From ietf-secretariat-reply@ietf.org Wed Jan 1 04:41:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2A91AE4F9 for ; Wed, 1 Jan 2014 04:41:22 -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 BTP8QEIP3a3p for ; Wed, 1 Jan 2014 04:41:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1BC1AE4FD for ; Wed, 1 Jan 2014 04:41:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140101124120.11420.79478.idtracker@ietfa.amsl.com> Date: Wed, 01 Jan 2014 04:41:20 -0800 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 12:41:22 -0000 Changed milestone "Submit draft-ietf-mpls-tp-te-mib for publication", set due date to January 2014 from December 2013. URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Wed Jan 1 04:48:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA24E1AE4D9 for ; Wed, 1 Jan 2014 04:48:08 -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 fgm2nvTucL5h for ; Wed, 1 Jan 2014 04:48:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E2B1AE4FB for ; Wed, 1 Jan 2014 04:48:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140101124806.30651.46038.idtracker@ietfa.amsl.com> Date: Wed, 01 Jan 2014 04:48:06 -0800 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 12:48:08 -0000 Changed milestone "Submit draft-ietf-mpls-ldp-hello-crypto-auth for publication", set due date to April 2014 from December 2013. URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Wed Jan 1 04:57:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704621AE27A for ; Wed, 1 Jan 2014 04:57:50 -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 oXMDACuvdmqh for ; Wed, 1 Jan 2014 04:57:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 797AD1AE4D9 for ; Wed, 1 Jan 2014 04:57:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140101125748.31073.24091.idtracker@ietfa.amsl.com> Date: Wed, 01 Jan 2014 04:57:48 -0800 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 12:57:50 -0000 Changed milestone "Submit draft-ietf-mpls-mldp-hsmp for publication", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From ryoo@etri.re.kr Wed Jan 1 17:39:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA38B1AE04B for ; Wed, 1 Jan 2014 17:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RP_MATCHES_RCVD=-0.538, 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 nTbzhnQONTuT for ; Wed, 1 Jan 2014 17:39:51 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 706571AE04A for ; Wed, 1 Jan 2014 17:39:50 -0800 (PST) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Jan 2014 10:39:40 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Thu, 2 Jan 2014 10:39:34 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , Yaacov Weingarten Thread-Topic: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHO9ATofTfzY1WrTkK6rDh0YabjsJpMSsLJgAAiYoCAGZTyhP//kS+AgAHUA6qAAxSFgIAGUXCZ Date: Thu, 2 Jan 2014 01:39:33 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AF703@SMTP2.etri.info> References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info>, <52BBD59D.8000104@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEFF9@SMTP2.etri.info>, <52BFF3AB.3070609@pi.nu> In-Reply-To: <52BFF3AB.3070609@pi.nu> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF703SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 01:39:55 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF703SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLCB0aGFua3MgZm9yIHRoZSBlbWFpbC4NCg0KSSBnb3QgdGhlIHBvaW50IG5vdy4NCkFzIHlv dSBtZW50aW9uZWQgaW4gdGhlIGxhc3QgcGFydCBvZiB5b3VyIGVtYWlsLCB3ZSdkIGJldHRlciBm aW5kIHRoZSB0ZXh0Lg0KRG8geW91IGhhdmUgYW55IHRleHQgdG8gcHJvcG9zZT8NCg0KQmVzdCBy ZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbSA6ICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51Pg0KU2VudCA6IDIwMTMtMTIt MjkgMTk6MDQ6MzggKCArMDk6MDAgKQ0KVG8gOiBSeW9vLCBKZW9uZy1kb25nIDxyeW9vQGV0cmku cmUua3I+LCBZYWFjb3YgV2VpbmdhcnRlbiA8d3lhYWNvdkBnbWFpbC5jb20+DQpDYyA6IG1wbHNA aWV0Zi5vcmcgPG1wbHNAaWV0Zi5vcmc+LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29s cy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+DQpT dWJqZWN0IDogUmU6IFttcGxzXSBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dQ0KDQpKZW9uZy1kb25nLA0KDQpJIGdvdCBjb25mbGlj dGluZyBhbnN3ZXJzIHlvdSBhbmQgSHV1Yi4gSSBkb24ndCBpbW1lZGlhdGVseSB3YW50IHRvDQpj aGFuZ2UgdGhlIHRleHQgaW4gdGhlIGRvY3VtZW50LCBidXQgcmF0aGVyIHVuZGVyc3RhbmQgaWYg aXQgbmVlZHMgdG8NCmJlIGNoYW5nZWQgdG8gZ2l2ZSBhIGNvbnRleHQgdG8gcmVzb2x2ZSBZYWFj b3YncyBjb21tZW50cy4NCg0KVGhlIHBvaW50IEkgd2FzIHRyeWluZyB0byBtYWtlIHdhcyB0aGF0 IHlvdSBhbmQgWWFhY292IHN0YW5kIG9uIHR3bw0KZGlmZmVyZW50IG1vdW50YWlucyAobmV0d29y ayBsYXllcmluZyBtb2RlbHMpIGFuZCBjYW4ndCBhZ3JlZSBpZiB5b3UNCnNlZSB0aGUgc3VuIHNl dCBvciBub3QuIFlvdSBzYXkgeW91IGNhbiwgYnV0IFlhYWNvIGRvbid0IGFncmVlLCBzaW5jZQ0K dGhlIHN1biBkaXNhcHBlYXJlZCBiZWhpbmQgdGhlIG1vdW50YWluIHlvdSBhcmUgc3RhbmRpbmcg b24gbW9yZSB0aGFuDQphbiBob3VyIGFnby4NCg0KV2hhdCBJIHRoaW5rIGhhcHBlbnMgaXMgdGhh dCB5b3UgdGhpbmsgYWJvdXQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcsDQpzZWxlY3RvciBhbmQgYnJp ZGdlIGluIHRoZSB0ZXJtcyBvZiB0aGUgbW9kZWwgeW91IGFyZSB1c2VkIHRvLg0KDQpXaGVuIFlh YWNvdiBoZWFyIHRoYXQgaGUgdGhpbmtzIGFib3V0IHRoZW0gdGhlIHdheSBoZSBpcyB1c2VkIHRv IHVzZQ0KdGhlbSBmcm9tIGhpcyBtb2RlbC4NCg0KTmVpdGhlciBtb2RlbCBpcyAicmlnaHQgb3Ig d3JvbmciIChib3RoIG1vdW50YWlucyBhcmUgcmVhbCkgYnV0IHRoZSBhcmUNCmRpZmZlcmVudC4N Cg0KV2hhdCBJIHRyaWVkIHRvIHNheSB3YXMgdGhhdCB3aGVuIFlhYWNvdiB0aGlua3MgYWJvdXQg YXMgcGh5c2ljYWwNCm9iamVjdHMsIHdoaWxlIHlvdSBzZWVtIHRvIHVzZSB0aGVtIGFzIGEgY2xh c3MgbmFtZSwgcGVyZm9ybWluZyB0aGUNCnNhbWUgZnVuY3Rpb24gZm9yIGFueSBsYXllciwgYnV0 IGFsc28gaW1wbGVtZW50ZWQgZGlmZmVyZW50bHkgb24NCmVhY2ggbGF5ZXIuDQoNCkkgdGhpbmsg dGhpcyB3YXMgd2hhdCBIdXViIGFncmVlZCB0bywgcmlnaHQ/DQoNCllhYWNvdiBzdGVwIG9mIHRo aXMgdHJhaW4gaGVyZSBpZiB5b3UgZG9uJ3QgYWdyZWUhDQoNClNvIHdoYXQgSSBpbnRlbmRlZCB0 byB0byB3YXMgdG8ga2VlcCB0aGUgY2xhc3MgbmFtZSAoZm9yIGV2ZXJ5IGV4aXN0aW5nDQpicmlk Z2UgYW5kIHNlbGVjdG9yLCBjYWxsaW5nIHRoZW0ganVzdCB0aGF0KSBhbmQgem9vbSBvbSBvbiBl LmcuIG9uZQ0KbmV0d29yayBsYXllcmluZyBpbnN0YW5jZSBvZiB0aGUgY2xhc3MsIHRhbGtpbmcg YWJvdXQgIm1wbHMgc2VsZWN0b3INCmZ1bmN0aW9uIiBhbmQgIm1wbHMgYnJpZGdlIGZ1bmN0aW9u Ii4NCg0KUGxlYXNlIG5vdGUgdGhhdCBJJ20gbm90IHN1Z2dlc3RpbmcgbmFtZXMgb3IgdGVybWlu b2xvZ3ksIGp1c3QgdHJ5aW5nDQp0byBmaWd1cmUgb3V0IGl0IGlmIHRoaXMgaXMgdGhlIHdoeSB5 b3UgZG9uJ3Qgc2VlbSB0byBhZ3JlZS4NCg0KSWYgd2UgYWdyZWUgd2hhdCB0aGUgcHJvYmxlbSBp cyB0aGVuIGl0IGlzIGZhaXJseSBlYXN5IHRvIGZpbmQgdGhlDQp0ZXh0IHRoYXQgbmVlZHMgdG8g Z28gaW50byB0aGUgZG9jdW1lbnQuDQoNCi9Mb2ENCg0KT24gMjAxMy0xMi0yNyAxMDo0MSwgUnlv bywgSmVvbmctZG9uZyB3cm90ZToNCj4gTG9hLA0KPiBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFu ZCB5b3VyIHF1ZXN0aW9uIGNvcnJlY3RseSwgYnV0IEkgd291bGQgc2F5IHRoYXQ6DQo+IEVhY2gg bGF5ZXIgaGFzIGl0cyBvd24gYnJpZGdlIGFuZCBzZWxlY3RvciBmb3IgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcsIHNvDQo+IHRoYXQgZWFjaCBsYXllciBjYW4gcGVyZm9ybSBwcm90ZWN0aW9uIHN3aXRj aGluZyBvZiBpdHMgb3duLg0KPiBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgImJyaWRn ZS9zZWxlY3RvciBmdW5jdGlvbiIsIGJ1dCBpbiBJVFUtVA0KPiB0ZXJtaW5vbG9neSwgdGhlIGJy aWRnZSBhbmQgc2VsZWN0b3IgYXJlIGluY2x1ZGVkIGluICJjb25uZWN0aW9uDQo+IGZ1bmN0aW9u IiBvZiBpdHMgb3duIGxheWVyIChmb3IgZXhhbXBsZSwgTVRfQyBmb3IgTVBMUy1UUCBjb25uZWN0 aW9uDQo+IGZ1bmN0aW9uLCB3aGljaCBpbmNsdWRlcyB0aGUgYnJpZGdlIGFuZCB0aGUgc2VsZWN0 b3IgZm9yIHRoZSBNUExTLVRQDQo+IGxheWVyKS4NCj4gRm9yIHRoZSBQU0MgUkZDLCBJIGRvbid0 IHRoaW5rIHdlIG5lZWQgdG8gaW50cm9kdWNlIGFueSBuZXcgdGVybWlub2xvZ3kNCj4gc3VjaCBh cyB0aGUgImJyaWRnZS9zZWxlY3RvciBmdW5jdGlvbiIgb3IgImNvbm5lY3Rpb24gZnVuY3Rpb24i Lg0KPiBUaGUgYnJpZGdlL3NlbGVjdG9yIGhhdmUgYWxyZWFkeSBiZWVuIGludHJvZHVjZWQgaW4g dGhlIFJGQzYzNzggKE1QTFMtVFANCj4gbGluZWFyIHByb3RlY3Rpb24pLg0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IEplb25nLWRvbmcNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICpGcm9tIDogKiJMb2Eg QW5kZXJzc29uIg0KPiAqU2VudCA6ICoyMDEzLTEyLTI2IDE2OjA3OjE1ICggKzA5OjAwICkNCj4g KlRvIDogKlJ5b28sIEplb25nLWRvbmcgLCBZYWFjb3YgV2VpbmdhcnRlbg0KPg0KPiAqQ2MgOiAq bXBsc0BpZXRmLm9yZyAsDQo+IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYu b3JnDQo+DQo+ICpTdWJqZWN0IDogKlJlOiBbbXBsc10gUXVlc3Rpb24gcmVnYXJkaW5nIFNEIHBy b3RlY3Rpb24gaW4NCj4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCj4NCj4gSmVvbmctZG9u ZywNCj4NCj4gSXMgdGhpcyBzaW1wbHkgYSBtYXR0ZXIgb2YgdGVybWlub2xvZ3kuIEVhY2ggbGF5 ZXIgbmVlZHMgdG8gcGVyZm9ybSBpdHMNCj4gb3duIHByb3RlY3Rpb24gc3dpdGNoaW5nLCBpLmUu IHRoZXJlIGhhcyB0byBiZSBhICpicmlkZ2UgZnVudGlvbiogYW5kIGENCj4gKnNlbGVjdG9yIGZ1 bmN0aW9uKiAob24gZWFjaCBsYXllciBkZXBlbmRpbmcgb24gdGhlIGltcGxlbWVudGF0aW9uKTsN Cj4gd2hpbGUgKmJyaWRnZSogYW5kICpzZWxlY3RvciogYXJlIHRoZSBwaHlzaWNhbCBsYXllciBl bnRpdGllcz8NCj4NCj4gL0xvYQ0KPg0KPiBPbiAyMDEzLTEyLTI2IDEyOjUxLCBSeW9vLCBKZW9u Zy1kb25nIHdyb3RlOg0KPiA+IFlhYWNvdiwgdGhhbmtzIGZvciB5b3VyIGVtYWlsLiBTb21laG93 LCBJIGZvcmdvdCB0byByZXNwb25kIGFuZCBhbSBzb3JyeQ0KPiA+IGZvciB0aGUgZGVsYXkuDQo+ ID4NCj4gPiBGaXJzdCBvZiBhbGwsIFlhYWNvdiwgaXQgaXMgbm90IHRydWUgdGhhdCB0aGUgcHJv dGVjdGlvbiBzd2l0Y2hpbmcgb2YNCj4gPiBFdGhlcm5ldCBvciBTREggZGVzY3JpYmVzIHRoZSBv cGVyYXRpb24gb2YgYW55IGxheWVyIGJlbG93LiBSYXRoZXIsIGVhY2gNCj4gPiBsYXllciBpcyBz dXBwb3NlZCB0byBvcGVyYXRlIGluZGVwZW5kZW50bHkuIEhvd2V2ZXIsIHRoZXJlIGFyZSBhIGZl dw0KPiA+IGV4Y2VwdGlvbnMsIHN1Y2ggYXMgaG9sZC1vZmYgdGltZXIgYW5kIEFJUyAoYXMgYSB0 cmlnZ2VyIGZyb20gbG93ZXINCj4gPiBsYXllcikuIEV2ZW4gdGhvdWdoIHRoZXJlIGV4aXN0IHNv bWUgcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRpb25zIHRoYXQNCj4gPiB1c2Ugb3RoZXIgaW5mb3Jt YXRpb24gZnJvbSBsb3dlciBsYXllciwgbW9zdCBvZiB0aGVtIGFyZSBub3QgcmVjb21tZW5kZWQN Cj4gPiBpbiBJVFUtVCBzdGFuZGFyZHMuDQo+ID4NCj4gPiBCcmlkZ2UgYW5kIHNlbGVjdG9yIGFy ZSBub3QgaW4gdGhlIHBoeXNpY2FsIGxheWVyLCBidXQgdGhleSBhcmUgcGFydCBvZg0KPiA+IHBy b3RlY3Rpb24gc3dpdGNoaW5nLiBPbmUgb2YgdGhlIGltcG9ydGFudCBvdXRwdXQgYWN0aW9ucyBm cm9tIHRoZSBQU0MNCj4gPiBjb250cm9sIGxvZ2ljIGlzIGNvb3JkaW5hdGluZyB0aGUgcG9zaXRp b25zIG9mIGJyaWRnZSBhbmQgc2VsZWN0b3IuDQo+ID4gQWxzbywgdGhlIGJyaWRnZSBvcGVyYXRp b24gcmVzcG9uZGluZyB0byB0aGUgUFNDIGNvbnRyb2wgbG9naWMgaXMgYWxzbw0KPiA+IHBhcnQg b2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIEhvd2V2ZXIsIGhvdyB0byByZWFsaXplIHRoZSBicmlk Z2UgYW5kDQo+ID4gc2VsZWN0b3IgKGZvciBleGFtcGxlLCBob3cgdG8gbWFuaXB1bGF0ZSBhIHBh Y2tldCBmb3J3YXJkaW5nIG1lY2hhbmlzbSkNCj4gPiBpcyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0 ZXIuDQo+ID4NCj4gPiBXaGVuIHdlIG1lbnRpb24gMSsxIG9yIDE6MSBpbiBwcm90ZWN0aW9uIGFy Y2hpdGVjdHVyZSwgd2UgZGVhbCB3aXRoIHRoZQ0KPiA+IG9wZXJhdGlvbiBvZiBicmlkZ2UuIEZv ciAxKzEgYXJjaGl0ZWN0dXJlLCB0aGUgdHJhZmZpYyBuZWVkcyB0byBiZQ0KPiA+IGR1cGxpY2F0 ZWQgYXQgdGhlIHNlbmRlciBhbmQgc2VudCB0byBib3RoIHBhdGhzIGFsbCB0aGUgdGltZSwgd2hp Y2ggaXMNCj4gPiB0aGUgc2FtZSBkZXNjcmlwdGlvbiBhcyB0aGUg4oCccGVybWFuZW50IGJyaWRn ZeKAnS4gRm9yIDE6MSBhcmNoaXRlY3R1cmUsDQo+ID4g4oCcc2VsZWN0b3IgYnJpZGdl4oCdIGlz IHVzZWQgdG8gc2VuZCB0aGUgdHJhZmZpYyBvbmx5IG9uZSBvZiB0aGUgcGF0aHMuIEFzDQo+ID4g dGhlIHByb3RlY3Rpb24gcGF0aCBjYW4gYmUgdXNlZCBieSBiZXN0IHRyYWZmaWMgaW4gcGFja2V0 IG5ldHdvcmtzIGFuZA0KPiA+IHRoZSBwYWNrZXQgZHVwbGljYXRpb24gdGFrZXMgbXVjaCBtb3Jl IGVmZm9ydC9pbnRlcm5hbCBiYW5kd2lkdGggaW5zaWRlDQo+ID4gYSBzd2l0Y2ggdGhhbiB0aGUg dGltZSBzbG90IGNvcHkgb2YgY2lyY3VpdCBuZXR3b3Jrcy4gMToxIGlzIGNvbnNpZGVyZWQNCj4g PiBhcyBwcmVmZXJhYmxlIGFyY2hpdGVjdHVyZSBpbiBwYWNrZXQgbmV0d29ya3MuDQo+ID4NCj4g PiBBcyB5b3UgbWlnaHQgcmVjYWxsIGZyb20gRy44MDMxIOKAkyBFdGhlcm5ldCBsaW5lYXIgcHJv dGVjdGlvbiwgdGhlDQo+ID4gc2VsZWN0b3IgYnJpZGdlIGlzIG5vdCByZWNvbW1lbmRlZCBkdWUg dG8gdGhlIHRyYWZmaWMgZmxhcHBpbmcgdW5kZXIgU0QNCj4gPiBjb25kaXRpb25zIG9uIGJvdGgg cGF0aHMuIEluc3RlYWQg4oCcYnJvYWRjYXN0IGJyaWRnZeKAnSBpcyBpbnRyb2R1Y2VkIHRvDQo+ ID4gc3VwcG9ydCBwcm90ZWN0aW9uIHN3aXRjaGluZyBhZ2FpbnN0IFNELiBCdXQsIHRoaXMgYnJv YWRjYXN0IGJyaWRnZSBpcw0KPiA+IG5vdCByZWNvbW1lbmRlZCBpbiBub24tcmV2ZXJ0aXZlIG1v ZGUgYXMgdGhlIHdvcmtpbmcgcGF0aCBuZWVkcyB0byBiZQ0KPiA+IG9jY3VwaWVkIGJ5IHRyYWZm aWMgYWxsIHRoZSB0aW1lLiBBbHNvIHRoZSBicm9hZGNhc3QgYnJpZGdlIGlzIG5vdA0KPiA+IGVm ZmljaWVudCwgc2luY2UgYnkgZGVmaW5pdGlvbiwgdGhlIHBhY2tldCBkdXBsaWNhdGlvbiBzaG91 bGQgb2NjdXINCj4gPiBkdXJpbmcgbm90IG9ubHkgU0QgYnV0IGFsc28gU0YsIEZTLCBNUywgZXRj LiBJbiB0aGlzIGRvY3VtZW50LCB3ZSBhcmUNCj4gPiBpbnRyb2R1Y2luZyBhbiBpbXByb3ZlZCBi cmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhhdmVzIGxpa2UgYSBzZWxlY3Rvcg0KPiA+IGJyaWRn ZSBidXQgZHVwbGljYXRlcyB0aGUgdHJhZmZpYyBvbmx5IHVuZGVyIFNEIGNvbmRpdGlvbiwgYW5k IHdlDQo+ID4gYmVsaWV2ZSB0aGF0IGl0IGFkZHJlc3NlcyBhbGwgdGhlIGlzc3VlcyB3aXRoIGV4 aXN0aW5nIGJyaWRnZXMuDQo+ID4NCj4gPiBXaGF0IHdlIG1lYW4gYnkgU0QgcHJvdGVjdGlvbiBp cyBhZ25vc3RpYyB0byB0aGUgU0QgZGV0ZWN0aW9uIG1ldGhvZCBpcw0KPiA+IHRoYXQgdGhlIHBy b3Bvc2VkIFNEIHByb3RlY3Rpb24gbWV0aG9kIChhZ2FpbiBob3cgdG8gb3BlcmF0ZSBhIGJyaWRn ZSBvcg0KPiA+IHdoYXQgYnJpZ2UgaXMgdXNlZCBpcyBhIHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcpIGNhbiBiZSB1c2VkIG5vDQo+ID4gbWF0dGVyIHdoYXQga2luZCBvZiBTRCBkZXRlY3Rp b24gbWV0aG9kcyAoZGF0YSBwYWNrZXQgY291bnRpbmcsIENDTQ0KPiA+IHBhY2tldCBjb3VudGlu Zywgb3IgZXZlbiBwcm9wcmlldGFyeSBzZXJ2ZXIgbGF5ZXIgU0QgZGV0ZWN0aW9uKSBpcyB1c2Vk Lg0KPiA+DQo+ID4gSSB0aGluayBJIGFuc3dlcmVkIGFsbCB0aGUgcXVlc3Rpb25zIG9uIHlvdXIg ZW1haWwuDQo+ID4NCj4gPiBZYWFjb3YsIGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbmNlcm5z IG9yIHF1ZXN0aW9ucywgcGxlYXNlIGxldCBtZQ0KPiBrbm93Lg0KPiA+DQo+ID4gQmVzdCByZWdh cmRzLA0KPiA+DQo+ID4gSmVvbmctZG9uZw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4gKkZyb20gOiAqIllhYWNvdiBXZWluZ2FydGVuIg0KPiA+ICpTZW50IDog KjIwMTMtMTItMTAgMTY6MDQ6MTcgKCArMDk6MDAgKQ0KPiA+ICpUbyA6ICpSeW9vLCBKZW9uZy1k b25nDQo+ID4gKkNjIDogKmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3Jn DQo+ID4gLCBtcGxzQGlldGYub3JnDQo+ID4gKlN1YmplY3QgOiAqUmU6IFF1ZXN0aW9uIHJlZ2Fy ZGluZyBTRCBwcm90ZWN0aW9uIGluDQo+ID4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCj4g Pg0KPiA+IEplb25nLWRvbmcsIGhpDQo+ID4NCj4gPiBUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHku IFlvdXIgYW5zd2VyIHNlZW1zIHRvIGJlIGFuIGFwcHJvcHJpYXRlIGFuc3dlcg0KPiA+IGZvciBv dGhlciBTRE9zLCBub3Qgc3VyZSB0aGF0IGl0IGlzIHRydWUgZm9yIHRoZSBjb250ZXh0IG9mIE1Q TFMgYW5kDQo+ID4gSUVURiB3b3JrLg0KPiA+DQo+ID4gMS4gWW91IHdyb3RlICJhbnkgcHJvdGVj dGlvbiBzd2l0Y2hpbmcgKGluY2x1ZGluZyBQU0MpIGlzIHN1cHBvc2VkIHRvDQo+ID4gZGVzY3Jp YmUgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiIgLSB0aGlzIG1heSBiZSB0 cnVlIGZvcg0KPiA+IEV0aGVybmV0IGFuZFNESCBhbmQgZm9yIGRvY3VtZW50cyB0aGF0IGFyZSBk ZXNjcmliaW5nIHRoZSBvcGVyYXRpb24gb2YNCj4gPiB0aGUgcGh5c2ljYWwgbGF5ZXIuIEhvd2V2 ZXIsIHRoZSBJRVRGICh0byBteSB1bmRlcnN0YW5kaW5nIC0gYW5kIEkgYW0NCj4gPiBjZXJ0YWlu bHkgd2lsbGluZyB0byBiZSBjb3JyZWN0ZWQgb24gdGhpcyBwb2ludCkgaXMgY29uY2VybmVkIHdp dGggdGhlDQo+ID4gcHJvdG9jb2wgYW5kIGxlYXZlIHRoZSBsb3dlciBsYXllcnMgdG8gaW1wbGVt ZW50YXRpb24uIEFsc28sIEkgYW0gbm90DQo+ID4gc3VyZSB0aGF0IHRoZSBjb25jZXB0cyBvZiBC cmlkZ2UgYW5kIFNlbGVjdG9yIHJlYWxseSBhcHBseSB0byBNUExTDQo+ID4gKGFsdGhvdWdoIEkg YWRtaXQgdGhhdCB3ZSBkaWQgbWVudGlvbiB0aGVtIGluIHRoZSBvcmlnaW5hbCBQU0MNCj4gZGVm aW5pdGlvbikuDQo+ID4NCj4gPiAyLiBZb3UgY2l0ZSB3aGF0IHdhcyB3cml0dGVuIGluIEc4MDMx IGFzIGp1c3RpZmljYXRpb24gZm9yIGluY2x1ZGluZw0KPiA+IGNvbnRlbnQgaW50byB5b3VyIGRy YWZ0LiBBZ2FpbiBpdCBpcyBoYXJkIHRvIHRyYW5zZmVyIG1ldGhvZG9sb2d5IGZyb20NCj4gPiBv bmUgU0RPIHRvIGFub3RoZXIgYW5kIHRoZXJlZm9yZSwgd2hpbGUgSSBoaWdobHkgcmVzcGVjdCB0 aGUgd29yayBvZiB0aGUNCj4gPiBJVFUsIEkgZG8gbm90IGZlZWwgdGhhdCB0aGlzIGlzIGEgdmVy eSBjbGVhciBqdXN0aWZpY2F0aW9uIGZvciBpbmNsdXNpb24NCj4gPiBpbnRvIGFuIGludGVybmV0 LWRyYWZ0LiBFdmVuIHdoZW4gdGhlIGRyYWZ0IHN0YXRlcyB0aGF0IGl0cyBwdXJwb3NlIGlzDQo+ ID4gdG8gYWRkcmVzcyB0aGUgY29uY2VybnMgb2YgdGhlIElUVS4NCj4gPg0KPiA+IDMuIFRvIHRo ZSBhY3R1YWwgcG9pbnQgb2YgbXkgZWFybGllciBjb21tZW50LCB0aGF0IHlvdSBkbyBub3Qgc2Vl bSB0bw0KPiA+IGFkZHJlc3MgLSB0aGUgcGFyYWdyYXBoIGluIFNlY3Rpb24gNy4zIHNlZW1zIHRv IHN0YXRlIHRoYXQgU0QgcHJvdGVjdGlvbg0KPiA+IGNoYW5nZXMgYWNjb3JkaW5nIHRvIHRoZSBt ZXRob2QgdGhhdCBpcyB1c2VkIHRvIGRldGVjdCB0aGUgU0QuIFRoaXMNCj4gPiBtZWFucyB0aGF0 IFNEIHByb3RlY3Rpb24gaXMgbm90IGFnbm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhl DQo+ID4gZGV0ZWN0aW9uLg0KPiA+IEFsdGVybmF0aXZlbHksIHdlIGNvdWxkIGJyZWFrIHRoaXMg ZGVwZW5kZW5jZSBhbmQgc3RhdGUgdGhhdCBTRA0KPiA+IHByb3RlY3Rpb24gaXMgYWx3YXlzIHBy b3ZpZGVkIGJ5IGNoYW5naW5nIHRoZSB0cmFuc21pc3Npb24gb2YgdGhlIGRhdGENCj4gPiB0byAx KzEgcHJvdGVjdGlvbiBpbiBjYXNlcyBvZiBTRCBkZXRlY3Rpb24sIHdoaWNoIGlzIHdoYXQgdGhl IHBhcmFncmFwaA0KPiA+IGlzIHN1Z2dlc3RpbmcgdG8gZG8gZm9yIHNvbWUgY2FzZXMuDQo+ID4N Cj4gPiBJIGhvcGUgdGhpcyBmb3JtdWxhdGlvbiBtYWtlIG15IGNvbW1lbnQgY2xlYXJlciBhbmQg d2UgYXJlIGFibGUgdG8NCj4gPiBkaXNjdXNzIHRoZSB0ZWNobm9sb2dpY2FsIGFwcHJvYWNoIHJh dGhlciB0aGFuIHRoZSBwaGlsb3NvcGhpY2FsDQo+ID4gZGlmZmVyZW5jZXMuDQo+ID4NCj4gPiBU aGFuayB5b3UsDQo+ID4geWFhY292DQo+ID4NCj4gPg0KPiA+IE9uIE1vbiwgRGVjIDksIDIwMTMg YXQgMTA6MDQgUE0sIFJ5b28sIEplb25nLWRvbmcgPiA+IHdyb3RlOg0KPiA+DQo+ID4gWWFhY292 LA0KPiA+DQo+ID4gWWVzLCBQU0MgaXMgc3VwcG9zZWQgdG8gYmUgYWdub3N0aWMgdG8gdGhlIG1l dGhvZCB1c2VkIGZvciB0aGUNCj4gPiBkZXRlY3Rpb24gb2YgU0YvU0QuDQo+ID4NCj4gPiBJdCBp cyBhbHNvIHRydWUgdGhhdCBhbnkgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGluY2x1ZGluZyBQU0Mp IGlzDQo+ID4gc3VwcG9zZWQgdG8gZGVzY3JpYmUgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgYW5k IHNlbGVjdG9yLg0KPiA+DQo+ID4gQXMgdGhlcmUgYXJlIG11bHRpcGxlIG9wdGlvbnMgZm9yIGRl dGVjdGluZyBTRCwgd2UgbmVlZGVkIHRvDQo+ID4gZGVzY3JpYmUgdGhlIGJlaGF2aW9yIG9mIHRo ZSBicmlkZ2UgdG8gY292ZXIgYWxsIHRoZSBwb3NzaWJsZQ0KPiA+IGRldGVjdGlvbiBtZXRob2Rz LiBEZXNjcmliaW5nIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGZvciBTRA0KPiA+IHByb3RlY3Rp b24gaXMgbm90IGEgbmV3IHRoaW5nLiBGb3IgZXhhbXBsZSwgRy44MDMxIC0gRXRoZXJuZXQgbGlu ZWFyDQo+ID4gcHJvdGVjdGlvbiBhbHNvIGRlc2NyaWJlcyB3aGF0IGJyaWRnZSBjYW4gYmUgdXNl ZCBpbiBvcmRlciB0bw0KPiA+IHByb3ZpZGUgcHJvdGVjdGlvbiBhZ2FpbnN0IFNELg0KPiA+DQo+ ID4gQmVzdCByZWdhcmRzLA0KPiA+DQo+ID4gSmVvbmctZG9uZw0KPiA+DQo+ID4NCj4gPg0KPiA+ DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gKkZyb20gOiAqIllhYWNvdiBXZWluZ2FydGVuIiA+ ID4NCj4gPiAqU2VudCA6ICoyMDEzLTEyLTA4IDIwOjAxOjU1ICggKzA5OjAwICkNCj4gPiAqVG8g OiAqZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcNCj4gPg0KPiA+ID4g PiwgbXBsc0BpZXRmLm9yZw0KPiA+ID4NCj4gPiAqQ2MgOiAqDQo+ID4gKlN1YmplY3QgOiAqUXVl c3Rpb24gcmVnYXJkaW5nIFNEIHByb3RlY3Rpb24gaW4NCj4gPiBkcmFmdC1pZXRmLW1wbHMtdHAt cHNjLWl0dQ0KPiA+DQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IEFmdGVyIHJlYWRpbmcgdGhyb3Vn aCB5b3VyIGRyYWZ0IG9uIHRoZSBleHRlbnNpb25zIHRvIFBTQyB0byBzdXBwb3J0DQo+ID4gU0Qg c2l0dWF0aW9ucywgSSBoYXZlIGEgcXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb24gLQ0KPiA+IElu IHlvdXIgaW50cm9kdWN0aW9uIC0geW91IHN0YXRlIHRoYXQgdGhlIG1ldGhvZCB1c2VkIHRvIGRl dGVjdCBTRA0KPiA+IHNpdHVhdGlvbnMgaXMgb3V0LW9mLXNjb3BlIG9mIHRoZSBkb2N1bWVudC4g RG9lcyB0aGlzIG1lYW4gdGhhdCBQU0MNCj4gPiBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3RpYyB0 byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoaXMgZGV0ZWN0aW9uPyBJdA0KPiA+IHNob3VsZCByZWFj dCBvbmx5IHRvIHRoZSBpbmRpY2F0aW9uLCBzaW1pbGFybHkgdG8gdGhlIHJlYWN0aW9uIGFuZA0K PiA+IHJlbGF0aW9uc2hpcCB0byB0aGUgbWV0aG9kIGZvciBkZXRlY3RpbmcgYW5kIGRlY2xhcmlu ZyBhIFNGIHNpdHVhdGlvbi4NCj4gPiBIb3dldmVyLCB3aGVuIHlvdSBleHBsYWluIHRoZSBiZWhh dmlvciBvZiB0aGUgU0QgcHJvdGVjdGlvbiBpbg0KPiA+IHNlY3Rpb24gNy4zIHlvdSBoYXZlIGEg cGFyYWdyYXBoIHRoYXQgc3RhcnRzIHdpdGggIklmIHRoZSBkZXRlY3Rpb24NCj4gPiBvZiBhIFNE IGRlcGVuZHMgb24gdGhlIHByZXNlbmNlIG9mIHVzZXIgZGF0YSBwYWNrZXRzIC4uLiIgdGhhdA0K PiA+IHNlZW1zIHRvIGluZGljYXRlIHRoYXQgdGhlIGJlaGF2aW9yIG9mIHRoZSBzeXN0ZW0gaXMg ZGVwZW5kZW50IHVwb24NCj4gPiB0aGUgZGV0ZWN0aW9uIG1ldGhvZCEgQ2xhcmlmaWNhdGlvbiB3 b3VsZCBiZSBhcHByZWNpYXRlZC4NCj4gPg0KPiA+IC0tDQo+ID4gVGhhbnggYW5kIEJSLA0KPiA+ IHlhYWNvdg0KPiA+DQo+ID4gL1N0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eS8NCj4g Pg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4gVGhhbnggYW5kIEJSLA0KPiA+IHlhYWNvdg0K PiA+DQo+ID4gL1N0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eS8NCj4gPg0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBt cGxzIG1haWxpbmcgbGlzdA0KPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPg0KPg0KPiAtLQ0KPg0KPg0KPiBMb2EgQW5k ZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gU2VuaW9yIE1QTFMgRXhwZXJ0 IGxvYUBwaS5udQ0KPiBIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogKzQ2 IDczOSA4MSAyMSA2NA0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEu aHVhd2VpLmNvbQ0KU2VuaW9yIE1QTFMgRXhwZXJ0IGxvYUBwaS5udQ0KSHVhd2VpIFRlY2hub2xv Z2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF703SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsIHRoYW5rcyBmb3IgdGhlIGVtYWlsLjwv ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkkgZ290IHRoZSBwb2ludCBub3cuPC9kaXY+DQo8ZGl2 IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+QXMgeW91IG1lbnRpb25lZCBpbiB0aGUgbGFzdCBw YXJ0IG9mIHlvdXIgZW1haWwsIHdlJ2QgYmV0dGVyJm5ic3A7ZmluZCB0aGUgdGV4dC4NCjxicj4N CkRvIHlvdSBoYXZlIGFueSB0ZXh0IHRvIHByb3Bvc2U/PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZu YnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRvbmc8L2Rp dj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48YnI+DQombmJzcDs8L2Rpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBpZD0iTWFpbFNpZ24iPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48Yj5Gcm9tIDogPC9iPiZxdW90O0xv YSBBbmRlcnNzb24mcXVvdDsgJmx0O2xvYUBwaS5udSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIw MTMtMTItMjkgMTk6MDQ6MzggKCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5SeW9vLCBK ZW9uZy1kb25nICZsdDtyeW9vQGV0cmkucmUua3ImZ3Q7LCBZYWFjb3YgV2VpbmdhcnRlbiAmbHQ7 d3lhYWNvdkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2MgOiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7 bXBsc0BpZXRmLm9yZyZndDssIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYu b3JnICZsdDtkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0IDogPC9iPlJlOiBbbXBsc10gUXVlc3Rpb24gcmVnYXJkaW5nIFNEIHByb3Rl Y3Rpb24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHU8YnI+DQo8YnI+DQpKZW9uZy1kb25n LDxicj4NCjxicj4NCkkgZ290IGNvbmZsaWN0aW5nIGFuc3dlcnMgeW91IGFuZCBIdXViLiBJIGRv bid0IGltbWVkaWF0ZWx5IHdhbnQgdG88YnI+DQpjaGFuZ2UgdGhlIHRleHQgaW4gdGhlIGRvY3Vt ZW50LCBidXQgcmF0aGVyIHVuZGVyc3RhbmQgaWYgaXQgbmVlZHMgdG88YnI+DQpiZSBjaGFuZ2Vk IHRvIGdpdmUgYSBjb250ZXh0IHRvIHJlc29sdmUgWWFhY292J3MgY29tbWVudHMuPGJyPg0KPGJy Pg0KVGhlIHBvaW50IEkgd2FzIHRyeWluZyB0byBtYWtlIHdhcyB0aGF0IHlvdSBhbmQgWWFhY292 IHN0YW5kIG9uIHR3bzxicj4NCmRpZmZlcmVudCBtb3VudGFpbnMgKG5ldHdvcmsgbGF5ZXJpbmcg bW9kZWxzKSBhbmQgY2FuJ3QgYWdyZWUgaWYgeW91PGJyPg0Kc2VlIHRoZSBzdW4gc2V0IG9yIG5v dC4gWW91IHNheSB5b3UgY2FuLCBidXQgWWFhY28gZG9uJ3QgYWdyZWUsIHNpbmNlPGJyPg0KdGhl IHN1biBkaXNhcHBlYXJlZCBiZWhpbmQgdGhlIG1vdW50YWluIHlvdSBhcmUgc3RhbmRpbmcgb24g bW9yZSB0aGFuPGJyPg0KYW4gaG91ciBhZ28uPGJyPg0KPGJyPg0KV2hhdCBJIHRoaW5rIGhhcHBl bnMgaXMgdGhhdCB5b3UgdGhpbmsgYWJvdXQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcsPGJyPg0Kc2Vs ZWN0b3IgYW5kIGJyaWRnZSBpbiB0aGUgdGVybXMgb2YgdGhlIG1vZGVsIHlvdSBhcmUgdXNlZCB0 by48YnI+DQo8YnI+DQpXaGVuIFlhYWNvdiBoZWFyIHRoYXQgaGUgdGhpbmtzIGFib3V0IHRoZW0g dGhlIHdheSBoZSBpcyB1c2VkIHRvIHVzZTxicj4NCnRoZW0gZnJvbSBoaXMgbW9kZWwuPGJyPg0K PGJyPg0KTmVpdGhlciBtb2RlbCBpcyAmcXVvdDtyaWdodCBvciB3cm9uZyZxdW90OyAoYm90aCBt b3VudGFpbnMgYXJlIHJlYWwpIGJ1dCB0aGUgYXJlPGJyPg0KZGlmZmVyZW50Ljxicj4NCjxicj4N CldoYXQgSSB0cmllZCB0byBzYXkgd2FzIHRoYXQgd2hlbiBZYWFjb3YgdGhpbmtzIGFib3V0IGFz IHBoeXNpY2FsPGJyPg0Kb2JqZWN0cywgd2hpbGUgeW91IHNlZW0gdG8gdXNlIHRoZW0gYXMgYSBj bGFzcyBuYW1lLCBwZXJmb3JtaW5nIHRoZTxicj4NCnNhbWUgZnVuY3Rpb24gZm9yIGFueSBsYXll ciwgYnV0IGFsc28gaW1wbGVtZW50ZWQgZGlmZmVyZW50bHkgb248YnI+DQplYWNoIGxheWVyLjxi cj4NCjxicj4NCkkgdGhpbmsgdGhpcyB3YXMgd2hhdCBIdXViIGFncmVlZCB0bywgcmlnaHQ/PGJy Pg0KPGJyPg0KWWFhY292IHN0ZXAgb2YgdGhpcyB0cmFpbiBoZXJlIGlmIHlvdSBkb24ndCBhZ3Jl ZSE8YnI+DQo8YnI+DQpTbyB3aGF0IEkgaW50ZW5kZWQgdG8gdG8gd2FzIHRvIGtlZXAgdGhlIGNs YXNzIG5hbWUgKGZvciBldmVyeSBleGlzdGluZzxicj4NCmJyaWRnZSBhbmQgc2VsZWN0b3IsIGNh bGxpbmcgdGhlbSBqdXN0IHRoYXQpIGFuZCB6b29tIG9tIG9uIGUuZy4gb25lPGJyPg0KbmV0d29y ayBsYXllcmluZyBpbnN0YW5jZSBvZiB0aGUgY2xhc3MsIHRhbGtpbmcgYWJvdXQgJnF1b3Q7bXBs cyBzZWxlY3Rvcjxicj4NCmZ1bmN0aW9uJnF1b3Q7IGFuZCAmcXVvdDttcGxzIGJyaWRnZSBmdW5j dGlvbiZxdW90Oy48YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IEknbSBub3Qgc3VnZ2VzdGlu ZyBuYW1lcyBvciB0ZXJtaW5vbG9neSwganVzdCB0cnlpbmc8YnI+DQp0byBmaWd1cmUgb3V0IGl0 IGlmIHRoaXMgaXMgdGhlIHdoeSB5b3UgZG9uJ3Qgc2VlbSB0byBhZ3JlZS48YnI+DQo8YnI+DQpJ ZiB3ZSBhZ3JlZSB3aGF0IHRoZSBwcm9ibGVtIGlzIHRoZW4gaXQgaXMgZmFpcmx5IGVhc3kgdG8g ZmluZCB0aGU8YnI+DQp0ZXh0IHRoYXQgbmVlZHMgdG8gZ28gaW50byB0aGUgZG9jdW1lbnQuPGJy Pg0KPGJyPg0KL0xvYTxicj4NCjxicj4NCk9uIDIwMTMtMTItMjcgMTA6NDEsIFJ5b28sIEplb25n LWRvbmcgd3JvdGU6PGJyPg0KJmd0OyBMb2EsPGJyPg0KJmd0OyBJIGFtIG5vdCBzdXJlIEkgdW5k ZXJzdGFuZCB5b3VyIHF1ZXN0aW9uIGNvcnJlY3RseSwgYnV0IEkgd291bGQgc2F5IHRoYXQ6PGJy Pg0KJmd0OyBFYWNoIGxheWVyIGhhcyBpdHMgb3duIGJyaWRnZSBhbmQgc2VsZWN0b3IgZm9yIHBy b3RlY3Rpb24gc3dpdGNoaW5nLCBzbzxicj4NCiZndDsgdGhhdCBlYWNoIGxheWVyIGNhbiBwZXJm b3JtIHByb3RlY3Rpb24gc3dpdGNoaW5nIG9mIGl0cyBvd24uPGJyPg0KJmd0OyBJIGFtIG5vdCBz dXJlIHdoYXQgeW91IG1lYW4gYnkgJnF1b3Q7YnJpZGdlL3NlbGVjdG9yIGZ1bmN0aW9uJnF1b3Q7 LCBidXQgaW4gSVRVLVQ8YnI+DQomZ3Q7IHRlcm1pbm9sb2d5LCB0aGUgYnJpZGdlIGFuZCBzZWxl Y3RvciBhcmUgaW5jbHVkZWQgaW4gJnF1b3Q7Y29ubmVjdGlvbjxicj4NCiZndDsgZnVuY3Rpb24m cXVvdDsgb2YgaXRzIG93biBsYXllciAoZm9yIGV4YW1wbGUsIE1UX0MgZm9yIE1QTFMtVFAgY29u bmVjdGlvbjxicj4NCiZndDsgZnVuY3Rpb24sIHdoaWNoIGluY2x1ZGVzIHRoZSBicmlkZ2UgYW5k IHRoZSBzZWxlY3RvciBmb3IgdGhlIE1QTFMtVFA8YnI+DQomZ3Q7IGxheWVyKS48YnI+DQomZ3Q7 IEZvciB0aGUgUFNDIFJGQywgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGludHJvZHVjZSBhbnkg bmV3IHRlcm1pbm9sb2d5PGJyPg0KJmd0OyBzdWNoIGFzIHRoZSAmcXVvdDticmlkZ2Uvc2VsZWN0 b3IgZnVuY3Rpb24mcXVvdDsgb3IgJnF1b3Q7Y29ubmVjdGlvbiBmdW5jdGlvbiZxdW90Oy48YnI+ DQomZ3Q7IFRoZSBicmlkZ2Uvc2VsZWN0b3IgaGF2ZSBhbHJlYWR5IGJlZW4gaW50cm9kdWNlZCBp biB0aGUgUkZDNjM3OCAoTVBMUy1UUDxicj4NCiZndDsgbGluZWFyIHByb3RlY3Rpb24pLjxicj4N CiZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgSmVvbmctZG9uZzxicj4NCiZndDs8YnI+DQom Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgKkZyb20gOiAqJnF1b3Q7TG9hIEFuZGVyc3Nv biZxdW90OyA8TE9BQFBJLk5VPjxicj4NCiZndDsgKlNlbnQgOiAqMjAxMy0xMi0yNiAxNjowNzox NSAoICYjNDM7MDk6MDAgKTxicj4NCiZndDsgKlRvIDogKlJ5b28sIEplb25nLWRvbmcgPFJZT09A RVRSSS5SRS5LUj4sIFlhYWNvdiBXZWluZ2FydGVuPGJyPg0KJmd0OyA8V1lBQUNPVkBHTUFJTC5D T00+PGJyPg0KJmd0OyAqQ2MgOiAqbXBsc0BpZXRmLm9yZyA8TVBMU0BJRVRGLk9SRz4sPGJyPg0K Jmd0OyBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZzxicj4NCiZndDsg PERSQUZULUlFVEYtTVBMUy1UUC1QU0MtSVRVQFRPT0xTLklFVEYuT1JHPjxicj4NCiZndDsgKlN1 YmplY3QgOiAqUmU6IFttcGxzXSBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbjxi cj4NCiZndDsgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHU8YnI+DQomZ3Q7PGJyPg0KJmd0OyBK ZW9uZy1kb25nLDxicj4NCiZndDs8YnI+DQomZ3Q7IElzIHRoaXMgc2ltcGx5IGEgbWF0dGVyIG9m IHRlcm1pbm9sb2d5LiBFYWNoIGxheWVyIG5lZWRzIHRvIHBlcmZvcm0gaXRzPGJyPg0KJmd0OyBv d24gcHJvdGVjdGlvbiBzd2l0Y2hpbmcsIGkuZS4gdGhlcmUgaGFzIHRvIGJlIGEgKmJyaWRnZSBm dW50aW9uKiBhbmQgYTxicj4NCiZndDsgKnNlbGVjdG9yIGZ1bmN0aW9uKiAob24gZWFjaCBsYXll ciBkZXBlbmRpbmcgb24gdGhlIGltcGxlbWVudGF0aW9uKTs8YnI+DQomZ3Q7IHdoaWxlICpicmlk Z2UqIGFuZCAqc2VsZWN0b3IqIGFyZSB0aGUgcGh5c2ljYWwgbGF5ZXIgZW50aXRpZXM/PGJyPg0K Jmd0Ozxicj4NCiZndDsgL0xvYTxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDIwMTMtMTItMjYgMTI6 NTEsIFJ5b28sIEplb25nLWRvbmcgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IFlhYWNvdiwgdGhhbmtz IGZvciB5b3VyIGVtYWlsLiBTb21laG93LCBJIGZvcmdvdCB0byByZXNwb25kIGFuZCBhbSBzb3Jy eTxicj4NCiZndDsgJmd0OyBmb3IgdGhlIGRlbGF5Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBGaXJzdCBvZiBhbGwsIFlhYWNvdiwgaXQgaXMgbm90IHRydWUgdGhhdCB0aGUgcHJvdGVj dGlvbiBzd2l0Y2hpbmcgb2Y8YnI+DQomZ3Q7ICZndDsgRXRoZXJuZXQgb3IgU0RIIGRlc2NyaWJl cyB0aGUgb3BlcmF0aW9uIG9mIGFueSBsYXllciBiZWxvdy4gUmF0aGVyLCBlYWNoPGJyPg0KJmd0 OyAmZ3Q7IGxheWVyIGlzIHN1cHBvc2VkIHRvIG9wZXJhdGUgaW5kZXBlbmRlbnRseS4gSG93ZXZl ciwgdGhlcmUgYXJlIGEgZmV3PGJyPg0KJmd0OyAmZ3Q7IGV4Y2VwdGlvbnMsIHN1Y2ggYXMgaG9s ZC1vZmYgdGltZXIgYW5kIEFJUyAoYXMgYSB0cmlnZ2VyIGZyb20gbG93ZXI8YnI+DQomZ3Q7ICZn dDsgbGF5ZXIpLiBFdmVuIHRob3VnaCB0aGVyZSBleGlzdCBzb21lIHByb3ByaWV0YXJ5IGltcGxl bWVudGF0aW9ucyB0aGF0PGJyPg0KJmd0OyAmZ3Q7IHVzZSBvdGhlciBpbmZvcm1hdGlvbiBmcm9t IGxvd2VyIGxheWVyLCBtb3N0IG9mIHRoZW0gYXJlIG5vdCByZWNvbW1lbmRlZDxicj4NCiZndDsg Jmd0OyBpbiBJVFUtVCBzdGFuZGFyZHMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEJy aWRnZSBhbmQgc2VsZWN0b3IgYXJlIG5vdCBpbiB0aGUgcGh5c2ljYWwgbGF5ZXIsIGJ1dCB0aGV5 IGFyZSBwYXJ0IG9mPGJyPg0KJmd0OyAmZ3Q7IHByb3RlY3Rpb24gc3dpdGNoaW5nLiBPbmUgb2Yg dGhlIGltcG9ydGFudCBvdXRwdXQgYWN0aW9ucyBmcm9tIHRoZSBQU0M8YnI+DQomZ3Q7ICZndDsg Y29udHJvbCBsb2dpYyBpcyBjb29yZGluYXRpbmcgdGhlIHBvc2l0aW9ucyBvZiBicmlkZ2UgYW5k IHNlbGVjdG9yLjxicj4NCiZndDsgJmd0OyBBbHNvLCB0aGUgYnJpZGdlIG9wZXJhdGlvbiByZXNw b25kaW5nIHRvIHRoZSBQU0MgY29udHJvbCBsb2dpYyBpcyBhbHNvPGJyPg0KJmd0OyAmZ3Q7IHBh cnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIEhvd2V2ZXIsIGhvdyB0byByZWFsaXplIHRoZSBi cmlkZ2UgYW5kPGJyPg0KJmd0OyAmZ3Q7IHNlbGVjdG9yIChmb3IgZXhhbXBsZSwgaG93IHRvIG1h bmlwdWxhdGUgYSBwYWNrZXQgZm9yd2FyZGluZyBtZWNoYW5pc20pPGJyPg0KJmd0OyAmZ3Q7IGlz IGFuIGltcGxlbWVudGF0aW9uIG1hdHRlci48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg V2hlbiB3ZSBtZW50aW9uIDEmIzQzOzEgb3IgMToxIGluIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJl LCB3ZSBkZWFsIHdpdGggdGhlPGJyPg0KJmd0OyAmZ3Q7IG9wZXJhdGlvbiBvZiBicmlkZ2UuIEZv ciAxJiM0MzsxIGFyY2hpdGVjdHVyZSwgdGhlIHRyYWZmaWMgbmVlZHMgdG8gYmU8YnI+DQomZ3Q7 ICZndDsgZHVwbGljYXRlZCBhdCB0aGUgc2VuZGVyIGFuZCBzZW50IHRvIGJvdGggcGF0aHMgYWxs IHRoZSB0aW1lLCB3aGljaCBpczxicj4NCiZndDsgJmd0OyB0aGUgc2FtZSBkZXNjcmlwdGlvbiBh cyB0aGUg4oCccGVybWFuZW50IGJyaWRnZeKAnS4gRm9yIDE6MSBhcmNoaXRlY3R1cmUsPGJyPg0K Jmd0OyAmZ3Q7IOKAnHNlbGVjdG9yIGJyaWRnZeKAnSBpcyB1c2VkIHRvIHNlbmQgdGhlIHRyYWZm aWMgb25seSBvbmUgb2YgdGhlIHBhdGhzLiBBczxicj4NCiZndDsgJmd0OyB0aGUgcHJvdGVjdGlv biBwYXRoIGNhbiBiZSB1c2VkIGJ5IGJlc3QgdHJhZmZpYyBpbiBwYWNrZXQgbmV0d29ya3MgYW5k PGJyPg0KJmd0OyAmZ3Q7IHRoZSBwYWNrZXQgZHVwbGljYXRpb24gdGFrZXMgbXVjaCBtb3JlIGVm Zm9ydC9pbnRlcm5hbCBiYW5kd2lkdGggaW5zaWRlPGJyPg0KJmd0OyAmZ3Q7IGEgc3dpdGNoIHRo YW4gdGhlIHRpbWUgc2xvdCBjb3B5IG9mIGNpcmN1aXQgbmV0d29ya3MuIDE6MSBpcyBjb25zaWRl cmVkPGJyPg0KJmd0OyAmZ3Q7IGFzIHByZWZlcmFibGUgYXJjaGl0ZWN0dXJlIGluIHBhY2tldCBu ZXR3b3Jrcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQXMgeW91IG1pZ2h0IHJlY2Fs bCBmcm9tIEcuODAzMSDigJMgRXRoZXJuZXQgbGluZWFyIHByb3RlY3Rpb24sIHRoZTxicj4NCiZn dDsgJmd0OyBzZWxlY3RvciBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVkIGR1ZSB0byB0aGUgdHJh ZmZpYyBmbGFwcGluZyB1bmRlciBTRDxicj4NCiZndDsgJmd0OyBjb25kaXRpb25zIG9uIGJvdGgg cGF0aHMuIEluc3RlYWQg4oCcYnJvYWRjYXN0IGJyaWRnZeKAnSBpcyBpbnRyb2R1Y2VkIHRvPGJy Pg0KJmd0OyAmZ3Q7IHN1cHBvcnQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgYWdhaW5zdCBTRC4gQnV0 LCB0aGlzIGJyb2FkY2FzdCBicmlkZ2UgaXM8YnI+DQomZ3Q7ICZndDsgbm90IHJlY29tbWVuZGVk IGluIG5vbi1yZXZlcnRpdmUgbW9kZSBhcyB0aGUgd29ya2luZyBwYXRoIG5lZWRzIHRvIGJlPGJy Pg0KJmd0OyAmZ3Q7IG9jY3VwaWVkIGJ5IHRyYWZmaWMgYWxsIHRoZSB0aW1lLiBBbHNvIHRoZSBi cm9hZGNhc3QgYnJpZGdlIGlzIG5vdDxicj4NCiZndDsgJmd0OyBlZmZpY2llbnQsIHNpbmNlIGJ5 IGRlZmluaXRpb24sIHRoZSBwYWNrZXQgZHVwbGljYXRpb24gc2hvdWxkIG9jY3VyPGJyPg0KJmd0 OyAmZ3Q7IGR1cmluZyBub3Qgb25seSBTRCBidXQgYWxzbyBTRiwgRlMsIE1TLCBldGMuIEluIHRo aXMgZG9jdW1lbnQsIHdlIGFyZTxicj4NCiZndDsgJmd0OyBpbnRyb2R1Y2luZyBhbiBpbXByb3Zl ZCBicmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhhdmVzIGxpa2UgYSBzZWxlY3Rvcjxicj4NCiZn dDsgJmd0OyBicmlkZ2UgYnV0IGR1cGxpY2F0ZXMgdGhlIHRyYWZmaWMgb25seSB1bmRlciBTRCBj b25kaXRpb24sIGFuZCB3ZTxicj4NCiZndDsgJmd0OyBiZWxpZXZlIHRoYXQgaXQgYWRkcmVzc2Vz IGFsbCB0aGUgaXNzdWVzIHdpdGggZXhpc3RpbmcgYnJpZGdlcy48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgV2hhdCB3ZSBtZWFuIGJ5IFNEIHByb3RlY3Rpb24gaXMgYWdub3N0aWMgdG8g dGhlIFNEIGRldGVjdGlvbiBtZXRob2QgaXM8YnI+DQomZ3Q7ICZndDsgdGhhdCB0aGUgcHJvcG9z ZWQgU0QgcHJvdGVjdGlvbiBtZXRob2QgKGFnYWluIGhvdyB0byBvcGVyYXRlIGEgYnJpZGdlIG9y PGJyPg0KJmd0OyAmZ3Q7IHdoYXQgYnJpZ2UgaXMgdXNlZCBpcyBhIHBhcnQgb2YgcHJvdGVjdGlv biBzd2l0Y2hpbmcpIGNhbiBiZSB1c2VkIG5vPGJyPg0KJmd0OyAmZ3Q7IG1hdHRlciB3aGF0IGtp bmQgb2YgU0QgZGV0ZWN0aW9uIG1ldGhvZHMgKGRhdGEgcGFja2V0IGNvdW50aW5nLCBDQ008YnI+ DQomZ3Q7ICZndDsgcGFja2V0IGNvdW50aW5nLCBvciBldmVuIHByb3ByaWV0YXJ5IHNlcnZlciBs YXllciBTRCBkZXRlY3Rpb24pIGlzIHVzZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IEkgdGhpbmsgSSBhbnN3ZXJlZCBhbGwgdGhlIHF1ZXN0aW9ucyBvbiB5b3VyIGVtYWlsLjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBZYWFjb3YsIGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVy IGNvbmNlcm5zIG9yIHF1ZXN0aW9ucywgcGxlYXNlIGxldCBtZTxicj4NCiZndDsga25vdy48YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBKZW9uZy1kb25nPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCiZndDsgJmd0OyAqRnJvbSA6IComcXVvdDtZYWFjb3YgV2VpbmdhcnRlbiZxdW90Ozxi cj4NCiZndDsgJmd0OyAqU2VudCA6ICoyMDEzLTEyLTEwIDE2OjA0OjE3ICggJiM0MzswOTowMCAp PGJyPg0KJmd0OyAmZ3Q7ICpUbyA6ICpSeW9vLCBKZW9uZy1kb25nPGJyPg0KJmd0OyAmZ3Q7ICpD YyA6ICpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZzxicj4NCiZndDsg Jmd0OyAsIG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgKlN1YmplY3QgOiAqUmU6IFF1ZXN0 aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9uIGluPGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0LWlldGYt bXBscy10cC1wc2MtaXR1PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEplb25nLWRvbmcs IGhpPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoYW5rIHlvdSBmb3IgeW91ciByZXBs eS4gWW91ciBhbnN3ZXIgc2VlbXMgdG8gYmUgYW4gYXBwcm9wcmlhdGUgYW5zd2VyPGJyPg0KJmd0 OyAmZ3Q7IGZvciBvdGhlciBTRE9zLCBub3Qgc3VyZSB0aGF0IGl0IGlzIHRydWUgZm9yIHRoZSBj b250ZXh0IG9mIE1QTFMgYW5kPGJyPg0KJmd0OyAmZ3Q7IElFVEYgd29yay48YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgMS4gWW91IHdyb3RlICZxdW90O2FueSBwcm90ZWN0aW9uIHN3aXRj aGluZyAoaW5jbHVkaW5nIFBTQykgaXMgc3VwcG9zZWQgdG88YnI+DQomZ3Q7ICZndDsgZGVzY3Jp YmUgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiZxdW90OyAtIHRoaXMgbWF5 IGJlIHRydWUgZm9yPGJyPg0KJmd0OyAmZ3Q7IEV0aGVybmV0IGFuZFNESCBhbmQgZm9yIGRvY3Vt ZW50cyB0aGF0IGFyZSBkZXNjcmliaW5nIHRoZSBvcGVyYXRpb24gb2Y8YnI+DQomZ3Q7ICZndDsg dGhlIHBoeXNpY2FsIGxheWVyLiBIb3dldmVyLCB0aGUgSUVURiAodG8gbXkgdW5kZXJzdGFuZGlu ZyAtIGFuZCBJIGFtPGJyPg0KJmd0OyAmZ3Q7IGNlcnRhaW5seSB3aWxsaW5nIHRvIGJlIGNvcnJl Y3RlZCBvbiB0aGlzIHBvaW50KSBpcyBjb25jZXJuZWQgd2l0aCB0aGU8YnI+DQomZ3Q7ICZndDsg cHJvdG9jb2wgYW5kIGxlYXZlIHRoZSBsb3dlciBsYXllcnMgdG8gaW1wbGVtZW50YXRpb24uIEFs c28sIEkgYW0gbm90PGJyPg0KJmd0OyAmZ3Q7IHN1cmUgdGhhdCB0aGUgY29uY2VwdHMgb2YgQnJp ZGdlIGFuZCBTZWxlY3RvciByZWFsbHkgYXBwbHkgdG8gTVBMUzxicj4NCiZndDsgJmd0OyAoYWx0 aG91Z2ggSSBhZG1pdCB0aGF0IHdlIGRpZCBtZW50aW9uIHRoZW0gaW4gdGhlIG9yaWdpbmFsIFBT Qzxicj4NCiZndDsgZGVmaW5pdGlvbikuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDIu IFlvdSBjaXRlIHdoYXQgd2FzIHdyaXR0ZW4gaW4gRzgwMzEgYXMganVzdGlmaWNhdGlvbiBmb3Ig aW5jbHVkaW5nPGJyPg0KJmd0OyAmZ3Q7IGNvbnRlbnQgaW50byB5b3VyIGRyYWZ0LiBBZ2FpbiBp dCBpcyBoYXJkIHRvIHRyYW5zZmVyIG1ldGhvZG9sb2d5IGZyb208YnI+DQomZ3Q7ICZndDsgb25l IFNETyB0byBhbm90aGVyIGFuZCB0aGVyZWZvcmUsIHdoaWxlIEkgaGlnaGx5IHJlc3BlY3QgdGhl IHdvcmsgb2YgdGhlPGJyPg0KJmd0OyAmZ3Q7IElUVSwgSSBkbyBub3QgZmVlbCB0aGF0IHRoaXMg aXMgYSB2ZXJ5IGNsZWFyIGp1c3RpZmljYXRpb24gZm9yIGluY2x1c2lvbjxicj4NCiZndDsgJmd0 OyBpbnRvIGFuIGludGVybmV0LWRyYWZ0LiBFdmVuIHdoZW4gdGhlIGRyYWZ0IHN0YXRlcyB0aGF0 IGl0cyBwdXJwb3NlIGlzPGJyPg0KJmd0OyAmZ3Q7IHRvIGFkZHJlc3MgdGhlIGNvbmNlcm5zIG9m IHRoZSBJVFUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDMuIFRvIHRoZSBhY3R1YWwg cG9pbnQgb2YgbXkgZWFybGllciBjb21tZW50LCB0aGF0IHlvdSBkbyBub3Qgc2VlbSB0bzxicj4N CiZndDsgJmd0OyBhZGRyZXNzIC0gdGhlIHBhcmFncmFwaCBpbiBTZWN0aW9uIDcuMyBzZWVtcyB0 byBzdGF0ZSB0aGF0IFNEIHByb3RlY3Rpb248YnI+DQomZ3Q7ICZndDsgY2hhbmdlcyBhY2NvcmRp bmcgdG8gdGhlIG1ldGhvZCB0aGF0IGlzIHVzZWQgdG8gZGV0ZWN0IHRoZSBTRC4gVGhpczxicj4N CiZndDsgJmd0OyBtZWFucyB0aGF0IFNEIHByb3RlY3Rpb24gaXMgbm90IGFnbm9zdGljIHRvIHRo ZSBtZXRob2QgdXNlZCBmb3IgdGhlPGJyPg0KJmd0OyAmZ3Q7IGRldGVjdGlvbi48YnI+DQomZ3Q7 ICZndDsgQWx0ZXJuYXRpdmVseSwgd2UgY291bGQgYnJlYWsgdGhpcyBkZXBlbmRlbmNlIGFuZCBz dGF0ZSB0aGF0IFNEPGJyPg0KJmd0OyAmZ3Q7IHByb3RlY3Rpb24gaXMgYWx3YXlzIHByb3ZpZGVk IGJ5IGNoYW5naW5nIHRoZSB0cmFuc21pc3Npb24gb2YgdGhlIGRhdGE8YnI+DQomZ3Q7ICZndDsg dG8gMSYjNDM7MSBwcm90ZWN0aW9uIGluIGNhc2VzIG9mIFNEIGRldGVjdGlvbiwgd2hpY2ggaXMg d2hhdCB0aGUgcGFyYWdyYXBoPGJyPg0KJmd0OyAmZ3Q7IGlzIHN1Z2dlc3RpbmcgdG8gZG8gZm9y IHNvbWUgY2FzZXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgaG9wZSB0aGlzIGZv cm11bGF0aW9uIG1ha2UgbXkgY29tbWVudCBjbGVhcmVyIGFuZCB3ZSBhcmUgYWJsZSB0bzxicj4N CiZndDsgJmd0OyBkaXNjdXNzIHRoZSB0ZWNobm9sb2dpY2FsIGFwcHJvYWNoIHJhdGhlciB0aGFu IHRoZSBwaGlsb3NvcGhpY2FsPGJyPg0KJmd0OyAmZ3Q7IGRpZmZlcmVuY2VzLjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyBUaGFuayB5b3UsPGJyPg0KJmd0OyAmZ3Q7IHlhYWNvdjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiBNb24sIERlYyA5LCAy MDEzIGF0IDEwOjA0IFBNLCBSeW9vLCBKZW9uZy1kb25nICZndDsgJmd0OyB3cm90ZTo8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgWWFhY292LDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBZZXMsIFBTQyBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVz ZWQgZm9yIHRoZTxicj4NCiZndDsgJmd0OyBkZXRlY3Rpb24gb2YgU0YvU0QuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IEl0IGlzIGFsc28gdHJ1ZSB0aGF0IGFueSBwcm90ZWN0aW9uIHN3 aXRjaGluZyAoaW5jbHVkaW5nIFBTQykgaXM8YnI+DQomZ3Q7ICZndDsgc3VwcG9zZWQgdG8gZGVz Y3JpYmUgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLjxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBBcyB0aGVyZSBhcmUgbXVsdGlwbGUgb3B0aW9ucyBmb3IgZGV0ZWN0 aW5nIFNELCB3ZSBuZWVkZWQgdG88YnI+DQomZ3Q7ICZndDsgZGVzY3JpYmUgdGhlIGJlaGF2aW9y IG9mIHRoZSBicmlkZ2UgdG8gY292ZXIgYWxsIHRoZSBwb3NzaWJsZTxicj4NCiZndDsgJmd0OyBk ZXRlY3Rpb24gbWV0aG9kcy4gRGVzY3JpYmluZyB0aGUgb3BlcmF0aW9uIG9mIGJyaWRnZSBmb3Ig U0Q8YnI+DQomZ3Q7ICZndDsgcHJvdGVjdGlvbiBpcyBub3QgYSBuZXcgdGhpbmcuIEZvciBleGFt cGxlLCBHLjgwMzEgLSBFdGhlcm5ldCBsaW5lYXI8YnI+DQomZ3Q7ICZndDsgcHJvdGVjdGlvbiBh bHNvIGRlc2NyaWJlcyB3aGF0IGJyaWRnZSBjYW4gYmUgdXNlZCBpbiBvcmRlciB0bzxicj4NCiZn dDsgJmd0OyBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCBTRC48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBK ZW9uZy1kb25nPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0 OyAqRnJvbSA6IComcXVvdDtZYWFjb3YgV2VpbmdhcnRlbiZxdW90OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgKlNlbnQgOiAqMjAxMy0xMi0wOCAyMDowMTo1NSAoICYjNDM7MDk6MDAgKTxicj4N CiZndDsgJmd0OyAqVG8gOiAqZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5v cmc8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7LCBtcGxzQGlldGYub3Jn PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgKkNjIDogKjxicj4NCiZndDsgJmd0 OyAqU3ViamVjdCA6ICpRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbjxicj4NCiZn dDsgJmd0OyBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg QWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHlvdXIgZHJhZnQgb24gdGhlIGV4dGVuc2lvbnMgdG8gUFND IHRvIHN1cHBvcnQ8YnI+DQomZ3Q7ICZndDsgU0Qgc2l0dWF0aW9ucywgSSBoYXZlIGEgcXVlc3Rp b24gZm9yIGNsYXJpZmljYXRpb24gLTxicj4NCiZndDsgJmd0OyBJbiB5b3VyIGludHJvZHVjdGlv biAtIHlvdSBzdGF0ZSB0aGF0IHRoZSBtZXRob2QgdXNlZCB0byBkZXRlY3QgU0Q8YnI+DQomZ3Q7 ICZndDsgc2l0dWF0aW9ucyBpcyBvdXQtb2Ytc2NvcGUgb2YgdGhlIGRvY3VtZW50LiBEb2VzIHRo aXMgbWVhbiB0aGF0IFBTQzxicj4NCiZndDsgJmd0OyBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3Rp YyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoaXMgZGV0ZWN0aW9uPyBJdDxicj4NCiZndDsgJmd0 OyBzaG91bGQgcmVhY3Qgb25seSB0byB0aGUgaW5kaWNhdGlvbiwgc2ltaWxhcmx5IHRvIHRoZSBy ZWFjdGlvbiBhbmQ8YnI+DQomZ3Q7ICZndDsgcmVsYXRpb25zaGlwIHRvIHRoZSBtZXRob2QgZm9y IGRldGVjdGluZyBhbmQgZGVjbGFyaW5nIGEgU0Ygc2l0dWF0aW9uLjxicj4NCiZndDsgJmd0OyBI b3dldmVyLCB3aGVuIHlvdSBleHBsYWluIHRoZSBiZWhhdmlvciBvZiB0aGUgU0QgcHJvdGVjdGlv biBpbjxicj4NCiZndDsgJmd0OyBzZWN0aW9uIDcuMyB5b3UgaGF2ZSBhIHBhcmFncmFwaCB0aGF0 IHN0YXJ0cyB3aXRoICZxdW90O0lmIHRoZSBkZXRlY3Rpb248YnI+DQomZ3Q7ICZndDsgb2YgYSBT RCBkZXBlbmRzIG9uIHRoZSBwcmVzZW5jZSBvZiB1c2VyIGRhdGEgcGFja2V0cyAuLi4mcXVvdDsg dGhhdDxicj4NCiZndDsgJmd0OyBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IHRoZSBiZWhhdmlvciBv ZiB0aGUgc3lzdGVtIGlzIGRlcGVuZGVudCB1cG9uPGJyPg0KJmd0OyAmZ3Q7IHRoZSBkZXRlY3Rp b24gbWV0aG9kISBDbGFyaWZpY2F0aW9uIHdvdWxkIGJlIGFwcHJlY2lhdGVkLjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0OyBUaGFueCBhbmQgQlIsPGJyPg0K Jmd0OyAmZ3Q7IHlhYWNvdjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAvU3RpbGwgbG9v a2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5Lzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLTxicj4NCiZndDsg Jmd0OyBUaGFueCBhbmQgQlIsPGJyPg0KJmd0OyAmZ3Q7IHlhYWNvdjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAvU3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5Lzxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBtcGxzIG1haWxpbmcg bGlzdDxicj4NCiZndDsgJmd0OyBtcGxzQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IExvYSBBbmRlcnNz b24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxicj4NCiZndDsgU2VuaW9yIE1QTFMgRXhw ZXJ0IGxvYUBwaS5udTxicj4NCiZndDsgSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkg cGhvbmU6ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJyPg0KPGJyPg0KLS0gPGJyPg0KPGJyPg0KPGJy Pg0KTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPGJyPg0KU2VuaW9y IE1QTFMgRXhwZXJ0IGxvYUBwaS5udTxicj4NCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRh bnQpIHBob25lOiAmIzQzOzQ2IDczOSA4MSAyMSA2NDxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF703SMTP2etriinfo_-- From eosborne@cisco.com Thu Jan 2 01:53:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9742A1AE48D for ; Thu, 2 Jan 2014 01:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 3lleYTGBTvW3 for ; Thu, 2 Jan 2014 01:53:15 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2997C1AE47C for ; Thu, 2 Jan 2014 01:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6907; q=dns/txt; s=iport; t=1388656388; x=1389865988; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lUPXLyt/c1Aoj1Bq6yWxh4f8TrN7pZbUxIl78GAUOnA=; b=F9QVvyu8T4s6q4xccIfN5O+hljfE/DDHeUDGhVsN3Wc1d5qyw605Jfnn F4ywOD4G55xSaTyJn4zM1XPjSsjTq9doFesX8n9Www5syCF/NLhdPVnnE KBHY/+g3TG08OStlrqn/BQ5+6Jf6X9557TuKJI+UDjS/po76JmePWgTDJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFALI2xVKtJV2Y/2dsb2JhbABYgwuBDaZkkhGBDBZ0giUBAQEEOjEODAICAgEIEQQBAQEKFAkHGxcTAQkIAgQBDQUIh2gDEcI6FwSNBoExEAIBHjEHBoMdgRMBA5YxjkCFOoMtgio X-IronPort-AV: E=Sophos;i="4.95,590,1384300800"; d="scan'208";a="294874105" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 02 Jan 2014 09:53:08 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s029r7aT001212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Jan 2014 09:53:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 2 Jan 2014 03:53:07 -0600 From: "Eric Osborne (eosborne)" To: Loa Andersson , Arun Viswanathan , "Ross Callon" Thread-Topic: bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 Thread-Index: AQHPBTIqMnx1t2cGQ0O9xvAngLUbkZpvHvwAgAA6owCAAHKsAIABacTA Date: Thu, 2 Jan 2014 09:53:06 +0000 Message-ID: <20ECF67871905846A80F77F8F4A2757210496CFA@xmb-rcd-x09.cisco.com> References: <52C122FE.8090706@pi.nu> <52C3B2D0.5030604@pi.nu> In-Reply-To: <52C3B2D0.5030604@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vishwas.manral@hp.com" , "mpls@ietf.org" , "rhboivie@us.ibm.com" , "nkfeldman@yahoo.com" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" , Ina Minei , Ina Minei , Bob Thomas , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 09:53:17 -0000 I don't have addresses for any of the four you're looking for, sorry. eric -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Wednesday, January 01, 2014 1:17 AM To: Arun Viswanathan; Ross Callon Cc: mpls-chairs@tools.ietf.org; Eric Osborne (eosborne); vishwas.manral@hp.= com; Rajiv Papneja; draft-ietf-mpls-ldp-ipv6@tools.ietf.org; Ina Minei; Eri= c Gray; Eric Rosen (erosen); Yakov Rekhter; mpls@ietf.org; Ina Minei; nkfel= dman@yahoo.com; rhboivie@us.ibm.com; Bob Thomas Subject: Re: bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 Folks, The devils is in details - it is the way that the acknowledgement were phra= sed "The ideas and text in RFC 3036 were collected from a number of sources. We would like to thank Rick Boivie, Ross Callon, Alex Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Rekhter, and Arun Viswanathan for their input for RFC 3036." To me that reads as text were contributed, and to remove the pre Nov 2008 disclaimer we need a statement tht you re willing to granted the BCP 7= 8 rights to the IETF trust. The list of missing addresses has shrunken considerably: Andre (RFC 3036 and 5036) - need mail address Paul (RFC 3036 and 5036) - need mail address Yoshihiro Ohba (acknowledged for contributing text to 3036 and 5036) Bernard Suter (acknowledged for contributing text to 3036 and 5036) Any help appreciated. /Loa /Loa On 2014-01-01 07:26, Arun Viswanathan wrote: > > Likewise, not sure I need to respond to this being cited in the acknowled= gment section, nonetheless I grant my BCP 78 rights for RFC 3036 and 5036 t= o IETF trust. > Thx > .-arun > > > -----Original Message----- > From: Ross Callon > Sent: Tuesday, December 31, 2013 11:57 AM > To: Loa Andersson > Cc: mpls-chairs@tools.ietf.org; Eric Osborne (eosborne);=20 > vishwas.manral@hp.com; Rajiv Papneja;=20 > draft-ietf-mpls-ldp-ipv6@tools.ietf.org; Ina Minei; Eric Gray; Eric=20 > Rosen; Yakov Rekhter; mpls@ietf.org; Arun Viswanathan; Ina Minei > Subject: RE: bcp 78 rights for RFC 3036 and 5036 +=20 > draft-ietf-mpls-ldp-ipv6 > > I am not sure whether or not I need to reply as a person acknowledged in = 3036 and 5036, but I am happy to grant my BCP 78 rights for RFC 3036 and 50= 36 to the IETF trust. > > Thanks, Ross > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Monday, December 30, 2013 2:39 AM > To: vishwas.manral@hp.com; Rajiv Papneja;=20 > draft-ietf-mpls-ldp-ipv6@tools.ietf.org; Ina Minei; Loa Andersson;=20 > Ross Callon; Eric Gray; Eric Rosen; Yakov Rekhter; mpls@ietf.org; Arun=20 > Viswanathan > Cc: mpls-chairs@tools.ietf.org; Eric Osborne (eosborne) > Subject: bcp 78 rights for RFC 3036 and 5036 +=20 > draft-ietf-mpls-ldp-ipv6 > > Working Group, > > This is informative and a request for you to see if you have mail address= es for the folks I've listed below and that I miss the current mail address= es for. > > Folks (authors contributors), > > (some of you will get this - a bit expanded - mail for a second time). > > > We might have a copyright issue with draft-ietf-mpls-ldp-ipv6. The curren= t boiler-plate text says: > > > This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. > Without obtaining an adequate license from the person(s) controlling > the copyright in such materials, this document may not be modified > outside the IETF Standards Process, and derivative works of it may > not be created outside the IETF Standards Process, except to format > it for publication as an RFC or to translate it into languages other > than English. > > We normally want to remove the "BCP 78 pre November 10 2008 boiler plate"= and use the new one. For us to do so each and every coauthor of documents = that draft-ietf-mpls-ldp-ipv6 relies on and people that have contributed te= xt to any of these documents needs to grant their BCP 78 rights to the IETF= trust. > > Note: You are not *required* to grant these rights, it is only that it si= mply the standardization process. > > Please, if you are on the list below, let me know if you are willing to a= ssign your BCP 78 copyrights to the IETF trust, and I will check what proce= ss we need to follow. > > According to my tentative analysis this is the the people and document=20 > concerned; > > > Vishwas (draft-ietf-mpls-ldp-ipv6) > Rajiv P (draft-ietf-mpls-ldp-ipv6) > > Ina (RFC5036) > Bob (RFC 3036 and 5036) - need mail address > myself (RFC 3036 and 5036) - OK to grant BCP 78 rights to IETF trust > > Andre (RFC 3036 and 5036) - need mail address > Nancy (RFC 3036 and 5036) - need mail address > Paul (RFC 3036 and 5036) - need mail address > > Rick Boivie (acknowledged for contributing text to 3036 and 5036) > need mail address > Ross Callon (acknowledged for contributing text to 3036 and 5036) > Alex Conta (acknowledged for contributing text to 3036 and 5036) > need mail address > Eric Gray (acknowledged for contributing text to 3036 and 5036) > Yoshihiro Ohba (acknowledged for contributing text to 3036 and 5036) > Eric Rosen (acknowledged for contributing text to 3036 and 5036) > need mail address > Bernard Suter (acknowledged for contributing text to 3036 and 5036) > Yakov Rekhter (acknowledged for contributing text to 3036 and 5036) > Arun Viswanathan (acknowledged for contributing text to 3036 and 5036) > need mail address (I have a Junper address but is not > sure that it is current) > > > It turns out that my address register is even worse than I thought. > Of the people above I miss quite a few of these addresses. If you a curre= nt mail address to anyone of the that I miss it for, please send that to me= unidirectional. > > I'm sending this to > - the draft authors > - Eric O (to check the mpls list if anyone of the missing are on > the list) > - my co-chairs to see if they have better track on things than I have > - I've also sent a few more unidirectional mails to see if people may > know > - people acknowledged for contributing text to 3036 and 5036 > > /Loa > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From vishwas.manral@hp.com Mon Dec 30 12:54:16 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2C1AE272 for ; Mon, 30 Dec 2013 12:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.438 X-Spam-Level: X-Spam-Status: No, score=-7.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538] 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 80JytixGdc2N for ; Mon, 30 Dec 2013 12:54:14 -0800 (PST) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id 1337E1AE18E for ; Mon, 30 Dec 2013 12:54:13 -0800 (PST) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id 3DC2C2C00F; Mon, 30 Dec 2013 20:54:07 +0000 (UTC) Received: from G5W5498.americas.hpqcorp.net (16.201.144.178) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 30 Dec 2013 20:53:16 +0000 Received: from G5W2732.americas.hpqcorp.net ([169.254.4.222]) by G5W5498.americas.hpqcorp.net ([16.201.144.178]) with mapi id 14.03.0123.003; Mon, 30 Dec 2013 20:53:16 +0000 From: "Manral, Vishwas" To: Loa Andersson , Rajiv Papneja , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" , Ina Minei , Ross Callon , Eric Gray , "Eric Rosen" , Yakov Rekhter , "mpls@ietf.org" , 'Arun Viswanathan' Thread-Topic: bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 Thread-Index: AQHPBTItwIM6OLfLC0euHOqu3o/TL5ptN70A Date: Mon, 30 Dec 2013 20:53:15 +0000 Message-ID: <5A9E892C56FD5842856290BDA06E12A00B8A5B4C@G5W2732.americas.hpqcorp.net> References: <52C122FE.8090706@pi.nu> In-Reply-To: <52C122FE.8090706@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.193.49.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 02 Jan 2014 02:16:58 -0800 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 20:54:16 -0000 Hi Loa, I grant IETF the right for this draft. -Vishwas -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Sunday, December 29, 2013 11:39 PM To: Manral, Vishwas; Rajiv Papneja; draft-ietf-mpls-ldp-ipv6@tools.ietf.org= ; Ina Minei; Loa Andersson; Ross Callon; Eric Gray; Eric Rosen; Yakov Rekht= er; mpls@ietf.org; 'Arun Viswanathan' Cc: mpls-chairs@tools.ietf.org; Eric Osborne (eosborne) Subject: bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 Working Group, This is informative and a request for you to see if you have mail addresses= for the folks I've listed below and that I miss the current mail addresses= for. Folks (authors contributors), (some of you will get this - a bit expanded - mail for a second time). We might have a copyright issue with draft-ietf-mpls-ldp-ipv6. The current = boiler-plate text says: This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. We normally want to remove the "BCP 78 pre November 10 2008 boiler plate" a= nd use the new one. For us to do so each and every coauthor of documents th= at draft-ietf-mpls-ldp-ipv6 relies on and people that have contributed text= to any of these documents needs to grant their BCP 78 rights to the IETF t= rust. Note: You are not *required* to grant these rights, it is only that it simp= ly the standardization process. Please, if you are on the list below, let me know if you are willing to ass= ign your BCP 78 copyrights to the IETF trust, and I will check what process= we need to follow. According to my tentative analysis this is the the people and document conc= erned; Vishwas (draft-ietf-mpls-ldp-ipv6) Rajiv P (draft-ietf-mpls-ldp-ipv6) Ina (RFC5036) Bob (RFC 3036 and 5036) - need mail address myself (RFC 3036 and 5036) - OK to grant BCP 78 rights to IETF trust Andre (RFC 3036 and 5036) - need mail address Nancy (RFC 3036 and 5036) - need mail address Paul (RFC 3036 and 5036) - need mail address Rick Boivie (acknowledged for contributing text to 3036 and 5036) need mail address Ross Callon (acknowledged for contributing text to 3036 and 5036) Alex Conta (acknowledged for contributing text to 3036 and 5036) need mail address Eric Gray (acknowledged for contributing text to 3036 and 5036) Yoshihiro Ohba (acknowledged for contributing text to 3036 and 5036) Eric Rosen (acknowledged for contributing text to 3036 and 5036) need mail address Bernard Suter (acknowledged for contributing text to 3036 and 5036) Yakov Rekhter (acknowledged for contributing text to 3036 and 5036) Arun Viswanathan (acknowledged for contributing text to 3036 and 5036) need mail address (I have a Junper address but is not sure that it is current) It turns out that my address register is even worse than I thought. Of the people above I miss quite a few of these addresses. If you a current= mail address to anyone of the that I miss it for, please send that to me u= nidirectional. I'm sending this to - the draft authors - Eric O (to check the mpls list if anyone of the missing are on the list) - my co-chairs to see if they have better track on things than I have - I've also sent a few more unidirectional mails to see if people may know - people acknowledged for contributing text to 3036 and 5036 /Loa --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Thu Jan 2 02:24:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2F91AE4E6 for ; Thu, 2 Jan 2014 02:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 5r0o1QVUyoqT for ; Thu, 2 Jan 2014 02:24:32 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 059551AC4A3 for ; Thu, 2 Jan 2014 02:24:32 -0800 (PST) Received: from [192.168.1.5] (unknown [112.208.5.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 74F411800740; Thu, 2 Jan 2014 11:24:22 +0100 (CET) Message-ID: <52C53E51.9060307@pi.nu> Date: Thu, 02 Jan 2014 18:24:17 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Ryoo, Jeong-dong" , Yaacov Weingarten References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info>, <52BBD59D.8000104@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEFF9@SMTP2.etri.info>, <52BFF3AB.3070609@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AF703@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AF703@SMTP2.etri.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 10:24:36 -0000 Jeong-dong, I could try, but that would be a novice stumbling around. I'd like Yaaco and Huub to take at spin at this first, I believe that they have a better chance to zoom in on what is crucial from the beginning. /Loa On 2014-01-02 09:39, Ryoo, Jeong-dong wrote: > Loa, thanks for the email. > I got the point now. > As you mentioned in the last part of your email, we'd better find the text. > Do you have any text to propose? > Best regards, > Jeong-dong > > > ------------------------------------------------------------------------ > *From : *"Loa Andersson" > *Sent : *2013-12-29 19:04:38 ( +09:00 ) > *To : *Ryoo, Jeong-dong , Yaacov Weingarten > > *Cc : *mpls@ietf.org , > draft-ietf-mpls-tp-psc-itu@tools.ietf.org > > *Subject : *Re: [mpls] Question regarding SD protection in > draft-ietf-mpls-tp-psc-itu > > Jeong-dong, > > I got conflicting answers you and Huub. I don't immediately want to > change the text in the document, but rather understand if it needs to > be changed to give a context to resolve Yaacov's comments. > > The point I was trying to make was that you and Yaacov stand on two > different mountains (network layering models) and can't agree if you > see the sun set or not. You say you can, but Yaaco don't agree, since > the sun disappeared behind the mountain you are standing on more than > an hour ago. > > What I think happens is that you think about protection switching, > selector and bridge in the terms of the model you are used to. > > When Yaacov hear that he thinks about them the way he is used to use > them from his model. > > Neither model is "right or wrong" (both mountains are real) but the are > different. > > What I tried to say was that when Yaacov thinks about as physical > objects, while you seem to use them as a class name, performing the > same function for any layer, but also implemented differently on > each layer. > > I think this was what Huub agreed to, right? > > Yaacov step of this train here if you don't agree! > > So what I intended to to was to keep the class name (for every existing > bridge and selector, calling them just that) and zoom om on e.g. one > network layering instance of the class, talking about "mpls selector > function" and "mpls bridge function". > > Please note that I'm not suggesting names or terminology, just trying > to figure out it if this is the why you don't seem to agree. > > If we agree what the problem is then it is fairly easy to find the > text that needs to go into the document. > > /Loa > > On 2013-12-27 10:41, Ryoo, Jeong-dong wrote: > > Loa, > > I am not sure I understand your question correctly, but I would say that: > > Each layer has its own bridge and selector for protection switching, so > > that each layer can perform protection switching of its own. > > I am not sure what you mean by "bridge/selector function", but in ITU-T > > terminology, the bridge and selector are included in "connection > > function" of its own layer (for example, MT_C for MPLS-TP connection > > function, which includes the bridge and the selector for the MPLS-TP > > layer). > > For the PSC RFC, I don't think we need to introduce any new terminology > > such as the "bridge/selector function" or "connection function". > > The bridge/selector have already been introduced in the RFC6378 (MPLS-TP > > linear protection). > > Best regards, > > Jeong-dong > > > > ------------------------------------------------------------------------ > > *From : *"Loa Andersson" > > *Sent : *2013-12-26 16:07:15 ( +09:00 ) > > *To : *Ryoo, Jeong-dong , Yaacov Weingarten > > > > *Cc : *mpls@ietf.org , > > draft-ietf-mpls-tp-psc-itu@tools.ietf.org > > > > *Subject : *Re: [mpls] Question regarding SD protection in > > draft-ietf-mpls-tp-psc-itu > > > > Jeong-dong, > > > > Is this simply a matter of terminology. Each layer needs to perform its > > own protection switching, i.e. there has to be a *bridge funtion* and a > > *selector function* (on each layer depending on the implementation); > > while *bridge* and *selector* are the physical layer entities? > > > > /Loa > > > > On 2013-12-26 12:51, Ryoo, Jeong-dong wrote: > > > Yaacov, thanks for your email. Somehow, I forgot to respond and am > sorry > > > for the delay. > > > > > > First of all, Yaacov, it is not true that the protection switching of > > > Ethernet or SDH describes the operation of any layer below. Rather, > each > > > layer is supposed to operate independently. However, there are a few > > > exceptions, such as hold-off timer and AIS (as a trigger from lower > > > layer). Even though there exist some proprietary implementations that > > > use other information from lower layer, most of them are not > recommended > > > in ITU-T standards. > > > > > > Bridge and selector are not in the physical layer, but they are part of > > > protection switching. One of the important output actions from the PSC > > > control logic is coordinating the positions of bridge and selector. > > > Also, the bridge operation responding to the PSC control logic is also > > > part of protection switching. However, how to realize the bridge and > > > selector (for example, how to manipulate a packet forwarding mechanism) > > > is an implementation matter. > > > > > > When we mention 1+1 or 1:1 in protection architecture, we deal with the > > > operation of bridge. For 1+1 architecture, the traffic needs to be > > > duplicated at the sender and sent to both paths all the time, which is > > > the same description as the “permanent bridgeâ€. For 1:1 architecture, > > > “selector bridge†is used to send the traffic only one of the paths. As > > > the protection path can be used by best traffic in packet networks and > > > the packet duplication takes much more effort/internal bandwidth inside > > > a switch than the time slot copy of circuit networks. 1:1 is considered > > > as preferable architecture in packet networks. > > > > > > As you might recall from G.8031 – Ethernet linear protection, the > > > selector bridge is not recommended due to the traffic flapping under SD > > > conditions on both paths. Instead “broadcast bridge†is introduced to > > > support protection switching against SD. But, this broadcast bridge is > > > not recommended in non-revertive mode as the working path needs to be > > > occupied by traffic all the time. Also the broadcast bridge is not > > > efficient, since by definition, the packet duplication should occur > > > during not only SD but also SF, FS, MS, etc. In this document, we are > > > introducing an improved bridge mechanism, which behaves like a selector > > > bridge but duplicates the traffic only under SD condition, and we > > > believe that it addresses all the issues with existing bridges. > > > > > > What we mean by SD protection is agnostic to the SD detection method is > > > that the proposed SD protection method (again how to operate a > bridge or > > > what brige is used is a part of protection switching) can be used no > > > matter what kind of SD detection methods (data packet counting, CCM > > > packet counting, or even proprietary server layer SD detection) is > used. > > > > > > I think I answered all the questions on your email. > > > > > > Yaacov, if you have any further concerns or questions, please let me > > know. > > > > > > Best regards, > > > > > > Jeong-dong > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > *From : *"Yaacov Weingarten" > > > *Sent : *2013-12-10 16:04:17 ( +09:00 ) > > > *To : *Ryoo, Jeong-dong > > > *Cc : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org > > > , mpls@ietf.org > > > *Subject : *Re: Question regarding SD protection in > > > draft-ietf-mpls-tp-psc-itu > > > > > > Jeong-dong, hi > > > > > > Thank you for your reply. Your answer seems to be an appropriate answer > > > for other SDOs, not sure that it is true for the context of MPLS and > > > IETF work. > > > > > > 1. You wrote "any protection switching (including PSC) is supposed to > > > describe the operation of bridge and selector." - this may be true for > > > Ethernet andSDH and for documents that are describing the operation of > > > the physical layer. However, the IETF (to my understanding - and I am > > > certainly willing to be corrected on this point) is concerned with the > > > protocol and leave the lower layers to implementation. Also, I am not > > > sure that the concepts of Bridge and Selector really apply to MPLS > > > (although I admit that we did mention them in the original PSC > > definition). > > > > > > 2. You cite what was written in G8031 as justification for including > > > content into your draft. Again it is hard to transfer methodology from > > > one SDO to another and therefore, while I highly respect the work > of the > > > ITU, I do not feel that this is a very clear justification for > inclusion > > > into an internet-draft. Even when the draft states that its purpose is > > > to address the concerns of the ITU. > > > > > > 3. To the actual point of my earlier comment, that you do not seem to > > > address - the paragraph in Section 7.3 seems to state that SD > protection > > > changes according to the method that is used to detect the SD. This > > > means that SD protection is not agnostic to the method used for the > > > detection. > > > Alternatively, we could break this dependence and state that SD > > > protection is always provided by changing the transmission of the data > > > to 1+1 protection in cases of SD detection, which is what the paragraph > > > is suggesting to do for some cases. > > > > > > I hope this formulation make my comment clearer and we are able to > > > discuss the technological approach rather than the philosophical > > > differences. > > > > > > Thank you, > > > yaacov > > > > > > > > > On Mon, Dec 9, 2013 at 10:04 PM, Ryoo, Jeong-dong > > wrote: > > > > > > Yaacov, > > > > > > Yes, PSC is supposed to be agnostic to the method used for the > > > detection of SF/SD. > > > > > > It is also true that any protection switching (including PSC) is > > > supposed to describe the operation of bridge and selector. > > > > > > As there are multiple options for detecting SD, we needed to > > > describe the behavior of the bridge to cover all the possible > > > detection methods. Describing the operation of bridge for SD > > > protection is not a new thing. For example, G.8031 - Ethernet linear > > > protection also describes what bridge can be used in order to > > > provide protection against SD. > > > > > > Best regards, > > > > > > Jeong-dong > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > *From : *"Yaacov Weingarten" > > > > > *Sent : *2013-12-08 20:01:55 ( +09:00 ) > > > *To : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org > > > > > > > >, mpls@ietf.org > > > > > > > *Cc : * > > > *Subject : *Question regarding SD protection in > > > draft-ietf-mpls-tp-psc-itu > > > > > > > > > Hi, > > > > > > After reading through your draft on the extensions to PSC to support > > > SD situations, I have a question for clarification - > > > In your introduction - you state that the method used to detect SD > > > situations is out-of-scope of the document. Does this mean that PSC > > > is supposed to be agnostic to the method used for this detection? It > > > should react only to the indication, similarly to the reaction and > > > relationship to the method for detecting and declaring a SF situation. > > > However, when you explain the behavior of the SD protection in > > > section 7.3 you have a paragraph that starts with "If the detection > > > of a SD depends on the presence of user data packets ..." that > > > seems to indicate that the behavior of the system is dependent upon > > > the detection method! Clarification would be appreciated. > > > > > > -- > > > Thanx and BR, > > > yaacov > > > > > > /Still looking for new opportunity/ > > > > > > > > > > > > > > > -- > > > Thanx and BR, > > > yaacov > > > > > > /Still looking for new opportunity/ > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From iesg-secretary@ietf.org Thu Jan 2 07:12:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39041AE390; Thu, 2 Jan 2014 07:12:56 -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 YjCj0OEL3d-9; Thu, 2 Jan 2014 07:12:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0766D1AE0C4; Thu, 2 Jan 2014 07:12:55 -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: 4.90 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140102151254.15460.43199.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 07:12:54 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Use of Multipath with MPLS and MPLS-TP) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 15:12:57 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Use of Multipath with MPLS and MPLS-TP' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-01-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy label, MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-multipath-use/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-multipath-use/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1593/ From iesg-secretary@ietf.org Thu Jan 2 07:14:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F301AE591; Thu, 2 Jan 2014 07:14:21 -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 rZSoX7qQz_48; Thu, 2 Jan 2014 07:14:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 612481AE397; Thu, 2 Jan 2014 07:14:19 -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: 4.90 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 07:14:19 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 15:14:21 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Encapsulating MPLS in UDP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-01-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1941/ http://datatracker.ietf.org/ipr/2198/ From iesg-secretary@ietf.org Thu Jan 2 07:16:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48521AE4B9; Thu, 2 Jan 2014 07:16:07 -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 qqM0KzCIeypq; Thu, 2 Jan 2014 07:16:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC871ADEA3; Thu, 2 Jan 2014 07:16:06 -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: 4.90 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140102151605.2998.36196.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 07:16:05 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 15:16:08 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-01-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh) Parameters" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This document updates RFC 5586. This document also updates RFC 6374, RFC 6428, RFC 6378, RFC 6427, RFC-ietf-mpls-gach-adv, and RFC-ietf-mpls-tp-ethernet-addressing. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-moving-iana-registries/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-moving-iana-registries/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Jan 2 07:17:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7D71AE5B8; Thu, 2 Jan 2014 07:17:21 -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 Y54HiOT6d0Km; Thu, 2 Jan 2014 07:17:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D90DF1ADEA3; Thu, 2 Jan 2014 07:17:19 -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: 4.90 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140102151719.16281.26554.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 07:17:19 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (A Framework for Point-to-Multipoint MPLS in Transport Networks) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 15:17:21 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Framework for Point-to-Multipoint MPLS in Transport Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-01-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Multiprotocol Label Switching Transport Profile is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture applicable specifically to supporting point-to- multipoint transport paths. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-p2mp-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-p2mp-framework/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Jan 2 09:31:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99631AE111; Thu, 2 Jan 2014 09:31: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] 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 BirMyyx8oTlT; Thu, 2 Jan 2014 09:31:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 355821AE3B5; Thu, 2 Jan 2014 09:31:23 -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: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140102173123.11831.92084.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 09:31:23 -0800 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'LDP Extensions for Hub & Spoke Multipoint Label Switched Path' to Proposed Standard (draft-ietf-mpls-mldp-hsmp-06.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 17:31:28 -0000 The IESG has approved the following document: - 'LDP Extensions for Hub & Spoke Multipoint Label Switched Path' (draft-ietf-mpls-mldp-hsmp-06.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-hsmp/ Technical Summary This draft introduces a hub & spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic both from root to leaf through point-to-multipoint (P2MP) LSP and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from application/customer at the root node travels downstream to each leaf node, exactly as if it is travelling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it is unicast to the root. The communication among the leaf nodes are not allowed. Working Group Summary There were nothing remarkable in the WG process, All decision were taken after converged discussions. Document Quality The working group chairs has sent an implementation poll to the working group mailing list. For the time being we are aware of implementations and intentions to implement. The document has been reviewed in the normal WG process including review from the MPLS Review Team and from the AD. All comments have been fairly easily resolved. Personnel Shepherd: Loa Andersson Responsible AD: Adrian Farrel From Rajiv.Papneja@huawei.com Thu Jan 2 11:00:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704951AC829 for ; Thu, 2 Jan 2014 11:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 09hk0_61JVJY for ; Thu, 2 Jan 2014 11:00:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4F61AC403 for ; Thu, 2 Jan 2014 11:00:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZO69034; Thu, 02 Jan 2014 19:00:18 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 2 Jan 2014 19:00:08 +0000 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, 2 Jan 2014 19:00:17 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Thu, 2 Jan 2014 11:00:10 -0800 From: Rajiv Papneja To: Loa Andersson , "vishwas.manral@hp.com" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" , Ina Minei , "Ross Callon" , Eric Gray , "Eric Rosen" , Yakov Rekhter , "mpls@ietf.org" , "'Arun Viswanathan'" Thread-Topic: bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 Thread-Index: AQHPBTIvNF2zONhZ3UW9G0+3GKeuyZpxzZQQ Date: Thu, 2 Jan 2014 19:00:09 +0000 Message-ID: <52B0D42F4BADB144B850705C4549F6EA213ADCB6@dfweml701-chm.china.huawei.com> References: <52C122FE.8090706@pi.nu> In-Reply-To: <52C122FE.8090706@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 19:00:31 -0000 Hello Loa, I have been out of office, hence the delay in responding to your request.=20 I grant my BCP 78 copyrights for this draft to the IETF trust Thanks and a very Happy New Year! /Rajiv -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Monday, December 30, 2013 2:39 AM To: vishwas.manral@hp.com; Rajiv Papneja; draft-ietf-mpls-ldp-ipv6@tools.ie= tf.org; Ina Minei; Loa Andersson; Ross Callon; Eric Gray; Eric Rosen; Yakov= Rekhter; mpls@ietf.org; 'Arun Viswanathan' Cc: mpls-chairs@tools.ietf.org; Eric Osborne (eosborne) Subject: bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 Working Group, This is informative and a request for you to see if you have mail addresses for the folks I've listed below and that I miss the current mail addresses for. Folks (authors contributors), (some of you will get this - a bit expanded - mail for a second time). We might have a copyright issue with draft-ietf-mpls-ldp-ipv6. The current boiler-plate text says: This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. We normally want to remove the "BCP 78 pre November 10 2008 boiler plate" and use the new one. For us to do so each and every coauthor of documents that draft-ietf-mpls-ldp-ipv6 relies on and people that have contributed text to any of these documents needs to grant their BCP 78 rights to the IETF trust. Note: You are not *required* to grant these rights, it is only that it simply the standardization process. Please, if you are on the list below, let me know if you are willing to assign your BCP 78 copyrights to the IETF trust, and I will check what process we need to follow. According to my tentative analysis this is the the people and document concerned; Vishwas (draft-ietf-mpls-ldp-ipv6) Rajiv P (draft-ietf-mpls-ldp-ipv6) Ina (RFC5036) Bob (RFC 3036 and 5036) - need mail address myself (RFC 3036 and 5036) - OK to grant BCP 78 rights to IETF trust Andre (RFC 3036 and 5036) - need mail address Nancy (RFC 3036 and 5036) - need mail address Paul (RFC 3036 and 5036) - need mail address Rick Boivie (acknowledged for contributing text to 3036 and 5036) need mail address Ross Callon (acknowledged for contributing text to 3036 and 5036) Alex Conta (acknowledged for contributing text to 3036 and 5036) need mail address Eric Gray (acknowledged for contributing text to 3036 and 5036) Yoshihiro Ohba (acknowledged for contributing text to 3036 and 5036) Eric Rosen (acknowledged for contributing text to 3036 and 5036) need mail address Bernard Suter (acknowledged for contributing text to 3036 and 5036) Yakov Rekhter (acknowledged for contributing text to 3036 and 5036) Arun Viswanathan (acknowledged for contributing text to 3036 and 5036) need mail address (I have a Junper address but is not sure that it is current) It turns out that my address register is even worse than I thought. Of the people above I miss quite a few of these addresses. If you a current mail address to anyone of the that I miss it for, please send that to me unidirectional. I'm sending this to - the draft authors - Eric O (to check the mpls list if anyone of the missing are on the list) - my co-chairs to see if they have better track on things than I have - I've also sent a few more unidirectional mails to see if people may know - people acknowledged for contributing text to 3036 and 5036 /Loa --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Thu Jan 2 16:40:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9BE1AC403; Thu, 2 Jan 2014 16:40: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 SUTDoxasktUf; Thu, 2 Jan 2014 16:40:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B06B1A1F62; Thu, 2 Jan 2014 16:40:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140103004018.12023.42682.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 16:40:18 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-proxy-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 00:40:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Proxy MPLS Echo Request Authors : George Swallow Vanson Lim Sam Aldrin Filename : draft-ietf-mpls-proxy-lsp-ping-01.txt Pages : 24 Date : 2014-01-02 Abstract: This document defines a means of remotely initiating Multiprotocol Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to leaf/ root tracing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-proxy-lsp-ping-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-proxy-lsp-ping-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aldrin.ietf@gmail.com Fri Jan 3 05:09:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29B71ADFA4 for ; Fri, 3 Jan 2014 05:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYnkCKmcgRdu for ; Fri, 3 Jan 2014 05:09:31 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 90CE71ADF87 for ; Fri, 3 Jan 2014 05:09:31 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rp16so15654322pbb.4 for ; Fri, 03 Jan 2014 05:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:subject:references:from :mime-version:in-reply-to:message-id:date:cc:to; bh=8L0Ri9Y0vvOBS1qUk6+ELis1cx7AYOyL4KzEM/dMGKk=; b=lZSL0T+ZnaezxIKYVZyb8p9qkJRnfUqp/tttMfmaSKEBMS2gPZxaIVTjb4ZCBIc9pU vbc5jFDieUX5WHQM3k9o2S4UWHRLerRApISp5X0h69kk3OhIc5XtGENckiiY/A3RMsH5 ANIVQgjc+KhYXIXWFNRD/rE6Zdzg7smfieWiSrWo6xr3F+CNA5qsutUNmnUJKfJs433f H+K6zwWF/E60jxz9byTAz0pP7MGEv67cvPa78S1gLg1TtDdBM/PlR9tAJo1Bi+rp55vt R3GsqCdujnwLYIE1au3/P5WPaawMdIp2NXb7NvFEoe12bfaW1hoExQ7PDb9IyW06FtGe FT0g== X-Received: by 10.69.31.1 with SMTP id ki1mr94567645pbd.124.1388754564282; Fri, 03 Jan 2014 05:09:24 -0800 (PST) Received: from [10.0.2.2] ([106.220.74.9]) by mx.google.com with ESMTPSA id om6sm108799995pbc.43.2014.01.03.05.08.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jan 2014 05:09:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <52A71923.8090701@pi.nu> <52BFB141.9000502@pi.nu> From: Sam Aldrin Mime-Version: 1.0 (1.0) In-Reply-To: <52BFB141.9000502@pi.nu> Message-Id: <75603645-5DC8-4687-A38B-FC408B862DFC@gmail.com> Date: Fri, 3 Jan 2014 17:34:45 +0530 To: Loa Andersson X-Mailer: iPhone Mail (11B554a) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-smp-requirements@tools.ietf.org" Subject: Re: [mpls] wglc on draft-ietf-mpls-smp-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 13:09:34 -0000 Loa et al, Will address comments received, soon. Sam Sent from my iPhone > On Dec 29, 2013, at 10:51 AM, Loa Andersson wrote: > > Working Group, > > This working group last call is closed! > > We have had some comments, could the authors please address these > and post a new version of the draft as necessary. > > /Loa > for the wg chairs > >> On 2013-12-10 21:37, Loa Andersson wrote: >> Working Group, >> >> >> this is to start a 2 week working group last call on >> draft-ietf-mpls-smp-requirements-02. >> >> Please review the document and send comments to the MPLS WG >> mailing list (mpls@ietf.org) . >> >> There are no IPR claims against this document. >> >> All the authors have stated on the MPLS wg mailing list that they >> are unaware of any IPRs that relate to this document. >> >> The working group last call ends Monday December 27 - 2013. >> >> Yes - that is is in the middle of the Holiday season, but at least >> one wg chair will be working partly between Xmas and New Year and be >> able to evaluate next steps. We count on most reviews taking place >> in the almost two weeks before Xmas. >> >> /Loa > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From tsaad@cisco.com Fri Jan 3 08:44:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187AC1ADFD4 for ; Fri, 3 Jan 2014 08:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.638 X-Spam-Level: X-Spam-Status: No, score=-13.638 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 WBP3TASCj7sR for ; Fri, 3 Jan 2014 08:44:42 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 18BEF1ADEBF for ; Fri, 3 Jan 2014 08:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21474; q=dns/txt; s=iport; t=1388767475; x=1389977075; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Z0i/I3NW/+Zo79MdZxC+RJTcH4XFDcrtzV0oLbQfANk=; b=Jwq57T6Wm3Dbt0V5Ha5K48xI0MBk8M2Tl4AaSIe59HRLAJHbhaEAG8IK /t7MsE33wCIO2YFPy/JnsYz99RO/f0UUVi5rPndFgwg9yC1wPOYWe0V2e qEeNsImXbPWHWA3PfvVGTKmk9rr9hBhuljmHEM/xgAIOM6OEOy9OxTfaR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAE3oxlKtJXHB/2dsb2JhbABYgkdEOFW5CoENFnSCJQEBAQQtXAIBCBEDAQEBKAcyFAkIAgQBEogEwywXjiNaFwGENwSYF5IUgy2CKg X-IronPort-AV: E=Sophos;i="4.95,598,1384300800"; d="scan'208,217";a="295108313" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 03 Jan 2014 16:44:34 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s03GiYgY030069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jan 2014 16:44:34 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 3 Jan 2014 10:44:33 -0600 From: "Tarek Saad (tsaad)" To: Huaimo Chen , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHO9zz2D8OUboE/BU63IW10jjHvHppWOpUAgACbxPCAHJIbgA== Date: Fri, 3 Jan 2014 16:44:31 +0000 Message-ID: References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C20383@sjceml501-mbs.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C20383@sjceml501-mbs.china.huawei.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-originating-ip: [10.86.242.144] Content-Type: multipart/alternative; boundary="_000_CEEC48369C0C5tsaadciscocom_" MIME-Version: 1.0 Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 16:44:45 -0000 --_000_CEEC48369C0C5tsaadciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Huaimo, Thanks. See inline below. 2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not = need any downstream label=85" i. What if the LSP is carrying non-IP traffic? Ii. There are cases where non-NULL label is needed at the egress=97 e.g., f= or collecting rx stats, for doing RPF check, etc.-- hence above statement i= s not necessarily true Huaimo: This ("For a primary LSP carrying IP packets, the PLR does not nee= d any downstream label=85") may be changed to something like: =93For a pri= mary LSP, if the PLR (the upstream node of the primary egress of the LSP) d= oes the PHP for the LSP, it redirects the traffic from the primary LSP int= o the backup LSP to the backup egress when it detects the failure of the pr= imary egress; otherwise, it redirects the packets from the primary LSP into= the backup LSP to backup egress using the primary LSP label from the prima= ry egress as an inner label. (At the backup egress, it uses the backup LSP = label as a context label to find the LFIB for the primary egress and uses t= he inner label under the context to handle the packets such as collecting r= x stats and forwarding the packets, which are similar to the behaviors at t= he primary egress.)=94 What are your suggestions and comments on this? [TS]: yes, using the primary egress label as inner label after rerouting (l= ocal repair) over the facility bypass may work. However, additional mechani= cs will be required to synchronize the label assignment between the primary= and backup egress nodes. Also, will necessitate backup egress node to supp= ort upstream assigned labels, and facility bypass must be UHP to provide co= ntext for the upstream label. Regards, Tarek From: Huaimo Chen > Date: Monday, 16 December, 2013 10:55 PM To: Tarek Saad >, "mpls@ietf.org" > Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Tarek, Thank you very much for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Sunday, December 15, 2013 10:09 PM To: Huaimo Chen; mpls@ietf.org Cc: Raveendra Torvi Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Huaimo, Thanks for making the changes. I still have the following comments: 1. Section 3.1: it is not still clear why the ingress has to specify the ba= ckup path (in form of EB-SERO) from previous hop PLR to the backup egress n= ode Huaimo: The ingress does not have to specify the backup path (in form of EB= -SERO) from previous hop PLR to the backup egress node. We will revise the = draft accordingly. 2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not = need any downstream label=85" i. What if the LSP is carrying non-IP traffic? Ii. There are cases where non-NULL label is needed at the egress=97 e.g., f= or collecting rx stats, for doing RPF check, etc.-- hence above statement i= s not necessarily true Huaimo: This ("For a primary LSP carrying IP packets, the PLR does not nee= d any downstream label=85") may be changed to something like: =93For a pri= mary LSP, if the PLR (the upstream node of the primary egress of the LSP) d= oes the PHP for the LSP, it redirects the traffic from the primary LSP int= o the backup LSP to the backup egress when it detects the failure of the pr= imary egress; otherwise, it redirects the packets from the primary LSP into= the backup LSP to backup egress using the primary LSP label from the prima= ry egress as an inner label. (At the backup egress, it uses the backup LSP = label as a context label to find the LFIB for the primary egress and uses t= he inner label under the context to handle the packets such as collecting r= x stats and forwarding the packets, which are similar to the behaviors at t= he primary egress.)=94 What are your suggestions and comments on this? 3. Incidentally, "draft-minto-rsvp-lsp-egress-fast-protection-03" is also p= roposing a mechanism to achieve this protection using proxy/virtual egress = node - although little mention to P2MP. Have you considered if there's any = overlap there? Huaimo: This draft tries to provide the P2P TE LSP egress protection using = proxy/virtual egress node (proxy method). It needs extensions to the IGP (I= SIS and OSPF) in addition to extensions to RSVP-TE and has a number of limi= tations (The top of page 9 in the draft lists four limitations/caveats). Regards, Tarek From: Huaimo Chen > Date: Thursday, 12 December, 2013 8:20 AM To: "mpls@ietf.org" > Cc: Tarek Saad >, Raveendra Torvi <= rtorvi@juniper.net> Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection draft-chen-mpls-p2mp-egress-protection was reviewed by the MPLS Review team= prior to being polled for WG adoption. The authors have updated the draft = according to the comments. We have had responses from some of the reviewers= that they are comfortable with how the comments have been addressed. We wo= uld like to have the same response from the other two reviewers. Best Regards, Huaimo --_000_CEEC48369C0C5tsaadciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <187C1897CEE823408E2540327600C8E1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Huaimo,

Thanks. See inline below.

2. Section 3.2.2: "For a primary LSP carrying IP pac= kets, the PLR does not need any downstream label=85"=

    i. What if the LSP is carrying non-IP traff= ic?

Ii. There are cases where no= n-NULL label is needed at the egress=97 e.g., for collecting rx stats, for = doing RPF check, etc.-- hence above statement is not necessarily true

Huaimo:  This ("For a = primary LSP carrying IP packets, the PLR does not need any downstream label=85") may be c= hanged to something like:  =93For a primary LSP, if the PLR (the upstr= eam node of the primary egress of the LSP) does the PHP  for the LSP, it redirects the traffic from the primary LSP into the = backup LSP to the backup egress when it detects the failure of the primary = egress; otherwise, it redirects the packets from the primary LSP into the b= ackup LSP to backup egress using the primary LSP label from the primary egress as an inner label. (At the backu= p egress, it uses the backup LSP label as a context label to find the LFIB = for the primary egress and uses the inner label under the context to handle= the packets such as collecting rx stats and forwarding the packets, which are similar to the behaviors at= the primary egress.)=94 What are your suggestions and comments on this?

[TS]: yes, using the primary egress label as inner label after rerouti= ng (local repair) over the facility bypass may work. However, addition= al mechanics will be required to synchronize the label assignment between t= he primary and backup egress nodes. Also, will necessitate backup egress node to support upstream assigned labels, a= nd facility bypass must be UHP to provide context for the upstream label.

Regards,
Tarek

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Monday, 16 December, 2013 10:= 55 PM
To: Tarek Saad <tsaad@cisco.com>, "mpls@ietf.org" <mpls@i= etf.org>
Subject: RE: MPLS-RT review of draf= t-chen-mpls-p2mp-egress-protection

Hi Tarek,

 

Thank = you very much for your comments!

My ans= wers/explanations are inline below.

&= nbsp;

Best Regards,

Huaimo

From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com]
Sent: Sunday, December 15, 2013 10:09 PM
To: Huaimo Chen; mpls@ietf.org<= br> Cc: Raveendra Torvi
Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

Hi Huaimo,

 

Thanks for making the changes. I still have= the following comments:

1. Section 3.1: it is not still clear why t= he ingress has to specify the backup path (in form of EB-SERO) from previou= s hop PLR to the backup egress node

Huaimo: The ingress does not hav= e to specify the backup path (in form of EB-SERO) from previous hop PLR to = the backup egress node. We will revise the draft accordingly.

 

2. Section 3.2.2: "For a primary LSP c= arrying IP packets, the PLR does not need any downstream label=85"

    i. What if the LSP is carryin= g non-IP traffic?

Ii. There are c= ases where non-NULL label is needed at the egress=97 e.g., for collecting r= x stats, for doing RPF check, etc.-- hence above statement is not necessarily true

Huaimo:  This (= may be changed to something like:  =93For a primary LSP, if the PLR (t= he upstream node of the primary egress of the LSP) does the PHP  for the LSP, it redirects the traffic from the primary = LSP into the backup LSP to the backup egress when it detects the failure of= the primary egress; otherwise, it redirects the packets from the primary L= SP into the backup LSP to backup egress using the primary LSP label from the primary egress as an inner label. (At= the backup egress, it uses the backup LSP label as a context label to find= the LFIB for the primary egress and uses the inner label under the context= to handle the packets such as collecting rx stats and forwarding the packets, which are similar to the behaviors at= the primary egress.)=94 What are your suggestions and comments on this?

 

3. Incidentally, "draft-minto-rsvp-lsp= -egress-fast-protection-03" is also proposing a mechanism to achieve t= his protection using proxy/virtual egress node - although little mention to P2MP. Have you considered if there's any= overlap there?

Huaimo: This draft tries to provid= e the P2P TE LSP egress protection using proxy/virtual egress node (proxy m= ethod). It needs extensions to the IGP (ISIS and OSPF) in addition to extensions to RSVP-TE and has a number of l= imitations (The top of page 9 in the draft lists four limitations/caveats).=  

 

Regards,

Tarek

 

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Thursday, 12 December, 2013 8:20 AM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Cc: Tarek Saad <tsaad@cisco.co= m>, Raveendra Torvi <rtorvi= @juniper.net>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

draft-chen-mpls-p2mp-egr= ess-protection was reviewed by the MPLS Review team prior to being polled f= or WG adoption. The authors have updated the draft according to the comment= s. We have had responses from some of the reviewers that they are comfortable with how the comments have been ad= dressed. We would like to have the same response from the other two reviewe= rs.

 =

Best Regards,=

Huaimo=

--_000_CEEC48369C0C5tsaadciscocom_-- From rcallon@juniper.net Fri Jan 3 08:49:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA1E1AE00E for ; Fri, 3 Jan 2014 08:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KXiy-UtU4r_y for ; Fri, 3 Jan 2014 08:49:35 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id A74AB1AE00F for ; Fri, 3 Jan 2014 08:49:34 -0800 (PST) Received: from mail7-co9-R.bigfish.com (10.236.132.238) by CO9EHSOBE006.bigfish.com (10.236.130.69) with Microsoft SMTP Server id 14.1.225.22; Fri, 3 Jan 2014 16:49:27 +0000 Received: from mail7-co9 (localhost [127.0.0.1]) by mail7-co9-R.bigfish.com (Postfix) with ESMTP id 155AA120194; Fri, 3 Jan 2014 16:49:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail7-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(189002)(199002)(164054003)(74366001)(54356001)(76796001)(76576001)(76482001)(87266001)(83322001)(74662001)(83072002)(56776001)(81342001)(51856001)(56816005)(90146001)(76176001)(77982001)(31966008)(59766001)(74316001)(53806001)(74502001)(54316002)(74876001)(79102001)(2656002)(81686001)(66066001)(80976001)(85306002)(4396001)(76786001)(80022001)(85852003)(81542001)(49866001)(47976001)(47736001)(74706001)(47446002)(69226001)(81816001)(65816001)(46102001)(63696002)(87936001)(33646001)(50986001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.17; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail7-co9 (localhost.localdomain [127.0.0.1]) by mail7-co9 (MessageSwitch) id 1388767765743122_17443; Fri, 3 Jan 2014 16:49:25 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.247]) by mail7-co9.bigfish.com (Postfix) with ESMTP id A611E4C004C; Fri, 3 Jan 2014 16:49:25 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 3 Jan 2014 16:49:25 +0000 Received: from CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 3 Jan 2014 16:49:23 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) with Microsoft SMTP Server (TLS) id 15.0.842.7; Fri, 3 Jan 2014 16:49:21 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0842.003; Fri, 3 Jan 2014 16:49:20 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoA== Date: Fri, 3 Jan 2014 16:49:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.17] x-forefront-prvs: 00808B16F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 16:49:37 -0000 Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to=20 draft-chen-mpls-p2mp-ingress-protection? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The=20 documents will not advance to the next stage until a response has been received from each author and each contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) From yshen@juniper.net Fri Jan 3 09:53:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A00C1AE01F for ; Fri, 3 Jan 2014 09:53:56 -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 sB9lqHJsb516 for ; Fri, 3 Jan 2014 09:53:51 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id B64BF1ADFFC for ; Fri, 3 Jan 2014 09:53:51 -0800 (PST) Received: from mail126-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE029.bigfish.com (10.236.130.92) with Microsoft SMTP Server id 14.1.225.22; Fri, 3 Jan 2014 17:53:44 +0000 Received: from mail126-co9 (localhost [127.0.0.1]) by mail126-co9-R.bigfish.com (Postfix) with ESMTP id 3CA799000C1; Fri, 3 Jan 2014 17:53:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz9371Ic85fh148cIec9I11f6N4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail126-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=yshen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(52604005)(377454003)(164054003)(45984002)(189002)(199002)(37854004)(33646001)(76576001)(77982001)(87936001)(76786001)(19609705001)(81816001)(54316002)(59766001)(74662001)(2656002)(51856001)(47446002)(76796001)(18717965001)(63696002)(87266001)(74502001)(54356001)(53806001)(74366001)(80022001)(65816001)(4396001)(46102001)(69226001)(66066001)(85852003)(49866001)(19580395003)(74316001)(83072002)(56776001)(50986001)(81686001)(47736001)(47976001)(76482001)(19300405004)(15202345003)(56816005)(83322001)(81342001)(81542001)(80976001)(79102001)(15975445006)(90146001)(31966008)(19580405001)(74706001)(74876001)(85306002)(16236675002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB725; H:BY2PR05MB728.namprd05.prod.outlook.com; CLIP:66.129.241.18; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail126-co9 (localhost.localdomain [127.0.0.1]) by mail126-co9 (MessageSwitch) id 1388771621918034_10942; Fri, 3 Jan 2014 17:53:41 +0000 (UTC) Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.244]) by mail126-co9.bigfish.com (Postfix) with ESMTP id D0A40180049; Fri, 3 Jan 2014 17:53:41 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 3 Jan 2014 17:53:39 +0000 Received: from BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 3 Jan 2014 17:53:39 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.842.7; Fri, 3 Jan 2014 17:53:36 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0842.003; Fri, 3 Jan 2014 17:53:36 +0000 From: Yimin Shen To: "Tarek Saad (tsaad)" , Huaimo Chen , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHO9zz2D8OUboE/BU63IW10jjHvHppWOpUAgACbxPCAHJIbgP//80tQ Date: Fri, 3 Jan 2014 17:53:35 +0000 Message-ID: <769a7465342c40109412a7451aac873f@BY2PR05MB728.namprd05.prod.outlook.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C20383@sjceml501-mbs.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: [66.129.241.18] x-forefront-prvs: 00808B16F3 Content-Type: multipart/alternative; boundary="_000_769a7465342c40109412a7451aac873fBY2PR05MB728namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 17:53:56 -0000 --_000_769a7465342c40109412a7451aac873fBY2PR05MB728namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I concur with Tarek's comment on this. In fact, the following drafts have b= een proposed to provide egress protection for the inner labels (i.e. layer-= 2/3 VPN service labels). These drafts solve egress protection from a differ= ent angle, i.e. on a per-service basis, because ultimately it is the servic= e label that must be protected. As I've communicated with Huaimo, this is a= n important piece that is missing in his draft. Also, once service labels c= an be protected, there is no need for an RSVP (or LDP) extension for bypass= tunnel signaling. This is because upstream labels, UHP, context label swi= tching, etc have already been defined by MPLS WG, and hence the existing by= pass path computation and signaling mechanisms are already sufficient. http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-00 http://tools.ietf.org/search/draft-minto-2547-egress-node-fast-protection-0= 2 Thanks, /Yimin From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad) Sent: Friday, January 03, 2014 11:45 AM To: Huaimo Chen; mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi Huaimo, Thanks. See inline below. 2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not = need any downstream label..." i. What if the LSP is carrying non-IP traffic? Ii. There are cases where non-NULL label is needed at the egress- e.g., for= collecting rx stats, for doing RPF check, etc.-- hence above statement is = not necessarily true Huaimo: This ("For a primary LSP carrying IP packets, the PLR does not nee= d any downstream label...") may be changed to something like: "For a prima= ry LSP, if the PLR (the upstream node of the primary egress of the LSP) doe= s the PHP for the LSP, it redirects the traffic from the primary LSP into = the backup LSP to the backup egress when it detects the failure of the prim= ary egress; otherwise, it redirects the packets from the primary LSP into t= he backup LSP to backup egress using the primary LSP label from the primary= egress as an inner label. (At the backup egress, it uses the backup LSP la= bel as a context label to find the LFIB for the primary egress and uses the= inner label under the context to handle the packets such as collecting rx = stats and forwarding the packets, which are similar to the behaviors at the= primary egress.)" What are your suggestions and comments on this? [TS]: yes, using the primary egress label as inner label after rerouting (l= ocal repair) over the facility bypass may work. However, additional mechani= cs will be required to synchronize the label assignment between the primary= and backup egress nodes. Also, will necessitate backup egress node to supp= ort upstream assigned labels, and facility bypass must be UHP to provide co= ntext for the upstream label. Regards, Tarek From: Huaimo Chen > Date: Monday, 16 December, 2013 10:55 PM To: Tarek Saad >, "mpls@ietf.org" > Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Tarek, Thank you very much for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Sunday, December 15, 2013 10:09 PM To: Huaimo Chen; mpls@ietf.org Cc: Raveendra Torvi Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Huaimo, Thanks for making the changes. I still have the following comments: 1. Section 3.1: it is not still clear why the ingress has to specify the ba= ckup path (in form of EB-SERO) from previous hop PLR to the backup egress n= ode Huaimo: The ingress does not have to specify the backup path (in form of EB= -SERO) from previous hop PLR to the backup egress node. We will revise the = draft accordingly. 2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not = need any downstream label..." i. What if the LSP is carrying non-IP traffic? Ii. There are cases where non-NULL label is needed at the egress- e.g., for= collecting rx stats, for doing RPF check, etc.-- hence above statement is = not necessarily true Huaimo: This ("For a primary LSP carrying IP packets, the PLR does not nee= d any downstream label...") may be changed to something like: "For a prima= ry LSP, if the PLR (the upstream node of the primary egress of the LSP) doe= s the PHP for the LSP, it redirects the traffic from the primary LSP into = the backup LSP to the backup egress when it detects the failure of the prim= ary egress; otherwise, it redirects the packets from the primary LSP into t= he backup LSP to backup egress using the primary LSP label from the primary= egress as an inner label. (At the backup egress, it uses the backup LSP la= bel as a context label to find the LFIB for the primary egress and uses the= inner label under the context to handle the packets such as collecting rx = stats and forwarding the packets, which are similar to the behaviors at the= primary egress.)" What are your suggestions and comments on this? 3. Incidentally, "draft-minto-rsvp-lsp-egress-fast-protection-03" is also p= roposing a mechanism to achieve this protection using proxy/virtual egress = node - although little mention to P2MP. Have you considered if there's any = overlap there? Huaimo: This draft tries to provide the P2P TE LSP egress protection using = proxy/virtual egress node (proxy method). It needs extensions to the IGP (I= SIS and OSPF) in addition to extensions to RSVP-TE and has a number of limi= tations (The top of page 9 in the draft lists four limitations/caveats). Regards, Tarek From: Huaimo Chen > Date: Thursday, 12 December, 2013 8:20 AM To: "mpls@ietf.org" > Cc: Tarek Saad >, Raveendra Torvi <= rtorvi@juniper.net> Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection draft-chen-mpls-p2mp-egress-protection was reviewed by the MPLS Review team= prior to being polled for WG adoption. The authors have updated the draft = according to the comments. We have had responses from some of the reviewers= that they are comfortable with how the comments have been addressed. We wo= uld like to have the same response from the other two reviewers. Best Regards, Huaimo --_000_769a7465342c40109412a7451aac873fBY2PR05MB728namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I concur with Tarek’= ;s comment on this. In fact, the following drafts have been proposed to pro= vide egress protection for the inner labels (i.e. layer-2/3 VPN service labels). These drafts solve egress protection from a different ang= le, i.e. on a per-service basis, because ultimately it is the service label= that must be protected. As I’ve communicated with Huaimo, this is an= important piece that is missing in his draft. Also, once service labels can be protected, there is no need for an= RSVP (or LDP) extension for bypass tunnel signaling. This is  because= upstream labels, UHP, context label switching, etc have already been defin= ed by MPLS WG, and hence the existing bypass path computation and signaling mechanisms are already sufficient. <= o:p>

 <= /p>

http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-p= rotection-00

http://tools.ietf.org/search/draft-minto-2547-egress= -node-fast-protection-02

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad)
Sent: Friday, January 03, 2014 11:45 AM
To: Huaimo Chen; mpls@ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi Huaimo,

 

Thanks. See inline below.

 

2. Section 3.2.2: "For a primary LSP= carrying IP packets, the PLR does not need any downstream label…&quo= t;

    i. What if the LSP is carry= ing non-IP traffic?

Ii. There are cases where non-NULL label is needed= at the egress— e.g., for collecting rx stats, for doing RPF check, e= tc.-- hence above statement is not necessarily true

Huaimo:  This ("For a primary LSP carrying IP packets, the PLR does not need any downstream la= bel…") may be changed to = something like:  “For a primary LSP, if the PLR (the upstream no= de of the primary egress of the LSP) does the PHP  for the LSP, it redirect= s the traffic from the primary LSP into the backup LSP to the backup egress= when it detects the failure of the primary egress; otherwise, it redirects= the packets from the primary LSP into the backup LSP to backup egress using the primary LSP label from the prima= ry egress as an inner label. (At the backup egress, it uses the backup LSP = label as a context label to find the LFIB for the primary egress and uses t= he inner label under the context to handle the packets such as collecting rx stats and forwarding the packe= ts, which are similar to the behaviors at the primary egress.)” What = are your suggestions and comments on this?

[TS]: yes, using the primar= y egress label as inner label after rerouting (local repair) over the = facility bypass may work. However, additional mechanics will be required to synchronize the label assignment between the primary and ba= ckup egress nodes. Also, will necessitate backup egress node to support ups= tream assigned labels, and facility bypass must be UHP to provide context f= or the upstream label.

 

Regards,<= /p>

Tarek

 

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Monday, 16 December, 2013 10:55 PM
To: Tarek Saad <tsaad@cisco.co= m>, "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

Hi Tarek,

 

Thank you very much for your comments!

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: Tarek Saad (tsaad) [mail= to:tsaad@cisco.com]
Sent: Sunday, December 15, 2013 10:09 PM
To: Huaimo Chen; mpls@ietf.org<= br> Cc: Raveendra Torvi
Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 =

Hi Huaimo,

 

Thanks for making the chang= es. I still have the following comments:=

1. Section 3.1: it is not s= till clear why the ingress has to specify the backup path (in form of EB-SE= RO) from previous hop PLR to the backup egress node

Huaimo: The ingress does = not have to specify the backup path (in form of EB-SERO) from previous hop = PLR to the backup egress node. We will revise the draft accordingly.

 

2. Section 3.2.2: "For= a primary LSP carrying IP packets, the PLR does not need any downstream la= bel…"

    i. What if th= e LSP is carrying non-IP traffic?

Ii. There are cases where non-NULL label is needed at the egress— e.= g., for collecting rx stats, for doing RPF check, etc.-- hence above statement is not necessarily true<= /o:p>

Huaimo:  This ("For a primary LSP carrying IP packets, the= PLR does not need any downstream label…") = may be changed to something like:  “For a primary LSP, if the PL= R (the upstream node of the primary egress of the LSP) does the PHP  f= or the LSP, it redirects the traffic from the primary LSP into the backup LSP to = the backup egress when it detects the failure of the primary egress; otherw= ise, it redirects the packets from the primary LSP into the backup LSP to b= ackup egress using the primary LSP label from the primary egress as an inner label. (At the backup egress, it= uses the backup LSP label as a context label to find the LFIB for the prim= ary egress and uses the inner label under the context to handle the packets= such as collecting rx stats and forwarding the packets, which are similar to the behaviors at the primary = egress.)” What are your suggestions and comments on this?

 

3. Incidentally, "draf= t-minto-rsvp-lsp-egress-fast-protection-03" is also proposing a mechan= ism to achieve this protection using proxy/virtual egress node - = although little mention to P2MP. Have you considered if there's any overlap there?<= /span>

Huaimo: This draft tries = to provide the P2P TE LSP egress protection using proxy/virtual egress node= (proxy method). It needs extensions to the IGP (ISIS and OSPF) in addition to extensions to RSVP-TE and has a number of limitations= (The top of page 9 in the draft lists four limitations/caveats).  

 

Regards,

Tarek

 

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Thursday, 12 December, 2013 8:20 AM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Cc: Tarek Saad <tsaad@cisco.co= m>, Raveendra Torvi <rtorvi= @juniper.net>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

draft-chen-mpls-p2mp-egr= ess-protection was reviewed by the MPLS Review team prior to being polled f= or WG adoption. The authors have updated the draft according to the comment= s. We have had responses from some of the reviewers that they are comfortable with how the comments have been ad= dressed. We would like to have the same response from the other two reviewe= rs.

 =

Best Regards,=

Huaimo=

--_000_769a7465342c40109412a7451aac873fBY2PR05MB728namprd05pro_-- From huaimo.chen@huawei.com Fri Jan 3 11:24:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E86A1AE012 for ; Fri, 3 Jan 2014 11:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 20jpv68lxi1Q for ; Fri, 3 Jan 2014 11:24:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 48E031ADFDA for ; Fri, 3 Jan 2014 11:24:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZP46564; Fri, 03 Jan 2014 19:24:40 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Jan 2014 19:24:28 +0000 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; Fri, 3 Jan 2014 19:24:39 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Fri, 3 Jan 2014 11:24:33 -0800 From: Huaimo Chen To: "Tarek Saad (tsaad)" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHO9zz2D8OUboE/BU63IW10jjHvHppWOpUAgACbxPCAHJIbgIAAEo2Q Date: Fri, 3 Jan 2014 19:24:32 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C2EE3B@SJCEML701-CHM.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C20383@sjceml501-mbs.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: [10.212.244.154] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C2EE3BSJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 19:24:54 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C2EE3BSJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tarek, Thanks much for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Friday, January 03, 2014 11:45 AM To: Huaimo Chen; mpls@ietf.org Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Huaimo, Thanks. See inline below. 2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not = need any downstream label..." i. What if the LSP is carrying non-IP traffic? Ii. There are cases where non-NULL label is needed at the egress- e.g., for= collecting rx stats, for doing RPF check, etc.-- hence above statement is = not necessarily true Huaimo: This ("For a primary LSP carrying IP packets, the PLR does not nee= d any downstream label...") may be changed to something like: "For a prima= ry LSP, if the PLR (the upstream node of the primary egress of the LSP) doe= s the PHP for the LSP, it redirects the traffic from the primary LSP into = the backup LSP to the backup egress when it detects the failure of the prim= ary egress; otherwise, it redirects the packets from the primary LSP into t= he backup LSP to backup egress using the primary LSP label from the primary= egress as an inner label. (At the backup egress, it uses the backup LSP la= bel as a context label to find the LFIB for the primary egress and uses the= inner label under the context to handle the packets such as collecting rx = stats and forwarding the packets, which are similar to the behaviors at the= primary egress.)" What are your suggestions and comments on this? [TS]: yes, using the primary egress label as inner label after rerouting (l= ocal repair) over the facility bypass may work. However, additional mechani= cs will be required to synchronize the label assignment between the primary= and backup egress nodes. Also, will necessitate backup egress node to supp= ort upstream assigned labels, and facility bypass must be UHP to provide co= ntext for the upstream label. [Huaimo]: There are a couple of ways to synchronize the label assignment be= tween the primary and backup egress nodes. One way is to use BGP or another= protocol for the primary egress to send the primary LSP label to the backu= p egress as upstream assigned (UA) label. Another way is that the primary e= gress sends the primary LSP label as UA label to the backup egress via the = PLR through RSVP-TE extensions. Basically, the PLR includes an EGRESS_BACKUP_SUB_LSP object in the Path mes= sage to the primary egress, containing the backup egress and the backup LSP= ID. The primary egress sends the backup egress the primary LSP label as UA= label via the PLR after receiving the Path message with the EGRESS_BACKUP_= SUB_LSP. The backup egress adds a forwarding entry with the label into the = LFIB for the primary egress when receiving a UA label from the primary egre= ss. When the PLR detects the failure of the primary egress, it redirects the pa= ckets from the primary LSP into the backup LSP to backup egress using the p= rimary LSP label from the primary egress as an inner label. The backup egre= ss delivers the packets to the same destinations as the primary egress usin= g the backup LSP label as context label and the inner label as UA label. This needs backup egress support upstream assigned labels and facility = bypass must be UHP as you mentioned. It seems that this is not a big issue = since the upstream label assignment and UHP have been defined by MPLS WG. Regards, Tarek From: Huaimo Chen > Date: Monday, 16 December, 2013 10:55 PM To: Tarek Saad >, "mpls@ietf.org" > Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Tarek, Thank you very much for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Sunday, December 15, 2013 10:09 PM To: Huaimo Chen; mpls@ietf.org Cc: Raveendra Torvi Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Huaimo, Thanks for making the changes. I still have the following comments: 1. Section 3.1: it is not still clear why the ingress has to specify the ba= ckup path (in form of EB-SERO) from previous hop PLR to the backup egress n= ode Huaimo: The ingress does not have to specify the backup path (in form of EB= -SERO) from previous hop PLR to the backup egress node. We will revise the = draft accordingly. 2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not = need any downstream label..." i. What if the LSP is carrying non-IP traffic? Ii. There are cases where non-NULL label is needed at the egress- e.g., for= collecting rx stats, for doing RPF check, etc.-- hence above statement is = not necessarily true Huaimo: This ("For a primary LSP carrying IP packets, the PLR does not nee= d any downstream label...") may be changed to something like: "For a prima= ry LSP, if the PLR (the upstream node of the primary egress of the LSP) doe= s the PHP for the LSP, it redirects the traffic from the primary LSP into = the backup LSP to the backup egress when it detects the failure of the prim= ary egress; otherwise, it redirects the packets from the primary LSP into t= he backup LSP to backup egress using the primary LSP label from the primary= egress as an inner label. (At the backup egress, it uses the backup LSP la= bel as a context label to find the LFIB for the primary egress and uses the= inner label under the context to handle the packets such as collecting rx = stats and forwarding the packets, which are similar to the behaviors at the= primary egress.)" What are your suggestions and comments on this? 3. Incidentally, "draft-minto-rsvp-lsp-egress-fast-protection-03" is also p= roposing a mechanism to achieve this protection using proxy/virtual egress = node - although little mention to P2MP. Have you considered if there's any = overlap there? Huaimo: This draft tries to provide the P2P TE LSP egress protection using = proxy/virtual egress node (proxy method). It needs extensions to the IGP (I= SIS and OSPF) in addition to extensions to RSVP-TE and has a number of limi= tations (The top of page 9 in the draft lists four limitations/caveats). Regards, Tarek From: Huaimo Chen > Date: Thursday, 12 December, 2013 8:20 AM To: "mpls@ietf.org" > Cc: Tarek Saad >, Raveendra Torvi <= rtorvi@juniper.net> Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection draft-chen-mpls-p2mp-egress-protection was reviewed by the MPLS Review team= prior to being polled for WG adoption. The authors have updated the draft = according to the comments. We have had responses from some of the reviewers= that they are comfortable with how the comments have been addressed. We wo= uld like to have the same response from the other two reviewers. Best Regards, Huaimo --_000_5316A0AB3C851246A7CA5758973207D445C2EE3BSJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tarek,

 <= /p>

Thanks much for your comments!

My answers/explanations are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Tarek Sa= ad (tsaad) [mailto:tsaad@cisco.com]
Sent: Friday, January 03, 2014 11:45 AM
To: Huaimo Chen; mpls@ietf.org
Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

Hi Huaimo,

 

Thanks. See inline below.

 

2. Section 3.2.2: "For a primary LSP= carrying IP packets, the PLR does not need any downstream label…&quo= t;

    i. What if the LSP is carry= ing non-IP traffic?

Ii. There are cases where non-NULL label is needed= at the egress— e.g., for collecting rx stats, for doing RPF check, e= tc.-- hence above statement is not necessarily true

Huaimo:  This ("For a primary LSP carrying IP packets, the PLR does not need any downstream la= bel…") may be changed to = something like:  “For a primary LSP, if the PLR (the upstream no= de of the primary egress of the LSP) does the PHP  for the LSP, it redirect= s the traffic from the primary LSP into the backup LSP to the backup egress= when it detects the failure of the primary egress; otherwise, it redirects= the packets from the primary LSP into the backup LSP to backup egress using the primary LSP label from the prima= ry egress as an inner label. (At the backup egress, it uses the backup LSP = label as a context label to find the LFIB for the primary egress and uses t= he inner label under the context to handle the packets such as collecting rx stats and forwarding the packe= ts, which are similar to the behaviors at the primary egress.)” What = are your suggestions and comments on this?

[TS]: yes, using the primar= y egress label as inner label after rerouting (local repair) over the = facility bypass may work. However, additional mechanics will be required to synchronize the label assignment between the primary and ba= ckup egress nodes. Also, will necessitate backup egress node to support ups= tream assigned labels, and facility bypass must be UHP to provide context f= or the upstream label.

 <= /p>

[Huaimo]: There are a couple of ways to synchronize the label assignment= between the primary and backup egress nodes. One way is to use BGP or another protocol for the primary egress to send the primary LSP= label to the backup egress as upstream assigned (UA) label. Another way is= that the primary egress sends the primary LSP label as UA label to the bac= kup egress via the PLR through RSVP-TE extensions.

Basically, the PLR includes an EGRESS_= BACKUP_SUB_LSP object in the Path message to the primary egress, containing the backup eg= ress and the backup LSP ID. The primary egress sends the backup egress the = primary LSP label as UA label via the PLR after receiving the Path message = with the EGRESS_BACKUP_SUB_LSP. The backup egress adds a forwarding entry with the label into the LFIB for= the primary egress when receiving a UA label from the primary egress.

When the PLR detects the failure of the primary egress, it redirects the= packets from the primary LSP into the backup LSP to backup egress using the primary LSP label from the primary egress as an inner lab= el. The backup egress delivers the packets to the same destinations as the = primary egress using the backup LSP label as context label and the inner la= bel as UA label.

    This n= eeds backup egress support upstream assigned labels and facility bypass mus= t be UHP as you mentioned. It seems that this is not a big issue since the upstream label assignment and UHP have been defined by MPLS WG.

 

Regards,<= /p>

Tarek

 

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Monday, 16 December, 2013 10:55 PM
To: Tarek Saad <tsaad@cisco.co= m>, "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

Hi Tarek,

 

Thank you very much for your comments!

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: Tarek Saad (tsaad) [mail= to:tsaad@cisco.com]
Sent: Sunday, December 15, 2013 10:09 PM
To: Huaimo Chen; mpls@ietf.org<= br> Cc: Raveendra Torvi
Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 =

Hi Huaimo,

 

Thanks for making the chang= es. I still have the following comments:=

1. Section 3.1: it is not s= till clear why the ingress has to specify the backup path (in form of EB-SE= RO) from previous hop PLR to the backup egress node

Huaimo: The ingress does = not have to specify the backup path (in form of EB-SERO) from previous hop = PLR to the backup egress node. We will revise the draft accordingly.

 

2. Section 3.2.2: "For= a primary LSP carrying IP packets, the PLR does not need any downstream la= bel…"

    i. What if th= e LSP is carrying non-IP traffic?

Ii. There are cases where non-NULL label is needed at the egress— e.= g., for collecting rx stats, for doing RPF check, etc.-- hence above statement is not necessarily true<= /o:p>

Huaimo:  This ("For a primary LSP carrying IP packets, the= PLR does not need any downstream label…") = may be changed to something like:  “For a primary LSP, if the PL= R (the upstream node of the primary egress of the LSP) does the PHP  f= or the LSP, it redirects the traffic from the primary LSP into the backup LSP to = the backup egress when it detects the failure of the primary egress; otherw= ise, it redirects the packets from the primary LSP into the backup LSP to b= ackup egress using the primary LSP label from the primary egress as an inner label. (At the backup egress, it= uses the backup LSP label as a context label to find the LFIB for the prim= ary egress and uses the inner label under the context to handle the packets= such as collecting rx stats and forwarding the packets, which are similar to the behaviors at the primary = egress.)” What are your suggestions and comments on this?

 

3. Incidentally, "draf= t-minto-rsvp-lsp-egress-fast-protection-03" is also proposing a mechan= ism to achieve this protection using proxy/virtual egress node - = although little mention to P2MP. Have you considered if there's any overlap there?<= /span>

Huaimo: This draft tries = to provide the P2P TE LSP egress protection using proxy/virtual egress node= (proxy method). It needs extensions to the IGP (ISIS and OSPF) in addition to extensions to RSVP-TE and has a number of limitations= (The top of page 9 in the draft lists four limitations/caveats).  

 

Regards,

Tarek

 

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Thursday, 12 December, 2013 8:20 AM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Cc: Tarek Saad <tsaad@cisco.co= m>, Raveendra Torvi <rtorvi= @juniper.net>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

draft-chen-mpls-p2mp-egr= ess-protection was reviewed by the MPLS Review team prior to being polled f= or WG adoption. The authors have updated the draft according to the comment= s. We have had responses from some of the reviewers that they are comfortable with how the comments have been ad= dressed. We would like to have the same response from the other two reviewe= rs.

 =

Best Regards,=

Huaimo=

--_000_5316A0AB3C851246A7CA5758973207D445C2EE3BSJCEML701CHMchi_-- From huaimo.chen@huawei.com Fri Jan 3 12:10:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118581ADFCB for ; Fri, 3 Jan 2014 12:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 sBimHWlrGw4p for ; Fri, 3 Jan 2014 12:10:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3372F1ADFDF for ; Fri, 3 Jan 2014 12:10:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZP48311; Fri, 03 Jan 2014 20:10:29 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Jan 2014 20:10:10 +0000 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; Fri, 3 Jan 2014 20:10:28 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Fri, 3 Jan 2014 12:10:21 -0800 From: Huaimo Chen To: Yimin Shen , "Tarek Saad (tsaad)" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHO9zz2D8OUboE/BU63IW10jjHvHppWOpUAgACbxPCAHJIbgP//80tQgAAog7A= Date: Fri, 3 Jan 2014 20:10:21 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C2EE66@SJCEML701-CHM.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C20383@sjceml501-mbs.china.huawei.com> <769a7465342c40109412a7451aac873f@BY2PR05MB728.namprd05.prod.outlook.com> In-Reply-To: <769a7465342c40109412a7451aac873f@BY2PR05MB728.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.154] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C2EE66SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 20:10:43 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C2EE66SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yimin, Thanks for your comments! It seems that an LSP may carry the traffic without any service label. In th= is case, how do you protect its egress failure using its service label as y= ou mentioned that your service protect drafts solve egress protection? Yimin, our egress local protect draft has section 4 "Considering Applicatio= n Traffic" talking about how to provide the service protection. In fact, with the egress local protection proposed in our draft, the servic= e traffic with a service label can be easily protected against the failure = of the primary egress. Thus both the traffic without any service label and = the traffic with a service label are protected for the failure of the prima= ry egress. BTW, the service protection proposed in your service protection draft ht= tp://tools.ietf.org/search/draft-minto-2547-egress-node-fast-protection-02 needs another LSP egress protection draft raft-minto-rsvp-lsp-egress-fast-p= rotection-01, which requires both IGP and RSVP-TE extensions. Best Regards, Huaimo From: Yimin Shen [mailto:yshen@juniper.net] Sent: Friday, January 03, 2014 12:54 PM To: Tarek Saad (tsaad); Huaimo Chen; mpls@ietf.org Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi, I concur with Tarek's comment on this. In fact, the following drafts have b= een proposed to provide egress protection for the inner labels (i.e. layer-= 2/3 VPN service labels). These drafts solve egress protection from a differ= ent angle, i.e. on a per-service basis, because ultimately it is the servic= e label that must be protected. As I've communicated with Huaimo, this is a= n important piece that is missing in his draft. Also, once service labels c= an be protected, there is no need for an RSVP (or LDP) extension for bypass= tunnel signaling. This is because upstream labels, UHP, context label swi= tching, etc have already been defined by MPLS WG, and hence the existing by= pass path computation and signaling mechanisms are already sufficient. http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-00 http://tools.ietf.org/search/draft-minto-2547-egress-node-fast-protection-0= 2 Thanks, /Yimin From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad) Sent: Friday, January 03, 2014 11:45 AM To: Huaimo Chen; mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi Huaimo, Thanks. See inline below. 2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not = need any downstream label..." i. What if the LSP is carrying non-IP traffic? Ii. There are cases where non-NULL label is needed at the egress- e.g., for= collecting rx stats, for doing RPF check, etc.-- hence above statement is = not necessarily true Huaimo: This ("For a primary LSP carrying IP packets, the PLR does not nee= d any downstream label...") may be changed to something like: "For a prima= ry LSP, if the PLR (the upstream node of the primary egress of the LSP) doe= s the PHP for the LSP, it redirects the traffic from the primary LSP into = the backup LSP to the backup egress when it detects the failure of the prim= ary egress; otherwise, it redirects the packets from the primary LSP into t= he backup LSP to backup egress using the primary LSP label from the primary= egress as an inner label. (At the backup egress, it uses the backup LSP la= bel as a context label to find the LFIB for the primary egress and uses the= inner label under the context to handle the packets such as collecting rx = stats and forwarding the packets, which are similar to the behaviors at the= primary egress.)" What are your suggestions and comments on this? [TS]: yes, using the primary egress label as inner label after rerouting (l= ocal repair) over the facility bypass may work. However, additional mechani= cs will be required to synchronize the label assignment between the primary= and backup egress nodes. Also, will necessitate backup egress node to supp= ort upstream assigned labels, and facility bypass must be UHP to provide co= ntext for the upstream label. Regards, Tarek From: Huaimo Chen > Date: Monday, 16 December, 2013 10:55 PM To: Tarek Saad >, "mpls@ietf.org" > Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Tarek, Thank you very much for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Sunday, December 15, 2013 10:09 PM To: Huaimo Chen; mpls@ietf.org Cc: Raveendra Torvi Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Huaimo, Thanks for making the changes. I still have the following comments: 1. Section 3.1: it is not still clear why the ingress has to specify the ba= ckup path (in form of EB-SERO) from previous hop PLR to the backup egress n= ode Huaimo: The ingress does not have to specify the backup path (in form of EB= -SERO) from previous hop PLR to the backup egress node. We will revise the = draft accordingly. 2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not = need any downstream label..." i. What if the LSP is carrying non-IP traffic? Ii. There are cases where non-NULL label is needed at the egress- e.g., for= collecting rx stats, for doing RPF check, etc.-- hence above statement is = not necessarily true Huaimo: This ("For a primary LSP carrying IP packets, the PLR does not nee= d any downstream label...") may be changed to something like: "For a prima= ry LSP, if the PLR (the upstream node of the primary egress of the LSP) doe= s the PHP for the LSP, it redirects the traffic from the primary LSP into = the backup LSP to the backup egress when it detects the failure of the prim= ary egress; otherwise, it redirects the packets from the primary LSP into t= he backup LSP to backup egress using the primary LSP label from the primary= egress as an inner label. (At the backup egress, it uses the backup LSP la= bel as a context label to find the LFIB for the primary egress and uses the= inner label under the context to handle the packets such as collecting rx = stats and forwarding the packets, which are similar to the behaviors at the= primary egress.)" What are your suggestions and comments on this? 3. Incidentally, "draft-minto-rsvp-lsp-egress-fast-protection-03" is also p= roposing a mechanism to achieve this protection using proxy/virtual egress = node - although little mention to P2MP. Have you considered if there's any = overlap there? Huaimo: This draft tries to provide the P2P TE LSP egress protection using = proxy/virtual egress node (proxy method). It needs extensions to the IGP (I= SIS and OSPF) in addition to extensions to RSVP-TE and has a number of limi= tations (The top of page 9 in the draft lists four limitations/caveats). Regards, Tarek From: Huaimo Chen > Date: Thursday, 12 December, 2013 8:20 AM To: "mpls@ietf.org" > Cc: Tarek Saad >, Raveendra Torvi <= rtorvi@juniper.net> Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection draft-chen-mpls-p2mp-egress-protection was reviewed by the MPLS Review team= prior to being polled for WG adoption. The authors have updated the draft = according to the comments. We have had responses from some of the reviewers= that they are comfortable with how the comments have been addressed. We wo= uld like to have the same response from the other two reviewers. Best Regards, Huaimo --_000_5316A0AB3C851246A7CA5758973207D445C2EE66SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yimin,

 <= /p>

Thanks for your comments!

It seems that an LSP may carry the traffic without any service label. In= this case, how do you protect its egress failure using its service label as you mentioned that your service protect drafts solve egre= ss protection?

Yimin, our egress local protect draft has section 4 “Considering A= pplication Traffic” talking about how to provide the service protecti= on.

In fact, with the egress local protection proposed in our draft, the ser= vice traffic with a service label can be easily protected against the failure of the primary egress. Thus both the traffic without a= ny service label and the traffic with a service label are protected for the= failure of the primary egress.

BTW, the service protection  proposed in your service protection dr= aft   http://tool= s.ietf.org/search/draft-minto-2547-egress-node-fast-protection-02

needs another LSP egress protection draft raft= -minto-rsvp-lsp-egress-fast-protection-01, w= hich requires both IGP and RSVP-TE extensions.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Yimin Sh= en [mailto:yshen@juniper.net]
Sent: Friday, January 03, 2014 12:54 PM
To: Tarek Saad (tsaad); Huaimo Chen; mpls@ietf.org
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

Hi,

 <= /p>

I concur with Tarek’= ;s comment on this. In fact, the following drafts have been proposed to pro= vide egress protection for the inner labels (i.e. layer-2/3 VPN service labels). These drafts solve egress protection from a different ang= le, i.e. on a per-service basis, because ultimately it is the service label= that must be protected. As I’ve communicated with Huaimo, this is an= important piece that is missing in his draft. Also, once service labels can be protected, there is no need for an= RSVP (or LDP) extension for bypass tunnel signaling. This is  because= upstream labels, UHP, context label switching, etc have already been defin= ed by MPLS WG, and hence the existing bypass path computation and signaling mechanisms are already sufficient. <= o:p>

 <= /p>

http://tools.ietf.org/html/draft-ietf-pw= e3-endpoint-fast-protection-00

http://tools.ietf.org/search/draft= -minto-2547-egress-node-fast-protection-02

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad)
Sent: Friday, January 03, 2014 11:45 AM
To: Huaimo Chen; mpls@ietf.org<= br> Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi Huaimo,

 

Thanks. See inline below.

 

2. Section 3.2.2: "For a primary LSP= carrying IP packets, the PLR does not need any downstream label…&quo= t;

    i. What if the LSP is carry= ing non-IP traffic?

Ii. There are cases where non-NULL label is needed= at the egress— e.g., for collecting rx stats, for doing RPF check, e= tc.-- hence above statement is not necessarily true

Huaimo:  This ("For a primary LSP carrying IP packets, the PLR does not need any downstream la= bel…") may be changed to = something like:  “For a primary LSP, if the PLR (the upstream no= de of the primary egress of the LSP) does the PHP  for the LSP, it redirect= s the traffic from the primary LSP into the backup LSP to the backup egress= when it detects the failure of the primary egress; otherwise, it redirects= the packets from the primary LSP into the backup LSP to backup egress using the primary LSP label from the prima= ry egress as an inner label. (At the backup egress, it uses the backup LSP = label as a context label to find the LFIB for the primary egress and uses t= he inner label under the context to handle the packets such as collecting rx stats and forwarding the packe= ts, which are similar to the behaviors at the primary egress.)” What = are your suggestions and comments on this?

[TS]: yes, using the primar= y egress label as inner label after rerouting (local repair) over the = facility bypass may work. However, additional mechanics will be required to synchronize the label assignment between the primary and ba= ckup egress nodes. Also, will necessitate backup egress node to support ups= tream assigned labels, and facility bypass must be UHP to provide context f= or the upstream label.

 

Regards,<= /p>

Tarek

 

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Monday, 16 December, 2013 10:55 PM
To: Tarek Saad <tsaad@cisco.co= m>, "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

Hi Tarek,

 

Thank you very much for your comments!

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: Tarek Saad (tsaad) [mail= to:tsaad@cisco.com]
Sent: Sunday, December 15, 2013 10:09 PM
To: Huaimo Chen; mpls@ietf.org<= br> Cc: Raveendra Torvi
Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 =

Hi Huaimo,

 

Thanks for making the chang= es. I still have the following comments:=

1. Section 3.1: it is not s= till clear why the ingress has to specify the backup path (in form of EB-SE= RO) from previous hop PLR to the backup egress node

Huaimo: The ingress does = not have to specify the backup path (in form of EB-SERO) from previous hop = PLR to the backup egress node. We will revise the draft accordingly.

 

2. Section 3.2.2: "For= a primary LSP carrying IP packets, the PLR does not need any downstream la= bel…"

    i. What if th= e LSP is carrying non-IP traffic?

Ii. There are cases where non-NULL label is needed at the egress— e.= g., for collecting rx stats, for doing RPF check, etc.-- hence above statement is not necessarily true<= /o:p>

Huaimo:  This ("For a primary LSP carrying IP packets, the= PLR does not need any downstream label…") = may be changed to something like:  “For a primary LSP, if the PL= R (the upstream node of the primary egress of the LSP) does the PHP  f= or the LSP, it redirects the traffic from the primary LSP into the backup LSP to = the backup egress when it detects the failure of the primary egress; otherw= ise, it redirects the packets from the primary LSP into the backup LSP to b= ackup egress using the primary LSP label from the primary egress as an inner label. (At the backup egress, it= uses the backup LSP label as a context label to find the LFIB for the prim= ary egress and uses the inner label under the context to handle the packets= such as collecting rx stats and forwarding the packets, which are similar to the behaviors at the primary = egress.)” What are your suggestions and comments on this?

 

3. Incidentally, "draf= t-minto-rsvp-lsp-egress-fast-protection-03" is also proposing a mechan= ism to achieve this protection using proxy/virtual egress node - = although little mention to P2MP. Have you considered if there's any overlap there?<= /span>

Huaimo: This draft tries = to provide the P2P TE LSP egress protection using proxy/virtual egress node= (proxy method). It needs extensions to the IGP (ISIS and OSPF) in addition to extensions to RSVP-TE and has a number of limitations= (The top of page 9 in the draft lists four limitations/caveats).  

 

Regards,

Tarek

 

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Thursday, 12 December, 2013 8:20 AM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Cc: Tarek Saad <tsaad@cisco.co= m>, Raveendra Torvi <rtorvi= @juniper.net>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

draft-chen-mpls-p2mp-egr= ess-protection was reviewed by the MPLS Review team prior to being polled f= or WG adoption. The authors have updated the draft according to the comment= s. We have had responses from some of the reviewers that they are comfortable with how the comments have been ad= dressed. We would like to have the same response from the other two reviewe= rs.

 =

Best Regards,=

Huaimo=

--_000_5316A0AB3C851246A7CA5758973207D445C2EE66SJCEML701CHMchi_-- From loa@pi.nu Fri Jan 3 21:03:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6471A1F1B for ; Fri, 3 Jan 2014 21:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 Bcfrn62XnfWt for ; Fri, 3 Jan 2014 21:03:09 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id C79071A1EF9 for ; Fri, 3 Jan 2014 21:03:08 -0800 (PST) Received: from [192.168.1.5] (unknown [112.208.5.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9BF881800740; Sat, 4 Jan 2014 06:02:58 +0100 (CET) Message-ID: <52C795FE.7060801@pi.nu> Date: Sat, 04 Jan 2014 13:02:54 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org Subject: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 05:03:11 -0000 Working Group, this is to start a two week working group last call on draft-ietf-mpls-proxy-lsp-ping-01.txt Please send your comments to working group mailing lists (mpls@ietf.org). We will do an IPR poll on this document in parallel thee wglc. There are three IPRs disclosures that relates to this document. The working group last call will end Friday January 20, 2914. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Fri Jan 3 21:03:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28C11A1F4E for ; Fri, 3 Jan 2014 21:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 SYI39myxbZiB for ; Fri, 3 Jan 2014 21:03:27 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id A896C1A1F4C for ; Fri, 3 Jan 2014 21:03:27 -0800 (PST) Received: from [192.168.1.5] (unknown [112.208.5.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 43F431800740; Sat, 4 Jan 2014 06:03:15 +0100 (CET) Message-ID: <52C79610.3080201@pi.nu> Date: Sat, 04 Jan 2014 13:03:12 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org, "mpls-chairs@tools.ietf.org" , Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] IPR poll on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 05:03:29 -0000 Working Group, We have just started a working group last call on draft-ietf-mpls-proxy-lsp-ping. we want to do an IPR poll in parallel. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-proxy-lsp-ping? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are three IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Sat Jan 4 04:16:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D593F1ADF4F; Sat, 4 Jan 2014 04:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 AortstPeZRsf; Sat, 4 Jan 2014 04:16:46 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 420861ADF39; Sat, 4 Jan 2014 04:16:46 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s04CGb9F021218; Sat, 4 Jan 2014 12:16:38 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s04CGZit021190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 4 Jan 2014 12:16:36 GMT From: "Adrian Farrel" To: Date: Sat, 4 Jan 2014 12:16:29 -0000 Message-ID: <007201cf0946$d2517c30$76f47490$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8JRrPrn/n8O7gdQU+Zn0x2e4iDrA== Content-Language: en-gb X-TM-AS-MML: No Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: (A Framework for Point-to-Multipoint MPLS in Transport Networks) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 12:16:48 -0000 So this doesn't get lost, here comments I sent to the authors before starting IETF last call... > Dan will probably want to update his coordinates. > > --- > > You don't need to be so enthusiastic with your acronyms in Section 1.2 > The following are "well known" according to > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > GMPLS Generalized MPLS > LDP Label Distribution Protocol > MPLS Multiprotocol Label Switching > > There is a serial comma missing from > OAM Operations, Administration and Maintenance > The comma is also missing in your text. > > --- > > In Section 1.3 you say > > There is no definition for MPLS TE-LSP support of multipoint-to- > multipoint connectivity and none is anticipated. > > Without opening up a discussion of whether what you cay is true, can you > say why it is relevant? Perhaps "This document is limited to a > discussion of point-to-multipoint function and does not discuss > multipoint-to-multipoint support." You might also move this to Section > 1.1. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG > Sent: 02 January 2014 15:17 > To: IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] Last Call: (A > Framework for Point-to-Multipoint MPLS in Transport Networks) to Informational > RFC > > > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'A Framework for Point-to-Multipoint MPLS in Transport Networks' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-01-16. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > The Multiprotocol Label Switching Transport Profile is the common set > of MPLS protocol functions defined to enable the construction and > operation of packet transport networks. The MPLS-TP supports both > point-to-point and point-to-multipoint transport paths. This > document defines the elements and functions of the MPLS-TP > architecture applicable specifically to supporting point-to- > multipoint transport paths. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-p2mp-framework/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-p2mp-framework/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From tnadeau@lucidvision.com Sat Jan 4 05:32:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF441ADF85 for ; Sat, 4 Jan 2014 05:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 uyVd5BoIvneo for ; Sat, 4 Jan 2014 05:32:24 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id BA1431ADF7B for ; Sat, 4 Jan 2014 05:32:23 -0800 (PST) Received: from [192.168.1.114] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DDF1826A5638; Sat, 4 Jan 2014 08:32:15 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_5F6F59BB-0907-47A0-9750-291CDFEBD342"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <52C79610.3080201@pi.nu> Date: Sat, 4 Jan 2014 08:32:15 -0500 Message-Id: <9535B527-9AD0-487A-B7B7-441B83EFFDA3@lucidvision.com> References: <52C79610.3080201@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1827) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 13:32:27 -0000 --Apple-Mail=_5F6F59BB-0907-47A0-9750-291CDFEBD342 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =09 I do not believe that Cisco has disclosed this related one: http://www.freepatentsonline.com/y2009/0238084.html --Tom > Working Group, >=20 > We have just started a working group last call on > draft-ietf-mpls-proxy-lsp-ping. we want to do an IPR poll in > parallel. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to = draft-ietf-mpls-proxy-lsp-ping? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are three IPR disclosures that relates to this = document. >=20 > If you are listed as a document author or contributor please respond = to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The = document will not advance to the next stage until a response has been > received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author = or > contributor, then please explicitly respond only if you are aware of = any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 --Apple-Mail=_5F6F59BB-0907-47A0-9750-291CDFEBD342 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 iQIcBAEBCgAGBQJSyA1fAAoJEPcO+I7eiUJZsWIP/iEhxQbpUGxNYzwXtTOiLBj3 zMgDMCOUevHFqSXomkk+t1q57CCwhB42LY46PnQLplEinU3yqbOinEUJfRcVcuDq fVQlLy11ZyZXfFVm1016qriKr5Of7p4ov42jRjLAqvJkcFzrGeGNwa4tRhczk7Ee kLhffVkFqHFttUmAV6lrK0c+JBFEKy052QglmBo8oTcxPeDApGpWFSZCanBftwDd etK4IO7j4XnGSklZ+2ER2q/h5aHmo+xF58XrddPmdQZk93KUVSmwxrDQNuZbZbeP lsm6BGIQTnz7+ujnI1xeNm00KnumO9LCvpjqWhWnyG/5jJjuBYBvlPCD94ndMjTS yNMwkwAlJeAZ2ypZKxbjsXYHW/pkdoqoI1q+o4kSEGfwURo8NtOU7kJhM7XR2KOO CDMlHJDWwCYLuPvlzwqsGU+37XdR5kTOzT83TCPwbB9NTiLC1e6rvTRCNcFaGwfg qs8ygOvZ6BaeVQg8aMm3WA7KR3vg5b8IdbCoLTxGccd8cnlMrXXuf3ltiJ+nfkdV 5NRXRSZeZ7Cx6UuxurSS9Rc2z22QPf/GwxJr++lOH9WmkP/KcqdKrtRWzNFkdBxb Bd9X7ZrnPVq6auKz8nNPFh6u5N4Qd9pyydgOR48AT8ZrmxfM49erSd9J1iRRRK6r nYtm1XYOFv/q6NaKkg5S =Id2E -----END PGP SIGNATURE----- --Apple-Mail=_5F6F59BB-0907-47A0-9750-291CDFEBD342-- From autumn.liu@ericsson.com Sat Jan 4 11:31:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F9B1AE051 for ; Sat, 4 Jan 2014 11:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwtMwcpVUVGr for ; Sat, 4 Jan 2014 11:31:43 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 640691AE089 for ; Sat, 4 Jan 2014 11:31:43 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-08-52c8619788d1 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C6.63.04556.79168C25; Sat, 4 Jan 2014 20:31:35 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0347.000; Sat, 4 Jan 2014 14:31:06 -0500 From: Autumn Liu To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJp09Vgg Date: Sat, 4 Jan 2014 19:31:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPlO70xBNBBhePm1nM+juT1eL7pSUs FreWrmS1+LviCosDi8eSJT+ZPK43XWX3+HL5M1sAcxSXTUpqTmZZapG+XQJXxtdDj9kLFvJW rPt4hLWB8TlXFyMnh4SAicSvNS3sELaYxIV769m6GLk4hASOMErcvrULylnGKDFv9nIWkCo2 AS2JffvfsYMkRAT2MkqsWzQLrJ1ZwFbizpNrjCC2sICDxPFtV8EaRAQcJbpv9DNC2EYST7vP M4HYLAIqEs/f7mAFsXkFfCXuv1kBZgsJhEqsud0LNpNTIExi8fxbYDajgKzEtEf3mSB2iUvc ejKfCeJsAYkle84zQ9iiEi8f/2OFsJUlvs95xAJRryOxYPcnNghbW2LZwtfMEHsFJU7OfMIy gVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UaGmxiBcXRMgs1xB+OCT5aHGKU5WJTEeb+8 dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCioJSp80rI0h622Q5xvwszOGIfd06ZkPXr4 YeE5BsE72a57NcwKrGzn+u0odSnYOs1Q/sK2Kc8UI6ru9d5QZQ4Jspu8z0Spq0/aNPGx8r/S GLlDmVJX2lZr/g5huxn/6pdca2rtrcetkz7f2MVpcZKjI+kiu/GyGbJT3ZmDK+Vmek5LdLJe qcRSnJFoqMVcVJwIAFHPWRlxAgAA Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 19:31:46 -0000 I am not aware of any related IPR. Thanks, Autumn (as co-author of this draft) -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, January 03, 2014 8:49 AM To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the workin= g group chairs that the draft is ready to be adopted as a working group doc= ument. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-ingress-prote= ction? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From aldrin.ietf@gmail.com Sat Jan 4 17:21:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170CB1AE0CF for ; Sat, 4 Jan 2014 17:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqixw9YE_DpJ for ; Sat, 4 Jan 2014 17:21:05 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id AA3D71AD73E for ; Sat, 4 Jan 2014 17:21:05 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id md12so17040560pbc.21 for ; Sat, 04 Jan 2014 17:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=xN6Mv+ULIsz4g4TmfwNQ7F4XQIi7Jn3soDfcCXmRqaI=; b=mp77z1BLt4x71j7/A1YFmEOVOJflFM8v+k/JrJ+rGDkmKfr7ktjiey9T3TqmM4wPZl JWSGZPcsuKw1pxiYo38g31HMTcZj9CtpPVXaxBVD/fFl+6fjtijaOyGsBhD49kCvU99d cWxN7KYxAKpBDXbqz3ahBkdUtG8bdF6mo7fTmKyK6C94p4ngel+l36e8VC/L6QlSca4+ HCgeBtCASLeq5QpJpxN3psBJB9nmFZmmDxiZHpNTtiS0+ngF6sur9uVKoiZNdPFSU0A7 SbUIk/YIoH1SRI7b/+h3sv7pNSmR6arq0hdVByavFhI2iaeuPyirQOBC5X+tGwGLUBuy vUbQ== X-Received: by 10.68.190.33 with SMTP id gn1mr110210754pbc.48.1388884857984; Sat, 04 Jan 2014 17:20:57 -0800 (PST) Received: from [10.0.2.2] ([106.220.25.49]) by mx.google.com with ESMTPSA id os1sm70116210pac.20.2014.01.04.17.20.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 17:20:56 -0800 (PST) References: <52C79610.3080201@pi.nu> Mime-Version: 1.0 (1.0) In-Reply-To: <52C79610.3080201@pi.nu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B554a) From: Sam Aldrin Date: Sun, 5 Jan 2014 06:50:45 +0530 To: Loa Andersson Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 01:21:07 -0000 I am not aware of any IPR's other than those which were already disclosed. Cheers Sam Sent from my iPhone > On Jan 4, 2014, at 10:33 AM, Loa Andersson wrote: >=20 > Working Group, >=20 > We have just started a working group last call on > draft-ietf-mpls-proxy-lsp-ping. we want to do an IPR poll in > parallel. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-proxy-lsp-ping? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are three IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The docu= ment will not advance to the next stage until a response has been > received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From cpignata@cisco.com Sun Jan 5 09:14:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFAC1AF05E for ; Sun, 5 Jan 2014 09:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 htf_nfORU2mJ for ; Sun, 5 Jan 2014 09:14:04 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 06EE21AF05F for ; Sun, 5 Jan 2014 09:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2950; q=dns/txt; s=iport; t=1388942037; x=1390151637; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0PunZ7QCtned1LWrPPwXwqTLq1I/68cZut+Yq0dDTRY=; b=GZJXPYRLOTKYDOX3NIe9rUnhwVAioeZeiDfEGC4SOxbFnIQDJsEIKtRS CtKt0JVKualpF9OkjJPIe7A3g+8+fM8XtKgmKnDKhlI3+6S1KjxWpDbDk Lt/IDkUjB4sxMGN7tXCkuVAbbyu5h0h8AvYT/59+COmVeNLeOhlL5R8lc o=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFWSyVKtJV2Z/2dsb2JhbABYgwuBDbkqgQwWdIIlAQEBAwF5BQsCAQgSBiMLMhcOAgQOBQ6HbgjDaBePDweDJIETBJAzgTGGM5IVgW+BPoIq X-IronPort-AV: E=Sophos;i="4.95,607,1384300800"; d="asc'?scan'208";a="292361137" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jan 2014 17:13:56 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s05HDtrW010230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Jan 2014 17:13:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Sun, 5 Jan 2014 11:13:55 -0600 From: "Carlos Pignataro (cpignata)" To: S Moonesamy Thread-Topic: Last Call: (Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry) to Proposed Standard Thread-Index: AQHPCgjN3AD3OuK030CVz7OglVxZIJp2w4eA Date: Sun, 5 Jan 2014 17:13:54 +0000 Message-ID: References: <20140102151605.2998.36196.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140104234315.0b5f4140@resistor.net> In-Reply-To: <6.2.5.6.2.20140104234315.0b5f4140@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.211.53] Content-Type: multipart/signed; boundary="Apple-Mail=_A0E24657-63E9-459A-9FCB-4A66F193D326"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-moving-iana-registries.all@tools.ietf.org" Subject: Re: [mpls] Last Call: (Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 17:14:06 -0000 --Apple-Mail=_A0E24657-63E9-459A-9FCB-4A66F193D326 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you for your review! Pleas see inline. On Jan 5, 2014, at 3:11 AM, S Moonesamy wrote: > Hello, > At 07:16 02-01-2014, The IESG wrote: >> The IESG has received a request from the Multiprotocol Label = Switching WG >> (mpls) to consider the following document: >> - 'Moving Generic Associated Channel (G-ACh) IANA Registries to a New >> Registry' >> as Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >=20 > =46rom the Introduction section: >=20 > 'RFC 5586 generalized the PW-ACH into the G-ACh. However, registries > and allocations of G-ACh namespaces had been distributed throughout > different registries. This document coalesces these into a new > "Generic Associated Channel (G-ACh) Parameters" registry in the > "Multiprotocol Label Switching Architecture (MPLS)" name space. = This > is an update to RFC RFC 5586 [RFC5586].' >=20 > The draft is about IANA actions. I don't see why the document is = being considered as a Proposed Standard. In Section 3 it is mentioned = that the updates RFC 5586 by renaming the Pseudowire Associated Channel = Types. That may be related to the IANA Considerations section in RFC = 5586. As there isn't any text in the draft suggesting that the = requirements in RFC 5586 are impacted by this update I conclude that = this draft does not change the technical part of RFC 5586. >=20 Two main reasons for progressing this draft as PS: 1. This document modifies IANA registries that have "Standards Action" = as the registration procedures, and consequently we need a Standards = Track RFC approved by the IESG. 2. As you note, this document also intends to update RFC 5586, PS, as = well as 6 other Std-Track RFCs. We are not dissecting which section of = RFC 5586 is PS and which one might not be. We consider that the IANA = actions *are* part of the requirements of RFC 5586, and integral part of = the protocol. Yes, no RFC 5586 procedures are impacted, only the IANA = actions. Thanks, -- Carlos. > Regards, > S. Moonesamy >=20 >=20 --Apple-Mail=_A0E24657-63E9-459A-9FCB-4A66F193D326 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLJktEACgkQtfDPGTp3USzj0ACfYnBp8AHxaHQ0m0GkjJ3Hg2RW JP4AoJjg1Q70xJYxBzndQs09myyWwUe2 =Y73R -----END PGP SIGNATURE----- --Apple-Mail=_A0E24657-63E9-459A-9FCB-4A66F193D326-- From ryoo@etri.re.kr Sun Jan 5 19:10:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3B01ADF64 for ; Sun, 5 Jan 2014 19:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.457 X-Spam-Level: X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 eWhnVNqVFAPJ for ; Sun, 5 Jan 2014 19:10:33 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0761ADF63 for ; Sun, 5 Jan 2014 19:10:32 -0800 (PST) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Jan 2014 12:10:16 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Mon, 6 Jan 2014 12:10:15 +0900 From: "Ryoo, Jeong-dong" To: Qin Wu , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] wglc on draft-ietf-mpls-smp-requirements Thread-Index: Ac76L8gPAbx7QpzERKO4dZ+zkusX+gQR6SgP Date: Mon, 6 Jan 2014 03:10:15 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AFE7B@SMTP2.etri.info> References: In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AFE7BSMTP2etriinfo_" MIME-Version: 1.0 Subject: Re: [mpls] wglc on draft-ietf-mpls-smp-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 03:10:36 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AFE7BSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UWluLCB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQoNClBsZWFzZSwgc2VlIGluIGxpbmVzIC4u Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb20gOiAiUWluIFd1IiA8YmlsbC53dUBodWF3ZWkuY29tPg0K U2VudCA6IDIwMTMtMTItMTYgMTY6MjU6NDkgKCArMDk6MDAgKQ0KVG8gOiBtcGxzQGlldGYub3Jn IDxtcGxzQGlldGYub3JnPiwgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgPG1wbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnPg0KQ2MgOg0KU3ViamVjdCA6IFttcGxzXSB3Z2xjIG9uIGRyYWZ0LWll dGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzDQoNCkhpLGFsbDoNCkkgaGF2ZSByZXZpZXdlZCBkcmFm dC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy4gSGVyZSBhcmUgYSBmZXcgY29tbWVudHMgSSBo YXZlIGJlbG93Lg0KMS4gQWJzdHJhY3Qgc2FpZDoNCuKAnA0KVGhpcyBkb2N1bWVudCBwcmVzZW50 cyB0aGUgYmFzaWMgbmV0d29yayBvYmplY3RpdmVzIGZvciB0aGUgYmVoYXZpb3INCm9mIHNoYXJl ZCBtZXNoIHByb3RlY3Rpb24gKFNNUCkgbm90IGJhc2VkIG9uIGNvbnRyb2wtcGxhbmUgc3VwcG9y dC4NCg0K4oCdDQpbUWluXTogQ2FuIFNNUCBiZWhhdmlvciBiZSBiYXNlZCBvbiBtYW5hZ2VtZW50 IHBsYW5lLCBpZiBub3QsIHdoeSBub3Qgc2F5IHRoZSBTTVAgYmVoYXZpb3IgaXMgYmFzZWQgb24g ZGF0YS1wbGFuZSBzdXBwb3J0IGRpcmVjdGx5Lg0KIFtKZW9uZy1kb25nXSBTTVAgaXMgYSBkYXRh IHBsYW5lIHByb3RvY29sLCB3aGljaCBtYXkgbmVlZCBzb21lIHN1cHBvcnRzIGZyb20gbWFuYWdl bWVudCBwbGFuZSBmb3IgY29uZmlndXJhdGlvbiwgYWxhcm0sIGV0Yy4NCg0KDQoyLiBTZWN0aW9u IDEsIFBhcmFncmFwaCB0d28gc2FpZDoNCuKAnA0KTVBMUyBwcm92aWRlcyBjb250cm9sLXBsYW5l IHRvb2xzIHRvIHN1cHBvcnQgdmFyaW91cyBzdXJ2aXZhYmlsaXR5DQogICBzY2hlbWVzIChFZGl0 b3IncyBub3RlIC0gYWRkIHJlZmVyZW5jZXMpLg0KDQrigJ0NCltRaW5dOiBXaGF0IHJlZmVyZW5j ZSBzaG91bGQgYmUgcHV0IGhlcmUgbmVlZHMgdG8gYmUgZml4ZWQuDQpbSmVvbmctZG9uZ10gWWVz LCBpdCBuZWVkcyB0byBiZSBmaXhlZC4gQSBjYW5kaWRhdGUgbWlnaHQgYmUgUkZDIDQ0MjYgLSBH TVBMUyBSZWNvdmVyeSBGdW5jdGlvbmFsIFNwZWNpZmljYXRpb24uDQoNCg0KMy4gU2VjdGlvbiAx LCBQYXJhZ3JhcGggdGhyZWUgc2FpZDoNCuKAnA0KV2hlbiBjb25zaWRlcmluZyBhIGZ1bGwtbWVz aCBuZXR3b3JrIGFuZCB0aGUgcHJvdGVjdGlvbiBvZiBkaWZmZXJlbnQNCiAgIHBhdGhzIHRoYXQg Y3Jpc3MtY3Jvc3MgdGhlIG1lc2gsIGl0IGlzIHBvc3NpYmxlIHRvIHByb3ZpZGUgYW4NCiAgIGFj Y2VwdGFibGUgbGV2ZWwgb2YgcHJvdGVjdGlvbiB3aGlsZSBjb25zZXJ2aW5nIHRoZSBhbW91bnQg b2YNCiAgIHByb3RlY3Rpb24gcmVzb3VyY2VzIG5lZWRlZCB0byBwcm90ZWN0IHRoZSBkaWZmZXJl bnQgZGF0YSBwYXRocy4NCg0K4oCdDQoNCltRaW5dOiBJdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hh dCBjcmlzcy1jcm9zcyBpcz8gV291bGQgaXQgYmUgZ29vZCB0byBhZGQgYSByZWZlcmVuY2UgZm9y IOKAnGNyaXNzLWNyb3Nz4oCdIGhlcmU/DQpbSmVvbmctZG9uZ10gICJjcmlzcy1jcm9zcyIgZnJv bSBPeGZvcmQgRGljdGlvbmFyaWVzOg0KICh2ZXJiICkgW3dpdGggb2JqZWN0XSBmb3JtIGEgcGF0 dGVybiBvZiBpbnRlcnNlY3RpbmcgbGluZXMgb3IgcGF0aHMgb24gKGEgcGxhY2UpOyB0aGUgZ3Jl ZW4gaGlsbCB3YXMgY3Jpc3MtY3Jvc3NlZCB3aXRoIGEgbmV0d29yayBvZiBzaGVlcCB0cmFja3Ms ICBbbm8gb2JqZWN0XTogdGhlIHNtYWxsZXIgc3RyZWV0cyBjcmlzcy1jcm9zc2VkIGluIGEgZ3Jp ZCBwYXR0ZXJuOyBtb3ZlIG9yIHRyYXZlbCBhcm91bmQgKGEgcGxhY2UpIGJ5IGdvaW5nIGJhY2sg YW5kIGZvcnRoIHJlcGVhdGVkbHk6IHRoZSBQcmVzaWRlbnQgY3Jpc3MtY3Jvc3NlZCBBbWVyaWNh DQoNCjQuU2VjdGlvbiA0LCBpdCBzYWlkOg0K4oCcDQoiSGFyZCBQcmVlbXB0aW9uIiByZXF1aXJl cyB0aGUgcHJvZ3JhbW1pbmcgb2Ygc2VsZWN0b3JzIGF0IHRoZSBpbmdyZXNzIG9mDQplYWNoIHNo YXJlZCBzZWdtZW50IHRvIGVuZm9yY2Ugd2hpY2ggYmFja3VwIHBhdGggaGFzIHRoZSBoaWdoZXN0 DQpwcmlvcml0eSB3aGVuIGNvbW1pdHRpbmcgcHJvdGVjdGlvbiByZXNvdXJjZXMsIHRoZSBvdGhl cnMgYmVpbmcNCnByZWVtcHRlZC4NCg0K4oCdDQoNCltRaW5dOiBJcyBzZWxlY3RvciBvbmUgb2Yg cHJvdGVjdGlvbiBlbmRwb2ludHM/IElzIHNlbGVjdG9yIGJlbG9uZyB0byBzaGFyZWQgc2VnbWVu dCBvciB1bnNoYXJlZA0KDQpwb3J0aW9ucyBvZiBzZWdtZW50PyBJcyBzZWxlY3RvciBpbiB0aGUg cHJvdGVjdGlvbiBwYXRoIG9yIHdvcmtpbmcgcGF0aD8NCkl0IGlzIGJldHRlciB0byBiZSBjbGVh ciBpbiB0aGUgdGV4dC4NCltKZW9uZy1kb25nXSBTZWxlY3RvciBpcyBpbiB0aGUgZW5kcG9pbnRz IG9mIHRoZSB3b3JraW5nIGFuZCBwcm90ZWN0aW9uIHBhdGhzIGFuZCBzZWxlY3RzIHRoZSB0cmFm ZmljIGZyb20gb25lIG9mIHRoZSBwYXRocy4gUGxlYXNlIHNlZSBSRkMgNDQyNywgd2hpY2ggaXMg bm9ybWF0aXZlbHkgcmVmZXJyZWQgYnkgdGhpcyBkb2N1bWVudC4NCg0KDQo1LiBTZWN0aW9uIDUu MSwgbGFzdCBwYXJhZ3JhcGggc2FpZDoNCuKAnA0KV2hhdCBpcyByZXF1aXJlZCBpcyBhIHByZWVt cHRpb24gbWVjaGFuaXNtIHRvDQogICBpbXBsZW1lbnQgYnVzaW5lc3MgcHJpb3JpdHkgd2hlbiBt dWx0aXBsZSBmYWlsdXJlIHNjZW5hcmlvcyBvY2N1ci4NCg0K4oCdDQpbUWluXTogSXMgcHJpb3Jp dHkgYnVzaW5lc3MgcmVsYXRlZCBvciBwb2xpY3kgZGVjaXNpb24gcmVsYXRlZD8gQ2FuIGJvdGgg cHJlZW1wdGlvbiBhbmQgcHJpb3JpdHkNCnBvbGljeSBkZWNpc2lvbiByZWxhdGVkPyBJdCBpcyBu b3QgY2xlYXIgdG8gbWUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBidXNpbmVzcyByZWxhdGVkIGFu ZCBwb2xpY3kNCmRlY2lzaW9uIHJlbGF0ZWQuIFdvdWxkIHlvdSBsaWtlIHRvIGNsYXJpZnkgYSBs aXR0bGUgYml0Pw0KW0plb25nLWRvbmddICBUaGUgYnVzaW5lc3MgcHJpb3JpdHkgY2FuIGJlIHRo b3VnaHQgYXMgdGhlIHByaW9yaXR5IGFzc2lnbmVkIHRvIGEgcGF0aCBhY2NvcmRpbmcgdG8gdGhl IHBvbGljeSBvZiBuZXR3b3JrIGFkbWluaXN0cmF0aW9uLg0KDQoNCjYuIFNlY3Rpb24gNS4yLCAx c3QgIHBhcmFncmFwaCBzYWlkOg0K4oCcDQpGb3IgdGhvc2UgbmV0d29ya3MsIGluIHBhcnRpY3Vs YXIgZm9yIG5ldHdvcmtzIHRoYXQgc3VwcG9ydCB0aGUgcmVxdWlyZW1lbnRzIGluDQpbUkZDNTY1 NF1bYW5kIGluIHBhcnRpY3VsYXIgc3VwcG9ydCBmb3IgcmVxdWlyZW1lbnQgNThdLCB0aGF0IHJl cXVpcmUNCnRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcywgaS5l LiBoYXJkIHByZWVtdGlvbiwNCnRoZSBmb2xsb3dpbmcgYmVoYXZpb3IgU0hPVUxEIGJlIHN1cHBv cnRlZDoNCuKAnQ0KW1Fpbl06IHMvcHJlZW10aW9uL3ByZWVtcHRpb24NCltKZW9uZy1kb25nXSBU aGlzIHNob3VsZCBiZSBmaXhlZC4NCg0KDQo3LlNlY3Rpb24gNS4yLCBsYXN0IGJ1bGxldCBzYWlk Og0K4oCcDQpEdXJpbmcgcHJlZW1wdGlvbiwgaWYgdGhlcmUgaXMgYW4gb3ZlciBzdWJzY3JpcHRp b24gb2YgcmVzb3VyY2VzDQpwcm90ZWN0ZWQgdHJhZmZpYyBTSE9VTEQgYmUgdHJlYXRlZCBhcyBk ZWZpbmVkIGluIFtSRkM1NzEyXSBvcg0KW1JGQzMyMDldDQrigJ0NCltRaW5dcy9bUkZDMzIwOV0v W1JGQzMyMDldLg0KDQpbUWluXTogSXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoeSBzb2Z0IHByZWVt cHRpb24gYmVoYXZpb3IgZGVmaW5lZA0KaW4gUkZDNTcxMiBzaG91bGQgYmUgYXBwbGllZCB0byBo YXJkIHByZWVtcHRpb24gcGFydCBvZiBzZWN0aW9uDQo1LjIgZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQ/DQppbg0KSXMgdGhlcmUgYW55IGNvbW1vbiBiZWhhdmlvciBiZXR3ZWVuIHNvZnQgcHJl ZW1wdGlvbiBhbmQgaGFyZCBwcmVlbXB0aW9uPw0KSXQgaXMgYmV0dGVyIHRvIGJlIGNsZWFyIGFi b3V0IHRoaXMgaW4gdGhlIHRleHQuDQpbSmVvbmctZG9uZ10gVGhlIGxhc3QgYnVsbGV0IGFwcGxp ZXMgZHVyaW5nIHByZWVtcHRpb24uIEl0IG1lYW5zIHRoYXQgd2hpbGUgdGhlIHByZWVtcHRpb24g YWN0aW9uIGlzIGluIHByb2dyZXNzLCB0aGUgdHJhZmZpYyBzaG91bGQgYmUgIHRyZWF0ZWQgYXMg c3BlY2lmaWVkIGluIHRoZSBsYXN0IGJ1bGxldC4NCg0KDQo4LlNlY3Rpb24gNS41LCAxc3QgcGFy YWdyYXBoIHNhaWQ6DQrigJwNCiAgIFByb3RlY3Rpb24gc3dpdGNoaW5nIHRpbWUgcmVmZXJzIHRv IHRoZSB0cmFuc2ZlciB0aW1lIChUdCkgZGVmaW5lZCBpbg0KICAgW0cuODA4LjFdIGFuZCByZWNv dmVyeSBzd2l0Y2hpbmcgdGltZSBkZWZpbmVkIGluIFtSRkM0NDI3XSwgYW5kIGlzDQogICBkZWZp bmVkIGFzIHRoZSBpbnRlcnZhbCBhZnRlciBhIHN3aXRjaGluZyB0cmlnZ2VyIGlzIGlkZW50aWZp ZWQgdW50aWwNCiAgIHRoZSB0cmFmZmljIGJlZ2lucyB0byBiZSB0cmFuc21pdHRlZCBvbiB0aGUg cHJvdGVjdGlvbiBwYXRoLg0KDQrigJ0NCg0KW1Fpbl06DQpXaGF0IHRoZSByZWxhdGlvbnNoaXAg YmV0d2VlbiDigJxwcm90ZWN0aW9uIHN3aXRjaGluZyB0aW1l4oCdDQphbmQg4oCcdHJhbnNmZXIg dGltZeKAnSBvciDigJxyZWNvdmVyeSBzd2l0Y2hpbmcgdGltZeKAnQ0KQ2FuIEkgcGFyc2UgdGhp cyByZWxhdGlvbiBhczoNClByb3RlY3Rpb24gc3dpdGNoaW5nIHRpbWUgPSB0aGUgdHJhbnNmZXIg dGltZSArIHJlY292ZXJ5IHN3aXRjaGluZyB0aW1lPw0KW0plb25nLWRvbmddIHByb3RlY3Rpb24g c3dpdGNoaW5nIHRpbWUgPSB0cmFuc2ZlciB0aW1lIGluIEcuODA4LjEgPSByZWNvdmVyeSBzd2l0 Y2hpbmcgdGltZSBpbiBSRkM0NDI3DQoNCg0KOS5TZWN0aW9uIDUuNSwgMXN0IHBhcmFncmFwaCBz YWlkOg0K4oCcDQogICBJbiBvcmRlciB0byBwcmV2ZW50IG11bHRpcGxlIHN3aXRjaGluZyBhY3Rp b25zIGZvciBhIHNpbmdsZSBzd2l0Y2hpbmcNCiAgIHRyaWdnZXIsIFNNUCBTSE9VTEQgYmUgY29u dHJvbGxlZCBieSBhIGhvbGQtb2ZmIHRpbWVyIHRoYXQgd291bGQNCiAgIGFsbG93IGxvd2VyIGxl dmVsIG1lY2hhbmlzbXMgdG8gY29tcGxldGUgdGhlaXIgc3dpdGNoaW5nIGFjdGlvbnMNCiAgIGJl Zm9yZSBpbnZva2luZyBTTVAgcHJvdGVjdGlvbiBhY3Rpb25zLg0KDQrigJ0NCltRaW5dOldoeSBh cmUgdGhlcmUgbXVsdGlwbGUgc3dpdGNoaW5nIGFjdGlvbnMgZm9yIGEgc2luZ2xlIHN3aXRjaGlu Zw0KdHJpZ2dlcj8gSXNu4oCZdCBvbmUgc3dpdGNoaW5nIHRyaWdnZXIgY29ycmVzcG9uZGluZyB0 byBvbmUgc3dpdGNoaW5nIGFjdGlvbj8NCkNhbiB5b3UgZ2l2ZSBhbiBleGFtcGxlIGZvciB0aGF0 Pw0KW0plb25nLWRvbmddIEEgc2luZ2xlIGZhaWx1cmUgY2FuIHRyaWdnZXIgdGhlIHByb3RlY3Rp b24gc3dpdGNoaW5nIGFjdGlvbnMgYm90aCBpbiBzZXJ2ZXIgbGF5ZXIgKE9UTiBmb3IgZXhhbXBs ZSkgYW5kIGNsaWVudCBsYXllciAoTVBMUy1UUCBmb3IgZXhhbXBsZSkuDQoNCjEwLlNlY3Rpb24g NS41LCAxc3QgcGFyYWdyYXBoIHNhaWQ6DQrigJwNCiAgIEluIG9yZGVyIHRvIHByZXZlbnQgbXVs dGlwbGUgc3dpdGNoaW5nIGFjdGlvbnMgZm9yIGEgc2luZ2xlIHN3aXRjaGluZw0KICAgdHJpZ2dl ciwgU01QIFNIT1VMRCBiZSBjb250cm9sbGVkIGJ5IGEgaG9sZC1vZmYgdGltZXIgdGhhdCB3b3Vs ZA0KICAgYWxsb3cgbG93ZXIgbGV2ZWwgbWVjaGFuaXNtcyB0byBjb21wbGV0ZSB0aGVpciBzd2l0 Y2hpbmcgYWN0aW9ucw0KICAgYmVmb3JlIGludm9raW5nIFNNUCBwcm90ZWN0aW9uIGFjdGlvbnMu DQoNCuKAnQ0KDQpbUWluXTpXaGF0IGxvd2VyIGxldmVsIG1lYW5zPyBXaGF0IHRoZSBkaWZmZXJl bmNlIGJldHdlZW4gbG93IGxldmVsDQphbmQgaGlnaCBsZXZlbD8gRG9lcyB0aGlzIHJlbGF0ZSB0 byBsb3dlciBwcmlvcml0eSBvciBoaWdoIHByaW9yaXR5Pw0KW0plb25nLWRvbmddIFNlZSB0aGUg YWJvdmUgYW5zd2VyLiAgRm9yIGJldHRlciBjbGFyaWZpY2F0aW9uLCB3ZSBjYW4gcmV3cml0ZSBp dCBzb21ldGhpbmcgbGlrZToNCiAgICJJbiBvcmRlciB0byBwcmV2ZW50IG11bHRpcGxlIHN3aXRj aGluZyBhY3Rpb25zIGZvciBhIHNpbmdsZSBzd2l0Y2hpbmcNCiAgIHRyaWdnZXIgd2hlbiB0aGVy ZSBhcmUgbXVsdGlwbGUgbGF5ZXJzIG9mIG5ldHdvcmtzLA0KICAgU01QIFNIT1VMRCBiZSBjb250 cm9sbGVkIGJ5IGEgaG9sZC1vZmYgdGltZXIgdGhhdCB3b3VsZA0KICAgYWxsb3cgbG93ZXIgbGF5 ZXIgbWVjaGFuaXNtcyB0byBjb21wbGV0ZSB0aGVpciBzd2l0Y2hpbmcgYWN0aW9ucw0KICAgYmVm b3JlIGludm9raW5nIFNNUCBwcm90ZWN0aW9uIGFjdGlvbnMuIg0KDQoNCk9uIFR1ZSwgRGVjIDEw LCAyMDEzIGF0IDg6MzcgQU0sIExvYSBBbmRlcnNzb24gPGxvYSBhdCBwaS5udT4gd3JvdGU6DQo+ IFdvcmtpbmcgR3JvdXAsDQo+DQo+DQo+IHRoaXMgaXMgdG8gc3RhcnQgYSAyIHdlZWsgd29ya2lu ZyBncm91cCBsYXN0IGNhbGwgb24NCj4gZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMt MDIuDQo+DQo+IFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBzZW5kIGNvbW1lbnRzIHRv IHRoZSBNUExTIFdHDQo+IG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZykgLg0KPg0KPiBU aGVyZSBhcmUgbm8gSVBSIGNsYWltcyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+DQo+IEFsbCB0 aGUgYXV0aG9ycyBoYXZlIHN0YXRlZCBvbiB0aGUgTVBMUyB3ZyBtYWlsaW5nIGxpc3QgdGhhdCB0 aGV5DQo+IGFyZSB1bmF3YXJlIG9mIGFueSBJUFJzIHRoYXQgcmVsYXRlIHRvIHRoaXMgZG9jdW1l bnQuDQo+DQo+IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIE1vbmRheSBEZWNlbWJl ciAyNyAtIDIwMTMuDQo+DQo+IFllcyAtIHRoYXQgaXMgaXMgaW4gdGhlIG1pZGRsZSBvZiB0aGUg SG9saWRheSBzZWFzb24sIGJ1dCBhdCBsZWFzdA0KPiBvbmUgd2cgY2hhaXIgd2lsbCBiZSB3b3Jr aW5nIHBhcnRseSBiZXR3ZWVuIFhtYXMgYW5kIE5ldyBZZWFyIGFuZCBiZQ0KPiBhYmxlIHRvIGV2 YWx1YXRlIG5leHQgc3RlcHMuIFdlIGNvdW50IG9uIG1vc3QgcmV2aWV3cyB0YWtpbmcgcGxhY2UN Cj4gaW4gdGhlIGFsbW9zdCB0d28gd2Vla3MgYmVmb3JlIFhtYXMuDQo+DQo+IC9Mb2ENCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AFE7BSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48Zm9udCBjb2xvcj0iIzAwMDBmZiI+UWluLCB0 aGFua3MgZm9yIHlvdXIgY29tbWVudHMuPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiPjxmb250IGNvbG9yPSIjMDAwMGZmIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGZvbnQgY29sb3I9IiMwMDAwZmYiPlBsZWFz ZSwgc2VlIGluIGxpbmVzIC4uLjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0Ij48Zm9udCBjb2xvcj0iIzAwMDBmZiI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdiBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxmb250IGNvbG9yPSIjMDAwMGZmIj5CZXN0IHJlZ2Fy ZHMsPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxmb250IGNv bG9yPSIjMDAwMGZmIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCI+PGZvbnQgY29sb3I9IiMwMDAwZmYiPkplb25nLWRvbmc8L2ZvbnQ+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0KPGJyPg0KJm5ic3A7PC9kaXY+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgaWQ9Ik1haWxTaWduIj48YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGI+RnJvbSA6IDwvYj4mcXVvdDtR aW4gV3UmcXVvdDsgJmx0O2JpbGwud3VAaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5TZW50IDogPC9i PjIwMTMtMTItMTYgMTY6MjU6NDkgKCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5tcGxz QGlldGYub3JnICZsdDttcGxzQGlldGYub3JnJmd0OywgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmcgJmx0O21wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjIDogPC9iPjxi cj4NCjxiPlN1YmplY3QgOiA8L2I+W21wbHNdIHdnbGMgb24gZHJhZnQtaWV0Zi1tcGxzLXNtcC1y ZXF1aXJlbWVudHM8YnI+DQo8YnI+DQo8L2Rpdj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlIGlkPSJk eW5Db20iIHR5cGU9InRleHQvY3NzIj48L3N0eWxlPjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3Jp cHQiPjwhLS0KZnVuY3Rpb24gbXNvQ29tbWVudFNob3coYW5jaG9yX2lkLCBjb21faWQpCnsKCWlm KG1zb0Jyb3dzZXJDaGVjaygpKSAKCQl7CgkJYyA9IGRvY3VtZW50LmFsbChjb21faWQpOwoJCWEg PSBkb2N1bWVudC5hbGwoYW5jaG9yX2lkKTsKCQlpZiAobnVsbCAhPSBjICYmIG51bGwgPT0gYy5s ZW5ndGggJiYgbnVsbCAhPSBhICYmIG51bGwgPT0gYS5sZW5ndGgpCgkJCXsKCQkJdmFyIGN3ID0g Yy5vZmZzZXRXaWR0aDsKCQkJdmFyIGNoID0gYy5vZmZzZXRIZWlnaHQ7CgkJCXZhciBhdyA9IGEu b2Zmc2V0V2lkdGg7CgkJCXZhciBhaCA9IGEub2Zmc2V0SGVpZ2h0OwoJCQl2YXIgeCAgPSBhLm9m ZnNldExlZnQ7CgkJCXZhciB5ICA9IGEub2Zmc2V0VG9wOwoJCQl2YXIgZWwgPSBhOwoJCQl3aGls ZSAoZWwudGFnTmFtZSAhPSAiQk9EWSIpIAoJCQkJewoJCQkJZWwgPSBlbC5vZmZzZXRQYXJlbnQ7 CgkJCQl4ID0geCArIGVsLm9mZnNldExlZnQ7CgkJCQl5ID0geSArIGVsLm9mZnNldFRvcDsKCQkJ CX0KCQkJdmFyIGJ3ID0gZG9jdW1lbnQuYm9keS5jbGllbnRXaWR0aDsKCQkJdmFyIGJoID0gZG9j dW1lbnQuYm9keS5jbGllbnRIZWlnaHQ7CgkJCXZhciBic2wgPSBkb2N1bWVudC5ib2R5LnNjcm9s bExlZnQ7CgkJCXZhciBic3QgPSBkb2N1bWVudC5ib2R5LnNjcm9sbFRvcDsKCQkJaWYgKHggKyBj dyArIGFoIC8gMiA+IGJ3ICsgYnNsICYmIHggKyBhdyAtIGFoIC8gMiAtIGN3ID49IGJzbCApIAoJ CQkJeyBjLnN0eWxlLmxlZnQgPSB4ICsgYXcgLSBhaCAvIDIgLSBjdzsgfQoJCQllbHNlIAoJCQkJ eyBjLnN0eWxlLmxlZnQgPSB4ICsgYWggLyAyOyB9CgkJCWlmICh5ICsgY2ggKyBhaCAvIDIgPiBi aCArIGJzdCAmJiB5ICsgYWggLyAyIC0gY2ggPj0gYnN0ICkgCgkJCQl7IGMuc3R5bGUudG9wID0g eSArIGFoIC8gMiAtIGNoOyB9CgkJCWVsc2UgCgkJCQl7IGMuc3R5bGUudG9wID0geSArIGFoIC8g MjsgfQoJCQljLnN0eWxlLnZpc2liaWxpdHkgPSAidmlzaWJsZSI7Cn0JfQl9CmZ1bmN0aW9uIG1z b0NvbW1lbnRIaWRlKGNvbV9pZCkgCnsKCWlmKG1zb0Jyb3dzZXJDaGVjaygpKQoJCXsKCQljID0g ZG9jdW1lbnQuYWxsKGNvbV9pZCk7CgkJaWYgKG51bGwgIT0gYyAmJiBudWxsID09IGMubGVuZ3Ro KQoJCXsKCQljLnN0eWxlLnZpc2liaWxpdHkgPSAiaGlkZGVuIjsKCQljLnN0eWxlLmxlZnQgPSAt MTAwMDsKCQljLnN0eWxlLnRvcCA9IC0xMDAwOwoJCX0gfSAKfQpmdW5jdGlvbiBtc29Ccm93c2Vy Q2hlY2soKQp7CgltcyA9IG5hdmlnYXRvci5hcHBWZXJzaW9uLmluZGV4T2YoIk1TSUUiKTsKCXZl cnMgPSBuYXZpZ2F0b3IuYXBwVmVyc2lvbi5zdWJzdHJpbmcobXMgKyA1LCBtcyArIDYpOwoJaWU0 ID0gKG1zID4gMCkgJiYgKHBhcnNlSW50KHZlcnMpID49IDQpOwoJcmV0dXJuIGllNDsKfQppZiAo bXNvQnJvd3NlckNoZWNrKCkpCnsKCWRvY3VtZW50LnN0eWxlU2hlZXRzLmR5bkNvbS5hZGRSdWxl KCIubXNvY29tYW5jaG9yIiwiYmFja2dyb3VuZDogaW5mb2JhY2tncm91bmQiKTsKCWRvY3VtZW50 LnN0eWxlU2hlZXRzLmR5bkNvbS5hZGRSdWxlKCIubXNvY29tb2ZmIiwiZGlzcGxheTogbm9uZSIp OwoJZG9jdW1lbnQuc3R5bGVTaGVldHMuZHluQ29tLmFkZFJ1bGUoIi5tc29jb210eHQiLCJ2aXNp YmlsaXR5OiBoaWRkZW4iKTsKCWRvY3VtZW50LnN0eWxlU2hlZXRzLmR5bkNvbS5hZGRSdWxlKCIu bXNvY29tdHh0IiwicG9zaXRpb246IGFic29sdXRlIik7Cglkb2N1bWVudC5zdHlsZVNoZWV0cy5k eW5Db20uYWRkUnVsZSgiLm1zb2NvbXR4dCIsInRvcDogLTEwMDAiKTsKCWRvY3VtZW50LnN0eWxl U2hlZXRzLmR5bkNvbS5hZGRSdWxlKCIubXNvY29tdHh0IiwibGVmdDogLTEwMDAiKTsKCWRvY3Vt ZW50LnN0eWxlU2hlZXRzLmR5bkNvbS5hZGRSdWxlKCIubXNvY29tdHh0Iiwid2lkdGg6IDMzJSIp OwoJZG9jdW1lbnQuc3R5bGVTaGVldHMuZHluQ29tLmFkZFJ1bGUoIi5tc29jb210eHQiLCJiYWNr Z3JvdW5kOiBpbmZvYmFja2dyb3VuZCIpOwoJZG9jdW1lbnQuc3R5bGVTaGVldHMuZHluQ29tLmFk ZFJ1bGUoIi5tc29jb210eHQiLCJjb2xvcjogaW5mb3RleHQiKTsKCWRvY3VtZW50LnN0eWxlU2hl ZXRzLmR5bkNvbS5hZGRSdWxlKCIubXNvY29tdHh0IiwiYm9yZGVyLXRvcDogMXB0IHNvbGlkIHRo cmVlZGxpZ2h0c2hhZG93Iik7Cglkb2N1bWVudC5zdHlsZVNoZWV0cy5keW5Db20uYWRkUnVsZSgi Lm1zb2NvbXR4dCIsImJvcmRlci1yaWdodDogMnB0IHNvbGlkIHRocmVlZHNoYWRvdyIpOwoJZG9j dW1lbnQuc3R5bGVTaGVldHMuZHluQ29tLmFkZFJ1bGUoIi5tc29jb210eHQiLCJib3JkZXItYm90 dG9tOiAycHQgc29saWQgdGhyZWVkc2hhZG93Iik7Cglkb2N1bWVudC5zdHlsZVNoZWV0cy5keW5D b20uYWRkUnVsZSgiLm1zb2NvbXR4dCIsImJvcmRlci1sZWZ0OiAxcHQgc29saWQgdGhyZWVkbGln aHRzaGFkb3ciKTsKCWRvY3VtZW50LnN0eWxlU2hlZXRzLmR5bkNvbS5hZGRSdWxlKCIubXNvY29t dHh0IiwicGFkZGluZzogM3B0IDNwdCAzcHQgM3B0Iik7Cglkb2N1bWVudC5zdHlsZVNoZWV0cy5k eW5Db20uYWRkUnVsZSgiLm1zb2NvbXR4dCIsInotaW5kZXg6IDEwMCIpOwp9Ci8vIC0tPjwvc2Ny aXB0PjxzdHlsZT5AZm9udC1mYWNlIHsKCWZvbnQtZmFtaWx5OiBTaW1TdW47Cn0KQGZvbnQtZmFj ZSB7Cglmb250LWZhbWlseTogQ2FtYnJpYSBNYXRoOwp9CkBmb250LWZhY2UgewoJZm9udC1mYW1p bHk6IENhbGlicmk7Cn0KQGZvbnQtZmFjZSB7Cglmb250LWZhbWlseTogU2ltU3VuOwp9CkBwYWdl IFdvcmRTZWN0aW9uMSB7c2l6ZTogNjEyLjBwdCA3OTIuMHB0OyBtYXJnaW46IDcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDsgfQpQLk1zb05vcm1hbCB7CglNQVJHSU46IDBjbSAwY20gMHB0OyBG T05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgRk9OVC1TSVpFOiAxMXB0Cn0KTEku TXNvTm9ybWFsIHsKCU1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOyBGT05ULVNJWkU6IDExcHQKfQpESVYuTXNvTm9ybWFsIHsKCU1BUkdJTjog MGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBGT05ULVNJ WkU6IDExcHQKfQpQLk1zb0NvbW1lbnRUZXh0IHsKCU1BUkdJTjogMGNtIDBjbSAwcHQ7IExBWU9V VC1HUklELU1PREU6IGNoYXI7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi OyBGT05ULVNJWkU6IDEwcHQ7IG1zby1zdHlsZS1saW5rOiAi5om55rOo5paH5a2XQ2hhciIKfQpM SS5Nc29Db21tZW50VGV4dCB7CglNQVJHSU46IDBjbSAwY20gMHB0OyBMQVlPVVQtR1JJRC1NT0RF OiBjaGFyOyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgRk9OVC1TSVpF OiAxMHB0OyBtc28tc3R5bGUtbGluazogIuaJueazqOaWh+Wtl0NoYXIiCn0KRElWLk1zb0NvbW1l bnRUZXh0IHsKCU1BUkdJTjogMGNtIDBjbSAwcHQ7IExBWU9VVC1HUklELU1PREU6IGNoYXI7IEZP TlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOyBGT05ULVNJWkU6IDEwcHQ7IG1z by1zdHlsZS1saW5rOiAi5om55rOo5paH5a2XQ2hhciIKfQpBOmxpbmsgewoJQ09MT1I6IGJsdWU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5Cn0KU1BB Ti5Nc29IeXBlcmxpbmsgewoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5l OyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5Cn0KQTp2aXNpdGVkIHsKCUNPTE9SOiBwdXJwbGU7IFRF WFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5Cn0KU1BBTi5N c29IeXBlcmxpbmtGb2xsb3dlZCB7CglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVu ZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQp9ClBSRSB7CglNQVJHSU46IDBjbSAwY20g MHB0OyBGT05ULUZBTUlMWTogIkNvdXJpZXIgTmV3IjsgRk9OVC1TSVpFOiAxMHB0OyBtc28tc3R5 bGUtbGluazogIkhUTUwgXDk4ODQgXDhCQkUg5qC85byPQ2hhciI7IG1zby1zdHlsZS1wcmlvcml0 eTogOTkKfQpQLk1zb0FjZXRhdGUgewoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6 IFNpbVN1bjsgRk9OVC1TSVpFOiA5cHQ7IG1zby1zdHlsZS1saW5rOiAi5om55rOoXDY4NDYg5paH 5pysQ2hhciI7IG1zby1zdHlsZS1wcmlvcml0eTogOTkKfQpMSS5Nc29BY2V0YXRlIHsKCU1BUkdJ TjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW47IEZPTlQtU0laRTogOXB0OyBtc28t c3R5bGUtbGluazogIuaJueazqFw2ODQ2IOaWh+acrENoYXIiOyBtc28tc3R5bGUtcHJpb3JpdHk6 IDk5Cn0KRElWLk1zb0FjZXRhdGUgewoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6 IFNpbVN1bjsgRk9OVC1TSVpFOiA5cHQ7IG1zby1zdHlsZS1saW5rOiAi5om55rOoXDY4NDYg5paH 5pysQ2hhciI7IG1zby1zdHlsZS1wcmlvcml0eTogOTkKfQpQLk1zb0xpc3RQYXJhZ3JhcGggewoJ TUFSR0lOOiAwY20gMGNtIDBwdCAzNnB0OyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNl cmlmIjsgRk9OVC1TSVpFOiAxMXB0OyBtc28tc3R5bGUtcHJpb3JpdHk6IDM0Cn0KTEkuTXNvTGlz dFBhcmFncmFwaCB7CglNQVJHSU46IDBjbSAwY20gMHB0IDM2cHQ7IEZPTlQtRkFNSUxZOiAiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOyBGT05ULVNJWkU6IDExcHQ7IG1zby1zdHlsZS1wcmlvcml0eTog MzQKfQpESVYuTXNvTGlzdFBhcmFncmFwaCB7CglNQVJHSU46IDBjbSAwY20gMHB0IDM2cHQ7IEZP TlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBGT05ULVNJWkU6IDExcHQ7IG1zby1z dHlsZS1wcmlvcml0eTogMzQKfQpTUEFOLkhUTUxDaGFyIHsKCUZPTlQtRkFNSUxZOiAiQ291cmll ciBOZXciOyBtc28tc3R5bGUtbGluazogIkhUTUwgXDk4ODQgXDhCQkUg5qC85byPIjsgbXNvLXN0 eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLW5hbWU6ICJIVE1MIFw5ODg0IFw4QkJFIOagvOW8 j0NoYXIiCn0KU1BBTi5DaGFyIHsKCUZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiOyBtc28tc3R5bGUtbGluazog5om55rOo5paH5a2XOyBtc28tc3R5bGUtbmFtZTogIuaJueaz qOaWh+Wtl0NoYXIiCn0KU1BBTi5DaGFyMCB7CglGT05ULUZBTUlMWTogU2ltU3VuOyBtc28tc3R5 bGUtbGluazog5om55rOoXDY4NDYg5paH5pysOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5OyBtc28t c3R5bGUtbmFtZTogIuaJueazqFw2ODQ2IOaWh+acrENoYXIiCn0KU1BBTi5FbWFpbFN0eWxlMjUg ewoJRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IENPTE9SOiB3aW5kb3d0ZXh0 OyBtc28tc3R5bGUtdHlwZTogcGVyc29uYWwtY29tcG9zZQp9Ci5Nc29DaHBEZWZhdWx0IHsKCUZP TlQtU0laRTogMTBwdDsgbXNvLXN0eWxlLXR5cGU6IGV4cG9ydC1vbmx5Cn0KRElWLldvcmRTZWN0 aW9uMSB7CglwYWdlOiBXb3JkU2VjdGlvbjEKfQo8L3N0eWxlPg0KPGRpdiBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiIGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQi PkhpLGFsbDo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPkkgaGF2ZSByZXZpZXdl ZCBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy4gSGVyZSBhcmUgYSBmZXcgY29tbWVu dHMgSSBoYXZlIGJlbG93Ljwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+MS4gQWJz dHJhY3Qgc2FpZDo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPuKAnDwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3Vy aWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+VGhpcyBkb2N1bWVudCBwcmVzZW50cyB0aGUgYmFz aWMgbmV0d29yayBvYmplY3RpdmVzIGZvciB0aGUgYmVoYXZpb3I8L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBG T05ULVNJWkU6IDEwcHQiPm9mIHNoYXJlZCBtZXNoIHByb3RlY3Rpb24gKFNNUCkgbm90IGJhc2Vk IG9uIGNvbnRyb2wtcGxhbmUgc3VwcG9ydC48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPuKAnTwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7 IEZPTlQtU0laRTogMTBwdCI+W1Fpbl06PC9zcGFuPiBDYW4gU01QIGJlaGF2aW9yIGJlIGJhc2Vk IG9uIG1hbmFnZW1lbnQgcGxhbmUsIGlmIG5vdCwgd2h5IG5vdCBzYXkgdGhlIFNNUCBiZWhhdmlv ciBpcyBiYXNlZCBvbiBkYXRhLXBsYW5lIHN1cHBvcnQgZGlyZWN0bHkuDQo8P3htbDpuYW1lc3Bh Y2UgcHJlZml4ID0gbyBucyA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZp Y2UiIC8+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+PGZvbnQg Y29sb3I9IiMwMDAwZmYiPiZuYnNwO1tKZW9uZy1kb25nXSBTTVAgaXMgYSBkYXRhIHBsYW5lIHBy b3RvY29sLCB3aGljaCBtYXkgbmVlZCZuYnNwO3NvbWUgc3VwcG9ydHMgZnJvbSBtYW5hZ2VtZW50 IHBsYW5lIGZvciBjb25maWd1cmF0aW9uLCZuYnNwO2FsYXJtLCBldGMuJm5ic3A7DQo8L2ZvbnQ+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286cD4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPjwvbzpwPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjIuIFNlY3Rpb24gMSwgUGFyYWdyYXBoIHR3byBzYWlkOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTog MTBwdCI+TVBMUyBwcm92aWRlcyBjb250cm9sLXBsYW5lIHRvb2xzIHRvIHN1cHBvcnQgdmFyaW91 cyBzdXJ2aXZhYmlsaXR5PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDsm bmJzcDsgc2NoZW1lcyAoRWRpdG9yJ3Mgbm90ZSAtIGFkZCByZWZlcmVuY2VzKS4mbmJzcDsNCjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+W1Fpbl06IFdoYXQgcmVmZXJlbmNlIHNob3VsZCBiZSBwdXQgaGVyZSBuZWVkcyB0byBiZSBm aXhlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+PGZvbnQgY29s b3I9IiMwMDAwZmYiPltKZW9uZy1kb25nXSBZZXMsIGl0IG5lZWRzIHRvIGJlIGZpeGVkLiBBIGNh bmRpZGF0ZSBtaWdodCBiZSBSRkMgNDQyNiAtIEdNUExTIFJlY292ZXJ5IEZ1bmN0aW9uYWwgU3Bl Y2lmaWNhdGlvbi48L2ZvbnQ+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48 L286cD4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPjwvbzpwPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuIFNlY3Rpb24gMSwgUGFyYWdyYXBoIHRocmVlIHNh aWQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij5XaGVuIGNvbnNpZGVyaW5nIGEgZnVsbC1tZXNoIG5l dHdvcmsgYW5kIHRoZSBwcm90ZWN0aW9uIG9mIGRpZmZlcmVudDwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZP TlQtU0laRTogMTBwdCI+Jm5ic3A7Jm5ic3A7IHBhdGhzIHRoYXQgY3Jpc3MtY3Jvc3MgdGhlIG1l c2gsIGl0IGlzIHBvc3NpYmxlIHRvIHByb3ZpZGUgYW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJ WkU6IDEwcHQiPiZuYnNwOyZuYnNwOyBhY2NlcHRhYmxlIGxldmVsIG9mIHByb3RlY3Rpb24gd2hp bGUgY29uc2VydmluZyB0aGUgYW1vdW50IG9mPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAx MHB0Ij4mbmJzcDsmbmJzcDsgcHJvdGVjdGlvbiByZXNvdXJjZXMgbmVlZGVkIHRvIHByb3RlY3Qg dGhlIGRpZmZlcmVudCBkYXRhIHBhdGhzLiZuYnNwOw0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCd PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltRaW5dOiBJdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hh dCA8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPg0KY3Jpc3MtY3Jvc3M8 L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4gaXM/IFdvdWxk IGl0IGJlIGdvb2QgdG8gYWRkIGEgcmVmZXJlbmNlIGZvciDigJw8L3NwYW4+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj5jcmlzcy1jcm9zczwvc3Bhbj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPuKAnSBoZXJlPzwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+W0plb25nLWRvbmddJm5ic3A7 ICZxdW90O2NyaXNzLWNyb3NzJnF1b3Q7IGZyb20gT3hmb3JkIERpY3Rpb25hcmllczo8L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgY29sb3I9IiMwMDAwZmYiPiZuYnNwOyh2 ZXJiICkgW3dpdGggb2JqZWN0XSBmb3JtIGEgcGF0dGVybiBvZiBpbnRlcnNlY3RpbmcgbGluZXMg b3IgcGF0aHMgb24gKGEgcGxhY2UpOyB0aGUgZ3JlZW4gaGlsbCB3YXMgY3Jpc3MtY3Jvc3NlZCB3 aXRoIGEgbmV0d29yayBvZiBzaGVlcCB0cmFja3MsJm5ic3A7Jm5ic3A7W25vIG9iamVjdF06IHRo ZSBzbWFsbGVyIHN0cmVldHMgY3Jpc3MtY3Jvc3NlZCBpbiBhIGdyaWQgcGF0dGVybjsNCiBtb3Zl IG9yIHRyYXZlbCBhcm91bmQgKGEgcGxhY2UpIGJ5IGdvaW5nIGJhY2sgYW5kIGZvcnRoIHJlcGVh dGVkbHk6IHRoZSBQcmVzaWRlbnQgY3Jpc3MtY3Jvc3NlZCBBbWVyaWNhPGJyPg0KPC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IGZhY2U9IiI+PC9mb250PiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIg TmV3JyI+NC5TZWN0aW9uIDQsIGl0IHNhaWQ6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+4oCcPC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij4mcXVvdDtIYXJkIFByZWVtcHRpb24mcXVvdDsgcmVx dWlyZXMgdGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9ycyBhdCB0aGUgaW5ncmVzcyBvZjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD b3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+ZWFjaCBzaGFyZWQgc2VnbWVudCB0byBlbmZv cmNlIHdoaWNoIGJhY2t1cCBwYXRoIGhhcyB0aGUgaGlnaGVzdDwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZP TlQtU0laRTogMTBwdCI+cHJpb3JpdHkgd2hlbiBjb21taXR0aW5nIHByb3RlY3Rpb24gcmVzb3Vy Y2VzLCB0aGUgb3RoZXJzIGJlaW5nPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij5w cmVlbXB0ZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPg0KPC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+4oCdPC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Db21tZW50VGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291 cmllciBOZXcnIj5bUWluXTo8L3NwYW4+IElzIHNlbGVjdG9yIG9uZSBvZiBwcm90ZWN0aW9uIGVu ZHBvaW50cz8gSXMgc2VsZWN0b3IgYmVsb25nIHRvIHNoYXJlZCBzZWdtZW50IG9yDQo8c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPnVuc2hhcmVkPC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Db21tZW50VGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll ciBOZXcnIj5wb3J0aW9ucyBvZjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3Vy aWVyIE5ldyciPiBzZWdtZW50PC9zcGFuPj8gSXMgc2VsZWN0b3IgaW4gdGhlIHByb3RlY3Rpb24g cGF0aCBvciB3b3JraW5nIHBhdGg/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCBpcyBiZXR0ZXIgdG8gYmUgY2xlYXIgaW4gdGhlIHRleHQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPjxmb250IGNvbG9yPSIjMDAwMGZmIj5bSmVvbmctZG9u Z10mbmJzcDtTZWxlY3RvciBpcyBpbiB0aGUgZW5kcG9pbnRzIG9mIHRoZSB3b3JraW5nIGFuZCBw cm90ZWN0aW9uIHBhdGhzIGFuZCBzZWxlY3RzIHRoZSB0cmFmZmljIGZyb20gb25lIG9mIHRoZSZu YnNwO3BhdGhzLiBQbGVhc2Ugc2VlIFJGQyA0NDI3LCB3aGljaCBpcyBub3JtYXRpdmVseSByZWZl cnJlZCZuYnNwO2J5IHRoaXMgZG9jdW1lbnQuICZuYnNwOzwvZm9udD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPjxmb250IGNvbG9yPSIjMWY0OTdkIj48bzpwPjwvbzpwPjwv Zm9udD48L286cD4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUuIFNlY3Rpb24gNS4xLCBsYXN0IHBhcmFn cmFwaCBzYWlkOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+V2hhdCBpcyByZXF1aXJlZCBpcyBhIHBy ZWVtcHRpb24gbWVjaGFuaXNtIHRvPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij4m bmJzcDsmbmJzcDsgaW1wbGVtZW50IGJ1c2luZXNzIHByaW9yaXR5IHdoZW4gbXVsdGlwbGUgZmFp bHVyZSBzY2VuYXJpb3Mgb2NjdXIuDQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJ08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltRaW5dOiBJcyBwcmlvcml0eSBidXNpbmVzcyBy ZWxhdGVkIG9yIHBvbGljeSBkZWNpc2lvbiByZWxhdGVkPyBDYW4gYm90aCBwcmVlbXB0aW9uIGFu ZCBwcmlvcml0eQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wb2xpY3kg ZGVjaXNpb24gcmVsYXRlZD8gSXQgaXMgbm90IGNsZWFyIHRvIG1lIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4gYnVzaW5lc3MgcmVsYXRlZCBhbmQgcG9saWN5DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmRlY2lzaW9uIHJlbGF0ZWQuIFdvdWxkIHlvdSBsaWtlIHRvIGNsYXJp ZnkgYSBsaXR0bGUgYml0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD48Zm9udCBjb2xvcj0iIzAwMDBmZiI+W0plb25nLWRvbmddJm5ic3A7Jm5ic3A7VGhlIGJ1c2lu ZXNzIHByaW9yaXR5IGNhbiBiZSB0aG91Z2h0IGFzIHRoZSBwcmlvcml0eSBhc3NpZ25lZCB0byBh IHBhdGggYWNjb3JkaW5nIHRvIHRoZSBwb2xpY3kgb2YgbmV0d29yayBhZG1pbmlzdHJhdGlvbi48 L2ZvbnQ+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48Zm9udCBjb2xvcj0i IzFmNDk3ZCI+PC9mb250PjwvbzpwPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+PGZvbnQgY29sb3I9IiMxZjQ5N2QiPjxvOnA+PC9vOnA+PC9mb250PjwvbzpwPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjYuIFNlY3Rpb24gNS4yLCAxPHN1cD5zdDwvc3VwPiZu YnNwOyBwYXJhZ3JhcGggc2FpZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PuKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPkZvciB0aG9zZSBuZXR3 b3JrcywgaW4gcGFydGljdWxhciBmb3IgbmV0d29ya3MgdGhhdCBzdXBwb3J0IHRoZSByZXF1aXJl bWVudHMgaW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPltSRkM1NjU0XVthbmQg aW4gcGFydGljdWxhciBzdXBwb3J0IGZvciByZXF1aXJlbWVudCA1OF0sIHRoYXQgcmVxdWlyZTwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+dGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhl IHByb3RlY3Rpb24gcmVzb3VyY2VzLCBpLmUuIGhhcmQgcHJlZW10aW9uLDwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyc7IEZPTlQtU0laRTogMTBwdCI+dGhlIGZvbGxvd2luZyBiZWhhdmlvciBTSE9VTEQgYmUgc3Vw cG9ydGVkOjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJ08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltRaW5dOiBzL3ByZWVtdGlvbi9wcmVlbXB0aW9uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPjxmb250IGNvbG9yPSIjMDAw MGZmIj5bSmVvbmctZG9uZ10gVGhpcyBzaG91bGQgYmUgZml4ZWQuJm5ic3A7PC9mb250Pjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+PC9vOnA+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij43LlNlY3Rpb24gNS4yLCBsYXN0IGJ1bGxldCBzYWlkOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+4oCcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+ RHVyaW5nIHByZWVtcHRpb24sIGlmIHRoZXJlIGlzIGFuIG92ZXIgc3Vic2NyaXB0aW9uIG9mIHJl c291cmNlczwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+cHJvdGVjdGVkIHRyYWZm aWMgU0hPVUxEIGJlIHRyZWF0ZWQgYXMgZGVmaW5lZCBpbiBbUkZDNTcxMl0gb3I8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll ciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPltSRkMzMjA5XTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij5bUWlu XXMvW1JGQzMyMDldL1tSRkMzMjA5XS48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPltRaW5dOiBJdCBpcyBub3QgY2xlYXIg dG8gbWUgd2h5IHNvZnQgcHJlZW1wdGlvbiBiZWhhdmlvciBkZWZpbmVkDQo8L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBO ZXcnOyBGT05ULVNJWkU6IDEwcHQiPmluIFJGQzU3MTIgc2hvdWxkIGJlIGFwcGxpZWQgdG8gaGFy ZCBwcmVlbXB0aW9uIHBhcnQgb2Ygc2VjdGlvbg0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpF OiAxMHB0Ij41LjIgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQ/PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmluPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPklzIHRoZXJlIGFu eSBjb21tb24gYmVoYXZpb3IgYmV0d2VlbiBzb2Z0IHByZWVtcHRpb24gYW5kIGhhcmQgcHJlZW1w dGlvbj88L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPkl0IGlzIGJldHRlciB0byBi ZSBjbGVhciBhYm91dCB0aGlzIGluIHRoZSB0ZXh0Ljwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+W0plb25nLWRvbmddIFRoZSBsYXN0IGJ1bGxl dCBhcHBsaWVzIGR1cmluZyBwcmVlbXB0aW9uLiBJdCBtZWFucyB0aGF0IHdoaWxlIHRoZSBwcmVl bXB0aW9uIGFjdGlvbiBpcyBpbiBwcm9ncmVzcywgdGhlIHRyYWZmaWMgc2hvdWxkIGJlJm5ic3A7 Jm5ic3A7dHJlYXRlZCBhcyBzcGVjaWZpZWQgaW4gdGhlIGxhc3QgYnVsbGV0LjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+OC5TZWN0aW9uIDUuNSwgMTxzdXA+c3Q8 L3N1cD4gcGFyYWdyYXBoIHNhaWQ6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij7i gJw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOyZuYnNwOyBQcm90ZWN0 aW9uIHN3aXRjaGluZyB0aW1lIHJlZmVycyB0byB0aGUgdHJhbnNmZXIgdGltZSAoVHQpIGRlZmlu ZWQgaW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOyZuYnNwOyBbRy44 MDguMV0gYW5kIHJlY292ZXJ5IHN3aXRjaGluZyB0aW1lIGRlZmluZWQgaW4gW1JGQzQ0MjddLCBh bmQgaXM8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOyZuYnNwOyBkZWZp bmVkIGFzIHRoZSBpbnRlcnZhbCBhZnRlciBhIHN3aXRjaGluZyB0cmlnZ2VyIGlzIGlkZW50aWZp ZWQgdW50aWw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOyZuYnNwOyB0 aGUgdHJhZmZpYyBiZWdpbnMgdG8gYmUgdHJhbnNtaXR0ZWQgb24gdGhlIHByb3RlY3Rpb24gcGF0 aC4mbmJzcDsNCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyc7IEZPTlQtU0laRTogMTBwdCI+4oCdPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij5bUWluXTo8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcn OyBGT05ULVNJWkU6IDEwcHQiPldoYXQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIOKAnHByb3Rl Y3Rpb24gc3dpdGNoaW5nIHRpbWXigJ0NCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBw dCI+YW5kIOKAnHRyYW5zZmVyIHRpbWXigJ0gb3Ig4oCccmVjb3Zlcnkgc3dpdGNoaW5nIHRpbWXi gJ08L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPkNhbiBJIHBhcnNlIHRoaXMgcmVs YXRpb24gYXM6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij5Qcm90ZWN0aW9uIHN3 aXRjaGluZyB0aW1lID0gdGhlIHRyYW5zZmVyIHRpbWUgJiM0MzsgcmVjb3Zlcnkgc3dpdGNoaW5n IHRpbWU/PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IGNvbG9yPSIjMDAw MGZmIj5bSmVvbmctZG9uZ10gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGltZSA9IHRyYW5zZmVyIHRp bWUgaW4gRy44MDguMSA9IHJlY292ZXJ5IHN3aXRjaGluZyB0aW1lIGluIFJGQzQ0Mjc8L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PGZvbnQgY29sb3I9IiMxZjQ5N2QiPjxm b250IHNpemU9IjIiPjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij48Zm9udCBmYWNlPSJDYWxpYnJp Ij48L2ZvbnQ+PG86cD48L286cD48L2ZvbnQ+PC9mb250PjwvZm9udD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBjb2xvcj0iIzFmNDk3ZCI+PGZvbnQgc2l6ZT0iMiI+PGZvbnQgZmFj ZT0iQ291cmllciBOZXciPjxvOnA+PC9vOnA+PC9mb250PjwvZm9udD48L2ZvbnQ+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll ciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPjkuU2VjdGlvbiA1LjUsIDE8c3VwPnN0PC9zdXA+IHBh cmFncmFwaCBzYWlkOjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+4oCcPC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nv dXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDsmbmJzcDsgSW4gb3JkZXIgdG8gcHJl dmVudCBtdWx0aXBsZSBzd2l0Y2hpbmcgYWN0aW9ucyBmb3IgYSBzaW5nbGUgc3dpdGNoaW5nPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDsmbmJzcDsgdHJpZ2dlciwgU01Q IFNIT1VMRCBiZSBjb250cm9sbGVkIGJ5IGEgaG9sZC1vZmYgdGltZXIgdGhhdCB3b3VsZDwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD b3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+Jm5ic3A7Jm5ic3A7IGFsbG93IGxvd2VyIGxl dmVsIG1lY2hhbmlzbXMgdG8gY29tcGxldGUgdGhlaXIgc3dpdGNoaW5nIGFjdGlvbnM8L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291 cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOyZuYnNwOyBiZWZvcmUgaW52b2tpbmcg U01QIHByb3RlY3Rpb24gYWN0aW9ucy48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPuKAnTwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZP TlQtU0laRTogMTBwdCI+W1Fpbl06V2h5IGFyZSB0aGVyZSBtdWx0aXBsZSBzd2l0Y2hpbmcgYWN0 aW9ucyBmb3IgYSBzaW5nbGUgc3dpdGNoaW5nPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAx MHB0Ij50cmlnZ2VyPyBJc27igJl0IG9uZSBzd2l0Y2hpbmcgdHJpZ2dlciBjb3JyZXNwb25kaW5n IHRvIG9uZSBzd2l0Y2hpbmcgYWN0aW9uPzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBw dCI+Q2FuIHlvdSBnaXZlIGFuIGV4YW1wbGUgZm9yIHRoYXQ/PC9zcGFuPjwvcD4NCjxmb250IGNv bG9yPSIjMDAwMGZmIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IGNvbG9yPSIjMDAwMGZm Ij5bSmVvbmctZG9uZ10mbmJzcDtBIHNpbmdsZSBmYWlsdXJlIGNhbiB0cmlnZ2VyIHRoZSBwcm90 ZWN0aW9uIHN3aXRjaGluZyBhY3Rpb25zIGJvdGggaW4gc2VydmVyIGxheWVyIChPVE4gZm9yIGV4 YW1wbGUpIGFuZCBjbGllbnQgbGF5ZXIgKE1QTFMtVFAgZm9yIGV4YW1wbGUpLg0KPGJyPg0KPC9m b250Pjxmb250IGNvbG9yPSIjMDAwMGZmIj48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0IiBs YW5nPSJFTi1VUyI+PGZvbnQgY29sb3I9IiMwMDAwZmYiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQiIGxhbmc9IkVOLVVTIj48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgY29sb3I9IiMwMDAwZmYiPjxzcGFuIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQiIGxhbmc9IkVOLVVTIj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+PHNwYW4gc3R5 bGU9IkZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4tVVMiPjxmb250IGNvbG9yPSIjMDAwMGZmIj48 c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1VUyI+PGZvbnQgY29sb3I9IiMw MDAwZmYiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLVVTIj48Zm9udCBj b2xvcj0iIzAwMDBmZiI+PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4tVVMi Pjxmb250IGNvbG9yPSIjMDAwMGZmIj48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0IiBsYW5n PSJFTi1VUyI+PGZvbnQgY29sb3I9IiMwMDAwZmYiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQiIGxhbmc9IkVOLVVTIj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+PHNwYW4gc3R5bGU9IkZPTlQt U0laRTogMTBwdCIgbGFuZz0iRU4tVVMiPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3Nw YW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bh bj48L2ZvbnQ+PC9zcGFuPjwvZm9udD4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 L2ZvbnQ+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6 IDEwcHQiPjEwLlNlY3Rpb24gNS41LCAxc3QgcGFyYWdyYXBoIHNhaWQ6PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JzsgRk9OVC1TSVpFOiAxMHB0Ij7igJw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQi PiZuYnNwOyZuYnNwOyBJbiBvcmRlciB0byBwcmV2ZW50IG11bHRpcGxlIHN3aXRjaGluZyBhY3Rp b25zIGZvciBhIHNpbmdsZSBzd2l0Y2hpbmc8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEw cHQiPiZuYnNwOyZuYnNwOyB0cmlnZ2VyLCBTTVAgU0hPVUxEIGJlIGNvbnRyb2xsZWQgYnkgYSBo b2xkLW9mZiB0aW1lciB0aGF0IHdvdWxkPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0 Ij4mbmJzcDsmbmJzcDsgYWxsb3cgbG93ZXIgbGV2ZWwgbWVjaGFuaXNtcyB0byBjb21wbGV0ZSB0 aGVpciBzd2l0Y2hpbmcgYWN0aW9uczwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+ Jm5ic3A7Jm5ic3A7IGJlZm9yZSBpbnZva2luZyBTTVAgcHJvdGVjdGlvbiBhY3Rpb25zLjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTog MTBwdCI+4oCdPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JzsgRk9OVC1TSVpFOiAxMHB0Ij5bUWluXTpXaGF0IGxvd2VyIGxldmVsIG1lYW5zPyBXaGF0IHRo ZSBkaWZmZXJlbmNlIGJldHdlZW4gbG93IGxldmVsDQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJ WkU6IDEwcHQiPmFuZCBoaWdoIGxldmVsPyBEb2VzIHRoaXMgcmVsYXRlIHRvIGxvd2VyIHByaW9y aXR5IG9yIGhpZ2ggcHJpb3JpdHk/PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IGNvbG9yPSIjMDAwMGZmIj5bPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMGZmIj48Zm9udCBj b2xvcj0iIzAwMDBmZiI+SmVvbmctZG9uZ10gU2VlIHRoZSBhYm92ZSBhbnN3ZXIuJm5ic3A7IEZv ciBiZXR0ZXIgY2xhcmlmaWNhdGlvbiwgd2UgY2FuIHJld3JpdGUgaXQgc29tZXRoaW5nIGxpa2U6 PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IGNvbG9yPSIjMDAwMGZmIj48 Zm9udCBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyZu YnNwOyAmcXVvdDtJbiBvcmRlciB0byBwcmV2ZW50IG11bHRpcGxlIHN3aXRjaGluZyBhY3Rpb25z IGZvciBhIHNpbmdsZSBzd2l0Y2hpbmc8L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQi Pjxmb250IGNvbG9yPSIjMDAwMGZmIj4mbmJzcDsmbmJzcDsgdHJpZ2dlcg0KPGZvbnQgY29sb3I9 IiNmZjAwMDAiPndoZW4gdGhlcmUgYXJlIG11bHRpcGxlIGxheWVycyZuYnNwO29mJm5ic3A7bmV0 d29ya3MsPC9mb250PiA8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij48 Zm9udCBjb2xvcj0iIzAwMDBmZiI+Jm5ic3A7Jm5ic3A7IFNNUCBTSE9VTEQgYmUgY29udHJvbGxl ZCBieSBhIGhvbGQtb2ZmIHRpbWVyIHRoYXQgd291bGQ8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3Jzsg Rk9OVC1TSVpFOiAxMHB0Ij48Zm9udCBjb2xvcj0iIzAwMDBmZiI+Jm5ic3A7Jm5ic3A7IGFsbG93 IGxvd2VyDQo8Zm9udCBjb2xvcj0iI2ZmMDAwMCI+bGF5ZXIgPC9mb250Pm1lY2hhbmlzbXMgdG8g Y29tcGxldGUgdGhlaXIgc3dpdGNoaW5nIGFjdGlvbnM8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3Jzsg Rk9OVC1TSVpFOiAxMHB0Ij48Zm9udCBjb2xvcj0iIzAwMDBmZiI+Jm5ic3A7Jm5ic3A7IGJlZm9y ZSBpbnZva2luZyBTTVAgcHJvdGVjdGlvbiBhY3Rpb25zLiZxdW90OzwvZm9udD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PC9mb250PjwvZm9udD48Zm9udCBjb2xvcj0iIzAwMDBm ZiI+Jm5ic3A7Jm5ic3A7PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij5PbiBUdWUsIERlYyAxMCwgMjAxMyBhdCA4OjM3IEFN LCBMb2EgQW5kZXJzc29uICZsdDtsb2EgYXQgcGkubnUmZ3Q7IHdyb3RlOjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyc7IEZPTlQtU0laRTogMTBwdCI+Jmd0OyBXb3JraW5nIEdyb3VwLDwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7 IEZPTlQtU0laRTogMTBwdCI+Jmd0Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+ Jmd0Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+Jmd0OyB0aGlzIGlzIHRvIHN0 YXJ0IGEgMiB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3Jzsg Rk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTAy Ljwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+Jmd0Ozwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7 IEZPTlQtU0laRTogMTBwdCI+Jmd0OyBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgc2Vu ZCBjb21tZW50cyB0byB0aGUgTVBMUyBXRzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBw dCI+Jmd0OyBtYWlsaW5nIGxpc3QgKG1wbHMgYXQgaWV0Zi5vcmcpIC48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcn OyBGT05ULVNJWkU6IDEwcHQiPiZndDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQi PiZndDsgVGhlcmUgYXJlIG5vIElQUiBjbGFpbXMgYWdhaW5zdCB0aGlzIGRvY3VtZW50Ljwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD b3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+Jmd0Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQt U0laRTogMTBwdCI+Jmd0OyBBbGwgdGhlIGF1dGhvcnMgaGF2ZSBzdGF0ZWQgb24gdGhlIE1QTFMg d2cgbWFpbGluZyBsaXN0IHRoYXQgdGhleTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBw dCI+Jmd0OyBhcmUgdW5hd2FyZSBvZiBhbnkgSVBScyB0aGF0IHJlbGF0ZSB0byB0aGlzIGRvY3Vt ZW50Ljwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+Jmd0Ozwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyc7IEZPTlQtU0laRTogMTBwdCI+Jmd0OyBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5k cyBNb25kYXkgRGVjZW1iZXIgMjcgLSAyMDEzLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTog MTBwdCI+Jmd0Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+Jmd0OyBZZXMgLSB0 aGF0IGlzIGlzIGluIHRoZSBtaWRkbGUgb2YgdGhlIEhvbGlkYXkgc2Vhc29uLCBidXQgYXQgbGVh c3Q8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPiZndDsgb25lIHdnIGNoYWlyIHdp bGwgYmUgd29ya2luZyBwYXJ0bHkgYmV0d2VlbiBYbWFzIGFuZCBOZXcgWWVhciBhbmQgYmU8L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn Q291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiPiZndDsgYWJsZSB0byBldmFsdWF0ZSBuZXh0 IHN0ZXBzLiBXZSBjb3VudCBvbiBtb3N0IHJldmlld3MgdGFraW5nIHBsYWNlPC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIg TmV3JzsgRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IGluIHRoZSBhbG1vc3QgdHdvIHdlZWtzIGJlZm9y ZSBYbWFzLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCI+Jmd0Ozwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVy IE5ldyc7IEZPTlQtU0laRTogMTBwdCI+Jmd0OyAvTG9hPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdDsgbXNvLWVsZW1lbnQ6IGNvbW1lbnQtbGlzdCI+DQo8aHIgY2xhc3M9Im1z b2NvbW9mZiIgYWxpZ249ImxlZnQiIHNpemU9IjEiIHdpZHRoPSIzMyUiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AFE7BSMTP2etriinfo_-- From ryoo@etri.re.kr Sun Jan 5 21:41:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C94C1ADFA5 for ; Sun, 5 Jan 2014 21:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.539 X-Spam-Level: X-Spam-Status: No, score=-100.539 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 LqdPNOm-YH2e for ; Sun, 5 Jan 2014 21:41:44 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 916D21ADFA3 for ; Sun, 5 Jan 2014 21:41:43 -0800 (PST) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Jan 2014 14:41:27 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Mon, 6 Jan 2014 14:41:28 +0900 From: "Ryoo, Jeong-dong" To: "Eric Osborne (eosborne)" , "mpls@ietf.org" Thread-Topic: Comment on draft-ietf-mpls-psc-updates-00 Thread-Index: Ac8KofHMN3q6UuXFRdOa3M6rIjPiPA== Date: Mon, 6 Jan 2014 05:41:28 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AFF06@SMTP2.etri.info> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AFF06SMTP2etriinfo_" MIME-Version: 1.0 Subject: [mpls] Comment on draft-ietf-mpls-psc-updates-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 05:41:46 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AFF06SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYywNCg0KSW4gU2VjdGlvbiA0ICBvZiBkcmFmdC1pZXRmLW1wbHMtcHNjLXVwZGF0ZXMtMDAs IEkgbm90aWNlZCB0aGF0IHRoZSBleGFtcGxlIHRoYXQgY2Fubm90IGV4aXN0IGluIGdlbmVyYWwg aXMgYmVpbmcgdXNlZC4NCg0KTG9jYWwgTE8gYW5kIHJlbW90ZSBGUyBjYW5ub3QgZXhpc3Qgc2lu Y2UgdGhlIGhpZ2hlciBwcmlvcml0eSBMTyByZXF1ZXN0IHdpbGwgY2FuY2VsIHRoZSBGUyBjb21t YW5kLg0KT2YgY291cnNlLCB3aGVuIHR3byBkaWZmZXJlbnQgY29tbWFuZHMgYXJlIGlzc3VlZCBz aW11bHRhbmVvdXNseSBhdCBib3RoIG5vZGVzLCBMTyBhbmQgRlMgY2FuIGNvZXhpc3QgZm9yIGEg dmVyeSBzaG9ydCBwZXJpb2Qgb2YgdGltZS4NCkJ1dCwgYXMgc29vbiBhcyB0aGUgZmlyc3QgTE8g bWVzc2FnZSBhcnJpdmVzIGF0IGxvY2FsIG5vZGUgdGhhdCBoYXMgbG9jYWwgRlMgaW5wdXQsIHRo ZSBsb3cgcHJpb3JpdHkgbG9jYWwgRlMgY29tbWFuZCB3aWxsIGJlIGNhbmNlbGxlZC4NClNlZSBT ZWN0aW9uIDQuMy4zLjMgKFByb3RlY3RpbmcgQWRtaW5pc3RyYXRpdmUgU3RhdGUpIGluIFJGQyA2 Mzc4Og0KIkEgcmVtb3RlIExvY2tvdXQgb2YgcHJvdGVjdGlvbiBtZXNzYWdlIFNIQUxMIGNhdXNl IHRoZSBMRVIgdG8gZ28NCmludG8gcmVtb3RlIFVuYXZhaWxhYmxlIHN0YXRlIGFuZCBiZWdpbiB0 cmFuc21pdHRpbmcgYW4gTlIoMCwwKQ0KbWVzc2FnZS4gSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQg dGhpcyBhdXRvbWF0aWNhbGx5IGNhbmNlbHMgdGhlDQpjdXJyZW50IEZvcmNlZCBTd2l0Y2ggb3Ig TWFudWFsIFN3aXRjaCBjb21tYW5kIGFuZCBkYXRhIHRyYWZmaWMgaXMNCnJldmVydGVkIHRvIHRo ZSB3b3JraW5nIHBhdGguIg0KSSB3b3VsZCBzdWdnZXN0IHRvIHVzZSBTRi1XIGluc3RlYWQgb2Yg RlMuDQoNCkFub3RoZXIgdGhpbmcgaXMgdGhhdCBJIHdvbmRlciBpZiB5b3UgY2FuIGFsc28gY2hh bmdlICJjYXBhYmlsaXRpZXMgbWlzbWF0Y2giIHRvICJwcm92aXNvbmluZyBtaXNtYXRjaCIgaW4g dGhlIGRvY3VtZW50Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AFF06SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5FcmljLCA8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0Ij5JbiBTZWN0aW9uIDQmbmJzcDsgb2YgZHJhZnQtaWV0Zi1tcGxzLXBzYy11cGRhdGVzLTAw LCBJIG5vdGljZWQgdGhhdCB0aGUgZXhhbXBsZSB0aGF0IGNhbm5vdCBleGlzdCZuYnNwO2luIGdl bmVyYWwgaXMgYmVpbmcgdXNlZC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0 Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2NhbCZuYnNw O0xPIGFuZCByZW1vdGUgRlMgY2Fubm90IGV4aXN0Jm5ic3A7c2luY2UgdGhlJm5ic3A7aGlnaGVy IHByaW9yaXR5IExPIHJlcXVlc3Qgd2lsbCBjYW5jZWwgdGhlIEZTIGNvbW1hbmQuPC9kaXY+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+T2YgY291cnNlLCB3aGVuIHR3byBkaWZmZXJl bnQgY29tbWFuZHMgYXJlIGlzc3VlZCBzaW11bHRhbmVvdXNseSBhdCBib3RoIG5vZGVzLCBMTyBh bmQgRlMgY2FuIGNvZXhpc3QgZm9yIGEgdmVyeSBzaG9ydCBwZXJpb2Qgb2YgdGltZS48L2Rpdj4N CjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5CdXQsIGFzIHNvb24gYXMmbmJzcDt0aGUg Zmlyc3QmbmJzcDtMTyBtZXNzYWdlIGFycml2ZXMgYXQmbmJzcDtsb2NhbCBub2RlIHRoYXQgaGFz IGxvY2FsIEZTIGlucHV0LCB0aGUgbG93IHByaW9yaXR5IGxvY2FsIEZTIGNvbW1hbmQgd2lsbCBi ZSBjYW5jZWxsZWQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+U2VlIFNl Y3Rpb24gNC4zLjMuMyAoUHJvdGVjdGluZyBBZG1pbmlzdHJhdGl2ZSBTdGF0ZSkgaW4gUkZDIDYz Nzg6PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGZvbnQgZmFjZT0iQ291 cmllciBOZXciPiZxdW90O0EgcmVtb3RlIExvY2tvdXQgb2YgcHJvdGVjdGlvbiBtZXNzYWdlIFNI QUxMIGNhdXNlIHRoZSBMRVIgdG8gZ288YnI+DQppbnRvIHJlbW90ZSBVbmF2YWlsYWJsZSBzdGF0 ZSBhbmQgYmVnaW4gdHJhbnNtaXR0aW5nIGFuIE5SKDAsMCk8YnI+DQptZXNzYWdlLiBJdCBzaG91 bGQgYmUgbm90ZWQgdGhhdCB0aGlzIGF1dG9tYXRpY2FsbHkgY2FuY2VscyB0aGU8YnI+DQpjdXJy ZW50IEZvcmNlZCBTd2l0Y2ggb3IgTWFudWFsIFN3aXRjaCBjb21tYW5kIGFuZCBkYXRhIHRyYWZm aWMgaXM8YnI+DQpyZXZlcnRlZCB0byB0aGUgd29ya2luZyBwYXRoLiZxdW90Ozxicj4NCjwvZm9u dD48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5JIHdvdWxkIHN1Z2dlc3Qg dG8mbmJzcDt1c2UgU0YtVyBpbnN0ZWFkIG9mIEZTLiZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdiBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiPkFub3RoZXIgdGhpbmcgaXMgdGhhdCBJIHdvbmRlciBpZiB5b3UgY2FuIGFs c28gY2hhbmdlICZxdW90O2NhcGFiaWxpdGllcyBtaXNtYXRjaCZxdW90OyB0byAmcXVvdDtwcm92 aXNvbmluZyBtaXNtYXRjaCZxdW90OyBpbiB0aGUgZG9jdW1lbnQuPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCI+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRv bmc8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AFF06SMTP2etriinfo_-- From bill.wu@huawei.com Sun Jan 5 23:10:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ED91ADFC2 for ; Sun, 5 Jan 2014 23:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 sWnkiQ7WQ282 for ; Sun, 5 Jan 2014 23:10:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 584651ADFBF for ; Sun, 5 Jan 2014 23:10:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCE23334; Mon, 06 Jan 2014 07:10:26 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 07:09:59 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 07:10:24 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 15:10:19 +0800 From: Qin Wu To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping Thread-Index: AQHPCQpF8EKV6TDHQ0CJk57HMDs40pp3RgIA Date: Mon, 6 Jan 2014 07:10:18 +0000 Message-ID: References: <52C795FE.7060801@pi.nu> In-Reply-To: <52C795FE.7060801@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 07:10:38 -0000 Hi, authors: Have a quick look at this draft, It is not clear to me why proxy LSR doesn'= t need to wait for The result of MPLS echo rely and then send MPLS proxy ping reply? I know the draft says the receivers process the MPLS echo request, sending = their MPLS echo replies directly back to the initiator, however why bypass proxy = LSR? What about MPLS echo request initiating by proxy LSR is lost? How does the = initiator=20 know the lost of MPLS echo request or reply? What am I missing? Also it is not very clear to me how to use reply mode 5, although the draft= says " If the Reply Mode of the message header is 1 or is 5 and no errors or modifications have occurred no MPLS proxy ping reply is sent. " It looks to me if no MPLS proxy ping rely needs to be sent, why define repl= y mode 5? Also there are a lot of nits and typos that need to be fixed, s/ limiting the the number/ limiting the number s/ motivaton/ motivation s/ and and all autho-rization/ and all authorization s/ Pprocedures/ Procedures s/ sub-objexts/ sub-objects s/ modificatons /modifications s/ decribed/ described s/ assigments/assignments In section 5.2, there is no definition of reply to address field, I think i= t should be defined as initiator address For Downstream Mapping objects, it is better to add a reference to RFC4379. The references [McstPing] [mLDP] are now outdated and need to be updated to= the corresponding RFC. Regards! -Qin =20 -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, January 04, 2014 1:03 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-proxy-lsp-ping@tools.ietf.o= rg Subject: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping Working Group, this is to start a two week working group last call on draft-ietf-mpls-proxy-lsp-ping-01.txt Please send your comments to working group mailing lists (mpls@ietf.org). We will do an IPR poll on this document in parallel thee wglc. There are three IPRs disclosures that relates to this document. The working group last call will end Friday January 20, 2914. /Loa mpls wg co-chair --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From bill.wu@huawei.com Sun Jan 5 23:20:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD0B1ADFD8 for ; Sun, 5 Jan 2014 23:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 JZxnbBNYt2NV for ; Sun, 5 Jan 2014 23:20:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F1D781ADFD7 for ; Sun, 5 Jan 2014 23:20:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZQ92612; Mon, 06 Jan 2014 07:20:17 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 07:19:50 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 07:20:15 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 15:20:09 +0800 From: Qin Wu To: "Ryoo, Jeong-dong" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] wglc on draft-ietf-mpls-smp-requirements Thread-Index: Ac76L8gPAbx7QpzERKO4dZ+zkusX+gQR6SgPAA3oruA= Date: Mon, 6 Jan 2014 07:20:08 +0000 Message-ID: References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AFE7B@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AFE7B@SMTP2.etri.info> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C7037Ankgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] wglc on draft-ietf-mpls-smp-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 07:20:35 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C7037Ankgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEplb25nLWRvbmc6DQpUaGFuayBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLg0KWW91IGFkZHJl c3MgbW9zdCBvZiBteSBjb21tZW50cyBleGNlcHQgb25lLg0KRm9yIHNlY3Rpb24gNS4yLCBsYXN0 IGJ1bGxldCwgY2FuIHlvdSBwb2ludCBtZSB3aGVyZSBSRkM1NzEyIGFuZCBSRkMzMjA5IGRlYWwg d2l0aCB0aGUgY2FzZSB3aGVyZSByZXNvdXJjZXMNCmFyZSBvdmVyIHN1YnNjcmliZWQ/DQpJdCBp cyBiZXR0ZXIgdG8gc2F5DQrigJwNCnByb3RlY3RlZCB0cmFmZmljIFNIT1VMRCBiZSB0cmVhdGVk IGFzIGRlZmluZWQgaW4gc2VjdGlvbiB4eCBvZiBbUkZDNTcxMjxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM1NzEyPl0gb3INCnNlY3Rpb24geHggb2YgIFtSRkMzMjA5PGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzMyMDk+XQ0K4oCdDQoNClJlZ2FyZHMhDQotUWluDQpGcm9tOiBS eW9vLCBKZW9uZy1kb25nIFttYWlsdG86cnlvb0BldHJpLnJlLmtyXQ0KU2VudDogTW9uZGF5LCBK YW51YXJ5IDA2LCAyMDE0IDExOjEwIEFNDQpUbzogUWluIFd1OyBtcGxzQGlldGYub3JnOyBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFttcGxzXSB3Z2xjIG9uIGRyYWZ0 LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzDQoNClFpbiwgdGhhbmtzIGZvciB5b3VyIGNvbW1l bnRzLg0KDQpQbGVhc2UsIHNlZSBpbiBsaW5lcyAuLi4NCg0KQmVzdCByZWdhcmRzLA0KDQpKZW9u Zy1kb25nDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tIDog IlFpbiBXdSIgPGJpbGwud3VAaHVhd2VpLmNvbT4NClNlbnQgOiAyMDEzLTEyLTE2IDE2OjI1OjQ5 ICggKzA5OjAwICkNClRvIDogbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4sIG1wbHMtY2hh aXJzQHRvb2xzLmlldGYub3JnIDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCkNjIDoNClN1 YmplY3QgOiBbbXBsc10gd2dsYyBvbiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cw0K SGksYWxsOg0KSSBoYXZlIHJldmlld2VkIGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRz LiBIZXJlIGFyZSBhIGZldyBjb21tZW50cyBJIGhhdmUgYmVsb3cuDQoxLiBBYnN0cmFjdCBzYWlk Og0K4oCcDQpUaGlzIGRvY3VtZW50IHByZXNlbnRzIHRoZSBiYXNpYyBuZXR3b3JrIG9iamVjdGl2 ZXMgZm9yIHRoZSBiZWhhdmlvcg0Kb2Ygc2hhcmVkIG1lc2ggcHJvdGVjdGlvbiAoU01QKSBub3Qg YmFzZWQgb24gY29udHJvbC1wbGFuZSBzdXBwb3J0Lg0KDQrigJ0NCltRaW5dOiBDYW4gU01QIGJl aGF2aW9yIGJlIGJhc2VkIG9uIG1hbmFnZW1lbnQgcGxhbmUsIGlmIG5vdCwgd2h5IG5vdCBzYXkg dGhlIFNNUCBiZWhhdmlvciBpcyBiYXNlZCBvbiBkYXRhLXBsYW5lIHN1cHBvcnQgZGlyZWN0bHku DQpbSmVvbmctZG9uZ10gU01QIGlzIGEgZGF0YSBwbGFuZSBwcm90b2NvbCwgd2hpY2ggbWF5IG5l ZWQgc29tZSBzdXBwb3J0cyBmcm9tIG1hbmFnZW1lbnQgcGxhbmUgZm9yIGNvbmZpZ3VyYXRpb24s IGFsYXJtLCBldGMuDQoNCg0KMi4gU2VjdGlvbiAxLCBQYXJhZ3JhcGggdHdvIHNhaWQ6DQrigJwN Ck1QTFMgcHJvdmlkZXMgY29udHJvbC1wbGFuZSB0b29scyB0byBzdXBwb3J0IHZhcmlvdXMgc3Vy dml2YWJpbGl0eQ0KICAgc2NoZW1lcyAoRWRpdG9yJ3Mgbm90ZSAtIGFkZCByZWZlcmVuY2VzKS4N Cg0K4oCdDQpbUWluXTogV2hhdCByZWZlcmVuY2Ugc2hvdWxkIGJlIHB1dCBoZXJlIG5lZWRzIHRv IGJlIGZpeGVkLg0KW0plb25nLWRvbmddIFllcywgaXQgbmVlZHMgdG8gYmUgZml4ZWQuIEEgY2Fu ZGlkYXRlIG1pZ2h0IGJlIFJGQyA0NDI2IC0gR01QTFMgUmVjb3ZlcnkgRnVuY3Rpb25hbCBTcGVj aWZpY2F0aW9uLg0KDQoNCjMuIFNlY3Rpb24gMSwgUGFyYWdyYXBoIHRocmVlIHNhaWQ6DQrigJwN CldoZW4gY29uc2lkZXJpbmcgYSBmdWxsLW1lc2ggbmV0d29yayBhbmQgdGhlIHByb3RlY3Rpb24g b2YgZGlmZmVyZW50DQogICBwYXRocyB0aGF0IGNyaXNzLWNyb3NzIHRoZSBtZXNoLCBpdCBpcyBw b3NzaWJsZSB0byBwcm92aWRlIGFuDQogICBhY2NlcHRhYmxlIGxldmVsIG9mIHByb3RlY3Rpb24g d2hpbGUgY29uc2VydmluZyB0aGUgYW1vdW50IG9mDQogICBwcm90ZWN0aW9uIHJlc291cmNlcyBu ZWVkZWQgdG8gcHJvdGVjdCB0aGUgZGlmZmVyZW50IGRhdGEgcGF0aHMuDQoNCuKAnQ0KDQpbUWlu XTogSXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoYXQgY3Jpc3MtY3Jvc3MgaXM/IFdvdWxkIGl0IGJl IGdvb2QgdG8gYWRkIGEgcmVmZXJlbmNlIGZvciDigJxjcmlzcy1jcm9zc+KAnSBoZXJlPw0KW0pl b25nLWRvbmddICAiY3Jpc3MtY3Jvc3MiIGZyb20gT3hmb3JkIERpY3Rpb25hcmllczoNCiAodmVy YiApIFt3aXRoIG9iamVjdF0gZm9ybSBhIHBhdHRlcm4gb2YgaW50ZXJzZWN0aW5nIGxpbmVzIG9y IHBhdGhzIG9uIChhIHBsYWNlKTsgdGhlIGdyZWVuIGhpbGwgd2FzIGNyaXNzLWNyb3NzZWQgd2l0 aCBhIG5ldHdvcmsgb2Ygc2hlZXAgdHJhY2tzLCAgW25vIG9iamVjdF06IHRoZSBzbWFsbGVyIHN0 cmVldHMgY3Jpc3MtY3Jvc3NlZCBpbiBhIGdyaWQgcGF0dGVybjsgbW92ZSBvciB0cmF2ZWwgYXJv dW5kIChhIHBsYWNlKSBieSBnb2luZyBiYWNrIGFuZCBmb3J0aCByZXBlYXRlZGx5OiB0aGUgUHJl c2lkZW50IGNyaXNzLWNyb3NzZWQgQW1lcmljYQ0KDQo0LlNlY3Rpb24gNCwgaXQgc2FpZDoNCuKA nA0KIkhhcmQgUHJlZW1wdGlvbiIgcmVxdWlyZXMgdGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9y cyBhdCB0aGUgaW5ncmVzcyBvZg0KZWFjaCBzaGFyZWQgc2VnbWVudCB0byBlbmZvcmNlIHdoaWNo IGJhY2t1cCBwYXRoIGhhcyB0aGUgaGlnaGVzdA0KcHJpb3JpdHkgd2hlbiBjb21taXR0aW5nIHBy b3RlY3Rpb24gcmVzb3VyY2VzLCB0aGUgb3RoZXJzIGJlaW5nDQpwcmVlbXB0ZWQuDQoNCuKAnQ0K DQpbUWluXTogSXMgc2VsZWN0b3Igb25lIG9mIHByb3RlY3Rpb24gZW5kcG9pbnRzPyBJcyBzZWxl Y3RvciBiZWxvbmcgdG8gc2hhcmVkIHNlZ21lbnQgb3IgdW5zaGFyZWQNCg0KcG9ydGlvbnMgb2Yg c2VnbWVudD8gSXMgc2VsZWN0b3IgaW4gdGhlIHByb3RlY3Rpb24gcGF0aCBvciB3b3JraW5nIHBh dGg/DQpJdCBpcyBiZXR0ZXIgdG8gYmUgY2xlYXIgaW4gdGhlIHRleHQuDQpbSmVvbmctZG9uZ11T ZWxlY3RvciBpcyBpbiB0aGUgZW5kcG9pbnRzIG9mIHRoZSB3b3JraW5nIGFuZCBwcm90ZWN0aW9u IHBhdGhzIGFuZCBzZWxlY3RzIHRoZSB0cmFmZmljIGZyb20gb25lIG9mIHRoZSBwYXRocy4gUGxl YXNlIHNlZSBSRkMgNDQyNywgd2hpY2ggaXMgbm9ybWF0aXZlbHkgcmVmZXJyZWQgYnkgdGhpcyBk b2N1bWVudC4NCg0KDQo1LiBTZWN0aW9uIDUuMSwgbGFzdCBwYXJhZ3JhcGggc2FpZDoNCuKAnA0K V2hhdCBpcyByZXF1aXJlZCBpcyBhIHByZWVtcHRpb24gbWVjaGFuaXNtIHRvDQogICBpbXBsZW1l bnQgYnVzaW5lc3MgcHJpb3JpdHkgd2hlbiBtdWx0aXBsZSBmYWlsdXJlIHNjZW5hcmlvcyBvY2N1 ci4NCg0K4oCdDQpbUWluXTogSXMgcHJpb3JpdHkgYnVzaW5lc3MgcmVsYXRlZCBvciBwb2xpY3kg ZGVjaXNpb24gcmVsYXRlZD8gQ2FuIGJvdGggcHJlZW1wdGlvbiBhbmQgcHJpb3JpdHkNCnBvbGlj eSBkZWNpc2lvbiByZWxhdGVkPyBJdCBpcyBub3QgY2xlYXIgdG8gbWUgdGhlIGRpZmZlcmVuY2Ug YmV0d2VlbiBidXNpbmVzcyByZWxhdGVkIGFuZCBwb2xpY3kNCmRlY2lzaW9uIHJlbGF0ZWQuIFdv dWxkIHlvdSBsaWtlIHRvIGNsYXJpZnkgYSBsaXR0bGUgYml0Pw0KW0plb25nLWRvbmddIFRoZSBi dXNpbmVzcyBwcmlvcml0eSBjYW4gYmUgdGhvdWdodCBhcyB0aGUgcHJpb3JpdHkgYXNzaWduZWQg dG8gYSBwYXRoIGFjY29yZGluZyB0byB0aGUgcG9saWN5IG9mIG5ldHdvcmsgYWRtaW5pc3RyYXRp b24uDQoNCg0KNi4gU2VjdGlvbiA1LjIsIDFzdCAgcGFyYWdyYXBoIHNhaWQ6DQrigJwNCkZvciB0 aG9zZSBuZXR3b3JrcywgaW4gcGFydGljdWxhciBmb3IgbmV0d29ya3MgdGhhdCBzdXBwb3J0IHRo ZSByZXF1aXJlbWVudHMgaW4NCltSRkM1NjU0XVthbmQgaW4gcGFydGljdWxhciBzdXBwb3J0IGZv ciByZXF1aXJlbWVudCA1OF0sIHRoYXQgcmVxdWlyZQ0KdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhl IHByb3RlY3Rpb24gcmVzb3VyY2VzLCBpLmUuIGhhcmQgcHJlZW10aW9uLA0KdGhlIGZvbGxvd2lu ZyBiZWhhdmlvciBTSE9VTEQgYmUgc3VwcG9ydGVkOg0K4oCdDQpbUWluXTogcy9wcmVlbXRpb24v cHJlZW1wdGlvbg0KW0plb25nLWRvbmddIFRoaXMgc2hvdWxkIGJlIGZpeGVkLg0KDQoNCjcuU2Vj dGlvbiA1LjIsIGxhc3QgYnVsbGV0IHNhaWQ6DQrigJwNCkR1cmluZyBwcmVlbXB0aW9uLCBpZiB0 aGVyZSBpcyBhbiBvdmVyIHN1YnNjcmlwdGlvbiBvZiByZXNvdXJjZXMNCnByb3RlY3RlZCB0cmFm ZmljIFNIT1VMRCBiZSB0cmVhdGVkIGFzIGRlZmluZWQgaW4gW1JGQzU3MTJdIG9yDQpbUkZDMzIw OV0NCuKAnQ0KW1Fpbl1zL1tSRkMzMjA5XS9bUkZDMzIwOV0uDQoNCltRaW5dOiBJdCBpcyBub3Qg Y2xlYXIgdG8gbWUgd2h5IHNvZnQgcHJlZW1wdGlvbiBiZWhhdmlvciBkZWZpbmVkDQppbiBSRkM1 NzEyIHNob3VsZCBiZSBhcHBsaWVkIHRvIGhhcmQgcHJlZW1wdGlvbiBwYXJ0IG9mIHNlY3Rpb24N CjUuMiBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudD8NCmluDQpJcyB0aGVyZSBhbnkgY29tbW9u IGJlaGF2aW9yIGJldHdlZW4gc29mdCBwcmVlbXB0aW9uIGFuZCBoYXJkIHByZWVtcHRpb24/DQpJ dCBpcyBiZXR0ZXIgdG8gYmUgY2xlYXIgYWJvdXQgdGhpcyBpbiB0aGUgdGV4dC4NCltKZW9uZy1k b25nXSBUaGUgbGFzdCBidWxsZXQgYXBwbGllcyBkdXJpbmcgcHJlZW1wdGlvbi4gSXQgbWVhbnMg dGhhdCB3aGlsZSB0aGUgcHJlZW1wdGlvbiBhY3Rpb24gaXMgaW4gcHJvZ3Jlc3MsIHRoZSB0cmFm ZmljIHNob3VsZCBiZSAgdHJlYXRlZCBhcyBzcGVjaWZpZWQgaW4gdGhlIGxhc3QgYnVsbGV0Lg0K DQoNCjguU2VjdGlvbiA1LjUsIDFzdCBwYXJhZ3JhcGggc2FpZDoNCuKAnA0KICAgUHJvdGVjdGlv biBzd2l0Y2hpbmcgdGltZSByZWZlcnMgdG8gdGhlIHRyYW5zZmVyIHRpbWUgKFR0KSBkZWZpbmVk IGluDQogICBbRy44MDguMV0gYW5kIHJlY292ZXJ5IHN3aXRjaGluZyB0aW1lIGRlZmluZWQgaW4g W1JGQzQ0MjddLCBhbmQgaXMNCiAgIGRlZmluZWQgYXMgdGhlIGludGVydmFsIGFmdGVyIGEgc3dp dGNoaW5nIHRyaWdnZXIgaXMgaWRlbnRpZmllZCB1bnRpbA0KICAgdGhlIHRyYWZmaWMgYmVnaW5z IHRvIGJlIHRyYW5zbWl0dGVkIG9uIHRoZSBwcm90ZWN0aW9uIHBhdGguDQoNCuKAnQ0KDQpbUWlu XToNCldoYXQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIOKAnHByb3RlY3Rpb24gc3dpdGNoaW5n IHRpbWXigJ0NCmFuZCDigJx0cmFuc2ZlciB0aW1l4oCdIG9yIOKAnHJlY292ZXJ5IHN3aXRjaGlu ZyB0aW1l4oCdDQpDYW4gSSBwYXJzZSB0aGlzIHJlbGF0aW9uIGFzOg0KUHJvdGVjdGlvbiBzd2l0 Y2hpbmcgdGltZSA9IHRoZSB0cmFuc2ZlciB0aW1lICsgcmVjb3Zlcnkgc3dpdGNoaW5nIHRpbWU/ DQpbSmVvbmctZG9uZ10gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGltZSA9IHRyYW5zZmVyIHRpbWUg aW4gRy44MDguMSA9IHJlY292ZXJ5IHN3aXRjaGluZyB0aW1lIGluIFJGQzQ0MjcNCg0KDQo5LlNl Y3Rpb24gNS41LCAxc3QgcGFyYWdyYXBoIHNhaWQ6DQrigJwNCiAgIEluIG9yZGVyIHRvIHByZXZl bnQgbXVsdGlwbGUgc3dpdGNoaW5nIGFjdGlvbnMgZm9yIGEgc2luZ2xlIHN3aXRjaGluZw0KICAg dHJpZ2dlciwgU01QIFNIT1VMRCBiZSBjb250cm9sbGVkIGJ5IGEgaG9sZC1vZmYgdGltZXIgdGhh dCB3b3VsZA0KICAgYWxsb3cgbG93ZXIgbGV2ZWwgbWVjaGFuaXNtcyB0byBjb21wbGV0ZSB0aGVp ciBzd2l0Y2hpbmcgYWN0aW9ucw0KICAgYmVmb3JlIGludm9raW5nIFNNUCBwcm90ZWN0aW9uIGFj dGlvbnMuDQoNCuKAnQ0KW1Fpbl06V2h5IGFyZSB0aGVyZSBtdWx0aXBsZSBzd2l0Y2hpbmcgYWN0 aW9ucyBmb3IgYSBzaW5nbGUgc3dpdGNoaW5nDQp0cmlnZ2VyPyBJc27igJl0IG9uZSBzd2l0Y2hp bmcgdHJpZ2dlciBjb3JyZXNwb25kaW5nIHRvIG9uZSBzd2l0Y2hpbmcgYWN0aW9uPw0KQ2FuIHlv dSBnaXZlIGFuIGV4YW1wbGUgZm9yIHRoYXQ/DQpbSmVvbmctZG9uZ10gQSBzaW5nbGUgZmFpbHVy ZSBjYW4gdHJpZ2dlciB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgYWN0aW9ucyBib3RoIGluIHNl cnZlciBsYXllciAoT1ROIGZvciBleGFtcGxlKSBhbmQgY2xpZW50IGxheWVyIChNUExTLVRQIGZv ciBleGFtcGxlKS4NCg0KMTAuU2VjdGlvbiA1LjUsIDFzdCBwYXJhZ3JhcGggc2FpZDoNCuKAnA0K ICAgSW4gb3JkZXIgdG8gcHJldmVudCBtdWx0aXBsZSBzd2l0Y2hpbmcgYWN0aW9ucyBmb3IgYSBz aW5nbGUgc3dpdGNoaW5nDQogICB0cmlnZ2VyLCBTTVAgU0hPVUxEIGJlIGNvbnRyb2xsZWQgYnkg YSBob2xkLW9mZiB0aW1lciB0aGF0IHdvdWxkDQogICBhbGxvdyBsb3dlciBsZXZlbCBtZWNoYW5p c21zIHRvIGNvbXBsZXRlIHRoZWlyIHN3aXRjaGluZyBhY3Rpb25zDQogICBiZWZvcmUgaW52b2tp bmcgU01QIHByb3RlY3Rpb24gYWN0aW9ucy4NCg0K4oCdDQoNCltRaW5dOldoYXQgbG93ZXIgbGV2 ZWwgbWVhbnM/IFdoYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBsb3cgbGV2ZWwNCmFuZCBoaWdo IGxldmVsPyBEb2VzIHRoaXMgcmVsYXRlIHRvIGxvd2VyIHByaW9yaXR5IG9yIGhpZ2ggcHJpb3Jp dHk/DQpbSmVvbmctZG9uZ10gU2VlIHRoZSBhYm92ZSBhbnN3ZXIuICBGb3IgYmV0dGVyIGNsYXJp ZmljYXRpb24sIHdlIGNhbiByZXdyaXRlIGl0IHNvbWV0aGluZyBsaWtlOg0KICAgIkluIG9yZGVy IHRvIHByZXZlbnQgbXVsdGlwbGUgc3dpdGNoaW5nIGFjdGlvbnMgZm9yIGEgc2luZ2xlIHN3aXRj aGluZw0KICAgdHJpZ2dlciB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBsYXllcnMgb2YgbmV0d29y a3MsDQogICBTTVAgU0hPVUxEIGJlIGNvbnRyb2xsZWQgYnkgYSBob2xkLW9mZiB0aW1lciB0aGF0 IHdvdWxkDQogICBhbGxvdyBsb3dlciBsYXllciBtZWNoYW5pc21zIHRvIGNvbXBsZXRlIHRoZWly IHN3aXRjaGluZyBhY3Rpb25zDQogICBiZWZvcmUgaW52b2tpbmcgU01QIHByb3RlY3Rpb24gYWN0 aW9ucy4iDQoNCg0KT24gVHVlLCBEZWMgMTAsIDIwMTMgYXQgODozNyBBTSwgTG9hIEFuZGVyc3Nv biA8bG9hIGF0IHBpLm51PiB3cm90ZToNCj4gV29ya2luZyBHcm91cCwNCj4NCj4NCj4gdGhpcyBp cyB0byBzdGFydCBhIDIgd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KPiBkcmFmdC1p ZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wMi4NCj4NCj4gUGxlYXNlIHJldmlldyB0aGUgZG9j dW1lbnQgYW5kIHNlbmQgY29tbWVudHMgdG8gdGhlIE1QTFMgV0cNCj4gbWFpbGluZyBsaXN0ICht cGxzIGF0IGlldGYub3JnKSAuDQo+DQo+IFRoZXJlIGFyZSBubyBJUFIgY2xhaW1zIGFnYWluc3Qg dGhpcyBkb2N1bWVudC4NCj4NCj4gQWxsIHRoZSBhdXRob3JzIGhhdmUgc3RhdGVkIG9uIHRoZSBN UExTIHdnIG1haWxpbmcgbGlzdCB0aGF0IHRoZXkNCj4gYXJlIHVuYXdhcmUgb2YgYW55IElQUnMg dGhhdCByZWxhdGUgdG8gdGhpcyBkb2N1bWVudC4NCj4NCj4gVGhlIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIGVuZHMgTW9uZGF5IERlY2VtYmVyIDI3IC0gMjAxMy4NCj4NCj4gWWVzIC0gdGhhdCBp cyBpcyBpbiB0aGUgbWlkZGxlIG9mIHRoZSBIb2xpZGF5IHNlYXNvbiwgYnV0IGF0IGxlYXN0DQo+ IG9uZSB3ZyBjaGFpciB3aWxsIGJlIHdvcmtpbmcgcGFydGx5IGJldHdlZW4gWG1hcyBhbmQgTmV3 IFllYXIgYW5kIGJlDQo+IGFibGUgdG8gZXZhbHVhdGUgbmV4dCBzdGVwcy4gV2UgY291bnQgb24g bW9zdCByZXZpZXdzIHRha2luZyBwbGFjZQ0KPiBpbiB0aGUgYWxtb3N0IHR3byB3ZWVrcyBiZWZv cmUgWG1hcy4NCj4NCj4gL0xvYQ0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA43C7037Ankgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGUgaWQ9ZHluQ29tPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwp O30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVy bCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K PC9zdHlsZT48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBh bm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpD YWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9z ZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvQ29tbWVudFRleHQsIGxpLk1zb0NvbW1lbnRUZXh0 LCBkaXYuTXNvQ29tbWVudFRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiLmibnms6jmloflrZcgQ2hhcjEiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWxheW91dC1ncmlkLW1vZGU6Y2hhcjsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFu LkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOaWh+WtlyBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5paH5a2XOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFtZToi 5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAuSFRNTCwg bGkuSFRNTCwgZGl2LkhUTUwNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKEIOiuviDmoLzlvI8i Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihCDorr4g5qC85byPQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTENoYXIwDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIOmihCDorr4g5qC85byPQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihCDorr4g5qC85byPIjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnNwYW4uQ2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOaWh+Wt lyBDaGFyMSI7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5paH5a2XOw0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5DaGFyMg0KCXttc28tc3R5bGUtbmFtZToi 5om55rOo5qGGIOaWh+acrENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSwgSmVvbmct ZG9uZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmsgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+WW91IGFkZHJlc3MgbW9zdCBvZiBteSBjb21tZW50cyBleGNlcHQgb25lLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5Gb3Igc2VjdGlvbiA1LjIsIGxhc3QgYnVsbGV0LCBjYW4geW91IHBvaW50IG1l IHdoZXJlIFJGQzU3MTIgYW5kIFJGQzMyMDkgZGVhbCB3aXRoIHRoZSBjYXNlIHdoZXJlIHJlc291 cmNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5hcmUgb3ZlciBzdWJzY3JpYmVkPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5J dCBpcyBiZXR0ZXIgdG8gc2F5IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj7igJw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPnByb3RlY3RlZCB0cmFmZmljIFNIT1VMRCBiZSB0cmVhdGVk IGFzIGRlZmluZWQgaW4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnNlY3Rpb24geHggb2YN Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPls8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM1NzEyIiB0aXRsZT0iJnF1b3Q7TVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nIFNv ZnQgUHJlZW1wdGlvbiZxdW90OyI+UkZDNTcxMjwvYT5dIG9yPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5zZWN0aW9uIHh4IG9mPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7IFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMjA5IiB0 aXRsZT0iJnF1b3Q7UlNWUC1URTogRXh0ZW5zaW9ucyB0byBSU1ZQIGZvciBMU1AgVHVubmVscyZx dW90OyI+UkZDMzIwOTwvYT5dPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LVFpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUnlvbywgSmVvbmctZG9uZyBbbWFpbHRvOnJ5 b29AZXRyaS5yZS5rcl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMDYsIDIw MTQgMTE6MTAgQU08YnI+DQo8Yj5Ubzo8L2I+IFFpbiBXdTsgbXBsc0BpZXRmLm9yZzsgbXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFttcGxzXSB3Z2xj IG9uIGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBpZD0iZXpGb3JtUHJvY19kaXYiPg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+UWluLCB0aGFua3MgZm9yIHlv dXIgY29tbWVudHMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+UGxlYXNlLCBzZWUgaW4gbGluZXMgLi4uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+QmVzdCByZWdhcmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkplb25nLWRvbmc8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJNYWlsU2lnbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDox NS4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9 IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2xpbmUtaGVpZ2h0 OjE1LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbSA6DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90O1FpbiBXdSZxdW90OyAmbHQ7YmlsbC53 dUBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAxMy0xMi0xNiAxNjoyNTo0OSAo ICYjNDM7MDk6MDAgKTxicj4NCjxiPlRvIDogPC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0 Zi5vcmcmZ3Q7LCBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyAmbHQ7bXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2MgOiA8L2I+PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5b bXBsc10gd2dsYyBvbiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50czxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkhpLGFsbDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBo YXZlIHJldmlld2VkIGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLiBIZXJlIGFyZSBh IGZldyBjb21tZW50cyBJIGhhdmUgYmVsb3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEuIEFi c3RyYWN0IHNhaWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAnDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5UaGlzIGRvY3VtZW50IHByZXNlbnRzIHRoZSBiYXNpYyBuZXR3b3JrIG9iamVjdGl2 ZXMgZm9yIHRoZSBiZWhhdmlvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vZiBzaGFyZWQgbWVz aCBwcm90ZWN0aW9uIChTTVApIG5vdCBiYXNlZCBvbiBjb250cm9sLXBsYW5lIHN1cHBvcnQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCdPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPltRaW5dOjwvc3Bhbj4gQ2FuIFNNUCBiZWhhdmlvciBiZSBiYXNlZCBvbiBtYW5hZ2Vt ZW50IHBsYW5lLCBpZiBub3QsIHdoeSBub3Qgc2F5IHRoZSBTTVAgYmVoYXZpb3IgaXMgYmFzZWQg b24gZGF0YS1wbGFuZSBzdXBwb3J0IGRpcmVjdGx5Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iY29s b3I6Ymx1ZSI+W0plb25nLWRvbmddIFNNUCBpcyBhIGRhdGEgcGxhbmUgcHJvdG9jb2wsIHdoaWNo IG1heSBuZWVkJm5ic3A7c29tZSBzdXBwb3J0cyBmcm9tIG1hbmFnZW1lbnQgcGxhbmUgZm9yIGNv bmZpZ3VyYXRpb24sJm5ic3A7YWxhcm0sIGV0Yy4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij4yLiBTZWN0aW9uIDEsIFBhcmFncmFwaCB0d28gc2FpZDo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQiPuKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1QTFMgcHJvdmlkZXMgY29udHJvbC1wbGFuZSB0 b29scyB0byBzdXBwb3J0IHZhcmlvdXMgc3Vydml2YWJpbGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgc2NoZW1lcyAoRWRpdG9yJ3Mgbm90ZSAtIGFkZCByZWZlcmVuY2Vz KS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+4oCdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij5bUWluXTog V2hhdCByZWZlcmVuY2Ugc2hvdWxkIGJlIHB1dCBoZXJlIG5lZWRzIHRvIGJlIGZpeGVkLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPltKZW9uZy1kb25nXSBZZXMsIGl0IG5lZWRzIHRv IGJlIGZpeGVkLiBBIGNhbmRpZGF0ZSBtaWdodCBiZSBSRkMgNDQyNiAtIEdNUExTIFJlY292ZXJ5 IEZ1bmN0aW9uYWwgU3BlY2lmaWNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdCI+My4gU2VjdGlvbiAxLCBQYXJhZ3JhcGggdGhyZWUgc2FpZDo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPuKA nDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPldoZW4gY29uc2lkZXJpbmcgYSBmdWxsLW1lc2ggbmV0d29yayBh bmQgdGhlIHByb3RlY3Rpb24gb2YgZGlmZmVyZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBwYXRocyB0aGF0IGNyaXNzLWNyb3NzIHRoZSBtZXNoLCBpdCBpcyBwb3NzaWJs ZSB0byBwcm92aWRlIGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBhY2Nl cHRhYmxlIGxldmVsIG9mIHByb3RlY3Rpb24gd2hpbGUgY29uc2VydmluZyB0aGUgYW1vdW50IG9m PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwcm90ZWN0aW9uIHJlc291cmNl cyBuZWVkZWQgdG8gcHJvdGVjdCB0aGUgZGlmZmVyZW50IGRhdGEgcGF0aHMuJm5ic3A7DQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij5bUWluXTog SXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoYXQNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Y3Jpc3MtY3Jvc3MgaXM/IFdvdWxkIGl0IGJlIGdvb2QgdG8g YWRkIGEgcmVmZXJlbmNlIGZvciDigJxjcmlzcy1jcm9zc+KAnSBoZXJlPzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5bSmVvbmctZG9uZ10mbmJzcDsgJnF1b3Q7Y3Jpc3Mt Y3Jvc3MmcXVvdDsgZnJvbSBPeGZvcmQgRGljdGlvbmFyaWVzOjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibHVlIj4mbmJzcDsodmVyYiApIFt3aXRoIG9iamVjdF0gZm9ybSBhIHBh dHRlcm4gb2YgaW50ZXJzZWN0aW5nIGxpbmVzIG9yIHBhdGhzIG9uIChhIHBsYWNlKTsgdGhlIGdy ZWVuIGhpbGwgd2FzIGNyaXNzLWNyb3NzZWQgd2l0aCBhIG5ldHdvcmsgb2Ygc2hlZXAgdHJhY2tz LCZuYnNwOyZuYnNwO1tubyBvYmplY3RdOiB0aGUgc21hbGxlciBzdHJlZXRzIGNyaXNzLWNyb3Nz ZWQNCiBpbiBhIGdyaWQgcGF0dGVybjsgbW92ZSBvciB0cmF2ZWwgYXJvdW5kIChhIHBsYWNlKSBi eSBnb2luZyBiYWNrIGFuZCBmb3J0aCByZXBlYXRlZGx5OiB0aGUgUHJlc2lkZW50IGNyaXNzLWNy b3NzZWQgQW1lcmljYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij40LlNlY3Rpb24gNCwgaXQgc2FpZDo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPuKAnDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDtIYXJkIFByZWVtcHRpb24m cXVvdDsgcmVxdWlyZXMgdGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9ycyBhdCB0aGUgaW5ncmVz cyBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5lYWNoIHNoYXJlZCBzZWdtZW50IHRvIGVuZm9y Y2Ugd2hpY2ggYmFja3VwIHBhdGggaGFzIHRoZSBoaWdoZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnByaW9yaXR5IHdoZW4gY29tbWl0dGluZyBwcm90ZWN0aW9uIHJlc291cmNlcywgdGhlIG90 aGVycyBiZWluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5wcmVlbXB0ZWQuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJ08L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvQ29tbWVudFRleHQiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+W1Fpbl06PC9zcGFuPiBJcyBzZWxlY3RvciBvbmUgb2YgcHJvdGVjdGlvbiBlbmRw b2ludHM/IElzIHNlbGVjdG9yIGJlbG9uZyB0byBzaGFyZWQgc2VnbWVudCBvcg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij51bnNoYXJlZDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Db21tZW50VGV4dCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5wb3J0aW9ucyBvZiBzZWdtZW50PC9zcGFuPj8gSXMgc2VsZWN0b3IgaW4gdGhlIHByb3Rl Y3Rpb24gcGF0aCBvciB3b3JraW5nIHBhdGg/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij5JdCBpcyBiZXR0ZXIgdG8gYmUgY2xl YXIgaW4gdGhlIHRleHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+W0plb25nLWRv bmddU2VsZWN0b3IgaXMgaW4gdGhlIGVuZHBvaW50cyBvZiB0aGUgd29ya2luZyBhbmQgcHJvdGVj dGlvbiBwYXRocyBhbmQgc2VsZWN0cyB0aGUgdHJhZmZpYyBmcm9tIG9uZSBvZiB0aGUmbmJzcDtw YXRocy4gUGxlYXNlIHNlZSBSRkMgNDQyNywgd2hpY2ggaXMgbm9ybWF0aXZlbHkgcmVmZXJyZWQm bmJzcDtieSB0aGlzIGRvY3VtZW50Lg0KICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0Ij41LiBTZWN0aW9uIDUuMSwgbGFzdCBwYXJhZ3JhcGggc2FpZDo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4w cHQiPuKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoYXQgaXMgcmVxdWlyZWQgaXMgYSBwcmVlbXB0aW9u IG1lY2hhbmlzbSB0bzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW1wbGVt ZW50IGJ1c2luZXNzIHByaW9yaXR5IHdoZW4gbXVsdGlwbGUgZmFpbHVyZSBzY2VuYXJpb3Mgb2Nj dXIuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+W1Fpbl06IElzIHBy aW9yaXR5IGJ1c2luZXNzIHJlbGF0ZWQgb3IgcG9saWN5IGRlY2lzaW9uIHJlbGF0ZWQ/IENhbiBi b3RoIHByZWVtcHRpb24gYW5kIHByaW9yaXR5DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPnBvbGljeSBkZWNpc2lvbiByZWxh dGVkPyBJdCBpcyBub3QgY2xlYXIgdG8gbWUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBidXNpbmVz cyByZWxhdGVkIGFuZCBwb2xpY3kNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+ZGVjaXNpb24gcmVsYXRlZC4gV291bGQgeW91 IGxpa2UgdG8gY2xhcmlmeSBhIGxpdHRsZSBiaXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 Ymx1ZSI+W0plb25nLWRvbmddJm5ic3A7VGhlIGJ1c2luZXNzIHByaW9yaXR5IGNhbiBiZSB0aG91 Z2h0IGFzIHRoZSBwcmlvcml0eSBhc3NpZ25lZCB0byBhIHBhdGggYWNjb3JkaW5nIHRvIHRoZSBw b2xpY3kgb2YgbmV0d29yayBhZG1pbmlzdHJhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdCI+Ni4gU2VjdGlvbiA1LjIsIDE8c3VwPnN0PC9zdXA+Jm5ic3A7IHBh cmFncmFwaCBzYWlkOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE1LjBwdCI+4oCcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Rm9yIHRob3NlIG5ldHdv cmtzLCBpbiBwYXJ0aWN1bGFyIGZvciBuZXR3b3JrcyB0aGF0IHN1cHBvcnQgdGhlIHJlcXVpcmVt ZW50cyBpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bUkZDNTY1NF1bYW5kIGluIHBhcnRpY3Vs YXIgc3VwcG9ydCBmb3IgcmVxdWlyZW1lbnQgNThdLCB0aGF0IHJlcXVpcmU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+dGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIHByb3RlY3Rpb24gcmVzb3VyY2Vz LCBpLmUuIGhhcmQgcHJlZW10aW9uLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50aGUgZm9sbG93 aW5nIGJlaGF2aW9yIFNIT1VMRCBiZSBzdXBwb3J0ZWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+4oCdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 Ij5bUWluXTogcy9wcmVlbXRpb24vcHJlZW1wdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsdWUiPltKZW9uZy1kb25nXSBUaGlzIHNob3VsZCBiZSBmaXhlZC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+Ny5TZWN0aW9uIDUuMiwgbGFzdCBidWxsZXQgc2Fp ZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQiPuKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkR1cmluZyBwcmVlbXB0aW9uLCBpZiB0aGVy ZSBpcyBhbiBvdmVyIHN1YnNjcmlwdGlvbiBvZiByZXNvdXJjZXM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+cHJvdGVjdGVkIHRyYWZmaWMgU0hPVUxEIGJlIHRyZWF0ZWQgYXMgZGVmaW5lZCBpbiBb UkZDNTcxMl0gb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W1JGQzMyMDldPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dCI+4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W1Fpbl1zL1tSRkMzMjA5XS9bUkZDMzIwOV0uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W1Fpbl06IEl0IGlzIG5vdCBjbGVhciB0 byBtZSB3aHkgc29mdCBwcmVlbXB0aW9uIGJlaGF2aW9yIGRlZmluZWQNCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5pbiBSRkM1NzEyIHNob3VsZCBiZSBhcHBsaWVkIHRvIGhhcmQgcHJlZW1wdGlv biBwYXJ0IG9mIHNlY3Rpb24NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij41LjIgZGVzY3JpYmVk IGluIHRoaXMgZG9jdW1lbnQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+aW48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JcyB0 aGVyZSBhbnkgY29tbW9uIGJlaGF2aW9yIGJldHdlZW4gc29mdCBwcmVlbXB0aW9uIGFuZCBoYXJk IHByZWVtcHRpb24/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkl0IGlzIGJldHRlciB0byBiZSBj bGVhciBhYm91dCB0aGlzIGluIHRoZSB0ZXh0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibHVlIj5bSmVvbmctZG9uZ10gVGhlIGxhc3QgYnVsbGV0IGFwcGxpZXMgZHVyaW5nIHBy ZWVtcHRpb24uIEl0IG1lYW5zIHRoYXQgd2hpbGUgdGhlIHByZWVtcHRpb24gYWN0aW9uIGlzIGlu IHByb2dyZXNzLCB0aGUgdHJhZmZpYyBzaG91bGQgYmUmbmJzcDsmbmJzcDt0cmVhdGVkIGFzIHNw ZWNpZmllZCBpbiB0aGUgbGFzdCBidWxsZXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij44LlNlY3Rpb24gNS41LCAxPHN1cD5zdDwvc3VwPiBwYXJh Z3JhcGggc2FpZDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCcPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyBQcm90ZWN0aW9uIHN3aXRjaGluZyB0aW1lIHJlZmVycyB0byB0 aGUgdHJhbnNmZXIgdGltZSAoVHQpIGRlZmluZWQgaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IFtHLjgwOC4xXSBhbmQgcmVjb3Zlcnkgc3dpdGNoaW5nIHRpbWUgZGVmaW5l ZCBpbiBbUkZDNDQyN10sIGFuZCBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgZGVmaW5lZCBhcyB0aGUgaW50ZXJ2YWwgYWZ0ZXIgYSBzd2l0Y2hpbmcgdHJpZ2dlciBpcyBp ZGVudGlmaWVkIHVudGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGUg dHJhZmZpYyBiZWdpbnMgdG8gYmUgdHJhbnNtaXR0ZWQgb24gdGhlIHByb3RlY3Rpb24gcGF0aC4m bmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAnTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltRaW5dOjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5XaGF0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiDigJxwcm90ZWN0aW9uIHN3aXRjaGlu ZyB0aW1l4oCdDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YW5kIOKAnHRyYW5zZmVyIHRpbWXi gJ0gb3Ig4oCccmVjb3Zlcnkgc3dpdGNoaW5nIHRpbWXigJ08L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Q2FuIEkgcGFyc2UgdGhpcyByZWxhdGlvbiBhczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ UHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGltZSA9IHRoZSB0cmFuc2ZlciB0aW1lICYjNDM7IHJlY292 ZXJ5IHN3aXRjaGluZyB0aW1lPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVl Ij5bSmVvbmctZG9uZ10gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGltZSA9IHRyYW5zZmVyIHRpbWUg aW4gRy44MDguMSA9IHJlY292ZXJ5IHN3aXRjaGluZyB0aW1lIGluIFJGQzQ0Mjc8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0Ij4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+OS5TZWN0aW9u IDUuNSwgMTxzdXA+c3Q8L3N1cD4gcGFyYWdyYXBoIHNhaWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPuKAnDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgSW4gb3JkZXIgdG8g cHJldmVudCBtdWx0aXBsZSBzd2l0Y2hpbmcgYWN0aW9ucyBmb3IgYSBzaW5nbGUgc3dpdGNoaW5n PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0cmlnZ2VyLCBTTVAgU0hPVUxE IGJlIGNvbnRyb2xsZWQgYnkgYSBob2xkLW9mZiB0aW1lciB0aGF0IHdvdWxkPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBhbGxvdyBsb3dlciBsZXZlbCBtZWNoYW5pc21zIHRv IGNvbXBsZXRlIHRoZWlyIHN3aXRjaGluZyBhY3Rpb25zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyBiZWZvcmUgaW52b2tpbmcgU01QIHByb3RlY3Rpb24gYWN0aW9ucy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJ08L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+W1Fpbl06V2h5IGFyZSB0aGVyZSBtdWx0aXBsZSBzd2l0Y2hpbmcgYWN0aW9ucyBmb3Ig YSBzaW5nbGUgc3dpdGNoaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnRyaWdnZXI/IElzbuKA mXQgb25lIHN3aXRjaGluZyB0cmlnZ2VyIGNvcnJlc3BvbmRpbmcgdG8gb25lIHN3aXRjaGluZyBh Y3Rpb24/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNhbiB5b3UgZ2l2ZSBhbiBleGFtcGxlIGZv ciB0aGF0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5bSmVvbmctZG9u Z10mbmJzcDtBIHNpbmdsZSBmYWlsdXJlIGNhbiB0cmlnZ2VyIHRoZSBwcm90ZWN0aW9uIHN3aXRj aGluZyBhY3Rpb25zIGJvdGggaW4gc2VydmVyIGxheWVyIChPVE4gZm9yIGV4YW1wbGUpIGFuZCBj bGllbnQgbGF5ZXIgKE1QTFMtVFAgZm9yIGV4YW1wbGUpLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xMC5TZWN0 aW9uIDUuNSwgMXN0IHBhcmFncmFwaCBzYWlkOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEluIG9yZGVyIHRvIHByZXZlbnQg bXVsdGlwbGUgc3dpdGNoaW5nIGFjdGlvbnMgZm9yIGEgc2luZ2xlIHN3aXRjaGluZzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdHJpZ2dlciwgU01QIFNIT1VMRCBiZSBjb250 cm9sbGVkIGJ5IGEgaG9sZC1vZmYgdGltZXIgdGhhdCB3b3VsZDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgYWxsb3cgbG93ZXIgbGV2ZWwgbWVjaGFuaXNtcyB0byBjb21wbGV0 ZSB0aGVpciBzd2l0Y2hpbmcgYWN0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgYmVmb3JlIGludm9raW5nIFNNUCBwcm90ZWN0aW9uIGFjdGlvbnMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+W1Fpbl06V2hhdCBsb3dlciBsZXZlbCBtZWFucz8gV2hhdCB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIGxvdyBsZXZlbA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmFuZCBoaWdo IGxldmVsPyBEb2VzIHRoaXMgcmVsYXRlIHRvIGxvd2VyIHByaW9yaXR5IG9yIGhpZ2ggcHJpb3Jp dHk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPltKZW9uZy1kb25nXSBT ZWUgdGhlIGFib3ZlIGFuc3dlci4mbmJzcDsgRm9yIGJldHRlciBjbGFyaWZpY2F0aW9uLCB3ZSBj YW4gcmV3cml0ZSBpdCBzb21ldGhpbmcgbGlrZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibHVlIj4mbmJzcDsmbmJzcDsgJnF1b3Q7SW4gb3JkZXIgdG8gcHJldmVudCBtdWx0aXBsZSBz d2l0Y2hpbmcgYWN0aW9ucyBmb3IgYSBzaW5nbGUgc3dpdGNoaW5nPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibHVlIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDsm bmJzcDsgdHJpZ2dlcg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+d2hlbiB0aGVyZSBhcmUg bXVsdGlwbGUgbGF5ZXJzJm5ic3A7b2YmbmJzcDtuZXR3b3Jrcyw8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6Ymx1ZSI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyBTTVAgU0hPVUxEIGJlIGNvbnRyb2xs ZWQgYnkgYSBob2xkLW9mZiB0aW1lciB0aGF0IHdvdWxkPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibHVlIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsg YWxsb3cgbG93ZXINCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZWQiPmxheWVyIDwvc3Bhbj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsdWUiPm1lY2hhbmlzbXMgdG8gY29tcGxldGUgdGhlaXIgc3dpdGNoaW5n IGFjdGlvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyBiZWZvcmUgaW52b2tpbmcgU01QIHByb3Rl Y3Rpb24gYWN0aW9ucy4mcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PbiBUdWUsIERlYyAxMCwgMjAxMyBhdCA4OjM3 IEFNLCBMb2EgQW5kZXJzc29uICZsdDtsb2EgYXQgcGkubnUmZ3Q7IHdyb3RlOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mZ3Q7IFdvcmtpbmcgR3JvdXAsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZndDs8L3NwYW4+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0Ozwvc3Bhbj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mZ3Q7IHRoaXMgaXMgdG8gc3RhcnQgYSAyIHdlZWsgd29ya2luZyBncm91 cCBsYXN0IGNhbGwgb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBkcmFmdC1pZXRmLW1w bHMtc21wLXJlcXVpcmVtZW50cy0wMi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0Ozwvc3Bh bj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50 IGFuZCBzZW5kIGNvbW1lbnRzIHRvIHRoZSBNUExTIFdHPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZndDsgbWFpbGluZyBsaXN0IChtcGxzIGF0IGlldGYub3JnKSAuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZndDs8L3NwYW4+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBUaGVyZSBhcmUg bm8gSVBSIGNsYWltcyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZndDs8L3NwYW4+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBBbGwgdGhlIGF1dGhv cnMgaGF2ZSBzdGF0ZWQgb24gdGhlIE1QTFMgd2cgbWFpbGluZyBsaXN0IHRoYXQgdGhleTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IGFyZSB1bmF3YXJlIG9mIGFueSBJUFJzIHRoYXQgcmVs YXRlIHRvIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8L3NwYW4+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwg ZW5kcyBNb25kYXkgRGVjZW1iZXIgMjcgLSAyMDEzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m Z3Q7PC9zcGFuPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgWWVzIC0gdGhhdCBpcyBpcyBp biB0aGUgbWlkZGxlIG9mIHRoZSBIb2xpZGF5IHNlYXNvbiwgYnV0IGF0IGxlYXN0PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZndDsgb25lIHdnIGNoYWlyIHdpbGwgYmUgd29ya2luZyBwYXJ0bHkg YmV0d2VlbiBYbWFzIGFuZCBOZXcgWWVhciBhbmQgYmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jmd0OyBhYmxlIHRvIGV2YWx1YXRlIG5leHQgc3RlcHMuIFdlIGNvdW50IG9uIG1vc3QgcmV2aWV3 cyB0YWtpbmcgcGxhY2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBpbiB0aGUgYWxtb3N0 IHR3byB3ZWVrcyBiZWZvcmUgWG1hcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0Ozwvc3Bh bj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IC9Mb2E8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA43C7037Ankgeml501mbschi_-- From sm@elandsys.com Sun Jan 5 03:25:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5761AE0F2 for ; Sun, 5 Jan 2014 03:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538] 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 2FfuQuVGNcjv for ; Sun, 5 Jan 2014 03:25:00 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DA31AE0EC for ; Sun, 5 Jan 2014 03:25:00 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.232.224]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s05BOdSa027968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Jan 2014 03:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1388921091; bh=C24zzwxxRxf+9SJLGQ20rJ2eTug1jIdY+zSD+MWONxI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ed+SYE8ci4WoyI0ppL8In58nGnXNoQXAF6Eg5bE3pTjNGPdMFoYTm8aMEPIDukI+p BTfM13/tlQokW2pZKStU1OugcmWFWHlpBneMAN+LpXCHeJqEE9zBulbFLedRhb32QI bmExN8xzRIu/lmfKUUi7Oz4Enz93tSznHgsl1DBw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1388921091; i=@elandsys.com; bh=C24zzwxxRxf+9SJLGQ20rJ2eTug1jIdY+zSD+MWONxI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XOSyPfFKH4fYHHcBU5yY+ICzYrQxtdElvWfQuIKsYbI+J5wBJA7XHpzNx01XUNL/C MDG6PREPw8QFONwZ6rtjBuxsGxeAfgqXItwiGyYoOG24NV5N2ZnpQK8oXK+0rChPdZ OGtba8ZU84L7WQBvCbjjY4kya7Gty0ZJf8CZHITA= Message-Id: <6.2.5.6.2.20140104234315.0b5f4140@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 05 Jan 2014 00:11:47 -0800 To: mpls@ietf.org From: S Moonesamy In-Reply-To: <20140102151605.2998.36196.idtracker@ietfa.amsl.com> References: <20140102151605.2998.36196.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Mon, 06 Jan 2014 06:54:30 -0800 Cc: draft-ietf-mpls-moving-iana-registries.all@tools.ietf.org Subject: Re: [mpls] Last Call: (Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 11:25:02 -0000 Hello, At 07:16 02-01-2014, The IESG wrote: >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Moving Generic Associated Channel (G-ACh) IANA Registries to a New > Registry' > as Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the From the Introduction section: 'RFC 5586 generalized the PW-ACH into the G-ACh. However, registries and allocations of G-ACh namespaces had been distributed throughout different registries. This document coalesces these into a new "Generic Associated Channel (G-ACh) Parameters" registry in the "Multiprotocol Label Switching Architecture (MPLS)" name space. This is an update to RFC RFC 5586 [RFC5586].' The draft is about IANA actions. I don't see why the document is being considered as a Proposed Standard. In Section 3 it is mentioned that the updates RFC 5586 by renaming the Pseudowire Associated Channel Types. That may be related to the IANA Considerations section in RFC 5586. As there isn't any text in the draft suggesting that the requirements in RFC 5586 are impacted by this update I conclude that this draft does not change the technical part of RFC 5586. Regards, S. Moonesamy From yshen@juniper.net Mon Jan 6 09:24:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BF61AE115 for ; Mon, 6 Jan 2014 09:24:11 -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 9HkUE_w3R8QY for ; Mon, 6 Jan 2014 09:24:05 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBF41AE10E for ; Mon, 6 Jan 2014 09:24:04 -0800 (PST) Received: from mail158-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE020.bigfish.com (10.243.66.83) with Microsoft SMTP Server id 14.1.225.22; Mon, 6 Jan 2014 17:23:56 +0000 Received: from mail158-co1 (localhost [127.0.0.1]) by mail158-co1-R.bigfish.com (Postfix) with ESMTP id 3D58D4800DB; Mon, 6 Jan 2014 17:23:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz9371Ic85fh148cIec9I11f6N4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail158-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=yshen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(52604005)(377454003)(189002)(37854004)(199002)(45984002)(164054003)(74706001)(18717965001)(49866001)(79102001)(47736001)(54356001)(76482001)(19300405004)(74366001)(51856001)(15202345003)(53806001)(63696002)(19580395003)(74876001)(46102001)(81342001)(33646001)(19609705001)(47446002)(65816001)(74662001)(74316001)(83322001)(76576001)(87936001)(85306002)(74502001)(4396001)(80022001)(80976001)(66066001)(16236675002)(77982001)(59766001)(85852003)(81816001)(69226001)(76786001)(47976001)(81542001)(50986001)(76796001)(19580405001)(15975445006)(54316002)(56776001)(83072002)(90146001)(31966008)(2656002)(81686001)(87266001)(56816005)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB727; H:BY2PR05MB728.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail158-co1 (localhost.localdomain [127.0.0.1]) by mail158-co1 (MessageSwitch) id 1389029032304603_19491; Mon, 6 Jan 2014 17:23:52 +0000 (UTC) Received: from CO1EHSMHS012.bigfish.com (unknown [10.243.78.246]) by mail158-co1.bigfish.com (Postfix) with ESMTP id 445E1C4004A; Mon, 6 Jan 2014 17:23:52 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS012.bigfish.com (10.243.66.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 6 Jan 2014 17:23:48 +0000 Received: from BY2PR05MB727.namprd05.prod.outlook.com (10.141.223.23) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.395.1; Mon, 6 Jan 2014 17:23:46 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB727.namprd05.prod.outlook.com (10.141.223.23) with Microsoft SMTP Server (TLS) id 15.0.842.7; Mon, 6 Jan 2014 17:23:44 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0842.003; Mon, 6 Jan 2014 17:23:44 +0000 From: Yimin Shen To: Huaimo Chen , "Tarek Saad (tsaad)" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHO9zz2D8OUboE/BU63IW10jjHvHppWOpUAgACbxPCAHJIbgP//80tQgAAog7CABJK/4A== Date: Mon, 6 Jan 2014 17:23:44 +0000 Message-ID: <878d09a23e6442ce90376433b9d88148@BY2PR05MB728.namprd05.prod.outlook.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C20383@sjceml501-mbs.china.huawei.com> <769a7465342c40109412a7451aac873f@BY2PR05MB728.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445C2EE66@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C2EE66@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 0083A7F08A Content-Type: multipart/alternative; boundary="_000_878d09a23e6442ce90376433b9d88148BY2PR05MB728namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 17:24:11 -0000 --_000_878d09a23e6442ce90376433b9d88148BY2PR05MB728namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Huaimo, In context label switching, if traffic doesn't have a service label, a prot= ector can simply perform IP lookup as default. Thanks, /Yimin From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, January 03, 2014 3:10 PM To: Yimin Shen; Tarek Saad (tsaad); mpls@ietf.org Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Yimin, Thanks for your comments! It seems that an LSP may carry the traffic without any service label. In th= is case, how do you protect its egress failure using its service label as y= ou mentioned that your service protect drafts solve egress protection? Yimin, our egress local protect draft has section 4 "Considering Applicatio= n Traffic" talking about how to provide the service protection. In fact, with the egress local protection proposed in our draft, the servic= e traffic with a service label can be easily protected against the failure = of the primary egress. Thus both the traffic without any service label and = the traffic with a service label are protected for the failure of the prima= ry egress. BTW, the service protection proposed in your service protection draft ht= tp://tools.ietf.org/search/draft-minto-2547-egress-node-fast-protection-02 needs another LSP egress protection draft raft-minto-rsvp-lsp-egress-fast-p= rotection-01, which requires both IGP and RSVP-TE extensions. Best Regards, Huaimo From: Yimin Shen [mailto:yshen@juniper.net] Sent: Friday, January 03, 2014 12:54 PM To: Tarek Saad (tsaad); Huaimo Chen; mpls@ietf.org Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi, I concur with Tarek's comment on this. In fact, the following drafts have b= een proposed to provide egress protection for the inner labels (i.e. layer-= 2/3 VPN service labels). These drafts solve egress protection from a differ= ent angle, i.e. on a per-service basis, because ultimately it is the servic= e label that must be protected. As I've communicated with Huaimo, this is a= n important piece that is missing in his draft. Also, once service labels c= an be protected, there is no need for an RSVP (or LDP) extension for bypass= tunnel signaling. This is because upstream labels, UHP, context label swi= tching, etc have already been defined by MPLS WG, and hence the existing by= pass path computation and signaling mechanisms are already sufficient. http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-00 http://tools.ietf.org/search/draft-minto-2547-egress-node-fast-protection-0= 2 Thanks, /Yimin From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad) Sent: Friday, January 03, 2014 11:45 AM To: Huaimo Chen; mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi Huaimo, Thanks. See inline below. 2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not = need any downstream label..." i. What if the LSP is carrying non-IP traffic? Ii. There are cases where non-NULL label is needed at the egress- e.g., for= collecting rx stats, for doing RPF check, etc.-- hence above statement is = not necessarily true Huaimo: This ("For a primary LSP carrying IP packets, the PLR does not nee= d any downstream label...") may be changed to something like: "For a prima= ry LSP, if the PLR (the upstream node of the primary egress of the LSP) doe= s the PHP for the LSP, it redirects the traffic from the primary LSP into = the backup LSP to the backup egress when it detects the failure of the prim= ary egress; otherwise, it redirects the packets from the primary LSP into t= he backup LSP to backup egress using the primary LSP label from the primary= egress as an inner label. (At the backup egress, it uses the backup LSP la= bel as a context label to find the LFIB for the primary egress and uses the= inner label under the context to handle the packets such as collecting rx = stats and forwarding the packets, which are similar to the behaviors at the= primary egress.)" What are your suggestions and comments on this? [TS]: yes, using the primary egress label as inner label after rerouting (l= ocal repair) over the facility bypass may work. However, additional mechani= cs will be required to synchronize the label assignment between the primary= and backup egress nodes. Also, will necessitate backup egress node to supp= ort upstream assigned labels, and facility bypass must be UHP to provide co= ntext for the upstream label. Regards, Tarek From: Huaimo Chen > Date: Monday, 16 December, 2013 10:55 PM To: Tarek Saad >, "mpls@ietf.org" > Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Tarek, Thank you very much for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Sunday, December 15, 2013 10:09 PM To: Huaimo Chen; mpls@ietf.org Cc: Raveendra Torvi Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Huaimo, Thanks for making the changes. I still have the following comments: 1. Section 3.1: it is not still clear why the ingress has to specify the ba= ckup path (in form of EB-SERO) from previous hop PLR to the backup egress n= ode Huaimo: The ingress does not have to specify the backup path (in form of EB= -SERO) from previous hop PLR to the backup egress node. We will revise the = draft accordingly. 2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not = need any downstream label..." i. What if the LSP is carrying non-IP traffic? Ii. There are cases where non-NULL label is needed at the egress- e.g., for= collecting rx stats, for doing RPF check, etc.-- hence above statement is = not necessarily true Huaimo: This ("For a primary LSP carrying IP packets, the PLR does not nee= d any downstream label...") may be changed to something like: "For a prima= ry LSP, if the PLR (the upstream node of the primary egress of the LSP) doe= s the PHP for the LSP, it redirects the traffic from the primary LSP into = the backup LSP to the backup egress when it detects the failure of the prim= ary egress; otherwise, it redirects the packets from the primary LSP into t= he backup LSP to backup egress using the primary LSP label from the primary= egress as an inner label. (At the backup egress, it uses the backup LSP la= bel as a context label to find the LFIB for the primary egress and uses the= inner label under the context to handle the packets such as collecting rx = stats and forwarding the packets, which are similar to the behaviors at the= primary egress.)" What are your suggestions and comments on this? 3. Incidentally, "draft-minto-rsvp-lsp-egress-fast-protection-03" is also p= roposing a mechanism to achieve this protection using proxy/virtual egress = node - although little mention to P2MP. Have you considered if there's any = overlap there? Huaimo: This draft tries to provide the P2P TE LSP egress protection using = proxy/virtual egress node (proxy method). It needs extensions to the IGP (I= SIS and OSPF) in addition to extensions to RSVP-TE and has a number of limi= tations (The top of page 9 in the draft lists four limitations/caveats). Regards, Tarek From: Huaimo Chen > Date: Thursday, 12 December, 2013 8:20 AM To: "mpls@ietf.org" > Cc: Tarek Saad >, Raveendra Torvi <= rtorvi@juniper.net> Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection draft-chen-mpls-p2mp-egress-protection was reviewed by the MPLS Review team= prior to being polled for WG adoption. The authors have updated the draft = according to the comments. We have had responses from some of the reviewers= that they are comfortable with how the comments have been addressed. We wo= uld like to have the same response from the other two reviewers. Best Regards, Huaimo --_000_878d09a23e6442ce90376433b9d88148BY2PR05MB728namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Huaimo,=

 <= /p>

In context label switchin= g, if traffic doesn’t have a service label, a protector can simply pe= rform IP lookup as default.

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Friday, January 03, 2014 3:10 PM
To: Yimin Shen; Tarek Saad (tsaad); mpls@ietf.org
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

Hi Yimin,

 <= /p>

Thanks for your comments!

It seems that an LSP may carry the traffic without any service label. In= this case, how do you protect its egress failure using its service label as you mentioned that your service protect drafts solve egre= ss protection?

Yimin, our egress local protect draft has section 4 “Considering A= pplication Traffic” talking about how to provide the service protecti= on.

In fact, with the egress local protection proposed in our draft, the ser= vice traffic with a service label can be easily protected against the failure of the primary egress. Thus both the traffic without a= ny service label and the traffic with a service label are protected for the= failure of the primary egress.

BTW, the service protection  proposed in your service protection dr= aft   http://tools.ietf.org/search/= draft-minto-2547-egress-node-fast-protection-02

needs another LSP egress protection draft raft= -minto-rsvp-lsp-egress-fast-protection-01, w= hich requires both IGP and RSVP-TE extensions.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Yimin Sh= en [mailto:yshen@juniper.net]
Sent: Friday, January 03, 2014 12:54 PM
To: Tarek Saad (tsaad); Huaimo Chen; mpls@ietf.org
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

Hi,

 <= /p>

I concur with Tarek’= ;s comment on this. In fact, the following drafts have been proposed to pro= vide egress protection for the inner labels (i.e. layer-2/3 VPN service labels). These drafts solve egress protection from a different ang= le, i.e. on a per-service basis, because ultimately it is the service label= that must be protected. As I’ve communicated with Huaimo, this is an= important piece that is missing in his draft. Also, once service labels can be protected, there is no need for an= RSVP (or LDP) extension for bypass tunnel signaling. This is  because= upstream labels, UHP, context label switching, etc have already been defin= ed by MPLS WG, and hence the existing bypass path computation and signaling mechanisms are already sufficient. <= o:p>

 <= /p>

http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-p= rotection-00

http://tools.ietf.org/search/draft-minto-2547-egress= -node-fast-protection-02

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad)
Sent: Friday, January 03, 2014 11:45 AM
To: Huaimo Chen; mpls@ietf.org<= br> Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi Huaimo,

 

Thanks. See inline below.

 

2. Section 3.2.2: "For a primary LSP= carrying IP packets, the PLR does not need any downstream label…&quo= t;

    i. What if the LSP is carry= ing non-IP traffic?

Ii. There are cases where non-NULL label is needed= at the egress— e.g., for collecting rx stats, for doing RPF check, e= tc.-- hence above statement is not necessarily true

Huaimo:  This ("For a primary LSP carrying IP packets, the PLR does not need any downstream la= bel…") may be changed to = something like:  “For a primary LSP, if the PLR (the upstream no= de of the primary egress of the LSP) does the PHP  for the LSP, it redirect= s the traffic from the primary LSP into the backup LSP to the backup egress= when it detects the failure of the primary egress; otherwise, it redirects= the packets from the primary LSP into the backup LSP to backup egress using the primary LSP label from the prima= ry egress as an inner label. (At the backup egress, it uses the backup LSP = label as a context label to find the LFIB for the primary egress and uses t= he inner label under the context to handle the packets such as collecting rx stats and forwarding the packe= ts, which are similar to the behaviors at the primary egress.)” What = are your suggestions and comments on this?

[TS]: yes, using the primar= y egress label as inner label after rerouting (local repair) over the = facility bypass may work. However, additional mechanics will be required to synchronize the label assignment between the primary and ba= ckup egress nodes. Also, will necessitate backup egress node to support ups= tream assigned labels, and facility bypass must be UHP to provide context f= or the upstream label.

 

Regards,<= /p>

Tarek

 

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Monday, 16 December, 2013 10:55 PM
To: Tarek Saad <tsaad@cisco.co= m>, "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

Hi Tarek,

 

Thank you very much for your comments!

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: Tarek Saad (tsaad) [mail= to:tsaad@cisco.com]
Sent: Sunday, December 15, 2013 10:09 PM
To: Huaimo Chen; mpls@ietf.org<= br> Cc: Raveendra Torvi
Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 =

Hi Huaimo,

 

Thanks for making the chang= es. I still have the following comments:=

1. Section 3.1: it is not s= till clear why the ingress has to specify the backup path (in form of EB-SE= RO) from previous hop PLR to the backup egress node

Huaimo: The ingress does = not have to specify the backup path (in form of EB-SERO) from previous hop = PLR to the backup egress node. We will revise the draft accordingly.

 

2. Section 3.2.2: "For= a primary LSP carrying IP packets, the PLR does not need any downstream la= bel…"

    i. What if th= e LSP is carrying non-IP traffic?

Ii. There are cases where non-NULL label is needed at the egress— e.= g., for collecting rx stats, for doing RPF check, etc.-- hence above statement is not necessarily true<= /o:p>

Huaimo:  This ("For a primary LSP carrying IP packets, the= PLR does not need any downstream label…") = may be changed to something like:  “For a primary LSP, if the PL= R (the upstream node of the primary egress of the LSP) does the PHP  f= or the LSP, it redirects the traffic from the primary LSP into the backup LSP to = the backup egress when it detects the failure of the primary egress; otherw= ise, it redirects the packets from the primary LSP into the backup LSP to b= ackup egress using the primary LSP label from the primary egress as an inner label. (At the backup egress, it= uses the backup LSP label as a context label to find the LFIB for the prim= ary egress and uses the inner label under the context to handle the packets= such as collecting rx stats and forwarding the packets, which are similar to the behaviors at the primary = egress.)” What are your suggestions and comments on this?

 

3. Incidentally, "draf= t-minto-rsvp-lsp-egress-fast-protection-03" is also proposing a mechan= ism to achieve this protection using proxy/virtual egress node - = although little mention to P2MP. Have you considered if there's any overlap there?<= /span>

Huaimo: This draft tries = to provide the P2P TE LSP egress protection using proxy/virtual egress node= (proxy method). It needs extensions to the IGP (ISIS and OSPF) in addition to extensions to RSVP-TE and has a number of limitations= (The top of page 9 in the draft lists four limitations/caveats).  

 

Regards,

Tarek

 

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Thursday, 12 December, 2013 8:20 AM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Cc: Tarek Saad <tsaad@cisco.co= m>, Raveendra Torvi <rtorvi= @juniper.net>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

draft-chen-mpls-p2mp-egr= ess-protection was reviewed by the MPLS Review team prior to being polled f= or WG adoption. The authors have updated the draft according to the comment= s. We have had responses from some of the reviewers that they are comfortable with how the comments have been ad= dressed. We would like to have the same response from the other two reviewe= rs.

 =

Best Regards,=

Huaimo=

--_000_878d09a23e6442ce90376433b9d88148BY2PR05MB728namprd05pro_-- From chris75roberts@gmail.com Wed Jan 8 03:11:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0FC1AE2A1 for ; Wed, 8 Jan 2014 03:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Okeb1z1JM05P for ; Wed, 8 Jan 2014 03:11:49 -0800 (PST) Received: from mail-la0-x241.google.com (mail-la0-x241.google.com [IPv6:2a00:1450:4010:c03::241]) by ietfa.amsl.com (Postfix) with ESMTP id ADB401AE27D for ; Wed, 8 Jan 2014 03:11:48 -0800 (PST) Received: by mail-la0-f65.google.com with SMTP id c6so285843lan.8 for ; Wed, 08 Jan 2014 03:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NOo+YLmqXDE6Y+rBvAEujygS30YEripXda3o+vF8wuo=; b=Dufg4WAt6GcvJA/1McOvF5LSulbfwu3WEGkqwoSx9yMJTsCtmGFsfyJy2SX6mJ4Xxr 2fizn1axgRCi6EKpw12V+SN+qslfp1mO5xC/VI9G2IltQWnjxS2z3YW2GTPM7+GnlGce xDkpcf2VMB35nUtPGPNyqicdMFvy+xKxTc3SiQsZiiCtNlRUY1KFvxYBMrBXgk8f79f9 bAfrGfiuMvcQLiYGgprnbGhxPIe95FvaVK2gP3RHjir0+2Squbdbl4wM2Qmh3bHGqgpt QazuRJp9zsqUKKJG+iBO8t/LPDvpEVivD8gsRh5WYtFx9/M1nkzFB9jJyDXvA/98r9N5 5RIQ== MIME-Version: 1.0 X-Received: by 10.112.12.106 with SMTP id x10mr4848226lbb.61.1389179498773; Wed, 08 Jan 2014 03:11:38 -0800 (PST) Received: by 10.112.255.193 with HTTP; Wed, 8 Jan 2014 03:11:38 -0800 (PST) Date: Wed, 8 Jan 2014 11:11:38 +0000 Message-ID: From: Chris Roberts To: mpls@ietf.org Content-Type: multipart/alternative; boundary=001a11c3f1548dc36904ef738e2d Subject: [mpls] draft-wijnands-mpls-mldp-in-band-wildcard-encoding-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 11:14:14 -0000 --001a11c3f1548dc36904ef738e2d Content-Type: text/plain; charset=ISO-8859-1 Hi Authors, I have a query about this draft relating to the use case of (Source, Wildcard Group) as the opaque value TLV. Section 3.2 Wildcard Semantics states the this should be treated this as "the TLV identifies the collection of PIM-SSM trees that have the source address as their root.". However, Section 6 Procedures for Wildcard Group Usage states "the Ingress LSR examines its IP multicast routing table, to find all the IP multicast streams whose IP source address is the address specified in the IP Source Address sub-field of the TLV. All these streams SHOULD be forwarded down the MP-LSP identified by the Opaque Value TLV. Note that some of these streams may have SSM group addresses, while some may have ASM group addresses." This seems to conflict....so an Egress-LSR sending this TLV - should it expect to see just SSM groups or both ASM and SSM? Presumably the latter if no group can be specified? Regards, Chris --001a11c3f1548dc36904ef738e2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Authors,

I = have a query about this draft relating to the use case of (Source, Wildcard= Group) as the opaque value TLV.

Section 3.2 Wildcard S= emantics states the this should be treated this as "the TLV=A0identifi= es the collection of PIM-SSM trees that have the source address as their ro= ot.".

However, Section 6=A0Procedures for Wild= card Group Usage=A0states "the Ingress LSR examines its IP multicast r= outing table, to find all the IP multicast streams whose IP source address = is the address specified in the IP Source Address sub-field of the TLV. All= these streams SHOULD be forwarded down the MP-LSP identified by the Opaque= Value TLV. Note that some of these streams may have SSM group addresses, w= hile some may have ASM group addresses."

This seems to conflict= ....so an Egress-LSR sending this TLV - should it expect to see just SSM gr= oups or both ASM and SSM? =A0Presumably the latter if no group can be speci= fied?

Regards,

Chris
--001a11c3f1548dc36904ef738e2d-- From ice@cisco.com Wed Jan 8 05:44:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBB31AE3A3 for ; Wed, 8 Jan 2014 05:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 j27pQYiHmSCK for ; Wed, 8 Jan 2014 05:44:50 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAD11AE39A for ; Wed, 8 Jan 2014 05:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1130; q=dns/txt; s=iport; t=1389188681; x=1390398281; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7667FFO78LQZtYBfqikpmsKaWVAp4vEDGI9uulfaJnA=; b=eNPZFj3or1k46QGswu0FHZdT8a+DZjvX82z7YSg5tTR4VbCfyIYOhRRn AgLWQLg8WFCLBixRgo0Y2zMJTAtfX0OVPsm7W0ZyxuNg2e8jxZ2I6XBpN Bn0vYqcBv2R+sVpiFDIxvZzeBEv7Sacn4Nk6iBeff8UeqOJDPzxM6028X c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYHACRVzVKQ/khL/2dsb2JhbABZgwumVZQogRMWdIIlAQEBAwF5BQsLRlcGiA8IxH0Xji4kMweDJIETBJgXkhWDLjuBLQ X-IronPort-AV: E=Sophos;i="4.95,624,1384300800"; d="scan'208";a="2668980" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 08 Jan 2014 13:44:40 +0000 Received: from ams-iwijnand-87112.cisco.com (ams-iwijnand-87112.cisco.com [10.55.191.157]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s08DicGx007653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jan 2014 13:44:38 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: IJsbrand Wijnands In-Reply-To: Date: Wed, 8 Jan 2014 14:44:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2F558588-4D8B-4544-BC93-68067FE6B2BF@cisco.com> References: To: Chris Roberts X-Mailer: Apple Mail (2.1510) Cc: mpls@ietf.org Subject: Re: [mpls] draft-wijnands-mpls-mldp-in-band-wildcard-encoding-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 13:44:52 -0000 Hi Chris, > I have a query about this draft relating to the use case of (Source, = Wildcard Group) as the opaque value TLV. >=20 > Section 3.2 Wildcard Semantics states the this should be treated this = as "the TLV identifies the collection of PIM-SSM trees that have the = source address as their root.". >=20 > However, Section 6 Procedures for Wildcard Group Usage states "the = Ingress LSR examines its IP multicast routing table, to find all the IP = multicast streams whose IP source address is the address specified in = the IP Source Address sub-field of the TLV. All these streams SHOULD be = forwarded down the MP-LSP identified by the Opaque Value TLV. Note that = some of these streams may have SSM group addresses, while some may have = ASM group addresses." >=20 > This seems to conflict....so an Egress-LSR sending this TLV - should = it expect to see just SSM groups or both ASM and SSM? Presumably the = latter if no group can be specified? Correct. The statement in section 3.2 should not limit this behaviour to = PIM SSM trees. We'll clarify it in the next revision. Thx, Ice.= From lars@netapp.com Wed Jan 8 02:21:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3441AE1D2; Wed, 8 Jan 2014 02:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 CX4kapA9sL_D; Wed, 8 Jan 2014 02:21:48 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id A21701AE1D9; Wed, 8 Jan 2014 02:21:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,623,1384329600"; d="asc'?scan'208";a="94680269" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 08 Jan 2014 02:21:38 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 02:21:38 -0800 From: "Eggert, Lars" To: IETF Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMA Date: Wed, 8 Jan 2014 10:21:37 +0000 Message-ID: <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> In-Reply-To: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_36C4746D-8644-40AC-AC97-DAF2E1204EE1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 08 Jan 2014 09:15:22 -0800 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 10:21:50 -0000 --Apple-Mail=_36C4746D-8644-40AC-AC97-DAF2E1204EE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-1-2, at 16:14, The IESG wrote: > - 'Encapsulating MPLS in UDP' > as Proposed Standard this document needs to describe how it addresses the issues raised in = BCP145 (RFC5405). It already contains some text about messages sizes and = congestion considerations, which is great. Unfortunately, the text about = congestion considerations is not fully in line with RFC5405. Lars --Apple-Mail=_36C4746D-8644-40AC-AC97-DAF2E1204EE1 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----- iQCVAwUBUs0msNZcnpRveo1xAQJmVgP/Ru+CWqFvoJjk+SPEXBDvVhBIAafFlril t49xr5u64LhTLeFxjtLGX41P1mitCFWV5euqgi2ixkpxIP9OxfCpMKAqLUF/o6/w GL6hw/fa5gB8yCiOBr3/H4h4HyNNJOGm66i7Y30Q5PhGSPhnr/E5essJBwHq9pZb kO+3844idqY= =2mpd -----END PGP SIGNATURE----- --Apple-Mail=_36C4746D-8644-40AC-AC97-DAF2E1204EE1-- From internet-drafts@ietf.org Wed Jan 8 10:34:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AA81AE081; Wed, 8 Jan 2014 10:34:58 -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 DLAOextsWBtT; Wed, 8 Jan 2014 10:34:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7ED41ADBD7; Wed, 8 Jan 2014 10:34:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140108183456.20529.64466.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2014 10:34:56 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-wijnands-mpls-mldp-in-band-wildcard-encoding-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 18:34:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : mLDP In-Band Signaling with Wildcards Authors : IJsbrand Wijnands Eric Rosen Arkadiy Gulko Uwe Joorde Jeff Tantsura Filename : draft-wijnands-mpls-mldp-in-band-wildcard-encoding-03.txt Pages : 16 Date : 2014-01-08 Abstract: There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" to an MPLS multipoint label switched path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either "Source-Specific Multicast" trees or "Bidirectional Multicast" trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP "Any Source Multicast" trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP "Any Source Multicast" trees is subject to certain applicability restrictions that are discussed in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wijnands-mpls-mldp-in-band-wildcard-= encoding/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-wijnands-mpls-mldp-in-band-wildcard-encodi= ng-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-wijnands-mpls-mldp-in-band-wildcar= d-encoding-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 swallow@cisco.com Wed Jan 8 12:04:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DE21AE14F for ; Wed, 8 Jan 2014 12:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 HNGP45hkOUMq for ; Wed, 8 Jan 2014 12:04:11 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 114071AE164 for ; Wed, 8 Jan 2014 12:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1406; q=dns/txt; s=iport; t=1389211442; x=1390421042; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bjrx5Zn0IwurH4Hf/BjVzrZf3fWZEZ4To3s+xd3pbFc=; b=h9ArdIt987NAljvggC60v9eX2DnPSu5B353MwZnz63PXYd2WTOZ2Auzl 5PeS5VkX+HD2gw6Ccro1ToyA9RFfzZkcPuN4pBUnjXMM5qDEozcetRSr0 mRemN4Qnx6GVLDQ3VkiqiA2erGZ7WsmKmMy/djMScnSKA/d3onzlRkRri o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAPWtzVKtJXHB/2dsb2JhbABZgwuBDrk7gRQWdIImAQEEOjEDBgUOAgIBCDYQGxclAgQBDQWIBMROFwSOHxACAU8HhDcBA5gXkhWDLYIq X-IronPort-AV: E=Sophos;i="4.95,626,1384300800"; d="scan'208";a="296112659" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jan 2014 20:04:01 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s08K4109030768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 20:04:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 14:04:00 -0600 From: "George Swallow (swallow)" To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Adrian Farrel Thread-Topic: IPR poll on draft-ietf-mpls-proxy-lsp-ping Thread-Index: AQHPCQpLaGnyyxwRn0yuIBsEeuu0/pp7WDWA Date: Wed, 8 Jan 2014 20:03:59 +0000 Message-ID: References: <52C79610.3080201@pi.nu> In-Reply-To: <52C79610.3080201@pi.nu> 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: [10.98.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] IPR poll on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:04:12 -0000 I know of no other IPR than that which has been disclosed. George On 1/4/14 12:03 AM, "Loa Andersson" wrote: >Working Group, > >We have just started a working group last call on >draft-ietf-mpls-proxy-lsp-ping. we want to do an IPR poll in >parallel. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to draft-ietf-mpls-proxy-lsp-ping? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >Currently there are three IPR disclosures that relates to this document. > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. *The response needs to be sent to the MPLS wg mailing list.* The >document will not advance to the next stage until a response has been >received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > >Thanks, Loa >(as MPLS WG co-chair) > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From swallow@cisco.com Wed Jan 8 12:11:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC571AE169 for ; Wed, 8 Jan 2014 12:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 BCODYhKX4uqk for ; Wed, 8 Jan 2014 12:11:32 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 224EE1AE593 for ; Wed, 8 Jan 2014 12:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1897; q=dns/txt; s=iport; t=1389211883; x=1390421483; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=007mJMuJdYkcx/pwF5MnXpJDfHHUjFi56GC7FO8iDqk=; b=Lq/CSkXaUjDeOgyNVfyUPtq/8oyb/TiQ7vFTYtnp80U5groiG/vUklx+ z6LwmGzGMKH+pU/RLwg/Thun4ftwTHy6+zOjA2m0OVDvcafbAV+nKvlx+ kBIMl42cg8jhnqjeiGVZRxO1Sr6lzmXpuzlKJUQHYPcTBpWe5Gi8phiEF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAPmvzVKtJXHB/2dsb2JhbABZgws4Vrk8gRQWdIIlAQEBAwEBAQE3MQMGBQ4CAgEIDigQGwwLJQIEAQ0Fh3wIDcQ8FwSOHxACAU8CBYQ3BJgXkhWDLYIq X-IronPort-AV: E=Sophos;i="4.95,626,1384300800"; d="scan'208";a="295910442" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jan 2014 20:11:22 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s08KBMmR007554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 20:11:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 14:11:22 -0600 From: "George Swallow (swallow)" To: Thomas Nadeau , Loa Andersson Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-proxy-lsp-ping Thread-Index: AQHPCQpLaGnyyxwRn0yuIBsEeuu0/pp09UOAgAZlAYA= Date: Wed, 8 Jan 2014 20:11:21 +0000 Message-ID: References: <52C79610.3080201@pi.nu> <9535B527-9AD0-487A-B7B7-441B83EFFDA3@lucidvision.com> In-Reply-To: <9535B527-9AD0-487A-B7B7-441B83EFFDA3@lucidvision.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-originating-ip: [10.98.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:11:35 -0000 Tom - The reference you have below is to the patent application. The patent has been issued as=20 7,808,919 and is covered by disclosure 2087. George=20 On 1/4/14 8:32 AM, "Thomas Nadeau" wrote: >=09 > I do not believe that Cisco has disclosed this related one: > > http://www.freepatentsonline.com/y2009/0238084.html > > --Tom > > >> Working Group, >>=20 >> We have just started a working group last call on >> draft-ietf-mpls-proxy-lsp-ping. we want to do an IPR poll in >> parallel. >>=20 >> This mail starts that IPR poll. >>=20 >> Are you aware of any IPR that applies to draft-ietf-mpls-proxy-lsp-ping? >>=20 >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >>=20 >> Currently there are three IPR disclosures that relates to this document. >>=20 >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >>document will not advance to the next stage until a response has been >> received from each author and contributor. >>=20 >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >>=20 >> Thanks, Loa >> (as MPLS WG co-chair) >>=20 >> --=20 >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 > From vlim@cisco.com Wed Jan 8 15:05:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014121A1F78 for ; Wed, 8 Jan 2014 15:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 XQ4SLCiLxRKX for ; Wed, 8 Jan 2014 15:05:23 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E73A61A1F58 for ; Wed, 8 Jan 2014 15:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1217; q=dns/txt; s=iport; t=1389222314; x=1390431914; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=/mQ53FTL9FwckjcZ9HGvFc6sW41TvZtcR8XU2F9i5Jk=; b=TTP9BRrpj+E1H8B1bPI/lqkxje1VMvd3JwWZexQNWcJX+O8LMF69vP+j 68Y/K1LsCNJy+Lx2b2fh8c+XG7BKoovLKFcDtt2qDh37TycxMTHyfW6t7 ZnVe0rlJ0MF3bML0QynRYbreRoIKO0oFDknMNhMw0YIcwM1UEt1Ys+3+E k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAIDYzVKrRDoG/2dsb2JhbABZgwu3RYMIgRIWdIIlAQEBBDg2BhULGAklDwJGBgEMCAEBh38BxEsXjiMQAgFWhDcBA4lDjlSGRYtQg00 X-IronPort-AV: E=Sophos;i="4.95,626,1384300800"; d="scan'208";a="99146111" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 08 Jan 2014 23:05:12 +0000 Received: from [64.101.72.25] ([64.101.72.25]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s08N5Cno003839; Wed, 8 Jan 2014 23:05:12 GMT Message-ID: <52CDD9AD.50308@cisco.com> Date: Wed, 08 Jan 2014 16:05:17 -0700 From: Vanson Lim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Loa Andersson , "mpls@ietf.org" , draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org, "mpls-chairs@tools.ietf.org" , Adrian Farrel References: <52C79610.3080201@pi.nu> In-Reply-To: <52C79610.3080201@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] IPR poll on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 23:05:24 -0000 I am not aware of any other IPR than that which has been disclosed. -Vanson On 1/3/14 10:03 PM, Loa Andersson wrote: > Working Group, > > We have just started a working group last call on > draft-ietf-mpls-proxy-lsp-ping. we want to do an IPR poll in > parallel. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-proxy-lsp-ping? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are three IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) > From jeff.tantsura@ericsson.com Wed Jan 8 15:25:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B23E1ADBCE for ; Wed, 8 Jan 2014 15:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SHzxWRR0kBt for ; Wed, 8 Jan 2014 15:25:28 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC3A1AD93D for ; Wed, 8 Jan 2014 15:25:28 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-39-52cdde5e0005 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 77.FF.04556.E5EDDC25; Thu, 9 Jan 2014 00:25:18 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0347.000; Wed, 8 Jan 2014 18:25:15 -0500 From: Jeff Tantsura To: "" Thread-Topic: LDP Hello - T1,R0 Thread-Index: Ac8MyOI5q8a9jVqKQdOy5alHYdz3yw== Date: Wed, 8 Jan 2014 23:25:14 +0000 Message-ID: <03F9FEC8-7C2B-48BB-9549-AAE4BDE6BE2D@ericsson.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-ID: <5B4E64B9247A1A4F9DDB7778BF1EA711@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyuXRPgm7cvbNBBqf/aFncWrqS1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGfNPdrIU7GeqmPH9IFMD4y/GLkZODgkBE4m1b1YyQ9hiEhfu rWcDsYUEjjBKLF2s0cXIBWQvY5T48u4oWBGbgIHE/2/HWUBsEQFViYbFN1lBbGEBKYl9O5rY IOLyEhtuP2CFsPUkTs85ClbPIqAiceXsd6AaDg5eAXuJr/sUQMKMQHu/n1rDBGIzC4hL3Hoy nwniHgGJJXvOQ90mKvHy8T9WiBodiQW7P7FB2NYSv7ZNYYawtSWWLXwNZvMKCEqcnPmEZQKj 8CwkY2chaZ+FpH0WkvZZSNoXMLKuYuQoLU4ty003MtzECAzvYxJsjjsYF3yyPMQozcGiJM77 5a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGkcnOzkcPdK3JObxppaZuYLif6Koth+7N PKecrbjs4NPkwzsCVcW9OSZ+a/qwrjI3irnrf5biA5tZH2w9co3Wv1r3Ryd3zdz3gQe8wm8f zJpQ27S1fm/6Eq1eTT5b8dDnb9u3rr+rKrW9P4fthtqLtefZVKZe31/FP/f1y5k1pw3DvF5E Cpz3V2Ipzkg01GIuKk4EACa69/w9AgAA Subject: [mpls] LDP Hello - T1,R0 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 23:25:30 -0000 Dear group, Could you please share whether anyone has an implementation where in some c= ases LDP Hello has T bit set and R not set. Could you please elaborate how your implementation would react on receiving= such Hello (ignore, stop sending hello's, drop, etc) =20 Thanks in advance! Regards, Jeff= From tnadeau@lucidvision.com Wed Jan 8 17:22:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D331ADF76 for ; Wed, 8 Jan 2014 17:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 nFVQW8Iv6RoG for ; Wed, 8 Jan 2014 17:22:28 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A9F661ADF62 for ; Wed, 8 Jan 2014 17:22:27 -0800 (PST) Received: from [10.90.119.191] (mobile-166-137-185-108.mycingular.net [166.137.185.108]) by lucidvision.com (Postfix) with ESMTP id 068BA26AC15B; Wed, 8 Jan 2014 20:22:18 -0500 (EST) References: <52C79610.3080201@pi.nu> <9535B527-9AD0-487A-B7B7-441B83EFFDA3@lucidvision.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <09CE801F-C312-44BC-87C9-A4EB46D4D14A@lucidvision.com> X-Mailer: iPhone Mail (11B554a) From: "Thomas D. Nadeau" Date: Wed, 8 Jan 2014 17:22:13 -0800 To: "George Swallow (swallow)" Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:22:30 -0000 cool. thanks for checking into this. > On Jan 8, 2014, at 12:11 PM, "George Swallow (swallow)" wrote: >=20 > Tom - >=20 > The reference you have below is to the patent application. The patent has= > been issued as=20 > 7,808,919 and is covered by disclosure 2087. >=20 > George=20 >=20 >=20 >> On 1/4/14 8:32 AM, "Thomas Nadeau" wrote: >>=20 >> =20 >> I do not believe that Cisco has disclosed this related one: >>=20 >> http://www.freepatentsonline.com/y2009/0238084.html >>=20 >> --Tom >>=20 >>=20 >>> Working Group, >>>=20 >>> We have just started a working group last call on >>> draft-ietf-mpls-proxy-lsp-ping. we want to do an IPR poll in >>> parallel. >>>=20 >>> This mail starts that IPR poll. >>>=20 >>> Are you aware of any IPR that applies to draft-ietf-mpls-proxy-lsp-ping?= >>>=20 >>> If so, has this IPR been disclosed in compliance with IETF IPR rules >>> (see RFCs 3979, 4879, 3669 and 5378 for more details). >>>=20 >>> Currently there are three IPR disclosures that relates to this document.= >>>=20 >>> If you are listed as a document author or contributor please respond to >>> this email regardless of whether or not you are aware of any relevant >>> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >>> document will not advance to the next stage until a response has been >>> received from each author and contributor. >>>=20 >>> If you are on the MPLS WG email list but are not listed as an author or >>> contributor, then please explicitly respond only if you are aware of any= >>> IPR that has not yet been disclosed in conformance with IETF rules. >>>=20 >>> Thanks, Loa >>> (as MPLS WG co-chair) >>>=20 >>> --=20 >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From l.wood@surrey.ac.uk Wed Jan 8 19:00:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860C91AE0A0 for ; Wed, 8 Jan 2014 19:00:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4JPYwjud98j for ; Wed, 8 Jan 2014 19:00:00 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) by ietfa.amsl.com (Postfix) with ESMTP id EAA031AE090 for ; Wed, 8 Jan 2014 18:59:58 -0800 (PST) Received: from [195.245.231.67:5848] by server-6.bemta-5.messagelabs.com id 0C/C9-16310-3A01EC25; Thu, 09 Jan 2014 02:59:47 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-82.messagelabs.com!1389236387!35269059!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27475 invoked from network); 9 Jan 2014 02:59:47 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-12.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jan 2014 02:59:47 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Thu, 9 Jan 2014 02:59:29 +0000 From: To: , Date: Thu, 9 Jan 2014 02:59:28 +0000 Thread-Topic: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Thread-Index: AQHPDObQGmJ4SKwhQk6QfMrFWtjgXA== Message-ID: <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ietf@ietf.org, mpls@ietf.org, jnc@mit.edu, lisp@ietf.org, tsvwg@ietf.org Subject: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 03:00:02 -0000 Thanks, David. Apart from the pollute-other-ports aspect that I've discussed in other mails, MPLS itself is not self-checking (GRE is for header and payload - if its optional checksum is used.) Without checking, corrupt the MPLS label, send it to another tunnel. Without checking, corrupt the UDP port, send the packet elsewhere and pollute another port and stream. I see L. Yong and X. Xu, who are coauthors of=20 draft-yong-tsvwg-gre-in-udp-encap, are also authors of draft-ietf-mpls-in-udp which again plays fast and loose with UDP checksums. This is clearly a widespread problem, and the reliability of the internet i= s being undermined. We can class UDP zero checksum use as an attacks on other streams and services, if that helps. Reliability is an unfashionable topic, but an atta= ck? That must be mitigated immediately. Because they specify zero UDP checksums,=20 I oppose publication of draft-ietf-mpls-in-udp in its current form I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its current= form. I oppose the IETF lisp documents. regards Lloyd Wood http://about.me/lloydwood ________________________________________ From: Black, David [david.black@emc.com] Sent: 08 January 2014 23:20 To: Wood L Dr (Electronic Eng); gorry@erg.abdn.ac.uk Cc: lisp@ietf.org; jnc@mit.edu; tsvwg@ietf.org; ietf@ietf.org Subject: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG= ) Lloyd, This is only at the draft adoption stage - the tsvwg WG gets to take a hard look at the zero checksum conditions in the gre-in-udp-encap draft and make sure that they're right (the WG could even remove the support for zero checksums) - that's among the good reasons for adopting the draft in tsvwg as opposed to elsewhere. Speaking of elsewhere, draft-ietf-mpls-in-udp is in IETF Last Call and has language allowing zero UDP checksums - I might suggest that you (and anyone else who cares about this topic) go read that draft and consider whether making Last Call comments would be appropriate. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of l.wood@surrey.ac= .uk > Sent: Wednesday, January 08, 2014 3:58 PM > To: gorry@erg.abdn.ac.uk > Cc: lisp@ietf.org; jnc@mit.edu; tsvwg@ietf.org; ietf@ietf.org > Subject: Re: [tsvwg] Milestones changed for tsvwg WG > > Zero UDP checksums are being selected for convenience, without an appreci= ation > of the overall effects and costs on other traffic. I see this is occurri= ng in > both tsvwg > and lisp, and it's probably happening elsewhere: > > From the recently adopted by tsvwg draft: > http://tools.ietf.org/html/draft-yong-tsvwg-gre-in-udp-encap-02 > To simplify packet processing at the tunnel egress, packets destined > to this assigned UDP destination port [TBD] SHOULD have their UDP > checksum and Sequence flags set to zero because the egress tunnel > only needs to identify this protocol. Although IPv6 [RFC2460] > restricts the processing a packet with the UDP checksum of zero, > [RFC6935] and [RFC6936] relax this constraint to allow the zero UDP > checksum. > > from http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 > The UDP checksum is zero because the inner packet usually already has > a end-end checksum, and the outer checksum adds no value. [Saltzer] > > (That's a misreading of Saltzer - the UDP checksum is also protecting aga= inst > misdelivery and pseudoheader corruption, and 'usually' is not a good defe= nce. > For shame, Noel.) > > After all, the best examples of end2end systems failure are with zero > checksums > at the endhosts. > > The TCP and UDP checksums catch significant numbers of errors, e.g. Stone= 's > work: > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pd= f > and some of those errors will appear in the headers, where they will send > the data to other ports and destinations. > > The potential for polluting other ports and applications because > there is no pseudoheader demultiplexing sanity check is there. > > IPv6 leaving this check implemented on a per-transport basis has opened = the > door, > and rewriting that section of RFC2460 in RFC6935 has taken the door off i= ts > hinges. > These RFCs break the minimal multiplexing pseudoheader sanity check that > RFC2460 > offered; IPv6 is a mess in so many ways, but making it worse? > > I think publishing RFC6935 and 6936 and letting in zero checksums again t= o > IPv6 > was a mistake, frankly. (alas, I wasn't paying much attention at the time= - > moving countries etc.) > > A strong recommendation that UDP-Lite covering headers offers minimal > computation > overhead on tunnelled packets while protecting against polluting other po= rts > is one > solution, while acknowledging deployment limitations. Section 2.4 of RFC6= 96 is > mostly there. > But zero UDP checksums should always come with copious warnings on the ef= fects > not on the > carried traffic, which can have its own payload checks, but on traffic sh= aring > the network > with traffic delivered with zero UDP checksums. Drafts relying on zero > checksums should be discouraged, not adopted by workgroups. > > It's a tragedy of the commons, but the I'm-alright-Jack engineers who wan= t > zero udp checksums for their traffic, and do protect against the effects = of > zero > checksums on their own payloads, won't care about effects on other traffi= c. > Hey, maybe this should be treated as an attack, which falls under perpass= ? > That > should get it attention... > > tsvwg needs to give (or get) some careful input on the implications here. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk] > Sent: 08 January 2014 12:55 > To: Wood L Dr (Electronic Eng) > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] Milestones changed for tsvwg WG > > Lloyd, > > Here is a little context... which could help. The IETF agreed to update > the UDP checksum behaviour for IPv6 in RFC 6935, but only subject to the > applicability specified in RFC 6936. > > One of the reasons why a simple encapsulation like this needs to be done > in tsvwg is to minimise the end-to-end implications on other traffic. > Sure, using a zero checksum has such implications, and my own first > concern is that the new GRE-in-UDP work follows the applicability > statement in RFC 6936. To me, it seems the authors are heading this way - > but maybe more help is needed. It would be no bad thing to highlight the > implications of using zero checksums on other traffic. > > Gorry > > > Am I the only one who finds putting zero checksums in proposed standard= s > > to be a worrying > > trend? > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: tsvwg [tsvwg-bounces@ietf.org] On Behalf Of IETF Secretariat > > [ietf-secretariat-reply@ietf.org] > > Sent: 07 January 2014 20:20 > > To: tsvwg@ietf.org > > Subject: [tsvwg] Milestones changed for tsvwg WG > > > > Added milestone "Submit 'Specification of GRE in UDP encapsulation' to > > IESG as a PS RFC", due December 2014. > > > > URL: http://datatracker.ietf.org/wg/tsvwg/charter/ > > > > From randy@psg.com Wed Jan 8 23:51:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB51AE11A; Wed, 8 Jan 2014 23:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 oANByb7vVI-F; Wed, 8 Jan 2014 23:51:54 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 154B21AE08E; Wed, 8 Jan 2014 23:51:54 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W1AOt-0007Zj-Ra; Thu, 09 Jan 2014 07:51:36 +0000 Date: Thu, 09 Jan 2014 16:51:33 +0900 Message-ID: From: Randy Bush To: In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Thu_Jan__9_16:51:26_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 07:51:55 -0000 --pgp-sign-Multipart_Thu_Jan__9_16:51:26_2014-1 Content-Type: text/plain; charset=US-ASCII > Because they specify zero UDP checksums, > I oppose publication of draft-ietf-mpls-in-udp in its current form > I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its current form. > I oppose the IETF lisp documents. lloyd, i think i understand your position. but i disagree with preventing wg adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly see wg adoption as how we get to discuss and work on a document, not as approval of the document. as david said, i think we need to discuss it so we can decide if it should be fixed. to do so, we have to adopt it. randy --pgp-sign-Multipart_Thu_Jan__9_16:51:26_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJSzlUEAAoJEMzMBey4OgLtpjYH/iM5qSYEPIFoK6ay0D9mYB/t gqH8nCOV6Kw+E9VWgwfPs2fwtuLboUrxn4aJF3M84FCDcg1pFks7d6g2d3EDx5wJ KLcpcq9Kg+hAdU+oWYAkmT+aA3HtEdCysVqMlo15G4Cm46TI2VycKEBAzhCGe1ue C8j66MfVUCIrIqLeZEAb6mzXUsqpzZnNKaGBtatHp/4TGMWGllwCVC/va46IvKWE 6aYtgxWUDO4g07Iu/c7SdJQcQHUh58o785Nyc7jhuEXTV6DTJe6Rtte+aXOr0hmU blDwmEf5ixrkuT4YO+mPoKpgmwMk4VLxcpt22pe29VRmS9DDiVtckX3KXgoPJsc= =IiRO -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Jan__9_16:51:26_2014-1-- From l.wood@surrey.ac.uk Thu Jan 9 00:09:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52A71AE06F; Thu, 9 Jan 2014 00:09:15 -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, 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 gG1Cmobgtscu; Thu, 9 Jan 2014 00:09:13 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) by ietfa.amsl.com (Postfix) with ESMTP id CCA661AE06D; Thu, 9 Jan 2014 00:09:12 -0800 (PST) Received: from [195.245.230.131:54618] by server-16.bemta-3.messagelabs.com id 39/23-26128-E195EC25; Thu, 09 Jan 2014 08:09:02 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-78.messagelabs.com!1389254942!29878430!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31345 invoked from network); 9 Jan 2014 08:09:02 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-15.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jan 2014 08:09:02 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Thu, 9 Jan 2014 08:09:01 +0000 From: To: Date: Thu, 9 Jan 2014 08:06:57 +0000 Thread-Topic: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Thread-Index: Ac8ND6LbmabIHemQQc6QHOWUwU/54gAAiHqr Message-ID: <290E20B455C66743BE178C5C84F1240847E63346B5@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 08:09:16 -0000 Randy, okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get con= sensus on it. And then the authors can adopt that consensus for mpls-in-ud= p, which overlaps in authorship... thanks, Lloyd Wood http://about.me/lloydwood ________________________________________ From: Randy Bush [randy@psg.com] Sent: 09 January 2014 07:51 To: Wood L Dr (Electronic Eng) Cc: david.black@emc.com; gorry@erg.abdn.ac.uk; ietf@ietf.org; mpls@ietf.org= ; jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsv= wg] Milestones changed for tsvwg WG) > Because they specify zero UDP checksums, > I oppose publication of draft-ietf-mpls-in-udp in its current form > I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its curre= nt form. > I oppose the IETF lisp documents. lloyd, i think i understand your position. but i disagree with preventing wg adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly see wg adoption as how we get to discuss and work on a document, not as approval of the document. as david said, i think we need to discuss it so we can decide if it should be fixed. to do so, we have to adopt it. randy From adrian@olddog.co.uk Thu Jan 9 02:22:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C701AE1AE; Thu, 9 Jan 2014 02:22:07 -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, 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 PVl5ZX95-Aw7; Thu, 9 Jan 2014 02:22:04 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3AF1AE23A; Thu, 9 Jan 2014 02:22:04 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09ALoZl029262; Thu, 9 Jan 2014 10:21:50 GMT Received: from 950129200 (15.21.90.92.rev.sfr.net [92.90.21.15]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09ALjKd029119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 10:21:48 GMT From: "Adrian Farrel" To: , References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F1240847E63346B5@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346B5@EXMB01CMS.surrey.ac.uk> Date: Thu, 9 Jan 2014 10:21:44 -0000 Message-ID: <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLp3cWoqiSzZKGjmFXJEPC82F9z6gH14gYaAYJCBgICOkjTg5gY93Xw Content-Language: en-gb Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, david.black@emc.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:22:07 -0000 Lloyd and Randy, With respect to draft-ietf-mpls-in-udp, this is why we have IETF last calls, so thanks for the comments. We did take the precaution of sending this I-D for an early TSV Directorate review because of the concern about a number of factors and the overlap with tsvwg work, but the review came back "clean". Of course, such a review is just one person, so this conversation is good. Wrt zero checksum, where do you stand on nested checksums? There is some claim that they represent a waste of processing. I am not convinced by that when each layer is using dedicated hardware (that can presumably process checksums at line speed), but I am interested in the consequences for cheap hardware and for software implementations (as have been claimed to be some of the motivations for this work). Other TSV-related issues that surely pop up are: - allocation of ports for foo-in-UDP - congestion control Please note that there are a number of I-Ds that you missed in your broad sweep of "I am opposed". You should probably look at the NVGRE and VXLAN work (which I think is lurking around the NVO3 working group) because that is also looking at UDP encaps of a tunnelling protocol. Thanks, Adrian Health warnings: I am responsible AD for draft-ietf-mpls-in-udp I am a co-author of the gre-in-udp draft. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk > Sent: 09 January 2014 08:07 > To: randy@psg.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; > tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: > [tsvwg] Milestones changed for tsvwg WG) > > Randy, > > okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get > consensus on it. And then the authors can adopt that consensus for mpls-in-udp, > which overlaps in authorship... > > thanks, > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Randy Bush [randy@psg.com] > Sent: 09 January 2014 07:51 > To: Wood L Dr (Electronic Eng) > Cc: david.black@emc.com; gorry@erg.abdn.ac.uk; ietf@ietf.org; mpls@ietf.org; > jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org > Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] > Milestones changed for tsvwg WG) > > > Because they specify zero UDP checksums, > > I oppose publication of draft-ietf-mpls-in-udp in its current form > > I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its current > form. > > I oppose the IETF lisp documents. > > lloyd, > > i think i understand your position. but i disagree with preventing wg > adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly > see wg adoption as how we get to discuss and work on a document, not as > approval of the document. as david said, i think we need to discuss it > so we can decide if it should be fixed. to do so, we have to adopt it. > > randy > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Thu Jan 9 02:59:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598A31AE135; Thu, 9 Jan 2014 02:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 ZAx0xcNlXw_k; Thu, 9 Jan 2014 02:59:21 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 81E0A1AE215; Thu, 9 Jan 2014 02:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=399; q=dns/txt; s=iport; t=1389265152; x=1390474752; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Qbe2VRt6TGgmdKkwK0vrwchK/iSeGfGGNd3cr1ckZPM=; b=EO/vraLAtH2nDac172HbQ2TDFlN02f4DmnCrHJqkVioUI1jQsn84Vnk1 fK/OaPU/lMpgniKE//8hSFdp+pOXCUXQlWRxN6lBmilOL50soeCMsXGVo fYQJuSyS65zUyPh569yL7IjwaRZYktZDplPX7s6H7jmeUFcuwWe9aMH2Q w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHWAzlKQ/khL/2dsb2JhbABZDoJ9ulOBEBZ0giUBAQEEOEABEAsYCRYECwkDAgECAUUHDAEFAgEBiADFEBePBQeENwEDmBeSFYFvfz8 X-IronPort-AV: E=Sophos;i="4.95,630,1384300800"; d="scan'208";a="3380445" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 09 Jan 2014 10:59:10 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s09Ax9RB017045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 10:59:10 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s09Ax8Lc029902; Thu, 9 Jan 2014 10:59:08 GMT Message-ID: <52CE80FC.9060306@cisco.com> Date: Thu, 09 Jan 2014 10:59:08 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, david.black@emc.com, gorry@erg.abdn.ac.uk References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, tsvwg@ietf.org, jnc@mit.edu, ietf@ietf.org, lisp@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:59:23 -0000 On 09/01/2014 02:59, l.wood@surrey.ac.uk wrote: > MPLS itself is not self-checking (GRE is for header and > payload - if its optional checksum is used.) Without checking, corrupt > the MPLS label, send it to another tunnel. Lloyd I would be interested in what operators are observing in their network, because I have never heard a concern expressed that this was happening. - Stewart From mark.tinka@seacom.mu Thu Jan 9 03:04:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AED91AE26D; Thu, 9 Jan 2014 03:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 0OVBMb7fXizw; Thu, 9 Jan 2014 03:04:30 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id DD01E1AE262; Thu, 9 Jan 2014 03:04:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W1DOz-0002Gm-N2; Thu, 09 Jan 2014 13:03:53 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org, stbryant@cisco.com Date: Thu, 9 Jan 2014 13:03:52 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> <52CE80FC.9060306@cisco.com> In-Reply-To: <52CE80FC.9060306@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6950898.q6vmhhEH7r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401091303.53239.mark.tinka@seacom.mu> Cc: gorry@erg.abdn.ac.uk, lisp@ietf.org, tsvwg@ietf.org, david.black@emc.com, jnc@mit.edu, ietf@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 11:04:34 -0000 --nextPart6950898.q6vmhhEH7r Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, January 09, 2014 12:59:08 PM Stewart Bryant=20 wrote: > I would be interested in what operators are observing in > their network, because I have never heard a concern > expressed that this was happening. You mean for native MPLS, or for encapsulated MPLS? Mark. --nextPart6950898.q6vmhhEH7r Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJSzoIZAAoJEGcZuYTeKm+Gxx8QAImaR5aEcX9avA5B3dKrYbe4 AeGqeUKtVCjkZt9/p91LkMPXcRd9QcQzjfprDRwW0LT6PT9tkFWS/N6dep6ZZQ8x UytAYCUVqEngI3El7p+LvSt97JW+n97/9aFRA6hD65av/PwOG4Y1M97rEP2qsnGu pXG4TrZ+uJ28bjtXwahgHnhjKgF2Wu5rTSrdWpfShRRlYPsrMjFAw2gkOqGqwQGH D1CUFnv8e3V2hj+rS9sWRf+qjGsqm5I273kLn6ryX6XBdjE+qZTDptdIXo43+/2I qJsemitPOydyM4y8qCYL33dyLYUlFTMhW6IOakX4lzNPCPgcoTIqeJvjZHECT1hn IcHZGgMDxVlbQgLIoGqmdHGLN5BQsHUfIWIkZLbn4ftaJ8oqFm8ZhWvGgLgxiZ2I 1p/87+rm9/6hnYPWdZOY2XlZ8yKEQbEQs6zalpvselUq7Ydk20JxtF74v5nuUIfx N+WtjEYqGIhNCbiN68MRxyHWj1Ojlojo0W45raE+Cz5vmkQM6O4vpKUXue0BbLkR 2l3EjbusFbnJMzTR5B2qHFALS+EADIuoSxfdqSfUNQTYR1/K/z/te8g5fQbci6VW WcP28pMwG48YGE8N2pyk/Rsk0wISDgtJ9Vu+mOzsDllAkQmMKRyDUpJKc2VepmhF zgaLCG2+5qg/tLsKEs9G =nW7X -----END PGP SIGNATURE----- --nextPart6950898.q6vmhhEH7r-- From adrian@olddog.co.uk Thu Jan 9 03:51:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDED51AE29B for ; Thu, 9 Jan 2014 03:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 yuN8muUI3Vo4 for ; Thu, 9 Jan 2014 03:51:20 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id A8AE91AE20E for ; Thu, 9 Jan 2014 03:51:19 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09Bp6rA026716; Thu, 9 Jan 2014 11:51:08 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09Bp4wT026686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 11:51:05 GMT From: "Adrian Farrel" To: References: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> In-Reply-To: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> Date: Thu, 9 Jan 2014 11:51:03 -0000 Message-ID: <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMUV0gQu98E8zPvuS9WnPXs2HJTspfxslEg Content-Language: en-gb Cc: stephen.farrell@cs.tcd.ie Subject: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 11:51:22 -0000 Hi MPLS working group, Stephen and I have been looking at MPLS data plane security and wondering whether anything could be done to help protect against various types of bulk surveillance achieved by tapping entire links without requiring full and management-heavy establishment of security associations. This I-D is very rough! it is a first attempt to show what might be achieved. We are confident that there are problems with what we have suggested both from a security and an MPLS perspective. Your thoughts and comments are encouraged. Thanks, The Farrel twins. > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 09 January 2014 11:44 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Opportunistic Encryption in MPLS Networks > Authors : Adrian Farrel > Stephen Farrell > Filename : draft-farrelll-mpls-opportunistic-encrypt-00.txt > Pages : 22 > Date : 2014-01-09 > > Abstract: > This document describes a way to apply opportunistic encryption > between adjacent nodes on an MPLS Label Switched Path (LSP) or > between end points of an LSP. It explains how keys may be exchanged > to enable the encryption, and indicates how key identifiers are > exchanged in encrypted MPLS packets. Finally, this document > describes the applicability of opportunistic encryption in MPLS > networks with an indication of the level of improved security as well > as the continued vulnerabilities. > > This document does not describe security for MPLS control plane > protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic-encrypt/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stbryant@cisco.com Thu Jan 9 04:08:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7861AE092; Thu, 9 Jan 2014 04:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 1MiTxQP-0ggZ; Thu, 9 Jan 2014 04:08:56 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 855E01ADF52; Thu, 9 Jan 2014 04:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=478; q=dns/txt; s=iport; t=1389269326; x=1390478926; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6TFNL/i3NO0Be9C+OxWBBxbGoqGq75F7IjQQAg9OjH4=; b=Mp8Vka/qzKqcutS+2Pd23V2bUukZ6qLqQR7wJ4qn8m3NglHWIXTtf2va sGOZLT2MpmzfOEG4AwKtdQsiAakKlXRBFSY2z9Ka5+BnQvXAxV2kERbdr UKnHxD2dbmJ6J2LGaMW9NwSrQLWm4qBqK3KPS/STuJflI8UOZNpff82/5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPCQzlKQ/khM/2dsb2JhbABZgwu3S4MIgREWdIIlAQEBBDhAARALGAkWDwkDAgECAUUHDAEHAQGIAMR4F48FB4Q3AQOYF5IVgy0 X-IronPort-AV: E=Sophos;i="4.95,630,1384300800"; d="scan'208";a="3383896" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 09 Jan 2014 12:08:45 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s09C8iYO006013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 12:08:45 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s09C8h6p005115; Thu, 9 Jan 2014 12:08:43 GMT Message-ID: <52CE914B.7070506@cisco.com> Date: Thu, 09 Jan 2014 12:08:43 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mark.tinka@seacom.mu, mpls@ietf.org References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk> <52CE80FC.9060306@cisco.com> <201401091303.53239.mark.tinka@seacom.mu> In-Reply-To: <201401091303.53239.mark.tinka@seacom.mu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, ietf@ietf.org, david.black@emc.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 12:08:58 -0000 On 09/01/2014 11:03, Mark Tinka wrote: > On Thursday, January 09, 2014 12:59:08 PM Stewart Bryant > wrote: > >> I would be interested in what operators are observing in >> their network, because I have never heard a concern >> expressed that this was happening. > You mean for native MPLS, or for encapsulated MPLS? > > Mark. Hi Mark, Either or both. I am interested in how often in practice MPLS packets get misdelivered due to label corruption. - Stewart From mark.tinka@seacom.mu Thu Jan 9 04:37:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C601AE215; Thu, 9 Jan 2014 04:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 udwRene6NZUG; Thu, 9 Jan 2014 04:37:34 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id BD7E31AD8CD; Thu, 9 Jan 2014 04:37:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W1ErA-00037O-Os; Thu, 09 Jan 2014 14:37:04 +0200 From: Mark Tinka Organization: SEACOM To: stbryant@cisco.com Date: Thu, 9 Jan 2014 14:36:56 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> In-Reply-To: <52CE914B.7070506@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2216786.Gj6lG7fHB8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401091437.04245.mark.tinka@seacom.mu> Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 12:37:35 -0000 --nextPart2216786.Gj6lG7fHB8 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant=20 wrote: > Either or both. I can only speak to native MPLS, as I've never run tunneled=20 MPLS. > I am interested in how often in practice MPLS packets get > misdelivered due to label corruption. Well, first of all, routers would need to report corrupted=20 MPLS frames so operators can glean this data. This isn't=20 something I've come across, but it would be good to find=20 some kind of way to count this across interfaces, if the=20 routers can detect and report them. The known issue about mis-delivery of MPLS frames is poorly- sized MTU interfaces. I have no empirical data as to how=20 this can corrupt successive MPLS frames that may fit into=20 the transit MTU. But in this case, as with any Layer 2=20 traffic, not enough MTU =3D dropped frame. Mark. --nextPart2216786.Gj6lG7fHB8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJSzpfwAAoJEGcZuYTeKm+G5SAQALfNbYG3PYHbT7QCKV8dprMp ryTPEndCuPuAlpjpfqZDscQSjn0K4F2wIofJN48CBDHC7ivhfBCuQUpNFbP+jYln 04mV9pEhM6urzKZQUgpq/GdMmUVG03loq8TPhZV6gT+3+hO26SnDwl8VzqdafaGi K/e0qSuuwmlVKnN+ywhHTOwd+5r3mJPE6fZpSHByjjRz1EDPIgUptg8Cf5Wcz3uP QlC0DM0drEYwZn+jzOOScv6Zvb+8/Z7e3zdFmLHIWYAi4xM89lWCNShU7bQNDwvp Wc6gIFMaPY0A8Vj2gy1x61jf/PCXk69xSXt7n4tPTn4oRSMSfKFShInklxWmVtsq wmM6D2QieXMB0lRrXzXSSnjJMvsNuhICqNy7FwI9MFfJEXFo/nsc13xZHnHf0VKV tdCnlQheOehwK3qmZyg4OQiBIoQ10MRK4e/qgU9hyXJQrzResVAmf5HpiE1ZFIQH AtQdcfd3PBvxrTO6p8NLRja7hPZ9CLu554Sz6Z2DA12mD/KZAkTbpz5bef4/fTSH IPRz9VBwLeJEJQr1yg4aIK8p46TPNwMKvJjLsowydmb6PUo70JVmYKUPolbCYs8A 9KpuLtPk4miCEbIpRNLYOVFnJGCqnOsH0WmkDJFqCV0G+jESv7hZWnbU4nCnmtnO lwX81Wa/2rU7Z/g6WUnW =MplW -----END PGP SIGNATURE----- --nextPart2216786.Gj6lG7fHB8-- From mark.tinka@seacom.mu Thu Jan 9 05:15:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B2A1AE1D9 for ; Thu, 9 Jan 2014 05:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 MHefDBu_DPO1 for ; Thu, 9 Jan 2014 05:15:03 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id E7AF71AE2BB for ; Thu, 9 Jan 2014 05:15:01 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W1FRR-0003Vr-Iz; Thu, 09 Jan 2014 15:14:33 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org, adrian@olddog.co.uk Date: Thu, 9 Jan 2014 15:14:29 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> In-Reply-To: <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1808822.iEuItDjuWL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401091514.32953.mark.tinka@seacom.mu> Cc: stephen.farrell@cs.tcd.ie Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:15:04 -0000 --nextPart1808822.iEuItDjuWL Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, January 09, 2014 01:51:03 PM Adrian Farrel=20 wrote: > Hi MPLS working group, >=20 > Stephen and I have been looking at MPLS data plane > security and wondering whether anything could be done to > help protect against various types of bulk surveillance > achieved by tapping entire links without requiring full > and management-heavy establishment of security > associations. >=20 > This I-D is very rough! it is a first attempt to show > what might be achieved. We are confident that there are > problems with what we have suggested both from a > security and an MPLS perspective. Your thoughts and > comments are encouraged. Thanks for this draft, Farrel twins. As an operator, my rather high level concerns are: - What impact does this have on linear data plane throughput? - What impact does this have on data plane operational complexity? - What impact does this have on the control plane. - How efficient is key management on a global level, and what is the practical impact to day-to-day operations, for situations where MPLS paths cross distinct routing domains? - What kind of backward compatibility is there for domains that do not participate, or for nodes within the same domain that do not participate, as this has an impact on overall domain capability (i.e., cost). Cheers, Mark. --nextPart1808822.iEuItDjuWL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJSzqC4AAoJEGcZuYTeKm+GEMIP/j59cUOas8RPnc9zEUHSwZ2c 5NCs2Q4okbwUdUnkdSxjCA2PVshqCkSAZFga1FoQvgR6jBGGJImoKBWVYjsGB0Ff IpKqgNa8/dhzJlJcM3Lmve+9OyXz4gPfLh5e5kZIzOT6jGo8D7gjzmi0yhzaz5N5 wI8hRjEeGlXMQdXJYVq9OXpw+slhcHiXI11THbXjJpBQKgcwTjnel8sItkqbxFOR VrOr744d/LYeJcQA+g4GdPegC0n8KWNV1IuC4T8jj9u/Hv2rd4QX+DmUFUeia+RT DCt1T19s8bOG0H69KDasP5bzG6B22Y2i+H0Ij3kLYg36ilUwdPB67gQHaGVu7PO1 tkfV5qhGamQBOee53vO3UKCPhBO/0u/cJB6CjIVjViTN/rso+0xpg/Wta3YghJvl u3FhTg82veXtjc5dJ9HkVW8RCp9LAIyKVQ3qame346ILr+wc4p3L4m0FzIdzQPHC rRUyEdi/HDrP4/gv6tdHgZO+2UA2xl7Ol/yb4w4cf/jThTGfo/356qAc3x12jMh9 dQfBux+ogCumZbJonssZbfAeFWKc57f5qExbjAiir9MO2/MQC9TPEEO5MfYi/Xwj NYmJ1hVI2lbZ+BOT79ZEPfil3gXSVMun9jWZOZ3L71DWudorC6AVdbgTh2D8RTCY pTp6sQ/A59oIgq62mVrw =WjIE -----END PGP SIGNATURE----- --nextPart1808822.iEuItDjuWL-- From adrian@olddog.co.uk Thu Jan 9 06:16:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6382E1AE309 for ; Thu, 9 Jan 2014 06:16:22 -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, 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 hyOQo7I0yR8V for ; Thu, 9 Jan 2014 06:16:18 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 40E951AE31D for ; Thu, 9 Jan 2014 06:16:18 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09EG6Ex007091; Thu, 9 Jan 2014 14:16:06 GMT Received: from 950129200 (16.17.90.92.rev.sfr.net [92.90.17.16]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09EG4Du007018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 14:16:05 GMT From: "Adrian Farrel" To: , References: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> <201401091514.32953.mark.tinka@seacom.mu> In-Reply-To: <201401091514.32953.mark.tinka@seacom.mu> Date: Thu, 9 Jan 2014 14:16:03 -0000 Message-ID: <022b01cf0d45$5566f8f0$0034ead0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMUV0gQu98E8zPvuS9WnPXs2HJTsgGNbmkbAhKyunaX1NkZYA== Content-Language: en-gb X-TM-AS-MML: No Cc: stephen.farrell@cs.tcd.ie Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:16:22 -0000 Hi Mark, Thanks for the rapid response. I leave some of your questions for wider discussion and just respond to a few of them... > As an operator, my rather high level concerns are: > > - What impact does this have on linear data plane > throughput? TBD Some people have noted that per hop encryption/decryption might be an issue. Others have countered that ETH h/w can already handle MACsec at line rate. e2e encryption seems (to me) to be less likely to be an issue. > - What impact does this have on data plane > operational complexity? > > - What impact does this have on the control plane. AFAIK, none. The I-D doesn't touch the control plane. > - How efficient is key management on a global level, > and what is the practical impact to day-to-day > operations, for situations where MPLS paths cross > distinct routing domains? The point of OE is that there is no key management on a global level. It is, of course, still relatively rare that LSPs cross distinct routing domains, but when they do, this need not have any impact on OE. > - What kind of backward compatibility is there for > domains that do not participate, or for nodes > within the same domain that do not participate, as > this has an impact on overall domain capability > (i.e., cost). This is covered in the document (although maybe not in enough detail?). Transit nodes (and so domains) do not need to be aware of the encryption which is below the top labels and potentially below the entropy label. End nodes that do not support will, erm, not support :-) Thanks for the early thoughts and I encourage an in-depth read and some more pontifications. Adrian From stephen.farrell@cs.tcd.ie Thu Jan 9 06:18:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2F91AE325 for ; Thu, 9 Jan 2014 06:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 I3dj7F9ag_v8 for ; Thu, 9 Jan 2014 06:18:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 031B31AE306 for ; Thu, 9 Jan 2014 06:18:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 35AE6BE54; Thu, 9 Jan 2014 14:18:21 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPiHt82i9h+o; Thu, 9 Jan 2014 14:18:21 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 10CBEBE53; Thu, 9 Jan 2014 14:18:21 +0000 (GMT) Message-ID: <52CEAFAC.8010901@cs.tcd.ie> Date: Thu, 09 Jan 2014 14:18:20 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, mark.tinka@seacom.mu, mpls@ietf.org References: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> <201401091514.32953.mark.tinka@seacom.mu> <022b01cf0d45$5566f8f0$0034ead0$@olddog.co.uk> In-Reply-To: <022b01cf0d45$5566f8f0$0034ead0$@olddog.co.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:18:33 -0000 On 01/09/2014 02:16 PM, Adrian Farrel wrote: > Hi Mark, > > Thanks for the rapid response. > > I leave some of your questions for wider discussion and just respond to a few of > them... > >> As an operator, my rather high level concerns are: >> >> - What impact does this have on linear data plane >> throughput? > > TBD > Some people have noted that per hop encryption/decryption might be an issue. > Others have countered that ETH h/w can already handle MACsec at line rate. > e2e encryption seems (to me) to be less likely to be an issue. I'm not a h/w person myself, so take this with salt, but [1] indicates they got 30Gbps with one Xilinx Virtex5 FPGA and AES-GCM is designed to be parallelised. S. [1] http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6674921 > >> - What impact does this have on data plane >> operational complexity? >> >> - What impact does this have on the control plane. > > AFAIK, none. The I-D doesn't touch the control plane. > >> - How efficient is key management on a global level, >> and what is the practical impact to day-to-day >> operations, for situations where MPLS paths cross >> distinct routing domains? > > The point of OE is that there is no key management on a global level. > It is, of course, still relatively rare that LSPs cross distinct routing > domains, but when they do, this need not have any impact on OE. > >> - What kind of backward compatibility is there for >> domains that do not participate, or for nodes >> within the same domain that do not participate, as >> this has an impact on overall domain capability >> (i.e., cost). > > This is covered in the document (although maybe not in enough detail?). > Transit nodes (and so domains) do not need to be aware of the encryption which > is below the top labels and potentially below the entropy label. > End nodes that do not support will, erm, not support :-) > > Thanks for the early thoughts and I encourage an in-depth read and some more > pontifications. > > Adrian > From mark.tinka@seacom.mu Thu Jan 9 06:47:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C171AE378 for ; Thu, 9 Jan 2014 06:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 z6hAbiWgx6rm for ; Thu, 9 Jan 2014 06:47:16 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 983CB1AE37B for ; Thu, 9 Jan 2014 06:47:15 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W1Gsi-0004Tq-KC; Thu, 09 Jan 2014 16:46:48 +0200 From: Mark Tinka Organization: SEACOM To: adrian@olddog.co.uk Date: Thu, 9 Jan 2014 16:46:44 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> <201401091514.32953.mark.tinka@seacom.mu> <022b01cf0d45$5566f8f0$0034ead0$@olddog.co.uk> In-Reply-To: <022b01cf0d45$5566f8f0$0034ead0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2929368.IMDybXLlaT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401091646.48102.mark.tinka@seacom.mu> Cc: mpls@ietf.org, stephen.farrell@cs.tcd.ie Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:47:18 -0000 --nextPart2929368.IMDybXLlaT Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, January 09, 2014 04:16:03 PM Adrian Farrel=20 wrote: > TBD > Some people have noted that per hop encryption/decryption > might be an issue. Others have countered that ETH h/w > can already handle MACsec at line rate. e2e encryption > seems (to me) to be less likely to be an issue. Optical vendors have started supporting encryption at the=20 DWDM level. I haven't implemented such myself, so can't=20 really qualify its stability in the field, but those=20 chipsets are limited in their service flexibility. Vendors generally bias ASIC development toward supporting=20 line rate for Ethernet and upper Layer 3 protocols at line=20 rate, with a reasonable amount of trade-off. I'm not sure whether this could signal for them to develop=20 even more expensive ASIC's, or have a separate ASIC handling=20 the encryption, either along with the MPLS forwarding or in=20 parallel. My concern is data plane complexity and line card cost. But,=20 obviously, this could be out of scope of this I-D, to a=20 great extent. My concerns are just operational. > AFAIK, none. The I-D doesn't touch the control plane. Key exchange is inband, yes? > The point of OE is that there is no key management on a > global level. It is, of course, still relatively rare > that LSPs cross distinct routing domains, but when they > do, this need not have any impact on OE. Again, because key exchange is inband? > This is covered in the document (although maybe not in > enough detail?). Transit nodes (and so domains) do not > need to be aware of the encryption which is below the > top labels and potentially below the entropy label. End > nodes that do not support will, erm, not support :-) Given LSP's can interconnect various nodes in the same=20 domain in any number of ways, OE would require all MPLS=20 nodes support it in unison, to avoid global domain traffic=20 drops, yes? Mark. --nextPart2929368.IMDybXLlaT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJSzrZXAAoJEGcZuYTeKm+GsmUP/i3JZVO9dda1ogz66y21iusE d780wD7a9zgQH/toQJGYGdMZbG5VSDyVNyr8JCWDhPdGHIIB/BLZP1dN9tXQKR/O OeYq8KV1hZFYxVAYG9ESPNHsqLkjdlcs0/S7fCo8DghWNa1ntCNC7fcTpy8LyNVS g/beOs3h1d7lQcHqn9JsFh6sh6T17zWVAXXPOfxC1S18uiWLQsr25WJk6WJff9Zr oArF2/Bb4I7xKo+el9M50Lz6pfpJ22dsa4/7txU2mENw91JXFKumAytHPtvE4KwY w4x+7GIUtZ6uzaMsMeNhQm3bdA84fOnmyxvp948NRyt0PzNUYgfN9R7iHpaZJRvs +Hu8qqDeRL1MEffUPR/ul8IF2uR08rTrekNdiNyP/REIWHaJ6XWH3UYOYR4F3n+d n6vHlzXFSNQ5vpRZeLwcjVRMfWuxMnKM/pXY8zYyVhkllPsGmSMLIP3BRMQU8rjW yXMBWcBJBodvH3zu+66ovpBnwy7Mcd2auKDB1JV17LYNdAhPzWbmYGVb6XZyqmQK c3NPuYRDpzEtPam8h1J+zL0Kx2Sqt0K/JNyFbXdta8CgaP8icuNzfxbqde6Nj+k+ qfB/PPzTwYoAqjkrPoVdoWYq8xoqI9EkUKaMU67TR0+ilNu+CFDFY9PicE2LUKue pWehN/TtmTwrjYAaV4Ue =vdgF -----END PGP SIGNATURE----- --nextPart2929368.IMDybXLlaT-- From adrian@olddog.co.uk Thu Jan 9 07:56:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E421AE435 for ; Thu, 9 Jan 2014 07:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 PZhJKe90qJ1C for ; Thu, 9 Jan 2014 07:56:49 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 463C31AE43B for ; Thu, 9 Jan 2014 07:56:42 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09FuUCm017898; Thu, 9 Jan 2014 15:56:30 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s09FuPlm017833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 15:56:27 GMT From: "Adrian Farrel" To: References: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> <201401091514.32953.mark.tinka@seacom.mu> <022b01cf0d45$5566f8f0$0034ead0$@olddog.co.uk> <201401091646.48102.mark.tinka@seacom.mu> In-Reply-To: <201401091646.48102.mark.tinka@seacom.mu> Date: Thu, 9 Jan 2014 15:56:24 -0000 Message-ID: <029901cf0d53$5beb7d00$13c27700$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMUV0gQu98E8zPvuS9WnPXs2HJTsgISsrp2ATum82gCb2dYC5fECXPw Content-Language: en-gb X-TM-AS-MML: No Cc: mpls@ietf.org, stephen.farrell@cs.tcd.ie Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:56:51 -0000 Hi again Mark, Just pursuing one point... > > Transit nodes (and so domains) do not > > need to be aware of the encryption which is below the > > top labels and potentially below the entropy label. End > > nodes that do not support will, erm, not support :-) > > Given LSP's can interconnect various nodes in the same > domain in any number of ways, OE would require all MPLS > nodes support it in unison, to avoid global domain traffic > drops, yes? I don't get this. Only the end points of the encryption need to be aware of it. It is only used when the end points agree to do it. If one end point does not agree we have status quo. If both end points agree then the transit points (if they exist) don't participate. So I can't fathom your statement. Can you give me an example? Thanks, Adrian From loa@pi.nu Thu Jan 9 08:17:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A941AD68A; Thu, 9 Jan 2014 08:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 mjlRICDVIyjD; Thu, 9 Jan 2014 08:17:19 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 104661AE373; Thu, 9 Jan 2014 08:17:19 -0800 (PST) Received: from [192.168.1.5] (unknown [119.95.157.254]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CD075180145E; Thu, 9 Jan 2014 17:17:04 +0100 (CET) Message-ID: <52CECB7B.3090200@pi.nu> Date: Fri, 10 Jan 2014 00:16:59 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mark.tinka@seacom.mu, stbryant@cisco.com References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> <201401091437.04245.mark.tinka@seacom.mu> In-Reply-To: <201401091437.04245.mark.tinka@seacom.mu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 16:17:21 -0000 Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled > MPLS. > >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted > MPLS frames so operators can glean this data. This isn't > something I've come across, but it would be good to find > some kind of way to count this across interfaces, if the > routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- > sized MTU interfaces. I have no empirical data as to how > this can corrupt successive MPLS frames that may fit into > the transit MTU. But in this case, as with any Layer 2 > traffic, not enough MTU = dropped frame. > > Mark. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Thu Jan 9 09:26:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C221AE4BC; Thu, 9 Jan 2014 09:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eN9Jj6shE4V6; Thu, 9 Jan 2014 09:26:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD8C1AE391; Thu, 9 Jan 2014 09:26:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140109172615.1695.67630.idtracker@ietfa.amsl.com> Date: Thu, 09 Jan 2014 09:26:15 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-osborne-mpls-extended-admin-groups-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:26:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Extended Administrative Groups in MPLS-TE Author : Eric Osborne Filename : draft-osborne-mpls-extended-admin-groups-03.txt Pages : 6 Date : 2014-01-09 Abstract: This document provides additional administrative groups (sometimes referred to as "link colors") to the IGP extensions for MPLS-TE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-osborne-mpls-extended-admin-groups/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-osborne-mpls-extended-admin-groups= -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 gregory.mirsky@ericsson.com Thu Jan 9 09:30:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6752D1AE453; Thu, 9 Jan 2014 09:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58YQRyTm8sna; Thu, 9 Jan 2014 09:30:38 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 47A731AE3DC; Thu, 9 Jan 2014 09:30:38 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-26-52cedcb16bbb Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E5.D8.23183.1BCDEC25; Thu, 9 Jan 2014 18:30:26 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0347.000; Thu, 9 Jan 2014 12:30:28 -0500 From: Gregory Mirsky To: Loa Andersson , "mark.tinka@seacom.mu" , "stbryant@cisco.com" Thread-Topic: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Thread-Index: AQHPDVZPwlV5fcTOlUKeWNcLbDwLU5p8pA3g Date: Thu, 9 Jan 2014 17:30:27 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B743FDC@eusaamb103.ericsson.se> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> <201401091437.04245.mark.tinka@seacom.mu> <52CECB7B.3090200@pi.nu> In-Reply-To: <52CECB7B.3090200@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLonUHfTnXNBBj928FhsPbyW3eJ122xG i2cb57NYvP23gdViyll1i39z5zBb3Fu7mN3i1tKVrBbnns5htDj25i6bA5fHlN8bWT2OHJnN 4tHz+QWTx5IlP5k8ms4cZfaYNb2NzaPz2kT2APYoLpuU1JzMstQifbsEroyFx8+yFCwUqDix 5jlbA+Mnni5GTg4JAROJhklrmSBsMYkL99azdTFycQgJHGGU2PPhFDOEs4xR4uNOiCo2ASOJ Fxt72EFsEYFKiV/TdoF1MAu0M0lcWrsULCEskCWx/MwUIJsDqChb4uVSf4h6I4knX9sZQWwW ARWJ+5fug9m8Ar4Ssz4cg9p8k1Hi5/x7YHM4BVQlnh2aAGYzAp33/dQasCOYBcQlbj2ZD3W2 gMSSPeeZIWxRiZeP/7FC2MoS3+c8YoGo15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2C8nY WUhaZiFpmYWkZQEjyypGjtLi1LLcdCODTYzASD0mwaa7g3HPS8tDjNIcLErivF/eOgcJCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYLQqtLg5+02N5cIWkw+vvas/s66qeqbzTmWD16e8W89e Nbn9rZit/tq4a7rK3B9xHoGxv1h3TWb8tCJykWN++PVNu623PGY9LRp/cPe+NqaJDw6fK2D7 cv5SgfgG5VeT2xqU22wDJV0T3P+zq+9pnKzD1rxcWVmzNGlzx6kXFzc/+PH1T+lb9yVKLMUZ iYZazEXFiQBNPZh5ogIAAA== Cc: "gorry@erg.abdn.ac.uk" , "mpls@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" , "david.black@emc.com" , "jnc@mit.edu" , "tsvwg@ietf.org" Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:30:40 -0000 Hi Loa, et al., I think that you're referring to Connectivity Verification in MPLS-TP (RFC = 6428). It would only detect mis-connection but would not count leaked in fr= ames. Such problem may be more apparent in Segment Routing (SPRING WG). Perhaps C= V should be a requirement in SR OAM. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, January 09, 2014 8:17 AM To: mark.tinka@seacom.mu; stbryant@cisco.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com= ; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org Subject: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp= was RE: gre-in-udp draft Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled MPLS. > >> I am interested in how often in practice MPLS packets get=20 >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted MPLS frames=20 > so operators can glean this data. This isn't something I've come=20 > across, but it would be good to find some kind of way to count this=20 > across interfaces, if the routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- sized MTU=20 > interfaces. I have no empirical data as to how this can corrupt=20 > successive MPLS frames that may fit into the transit MTU. But in this=20 > case, as with any Layer 2 traffic, not enough MTU =3D dropped frame. > > Mark. > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From erosen@cisco.com Thu Jan 9 09:34:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B227C1AE4B5 for ; Thu, 9 Jan 2014 09:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 gcWV0T6j8Ug0 for ; Thu, 9 Jan 2014 09:34:35 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B4EAA1AE473 for ; Thu, 9 Jan 2014 09:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=950; q=dns/txt; s=iport; t=1389288866; x=1390498466; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=cxB043U8VPdQFBVR0PNH9i4kmt+ect8Y2yY8gNtkDzU=; b=IzEZJVxeDGA0OgRImkzfw0W6VtocQO0o5XoIOzZw8mrEhDFBQGon96ou BxtNFr+6GRJXA178Mcx76ZKYaz1ibumM1CXcm50d9jDkPHbC6CUmiN23F ihl23xqux9rX6Ny4CnQLNk0v7iDrk8lmraMX71knzFfBUGQ4+f2X0Owxe k=; X-IronPort-AV: E=Sophos;i="4.95,632,1384300800"; d="scan'208";a="99211543" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 09 Jan 2014 17:34:26 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s09HYPC2025920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 17:34:25 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id s09HYNBY023488; Thu, 9 Jan 2014 12:34:23 -0500 From: Eric Rosen To: adrian@olddog.co.uk In-reply-to: Your message of Thu, 09 Jan 2014 11:51:03 +0000. <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk> Date: Thu, 09 Jan 2014 12:34:23 -0500 Message-ID: <23487.1389288863@erosen-linux> Cc: mpls@ietf.org, stephen.farrell@cs.tcd.ie Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:34:36 -0000 > wondering whether anything could be done to help protect against various > types of bulk surveillance achieved by tapping entire links Aren't there link layer encryption schemes that protect the confidentiality of all traffic on the link? I don't see why one would want an MPLS-specific protocol for "single hop" encryption. I also don't understand the need for MPLS-specific "end-end" (probably "edge-edge" is what is meant) encryption, as one can always send traffic via IPsec. So, just what is the unsolved problem addressed by this draft? (I was going to ask whether RFC 5566 is relevant at all, but first it would be good to get a clear statement of the scenarios that are being addressed.) BTW, most of the draft seems to be about encryption and/or key distribution, which of course is out of scope for this WG. Surely the security ADs will not tolerate having the MPLS WG invent new key distribution protocols. From huubatwork@gmail.com Thu Jan 9 09:59:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3916B1AE037; Thu, 9 Jan 2014 09:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1w5ISvsAUPS; Thu, 9 Jan 2014 09:59:05 -0800 (PST) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7D1ADF8C; Thu, 9 Jan 2014 09:59:04 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id h10so1618109eak.16 for ; Thu, 09 Jan 2014 09:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/vxgliJ4X1BuIFdyXzXCO5LYDKB3JmRy977VfMjxC08=; b=Qvy5cbOwTeQylcAQEAQy1Y9jxlAyMpOL5lHPHMRL5/6PYHD2n9rLnBZXszwVqj3L2n x2Sdv+5vZEhOrVF4F2ZBS8CkAIj1yaikwWLX319/ehTNukfKDlwKBY6hAtr7cmmTp52W oq9IckDe5Wv6OrQ2uquUx0BukzkIWv8qyGu/TpbFefMsUqp23SZMXWvtCKtUPAhgliMY nP+IFp9iNRh4W3N3zW5N+iddX20XQsYVGWH5mJptPp8EHOCJfRO+cM+2cOa3FFRrkAKw FcNXGzHFpS/Vg6D9BzdMiNX69HKBZS5FqN6+m3B0C2Pst1HBpTctxYRpDq7+zd6dH9gj 6r/w== X-Received: by 10.14.5.194 with SMTP id 42mr4690805eel.100.1389290335030; Thu, 09 Jan 2014 09:58:55 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id v1sm7582058eef.9.2014.01.09.09.58.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jan 2014 09:58:54 -0800 (PST) Message-ID: <52CEE358.1050309@gmail.com> Date: Thu, 09 Jan 2014 18:58:48 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gregory Mirsky References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> <201401091437.04245.mark.tinka@seacom.mu> <52CECB7B.3090200@pi.nu> <7347100B5761DC41A166AC17F22DF1121B743FDC@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B743FDC@eusaamb103.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "tsvwg@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:59:07 -0000 Hello Greg, You wrote: > I think that you're referring to Connectivity Verification in > MPLS-TP (RFC 6428). It would only detect mis-connection > but would not count leaked in frames. Indeed. However, there is the Loss Measurement tool which can be used to count dropped and mis-delivered packets. Note that the CV tool in G.8113.1 includes packet loss counting. > Such problem may be more apparent in Segment Routing (SPRING WG). > Perhaps CV should be a requirement in SR OAM. Indeed. Regards, Huub. -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From stephen.farrell@cs.tcd.ie Thu Jan 9 10:33:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215131AE075 for ; Thu, 9 Jan 2014 10:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 7iJUeGawh7CO for ; Thu, 9 Jan 2014 10:33:10 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 857151AE04F for ; Thu, 9 Jan 2014 10:33:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8DD51BE47; Thu, 9 Jan 2014 18:32:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5O0U5VO+ggW; Thu, 9 Jan 2014 18:32:58 +0000 (GMT) Received: from [10.87.48.14] (unknown [86.41.58.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1EF4BBE3F; Thu, 9 Jan 2014 18:32:58 +0000 (GMT) Message-ID: <52CEEB4F.2010609@cs.tcd.ie> Date: Thu, 09 Jan 2014 18:32:47 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: erosen@cisco.com, adrian@olddog.co.uk References: <23487.1389288863@erosen-linux> In-Reply-To: <23487.1389288863@erosen-linux> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 18:33:13 -0000 Hi Eric, On 01/09/2014 05:34 PM, Eric Rosen wrote: >> wondering whether anything could be done to help protect against various >> types of bulk surveillance achieved by tapping entire links > > Aren't there link layer encryption schemes that protect the confidentiality > of all traffic on the link? I don't see why one would want an MPLS-specific > protocol for "single hop" encryption. Are those widely used? I'd be interested to know. If not, then this tool as another tool in the toolbox may be of use. And those don't address the end-end (or edge-edge) cases, right? > I also don't understand the need for MPLS-specific "end-end" (probably > "edge-edge" is what is meant) encryption, as one can always send traffic > via IPsec. My understanding is that not all traffic being sent in an LSP is IP, is that wrong? (I'm told end-end is right also for an LSP, but am happy to admit my ignorance of terminology here.) > So, just what is the unsolved problem addressed by this draft? (I was going > to ask whether RFC 5566 is relevant at all, but first it would be good to > get a clear statement of the scenarios that are being addressed.) I guess I'd refer to draft-farrell-perpass-attack and draft-barnes-pervasive-problem. I realise you're not a big fan of at least the first one there. > BTW, most of the draft seems to be about encryption and/or key distribution, > which of course is out of scope for this WG. Surely the security ADs will > not tolerate having the MPLS WG invent new key distribution protocols. Heh. This one is happy. The other was was too when he had a read of this. If the draft looks like its attractive and useful then we can figure out how to process it so its handled properly. (I also forwarded Adrian's note to the perpass list - this might also be useful as a template for how to add OE to other protocols.) But we'll for sure get the right review. Cheers, S. > From mark.tinka@seacom.mu Thu Jan 9 10:48:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F401AE525; Thu, 9 Jan 2014 10:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 jXsUnWvkCvLP; Thu, 9 Jan 2014 10:48:47 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 192301AE52B; Thu, 9 Jan 2014 10:48:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W1KeO-0005FL-Qh; Thu, 09 Jan 2014 20:48:16 +0200 From: Mark Tinka Organization: SEACOM To: Loa Andersson Date: Thu, 9 Jan 2014 20:48:15 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091437.04245.mark.tinka@seacom.mu> <52CECB7B.3090200@pi.nu> In-Reply-To: <52CECB7B.3090200@pi.nu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7202981.cQ0BC7dWJg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401092048.16168.mark.tinka@seacom.mu> Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, david.black@emc.com, tsvwg@ietf.org, jnc@mit.edu, ietf@ietf.org Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 18:48:49 -0000 --nextPart7202981.cQ0BC7dWJg Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, January 09, 2014 06:16:59 PM Loa Andersson=20 wrote: > This would be possible to do with MPLS-TP OAM, wouldn't > it? Sorry, no experience.=20 I don't personally like MPLS-TP :-), but happy to hear of=20 any experiences from those that do. Mark. --nextPart7202981.cQ0BC7dWJg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJSzu7wAAoJEGcZuYTeKm+GfxkP/ArGFtdiH9YpCn6vMqW+OJ5k mIhR4Hhpu7DUOXHXVwUw1f24fUU/RrMdPvveiLFo6LJmWLo/w8D7fY9IvP+KXlu/ XFSth1OZOKHRQw27LHHm9iZKURnreMitSZnJ+dFyAsZHTOAyPHshBvDY1oYbKvbK qcPASfq+BXrQ2PfAkfWCXWYVHthS47FxFpcTxDOzLffnjhcAgxbb/eR75ieU34TY wa+tGlvgrb4D4THEJ5gHZiOWBR4Mtt/4bsNRAL8FKlX4UtcYYiuF++xYNQhPpQnB 0IJ/OFCWOb4/cB71hpe4STjrE2++CayAXExFM5f6Ypi+woNdynKOq56V36E2gOZe F32sX23IJ8cvU2yEOjYRkLtGnrsYGHlcl9kSh/t1gs5mCxq6yMiJFkwYyzrsv6Nz gTPmE4V16jpBQMb7Ojx3fJ1td0ltOlbJS32ITvbH0AWrlbCeybzn5NjDtNiDtIJO F+s21T3YPyII8xP7CELn5i06HxQKo81BuahYAv9cI8Nom6FsPUEAAMMe9Si43sLg tgbqtrfC2hox9xH83SiN4wboJZs/QeTeaaKSwgRBVtiM+rI1dVZahSBwSTKpCoxH fgG/fU1ssPcPdnuq2C7/UUMB5dYqfAwGugimChhJcnmEAMwYbeyoEu9WNq0cyHCC L43oBc1rSsXS51qjJLZW =aFJ/ -----END PGP SIGNATURE----- --nextPart7202981.cQ0BC7dWJg-- From agmalis@gmail.com Thu Jan 9 12:12:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5CF1AE049; Thu, 9 Jan 2014 12:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqN6D8ojfnmc; Thu, 9 Jan 2014 12:12:47 -0800 (PST) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D37071AE10B; Thu, 9 Jan 2014 12:12:46 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so808264qaq.15 for ; Thu, 09 Jan 2014 12:12: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:from:date:message-id:subject:to :cc:content-type; bh=LX/HdHP0vU4UfmPFt9sL8qmvL7+dWijc3NcyMBigIq0=; b=GJkU5aztNSdOByof9ww/pNN0+ndJZVX2SbcKG2xcqv/mRlQswQaYiehnqeW8bZ6IxB Dhj2dJ59Ut7RXDW5pw2+4YoYjLPivWqCV3EPwBQlpK22wiD8J2l9RQ4MPd1PbwTm4z+Y exALqeeveVSTv5Ad1u0r51Aud3+tzRK1y8nzwFtyL+MHTEkXJQQ+T7saAuLDBkMjFBxV Gf2YnEEHAy/wxsHDTwTYJ9lUpimIi5+hiV4Cq10V+SaFv3Zd1jUcsVkHzEdCzSv9+5BN ast+lwlMZD5/G9Hwm5rQBecYfkRZw8s5S4GeVXXJz9CalhLSIACWclOjNaD2yj/1RVQ3 f5cg== X-Received: by 10.224.72.81 with SMTP id l17mr298105qaj.88.1389298356984; Thu, 09 Jan 2014 12:12:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.120.130 with HTTP; Thu, 9 Jan 2014 12:12:16 -0800 (PST) In-Reply-To: <201401091437.04245.mark.tinka@seacom.mu> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> <201401091437.04245.mark.tinka@seacom.mu> From: "Andrew G. Malis" Date: Thu, 9 Jan 2014 15:12:16 -0500 Message-ID: To: mark.tinka@seacom.mu Content-Type: text/plain; charset=ISO-8859-1 Cc: gorry@erg.abdn.ac.uk, "mpls@ietf.org" , LISP mailing list list , david.black@emc.com, tsvwg@ietf.org, jnc@mit.edu, IETF Discussion Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 20:12:50 -0000 I suspect the only way that we can count "misdelivered" MPLS packets is by looking for missing packets at the receiver, such as by using the sequence number in the PW control word, TCP, or UDP header, depending on the MPLS LSP payload. Thinking about the consequences of an MPLS label somehow becoming corrupted in transit, nothing will happen until the corrupted label reaches the top of the stack. At that time, either the packet will be dropped because the corrupted label isn't in the local LIB, or it is in the database and the packet will be most likely forwarded out of the wrong interface, to be dropped at the next label pop because the label now at the top of the stack is most likely not in that router's LIB. Eventually, the packet will most likely be dropped in the network, or there is a small but nonzero probability that it will be delivered to an incorrect non-MPLS external interface after the last label has been popped. If the payload was a globally routable IP packet (not in an IP VPN) and PHP is in use, then the IP forwarding lookup in the LER may get the packet to the right place (which will most probably be not on that particular LER). Even if PHP isn't in use, if the external interface happens to be to another router in the same IP address space, then again IP forwarding may get the packet to the right place. Of course, it could be a PW control word that gets corrupted, in which case the packets would reach the PW termination point, but would fail the sequence number check if the sequence number is in use and that's the part of the CW that was corrupted. I don't think anything really bad happens if an entropy label is corrupted. An interesting thought experiment. Cheers, Andy On Thu, Jan 9, 2014 at 7:36 AM, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled > MPLS. > >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted > MPLS frames so operators can glean this data. This isn't > something I've come across, but it would be good to find > some kind of way to count this across interfaces, if the > routers can detect and report them. > > The known issue about mis-delivery of MPLS frames is poorly- > sized MTU interfaces. I have no empirical data as to how > this can corrupt successive MPLS frames that may fit into > the transit MTU. But in this case, as with any Layer 2 > traffic, not enough MTU = dropped frame. > > Mark. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From david.i.allan@ericsson.com Thu Jan 9 12:26:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA701AE425; Thu, 9 Jan 2014 12:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8avMEAKu9fRr; Thu, 9 Jan 2014 12:26:44 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 18DCF1AE411; Thu, 9 Jan 2014 12:26:44 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-25-52cf05f6cddf Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A7.B2.23183.6F50FC25; Thu, 9 Jan 2014 21:26:31 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0347.000; Thu, 9 Jan 2014 15:26:28 -0500 From: David Allan I To: Gregory Mirsky , "mpls@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Thread-Index: AQHPDVZP/GN/wtlIskG6flItphhfHpp8+h2A///ZBGA= Date: Thu, 9 Jan 2014 20:26:27 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <201401091303.53239.mark.tinka@seacom.mu> <52CE914B.7070506@cisco.com> <201401091437.04245.mark.tinka@seacom.mu> <52CECB7B.3090200@pi.nu> <7347100B5761DC41A166AC17F22DF1121B743FDC@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B743FDC@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyuXRPoO531vNBBn+/2Fg82zifxWLKWXWL W0tXsloce3OXzYHFY8mSn0wBjFFcNimpOZllqUX6dglcGac3rGUuOCtR0XnmKnMD41vhLkYO DgkBE4mNU3y7GDmBTDGJC/fWs3UxcnEICRxhlJjU/ZkVwlnGKLG9eQ0rSBWbgIHEnv9fGEES IgK7GCXuHp7PApIQFsiSWH5mCjvIVBGBbImXS/1BwiICVhKrLpxmB7FZBFQklk7bzAhi8wr4 Snze/B9q21wmif8Lf4Et4BTwk3i5YyaYzQh00vdTa5hAbGYBcYlbT+YzQZwqILFkz3lmCFtU 4uXjf6wQtrLE9zmPWCDqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsoqRo7Q4tSw33chgEyMwLo5JsOnuYNzz0vIQozQHi5I475e3zkFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGK13Jj+/q3D3CuvaH6GzePcUJ4YsSD8e9vmMu4rwlU8eGTUd+1pLTET2 XJ706sDkAEc+TpnvZ+rebPgYzHXUy/3qzbXtlif2TxIImFamcj3n9/2KrOCQ8z5Fts3iQos/ 1Mmuc/gWs+ZOBUPe5IKbIvNY5lq13bv2RidlQsXD+isrLRMPL5OynabEUpyRaKjFXFScCABg f1O7WQIAAA== Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 20:26:46 -0000 Hi (trimmed received list) I'm not sure what the starting point of this dialog is, but I can at least = say Greg is right on the CV front, it only detects and does not measure mis= direction.=20 The only other possibility to count anything is a "no ILM" condition where = the label value is unrecognized by the receiving LSR, which IMO could not b= e made authoritative if it is label values in either the frame or the NHLFE= and not exclusively next hops that is corrupted. Cheers D -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, January 09, 2014 9:30 AM To: Loa Andersson; mark.tinka@seacom.mu; stbryant@cisco.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; davi= d.black@emc.com; jnc@mit.edu; tsvwg@ietf.org Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in= -udp was RE: gre-in-udp draft Hi Loa, et al., I think that you're referring to Connectivity Verification in MPLS-TP (RFC = 6428). It would only detect mis-connection but would not count leaked in fr= ames. Such problem may be more apparent in Segment Routing (SPRING WG). Perhaps C= V should be a requirement in SR OAM. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, January 09, 2014 8:17 AM To: mark.tinka@seacom.mu; stbryant@cisco.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com= ; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org Subject: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp= was RE: gre-in-udp draft Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled MPLS. > >> I am interested in how often in practice MPLS packets get=20 >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted MPLS frames=20 > so operators can glean this data. This isn't something I've come=20 > across, but it would be good to find some kind of way to count this=20 > across interfaces, if the routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- sized MTU=20 > interfaces. I have no empirical data as to how this can corrupt=20 > successive MPLS frames that may fit into the transit MTU. But in this=20 > case, as with any Layer 2 traffic, not enough MTU =3D dropped frame. > > Mark. > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Thu Jan 9 18:18:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3653D1ADF8A; Thu, 9 Jan 2014 18:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 J6UI_-fdkPL0; Thu, 9 Jan 2014 18:18:15 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7F1ADF65; Thu, 9 Jan 2014 18:18:14 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0A2Hv4I081006; Thu, 9 Jan 2014 21:17:57 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401100217.s0A2Hv4I081006@maildrop2.v6ds.occnc.com> To: David Allan I From: Curtis Villamizar In-reply-to: Your message of "Thu, 09 Jan 2014 20:26:27 +0000." Date: Thu, 09 Jan 2014 21:17:57 -0500 Cc: "mpls@ietf.org" , "tsvwg@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 02:18:18 -0000 Since we are all top posting ... For counting dropped packets LM OAM is what you need. CV doesn't do that. Direct LM will give best results on a per LSP basis but requires forwarding chip support to do so. I also don't know the origin of this discussion. >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. Not very often if ever at least for major vendor products. I don't know if second tier or third tier players have bugs. (Very often circa 2000 or earlier particularly with one specific vendor and with one provider who made things much worse by mucking with the ILM through management plane, but that is ancient history). Bit rot in TCAM or SRAM is very rare. Bit rot in circa 1980s DRAM was a problem. Bit rot in modern non-ECC DRAM is rare. Bit rot in modern ECC DRAM is very rare. Therefore to have a bad ILM you need bugs. Curtis In message David Allan I writes: Hi (trimmed received list) I'm not sure what the starting point of this dialog is, but I can at least say Greg is right on the CV front, it only detects and does not measure misdirection. The only other possibility to count anything is a "no ILM" condition where the label value is unrecognized by the receiving LSR, which IMO could not be made authoritative if it is label values in either the frame or the NHLFE and not exclusively next hops that is corrupted. Cheers D -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, January 09, 2014 9:30 AM To: Loa Andersson; mark.tinka@seacom.mu; stbryant@cisco.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; david.black@emc.com; jnc@mit.edu; tsvwg@ietf.org Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Hi Loa, et al., I think that you're referring to Connectivity Verification in MPLS-TP (RFC 6428). It would only detect mis-connection but would not count leaked in frames. Such problem may be more apparent in Segment Routing (SPRING WG). Perhaps CV should be a requirement in SR OAM. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, January 09, 2014 8:17 AM To: mark.tinka@seacom.mu; stbryant@cisco.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org Subject: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled MPLS. > >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted MPLS frames > so operators can glean this data. This isn't something I've come > across, but it would be good to find some kind of way to count this > across interfaces, if the routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- sized MTU > interfaces. I have no empirical data as to how this can corrupt > successive MPLS frames that may fit into the transit MTU. But in this > case, as with any Layer 2 traffic, not enough MTU = dropped frame. > > Mark. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From xuxiaohu@huawei.com Thu Jan 9 19:46:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836C81AE004; Thu, 9 Jan 2014 19:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 SZYX0prRW3cO; Thu, 9 Jan 2014 19:46:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD271ADFAF; Thu, 9 Jan 2014 19:46:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCI66147; Fri, 10 Jan 2014 03:46:14 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 03:45:36 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 03:46:13 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 11:46:07 +0800 From: Xuxiaohu To: "Eggert, Lars" , IETF Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPDJU4xcLOVIDgI0yv/bpzgg7Unpp9UGqw Date: Fri, 10 Jan 2014 03:46:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> In-Reply-To: <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 03:46:27 -0000 SGkgTGFycywNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLg0KDQpJIHdvbmRlciB3 aGV0aGVyIHRoZSBmb2xsb3dpbmcgbW9kaWZpZWQgdGV4dCBmb3IgQ29uZ2VzdGlvbiBDb25zaWRl cmF0aW9uIHNlY3Rpb24gaXMgT0sgZnJvbSB5b3VyIHBvaW50IG9mIHZpZXc6DQoNClNpbmNlIHRo ZSBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uIGNhdXNlcyBNUExTIHBhY2tldHMgdG8gYmUgZm9y d2FyZGVkIHRocm91Z2ggIlVEUCB0dW5uZWxzIiwgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBndWlk ZWxpbmVzIGZvciBVRFAgdHVubmVscyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjMgb2YgW1JG QzU0MDVdIFNIT1VMRCBiZSBmb2xsb3dlZC4gU3BlY2lmaWNhbGx5LCBNUExTIGNhbiBjYXJyeSBh IG51bWJlciBvZiBkaWZmZXJlbnQgcHJvdG9jb2xzIGFzIHBheWxvYWRzLiBXaGVuIHRoZSBwYXls b2FkIHRyYWZmaWMgaXMgSVAtYmFzZWQgYW5kIGNvbmdlc3Rpb24tY29udHJvbGxlZCwgdGhlIFVE UCB0dW5uZWwgU0hPVUxEIE5PVCBlbXBsb3kgaXRzIG93biBjb25nZXN0aW9uIGNvbnRyb2wgbWVj aGFuaXNtLCBiZWNhdXNlIGNvbmdlc3Rpb24gbG9zc2VzIG9mIHR1bm5lbGVkIHRyYWZmaWMgd2ls bCBhbHJlYWR5IHRyaWdnZXIgYW4gYXBwcm9wcmlhdGUgY29uZ2VzdGlvbiByZXNwb25zZSBhdCB0 aGUgb3JpZ2luYWwgc2VuZGVycyBvZiB0aGUgdHVubmVsZWQgdHJhZmZpYy4gV2hlbiB0aGUgcGF5 bG9hZCB0cmFmZmljIGlzIG5vdCBrbm93biB0byBiZSBJUC1iYXNlZCwgb3IgaXMga25vd24gdG8g YmUgSVAtYmFzZWQgYnV0IG5vdCBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFAgdHVubmVs IFNIT1VMRCBlbXBsb3kgYW4gYXBwcm9wcmlhdGUgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlz bS4gRnVydGhlcm1vcmUsIGJlY2F1c2UgVURQIHR1bm5lbHMgYXJlIHVzdWFsbHkgYnVsay10cmFu c2ZlciBhcHBsaWNhdGlvbnMgYXMgZmFyIGFzIHRoZSBpbnRlcm1lZGlhdGUgcm91dGVycyBhcmUg Y29uY2VybmVkLCB0aGUgZ3VpZGVsaW5lcyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjEgb2Yg W1JGQzU0MDVdIFNIT1VMRCBhcHBseS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0t LS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBFZ2dlcnQsIExhcnMNCj4gt6LLzcqxvOQ6IDIwMTTE6jHUwjjI1SAxODoyMg0K PiDK1bz+yMs6IElFVEYNCj4gs63LzTogbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBSZTogW21wbHNd IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGlu ZyBNUExTDQo+IGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+IEhpLA0KPiANCj4g T24gMjAxNC0xLTIsIGF0IDE2OjE0LCBUaGUgSUVTRyA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+ IHdyb3RlOg0KPiA+IC0gJ0VuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFAnDQo+ID4gIDxkcmFmdC1p ZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+IA0KPiB0 aGlzIGRvY3VtZW50IG5lZWRzIHRvIGRlc2NyaWJlIGhvdyBpdCBhZGRyZXNzZXMgdGhlIGlzc3Vl cyByYWlzZWQgaW4gQkNQMTQ1DQo+IChSRkM1NDA1KS4gSXQgYWxyZWFkeSBjb250YWlucyBzb21l IHRleHQgYWJvdXQgbWVzc2FnZXMgc2l6ZXMgYW5kIGNvbmdlc3Rpb24NCj4gY29uc2lkZXJhdGlv bnMsIHdoaWNoIGlzIGdyZWF0LiBVbmZvcnR1bmF0ZWx5LCB0aGUgdGV4dCBhYm91dCBjb25nZXN0 aW9uDQo+IGNvbnNpZGVyYXRpb25zIGlzIG5vdCBmdWxseSBpbiBsaW5lIHdpdGggUkZDNTQwNS4N Cj4gDQo+IExhcnMNCg== From l.wood@surrey.ac.uk Thu Jan 9 20:22:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34CB1AE001; Thu, 9 Jan 2014 20:22:23 -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, RCVD_IN_DNSWL_MED=-2.3, 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 jxwNkA2w2dQi; Thu, 9 Jan 2014 20:22:20 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.118]) by ietfa.amsl.com (Postfix) with ESMTP id D307E1ADF5C; Thu, 9 Jan 2014 20:22:19 -0800 (PST) Received: from [193.109.255.147:34109] by server-14.bemta-14.messagelabs.com id E5/D4-12628-1757FC25; Fri, 10 Jan 2014 04:22:09 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-8.tower-72.messagelabs.com!1389327728!11897647!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2107 invoked from network); 10 Jan 2014 04:22:09 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-8.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jan 2014 04:22:09 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 10 Jan 2014 04:22:08 +0000 From: To: , Date: Fri, 10 Jan 2014 04:19:24 +0000 Thread-Topic: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Thread-Index: Ac8Nqj4MGzqvYffaRlKHQ/vzzrnSnQAEObyx Message-ID: <290E20B455C66743BE178C5C84F1240847E63346B8@EXMB01CMS.surrey.ac.uk> References: Your message of "Thu, 09 Jan 2014 20:26:27 +0000." , <201401100217.s0A2Hv4I081006@maildrop2.v6ds.occnc.com> In-Reply-To: <201401100217.s0A2Hv4I081006@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org, tsvwg@ietf.org, lisp@ietf.org Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 04:22:23 -0000 The origin of this discussion is zero UDP checksums and http://www.ietf.org/mail-archive/web/ietf/current/msg85354.html I suggest reading Jonathan Stone's papers and PhD thesis for a good understanding of where errors can come from. Lloyd Wood http://about.me/lloydwood ________________________________________ From: mpls [mpls-bounces@ietf.org] On Behalf Of Curtis Villamizar [curtis@i= pv6.occnc.com] Sent: 10 January 2014 02:17 To: David Allan I Cc: mpls@ietf.org; tsvwg@ietf.org; lisp@ietf.org; ietf@ietf.org Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-= mpls-in-udp was RE: gre-in-udp draft Since we are all top posting ... For counting dropped packets LM OAM is what you need. CV doesn't do that. Direct LM will give best results on a per LSP basis but requires forwarding chip support to do so. I also don't know the origin of this discussion. >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. Not very often if ever at least for major vendor products. I don't know if second tier or third tier players have bugs. (Very often circa 2000 or earlier particularly with one specific vendor and with one provider who made things much worse by mucking with the ILM through management plane, but that is ancient history). Bit rot in TCAM or SRAM is very rare. Bit rot in circa 1980s DRAM was a problem. Bit rot in modern non-ECC DRAM is rare. Bit rot in modern ECC DRAM is very rare. Therefore to have a bad ILM you need bugs. Curtis In message David Allan I writes: Hi (trimmed received list) I'm not sure what the starting point of this dialog is, but I can at least = say Greg is right on the CV front, it only detects and does not measure mis= direction. The only other possibility to count anything is a "no ILM" condition where = the label value is unrecognized by the receiving LSR, which IMO could not b= e made authoritative if it is label values in either the frame or the NHLFE= and not exclusively next hops that is corrupted. Cheers D -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, January 09, 2014 9:30 AM To: Loa Andersson; mark.tinka@seacom.mu; stbryant@cisco.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; davi= d.black@emc.com; jnc@mit.edu; tsvwg@ietf.org Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in= -udp was RE: gre-in-udp draft Hi Loa, et al., I think that you're referring to Connectivity Verification in MPLS-TP (RFC = 6428). It would only detect mis-connection but would not count leaked in fr= ames. Such problem may be more apparent in Segment Routing (SPRING WG). Perhaps C= V should be a requirement in SR OAM. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, January 09, 2014 8:17 AM To: mark.tinka@seacom.mu; stbryant@cisco.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com= ; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org Subject: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp= was RE: gre-in-udp draft Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled MPLS. > >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted MPLS frames > so operators can glean this data. This isn't something I've come > across, but it would be good to find some kind of way to count this > across interfaces, if the routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- sized MTU > interfaces. I have no empirical data as to how this can corrupt > successive MPLS frames that may fit into the transit MTU. But in this > case, as with any Layer 2 traffic, not enough MTU =3D dropped frame. > > Mark. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Fri Jan 10 01:16:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24341ADBE5; Fri, 10 Jan 2014 01:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.25 X-Spam-Level: X-Spam-Status: No, score=-7.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 F5WWUgbbWk6U; Fri, 10 Jan 2014 01:16:07 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id A9D201ACCFF; Fri, 10 Jan 2014 01:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2578; q=dns/txt; s=iport; t=1389345357; x=1390554957; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uMgQFsVuArum1DXQg86uzbpQK6+XtgZVztJ0skbJ8SA=; b=L7EBd4RK/Ix02bMXEM0Om7A3xKzA2PBWu6EwOnFvbQXBa/PCCZgwuGLA AsbCmzWQ6gakTD2yx2DT76g0Qv5NCmwJiWyDXP9wItGaW+J/ejVrAli/4 1HOYQEl2NKpy6FqJMo+rysYlUNwdw8VdPhO0yeP+Snh1KWXy8ta8bx3v2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FABm5z1KQ/khM/2dsb2JhbABZgws4g1S2QoEHFnSCJQEBAQQBAQFrCgEQCQIYBAUWBAQFAgkDAgECARUfEQYBCQMBBQIBAYgADYxGm2sImngXgSWNLTMHgmuBTASJEI8HkhWBb4E+ X-IronPort-AV: E=Sophos;i="4.95,637,1384300800"; d="scan'208";a="2762080" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 10 Jan 2014 09:15:56 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0A9Ftdp015696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 09:15:55 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0A9Frcj006408; Fri, 10 Jan 2014 09:15:54 GMT Message-ID: <52CFBA49.8070500@cisco.com> Date: Fri, 10 Jan 2014 09:15:53 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Xuxiaohu , "Eggert, Lars" , IETF References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:16:10 -0000 RFC3985/6.5. Congestion Considerations may have some useful text.=20 We have a lot of deployment experience with PWs and frankly I have never seen a congestion complain raised from the field. Stewart On 10/01/2014 03:46, Xuxiaohu wrote: > Hi Lars, > > Thanks a lot for your comments. > > I wonder whether the following modified text for Congestion Considerati= on section is OK from your point of view: > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded= through "UDP tunnels", the congestion control guidelines for UDP tunnels= as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specificall= y, MPLS can carry a number of different protocols as payloads. When the p= ayload traffic is IP-based and congestion-controlled, the UDP tunnel SHOU= LD NOT employ its own congestion control mechanism, because congestion lo= sses of tunneled traffic will already trigger an appropriate congestion r= esponse at the original senders of the tunneled traffic. When the payload= traffic is not known to be IP-based, or is known to be IP-based but not = congestion-controlled, the UDP tunnel SHOULD employ an appropriate conges= tion control mechanism. Furthermore, because UDP tunnels are usually bulk= -transfer applications as far as the intermediate routers are concerned, = the guidelines as defined in Section 3.1.1 of [RFC5405] SHOULD apply. > > Best regards, > Xiaohu > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: mpls [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED E= ggert, Lars >> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C28=C8=D5 18:22 >> =CA=D5=BC=FE=C8=CB: IETF >> =B3=AD=CB=CD: mpls@ietf.org >> =D6=F7=CC=E2: Re: [mpls] Last Call: (E= ncapsulating MPLS >> in UDP) to Proposed Standard >> >> Hi, >> >> On 2014-1-2, at 16:14, The IESG wrote: >>> - 'Encapsulating MPLS in UDP' >>> as Proposed Standard >> >> this document needs to describe how it addresses the issues raised in = BCP145 >> (RFC5405). It already contains some text about messages sizes and cong= estion >> considerations, which is great. Unfortunately, the text about congesti= on >> considerations is not fully in line with RFC5405. >> >> Lars > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --=20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From xuxiaohu@huawei.com Fri Jan 10 02:07:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3401ADF7F; Fri, 10 Jan 2014 02:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.55 X-Spam-Level: * X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 7TsOjR_Z2SOJ; Fri, 10 Jan 2014 02:07:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D01A61ADF6D; Fri, 10 Jan 2014 02:07:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCI93416; Fri, 10 Jan 2014 10:06:51 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 10:06:11 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 10:06:49 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 18:06:41 +0800 From: Xuxiaohu To: "Eggert, Lars" Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPDJU4xcLOVIDgI0yv/bpzgg7Unpp9UGqw///RhoCAAJa00A== Date: Fri, 10 Jan 2014 10:06:41 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08243BB4@NKGEML512-MBS.china.huawei.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> In-Reply-To: <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , IETF Subject: [mpls] =?gb2312?b?tPC4tDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxz?= =?gb2312?b?LWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0?= =?gb2312?b?byBQcm9wb3NlZCBTdGFuZGFyZA==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:07:05 -0000 SGkgTGFycywNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBFZ2dlcnQsIExhcnMg W21haWx0bzpsYXJzQG5ldGFwcC5jb21dDQo+ILeiy83KsbzkOiAyMDE0xOox1MIxMMjVIDE2OjQ4 DQo+IMrVvP7IyzogWHV4aWFvaHUNCj4gs63LzTogSUVURjsgbXBsc0BpZXRmLm9yZw0KPiDW98zi OiBSZTogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1 bGF0aW5nIE1QTFMgaW4gVURQKQ0KPiB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gSGksDQo+ IA0KPiB0aGF0IHNvdW5kcyBnb29kLiBXaGF0IGNvbmdlc3Rpb24gY29udHJvbCBhcmUgeW91IGdv aW5nIHRvIGJlIHNwZWNpZnlpbmcgZm9yDQo+IHlvdXIgdHVubmVsPw0KDQpJTUhPLCB0aGlzIGlz IGEgY29tbW9uIGlzc3VlIHdpdGggYW55IG90aGVyIGVuY2Fwc3VsYXRpb25zIGZvciBNUExTIGFu ZCBldmVuIG90aGVyIGFwcGxpY2F0aW9ucyBvZiBVRFAgdHVubmVscyAuIE9mIGNvdXJzZSwgdGhl IGZvbGxvd2luZyB0ZXh0IGNvdWxkIGJlIGFkZGVkIGlmIHdlIGJlbGlldmUgaXQncyBuZWNlc3Nh cnk6IA0KDQogICAiLi4uYXBwbGljYXRpb25zIHRoYXQgdXNlcyB0aGUgZW5jYXBzdWxhdGlvbiBh cyBzcGVjaWZpZWQgaW4gdGhpcw0KICAgZG9jdW1lbnQgU0hPVUxEIG1vbml0b3IgdGhlIHBhY2tl dCBsb3NzIHJhdGUgdG8gZW5zdXJlIHRoYXQgaXQgaXMNCiAgIHdpdGhpbiBhY2NlcHRhYmxlIHBh cmFtZXRlcnMuIFBhY2tldCBsb3NzIGlzIGNvbnNpZGVyZWQgYWNjZXB0YWJsZQ0KICAgaWYgYSBU Q1AgZmxvdyBhY3Jvc3MgdGhlIHNhbWUgbmV0d29yayBwYXRoIHVuZGVyIHRoZSBzYW1lIG5ldHdv cmsNCiAgIGNvbmRpdGlvbnMgd291bGQgYWNoaWV2ZSBhbiBhdmVyYWdlIHRocm91Z2hwdXQsIG1l YXN1cmVkIG9uIGENCiAgIHJlYXNvbmFibGUgdGltZXNjYWxlLCB0aGF0IGlzIG5vdCBsZXNzIHRo YW4gdGhhdCBvZiB0aGUgTVBMUy1pbi1VRFAgZmxvdy4NCiAgIFRoZSBjb21wYXJpc29uIHRvIFRD UCBjYW5ub3QgYmUgc3BlY2lmaWVkIGV4YWN0bHksIGJ1dCBpcyBpbnRlbmRlZCBhcw0KICAgYW4g Im9yZGVyLW9mLW1hZ25pdHVkZSIgY29tcGFyaXNvbiBpbiB0aW1lc2NhbGUgYW5kIHRocm91Z2hw dXQuDQoNCiAgIEluIGVzc2VuY2UsIHRoaXMgcmVxdWlyZW1lbnQgc3RhdGVzIHRoYXQgaXQgaXMN CiAgIG5vdCBhY2NlcHRhYmxlIHRvIGRlcGxveSBhbiBhcHBsaWNhdGlvbiB1c2luZyB0aGUgZW5j YXBzdWxhdGlvbg0KICAgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgb24gdGhlIGJlc3QtZWZm b3J0IEludGVybmV0LCB3aGljaA0KICAgY29uc3VtZXMgYmFuZHdpZHRoIGFyYml0cmFyaWx5IGFu ZCBkb2VzIG5vdCBjb21wZXRlIGZhaXJseSB3aXRoIFRDUA0KICAgd2l0aGluIGFuIG9yZGVyIG9m IG1hZ25pdHVkZS4gT25lIG1ldGhvZCBvZiBkZXRlcm1pbmluZyBhbg0KICAgYWNjZXB0YWJsZSBi YW5kd2lkdGggaXMgZGVzY3JpYmVkIGluIFtSRkMzNDQ4XS4gIg0KDQpCZXN0IHJlZ2FyZHMsDQpY aWFvaHUNCg0KDQo+IExhcnMNCj4gDQo+IE9uIDIwMTQtMS0xMCwgYXQgNDo0NiwgWHV4aWFvaHUg PHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gPiBIaSBMYXJzLA0KPiA+DQo+ID4g VGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLg0KPiA+DQo+ID4gSSB3b25kZXIgd2hldGhl ciB0aGUgZm9sbG93aW5nIG1vZGlmaWVkIHRleHQgZm9yIENvbmdlc3Rpb24gQ29uc2lkZXJhdGlv bg0KPiBzZWN0aW9uIGlzIE9LIGZyb20geW91ciBwb2ludCBvZiB2aWV3Og0KPiA+DQo+ID4gU2lu Y2UgdGhlIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24gY2F1c2VzIE1QTFMgcGFja2V0cyB0byBi ZSBmb3J3YXJkZWQNCj4gdGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250 cm9sIGd1aWRlbGluZXMgZm9yIFVEUCB0dW5uZWxzIGFzDQo+IGRlZmluZWQgaW4gU2VjdGlvbiAz LjEuMyBvZiBbUkZDNTQwNV0gU0hPVUxEIGJlIGZvbGxvd2VkLiBTcGVjaWZpY2FsbHksIE1QTFMN Cj4gY2FuIGNhcnJ5IGEgbnVtYmVyIG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMgcGF5bG9hZHMu IFdoZW4gdGhlIHBheWxvYWQgdHJhZmZpYw0KPiBpcyBJUC1iYXNlZCBhbmQgY29uZ2VzdGlvbi1j b250cm9sbGVkLCB0aGUgVURQIHR1bm5lbCBTSE9VTEQgTk9UIGVtcGxveSBpdHMNCj4gb3duIGNv bmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20sIGJlY2F1c2UgY29uZ2VzdGlvbiBsb3NzZXMgb2Yg dHVubmVsZWQNCj4gdHJhZmZpYyB3aWxsIGFscmVhZHkgdHJpZ2dlciBhbiBhcHByb3ByaWF0ZSBj b25nZXN0aW9uIHJlc3BvbnNlIGF0IHRoZSBvcmlnaW5hbA0KPiBzZW5kZXJzIG9mIHRoZSB0dW5u ZWxlZCB0cmFmZmljLiBXaGVuIHRoZSBwYXlsb2FkIHRyYWZmaWMgaXMgbm90IGtub3duIHRvIGJl DQo+IElQLWJhc2VkLCBvciBpcyBrbm93biB0byBiZSBJUC1iYXNlZCBidXQgbm90IGNvbmdlc3Rp b24tY29udHJvbGxlZCwgdGhlIFVEUA0KPiB0dW5uZWwgU0hPVUxEIGVtcGxveSBhbiBhcHByb3By aWF0ZSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLg0KPiBGdXJ0aGVybW9yZSwgYmVjYXVz ZSBVRFAgdHVubmVscyBhcmUgdXN1YWxseSBidWxrLXRyYW5zZmVyIGFwcGxpY2F0aW9ucyBhcyBm YXINCj4gYXMgdGhlIGludGVybWVkaWF0ZSByb3V0ZXJzIGFyZSBjb25jZXJuZWQsIHRoZSBndWlk ZWxpbmVzIGFzIGRlZmluZWQgaW4gU2VjdGlvbg0KPiAzLjEuMSBvZiBbUkZDNTQwNV0gU0hPVUxE IGFwcGx5Lg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4+IC0t LS0t08q8/tStvP4tLS0tLQ0KPiA+PiC3orz+yMs6IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gRWdnZXJ0LCBMYXJzDQo+ID4+ILeiy83KsbzkOiAyMDE0xOox1MI4yNUg MTg6MjINCj4gPj4gytW8/sjLOiBJRVRGDQo+ID4+ILOty806IG1wbHNAaWV0Zi5vcmcNCj4gPj4g 1vfM4jogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4 dD4NCj4gPj4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJk DQo+ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBPbiAyMDE0LTEtMiwgYXQgMTY6MTQsIFRoZSBJ RVNHIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4gd3JvdGU6DQo+ID4+PiAtICdFbmNhcHN1bGF0 aW5nIE1QTFMgaW4gVURQJw0KPiA+Pj4gPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiBh cyBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+Pg0KPiA+Pg0KPiA+PiB0aGlzIGRvY3VtZW50IG5lZWRz IHRvIGRlc2NyaWJlIGhvdyBpdCBhZGRyZXNzZXMgdGhlIGlzc3VlcyByYWlzZWQgaW4NCj4gPj4g QkNQMTQ1IChSRkM1NDA1KS4gSXQgYWxyZWFkeSBjb250YWlucyBzb21lIHRleHQgYWJvdXQgbWVz c2FnZXMgc2l6ZXMNCj4gPj4gYW5kIGNvbmdlc3Rpb24gY29uc2lkZXJhdGlvbnMsIHdoaWNoIGlz IGdyZWF0LiBVbmZvcnR1bmF0ZWx5LCB0aGUNCj4gPj4gdGV4dCBhYm91dCBjb25nZXN0aW9uIGNv bnNpZGVyYXRpb25zIGlzIG5vdCBmdWxseSBpbiBsaW5lIHdpdGggUkZDNTQwNS4NCj4gPj4NCj4g Pj4gTGFycw0KDQo= From xuxiaohu@huawei.com Fri Jan 10 02:07:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DA71ACD04; Fri, 10 Jan 2014 02:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.55 X-Spam-Level: * X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 xAQk_Ozv6tkZ; Fri, 10 Jan 2014 02:07:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 39CBF1AD7C0; Fri, 10 Jan 2014 02:07:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCI93476; Fri, 10 Jan 2014 10:07:23 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 10:06:39 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 10:07:16 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 18:07:14 +0800 From: Xuxiaohu To: "stbryant@cisco.com" , "Eggert, Lars" , IETF Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPDJU4xcLOVIDgI0yv/bpzgg7Unpp9UGqw///ZboCAAJRTEA== Date: Fri, 10 Jan 2014 10:07:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08243BC5@NKGEML512-MBS.china.huawei.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <52CFBA49.8070500@cisco.com> In-Reply-To: <52CFBA49.8070500@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg?= =?gb2312?b?dG8gUHJvcG9zZWQgU3RhbmRhcmQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:07:35 -0000 SGkgU3Rld2FydCwNCg0KVGhhbmtzIGZvciB0aGF0IGluZm9ybWF0aW9uIGFuZCBJIHdpbGwgbG9v ayBhdCBpdC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0t DQo+ILeivP7IyzogU3Rld2FydCBCcnlhbnQgW21haWx0bzpzdGJyeWFudEBjaXNjby5jb21dDQo+ ILeiy83KsbzkOiAyMDE0xOox1MIxMMjVIDE3OjE2DQo+IMrVvP7IyzogWHV4aWFvaHU7IEVnZ2Vy dCwgTGFyczsgSUVURg0KPiCzrcvNOiBtcGxzQGlldGYub3JnDQo+INb3zOI6IFJlOiBbbXBsc10g TGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5n IE1QTFMNCj4gaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gUkZDMzk4NS82LjUu ICBDb25nZXN0aW9uIENvbnNpZGVyYXRpb25zDQo+IG1heSBoYXZlIHNvbWUgdXNlZnVsIHRleHQu DQo+IA0KPiBXZSBoYXZlIGEgbG90IG9mIGRlcGxveW1lbnQgZXhwZXJpZW5jZSB3aXRoIFBXcyBh bmQgZnJhbmtseSBJIGhhdmUgbmV2ZXIgc2Vlbg0KPiBhIGNvbmdlc3Rpb24gY29tcGxhaW4gcmFp c2VkIGZyb20gdGhlIGZpZWxkLg0KPiANCj4gU3Rld2FydA0KPiANCj4gDQo+IA0KPiBPbiAxMC8w MS8yMDE0IDAzOjQ2LCBYdXhpYW9odSB3cm90ZToNCj4gPiBIaSBMYXJzLA0KPiA+DQo+ID4gVGhh bmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLg0KPiA+DQo+ID4gSSB3b25kZXIgd2hldGhlciB0 aGUgZm9sbG93aW5nIG1vZGlmaWVkIHRleHQgZm9yIENvbmdlc3Rpb24gQ29uc2lkZXJhdGlvbg0K PiBzZWN0aW9uIGlzIE9LIGZyb20geW91ciBwb2ludCBvZiB2aWV3Og0KPiA+DQo+ID4gU2luY2Ug dGhlIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24gY2F1c2VzIE1QTFMgcGFja2V0cyB0byBiZSBm b3J3YXJkZWQNCj4gdGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250cm9s IGd1aWRlbGluZXMgZm9yIFVEUCB0dW5uZWxzIGFzDQo+IGRlZmluZWQgaW4gU2VjdGlvbiAzLjEu MyBvZiBbUkZDNTQwNV0gU0hPVUxEIGJlIGZvbGxvd2VkLiBTcGVjaWZpY2FsbHksIE1QTFMNCj4g Y2FuIGNhcnJ5IGEgbnVtYmVyIG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMgcGF5bG9hZHMuIFdo ZW4gdGhlIHBheWxvYWQgdHJhZmZpYw0KPiBpcyBJUC1iYXNlZCBhbmQgY29uZ2VzdGlvbi1jb250 cm9sbGVkLCB0aGUgVURQIHR1bm5lbCBTSE9VTEQgTk9UIGVtcGxveSBpdHMNCj4gb3duIGNvbmdl c3Rpb24gY29udHJvbCBtZWNoYW5pc20sIGJlY2F1c2UgY29uZ2VzdGlvbiBsb3NzZXMgb2YgdHVu bmVsZWQNCj4gdHJhZmZpYyB3aWxsIGFscmVhZHkgdHJpZ2dlciBhbiBhcHByb3ByaWF0ZSBjb25n ZXN0aW9uIHJlc3BvbnNlIGF0IHRoZSBvcmlnaW5hbA0KPiBzZW5kZXJzIG9mIHRoZSB0dW5uZWxl ZCB0cmFmZmljLiBXaGVuIHRoZSBwYXlsb2FkIHRyYWZmaWMgaXMgbm90IGtub3duIHRvIGJlDQo+ IElQLWJhc2VkLCBvciBpcyBrbm93biB0byBiZSBJUC1iYXNlZCBidXQgbm90IGNvbmdlc3Rpb24t Y29udHJvbGxlZCwgdGhlIFVEUA0KPiB0dW5uZWwgU0hPVUxEIGVtcGxveSBhbiBhcHByb3ByaWF0 ZSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLg0KPiBGdXJ0aGVybW9yZSwgYmVjYXVzZSBV RFAgdHVubmVscyBhcmUgdXN1YWxseSBidWxrLXRyYW5zZmVyIGFwcGxpY2F0aW9ucyBhcyBmYXIN Cj4gYXMgdGhlIGludGVybWVkaWF0ZSByb3V0ZXJzIGFyZSBjb25jZXJuZWQsIHRoZSBndWlkZWxp bmVzIGFzIGRlZmluZWQgaW4gU2VjdGlvbg0KPiAzLjEuMSBvZiBbUkZDNTQwNV0gU0hPVUxEIGFw cGx5Lg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4+IC0tLS0t 08q8/tStvP4tLS0tLQ0KPiA+PiC3orz+yMs6IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmddILT6se0gRWdnZXJ0LCBMYXJzDQo+ID4+ILeiy83KsbzkOiAyMDE0xOox1MI4yNUgMTg6 MjINCj4gPj4gytW8/sjLOiBJRVRGDQo+ID4+ILOty806IG1wbHNAaWV0Zi5vcmcNCj4gPj4g1vfM 4jogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4N Cj4gPj4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBPbiAyMDE0LTEtMiwgYXQgMTY6MTQsIFRoZSBJRVNH IDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4gd3JvdGU6DQo+ID4+PiAtICdFbmNhcHN1bGF0aW5n IE1QTFMgaW4gVURQJw0KPiA+Pj4gIDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gYXMg UHJvcG9zZWQgU3RhbmRhcmQNCj4gPj4NCj4gPj4gdGhpcyBkb2N1bWVudCBuZWVkcyB0byBkZXNj cmliZSBob3cgaXQgYWRkcmVzc2VzIHRoZSBpc3N1ZXMgcmFpc2VkIGluDQo+ID4+IEJDUDE0NSAo UkZDNTQwNSkuIEl0IGFscmVhZHkgY29udGFpbnMgc29tZSB0ZXh0IGFib3V0IG1lc3NhZ2VzIHNp emVzDQo+ID4+IGFuZCBjb25nZXN0aW9uIGNvbnNpZGVyYXRpb25zLCB3aGljaCBpcyBncmVhdC4g VW5mb3J0dW5hdGVseSwgdGhlDQo+ID4+IHRleHQgYWJvdXQgY29uZ2VzdGlvbiBjb25zaWRlcmF0 aW9ucyBpcyBub3QgZnVsbHkgaW4gbGluZSB3aXRoIFJGQzU0MDUuDQo+ID4+DQo+ID4+IExhcnMN Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiANCj4gDQo+IC0tDQo+IEZvciBjb3Jwb3Jh dGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQo+IA0KPiBodHRwOi8vd3d3LmNpc2NvLmNvbS93 ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwNCj4gDQoNCg== From lars@netapp.com Fri Jan 10 00:47:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2241AD0F0; Fri, 10 Jan 2014 00:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 scnrZ1SSCbdp; Fri, 10 Jan 2014 00:47:46 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id EC1D51A9313; Fri, 10 Jan 2014 00:47:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,637,1384329600"; d="asc'?scan'208";a="95233738" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 10 Jan 2014 00:47:36 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Fri, 10 Jan 2014 00:47:35 -0800 From: "Eggert, Lars" To: Xuxiaohu Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gA== Date: Fri, 10 Jan 2014 08:47:35 +0000 Message-ID: <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_83EDAABB-5D4B-4EB6-8739-F7B6E64D302C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 10 Jan 2014 07:17:36 -0800 Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 08:47:47 -0000 --Apple-Mail=_83EDAABB-5D4B-4EB6-8739-F7B6E64D302C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi, that sounds good. What congestion control are you going to be specifying = for your tunnel? Lars On 2014-1-10, at 4:46, Xuxiaohu wrote: > Hi Lars, >=20 > Thanks a lot for your comments. >=20 > I wonder whether the following modified text for Congestion = Consideration section is OK from your point of view: >=20 > Since the MPLS-in-UDP encapsulation causes MPLS packets to be = forwarded through "UDP tunnels", the congestion control guidelines for = UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. = Specifically, MPLS can carry a number of different protocols as = payloads. When the payload traffic is IP-based and = congestion-controlled, the UDP tunnel SHOULD NOT employ its own = congestion control mechanism, because congestion losses of tunneled = traffic will already trigger an appropriate congestion response at the = original senders of the tunneled traffic. When the payload traffic is = not known to be IP-based, or is known to be IP-based but not = congestion-controlled, the UDP tunnel SHOULD employ an appropriate = congestion control mechanism. Furthermore, because UDP tunnels are = usually bulk-transfer applications as far as the intermediate routers = are concerned, the guidelines as defined in Section 3.1.1 of [RFC5405] = SHOULD apply. >=20 > Best regards, > Xiaohu >=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: mpls [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED = Eggert, Lars >> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C28=C8=D5 18:22 >> =CA=D5=BC=FE=C8=CB: IETF >> =B3=AD=CB=CD: mpls@ietf.org >> =D6=F7=CC=E2: Re: [mpls] Last Call: = (Encapsulating MPLS >> in UDP) to Proposed Standard >>=20 >> Hi, >>=20 >> On 2014-1-2, at 16:14, The IESG wrote: >>> - 'Encapsulating MPLS in UDP' >>> as Proposed Standard >>=20 >>=20 >> this document needs to describe how it addresses the issues raised in = BCP145 >> (RFC5405). It already contains some text about messages sizes and = congestion >> considerations, which is great. Unfortunately, the text about = congestion >> considerations is not fully in line with RFC5405. >>=20 >> Lars --Apple-Mail=_83EDAABB-5D4B-4EB6-8739-F7B6E64D302C 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----- iQCVAwUBUs+zpNZcnpRveo1xAQI5UwP/UXw1WuO+svt2Ths4EVAoNk1bxViGvtj8 8BVNQWdO2x9+99SO08qE2unslZJLdE7CiIQqKhbepSw3DIy2zXXjtNRj8tmDLvTt cTaMq7CRnwvf48202Yklmy2xCQ2PgT4qa3M8yJ3QPp12ejEqi3SFQWC8dIh4+UDL 6l2K3HMkK+Q= =T5qM -----END PGP SIGNATURE----- --Apple-Mail=_83EDAABB-5D4B-4EB6-8739-F7B6E64D302C-- From jmh@joelhalpern.com Fri Jan 10 07:37:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1A21AE09E; Fri, 10 Jan 2014 07:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.887 X-Spam-Level: X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 CKGWm1xEdHDa; Fri, 10 Jan 2014 07:37:00 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7312D1AE08E; Fri, 10 Jan 2014 07:37:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D78DB6200B8; Fri, 10 Jan 2014 07:36:50 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E83231C02DA; Fri, 10 Jan 2014 07:36:42 -0800 (PST) Message-ID: <52D01383.2080509@joelhalpern.com> Date: Fri, 10 Jan 2014 10:36:35 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Eggert, Lars" , Xuxiaohu References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> In-Reply-To: <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 15:37:05 -0000 X-List-Received-Date: Fri, 10 Jan 2014 15:37:05 -0000 Maybe I am completely missing things, but this looks wrong. If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion control will make it more likely that the service won't work. Is that really the goal? We do not perform congestion control on MPLS LSPs. Assuming that a UDP tunnel is carrying just MPLS and was established just for MPLS, why would we expect it to behave differently than an MPLS LSP running over the exact same path, carrying the exact same traffic? Yours, Joel On 1/10/14 3:47 AM, Eggert, Lars wrote: > Hi, > > that sounds good. What congestion control are you going to be specifying for your tunnel? > > Lars > > On 2014-1-10, at 4:46, Xuxiaohu wrote: > >> Hi Lars, >> >> Thanks a lot for your comments. >> >> I wonder whether the following modified text for Congestion Consideration section is OK from your point of view: >> >> Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded through "UDP tunnels", the congestion control guidelines for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically, MPLS can carry a number of different protocols as payloads. When the payload traffic is IP-based and congestion-controlled, the UDP tunnel SHOULD NOT employ its own congestion control mechanism, because congestion losses of tunneled traffic will already trigger an appropriate congestion response at the original senders of the tunneled traffic. When the payload traffic is not known to be IP-based, or is known to be IP-based but not congestion-controlled, the UDP tunnel SHOULD employ an appropriate congestion control mechanism. Furthermore, because UDP tunnels are usually bulk-transfer applications as far as the intermediate routers are concerned, the guidelines as defined in Section 3.1.1 of [RFC5405] SHOULD apply. >> >> Best regards, >> Xiaohu >> >>> -----ÓʼþÔ­¼þ----- >>> ·¢¼þÈË: mpls [mailto:mpls-bounces@ietf.org] ´ú±í Eggert, Lars >>> ·¢ËÍʱ¼ä: 2014Äê1ÔÂ8ÈÕ 18:22 >>> ÊÕ¼þÈË: IETF >>> ³­ËÍ: mpls@ietf.org >>> Ö÷Ìâ: Re: [mpls] Last Call: (Encapsulating MPLS >>> in UDP) to Proposed Standard >>> >>> Hi, >>> >>> On 2014-1-2, at 16:14, The IESG wrote: >>>> - 'Encapsulating MPLS in UDP' >>>> as Proposed Standard >>> >>> >>> this document needs to describe how it addresses the issues raised in BCP145 >>> (RFC5405). It already contains some text about messages sizes and congestion >>> considerations, which is great. Unfortunately, the text about congestion >>> considerations is not fully in line with RFC5405. >>> >>> Lars > From erosen@cisco.com Fri Jan 10 08:06:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96761AE0D8 for ; Fri, 10 Jan 2014 08:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 Bn_XCcmWdVWD for ; Fri, 10 Jan 2014 08:06:18 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 341D21AE0CB for ; Fri, 10 Jan 2014 08:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3620; q=dns/txt; s=iport; t=1389369968; x=1390579568; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=/54oyXII8KQH2t0g6liUaOIguOzrlgAtUagQTGexwjc=; b=QHqu3VzymNTnHW6LLC89gqKhQFTZJOFhFM5OE0h+fHvtF63Jw6oMp1kI aTPpgRFxDHkQef3ckahADqWOvJ6N1WnbyK7JkTH5q92xYl8plNJPdN/bF mfjjJirPZj7l0Dy8kLZaE027othtbIYyWtWMz7S0UGTYXUpg28Uq2wPKZ E=; X-IronPort-AV: E=Sophos;i="4.95,639,1384300800"; d="scan'208";a="296528626" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jan 2014 16:06:08 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0AG67ek015245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 16:06:08 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id s0AG6627006926; Fri, 10 Jan 2014 11:06:06 -0500 From: Eric Rosen To: Stephen Farrell In-reply-to: Your message of Thu, 09 Jan 2014 18:32:47 +0000. <52CEEB4F.2010609@cs.tcd.ie> Date: Fri, 10 Jan 2014 11:06:06 -0500 Message-ID: <6925.1389369966@erosen-linux> Cc: mpls@ietf.org Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:06:20 -0000 Eric> Aren't there link layer encryption schemes that protect the Eric> confidentiality of all traffic on the link? I don't see why one would Eric> want an MPLS-specific protocol for "single hop" encryption. Stephen> Are those widely used? I'd be interested to know. Well, if one thinks that "single hop" encryption is an important tool for ensuring privacy, the first thing one should do is look at the state of the art and figure out why there isn't more deployment. Stephen> If not, then this tool as another tool in the toolbox may be of Stephen> use. And why would an MPLS-specific single-hop encryption scheme gain any more deployment than a more general link layer encryption scheme? I suspect that service providers don't see how protecting their users' privacy in this manner is going to result in a positive return on investment for them. Stephen> And those don't address the end-end (or edge-edge) cases, right? Wouldn't ubiquitous link layer encryption be the best defense against any sort of wire tapping? Then not even the network addresses appear in the clear on the wire. Of course, an enduser who is worried about pervasive monitoring might not want to rely on the service providers to protect his traffic. But an edge-to-edge MPLS-specific scheme won't provide any more confidence, as it still relies on the service providers to ensure privacy. Endusers don't generate MPLS traffic. Stephen> I'm told end-end is right also for an LSP An LSP typically begins at the ingress point to a service provider backbone, and typically ends at the egress point of that backbone. There are scenarios in which there are multi-provider LSPs, but that is still not end-end, as the source and destination hosts are rarely involved. Note also that the ingress node and egress node of a particular LSP often do not have a control plane connection between them, and in many cases neither knows the identity of the other. There are a number of internet drafts that have addressed the use of IPsec in MPLS/BGP/VPN environments, e.g.: - draft-ietf-l3vpn-ipsec-2547-05 (expired) - RFC 4023, section 8.1 - RFC 5566 But there has never been enough interest (measured in dollars) to deploy any of the security schemes described in these drafts. > not all traffic being sent in an LSP is IP True enough. That doesn't preclude the use of IPsec, since one can always encapsulate anything inside IP and then use IPsec transport mode. That's what draft-ietf-l3vpn-ipsec-2547 proposed for one kind of non-IP packet (MPLS). Eric> So, just what is the unsolved problem addressed by this draft? Stephen> I guess I'd refer to draft-farrell-perpass-attack I don't think that draft mentions any MPLS-specific issues, nor does it suggest that there is a need to encrypt parts of the MPLS label stack. Since MPLS labels have local significance, I don't think there's that much to be learned by looking at the last billion label stacks that appeared on the wire. If there is some analysis to show otherwise, that would be interesting. Adrian> Some people have noted that per hop encryption/decryption might be Adrian> an issue. Others have countered that ETH h/w can already handle Adrian> MACsec at line rate. e2e encryption seems (to me) to be less likely Adrian> to be an issue. I think encryption at the network layer is much more complicated to do at scale than is encryption at the data link layer. There's just a lot more to figure out on a per-packet basis, and the system design becomes more complex. From agmalis@gmail.com Fri Jan 10 08:40:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472371AE0E1 for ; Fri, 10 Jan 2014 08:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyiv5nKI5PME for ; Fri, 10 Jan 2014 08:40:41 -0800 (PST) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BE6C91AE139 for ; Fri, 10 Jan 2014 08:40:30 -0800 (PST) Received: by mail-qe0-f43.google.com with SMTP id jy17so4629313qeb.16 for ; Fri, 10 Jan 2014 08:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2La0Es8Oj5YShoFY4xqeBnGV6ZtSlXk75ClL5ALfvss=; b=Ml7CQ3ZRPhqZ5Z1zV9hM1uYMD0ixrR8/R50TMQZdqt9YEfUcYltpz1HIQcggIfdOim etVhO/CRhQIqgvjqlAO4fLDAnCGBq/1PmJEIPgRFYnmR8qdP0e80CKU70GO17QnA565t tb+0cyXakisNmQmghLJ+hwZ6ubcXqziRFiMOHhU7KwkqSj6TKoPhfdbD4QtyeulUpIiG cZDPUgHaf2Q15bLhciFyOnDWGKgooZgRasfKoqeoWWhj7h7Gi35Zp/MObA6pTUNptAcI PsSghFn4tDIY8YWK2LaqvreJ8sYlhO+9qtwKlRTg3GYExXtazIvSHUDaKvCSBXwd8hDH UEaQ== X-Received: by 10.224.167.143 with SMTP id q15mr9153047qay.97.1389372020605; Fri, 10 Jan 2014 08:40:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.120.130 with HTTP; Fri, 10 Jan 2014 08:39:59 -0800 (PST) In-Reply-To: <6925.1389369966@erosen-linux> References: <52CEEB4F.2010609@cs.tcd.ie> <6925.1389369966@erosen-linux> From: "Andrew G. Malis" Date: Fri, 10 Jan 2014 11:39:59 -0500 Message-ID: To: erosen@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , Stephen Farrell Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:40:42 -0000 On Fri, Jan 10, 2014 at 11:06 AM, Eric Rosen wrote: > Adrian> Some people have noted that per hop encryption/decryption might be > Adrian> an issue. Others have countered that ETH h/w can already handle > Adrian> MACsec at line rate. e2e encryption seems (to me) to be less likely > Adrian> to be an issue. > > I think encryption at the network layer is much more complicated to do at > scale than is encryption at the data link layer. There's just a lot more to > figure out on a per-packet basis, and the system design becomes more > complex. I agree with Eric on this point. There is 100 GigE/OTU4 encryption commercially available (not to mention 10G and 40G as well), so why not just use that at the link layer? Cheers, Andy From lars@netapp.com Fri Jan 10 08:09:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB821AE0B0; Fri, 10 Jan 2014 08:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 Ld306yLTqEvc; Fri, 10 Jan 2014 08:09:56 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id AB2EF1AE074; Fri, 10 Jan 2014 08:09:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,639,1384329600"; d="asc'?scan'208";a="95307383" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 10 Jan 2014 08:09:45 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Fri, 10 Jan 2014 08:09:45 -0800 From: "Eggert, Lars" To: Joel Halpern Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQIA= Date: Fri, 10 Jan 2014 16:09:45 +0000 Message-ID: <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> In-Reply-To: <52D01383.2080509@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_314DE890-78FD-4040-92CF-9007B2DDAACD"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 10 Jan 2014 10:14:13 -0800 Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:09:58 -0000 --Apple-Mail=_314DE890-78FD-4040-92CF-9007B2DDAACD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi, On 2014-1-10, at 16:36, Joel M. Halpern wrote: > Maybe I am completely missing things, but this looks wrong. > If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion > control will make it more likely that the service won't work. Is that > really the goal? >=20 > We do not perform congestion control on MPLS LSPs. > Assuming that a UDP tunnel is carrying just MPLS and was established > just for MPLS, why would we expect it to behave differently than an = MPLS > LSP running over the exact same path, carrying the exact same traffic? we've been rehashing this discussion several times over the years, e.g., = for PWE, AMT, etc. In order to carry fixed-rate or otherwise = non-congestion-controlled traffic over unprovisioned general Internet = paths, there needs to be some sort of basic congestion control = mechanism, like a circuit breaker. The whole point of running MPLS is to create networks in which paths are = provisionable, so this is usually not an issue. But if you start = sticking MPLS inside of UDP, those packets can go anywhere on the net, = so you need mechanisms to control the rate of that traffic if it causes = congestion, or at the very least you need to be able to stop the traffic = if it creates severe congestion. Lars --Apple-Mail=_314DE890-78FD-4040-92CF-9007B2DDAACD 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----- iQCVAwUBUtAbRdZcnpRveo1xAQKbZwP+IUK3JgbtrPeA/EPYWCZorxenzX/vl9Sv qmgKPHdsu1nYPDq40+6sEDT6VAK3tdFyf6zdfYqd2mG4e9tl1TqH6w09nGogL8s4 9YMT/V7Vr3/pTeiH1eto5f9I2awxne7KgQzVGE6Rf1fdlS7gHNWbJ2JM/dfYI2q+ Vt6xaM88vFo= =CwSc -----END PGP SIGNATURE----- --Apple-Mail=_314DE890-78FD-4040-92CF-9007B2DDAACD-- From scott.brim@gmail.com Fri Jan 10 08:32:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC0B1ADF82; Fri, 10 Jan 2014 08:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlsNJGgmvQnh; Fri, 10 Jan 2014 08:32:40 -0800 (PST) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5AD1AD627; Fri, 10 Jan 2014 08:32:40 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id m1so5250696oag.38 for ; Fri, 10 Jan 2014 08:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=165ZdF+2oX1Ye1xTkK5qqQyAKPRPFKPwMcXRdeMRvyo=; b=lRYwYVdrE18UOEisnEDE8EM6qCL+E1AhAncmKUlyotZ5LHsDedid5LWOQUO315mQXJ cPdRuRtpqzcqUD89B5nnq9GMFKqXiRFflD7F6XoD4vVdmvvc5WpLbrbDDtuNcveo26g1 9q/W1f9EEJfLercEr0aW0iEZI2JvXcW12HDi3biIOQyLqc9LsRIaj28hOHnFsNit1gJ9 SVxj8XU+RlJM3YXkucypP9xNgY60XjzFhZa5mydmNto4/t4Vhu5ptPc7Jl++1kxzcdvQ P5v01iBTnxDsRXZjAxQAvBzklGFULOIESKiQ8UdqkS4JBzhCRDzSOfobtWdkq+g9o23o qWeA== X-Received: by 10.60.174.167 with SMTP id bt7mr7596938oec.54.1389371550528; Fri, 10 Jan 2014 08:32:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Fri, 10 Jan 2014 08:32:10 -0800 (PST) In-Reply-To: <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> From: Scott Brim Date: Fri, 10 Jan 2014 11:32:10 -0500 Message-ID: To: "Eggert, Lars" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 10 Jan 2014 10:14:34 -0800 Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:32:43 -0000 I don't think it's right to try to solve this in MPLS, because MPLS is not a forwarding protocol - it's a connectivity protocol. In any use of UDP, congestion control is either left to something above UDP or ignored (left to queue management). Similarly, you want the client of MPLS to be responsible for managing its traffic. MPLS gives you paths, it doesn't push packets over them. Scott On Fri, Jan 10, 2014 at 11:09 AM, Eggert, Lars wrote: > Hi, > > On 2014-1-10, at 16:36, Joel M. Halpern wrote: >> Maybe I am completely missing things, but this looks wrong. >> If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion >> control will make it more likely that the service won't work. Is that >> really the goal? >> >> We do not perform congestion control on MPLS LSPs. >> Assuming that a UDP tunnel is carrying just MPLS and was established >> just for MPLS, why would we expect it to behave differently than an MPLS >> LSP running over the exact same path, carrying the exact same traffic? > > we've been rehashing this discussion several times over the years, e.g., = for PWE, AMT, etc. In order to carry fixed-rate or otherwise non-congestion= -controlled traffic over unprovisioned general Internet paths, there needs = to be some sort of basic congestion control mechanism, like a circuit break= er. > > The whole point of running MPLS is to create networks in which paths are = provisionable, so this is usually not an issue. But if you start sticking M= PLS inside of UDP, those packets can go anywhere on the net, so you need me= chanisms to control the rate of that traffic if it causes congestion, or at= the very least you need to be able to stop the traffic if it creates sever= e congestion. > > Lars From gregory.mirsky@ericsson.com Fri Jan 10 10:24:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B00F1AE16E; Fri, 10 Jan 2014 10:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Stf5jOuFacCl; Fri, 10 Jan 2014 10:24:14 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0D771AE037; Fri, 10 Jan 2014 10:24:14 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-15-52d03ac08793 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 18.65.23183.0CA30D25; Fri, 10 Jan 2014 19:24:01 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0347.000; Fri, 10 Jan 2014 13:24:03 -0500 From: Gregory Mirsky To: "Eggert, Lars" , Joel Halpern Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPDi/NnXFwG1Tc20SQPsVMzJPOgJp+RLFA Date: Fri, 10 Jan 2014 18:24:02 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7447E4@eusaamb103.ericsson.se> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> In-Reply-To: <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPgu5BqwtBBu+2iFo82zifxeLjqTdM Fi9e97BY3Fq6ktWBxWPJkp9MHuemfGf0mPHpC1sAcxSXTUpqTmZZapG+XQJXxtJFO1gLbvJX 7H/+hrmB8SpPFyMnh4SAicSHtscsELaYxIV769lAbCGBI4wSDb3mEPZyRonN61NAbDYBI4kX G3vYQWwRAQ+Jz2t3g9nMApYSR2cfAusVFsiSeHDnByNETbbEwZ07mSBsI4ndG16A1bMIqErM a20Dq+EV8JW4suYG0A1cQLvOMkm0HN0I1sApYCdx9exusKGMQMd9P7WGCWKZuMStJ/OZII4W kFiy5zwzhC0q8fLxP1YIW1ni+5xHLBD1OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGMVmIRk7 C0nLLCQts5C0LGBkWcXIUVqcWpabbmSwiREYQ8ck2HR3MO55aXmIUZqDRUmc98tb5yAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjApCTtufOf+s3/L4q8N+myW71rWGZztMymF6lrgx8Ouu Hwx7Tp3aI7s5WaXK9B1b64ReBstPS8vlGoWubOsTuq9w4fuEN0XcW9wt3QUvynJoeMqxc79k 2CK63KJL6oUJp5DQThuZtCda55yv96zQeTBvyuNzX9u0hSK6ji/b/7Myd/1V2QMHliuxFGck GmoxFxUnAgBF/cFlbwIAAA== Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:24:16 -0000 Hi Lars, I think that " The whole point of running MPLS is to create networks in whi= ch paths are provisionable, so this is usually not an issue." is only parti= ally correct. LDP-based MPLS network is not provisionable and LSPs follow I= P best route selection. Explicit signaling of LSP is achievable in (G)MPLS = by using RSVP(-TE) signaling. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: Friday, January 10, 2014 8:10 AM To: Joel Halpern Cc: mpls@ietf.org; IETF Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Hi, On 2014-1-10, at 16:36, Joel M. Halpern wrote: > Maybe I am completely missing things, but this looks wrong. > If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion=20 > control will make it more likely that the service won't work. Is that=20 > really the goal? >=20 > We do not perform congestion control on MPLS LSPs. > Assuming that a UDP tunnel is carrying just MPLS and was established=20 > just for MPLS, why would we expect it to behave differently than an=20 > MPLS LSP running over the exact same path, carrying the exact same traffi= c? we've been rehashing this discussion several times over the years, e.g., fo= r PWE, AMT, etc. In order to carry fixed-rate or otherwise non-congestion-c= ontrolled traffic over unprovisioned general Internet paths, there needs to= be some sort of basic congestion control mechanism, like a circuit breaker= . The whole point of running MPLS is to create networks in which paths are pr= ovisionable, so this is usually not an issue. But if you start sticking MPL= S inside of UDP, those packets can go anywhere on the net, so you need mech= anisms to control the rate of that traffic if it causes congestion, or at t= he very least you need to be able to stop the traffic if it creates severe = congestion. Lars From edc@google.com Fri Jan 10 12:15:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E408B1AE1FB for ; Fri, 10 Jan 2014 12:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU1_r0L4YAmq for ; Fri, 10 Jan 2014 12:15:15 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id A53421AE1EE for ; Fri, 10 Jan 2014 12:15:15 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so4456266wes.41 for ; Fri, 10 Jan 2014 12:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Hf5/fpB19PPfk+FSGxeMnrQwJZrRFwb9PX8n8bCKxuo=; b=Jfo7uOeRco3InsSCqLhr4qvvgFWpul4/tsxwodTvfR5kbP4Ml8u/1BBnY3TvyDjs/2 coSCoRBk+Uwib2OayM+DhQ1c/RElJPy9WrFTpvAdbcyKjVQD20EB3zRoyzRDVrD1hQsD WcKQKc2hm3ZgQRSYO/G/tXbJHhAwaQks873bHoUjODPN/Nn/CO59nbkvgFB/3s4k7gN8 txCiehehYFKQZG4RN5YsXEsm40crTGplRj7ZOVUA6/sOi30xy/eMtC6nKk6CiCNjIELh wHsZgfAGxkYwtbUEzq/Z6j8XY2wqV1kgH0YEvB06JFPMPElur6mc8kYGoRYbKeDWvEnE da7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Hf5/fpB19PPfk+FSGxeMnrQwJZrRFwb9PX8n8bCKxuo=; b=KNuuDo16fKmv57jeR6VVNaHLbIncnRDT/f8WuDuQzjo608MY8fQsIgDg0uMPEXNnYv hrN7MNI7FQ0juLnYbEwL3CGZlns57zzkeoOB/8KF3AYFYi51miSMfEXuX8IwGnM/DLzH dYsiBV+a9BMbZLLsKnpUd80zhqr8qClwuKejGDqgrvH0fa8WDkcsMi0pe0dLl/4j3o0X HLAukjs4ZbTzPYn/yR89yJ1fQV+4Vb5oqk6ve9Q2ZgVqvXAabylo3lGA4RyGUcE0aBgY peMsrbh0qGxBDpHGQkry1Hw444NZkyQvnXILLEzzJKeevoIrTzOpIgwqBWLaFBcOAwAW WDkg== X-Gm-Message-State: ALoCoQn/fJp5WQNd+10tE1YGU88cC5kG+R3L64gK7BL3w7vLViLizec3IBT8E+kt9megLVf6HMDbT59wPZoWOnGAjKBFMlEGJd6RaHSrjBHn2rFPacuYJs3b4lfkPbklDMNLyiO4CEx7Q/dKu6jxW0LIhktDZNT4Brbjf5UNz4/mfhpwxcvqoNvGWy/jVdze1ydRkJyFbgDp X-Received: by 10.180.93.169 with SMTP id cv9mr4447242wib.3.1389384905056; Fri, 10 Jan 2014 12:15:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Fri, 10 Jan 2014 12:14:24 -0800 (PST) In-Reply-To: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> From: Edward Crabbe Date: Fri, 10 Jan 2014 12:14:24 -0800 Message-ID: To: Scott Brim Content-Type: multipart/alternative; boundary=f46d043c7fc0b917d704efa361e2 Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 20:15:18 -0000 --f46d043c7fc0b917d704efa361e2 Content-Type: text/plain; charset=ISO-8859-1 +1 Let the encapsulated transport protocols take care of the congestion end-to-end. On Fri, Jan 10, 2014 at 8:32 AM, Scott Brim wrote: > I don't think it's right to try to solve this in MPLS, because MPLS is > not a forwarding protocol - it's a connectivity protocol. In any use > of UDP, congestion control is either left to something above UDP or > ignored (left to queue management). Similarly, you want the client of > MPLS to be responsible for managing its traffic. MPLS gives you paths, > it doesn't push packets over them. > > Scott > > > On Fri, Jan 10, 2014 at 11:09 AM, Eggert, Lars wrote: > > Hi, > > > > On 2014-1-10, at 16:36, Joel M. Halpern wrote: > >> Maybe I am completely missing things, but this looks wrong. > >> If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion > >> control will make it more likely that the service won't work. Is that > >> really the goal? > >> > >> We do not perform congestion control on MPLS LSPs. > >> Assuming that a UDP tunnel is carrying just MPLS and was established > >> just for MPLS, why would we expect it to behave differently than an MPLS > >> LSP running over the exact same path, carrying the exact same traffic? > > > > we've been rehashing this discussion several times over the years, e.g., > for PWE, AMT, etc. In order to carry fixed-rate or otherwise > non-congestion-controlled traffic over unprovisioned general Internet > paths, there needs to be some sort of basic congestion control mechanism, > like a circuit breaker. > > > > The whole point of running MPLS is to create networks in which paths are > provisionable, so this is usually not an issue. But if you start sticking > MPLS inside of UDP, those packets can go anywhere on the net, so you need > mechanisms to control the rate of that traffic if it causes congestion, or > at the very least you need to be able to stop the traffic if it creates > severe congestion. > > > > Lars > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --f46d043c7fc0b917d704efa361e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1=A0

Let the encapsulated transport pr= otocols take care of the congestion end-to-end. =A0


On Fri, Jan 10, 2014 at= 8:32 AM, Scott Brim <scott.brim@gmail.com> wrote:
I don't think it's right to try to s= olve this in MPLS, because MPLS is
not a forwarding protocol - it's a connectivity protocol. In any use of UDP, congestion control is either left to something above UDP or
ignored (left to queue management). Similarly, you want the client of
MPLS to be responsible for managing its traffic. MPLS gives you paths,
it doesn't push packets over them.

Scott


On Fri, Jan 10, 2014 at 11:09 AM, Eggert, Lars <lars@netapp.com> wrote:
> Hi,
>
> On 2014-1-10, at 16:36, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>> Maybe I am completely missing things, but this looks wrong.
>> If the MPLS LSP is carrying fixed rate pseudo-wires, adding conges= tion
>> control will make it more likely that the service won't work. = =A0Is that
>> really the goal?
>>
>> We do not perform congestion control on MPLS LSPs.
>> Assuming that a UDP tunnel is carrying just MPLS and was establish= ed
>> just for MPLS, why would we expect it to behave differently than a= n MPLS
>> LSP running over the exact same path, carrying the exact same traf= fic?
>
> we've been rehashing this discussion several times over the years,= e.g., for PWE, AMT, etc. In order to carry fixed-rate or otherwise non-con= gestion-controlled traffic over unprovisioned general Internet paths, there= needs to be some sort of basic congestion control mechanism, like a circui= t breaker.
>
> The whole point of running MPLS is to create networks in which paths a= re provisionable, so this is usually not an issue. But if you start stickin= g MPLS inside of UDP, those packets can go anywhere on the net, so you need= mechanisms to control the rate of that traffic if it causes congestion, or= at the very least you need to be able to stop the traffic if it creates se= vere congestion.
>
> Lars
_______________________= ________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--f46d043c7fc0b917d704efa361e2-- From scott.brim@gmail.com Fri Jan 10 12:42:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F361AE12A; Fri, 10 Jan 2014 12:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id febzYUiKQLhd; Fri, 10 Jan 2014 12:42:18 -0800 (PST) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E672D1AE124; Fri, 10 Jan 2014 12:42:17 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id l6so5579663oag.19 for ; Fri, 10 Jan 2014 12:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=moG0yemAQwwvJIWbwjt1o1ztST01ymzMWqGDB9RKYEQ=; b=hMx+Y11JeUSseArOuA3sP/D3RQ7P7fbrOtKAS7/yyIhP6UCutPragbQFvA7hF8XEnx 7fnoJG1/eKcJpktmEzvC2KmAkwPJV83Rusj+UGgceHqID1pKarMkMYaKcZaQTxS6+d5I utUjBmmm4jI8NGGHDtErI1RIfis8PXZf4IcfDnAs4RsGCKb8ukkaGhdQxdsz5VuwLQ9G H8fQ9wQuP/1ClIOZG0Eo42rbEaWadDrpMG/RgJEQMUyFA2vREwheZWK+EnQ+BPxXUmBB sbb7KVc7Kp2wh1CCSoktop1JQgP/PwCO0h9IE+JT+eDNW+SrveJ9X/St1LxoY5jRq/6J 72Gw== X-Received: by 10.60.136.196 with SMTP id qc4mr9638611oeb.41.1389386527805; Fri, 10 Jan 2014 12:42:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Fri, 10 Jan 2014 12:41:47 -0800 (PST) In-Reply-To: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> From: Scott Brim Date: Fri, 10 Jan 2014 15:41:47 -0500 Message-ID: To: Edward Crabbe Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 20:42:19 -0000 On Fri, Jan 10, 2014 at 3:14 PM, Edward Crabbe wrote: > +1 > > Let the encapsulated transport protocols take care of the congestion > end-to-end. Xu Xiaohu proposed a good paragraph: https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=75392&tid=1389386424 From jmh@joelhalpern.com Fri Jan 10 12:48:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3168A1AE116; Fri, 10 Jan 2014 12:48:03 -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 6SXdvSz7JJzX; Fri, 10 Jan 2014 12:48:01 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id D6B6A1AE0C6; Fri, 10 Jan 2014 12:48:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 35F061C0D2E; Fri, 10 Jan 2014 12:47:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 29102620DAE; Fri, 10 Jan 2014 12:47:51 -0800 (PST) Message-ID: <52D05C75.3050505@joelhalpern.com> Date: Fri, 10 Jan 2014 15:47:49 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Scott Brim , Edward Crabbe References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 20:48:03 -0000 The problem with taht paragraph is that it assumes that the UDP encapsulator knows what the payload is. It seems to me that one could easily be applying the UDP in any one of a number of cases where the payload will not be known. So the requirement in the paragraph seems at best difficult to meet. And has been noted, this seems to place an expectation on UDP encapsulated MPLS that is not present for MPLS itself, when the traffic is not known to be IP. Yours, Joel On 1/10/14 3:41 PM, Scott Brim wrote: > On Fri, Jan 10, 2014 at 3:14 PM, Edward Crabbe wrote: >> +1 >> >> Let the encapsulated transport protocols take care of the congestion >> end-to-end. > > Xu Xiaohu proposed a good paragraph: > https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=75392&tid=1389386424 > From scott.brim@gmail.com Fri Jan 10 13:32:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC371AE1E1; Fri, 10 Jan 2014 13:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYyHLZzaosdI; Fri, 10 Jan 2014 13:32:34 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 30AFD1AE1D3; Fri, 10 Jan 2014 13:32:33 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id vb8so5301438obc.8 for ; Fri, 10 Jan 2014 13:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FQc3/hCV61AVpz/i8uWVPiJiCv37btbVGsRN2qG2ZcM=; b=Ls7/51+a09ybWl1R3ILoQBG3lfy67av0R/vd/vT8kl67Eg2F/47+AllcbHs4QXF8xu xTuNb5ZUYDCjK8LPpWTBdOX4Lv+f17x8+hl5i9jVYWCKL9Xk3fweg0pZD+jISdMWxMf7 Nk9V6ZkobBk9mfhrfH/gzy1T04XIFbMvVQpa2KZb4RIYG/ONblZmVPAWrEiVZ7SPpxzd 1DuGF7+S8Zum6LzGQb6jS8/ClvV7wQVv49aFxPE06yoRwm/qZ4BYo5LDPOn10G4rSzWH 6Mc0cWuB9zojk3KsZLYjiQCl5TaaKeRGn23uz0pNAQwMGHiGptWyMC3uzkDjiwpPRTnq ZFNg== X-Received: by 10.60.174.167 with SMTP id bt7mr8891124oec.54.1389389543027; Fri, 10 Jan 2014 13:32:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Fri, 10 Jan 2014 13:32:02 -0800 (PST) In-Reply-To: <52D05C75.3050505@joelhalpern.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <52D05C75.3050505@joelhalpern.com> From: Scott Brim Date: Fri, 10 Jan 2014 16:32:02 -0500 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 21:32:36 -0000 On Fri, Jan 10, 2014 at 3:47 PM, Joel M. Halpern wrote: > The problem with taht paragraph is that it assumes that the UDP encapsulator > knows what the payload is. > It seems to me that one could easily be applying the UDP in any one of a > number of cases where the payload will not be known. > So the requirement in the paragraph seems at best difficult to meet. > > And has been noted, this seems to place an expectation on UDP encapsulated > MPLS that is not present for MPLS itself, when the traffic is not known to > be IP. OK good point - so we invoke the end-to-end argument on MPLS's behalf. From lars@netapp.com Fri Jan 10 22:23:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B120D1AE041; Fri, 10 Jan 2014 22:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 toHCxHOIb8YU; Fri, 10 Jan 2014 22:23:32 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1101AE035; Fri, 10 Jan 2014 22:23:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,642,1384329600"; d="asc'?scan'208";a="95450478" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 10 Jan 2014 22:23:21 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Fri, 10 Jan 2014 22:23:21 -0800 From: "Eggert, Lars" To: Scott Brim Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAAPhcAgAAHp4CAAAGvgIAADFsAgACUVIA= Date: Sat, 11 Jan 2014 06:23:20 +0000 Message-ID: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <52D05C75.3050505@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_F03B8410-331A-4839-BADD-9F7B10C21371"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 06:23:33 -0000 --Apple-Mail=_F03B8410-331A-4839-BADD-9F7B10C21371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 2014-1-10, at 22:32, Scott Brim wrote: > OK good point - so we invoke the end-to-end argument on MPLS's behalf. look at it the other way. =46rom the viewpoint of the rest of the net, = you are an application using UDP. Such applications need to follow a set = of principles we have IETF consensus on (RFC5405). By encapsulating MPLS in UDP, you are changing the game. That traffic = can now appear on any Internet path, and not just inside provisioned = networks. Because of that, you need a mechanism to detect if you are = causing congestion, and a mechanism to react to it. And it *is* a requirement on the encapsulator, because from the = perspective of the rest of the net, that is the application that = generates the UDP traffic. Lars --Apple-Mail=_F03B8410-331A-4839-BADD-9F7B10C21371 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----- iQCVAwUBUtDjP9ZcnpRveo1xAQJiQAP/Ytgorv2DhWWGHAudxHLokDsN5Na53mhY Xh6G1ABbKcf3KMHrEEv8XgmSmQb9+zeyQRx1YKvsWTeCabZB/y1e27Q98ziTPO3I nuQvjxKZMscJ/sohP0SizTy9710q81fTlfFJ2wWapKlafOCdYG588Q7LEkMaTvs5 PafkaLpsaDE= =tle/ -----END PGP SIGNATURE----- --Apple-Mail=_F03B8410-331A-4839-BADD-9F7B10C21371-- From l.wood@surrey.ac.uk Sat Jan 11 18:59:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550E71ACCF8; Sat, 11 Jan 2014 18:59:58 -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, 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 E7Cl-HXCPHrL; Sat, 11 Jan 2014 18:59:56 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0441AD8EB; Sat, 11 Jan 2014 18:59:54 -0800 (PST) Received: from [195.245.231.67:12094] by server-17.bemta-5.messagelabs.com id 91/A7-19152-F1502D25; Sun, 12 Jan 2014 02:59:43 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-13.tower-82.messagelabs.com!1389495582!35539380!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24692 invoked from network); 12 Jan 2014 02:59:42 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-13.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 12 Jan 2014 02:59:42 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Sun, 12 Jan 2014 02:59:42 +0000 From: To: , Date: Sun, 12 Jan 2014 02:59:41 +0000 Thread-Topic: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Thread-Index: AQLp3cWoqiSzZKGjmFXJEPC82F9z6gH14gYaAYJCBgICOkjTg5gY93XwgAQ4kWA= Message-ID: <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F1240847E63346B5@EXMB01CMS.surrey.ac.uk>, <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> In-Reply-To: <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, david.black@emc.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 02:59:58 -0000 On nested checksums, the question is how they are nested; it's a matter of scope. With a bunch of checksums checking only a payload and any inner checksums like Russian Matryoshka dolls, the end-to-end argument tells us that for reliable receipt of the payload, only the innermost check= sum matters. But here, we are not solely checking the payload, but information on how to deliver and identify that payload - and while an outer Ethernet CRC is acro= ss the last link, the UDP checksum, though weak, provides a check on the IP addresses and UDP ports (via the pseudoheader check) and MPLS stack from UDP/IP source to UDP/IP destination (and the payload, which is the bit everyone focuses on as the performance hit as redundant and a processing cost when the payload has its own check, and the bit that UDP-Lite can leav= e out). Nothing else checks that scope. The scope is wider, and affects the network as a whole. Errors in these unchecked fields lead to misdirection and lead = to misdelivery. Or pollution of other ports. The MPLS assumption is that it's protected and checked by a strong link CRC= like Ethernet, and checked/regenerated by stack processing between hops; here, in a path context, with zero UDP checksums MPLS has no checking at all. "consequences for cheap hardware and for software implementations" I'm sorry, when was MPLS cheap? Lloyd Wood http://about.me/lloydwood ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: 09 January 2014 10:21 To: Wood L Dr (Electronic Eng); randy@psg.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com= ; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org Subject: RE: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: R= E: [tsvwg] Milestones changed for tsvwg WG) Lloyd and Randy, With respect to draft-ietf-mpls-in-udp, this is why we have IETF last calls= , so thanks for the comments. We did take the precaution of sending this I-D for an early TSV Directorate review because of the concern about a number of factors and the overlap wit= h tsvwg work, but the review came back "clean". Of course, such a review is j= ust one person, so this conversation is good. Wrt zero checksum, where do you stand on nested checksums? There is some cl= aim that they represent a waste of processing. I am not convinced by that when = each layer is using dedicated hardware (that can presumably process checksums at= line speed), but I am interested in the consequences for cheap hardware and for software implementations (as have been claimed to be some of the motivation= s for this work). Other TSV-related issues that surely pop up are: - allocation of ports for foo-in-UDP - congestion control Please note that there are a number of I-Ds that you missed in your broad s= weep of "I am opposed". You should probably look at the NVGRE and VXLAN work (wh= ich I think is lurking around the NVO3 working group) because that is also lookin= g at UDP encaps of a tunnelling protocol. Thanks, Adrian Health warnings: I am responsible AD for draft-ietf-mpls-in-udp I am a co-author of the gre-in-udp draft. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.u= k > Sent: 09 January 2014 08:07 > To: randy@psg.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.c= om; > tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was:= RE: > [tsvwg] Milestones changed for tsvwg WG) > > Randy, > > okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get > consensus on it. And then the authors can adopt that consensus for mpls-in-udp, > which overlaps in authorship... > > thanks, > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Randy Bush [randy@psg.com] > Sent: 09 January 2014 07:51 > To: Wood L Dr (Electronic Eng) > Cc: david.black@emc.com; gorry@erg.abdn.ac.uk; ietf@ietf.org; mpls@ietf.o= rg; > jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org > Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [t= svwg] > Milestones changed for tsvwg WG) > > > Because they specify zero UDP checksums, > > I oppose publication of draft-ietf-mpls-in-udp in its current form > > I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its cur= rent > form. > > I oppose the IETF lisp documents. > > lloyd, > > i think i understand your position. but i disagree with preventing wg > adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly > see wg adoption as how we get to discuss and work on a document, not as > approval of the document. as david said, i think we need to discuss it > so we can decide if it should be fixed. to do so, we have to adopt it. > > randy > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Sun Jan 12 01:42:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE0C1ADEB7; Sun, 12 Jan 2014 01:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBD5QGBIMzi1; Sun, 12 Jan 2014 01:42:34 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A54A1AD8ED; Sun, 12 Jan 2014 01:42:31 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB530.eurprd03.prod.outlook.com (10.242.109.154) with Microsoft SMTP Server (TLS) id 15.0.851.11; Sun, 12 Jan 2014 09:42:14 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Sun, 12 Jan 2014 09:42:14 +0000 From: Alexander Vainshtein To: "Eggert, Lars" , Scott Brim Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPDi/Q1tWkYFyrTkep2zSq03bWq5p+JqQAgAA+GACAAAemgIAAAbCAgAAMWwCAAJRxAIABu3dQ Date: Sun, 12 Jan 2014 09:42:13 +0000 Message-ID: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <52D05C75.3050505@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(24454002)(252514010)(377454003)(51704005)(13464003)(377424004)(189002)(199002)(46102001)(74366001)(85852003)(47446002)(80022001)(65816001)(53806001)(79102001)(66066001)(33646001)(85306002)(87936001)(2656002)(54316002)(49866001)(51856001)(76482001)(31966008)(76796001)(87266001)(56776001)(54356001)(74316001)(63696002)(74662001)(69226001)(81342001)(81686001)(47976001)(74502001)(19580395003)(83072002)(80976001)(83322001)(19580405001)(74706001)(74876001)(81816001)(59766001)(50986001)(4396001)(47736001)(76576001)(77982001)(81542001)(76786001)(56816005)(92566001)(90146001)(15975445006)(93136001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB530; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:147.234.56.21; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 09:42:38 -0000 Lars, Scott and all, First, a piece of history. Congestion control considerations have been a major point of contention bet= ween the (then) leadership of the Transport Area and the PWE3 WG (that has = started in the Transport Area, then migrated to Internet Area and finally a= rrived to the Routing Area). A congestion control framework document is st= ill listed as one of the goals of this WG even if the target date has passe= d and the draft that was supposed to deal with the subject (https://datatra= cker.ietf.org/doc/draft-ietf-pwe3-congestion-frmwk) has expired almost 4 ye= ars ago. TDM PWs which, for historical reasons, have always included encapsulations = over UDP/IP, have been one of the focal points of this contention with DISC= USS by one of the then Transport Area directors in the process of the IESG = approval of the first of these documents. Eventually, this contention has b= een resolved by adding a dedicated Congestion Control section to RFC 4553. = This section introduced several guards against congestion being created by = excessive deployment of TDM PWs and provided specific guidelines for imple= menting a congestion prevention mechanism (specific to TDM PWs).=20 Going back to the draft in question... Encapsulating MPLS in UDP looks to me like a far-going extension of runnin= g TDM PWs over UDP/IP. The main differences, as I see them, are: - General MPLS-in-UDP flows can be "BW-greedy" while TDM PWs are not - Congestion detection for these flows by the encapsulation endpoints (pres= umably called "applications using MPLS/UDP encapsulation" in the ) is much = more problematic, nor is it clear to me, how backpressure between these en= dpoints can operate even if congestion were detected The text I have found in the Congestion Considerations section of the draft= recognizes potential for congestion created by MPLS/UDP flows, and even ca= lls for a mandatory additional congestion control mechanism. However, I cou= ld not find any guidelines (or even hints) that would help an implementer t= o create such a mechanism. So I'd say that with regard to congestion contr= ol this draft does not meet the standard that has been expected (years ago = from now) from the TDM PW drafts.=20 My 2c, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars > Sent: Saturday, January 11, 2014 8:23 AM > To: Scott Brim > Cc: mpls@ietf.org; IETF > Subject: Re: [mpls] Last Call: (Encapsula= ting > MPLS in UDP) to Proposed Standard >=20 > Hi, >=20 > On 2014-1-10, at 22:32, Scott Brim wrote: > > OK good point - so we invoke the end-to-end argument on MPLS's behalf. >=20 > look at it the other way. From the viewpoint of the rest of the net, you = are an > application using UDP. Such applications need to follow a set of principl= es we > have IETF consensus on (RFC5405). >=20 > By encapsulating MPLS in UDP, you are changing the game. That traffic can > now appear on any Internet path, and not just inside provisioned networks= . > Because of that, you need a mechanism to detect if you are causing > congestion, and a mechanism to react to it. >=20 > And it *is* a requirement on the encapsulator, because from the perspecti= ve > of the rest of the net, that is the application that generates the UDP tr= affic. >=20 > Lars From mark.tinka@seacom.mu Sun Jan 12 04:02:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAF41ADF23 for ; Sun, 12 Jan 2014 04:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 UDmsZImkZ27b for ; Sun, 12 Jan 2014 04:02:00 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5A61ADE84 for ; Sun, 12 Jan 2014 04:01:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2JjX-0007Cf-P8; Sun, 12 Jan 2014 14:01:39 +0200 From: Mark Tinka Organization: SEACOM To: adrian@olddog.co.uk Date: Sun, 12 Jan 2014 14:01:35 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> <201401091646.48102.mark.tinka@seacom.mu> <029901cf0d53$5beb7d00$13c27700$@olddog.co.uk> In-Reply-To: <029901cf0d53$5beb7d00$13c27700$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6815982.1QttyuDH4S"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401121401.39144.mark.tinka@seacom.mu> Cc: mpls@ietf.org, stephen.farrell@cs.tcd.ie Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 12:02:02 -0000 --nextPart6815982.1QttyuDH4S Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, January 09, 2014 05:56:24 PM Adrian Farrel=20 wrote: > I don't get this. > Only the end points of the encryption need to be aware of > it. It is only used when the end points agree to do it. > If one end point does not agree we have status quo. If > both end points agree then the transit points (if they > exist) don't participate. Thanks, Adrian. This clarifies, then. I just wanted to make sure that if one end supports=20 encryption (and independently encrypts the flow) while the=20 other end does not, we don't lose traffic. As you explain, both ends must agree to OE support before=20 anything can happen, and if they don't, existing forwarding=20 paradigms remain in place, which is fine by me. Mark. --nextPart6815982.1QttyuDH4S Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS0oQjAAoJEGcZuYTeKm+GTcUQAI/WEmnJlBmm1UUt44ZQZ8p4 CNkeFXwoNc0IVwpJDGwj95xN9sC+senoEtnah+gr+LvJ9CsgvPen2FRkGgS/u4UG OS6MbqazBSbZlLffj5kJkJBAa5XROdYqU984/T7SvtsUp+CxRbkAVwnXxgRu27Wg BQLK2/11Sir5S7JMdzATuK2TId1IJZ6sbYIzf8NuSa0Ly+ZzzV38nPBPkifq29e/ cW1Xm8aOtYbeGjBQA/YG6F08/cpyOv9gCWp5Z5fDQ+QqpVbKKCPY2qYfB4MJWwX5 FNvohgBl3PkpeNHE0QV/20B/x0vJ41wWhiv7c4lgTs9kEWhiT2jY/AH3858umNQ9 04DuIzxh0x9TbycOAITrOBtjSwVPAFCcffd0HnBX/rLtpiRlwfk47IwOLx/qi8L6 cclrbGx12A5hY6Fsdyp3cP94lvBU2QPAF7uvVd9EmYXwSIOG4J12FQWNj2h9trFF NMO0MYDcLPybEOzHGEVKj3x5nFDCGNNyoObXEeBHlTpolYXL0N1AnohJOvTuI95H mPu0uAM5Buw4qY6YSG+RQ5ay0hgTFj5RSlJR/iMlGmx/AZbVWu15pYE/ui+4nKYd JanMD7kHy5zpNW6Q1dwKHY1zTpUC20f0eQkFNPhhYOsHnVUt71p+E+Jgoc57qOfc TSdA3Eqe0A2XTZwHndrh =PRV7 -----END PGP SIGNATURE----- --nextPart6815982.1QttyuDH4S-- From mark.tinka@seacom.mu Sun Jan 12 04:06:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4891AE02A for ; Sun, 12 Jan 2014 04:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 4X6cn1f5W08e for ; Sun, 12 Jan 2014 04:06:35 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 95E4A1ADE84 for ; Sun, 12 Jan 2014 04:06:34 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2Jo4-0007E5-2Z; Sun, 12 Jan 2014 14:06:20 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org Date: Sun, 12 Jan 2014 14:06:19 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <23487.1389288863@erosen-linux> <52CEEB4F.2010609@cs.tcd.ie> In-Reply-To: <52CEEB4F.2010609@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3418644.7xQfiLWAjj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401121406.19381.mark.tinka@seacom.mu> Cc: Stephen Farrell Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 12:06:36 -0000 --nextPart3418644.7xQfiLWAjj Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, January 09, 2014 08:32:47 PM Stephen Farrell=20 wrote: > Are those widely used? I'd be interested to know. If not, > then this tool as another tool in the toolbox may be of > use. =46olk like Adva, Tejas and others have encryption at the=20 optical layer. I'm not sure how well this scales in service=20 provider deployments, but I know enterprises have been=20 lapping it up. The fastest data rates I've seen being encrypted at the=20 optical layer are 10Gbps. Mark. --nextPart3418644.7xQfiLWAjj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS0oU7AAoJEGcZuYTeKm+Gjw8P/1aR9aBvehub/0YUnjoqtkUB S870sZ5lhcK+zXyBAr5dlNvhbxc9HU6ltpte13Z7hQFRgUVUBvEu2dtMA3OT1e6t eaTtENdLmvQjsBbQYLrX2fqbUHM8xqTelJSrGkV0Z6WPKxXn1DOdlIE7nX3nNsBT vC7l2hup2+56vkVcOYhyNqngjOZ53+5JxCceIj7cM6uQmKJjFfS3OqO1u+kKHKdB QcaagyIRM2EGUcbCcX82REHVmeRjPPh/lfgQMQ5c6vf23CZc1Oeph1g8OYCp0bRe rFIGBuOcakWt/Ic+D+5BFL0XLwP3yrpCjI9TWRdqPMW/UuFAYtyjdcrQJ2sHwNNo b9m2cYTh3uyPh4BoR1lklI8Nc6KvXK2EFuW4z8NBUE05EUa2AKf186ZVbr//3iDc rq5KAOA1O5aVmz0BpcFnkxwoDo3Hevu70D5f8BoMyPzz7Ts3zt+V496eJ0hb1SHA rm7LkZVqCAv8MZT4Bd/4cwX7H5EOmsFXyXHufNqSIkd4HXzlt6f3eLl5d9Ua2Jj2 zfR7MPolA0rbk4ivbcrvLqJIFRgPj6P0bjlbljd+gYIHyMgSZtYSUw5yVESKqxIW gmFpRKKlQW3Nr4NZNt+4hulfKmRsyjZ5BJjW/WXBS1SgmCV3CYnClYeHBF91sQY4 RADrZDe6xwTwU5K9uxvU =C71q -----END PGP SIGNATURE----- --nextPart3418644.7xQfiLWAjj-- From mark.tinka@seacom.mu Sun Jan 12 04:15:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5408E1AE044 for ; Sun, 12 Jan 2014 04:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HOST_MISMATCH_COM=0.311] 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 HFdIYcvCdyku for ; Sun, 12 Jan 2014 04:15:09 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id BF45B1AE038 for ; Sun, 12 Jan 2014 04:15:08 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2JwP-0007KF-3P; Sun, 12 Jan 2014 14:14:57 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org, erosen@cisco.com Date: Sun, 12 Jan 2014 14:14:56 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <6925.1389369966@erosen-linux> In-Reply-To: <6925.1389369966@erosen-linux> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10531304.FC2U0uHNGl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401121414.56516.mark.tinka@seacom.mu> Cc: Stephen Farrell Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 12:15:10 -0000 --nextPart10531304.FC2U0uHNGl Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, January 10, 2014 06:06:06 PM Eric Rosen wrote: > I think encryption at the network layer is much more > complicated to do at scale than is encryption at the > data link layer. There's just a lot more to figure out > on a per-packet basis, and the system design becomes > more complex. This is one of my major concerns with this draft.=20 Implementation is likely to make the forwarding plane very=20 complex to the extent that if any vendor is brave enough to=20 support this, they will, in all likelihood, develop a=20 completely separate line card that employes this kind of=20 security, while building the generalized line cards in=20 parallel. Want to guess which one is more likely to be=20 affordable/sellable? Optical vendors are providing low-latency encryption at the=20 link layer, but I suspect that will not succeed much (in the=20 service provider market, anyway) because Ethernet speeds are=20 growing at a very fast rate; and it's hard enough to scale=20 that before one considers how adding security in the data=20 plane affects the same. Mark. --nextPart10531304.FC2U0uHNGl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS0odAAAoJEGcZuYTeKm+GHEAQAKVDCEPppLfspVsSuoi7hWXc Oj3B3G3H2GrC4cRNLNZvFbDrD+zN3bsGAVe//MPaG0Zq592MTEDwOjMaOjHi2xj1 +7ugPYrryoBm5pyxcO04KWOn0jOV4NdmIFrQtlZqH3TtzC1tqNaEKg8S98erjMoy ChuKyAjRUJD5EeZiLPGq0+ZHg5X78FgwPlYZD3gohrakl6sudWgPTt2RdYSYoPvt QTgl99wqy8nuVMijTPNvlwusO/Dd0cQm60XABwinNqFq1clxiAnt/oxIuw6MJe2V Twh6dJSQXD8BGNSytUAFUiU5aoI73wliGe05IqMTp9YRh0zPNwW6rwTPqaVQt87F sbOse89bwLNOBPw6WRKiiJkfSlNorzn6B09ag7MuQHiuZLdqvMJPSWqFYcgb9k23 rlEmuOM1WqsXrm202filrOHAaPSsl5VxmNGfxLEuYEPWSF05zD/AGyO2+5MzT/Gf U5M1uj5R6hhQJMm9TLG5T2+Hb/GgA8CXacgJlr3X3RX1aws7/B1rF5zA1HGVZSyM O9Q3KdNTCcY/eu3oYs2RU3+svtuCxAystRqu0srt8dXs/LY2vvbmK/QQCeJzUCHn H8IQdQdogVAFXrmUKkoAVQFmH6FVBIuo6OLANVQlBxDTZKk/iYzueSVTrBF2WKuN Egn41/WJya01/qDgPNis =MSck -----END PGP SIGNATURE----- --nextPart10531304.FC2U0uHNGl-- From mark.tinka@seacom.mu Sun Jan 12 04:18:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166281AE064; Sun, 12 Jan 2014 04:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 VMdSo1dvBmMt; Sun, 12 Jan 2014 04:18:36 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 689541AE063; Sun, 12 Jan 2014 04:18:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2JzY-0007Lo-9i; Sun, 12 Jan 2014 14:18:12 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org Date: Sun, 12 Jan 2014 14:18:11 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> In-Reply-To: <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1774670.NvQXsO8Ws6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401121418.11663.mark.tinka@seacom.mu> Cc: "Eggert, Lars" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 12:18:37 -0000 --nextPart1774670.NvQXsO8Ws6 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, January 10, 2014 06:09:45 PM Eggert, Lars wrote: > The whole point of running MPLS is to create networks in > which paths are provisionable, so this is usually not an > issue. But if you start sticking MPLS inside of UDP, > those packets can go anywhere on the net, so you need > mechanisms to control the rate of that traffic if it > causes congestion, or at the very least you need to be > able to stop the traffic if it creates severe > congestion. What most networks do is just police/shape traffic at=20 whatever rate you can afford to pay for, as it enters/leaves=20 the provider's network. As MPLS is in UDP, all the provider sees is IP, as they=20 should. I don't think there will be any "special treatment"=20 to UDP traffic carrying MPLS, vs. UDP traffic carrying other=20 payloads. Mark. --nextPart1774670.NvQXsO8Ws6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS0ogDAAoJEGcZuYTeKm+GNwUQAKqmgi/s/GOux2SsrGgl8dtx ByeO/hYWj/fdoEK/9df1sHScLJAKCuIRc4/fi5d3u55wCNsJz5MzRj1AFGi1R3qB 785Di7CpJp3bG07Dg8JsigD0zGuO/cNgHvxORzoxMmCWx4+pFwehnArVtK+PtF/T 6ltzFhadSABcWB1oTNcNjTD9/rNjJ1X0FJ9VLAyQ5Nox9GN531Nj5a4bpNVzh/NW 7g/XvQT507qft/JX5keNE/JGze860sqbD2fLo1p+OMiTkTBe6Ap9zsguGQ3bawD9 iICakUhtv22/oRC5HBGgPXYgvIkMZTFlzzhPTuu1By1KEguQWyHLwQMIIbo4/yKs t5+K58FN+dWISc2mfjTy9m4q2xqGfeBI8sc4m+SaUqSnKYX4SvEdqaOwIi1o/7x5 I2IVQCnZ84lDFNTkvoPoWQzIPpBL9+XVX3dAnIxl4uEGSOvf1UHtkC19Q1vmAGA1 dzx16M7VIPkkisZMrPnGLkg8ocMq7kNESxTlicqxlRDBA/QCp3pagMrnelO3bfis Uffvw+Al0gnmMarr7QeEvM2fFLbZ6jaQzM/6zTlAl3Q1LdUE/tp3L1sD+euME+Ue AhRO0TQnp6tJCAhprogG5mQwCZccc8DecBFMb6a9RqvLCvCXmHNr2gp3+JBmg2sw b3VNSBLcO00cC2as80jP =H7Wl -----END PGP SIGNATURE----- --nextPart1774670.NvQXsO8Ws6-- From mark.tinka@seacom.mu Sun Jan 12 04:26:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BAA1AE071; Sun, 12 Jan 2014 04:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_82=0.6] 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 K1oiHRm9zhHE; Sun, 12 Jan 2014 04:26:50 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0544D1AE06E; Sun, 12 Jan 2014 04:26:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2K7U-0007Rm-A2; Sun, 12 Jan 2014 14:26:24 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org Date: Sun, 12 Jan 2014 14:26:23 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2145601.e0txlHMqRJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401121426.23719.mark.tinka@seacom.mu> Cc: gorry@erg.abdn.ac.uk, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, ietf@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 12:26:51 -0000 --nextPart2145601.e0txlHMqRJ Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sunday, January 12, 2014 04:59:41 AM l.wood@surrey.ac.uk=20 wrote: > The MPLS assumption is that it's protected and checked by > a strong link CRC like Ethernet, and checked/regenerated > by stack processing between hops; here, in a path > context, with zero UDP checksums MPLS has no checking at > all. Right, which is probably why routers today can count badly=20 checksum'ed Ethernet frames, but don't have the equivalent=20 for MPLS. > I'm sorry, when was MPLS cheap? Current-generation ASIC's have no problem forwarding MPLS=20 frames at wire rate. One could go so far as to say that MPLS=20 has allowed vendors to make cheaper line cards also because=20 IP FIB's and traffic queues can be scaled down dramatically=20 (not that I'd every buy such line cards, but...). Mark. --nextPart2145601.e0txlHMqRJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS0onvAAoJEGcZuYTeKm+GO5YQAKFRVfaAIFXCOBY/gYZEQwQ4 iqdsoVfKH8J2qPY4ESdk/Z5CCABTXCQDSFSUicGPXZirZX0kQNF6aIOEbBhob6D9 dV8Hmg9Wn20xRMhhseBU1MSWld1W+TV00fxFGfkUUm34FP+ijm/qbyMaJxnugYqz QAtb7BDpI2PG3TiinXyWgmBrc3qKNEvSpkn/HIA9VWKlQmIoXEWXc+l6s9BzfC86 c2WrExvW2iEHfIwcJkcnX1hIQ9NVsVjzrj95XVYBb9oiyknhjrDGrsmBSyyvAgRB 6dTY/4o2hPK7gBr98srtaK+C35ak7aLvezj0PBfHbgQ2lF7Bk6fe3tN+ps4BKthg zsAn4+6qR+XOdZhzXx2kyaZe/PfFdFU/kKqVAQejn7BG4/etiWFm1pGSqSoVDMtc zqvN6tNyIYMNRSZGNZl6UZdX5ACG3Ta1T/WKTy/sO17SGES9gNxIZ8my7xH/FBeo Abxq3RVs6eAzgV05pDX92LBNvD94PxVbmQmKvWOWNl6VZpjV5h+mO4mKGdeR+p7G OVTQx1IR9zDYO5eJPz7v4n62P/BfIwzeVLlJBYFpmQNRvhtFLrn5R3u72WOahhZO JPZPAHqkLcfB/ScR3ulmt7zzUUr9zYUXsAzsINaGPDOekoVllVt5eNKOjKNw3Z45 IJ2hUIVy2S2BkNc2rk6+ =A+bb -----END PGP SIGNATURE----- --nextPart2145601.e0txlHMqRJ-- From mark.tinka@seacom.mu Sun Jan 12 04:44:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE571ADF64; Sun, 12 Jan 2014 04:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 xiiZZcop7tVB; Sun, 12 Jan 2014 04:44:49 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4162D1AD738; Sun, 12 Jan 2014 04:44:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2KP1-0007bN-Rc; Sun, 12 Jan 2014 14:44:31 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org Date: Sun, 12 Jan 2014 14:44:30 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <7347100B5761DC41A166AC17F22DF1121B7447E4@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7447E4@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1658773.OO1ujn9OSz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401121444.31194.mark.tinka@seacom.mu> Cc: "Eggert, Lars" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 12:44:50 -0000 --nextPart1658773.OO1ujn9OSz Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, January 10, 2014 08:24:02 PM Gregory Mirsky=20 wrote: > Hi Lars, > I think that " The whole point of running MPLS is to > create networks in which paths are provisionable, so > this is usually not an issue." is only partially > correct. LDP-based MPLS network is not provisionable and > LSPs follow IP best route selection. Explicit signaling > of LSP is achievable in (G)MPLS by using RSVP(-TE) > signaling. Greg, I think we can delineate provisioning from whether it=20 is dynamic or explicit. MPLS LSP's are all pre-provisioned, because of the FEC's=20 created. Whether those FEC's are dynamically or explicitly=20 provisioned is a separate issue. Mark. --nextPart1658773.OO1ujn9OSz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS0o4vAAoJEGcZuYTeKm+G4BIP/A3d2PbMI89e/C862l9Ivxbb nAMEK5/Hgw5hJOwa1DmunQyYY4rqzujhp5B6vWBj8NWcUKPC4g8J2pEV9alrAv6o w1VgNRUNlsZGdQUMX4BzT85qc12aZixMXyS/P1bxkygYBZDrqJa45NL248eYhk+B oKR2nWBK63+ou7H0YPe+tvSbOuMrlI71/cV9t9CHkGDAbfmE0kFcx5o8Eqbinnu7 2bF/fIvplS49JlJBKl7jmMHcn6k+2CSBDGXWZCcR8IaSTQiC0zYMHeSHHUfZxDXl i/5Y7/OqE6+B7CCTOgA7QHnW6/oDZosYoD42A6JKGUB3Unn+PHKGWFC6Da0Y4uMr PA4Av67abQibhxmTVk9Cc8K5VUBWC7mh/0I/H19HJcKOv9+WCMuXarxMr1EjaUPn 45mVcVj6YNQYosxbjgCyzOElGoGjE/I1thQDnOOy732coQjwyp6PziE8sqwTdR7Y 5XExETCYHxXZ/ee8VkVkNHoGCW3fvd3Xx+VwfJoOIRse9QAtbnHx1S39xg1NLeg4 cRN0lBXth7sjUzlj+428IAgnPU3dkl0ewhj05IjMwJ2s+0Dijxyy3isPh4UsmxzJ 18oqt+Qn1aWGp0XhpYZNjJO9ZcjeQnSs1h5tWkWS/UVSsFX+2BxQLSX2LUpFTvyh mA3BqKaZog9VXk+CYMBg =VqrV -----END PGP SIGNATURE----- --nextPart1658773.OO1ujn9OSz-- From curtis@ipv6.occnc.com Sun Jan 12 10:09:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209DE1ADF7D; Sun, 12 Jan 2014 10:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 kmWCUiK9SE2P; Sun, 12 Jan 2014 10:09:19 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 183821ADF7C; Sun, 12 Jan 2014 10:09:18 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0CI91Y1053969; Sun, 12 Jan 2014 13:09:01 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401121809.s0CI91Y1053969@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Sun, 12 Jan 2014 02:59:41 +0000." <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> Date: Sun, 12 Jan 2014 13:09:01 -0500 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 18:09:22 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > On nested checksums, the question is how they are nested; it's a matter > of scope. With a bunch of checksums checking only a payload and any > inner checksums like Russian Matryoshka dolls, the end-to-end argument > tells us that for reliable receipt of the payload, only the innermost checksum > matters. > > But here, we are not solely checking the payload, but information on how to > deliver and identify that payload - and while an outer Ethernet CRC is across > the last link, the UDP checksum, though weak, provides a check on the IP > addresses and UDP ports (via the pseudoheader check) and MPLS stack > from UDP/IP source to UDP/IP destination (and the payload, which is the bit > everyone focuses on as the performance hit as redundant and a processing > cost when the payload has its own check, and the bit that UDP-Lite can leave out). > > Nothing else checks that scope. The scope is wider, and affects the network > as a whole. Errors in these unchecked fields lead to misdirection and lead to > misdelivery. Or pollution of other ports. > > The MPLS assumption is that it's protected and checked by a strong link CRC like > Ethernet, and checked/regenerated by stack processing between hops; here, > in a path context, with zero UDP checksums MPLS has no checking at all. That UDP would be running over IP over Ethernet or POS or GFP or ... There is no layer-2 currently in use that does not have a robust FCS, generally a 32 FCS and therefore the MPLS assumption of checking at a lower layer is still valid. Curtis > "consequences for cheap hardware and for software implementations" > > I'm sorry, when was MPLS cheap? > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Adrian Farrel [adrian@olddog.co.uk] > Sent: 09 January 2014 10:21 > To: Wood L Dr (Electronic Eng); randy@psg.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: RE: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) > > Lloyd and Randy, > > With respect to draft-ietf-mpls-in-udp, this is why we have IETF last calls, so > thanks for the comments. > > We did take the precaution of sending this I-D for an early TSV Directorate > review because of the concern about a number of factors and the overlap with > tsvwg work, but the review came back "clean". Of course, such a review is just > one person, so this conversation is good. > > Wrt zero checksum, where do you stand on nested checksums? There is some claim > that they represent a waste of processing. I am not convinced by that when each > layer is using dedicated hardware (that can presumably process checksums at line > speed), but I am interested in the consequences for cheap hardware and for > software implementations (as have been claimed to be some of the motivations for > this work). > > Other TSV-related issues that surely pop up are: > - allocation of ports for foo-in-UDP > - congestion control > > Please note that there are a number of I-Ds that you missed in your broad sweep > of "I am opposed". You should probably look at the NVGRE and VXLAN work (which I > think is lurking around the NVO3 working group) because that is also looking at > UDP encaps of a tunnelling protocol. > > Thanks, > Adrian > > Health warnings: > I am responsible AD for draft-ietf-mpls-in-udp > I am a co-author of the gre-in-udp draft. > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk > > Sent: 09 January 2014 08:07 > > To: randy@psg.com > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; > > tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > > Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: > > [tsvwg] Milestones changed for tsvwg WG) > > > > Randy, > > > > okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get > > consensus on it. And then the authors can adopt that consensus for > mpls-in-udp, > > which overlaps in authorship... > > > > thanks, > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Randy Bush [randy@psg.com] > > Sent: 09 January 2014 07:51 > > To: Wood L Dr (Electronic Eng) > > Cc: david.black@emc.com; gorry@erg.abdn.ac.uk; ietf@ietf.org; mpls@ietf.org; > > jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org > > Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] > > Milestones changed for tsvwg WG) > > > > > Because they specify zero UDP checksums, > > > I oppose publication of draft-ietf-mpls-in-udp in its current form > > > I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its current > > form. > > > I oppose the IETF lisp documents. > > > > lloyd, > > > > i think i understand your position. but i disagree with preventing wg > > adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly > > see wg adoption as how we get to discuss and work on a document, not as > > approval of the document. as david said, i think we need to discuss it > > so we can decide if it should be fixed. to do so, we have to adopt it. > > > > randy From curtis@ipv6.occnc.com Sun Jan 12 10:37:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBCD1AE00C; Sun, 12 Jan 2014 10:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_82=0.6, RP_MATCHES_RCVD=-0.538, 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 pJnoHHCrCFIc; Sun, 12 Jan 2014 10:37:36 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id BB9AB1ADFE6; Sun, 12 Jan 2014 10:37:35 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0CIbGKE054334; Sun, 12 Jan 2014 13:37:16 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401121837.s0CIbGKE054334@maildrop2.v6ds.occnc.com> To: mark.tinka@seacom.mu From: Curtis Villamizar In-reply-to: Your message of "Sun, 12 Jan 2014 14:26:23 +0200." <201401121426.23719.mark.tinka@seacom.mu> Date: Sun, 12 Jan 2014 13:37:16 -0500 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: [mpls] OT was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 18:37:37 -0000 In message <201401121426.23719.mark.tinka@seacom.mu> Mark Tinka writes: > On Sunday, January 12, 2014 04:59:41 AM l.wood@surrey.ac.uk > wrote: > > > The MPLS assumption is that it's protected and checked by > > a strong link CRC like Ethernet, and checked/regenerated > > by stack processing between hops; here, in a path > > context, with zero UDP checksums MPLS has no checking at > > all. > > Right, which is probably why routers today can count badly > checksum'ed Ethernet frames, but don't have the equivalent > for MPLS. > > > I'm sorry, when was MPLS cheap? > > Current-generation ASIC's have no problem forwarding MPLS > frames at wire rate. One could go so far as to say that MPLS > has allowed vendors to make cheaper line cards also because > IP FIB's and traffic queues can be scaled down dramatically > (not that I'd every buy such line cards, but...). > > Mark. Perhaps if you actully worked for a company that made line cards you would not make the above statement. Many of the big router vendors use the same TCAM hardware for MPLS lookups as they do for IP lookups. Doing the lookup is not the rate limiting factor even in hardware that has an ILM SRAM table and some form of radix based lookup. All of the hardwre I've seen in the last 15 years or so forwards MPLS and IP at the same rate. ... Except IPv6 before they decided to waste the lower half of the address space with 40 quintilion host in a bridged subnet and you really did have to look at the whole 128 bits. Back when forwarding was done in software (circa 1995) your statement would have been true if MPLS preceeded forwarding ASICs which it did not. Also the statement "Current-generation ASIC's have no problem forwarding MPLS frames at wire rate" is not true for most (or all) hardware with 40 byte payloads (even with plus 4 with TCP SACK plus 4 if MPLS) and 100 Gb/s interfaces. It is true for "average packet size" traffic and on most hardware only true if bursts of 40 byte packets are very limited in duration. Curtis From mark.tinka@seacom.mu Sun Jan 12 11:05:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C2B1AE013; Sun, 12 Jan 2014 11:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 OQSton2cP-ZI; Sun, 12 Jan 2014 11:05:10 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id C693A1AE012; Sun, 12 Jan 2014 11:05:09 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2QKz-0000ia-1E; Sun, 12 Jan 2014 21:04:45 +0200 From: Mark Tinka Organization: SEACOM To: curtis@ipv6.occnc.com Date: Sun, 12 Jan 2014 21:04:40 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <201401121837.s0CIbGKE054334@maildrop2.v6ds.occnc.com> In-Reply-To: <201401121837.s0CIbGKE054334@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1564113.ZqtHiklPLi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401122104.44370.mark.tinka@seacom.mu> Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 19:05:13 -0000 --nextPart1564113.ZqtHiklPLi Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sunday, January 12, 2014 08:37:16 PM Curtis Villamizar=20 wrote: > Perhaps if you actully worked for a company that made > line cards you would not make the above statement. I work for an operator that pays real money to deploy and=20 use those line cards, and I make it my business to know what=20 I'm paying for. > Many of the big router vendors use the same TCAM hardware > for MPLS lookups as they do for IP lookups. Doing the > lookup is not the rate limiting factor even in hardware > that has an ILM SRAM table and some form of radix based > lookup. All of the hardwre I've seen in the last 15 > years or so forwards MPLS and IP at the same rate. Which was exactly my point - unless you somehow missed that. > ... > Except IPv6 before they decided to waste the lower half > of the address space with 40 quintilion host in a > bridged subnet and you really did have to look at the > whole 128 bits. It is no secret that forwarding of IPv6 packets on some=20 vendor equipment is about half the rate of IPv4 or MPLS. But=20 then again, because MPLS control planes are IPv4-driven=20 today, I'm hoping I didn't have to be explicit about not=20 including IPv6 in that group, on this list. > Back when forwarding was done in > software (circa 1995) your statement would have been > true if MPLS preceeded forwarding ASICs which it did > not. You might not know that line cards from C like the LSP=20 (Label Switch Processor) and much of the PFE from J's PTX=20 are forwarding engines that have been made cheaper by=20 reducing the IP FIB on the assumption that all traffic will=20 be carried in MPLS. This is, obviously, an assumption I do=20 not support because: - I run IPv6 natively, and at the moment, there are no production-grade IPv6 control planes for MPLS. - It assumes providers will run 6PE (in which case, IPv6 traffic enjoys MPLS and IPv6 wire rate forwarding speeds). I do not buy such line cards because for anyone running=20 native IPv6, you could potentially run out of FIB slots to=20 host IPv6 routes. That is why I say MPLS has allowed vendors to put out=20 cheaper line cards compared to the costs of those which have=20 large IPv4/IPv6 scale. Because MPLS forwarding is so=20 mainstream, there is no additional cost associated with=20 forwarding rates similar to IPv4. So much of the cost of=20 line cards is in QoS queues and routing FIB slots (and MPLS- biased line cards are stripped of that, hence making them=20 cheaper). > Also the statement "Current-generation ASIC's have no > problem forwarding MPLS frames at wire rate" is not true > for most (or all) hardware with 40 byte payloads (even > with plus 4 with TCP SACK plus 4 if MPLS) and 100 Gb/s > interfaces. It is true for "average packet size" > traffic and on most hardware only true if bursts of 40 > byte packets are very limited in duration. C'mon, Curtis. Everybody knows this already. Moreover, real=20 world IP traffic is not all 40 bytes. If operators have doubts about what forwarding engines can=20 do below 128 bytes, that is what PoC labs are for before you=20 buy. And even then, several operators accept the=20 restrictions up to a certain point, because the lab and real=20 life vary significantly. Mark. --nextPart1564113.ZqtHiklPLi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS0udMAAoJEGcZuYTeKm+GxhUQAKZAROVv7BygnH/5UIS6z5Zz 2NMk2GFbUL3p4hFWjOVwBSqhi6FVc6KRWpBynXlBTDJBaJIZfkD5HjBT7ZSr6m94 jYQLXeznNF1GnDMii8nA+n5kOQFahbOR21aKzm/GI/DUyH7dsqckHnZYy+K8m7cO ZmCPDuNV5BAba5Gsi7vFXFHak6z8dLqQWKzeUt7/im2HGCOphGQOhUXWuqqvgUFH lhh5H2JIntXJniCGsibbqBy5lTNviZ4qH2smXeFHjmPOyBzfRpBoYn82KJz6avry vunb+Ki1G0si+PPpbSv+rq8NE+i2RbH5/4cHjwPMhtNYYwu9LAEgZn2tLEialh56 TAui8DVpNZIJlH16IOn1gvIoEaridKeZsf4aT+0NwGr1jkc+P1AWEq6xse8o5Vqq XmnS/YmGLuCdknuzQzuIHzmmhdscDsw5LoCmd+Hel4tY3CvbcdGzMsaCWolADPke 69UX7tMuH8N8E499aiorT377kOn5yfOdSXEx8O4hRpPMoEbtQ4L1Q10XWrTJij3l 1tq7v0wy+TnZUGWzltMj+OWbCbfrwGx8j6KY3MjK29UkTtSswsR2s8WPHdoANlt+ oyk7v8XVbHt0/obgA3R1aPlrOHOx2U81LkBn4D+NlvAOeD5SbS7V+4l+NLgD6BZ0 6WmISwj1cO2CivbvsM38 =tmsD -----END PGP SIGNATURE----- --nextPart1564113.ZqtHiklPLi-- From l.wood@surrey.ac.uk Sun Jan 12 13:27:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242AF1ACC85; Sun, 12 Jan 2014 13:27:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ytbGuU5rCF86; Sun, 12 Jan 2014 13:27:04 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDA91A1DFA; Sun, 12 Jan 2014 13:27:03 -0800 (PST) Received: from [195.245.231.67:56026] by server-11.bemta-5.messagelabs.com id 75/AE-23268-B9803D25; Sun, 12 Jan 2014 21:26:51 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-9.tower-82.messagelabs.com!1389562011!29053243!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6226 invoked from network); 12 Jan 2014 21:26:51 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-9.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 12 Jan 2014 21:26:51 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sun, 12 Jan 2014 21:26:50 +0000 From: To: Date: Sun, 12 Jan 2014 21:22:58 +0000 Thread-Topic: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Thread-Index: Ac8PwWaHPFhUsU0dTLGXrrfKJuvBpAAGxCQx Message-ID: <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> References: Your message of "Sun, 12 Jan 2014 02:59:41 +0000." <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk>, <201401121809.s0CI91Y1053969@maildrop2.v6ds.occnc.com> In-Reply-To: <201401121809.s0CI91Y1053969@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 21:27:07 -0000 Curtis I suggest reading Stone's work, particularly ''When The CRC and TCP Checksum Disagree' for discussion of corruption. Particularly its conclusions: 'In the internet, that means we are sending large volumes of incorrect data without anyone noticing'. The Layer-2 check is per link, not end-to-end. That matters. The MPLS assumption is that it crosses a link with a frame checksum. Putting MPLS over UDP breaks that assumption. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 12 January 2014 18:09 To: Wood L Dr (Electronic Eng) Cc: adrian@olddog.co.uk; randy@psg.com; gorry@erg.abdn.ac.uk; mpls@ietf.org= ; lisp@ietf.org; ietf@ietf.org; david.black@emc.com; jnc@mit.edu; tsvwg@iet= f.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: R= E: [tsvwg] Milestones changed for tsvwg WG) In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > On nested checksums, the question is how they are nested; it's a matter > of scope. With a bunch of checksums checking only a payload and any > inner checksums like Russian Matryoshka dolls, the end-to-end argument > tells us that for reliable receipt of the payload, only the innermost che= cksum > matters. > > But here, we are not solely checking the payload, but information on how = to > deliver and identify that payload - and while an outer Ethernet CRC is ac= ross > the last link, the UDP checksum, though weak, provides a check on the IP > addresses and UDP ports (via the pseudoheader check) and MPLS stack > from UDP/IP source to UDP/IP destination (and the payload, which is the b= it > everyone focuses on as the performance hit as redundant and a processing > cost when the payload has its own check, and the bit that UDP-Lite can le= ave out). > > Nothing else checks that scope. The scope is wider, and affects the netwo= rk > as a whole. Errors in these unchecked fields lead to misdirection and lea= d to > misdelivery. Or pollution of other ports. > > The MPLS assumption is that it's protected and checked by a strong link C= RC like > Ethernet, and checked/regenerated by stack processing between hops; here, > in a path context, with zero UDP checksums MPLS has no checking at all. That UDP would be running over IP over Ethernet or POS or GFP or ... There is no layer-2 currently in use that does not have a robust FCS, generally a 32 FCS and therefore the MPLS assumption of checking at a lower layer is still valid. Curtis > "consequences for cheap hardware and for software implementations" > > I'm sorry, when was MPLS cheap? > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Adrian Farrel [adrian@olddog.co.uk] > Sent: 09 January 2014 10:21 > To: Wood L Dr (Electronic Eng); randy@psg.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.c= om; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: RE: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was:= RE: [tsvwg] Milestones changed for tsvwg WG) > > Lloyd and Randy, > > With respect to draft-ietf-mpls-in-udp, this is why we have IETF last cal= ls, so > thanks for the comments. > > We did take the precaution of sending this I-D for an early TSV Directora= te > review because of the concern about a number of factors and the overlap w= ith > tsvwg work, but the review came back "clean". Of course, such a review is= just > one person, so this conversation is good. > > Wrt zero checksum, where do you stand on nested checksums? There is some = claim > that they represent a waste of processing. I am not convinced by that whe= n each > layer is using dedicated hardware (that can presumably process checksums = at line > speed), but I am interested in the consequences for cheap hardware and fo= r > software implementations (as have been claimed to be some of the motivati= ons for > this work). > > Other TSV-related issues that surely pop up are: > - allocation of ports for foo-in-UDP > - congestion control > > Please note that there are a number of I-Ds that you missed in your broad= sweep > of "I am opposed". You should probably look at the NVGRE and VXLAN work (= which I > think is lurking around the NVO3 working group) because that is also look= ing at > UDP encaps of a tunnelling protocol. > > Thanks, > Adrian > > Health warnings: > I am responsible AD for draft-ietf-mpls-in-udp > I am a co-author of the gre-in-udp draft. > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of l.wood@surrey.ac= .uk > > Sent: 09 January 2014 08:07 > > To: randy@psg.com > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc= .com; > > tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > > Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (wa= s: RE: > > [tsvwg] Milestones changed for tsvwg WG) > > > > Randy, > > > > okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get > > consensus on it. And then the authors can adopt that consensus for > mpls-in-udp, > > which overlaps in authorship... > > > > thanks, > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Randy Bush [randy@psg.com] > > Sent: 09 January 2014 07:51 > > To: Wood L Dr (Electronic Eng) > > Cc: david.black@emc.com; gorry@erg.abdn.ac.uk; ietf@ietf.org; mpls@ietf= .org; > > jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org > > Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: = [tsvwg] > > Milestones changed for tsvwg WG) > > > > > Because they specify zero UDP checksums, > > > I oppose publication of draft-ietf-mpls-in-udp in its current form > > > I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its c= urrent > > form. > > > I oppose the IETF lisp documents. > > > > lloyd, > > > > i think i understand your position. but i disagree with preventing wg > > adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongl= y > > see wg adoption as how we get to discuss and work on a document, not as > > approval of the document. as david said, i think we need to discuss it > > so we can decide if it should be fixed. to do so, we have to adopt it. > > > > randy From l.wood@surrey.ac.uk Sun Jan 12 13:34:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5221ACC85; Sun, 12 Jan 2014 13:34:38 -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_82=0.6, 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 rVmWS-M1eOCv; Sun, 12 Jan 2014 13:34:37 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) by ietfa.amsl.com (Postfix) with ESMTP id 122891A1DFA; Sun, 12 Jan 2014 13:34:35 -0800 (PST) Received: from [85.158.137.99:24782] by server-16.bemta-3.messagelabs.com id DD/1B-26128-F5A03D25; Sun, 12 Jan 2014 21:34:23 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-10.tower-217.messagelabs.com!1389562463!21261411!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1644 invoked from network); 12 Jan 2014 21:34:23 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-10.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 12 Jan 2014 21:34:23 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Sun, 12 Jan 2014 21:34:23 +0000 From: To: , Date: Sun, 12 Jan 2014 21:32:28 +0000 Thread-Topic: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Thread-Index: Ac8PkY4DGIVCbttAQXqJ2uFOHpC4TAATD1BS Message-ID: <290E20B455C66743BE178C5C84F1240847E63346BE@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk>, <201401121426.23719.mark.tinka@seacom.mu> In-Reply-To: <201401121426.23719.mark.tinka@seacom.mu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, ietf@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 21:34:38 -0000 > Right, which is probably why routers today can count badly > checksum'ed Ethernet frames, but don't have the equivalent > for MPLS. If Ethernet frames keep failing the check, you know you have a local problem that needs fixing. That's why it's instrumented. Do any routers count TCP/UDP checksum failures, much less expose the count via SNMP? Lloyd Wood http://about.me/lloydwood ________________________________________ From: Mark Tinka [mark.tinka@seacom.mu] Sent: 12 January 2014 12:26 To: mpls@ietf.org Cc: Wood L Dr (Electronic Eng); adrian@olddog.co.uk; randy@psg.com; gorry@= erg.abdn.ac.uk; lisp@ietf.org; ietf@ietf.org; david.black@emc.com; jnc@mit.= edu; tsvwg@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: R= E: [tsvwg] Milestones changed for tsvwg WG) On Sunday, January 12, 2014 04:59:41 AM l.wood@surrey.ac.uk wrote: > The MPLS assumption is that it's protected and checked by > a strong link CRC like Ethernet, and checked/regenerated > by stack processing between hops; here, in a path > context, with zero UDP checksums MPLS has no checking at > all. Right, which is probably why routers today can count badly checksum'ed Ethernet frames, but don't have the equivalent for MPLS. > I'm sorry, when was MPLS cheap? Current-generation ASIC's have no problem forwarding MPLS frames at wire rate. One could go so far as to say that MPLS has allowed vendors to make cheaper line cards also because IP FIB's and traffic queues can be scaled down dramatically (not that I'd every buy such line cards, but...). Mark. From l.wood@surrey.ac.uk Sun Jan 12 16:48:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EEE1ACCD9; Sun, 12 Jan 2014 16:48: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, 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 zu0P8HFOgrYa; Sun, 12 Jan 2014 16:48:02 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id D3F281ACC91; Sun, 12 Jan 2014 16:48:01 -0800 (PST) Received: from [195.245.231.67:64589] by server-17.bemta-5.messagelabs.com id 32/F2-19152-6B733D25; Mon, 13 Jan 2014 00:47:50 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-9.tower-82.messagelabs.com!1389574069!29061545!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27567 invoked from network); 13 Jan 2014 00:47:49 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-9.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jan 2014 00:47:49 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Mon, 13 Jan 2014 00:47:48 +0000 From: To: Date: Mon, 13 Jan 2014 00:45:52 +0000 Thread-Topic: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Thread-Index: Ac8P3nEsYE8Z6DG8TdaYBKdC9S/GqwAGl7Nt Message-ID: <290E20B455C66743BE178C5C84F1240847E63346BF@EXMB01CMS.surrey.ac.uk> References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> <201401121426.23719.mark.tinka@seacom.mu> <290E20B455C66743BE178C5C84F1240847E63346BE@EXMB01CMS.surrey.ac.uk>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, gorry@erg.abdn.ac.uk, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 00:48:05 -0000 Really, you'd want to expose the pseudoheader check at endhosts; a well-ins= trumented Linux box could tell you a lot about checksum failures. But in this case, a router would be decapping UDP/MPLS tunnels as an endpoi= nt, so could report on checksum failures - if the checksum wasn't zero. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Dino Farinacci [farinacci@gmail.com] Sent: 12 January 2014 21:37 To: Wood L Dr (Electronic Eng) Cc: ; ; gorry@erg.abdn.ac.uk; lisp@iet= f.org; david.black@emc.com; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; iet= f@ietf.org Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft = (was: RE: [tsvwg] Milestones changed for tsvwg WG) > Do any routers count TCP/UDP checksum failures, much less > expose the count via SNMP? Typically they do but only for packets destined to them. Much like hosts wo= uld check the header checksum. Dino From gregory.mirsky@ericsson.com Sun Jan 12 17:30:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B4E1AC421 for ; Sun, 12 Jan 2014 17:30: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, 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 nL7abA56_F-x for ; Sun, 12 Jan 2014 17:30:18 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6EF1A1F55 for ; Sun, 12 Jan 2014 17:30:18 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-a7-52d3419a8168 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 80.C6.23183.A9143D25; Mon, 13 Jan 2014 02:30:03 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0347.000; Sun, 12 Jan 2014 20:30:05 -0500 From: Gregory Mirsky To: "mark.tinka@seacom.mu" , "mpls@ietf.org" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPDi/NnXFwG1Tc20SQPsVMzJPOgJp+RLFAgAMa0wCAAIA0EA== Date: Mon, 13 Jan 2014 01:30:04 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B744E67@eusaamb103.ericsson.se> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <7347100B5761DC41A166AC17F22DF1121B7447E4@eusaamb103.ericsson.se> <201401121444.31194.mark.tinka@seacom.mu> In-Reply-To: <201401121444.31194.mark.tinka@seacom.mu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPoO5sx8tBBh82c1t8PPWGyeLF6x4W i3trF7Nb3Fq6ktWBxWPJkp9MHuemfGf0mPHpC5tH57WJ7AEsUVw2Kak5mWWpRfp2CVwZF7q/ sRas56xYdvMkUwPjBfYuRk4OCQETieWHp7BB2GISF+6tB7K5OIQEjjBK/D+yjhUkISSwnFHi yGYDEJtNwEjixcYesGYRgRCJo0sOgTUzC3hIbG9fDGYLCxRKnJ71gRGipkjibU87G4TtJLGx 8xwLiM0ioCpxaMJasDm8Ar4SJy6sYIRY/IRR4v3b22AJTgEziV9rvoLZjEDXfT+1hglimbjE rSfzmSCuFpBYsuc8M4QtKvHy8T9WCFtZ4vucRywQ9ToSC3Z/gjpUW2LZwtfMEIsFJU7OfMIy gVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UYGmxiB8XRMgk13B+Oel5aHGKU5WJTEeb+8 dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLjcQuGnqanb6rjd2o+0ND90PLodmuHqJbM1 SNFGhet1+I0d7ZKtlu/mVPgwtahJPrAVPSKyZIuMRPgN9ReVLdYb9jhV7+x8nbNV0Hnzb1Uf 06Yi5R1HOiczx1r9/6JYuLhI1F+RM5S7TP2uX8mjnxsPPb6n4HCbw5wn6uP3Gium8FB+xp// lFiKMxINtZiLihMBCfdsOnUCAAA= Cc: "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 01:30:20 -0000 Hi Mark, if by "provisioning" you mean "mapped to", "assigned", then what about IP a= ddresses? Ain't they pre-provisioned as well? Or these are native propertie= s of NEs? Regards, Greg -----Original Message----- From: Mark Tinka [mailto:mark.tinka@seacom.mu]=20 Sent: Sunday, January 12, 2014 4:45 AM To: mpls@ietf.org Cc: Gregory Mirsky; Eggert, Lars; Joel Halpern; IETF Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard On Friday, January 10, 2014 08:24:02 PM Gregory Mirsky wrote: > Hi Lars, > I think that " The whole point of running MPLS is to create networks=20 > in which paths are provisionable, so this is usually not an issue." is=20 > only partially correct. LDP-based MPLS network is not provisionable=20 > and LSPs follow IP best route selection. Explicit signaling of LSP is=20 > achievable in (G)MPLS by using RSVP(-TE) signaling. Greg, I think we can delineate provisioning from whether it is dynamic or e= xplicit. MPLS LSP's are all pre-provisioned, because of the FEC's created. Whether t= hose FEC's are dynamically or explicitly provisioned is a separate issue. Mark. From xuxiaohu@huawei.com Sun Jan 12 18:13:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6D31ACCE8; Sun, 12 Jan 2014 18:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.55 X-Spam-Level: * X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 98qSy6Gt0ND8; Sun, 12 Jan 2014 18:12:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 227621A1F64; Sun, 12 Jan 2014 18:12:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZW40990; Mon, 13 Jan 2014 02:12:44 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 02:11:57 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 02:12:42 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 10:12:39 +0800 From: Xuxiaohu To: Gregory Mirsky , "Eggert, Lars" , Joel Halpern Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPDJU4xcLOVIDgI0yv/bpzgg7Unpp9UGqw///RhoCAAHJGgIAACUSAgAAlhQCABCkZ8A== Date: Mon, 13 Jan 2014 02:12:38 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824422A@NKGEML512-MBS.china.huawei.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <7347100B5761DC41A166AC17F22DF1121B7447E4@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7447E4@eusaamb103.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , IETF Subject: [mpls] =?gb2312?b?tPC4tDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxz?= =?gb2312?b?LWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0?= =?gb2312?b?byBQcm9wb3NlZCBTdGFuZGFyZA==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 02:13:01 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBscyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBHcmVnb3J5IE1pcnNreQ0KPiC3osvNyrG85DogMjAxNMTqMdTC MTHI1SAyOjI0DQo+IMrVvP7IyzogRWdnZXJ0LCBMYXJzOyBKb2VsIEhhbHBlcm4NCj4gs63LzTog bXBsc0BpZXRmLm9yZzsgSUVURg0KPiDW98ziOiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTDQo+IGluIFVEUCkg dG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+IEhpIExhcnMsDQo+IEkgdGhpbmsgdGhhdCAiIFRo ZSB3aG9sZSBwb2ludCBvZiBydW5uaW5nIE1QTFMgaXMgdG8gY3JlYXRlIG5ldHdvcmtzIGluIHdo aWNoDQo+IHBhdGhzIGFyZSBwcm92aXNpb25hYmxlLCBzbyB0aGlzIGlzIHVzdWFsbHkgbm90IGFu IGlzc3VlLiIgaXMgb25seSBwYXJ0aWFsbHkgY29ycmVjdC4NCj4gTERQLWJhc2VkIE1QTFMgbmV0 d29yayBpcyBub3QgcHJvdmlzaW9uYWJsZSBhbmQgTFNQcyBmb2xsb3cgSVAgYmVzdCByb3V0ZQ0K PiBzZWxlY3Rpb24uIEV4cGxpY2l0IHNpZ25hbGluZyBvZiBMU1AgaXMgYWNoaWV2YWJsZSBpbiAo RylNUExTIGJ5IHVzaW5nIFJTVlAoLVRFKQ0KPiBzaWduYWxpbmcuDQoNCisxLiBXaXRoIHRoZSBy ZXBsYWNlbWVudCBvZiBhIExEUC1iYXNlZCBMU1AgdHVubmVsIGJ5IGFuIElQLWJhc2VkIHR1bm5l bCAoZS5nLiwgTVBMUy1pbi1HUkUsIE1QTFMtaW4tSVAgb3IgTVBMUy1pbi1VRFApLCB0aGUgcGF0 aCB0aGF0IHRoZSB0cmFmZmljIHRyYXZlbHMgdGhyb3VnaCBpcyBub3QgY2hhbmdlZCBhdCBhbGwu DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IAlSZWdhcmRzLA0KPiAJCUdyZWcNCj4gDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMgW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFZ2dlcnQsIExhcnMNCj4gU2VudDogRnJpZGF5 LCBKYW51YXJ5IDEwLCAyMDE0IDg6MTAgQU0NCj4gVG86IEpvZWwgSGFscGVybg0KPiBDYzogbXBs c0BpZXRmLm9yZzsgSUVURg0KPiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZw0KPiBNUExTIGluIFVEUCkg dG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+IEhpLA0KPiANCj4gT24gMjAxNC0xLTEwLCBhdCAx NjozNiwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4gPiBN YXliZSBJIGFtIGNvbXBsZXRlbHkgbWlzc2luZyB0aGluZ3MsIGJ1dCB0aGlzIGxvb2tzIHdyb25n Lg0KPiA+IElmIHRoZSBNUExTIExTUCBpcyBjYXJyeWluZyBmaXhlZCByYXRlIHBzZXVkby13aXJl cywgYWRkaW5nIGNvbmdlc3Rpb24NCj4gPiBjb250cm9sIHdpbGwgbWFrZSBpdCBtb3JlIGxpa2Vs eSB0aGF0IHRoZSBzZXJ2aWNlIHdvbid0IHdvcmsuICBJcyB0aGF0DQo+ID4gcmVhbGx5IHRoZSBn b2FsPw0KPiA+DQo+ID4gV2UgZG8gbm90IHBlcmZvcm0gY29uZ2VzdGlvbiBjb250cm9sIG9uIE1Q TFMgTFNQcy4NCj4gPiBBc3N1bWluZyB0aGF0IGEgVURQIHR1bm5lbCBpcyBjYXJyeWluZyBqdXN0 IE1QTFMgYW5kIHdhcyBlc3RhYmxpc2hlZA0KPiA+IGp1c3QgZm9yIE1QTFMsIHdoeSB3b3VsZCB3 ZSBleHBlY3QgaXQgdG8gYmVoYXZlIGRpZmZlcmVudGx5IHRoYW4gYW4NCj4gPiBNUExTIExTUCBy dW5uaW5nIG92ZXIgdGhlIGV4YWN0IHNhbWUgcGF0aCwgY2FycnlpbmcgdGhlIGV4YWN0IHNhbWUg dHJhZmZpYz8NCj4gDQo+IHdlJ3ZlIGJlZW4gcmVoYXNoaW5nIHRoaXMgZGlzY3Vzc2lvbiBzZXZl cmFsIHRpbWVzIG92ZXIgdGhlIHllYXJzLCBlLmcuLCBmb3IgUFdFLA0KPiBBTVQsIGV0Yy4gSW4g b3JkZXIgdG8gY2FycnkgZml4ZWQtcmF0ZSBvciBvdGhlcndpc2Ugbm9uLWNvbmdlc3Rpb24tY29u dHJvbGxlZA0KPiB0cmFmZmljIG92ZXIgdW5wcm92aXNpb25lZCBnZW5lcmFsIEludGVybmV0IHBh dGhzLCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIHNvcnQgb2YNCj4gYmFzaWMgY29uZ2VzdGlvbiBj b250cm9sIG1lY2hhbmlzbSwgbGlrZSBhIGNpcmN1aXQgYnJlYWtlci4NCj4gDQo+IFRoZSB3aG9s ZSBwb2ludCBvZiBydW5uaW5nIE1QTFMgaXMgdG8gY3JlYXRlIG5ldHdvcmtzIGluIHdoaWNoIHBh dGhzIGFyZQ0KPiBwcm92aXNpb25hYmxlLCBzbyB0aGlzIGlzIHVzdWFsbHkgbm90IGFuIGlzc3Vl LiBCdXQgaWYgeW91IHN0YXJ0IHN0aWNraW5nIE1QTFMgaW5zaWRlDQo+IG9mIFVEUCwgdGhvc2Ug cGFja2V0cyBjYW4gZ28gYW55d2hlcmUgb24gdGhlIG5ldCwgc28geW91IG5lZWQgbWVjaGFuaXNt cyB0bw0KPiBjb250cm9sIHRoZSByYXRlIG9mIHRoYXQgdHJhZmZpYyBpZiBpdCBjYXVzZXMgY29u Z2VzdGlvbiwgb3IgYXQgdGhlIHZlcnkgbGVhc3QgeW91DQo+IG5lZWQgdG8gYmUgYWJsZSB0byBz dG9wIHRoZSB0cmFmZmljIGlmIGl0IGNyZWF0ZXMgc2V2ZXJlIGNvbmdlc3Rpb24uDQo+IA0KPiBM YXJzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From xuxiaohu@huawei.com Sun Jan 12 19:40:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1401AD8F9; Sun, 12 Jan 2014 19:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.55 X-Spam-Level: * X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 ov1hr5t2B58t; Sun, 12 Jan 2014 19:40:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CACC91AD6C1; Sun, 12 Jan 2014 19:40:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZW46192; Mon, 13 Jan 2014 03:40:27 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 03:39:48 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 03:40:24 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 11:40:18 +0800 From: Xuxiaohu To: Scott Brim , "Eggert, Lars" Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPDJU4xcLOVIDgI0yv/bpzgg7Unpp9UGqw///RhoCAAHJGgIAACUSAgAAGQwCABFBrUA== Date: Mon, 13 Jan 2014 03:40:17 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> 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.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , IETF Subject: [mpls] =?gb2312?b?tPC4tDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxz?= =?gb2312?b?LWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0?= =?gb2312?b?byBQcm9wb3NlZCBTdGFuZGFyZA==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 03:40:42 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogU2NvdHQgQnJpbSBbbWFpbHRvOnNj b3R0LmJyaW1AZ21haWwuY29tXQ0KPiC3osvNyrG85DogMjAxNMTqMdTCMTHI1SAwOjMyDQo+IMrV vP7IyzogRWdnZXJ0LCBMYXJzDQo+ILOty806IEpvZWwgSGFscGVybjsgbXBsc0BpZXRmLm9yZzsg WHV4aWFvaHU7IElFVEYNCj4g1vfM4jogUmU6IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1p bi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkNCj4gdG8gUHJvcG9zZWQg U3RhbmRhcmQNCj4gDQo+IEkgZG9uJ3QgdGhpbmsgaXQncyByaWdodCB0byB0cnkgdG8gc29sdmUg dGhpcyBpbiBNUExTLCBiZWNhdXNlIE1QTFMgaXMgbm90IGENCj4gZm9yd2FyZGluZyBwcm90b2Nv bCAtIGl0J3MgYSBjb25uZWN0aXZpdHkgcHJvdG9jb2wuIEluIGFueSB1c2Ugb2YgVURQLCBjb25n ZXN0aW9uDQo+IGNvbnRyb2wgaXMgZWl0aGVyIGxlZnQgdG8gc29tZXRoaW5nIGFib3ZlIFVEUCBv ciBpZ25vcmVkIChsZWZ0IHRvIHF1ZXVlDQo+IG1hbmFnZW1lbnQpLiBTaW1pbGFybHksIHlvdSB3 YW50IHRoZSBjbGllbnQgb2YgTVBMUyB0byBiZSByZXNwb25zaWJsZSBmb3INCj4gbWFuYWdpbmcg aXRzIHRyYWZmaWMuIE1QTFMgZ2l2ZXMgeW91IHBhdGhzLCBpdCBkb2Vzbid0IHB1c2ggcGFja2V0 cyBvdmVyIHRoZW0uDQoNCkZ1bGx5IGFncmVlLiBUaGUgY29uZ2VzdGlvbiBjb250cm9sIHNob3Vs ZCBiZSBwZXJmb3JtZWQgZWl0aGVyIGJ5IHRoZSBVRFAgdHVubmVsIGl0c2VsZiBvciB0aGUgY2xp ZW50IG9mIE1QTFMuIEluIHRoZSBmb3JtZXIgY2FzZSwgaXQnZCBiZXR0ZXIgdG8gc3BlY2lmeSB0 aGUgcHJhY3RpY2FsIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc21zIChpZiB0aGVyZSB3ZXJl IGFueSkgaW4gYSBnZW5lcmljIGRyYWZ0IChlLmcuLCBSRkM1NDA1YmlzKSBhbmQgdGhlbiBhbnkg dXNlIG9mIHRoZSBVRFAgdHVubmVsIGNvdWxkIHJlZmVyIHRvIHRoYXQgZ2VuZXJpYyBkcmFmdCB3 aXRoIHJlZ2FyZCB0byBjb25nZXN0aW9uIGNvbnRyb2wuIEluIHRoZSBsYXR0ZXIgY2FzZSwgaWYg dGhlIGNsaWVudCBvZiBNUExTIGlzIFRDUC1mcmllbmRseSwgdGhhdCBpcyBncmVhdC4gT3RoZXJ3 aXNlIChlLmcuLCBjaXJjdWl0IGVtdWxhdGlvbiBzZXJ2aWNlKSwgaXQgc2hvdWxkbid0IGJlIGRl cGxveWVkIG9uIHRoZSBJbnRlcm5ldCBhdCBhbGwsIGp1c3QgYXMgaGFzIGJlZW4gcG9pbnRlZCBv dXQgaW4gUkZDMzk4NSwgdGhlcmVmb3JlIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGFueSBzcGVjaWZp YyBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIG9uIHRoZSBjbGllbnQuDQogICANCiAgIi4u LiBJbiBlc3NlbmNlLCB0aGlzIHJlcXVpcmVtZW50IHN0YXRlcyB0aGF0IGl0IGlzDQogICBub3Qg YWNjZXB0YWJsZSB0byBkZXBsb3kgYW4gYXBwbGljYXRpb24gKHVzaW5nIFBXRTMgb3IgYW55IG90 aGVyDQogICB0cmFuc3BvcnQgcHJvdG9jb2wpIG9uIHRoZSBiZXN0LWVmZm9ydCBJbnRlcm5ldCwg d2hpY2ggY29uc3VtZXMNCiAgIGJhbmR3aWR0aCBhcmJpdHJhcmlseSBhbmQgZG9lcyBub3QgY29t cGV0ZSBmYWlybHkgd2l0aCBUQ1Agd2l0aGluIGFuDQogICBvcmRlciBvZiBtYWduaXR1ZGUuIiAo cXVvdGVkIGZyb20gU2VjdGlvbiA2LjUgb2YgUkZDMzk4NSkNCg0KVGhlIGFib3ZlIGNob2ljZSBz ZWVtcyBubyBjb25mbGljdCB3aXRoIHRoZSBmb2xsb3dpbmcgY29uZ2VzdGlvbiBjb250cm9sIGd1 aWRlbGluZXMgYXMgcXVvdGVkIGZyb20gU2VjdGlvbiAzLjEuMSBvZiBSRkM1NDA1LCBhcyB0aG9z ZSBub24tVENQLWZyaWVuZGx5IHRyYWZmaWMgd291bGQgYmUgdHJhbnNwb3J0ZWQgb3ZlciBhIHBy b3Zpc2lvbmVkIHBhdGgsIHJhdGhlciB0aGFuIG9uIHRoZSBJbnRlcm5ldC4NCg0KICAgIi4uLkZp bmFsbHksIHNvbWUgYnVsayB0cmFuc2ZlciBhcHBsaWNhdGlvbnMgbWF5IGNob29zZSBub3QgdG8g aW1wbGVtZW50DQogICBhbnkgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSBhbmQgaW5zdGVh ZCByZWx5IG9uIHRyYW5zbWl0dGluZw0KICAgYWNyb3NzIHJlc2VydmVkIHBhdGggY2FwYWNpdHku ICBUaGlzIG1pZ2h0IGJlIGFuIGFjY2VwdGFibGUgY2hvaWNlDQogICBmb3IgYSBzdWJzZXQgb2Yg cmVzdHJpY3RlZCBuZXR3b3JraW5nIGVudmlyb25tZW50cywgYnV0IGlzIGJ5IG5vDQogICBtZWFu cyBhIHNhZmUgcHJhY3RpY2UgZm9yIG9wZXJhdGlvbiBpbiB0aGUgSW50ZXJuZXQuIg0KDQpCZXN0 IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBTY290dA0KPiANCj4gDQo+IE9uIEZyaSwgSmFuIDEwLCAy MDE0IGF0IDExOjA5IEFNLCBFZ2dlcnQsIExhcnMgPGxhcnNAbmV0YXBwLmNvbT4gd3JvdGU6DQo+ ID4gSGksDQo+ID4NCj4gPiBPbiAyMDE0LTEtMTAsIGF0IDE2OjM2LCBKb2VsIE0uIEhhbHBlcm4g PGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPiA+PiBNYXliZSBJIGFtIGNvbXBsZXRlbHkg bWlzc2luZyB0aGluZ3MsIGJ1dCB0aGlzIGxvb2tzIHdyb25nLg0KPiA+PiBJZiB0aGUgTVBMUyBM U1AgaXMgY2FycnlpbmcgZml4ZWQgcmF0ZSBwc2V1ZG8td2lyZXMsIGFkZGluZw0KPiA+PiBjb25n ZXN0aW9uIGNvbnRyb2wgd2lsbCBtYWtlIGl0IG1vcmUgbGlrZWx5IHRoYXQgdGhlIHNlcnZpY2Ug d29uJ3QNCj4gPj4gd29yay4gIElzIHRoYXQgcmVhbGx5IHRoZSBnb2FsPw0KPiA+Pg0KPiA+PiBX ZSBkbyBub3QgcGVyZm9ybSBjb25nZXN0aW9uIGNvbnRyb2wgb24gTVBMUyBMU1BzLg0KPiA+PiBB c3N1bWluZyB0aGF0IGEgVURQIHR1bm5lbCBpcyBjYXJyeWluZyBqdXN0IE1QTFMgYW5kIHdhcyBl c3RhYmxpc2hlZA0KPiA+PiBqdXN0IGZvciBNUExTLCB3aHkgd291bGQgd2UgZXhwZWN0IGl0IHRv IGJlaGF2ZSBkaWZmZXJlbnRseSB0aGFuIGFuDQo+ID4+IE1QTFMgTFNQIHJ1bm5pbmcgb3ZlciB0 aGUgZXhhY3Qgc2FtZSBwYXRoLCBjYXJyeWluZyB0aGUgZXhhY3Qgc2FtZSB0cmFmZmljPw0KPiA+ DQo+ID4gd2UndmUgYmVlbiByZWhhc2hpbmcgdGhpcyBkaXNjdXNzaW9uIHNldmVyYWwgdGltZXMg b3ZlciB0aGUgeWVhcnMsIGUuZy4sIGZvcg0KPiBQV0UsIEFNVCwgZXRjLiBJbiBvcmRlciB0byBj YXJyeSBmaXhlZC1yYXRlIG9yIG90aGVyd2lzZQ0KPiBub24tY29uZ2VzdGlvbi1jb250cm9sbGVk IHRyYWZmaWMgb3ZlciB1bnByb3Zpc2lvbmVkIGdlbmVyYWwgSW50ZXJuZXQgcGF0aHMsDQo+IHRo ZXJlIG5lZWRzIHRvIGJlIHNvbWUgc29ydCBvZiBiYXNpYyBjb25nZXN0aW9uIGNvbnRyb2wgbWVj aGFuaXNtLCBsaWtlIGENCj4gY2lyY3VpdCBicmVha2VyLg0KPiA+DQo+ID4gVGhlIHdob2xlIHBv aW50IG9mIHJ1bm5pbmcgTVBMUyBpcyB0byBjcmVhdGUgbmV0d29ya3MgaW4gd2hpY2ggcGF0aHMg YXJlDQo+IHByb3Zpc2lvbmFibGUsIHNvIHRoaXMgaXMgdXN1YWxseSBub3QgYW4gaXNzdWUuIEJ1 dCBpZiB5b3Ugc3RhcnQgc3RpY2tpbmcgTVBMUyBpbnNpZGUNCj4gb2YgVURQLCB0aG9zZSBwYWNr ZXRzIGNhbiBnbyBhbnl3aGVyZSBvbiB0aGUgbmV0LCBzbyB5b3UgbmVlZCBtZWNoYW5pc21zIHRv DQo+IGNvbnRyb2wgdGhlIHJhdGUgb2YgdGhhdCB0cmFmZmljIGlmIGl0IGNhdXNlcyBjb25nZXN0 aW9uLCBvciBhdCB0aGUgdmVyeSBsZWFzdCB5b3UNCj4gbmVlZCB0byBiZSBhYmxlIHRvIHN0b3Ag dGhlIHRyYWZmaWMgaWYgaXQgY3JlYXRlcyBzZXZlcmUgY29uZ2VzdGlvbi4NCj4gPg0KPiA+IExh cnMNCg== From mark.tinka@seacom.mu Sun Jan 12 21:14:15 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DA01AD190 for ; Sun, 12 Jan 2014 21:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 GA65PUGtIDjb for ; Sun, 12 Jan 2014 21:14:13 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCBB1A1F7D for ; Sun, 12 Jan 2014 21:14:12 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2Zpr-0002Y9-I9; Mon, 13 Jan 2014 07:13:15 +0200 From: Mark Tinka Organization: SEACOM To: Gregory Mirsky Date: Mon, 13 Jan 2014 07:13:09 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <201401121444.31194.mark.tinka@seacom.mu> <7347100B5761DC41A166AC17F22DF1121B744E67@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B744E67@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2508335.VgM72WgTO5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401130713.13126.mark.tinka@seacom.mu> Cc: "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 05:14:15 -0000 --nextPart2508335.VgM72WgTO5 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Monday, January 13, 2014 03:30:04 AM Gregory Mirsky=20 wrote: > Hi Mark, > if by "provisioning" you mean "mapped to", "assigned", > then what about IP addresses? Ain't they pre-provisioned > as well? Or these are native properties of NEs? The path that two successive IP packets take to get from=20 point A to B, in an MPLS-free network, can be arbitrary. =46EC's are constant for a group of IP destinations mapped to=20 them. Mark. --nextPart2508335.VgM72WgTO5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS03XpAAoJEGcZuYTeKm+GZYkP/RqYGtlKi269oMgQHgEsoJBF BKBUCdiL7cvpqxGfsnDbffS5ShCovdGGRQEksMlyp/U9x/p42YPKNRkR25dy5FCi p0n8rBNLW38hfXVuG3Z/xPkvyt+DTzGoNDQVPDu8iiLCCGxl4zqn/PHHJg0cR+mH AzeF7FqU8tZdgyblkWT8Td3FZhjmqhNFrkj69VdzzOv9k6HTEhR2BDoCp1tAP5DM MpQcDBk/IFWqTo/fLwYOmk7zSkpLzgWiXoRpqWPNh+WTKw5FutUGR0S7ERUMNeIS YlYeEMq2Cj92iLRvqiRKC1ibvwj82xt3W92Gy5tZ47t7wBFVsMgyEyLfmuygDnMB q7eIILCpSlvc1GSGKqBJaZZw5Y3n9u413saOI1wcqmIly2ancZnKIQBzJZKVpO9i e+IMc4MjaLMS1skLCOANz91Gw2fv1yzEtGKL8x7b204f7EQhFLPMd/Mge2tTItjb Y7wWfKtImqZyFpYUF/ul7g6ZsbjdCjivRmXEsbreN/RCaWKTke0tSHauu+Rgv6MW cdrEndK+hdHb01AnrQCP3dY+6K7gzKwt1RwmMEci1sU3MNj1Ko0h8G0BmoXf1gr9 3uchbpyItI2xVav5DVivY57HHmR1UMD9Z5LbAT2hXoDP4vdXLbH+uiXA5r6mgWIL lswyfd9borX6bu6Cvnht =lCn4 -----END PGP SIGNATURE----- --nextPart2508335.VgM72WgTO5-- From lars@netapp.com Mon Jan 13 00:50:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF951ADF7A; Mon, 13 Jan 2014 00:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 aGMaXgZLYPmw; Mon, 13 Jan 2014 00:50:18 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id F35CE1AE070; Mon, 13 Jan 2014 00:50:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,651,1384329600"; d="asc'?scan'208";a="95683981" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 13 Jan 2014 00:50:07 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 00:50:07 -0800 From: "Eggert, Lars" To: Xuxiaohu Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAD31WAgABWjoA= Date: Mon, 13 Jan 2014 08:50:06 +0000 Message-ID: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , Scott Brim , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 08:50:20 -0000 --Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi, On 2014-1-13, at 4:40, Xuxiaohu wrote: >> I don't think it's right to try to solve this in MPLS, because MPLS = is not a >> forwarding protocol - it's a connectivity protocol. right, MPLS is the wrong place to address is. The UDP encaps/decaps = function needs to have this functionality. >> In any use of UDP, congestion >> control is either left to something above UDP or ignored (left to = queue >> management). There are several cases, see Section 3.1.3 of RFC5405. MPLS-over-UDP can = fall into any of the three cases, depending on what traffic is inside = the LSP being encapsulated.=20 You'll notice that RFC5405 for the first case - encapsulation of = IP-based congestion controlled "normal" Internet traffic - even says = that the tunnel SHOULD NOT employ any congestion control scheme of its = own. Having layered control loops fighting is not productive. The issue with MPLS-in-UDP (and GRE-in-UDP, and any other encaps scheme = that can carry non-IP traffic) are with cases two and three. When the = workload that is being encapsulated isn't known to be congestion = controlled by its endpoints, it is the obligation of the tunnel to = detect congestion and react to it by reducing the traffic volume. = Because for the rest of the network, that tunnel is the UDP sender, and = we have IETF consensus that we don't want UDP senders that don't react = to congestion on the net. (That's one of the main reasons for the = existence of the RMCAT WG - we don't want non-congestion-controlled RTP = media traffic on the net.) The key difference between putting MPLS e.g. into IP compared to putting = it into UDP is that once it's in UDP, it can go pretty much anywhere on = the net, because UDP traverses NATs and firewalls much more easily than = IP traffic with a rare protocol number does. >> Similarly, you want the client of MPLS to be responsible for >> managing its traffic. MPLS gives you paths, it doesn't push packets = over them. Right. However, once you slap a UDP header on a packet during = encapsulation, you now subjected yourself to the rules for Internet UDP = senders. Those are documented in RFC5405, and require the tunnel to = implement some sort of congestion detection and control. I'd personally = consider a circuit breaker mechanism sufficient, like RTP and I think = PWE are using. > Fully agree. The congestion control should be performed either by the = UDP tunnel itself or the client of MPLS. In the former case, it'd better = to specify the practical congestion control mechanisms (if there were = any) in a generic draft (e.g., RFC5405bis) and then any use of the UDP = tunnel could refer to that generic draft with regard to congestion = control. The general concept of a circuit breaker is easy enough that it doesn't = really need to be written down. And it wouldn't be possible to describe = it in a generic fashion, because congestion detection is typically = specific to the protocol being encapsulated (e.g., RTP uses RTCP = feedback to derive loss information, etc.) And the reaction to = congestion is also dependent on the protocol being encapsulated (does it = support multiple rates or only on/off, what timescales are OK for = reaction, etc.) > In the latter case, if the client of MPLS is TCP-friendly, that is = great. Otherwise (e.g., circuit emulation service), it shouldn't be = deployed on the Internet at all, just as has been pointed out in = RFC3985, therefore there is no need for any specific congestion control = mechanism on the client. >=20 > "... In essence, this requirement states that it is > not acceptable to deploy an application (using PWE3 or any other > transport protocol) on the best-effort Internet, which consumes > bandwidth arbitrarily and does not compete fairly with TCP within an > order of magnitude." (quoted from Section 6.5 of RFC3985) >=20 > The above choice seems no conflict with the following congestion = control guidelines as quoted from Section 3.1.1 of RFC5405, as those = non-TCP-friendly traffic would be transported over a provisioned path, = rather than on the Internet. >=20 > "...Finally, some bulk transfer applications may choose not to = implement > any congestion control mechanism and instead rely on transmitting > across reserved path capacity. This might be an acceptable choice > for a subset of restricted networking environments, but is by no > means a safe practice for operation in the Internet." How is that in conflict? Both quotes say that Internet traffic needs = congestion control, which is a restatement of RFC2914. Lars --Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D 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----- iQCVAwUBUtOovdZcnpRveo1xAQICtAP+IEcc32eXYdPz7se0PX+ytfYOjHW1ExJt bF/Wc+1umMc/GXbLL9tf8fKJdSpe/+ZUhuL6WpYG9BoptbI0uCsWCCH98/WP7BUI Bzf3SgJE1Qxpv+HNXTtYV1OuKJuYxp4p6Lgujkz1aGtiT1VfpBjX7a5e2D290dCp Kwtms72DUPw= =PeLB -----END PGP SIGNATURE----- --Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D-- From xuxiaohu@huawei.com Mon Jan 13 01:16:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A081AE0AF; Mon, 13 Jan 2014 01:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.55 X-Spam-Level: * X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 gA-8fgQphADM; Mon, 13 Jan 2014 01:16:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84F471ADF81; Mon, 13 Jan 2014 01:16:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCK96578; Mon, 13 Jan 2014 09:16:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 09:15:48 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 09:16:34 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 17:16:30 +0800 From: Xuxiaohu To: "Eggert, Lars" Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPDJU4xcLOVIDgI0yv/bpzgg7Unpp9UGqw///RhoCAAHJGgIAACUSAgAAGQwCABFBrUP//5XoAgACK6gA= Date: Mon, 13 Jan 2014 09:16:30 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082443DD@NKGEML512-MBS.china.huawei.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> 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.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , Scott Brim , IETF Subject: [mpls] =?gb2312?b?tPC4tDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxz?= =?gb2312?b?LWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0?= =?gb2312?b?byBQcm9wb3NlZCBTdGFuZGFyZA==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 09:16:56 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogRWdnZXJ0LCBMYXJzIFttYWlsdG86 bGFyc0BuZXRhcHAuY29tXQ0KPiC3osvNyrG85DogMjAxNMTqMdTCMTPI1SAxNjo1MA0KPiDK1bz+ yMs6IFh1eGlhb2h1DQo+ILOty806IFNjb3R0IEJyaW07IEpvZWwgSGFscGVybjsgbXBsc0BpZXRm Lm9yZzsgSUVURg0KPiDW98ziOiBSZTogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVk cC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKQ0KPiB0byBQcm9wb3NlZCBTdGFu ZGFyZA0KPiANCj4gSGksDQo+IA0KPiBPbiAyMDE0LTEtMTMsIGF0IDQ6NDAsIFh1eGlhb2h1IDx4 dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPj4gSSBkb24ndCB0aGluayBpdCdzIHJpZ2h0 IHRvIHRyeSB0byBzb2x2ZSB0aGlzIGluIE1QTFMsIGJlY2F1c2UgTVBMUw0KPiA+PiBpcyBub3Qg YSBmb3J3YXJkaW5nIHByb3RvY29sIC0gaXQncyBhIGNvbm5lY3Rpdml0eSBwcm90b2NvbC4NCj4g DQo+IHJpZ2h0LCBNUExTIGlzIHRoZSB3cm9uZyBwbGFjZSB0byBhZGRyZXNzIGlzLiBUaGUgVURQ IGVuY2Fwcy9kZWNhcHMgZnVuY3Rpb24NCj4gbmVlZHMgdG8gaGF2ZSB0aGlzIGZ1bmN0aW9uYWxp dHkuDQo+IA0KPiA+PiBJbiBhbnkgdXNlIG9mIFVEUCwgY29uZ2VzdGlvbg0KPiA+PiBjb250cm9s IGlzIGVpdGhlciBsZWZ0IHRvIHNvbWV0aGluZyBhYm92ZSBVRFAgb3IgaWdub3JlZCAobGVmdCB0 bw0KPiA+PiBxdWV1ZSBtYW5hZ2VtZW50KS4NCj4gDQo+IFRoZXJlIGFyZSBzZXZlcmFsIGNhc2Vz LCBzZWUgU2VjdGlvbiAzLjEuMyBvZiBSRkM1NDA1LiBNUExTLW92ZXItVURQIGNhbiBmYWxsDQo+ IGludG8gYW55IG9mIHRoZSB0aHJlZSBjYXNlcywgZGVwZW5kaW5nIG9uIHdoYXQgdHJhZmZpYyBp cyBpbnNpZGUgdGhlIExTUCBiZWluZw0KPiBlbmNhcHN1bGF0ZWQuDQo+IA0KPiBZb3UnbGwgbm90 aWNlIHRoYXQgUkZDNTQwNSBmb3IgdGhlIGZpcnN0IGNhc2UgLSBlbmNhcHN1bGF0aW9uIG9mIElQ LWJhc2VkDQo+IGNvbmdlc3Rpb24gY29udHJvbGxlZCAibm9ybWFsIiBJbnRlcm5ldCB0cmFmZmlj IC0gZXZlbiBzYXlzIHRoYXQgdGhlIHR1bm5lbA0KPiBTSE9VTEQgTk9UIGVtcGxveSBhbnkgY29u Z2VzdGlvbiBjb250cm9sIHNjaGVtZSBvZiBpdHMgb3duLiBIYXZpbmcgbGF5ZXJlZA0KPiBjb250 cm9sIGxvb3BzIGZpZ2h0aW5nIGlzIG5vdCBwcm9kdWN0aXZlLg0KPiANCj4gVGhlIGlzc3VlIHdp dGggTVBMUy1pbi1VRFAgKGFuZCBHUkUtaW4tVURQLCBhbmQgYW55IG90aGVyIGVuY2FwcyBzY2hl bWUNCj4gdGhhdCBjYW4gY2Fycnkgbm9uLUlQIHRyYWZmaWMpIGFyZSB3aXRoIGNhc2VzIHR3byBh bmQgdGhyZWUuIFdoZW4gdGhlIHdvcmtsb2FkDQo+IHRoYXQgaXMgYmVpbmcgZW5jYXBzdWxhdGVk IGlzbid0IGtub3duIHRvIGJlIGNvbmdlc3Rpb24gY29udHJvbGxlZCBieSBpdHMNCj4gZW5kcG9p bnRzLCBpdCBpcyB0aGUgb2JsaWdhdGlvbiBvZiB0aGUgdHVubmVsIHRvIGRldGVjdCBjb25nZXN0 aW9uIGFuZCByZWFjdCB0byBpdA0KPiBieSByZWR1Y2luZyB0aGUgdHJhZmZpYyB2b2x1bWUuIEJl Y2F1c2UgZm9yIHRoZSByZXN0IG9mIHRoZSBuZXR3b3JrLCB0aGF0IHR1bm5lbA0KPiBpcyB0aGUg VURQIHNlbmRlciwgYW5kIHdlIGhhdmUgSUVURiBjb25zZW5zdXMgdGhhdCB3ZSBkb24ndCB3YW50 IFVEUCBzZW5kZXJzDQo+IHRoYXQgZG9uJ3QgcmVhY3QgdG8gY29uZ2VzdGlvbiBvbiB0aGUgbmV0 LiAoVGhhdCdzIG9uZSBvZiB0aGUgbWFpbiByZWFzb25zIGZvcg0KPiB0aGUgZXhpc3RlbmNlIG9m IHRoZSBSTUNBVCBXRyAtIHdlIGRvbid0IHdhbnQgbm9uLWNvbmdlc3Rpb24tY29udHJvbGxlZCBS VFANCj4gbWVkaWEgdHJhZmZpYyBvbiB0aGUgbmV0LikNCj4gDQo+IFRoZSBrZXkgZGlmZmVyZW5j ZSBiZXR3ZWVuIHB1dHRpbmcgTVBMUyBlLmcuIGludG8gSVAgY29tcGFyZWQgdG8gcHV0dGluZyBp dA0KPiBpbnRvIFVEUCBpcyB0aGF0IG9uY2UgaXQncyBpbiBVRFAsIGl0IGNhbiBnbyBwcmV0dHkg bXVjaCBhbnl3aGVyZSBvbiB0aGUgbmV0LA0KPiBiZWNhdXNlIFVEUCB0cmF2ZXJzZXMgTkFUcyBh bmQgZmlyZXdhbGxzIG11Y2ggbW9yZSBlYXNpbHkgdGhhbiBJUCB0cmFmZmljIHdpdGgNCj4gYSBy YXJlIHByb3RvY29sIG51bWJlciBkb2VzLg0KPiANCj4gPj4gU2ltaWxhcmx5LCB5b3Ugd2FudCB0 aGUgY2xpZW50IG9mIE1QTFMgdG8gYmUgcmVzcG9uc2libGUgZm9yIG1hbmFnaW5nDQo+ID4+IGl0 cyB0cmFmZmljLiBNUExTIGdpdmVzIHlvdSBwYXRocywgaXQgZG9lc24ndCBwdXNoIHBhY2tldHMg b3ZlciB0aGVtLg0KPiANCj4gUmlnaHQuIEhvd2V2ZXIsIG9uY2UgeW91IHNsYXAgYSBVRFAgaGVh ZGVyIG9uIGEgcGFja2V0IGR1cmluZyBlbmNhcHN1bGF0aW9uLA0KPiB5b3Ugbm93IHN1YmplY3Rl ZCB5b3Vyc2VsZiB0byB0aGUgcnVsZXMgZm9yIEludGVybmV0IFVEUCBzZW5kZXJzLiBUaG9zZSBh cmUNCj4gZG9jdW1lbnRlZCBpbiBSRkM1NDA1LCBhbmQgcmVxdWlyZSB0aGUgdHVubmVsIHRvIGlt cGxlbWVudCBzb21lIHNvcnQgb2YNCj4gY29uZ2VzdGlvbiBkZXRlY3Rpb24gYW5kIGNvbnRyb2wu IEknZCBwZXJzb25hbGx5IGNvbnNpZGVyIGEgY2lyY3VpdCBicmVha2VyDQo+IG1lY2hhbmlzbSBz dWZmaWNpZW50LCBsaWtlIFJUUCBhbmQgSSB0aGluayBQV0UgYXJlIHVzaW5nLg0KPiANCj4gPiBG dWxseSBhZ3JlZS4gVGhlIGNvbmdlc3Rpb24gY29udHJvbCBzaG91bGQgYmUgcGVyZm9ybWVkIGVp dGhlciBieSB0aGUgVURQDQo+IHR1bm5lbCBpdHNlbGYgb3IgdGhlIGNsaWVudCBvZiBNUExTLiBJ biB0aGUgZm9ybWVyIGNhc2UsIGl0J2QgYmV0dGVyIHRvIHNwZWNpZnkgdGhlDQo+IHByYWN0aWNh bCBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtcyAoaWYgdGhlcmUgd2VyZSBhbnkpIGluIGEg Z2VuZXJpYyBkcmFmdA0KPiAoZS5nLiwgUkZDNTQwNWJpcykgYW5kIHRoZW4gYW55IHVzZSBvZiB0 aGUgVURQIHR1bm5lbCBjb3VsZCByZWZlciB0byB0aGF0DQo+IGdlbmVyaWMgZHJhZnQgd2l0aCBy ZWdhcmQgdG8gY29uZ2VzdGlvbiBjb250cm9sLg0KPiANCj4gVGhlIGdlbmVyYWwgY29uY2VwdCBv ZiBhIGNpcmN1aXQgYnJlYWtlciBpcyBlYXN5IGVub3VnaCB0aGF0IGl0IGRvZXNuJ3QgcmVhbGx5 DQo+IG5lZWQgdG8gYmUgd3JpdHRlbiBkb3duLiBBbmQgaXQgd291bGRuJ3QgYmUgcG9zc2libGUg dG8gZGVzY3JpYmUgaXQgaW4gYSBnZW5lcmljDQo+IGZhc2hpb24sIGJlY2F1c2UgY29uZ2VzdGlv biBkZXRlY3Rpb24gaXMgdHlwaWNhbGx5IHNwZWNpZmljIHRvIHRoZSBwcm90b2NvbCBiZWluZw0K PiBlbmNhcHN1bGF0ZWQgKGUuZy4sIFJUUCB1c2VzIFJUQ1AgZmVlZGJhY2sgdG8gZGVyaXZlIGxv c3MgaW5mb3JtYXRpb24sIGV0Yy4pIEFuZA0KPiB0aGUgcmVhY3Rpb24gdG8gY29uZ2VzdGlvbiBp cyBhbHNvIGRlcGVuZGVudCBvbiB0aGUgcHJvdG9jb2wgYmVpbmcNCj4gZW5jYXBzdWxhdGVkIChk b2VzIGl0IHN1cHBvcnQgbXVsdGlwbGUgcmF0ZXMgb3Igb25seSBvbi9vZmYsIHdoYXQgdGltZXNj YWxlcyBhcmUNCj4gT0sgZm9yIHJlYWN0aW9uLCBldGMuKQ0KPiANCj4gPiBJbiB0aGUgbGF0dGVy IGNhc2UsIGlmIHRoZSBjbGllbnQgb2YgTVBMUyBpcyBUQ1AtZnJpZW5kbHksIHRoYXQgaXMgZ3Jl YXQuIE90aGVyd2lzZQ0KPiAoZS5nLiwgY2lyY3VpdCBlbXVsYXRpb24gc2VydmljZSksIGl0IHNo b3VsZG4ndCBiZSBkZXBsb3llZCBvbiB0aGUgSW50ZXJuZXQgYXQgYWxsLA0KPiBqdXN0IGFzIGhh cyBiZWVuIHBvaW50ZWQgb3V0IGluIFJGQzM5ODUsIHRoZXJlZm9yZSB0aGVyZSBpcyBubyBuZWVk IGZvciBhbnkNCj4gc3BlY2lmaWMgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSBvbiB0aGUg Y2xpZW50Lg0KPiA+DQo+ID4gICIuLi4gSW4gZXNzZW5jZSwgdGhpcyByZXF1aXJlbWVudCBzdGF0 ZXMgdGhhdCBpdCBpcw0KPiA+ICAgbm90IGFjY2VwdGFibGUgdG8gZGVwbG95IGFuIGFwcGxpY2F0 aW9uICh1c2luZyBQV0UzIG9yIGFueSBvdGhlcg0KPiA+ICAgdHJhbnNwb3J0IHByb3RvY29sKSBv biB0aGUgYmVzdC1lZmZvcnQgSW50ZXJuZXQsIHdoaWNoIGNvbnN1bWVzDQo+ID4gICBiYW5kd2lk dGggYXJiaXRyYXJpbHkgYW5kIGRvZXMgbm90IGNvbXBldGUgZmFpcmx5IHdpdGggVENQIHdpdGhp biBhbg0KPiA+ICAgb3JkZXIgb2YgbWFnbml0dWRlLiIgKHF1b3RlZCBmcm9tIFNlY3Rpb24gNi41 IG9mIFJGQzM5ODUpDQo+ID4NCj4gPiBUaGUgYWJvdmUgY2hvaWNlIHNlZW1zIG5vIGNvbmZsaWN0 IHdpdGggdGhlIGZvbGxvd2luZyBjb25nZXN0aW9uIGNvbnRyb2wNCj4gZ3VpZGVsaW5lcyBhcyBx dW90ZWQgZnJvbSBTZWN0aW9uIDMuMS4xIG9mIFJGQzU0MDUsIGFzIHRob3NlIG5vbi1UQ1AtZnJp ZW5kbHkNCj4gdHJhZmZpYyB3b3VsZCBiZSB0cmFuc3BvcnRlZCBvdmVyIGEgcHJvdmlzaW9uZWQg cGF0aCwgcmF0aGVyIHRoYW4gb24gdGhlDQo+IEludGVybmV0Lg0KPiA+DQo+ID4gICAiLi4uRmlu YWxseSwgc29tZSBidWxrIHRyYW5zZmVyIGFwcGxpY2F0aW9ucyBtYXkgY2hvb3NlIG5vdCB0byBp bXBsZW1lbnQNCj4gPiAgIGFueSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIGFuZCBpbnN0 ZWFkIHJlbHkgb24gdHJhbnNtaXR0aW5nDQo+ID4gICBhY3Jvc3MgcmVzZXJ2ZWQgcGF0aCBjYXBh Y2l0eS4gIFRoaXMgbWlnaHQgYmUgYW4gYWNjZXB0YWJsZSBjaG9pY2UNCj4gPiAgIGZvciBhIHN1 YnNldCBvZiByZXN0cmljdGVkIG5ldHdvcmtpbmcgZW52aXJvbm1lbnRzLCBidXQgaXMgYnkgbm8N Cj4gPiAgIG1lYW5zIGEgc2FmZSBwcmFjdGljZSBmb3Igb3BlcmF0aW9uIGluIHRoZSBJbnRlcm5l dC4iDQo+IA0KPiBIb3cgaXMgdGhhdCBpbiBjb25mbGljdD8gQm90aCBxdW90ZXMgc2F5IHRoYXQg SW50ZXJuZXQgdHJhZmZpYyBuZWVkcyBjb25nZXN0aW9uDQo+IGNvbnRyb2wsIHdoaWNoIGlzIGEg cmVzdGF0ZW1lbnQgb2YgUkZDMjkxNC4NCg0KSGkgTGFycywNCg0KTm8gY29uZmxpY3QgYXQgYWxs LiBXaGF0IEkgbWVhbnQgaXM6IGZvciB0aG9zZSBjbGllbnRzIG9mIE1QTFMgd2hpY2ggYXJlIG5v dCBUQ1AtZnJpZW5kbHkgKGNhc2UgMiYzIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMS4zIG9m IFJGQzU0MDUpLCB0aGV5IHNob3VsZCBuZXZlciBiZSB0cmFuc3BvcnRlZCBvdmVyIHRoZSB1bnBy b3Zpc2lvbmVkIHBhdGggKGUuZy4sIHRoZSBJbnRlcm5ldCkuIEluc3RlYWRzLCB0aGV5IHNob3Vs ZCBvbmx5IGJlIHRyYW5zcG9ydGVkIG92ZXIgYSBwcm92aXNpb25lZCBwYXRoIGluIGEgcmVzdHJp Y3RlZCBuZXR3b3JraW5nIGVudmlyb25tZW50LiBBcyBhIHJlc3VsdCwgdGhlcmUgaXMgbm8gbmVl ZCBmb3IgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gZm9yIHRoZW0uDQoNCkJlc3Qg cmVnYXJkcywNClhpYW9odQ0KDQo+IExhcnMNCg== From stbryant@cisco.com Mon Jan 13 01:35:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CB91AE055 for ; Mon, 13 Jan 2014 01:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 8Thpw841awJR for ; Mon, 13 Jan 2014 01:35:15 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6B1ADF91 for ; Mon, 13 Jan 2014 01:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=756; q=dns/txt; s=iport; t=1389605705; x=1390815305; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fCC+6B4dRml0YwA9B/bNhBw8CSmazGABsodQJ+wJJgY=; b=W7c1+IUDPA8LT3KP8JOqF7vaOfN0Z2moigqD6i88CRXyyxfcewNgrPFS 284fdxDtlrd8N4XU51cQY5snL2yw+kn6T+xeCEH8JmzfqJ6Cx7+KOzlgx fQQdOjkDVrCePlvbyIuASUknKLMT7Lg37G6pGSi9RjDO0hcNeo62zFECx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFABCy01KQ/khR/2dsb2JhbABagwu3boMIgQ4WdIIlAQEBBDhAARALGAkWBAsJAwIBAgFFBgEMAQcBAYgAxFYXjwcHhDcBA5gXkhWBb4E+ X-IronPort-AV: E=Sophos;i="4.95,651,1384300800"; d="scan'208";a="2881651" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 13 Jan 2014 09:35:03 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0D9Z2Kq024003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jan 2014 09:35:03 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0D9Z1h3023919; Mon, 13 Jan 2014 09:35:01 GMT Message-ID: <52D3B345.4050002@cisco.com> Date: Mon, 13 Jan 2014 09:35:01 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mark.tinka@seacom.mu, Gregory Mirsky References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <201401121444.31194.mark.tinka@seacom.mu> <7347100B5761DC41A166AC17F22DF1121B744E67@eusaamb103.ericsson.se> <201401130713.13126.mark.tinka@seacom.mu> In-Reply-To: <201401130713.13126.mark.tinka@seacom.mu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 09:35:16 -0000 On 13/01/2014 05:13, Mark Tinka wrote: > On Monday, January 13, 2014 03:30:04 AM Gregory Mirsky > wrote: > >> Hi Mark, >> if by "provisioning" you mean "mapped to", "assigned", >> then what about IP addresses? Ain't they pre-provisioned >> as well? Or these are native properties of NEs? > The path that two successive IP packets take to get from > point A to B, in an MPLS-free network, can be arbitrary. It can be arbitrary, but the router designers try rather hard to make sure that flows follow the same path. This is because the transport protocols in the hosts complain if the routers introduce misordering. Remove that constraint and the forwarders become a lot simpler and we can do all sorts of anti-PM in the network. Stewart From lars@netapp.com Mon Jan 13 01:37:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ADC1AE055; Mon, 13 Jan 2014 01:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 0L8_sTzC5O3s; Mon, 13 Jan 2014 01:37:32 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 62F831ADF91; Mon, 13 Jan 2014 01:37:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,651,1384329600"; d="asc'?scan'208";a="95688395" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 13 Jan 2014 01:37:21 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 01:37:21 -0800 From: "Eggert, Lars" To: Xuxiaohu Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAD31WAgABWjoCAAAdiAIAABdIA Date: Mon, 13 Jan 2014 09:37:20 +0000 Message-ID: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082443DD@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082443DD@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_D834C883-FFDC-432B-B9B4-215915D1A122"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , Scott Brim , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 09:37:33 -0000 --Apple-Mail=_D834C883-FFDC-432B-B9B4-215915D1A122 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi, On 2014-1-13, at 10:16, Xuxiaohu wrote: > No conflict at all. What I meant is: for those clients of MPLS which = are not TCP-friendly (case 2&3 as described in Section 3.1.3 of = RFC5405), they should never be transported over the unprovisioned path = (e.g., the Internet). Insteads, they should only be transported over a = provisioned path in a restricted networking environment. As a result, = there is no need for the congestion control mechanism for them. ah, sorry! I misread "The above choice seems no conflict" in your = sentence as "The above choice seems TO conflict". Oops. Lars --Apple-Mail=_D834C883-FFDC-432B-B9B4-215915D1A122 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----- iQCVAwUBUtOz0NZcnpRveo1xAQLiZwQAlvXyzXRgiebzdR+moRumQVl30K/ldWsd NPlF/NlG1KkrMM69dyAjfdGHEcQZ1uZcpYt6/YoCsUIDITBt5wtU+HORyGijGAj2 1AH9NT2GHUyZPLg5lcRM3oCJ0odc9LnKlItH32s5bpRVFDmVjeh6/ba/4r2th/He cNDPjMtU9WE= =Ba1T -----END PGP SIGNATURE----- --Apple-Mail=_D834C883-FFDC-432B-B9B4-215915D1A122-- From lars@netapp.com Mon Jan 13 01:42:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA901ADF91; Mon, 13 Jan 2014 01:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 ISxiETNSJuqI; Mon, 13 Jan 2014 01:42:24 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4961ADE71; Mon, 13 Jan 2014 01:42:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,651,1384329600"; d="asc'?scan'208";a="95688805" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 13 Jan 2014 01:42:13 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 01:42:13 -0800 From: "Eggert, Lars" To: Xuxiaohu Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAD31WAgABWjoCAAAdiAIAAByqA Date: Mon, 13 Jan 2014 09:42:12 +0000 Message-ID: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082443DD@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082443DD@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_6A8AC501-152C-4A56-8A49-10A38055B6D9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , Scott Brim , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 09:42:25 -0000 --Apple-Mail=_6A8AC501-152C-4A56-8A49-10A38055B6D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi, On 2014-1-13, at 10:16, Xuxiaohu wrote: > No conflict at all. What I meant is: for those clients of MPLS which = are not TCP-friendly (case 2&3 as described in Section 3.1.3 of = RFC5405), they should never be transported over the unprovisioned path = (e.g., the Internet). Insteads, they should only be transported over a = provisioned path in a restricted networking environment. As a result, = there is no need for the congestion control mechanism for them. I agree, but I think we need a safety mechanism when such traffic does = end up on the general Internet (because operators may not read the RFC, = or there may be configuration errors, etc.) Even when running inside a provisioned domain, you probably want some = sort of safety net, like a circuit breaker that detects if your tunnel = is experiencing/causing severe congestion, and shut it down. Lars --Apple-Mail=_6A8AC501-152C-4A56-8A49-10A38055B6D9 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----- iQCVAwUBUtO08dZcnpRveo1xAQI95gQAgLVnN1A0dhbDOGTouXbI1mLZ7ybfAIZn hnyIX57k2pEI3Bbz7NsNK8GDf5EX6RWKl7Y7yqHVrVTIzJ0H1uzguq83gYoOg30l 5JLcybhzrfbH5DxqkmAXtGTRsoqNtNCqVBDOk8lFHzBlrA9vFkZ2T+kUZwC8rvyJ aHAw6LWx2qU= =aTe9 -----END PGP SIGNATURE----- --Apple-Mail=_6A8AC501-152C-4A56-8A49-10A38055B6D9-- From jmh@joelhalpern.com Mon Jan 13 07:51:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E181AE115; Mon, 13 Jan 2014 07:51:59 -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 D5LWw16SU__M; Mon, 13 Jan 2014 07:51:58 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 796A11AE098; Mon, 13 Jan 2014 07:51:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C9E631C06303; Mon, 13 Jan 2014 07:51:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 6F31B1C06304; Mon, 13 Jan 2014 07:51:46 -0800 (PST) Message-ID: <52D40B91.8040101@joelhalpern.com> Date: Mon, 13 Jan 2014 10:51:45 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Eggert, Lars" , Xuxiaohu References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , Scott Brim , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 15:51:59 -0000 Lars, are you really asking that the document say: 1) That the UDP encapsulation of MPLS can only be used when the devices performing the encapsulation and decapsulation know what protocol (above IP, if IP is being carried; above Ethernet and IP if the frame is Ethernet carrying IP) is being used 2) That those devices need to engage in a congestion control protocol if the carried packets are not TCP, SCTP, or DCCP? Those both look like excessive and difficult requirements. Which is fine if our goal is to pretend we are telling folks not to use UDP encapsulation of MPLS. (I had not thought that was our goal.) In practice, I simply do not see how anyone implementing this will pay any attention to either requirement. Yours, Joel On 1/13/14 3:50 AM, Eggert, Lars wrote: > Hi, > > On 2014-1-13, at 4:40, Xuxiaohu wrote: >>> I don't think it's right to try to solve this in MPLS, because >>> MPLS is not a forwarding protocol - it's a connectivity >>> protocol. > > right, MPLS is the wrong place to address is. The UDP encaps/decaps > function needs to have this functionality. > >>> In any use of UDP, congestion control is either left to something >>> above UDP or ignored (left to queue management). > > There are several cases, see Section 3.1.3 of RFC5405. MPLS-over-UDP > can fall into any of the three cases, depending on what traffic is > inside the LSP being encapsulated. > > You'll notice that RFC5405 for the first case - encapsulation of > IP-based congestion controlled "normal" Internet traffic - even says > that the tunnel SHOULD NOT employ any congestion control scheme of > its own. Having layered control loops fighting is not productive. > > The issue with MPLS-in-UDP (and GRE-in-UDP, and any other encaps > scheme that can carry non-IP traffic) are with cases two and three. > When the workload that is being encapsulated isn't known to be > congestion controlled by its endpoints, it is the obligation of the > tunnel to detect congestion and react to it by reducing the traffic > volume. Because for the rest of the network, that tunnel is the UDP > sender, and we have IETF consensus that we don't want UDP senders > that don't react to congestion on the net. (That's one of the main > reasons for the existence of the RMCAT WG - we don't want > non-congestion-controlled RTP media traffic on the net.) > > The key difference between putting MPLS e.g. into IP compared to > putting it into UDP is that once it's in UDP, it can go pretty much > anywhere on the net, because UDP traverses NATs and firewalls much > more easily than IP traffic with a rare protocol number does. > >>> Similarly, you want the client of MPLS to be responsible for >>> managing its traffic. MPLS gives you paths, it doesn't push >>> packets over them. > > Right. However, once you slap a UDP header on a packet during > encapsulation, you now subjected yourself to the rules for Internet > UDP senders. Those are documented in RFC5405, and require the tunnel > to implement some sort of congestion detection and control. I'd > personally consider a circuit breaker mechanism sufficient, like RTP > and I think PWE are using. > >> Fully agree. The congestion control should be performed either by >> the UDP tunnel itself or the client of MPLS. In the former case, >> it'd better to specify the practical congestion control mechanisms >> (if there were any) in a generic draft (e.g., RFC5405bis) and then >> any use of the UDP tunnel could refer to that generic draft with >> regard to congestion control. > > The general concept of a circuit breaker is easy enough that it > doesn't really need to be written down. And it wouldn't be possible > to describe it in a generic fashion, because congestion detection is > typically specific to the protocol being encapsulated (e.g., RTP uses > RTCP feedback to derive loss information, etc.) And the reaction to > congestion is also dependent on the protocol being encapsulated (does > it support multiple rates or only on/off, what timescales are OK for > reaction, etc.) > >> In the latter case, if the client of MPLS is TCP-friendly, that is >> great. Otherwise (e.g., circuit emulation service), it shouldn't be >> deployed on the Internet at all, just as has been pointed out in >> RFC3985, therefore there is no need for any specific congestion >> control mechanism on the client. >> >> "... In essence, this requirement states that it is not acceptable >> to deploy an application (using PWE3 or any other transport >> protocol) on the best-effort Internet, which consumes bandwidth >> arbitrarily and does not compete fairly with TCP within an order of >> magnitude." (quoted from Section 6.5 of RFC3985) >> >> The above choice seems no conflict with the following congestion >> control guidelines as quoted from Section 3.1.1 of RFC5405, as >> those non-TCP-friendly traffic would be transported over a >> provisioned path, rather than on the Internet. >> >> "...Finally, some bulk transfer applications may choose not to >> implement any congestion control mechanism and instead rely on >> transmitting across reserved path capacity. This might be an >> acceptable choice for a subset of restricted networking >> environments, but is by no means a safe practice for operation in >> the Internet." > > How is that in conflict? Both quotes say that Internet traffic needs > congestion control, which is a restatement of RFC2914. > > Lars > From mark.tinka@seacom.mu Mon Jan 13 09:10:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9B21AE1AB for ; Mon, 13 Jan 2014 09:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 078SlJVQOMoL for ; Mon, 13 Jan 2014 09:09:59 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 646311ADFA3 for ; Mon, 13 Jan 2014 09:09:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W2l0h-0004z8-Ej; Mon, 13 Jan 2014 19:09:11 +0200 From: Mark Tinka Organization: SEACOM To: stbryant@cisco.com Date: Mon, 13 Jan 2014 19:09:00 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <201401130713.13126.mark.tinka@seacom.mu> <52D3B345.4050002@cisco.com> In-Reply-To: <52D3B345.4050002@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1713835.9GnLoDKGqv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401131909.00922.mark.tinka@seacom.mu> Cc: "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 17:10:01 -0000 --nextPart1713835.9GnLoDKGqv Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Monday, January 13, 2014 11:35:01 AM Stewart Bryant=20 wrote: > It can be arbitrary, but the router designers try rather > hard to make sure that flows follow the same path. This > is because the transport protocols in the hosts complain > if the routers introduce misordering. Remove that > constraint and the forwarders become a lot simpler and > we can do all sorts of anti-PM in the network. I'm not talking about flow load sharing. I'm talking about=20 simple, linear flows. Mark. --nextPart1713835.9GnLoDKGqv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS1B2sAAoJEGcZuYTeKm+G2cgQAIflwu9Sd99JQ6gNmzqM/KSA vS49aCj41tAcO8ZLwuYyUfkNWOT2OF9AzebRa6BWfcSO8EFaqm1DRD2caIShxQ0L Lmk3fDFVYeTBDKvsSFi7RtHVsOT4VkBataPyOCOpq+Ou7woJ2Z9xpsWzmkmvvVnV W+eVnqSBeq7MkRPamECC3IHNlerTpVkacvNpo2ncsy2t2WfcF8J9hZoyE+YU4iHR BzCOQxDr8lyf8edoM203NpAIddUz7glaaSRPR1/wlFoNQ4NO1p/RB7fEVez28xLB KEEY/Yi3jZmRsd2X83c9RTcmBqYoe+L8r259gyQxqG6nEWdTVxXJIdzjvla0WTag cvB89d15+ItTbJ1gjQVD7HrfU76mGDpZerlvM+SfFSQXq2ODrn3yI7P/KvwALlSp pnjEtRtvFWj0iHPrmA/O0S3AhIAWrj78to0Wyz6SnrkV2D3IfO6psbfvqkcGKy4H 73jeFhBR6LFXS24lRLhv8nj9DMuqxf+XZ/8aEx4zywGqwMaJNT6drkg7sDArS/BD 6N4UJX2MNO6gicPLquD51NunlN5tLZQDipf1W4+J4UIPS+HoZpUFkb53UR7JPVF+ gfmIQgsOMH2kqS5nwQEF+ouwkotd6WgwyutxVc39rMaq8VDk3jvEStI+kXhOHUuH 0XVgEwmmm/rvrKYCih4X =wrLY -----END PGP SIGNATURE----- --nextPart1713835.9GnLoDKGqv-- From scott.brim@gmail.com Mon Jan 13 11:10:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA31D1ADF48; Mon, 13 Jan 2014 11:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jthw63jgjqFi; Mon, 13 Jan 2014 11:10:12 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A9A4F1ADF30; Mon, 13 Jan 2014 11:10:12 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so8076264obc.37 for ; Mon, 13 Jan 2014 11:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nE0na4ItdB7roaoNLWC4JjOVNLLfW/qhLCfvyE3UEXQ=; b=lqa4L45p5SdD7SXP1WgbjI61WR9adqvlsBCfwfFehj8HfbKR5cdPBJ+Z6cogsydyCU 4Emmkwek9/DDlKrgTn/eaynBpTWSoft4yjMG8D0vtOmiGQgkr28yi8oLdFfBltT+S/0w 78ck8CQskczAI6GrC78nIXJtCrQS601DSgpdMZhhi9UFK+lhqULKoCwEhVSjjBNu59Ka HCWVUkCz1YM9jQ43z+W7M+jUvbdicNmC3qROsml+rdeFErgj8i7MU9DGCSJyP8/PFTHb twsNKyKtB98qLpTZK3zVVTHIcvcos2+1M4rJdBAbTQhSbRa6aPpAO4FCwXTG/snLvDrX ZdYg== X-Received: by 10.60.65.101 with SMTP id w5mr22007857oes.0.1389640200544; Mon, 13 Jan 2014 11:10:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Mon, 13 Jan 2014 11:09:40 -0800 (PST) In-Reply-To: <52D40B91.8040101@joelhalpern.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> From: Scott Brim Date: Mon, 13 Jan 2014 14:09:40 -0500 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:10:14 -0000 On Mon, Jan 13, 2014 at 10:51 AM, Joel M. Halpern wrote: > Lars, are you really asking that the document say: > 1) That the UDP encapsulation of MPLS can only be used when the devices > performing the encapsulation and decapsulation know what protocol (above > IP, if IP is being carried; above Ethernet and IP if the frame is > Ethernet carrying IP) is being used > 2) That those devices need to engage in a congestion control protocol if > the carried packets are not TCP, SCTP, or DCCP? > > Those both look like excessive and difficult requirements. I'm concerned about TCP-over-X.25 scenarios. If the lower layer encapsulation does not know what congestion management is being used above, and it does what would be best assuming there isn't any, performance can truly suck. How was this handled in other cases? Saying UDP is a user of IP and thus must provide congestion control would be fine if our layering were simple and UDP was Transport, but in this case UDP is "lower layer", an encapsulation to extend the reach of MPLS and whatever is running over it. > Which is > fine if our goal is to pretend we are telling folks not to use UDP > encapsulation of MPLS. (I had not thought that was our goal.) > > In practice, I simply do not see how anyone implementing this will pay > any attention to either requirement. Yes. My inclination is that this is not fundamental architecture, and we can afford to see if there's a problem before we solve it. Scott From curtis@ipv6.occnc.com Mon Jan 13 11:11:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAA41AE005; Mon, 13 Jan 2014 11:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 M6kaCCNyruBj; Mon, 13 Jan 2014 11:11:37 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id A52B91AE008; Mon, 13 Jan 2014 11:11:36 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0DJBC1o079251; Mon, 13 Jan 2014 14:11:12 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401131911.s0DJBC1o079251@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Mon, 13 Jan 2014 00:45:52 +0000." <290E20B455C66743BE178C5C84F1240847E63346BF@EXMB01CMS.surrey.ac.uk> Date: Mon, 13 Jan 2014 14:11:12 -0500 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, farinacci@gmail.com, jnc@mit.edu, lisp@ietf.org Subject: Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:11:39 -0000 One of the reasons that IPv6 (rfc2460) dropped the header checksum that was in IPv4 is that with link layers all doing FCS it served no purpose. For the same reason TCP and UDP checksums server no purpose. The link layer checksum fails and the packet is dropped. Since this is usually not at the last hop (often a local Ethernet) but instead in a WAN link, the packet never arrives at the destination for anything to count IP header or TCP or UDP checksum errors. Also all of the following handle both data integrity and congestion avoidance the same way: UDP over IP over Ethernet UDP over IP over MPLS over Ethernet UDP over IP over MPLS over UDP over IP over Ethernet s/Ethernet/{POS,GFP,etc}/ for all of the above s/^UDP over IP/PW/ for all of the above In all of the above cases data integrity is handled by the link layer. In all of the above cases congestion avoidance is handled by the application (or not at all). Whether MPLS is carried directly over a link layer or over UDP/IP over a link layer makes no difference. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346BF@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > Really, you'd want to expose the pseudoheader check at endhosts; a well-instrumented Linux box could tell you a lot > about checksum failures. > > But in this case, a router would be decapping UDP/MPLS tunnels as an endpoint, so could report on checksum failures - > if the checksum wasn't zero. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Dino Farinacci [farinacci@gmail.com] > Sent: 12 January 2014 21:37 > To: Wood L Dr (Electronic Eng) > Cc: ; ; gorry@erg.abdn.ac.uk; lisp@ietf.org; david.black@emc.com; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; ietf@ietf.org > Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) > > > Do any routers count TCP/UDP checksum failures, much less > > expose the count via SNMP? > > Typically they do but only for packets destined to them. Much like hosts would check the header checksum. > > Dino > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Mon Jan 13 12:04:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DBB1ADFCA for ; Mon, 13 Jan 2014 12:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 eP9_LRbuYAzU for ; Mon, 13 Jan 2014 12:04:29 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 178C61ADFB5 for ; Mon, 13 Jan 2014 12:04:28 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0DK4DFO080786; Mon, 13 Jan 2014 15:04:13 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401132004.s0DK4DFO080786@maildrop2.v6ds.occnc.com> To: mark.tinka@seacom.mu From: Curtis Villamizar In-reply-to: Your message of "Mon, 13 Jan 2014 07:13:09 +0200." <201401130713.13126.mark.tinka@seacom.mu> Date: Mon, 13 Jan 2014 15:04:13 -0500 Cc: "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 20:04:30 -0000 In message <201401130713.13126.mark.tinka@seacom.mu> Mark Tinka writes: > On Monday, January 13, 2014 03:30:04 AM Gregory Mirsky > wrote: > > > Hi Mark, > > if by "provisioning" you mean "mapped to", "assigned", > > then what about IP addresses? Ain't they pre-provisioned > > as well? Or these are native properties of NEs? > > The path that two successive IP packets take to get from > point A to B, in an MPLS-free network, can be arbitrary. > > FEC's are constant for a group of IP destinations mapped to > them. > > Mark. Mark, Perhaps someone needs to explain to you what a FEC is and how MPLS traffic is routed in most LDP networks. The most common FECs "in the wild" from LDP RFC 5036 are the prefix TLV or address list TLV containing exactly one address local to an originating router. This FEC is passed to adjacent LSR and each LSR that get the FEC from more than one neighbor picks the best among them based on the IP routing table. Having picked a "best" next hop for the FEC, the LSR passed the FEC on to all other neighbors. In this way a multipoint to point tree is built where the tree exactly follows the IP routes in the same network. If there is an IP routing change, the MPLS tree to that FEC also changes. A packet destined to a given FEC would follow the same set of hops whether it was encapsulated in IP or encapsulated in MPLS. For things like PW or VPN, the MPLS encapsulation is needed but the endpoint can be identified by the FEC. MPLS label mappings *can* be provisioned, but in most cases (nearly all AFAIK) they are not. LDP is a signaling protocol and the mappings of label to FEC are dynamic as described in the prior paragraph. It is in the absense of LDP (and in the absense of RSVP-TE) that label mappings are provisioned. So your objection above and in prior emails seems to be based on a misunderstanding of what a MPLS FEC is and how LDP works. X over MPLS over L2 follows the same path to an IP FEC as X over MPLS over UDP over IP over L2. The exception is that if part of the network does not support MPLS (including an LDP partitioning where A and B would otherwise not have MPLS connectivity), X over MPLS over UDP over IP over L2 can make use of the non-MPLS capable part of that network. Curtis From internet-drafts@ietf.org Mon Jan 13 12:27:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310251AE146; Mon, 13 Jan 2014 12:27:45 -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 DbgLSJV-dPZ4; Mon, 13 Jan 2014 12:27:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2C21AE000; Mon, 13 Jan 2014 12:27:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140113202740.722.73887.idtracker@ietfa.amsl.com> Date: Mon, 13 Jan 2014 12:27:40 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 20:27:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Seamless MPLS Architecture Authors : Nicolai Leymann Bruno Decraene Clarence Filsfils Maciek Konstantynowicz Dirk Steinberg Filename : draft-ietf-mpls-seamless-mpls-05.txt Pages : 39 Date : 2014-01-13 Abstract: This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mpls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-seamless-mpls-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 mkonstan@cisco.com Mon Jan 13 12:28:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639BA1AE098 for ; Mon, 13 Jan 2014 12:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.439 X-Spam-Level: X-Spam-Status: No, score=-9.439 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_35=0.6, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 eBYItydTW3kA for ; Mon, 13 Jan 2014 12:28:29 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2C97B1ADFC3 for ; Mon, 13 Jan 2014 12:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13409; q=dns/txt; s=iport; t=1389644898; x=1390854498; h=from:to:cc:subject:date:message-id:references: in-reply-to:reply-to:content-id:content-transfer-encoding: mime-version; bh=k5IWfrVH93EYss7b70oIMWHTWVb0Rl3pYx8fsrBOtMs=; b=d5GOMN+hsa0osR2vwXlY9CSZTGBQ76gXYufF3Gbtpwa8/JKvH4mBerjC POsylkDVFUcDe23kfZpVVpAZuQPG/d6ePEnA3RtkmpYBS7YACi/lKA506 7rt1Tf8uEgIkL9Kc9S+V6QV7nozFqaiqI2tlc/qagADxBTnkBco3Hrqi0 A=; X-IronPort-AV: E=Sophos;i="4.95,654,1384300800"; d="scan'208";a="12549883" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 13 Jan 2014 20:28:18 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0DKSI5T019426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 20:28:18 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.165]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 14:28:17 -0600 From: "Maciek Konstantynowicz (mkonstan)" To: Curtis Villamizar Thread-Topic: [mpls] Still open: working group lst call on draft-ietf-mpls-seamless-mpls Thread-Index: AQHPEJ39DWlOvSXkY0qTgSKWAAnxhw== Date: Mon, 13 Jan 2014 20:28:16 +0000 Message-ID: References: <201310151709.r9FH98ts055454@gateway1.ipv6.occnc.com> In-Reply-To: <201310151709.r9FH98ts055454@gateway1.ipv6.occnc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.97.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <28F329C606FF31429D5D1C320678A617@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-seamless-mpls.all@tools.ietf.org" Subject: Re: [mpls] Still open: working group lst call on draft-ietf-mpls-seamless-mpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "maciek@cisco.com" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 20:28:32 -0000 Curtis, Pls see our comments inline, and let us know your thoughts. We have also posted updated ID. On 15 Oct 2013, at 18:09, Curtis Villamizar wrote: >=20 > Loa, >=20 > No details are given in IPR #686 (applicable to RFC 5283) for the > "Reasonable and Non-Discriminatory License to All Implementers with > Possible Royalty/Fee." At the very least, some terms should be given. Update from Bruno in addition to the email he sent on Date: 16 October 2013 08:43:46 GMT+01:00 <...> Tried for more than 6 months, to have my IPR team to update the IPR 853 to make it clear that it _replaces/supersede _ 686. But they are not moving. It's all the more incredible that they have dropped the patent. So no, it's not even "No licence Required" it's even no IPR at all... That being said, the above IPR was on RFC 5283, not on seamless MPLS draft. I had a discussion with Loa & Adrian on this, and there opinion is that no IPR declaration would be required for draft seamless mpls. So there is no real problem in the first place. <...> >=20 > IPR #1920 and #2212 do provide details. >=20 > An alternate to the use of a prefix based LDP LSP is to use a prefix > based RSVP-TE LSP and carry the individual end-to-end LSP within it. > This is not mentioned in the draft. See below for details. The use cases, proposed design and protocol choices have been driven by the actual SP deployments. Design based on the hierarchy of RSVP-TE LSPs may address the listed use cases. However the labeled BGP design with LDP DoD has been chosen due to the higher degree of out-of-the-box automation and operational simplicity as well as compatibility with the existing backbone and backhaul designs & deployments which use LDP and not RSVP-TE. It also assumes relatively simple MPLS implementations on access nodes - RFC 7032 goes into much more detail there. >=20 > Scaling numbers are given as: >=20 > Number of Aggregation Domains: 100 > Number of Backbone Nodes: 1.000 > Number of Aggregation Nodes: 10.000 > Number of Access Nodes: 100.000 >=20 > This section should state that very sparse connectivity among the set > of access nodes is expected. For exampls, you would not expect each > access node to have an LSP to every other access node. Is so, more > than 10 such access nodes aggregated prior to a prefix based LSP would > exceed the limits of the MPLS 20 bit label space. The requirement was to cater for service connectivity over transport LSPs per scaling numbers provided for listed deployment use cases. The required design was not to restrict the LSP based connectivity between the access, aggregation and backbone nodes, catering equally well for sparse and dense connectivity, but not the full-mesh. Full-mesh connectivity between between all ANs will require each AN maintaining LSP that they initiate and terminate, complicating the AN implementation.=20 Luckily this is not the case in the listed use cases and the actual access deployments. The result is the seamless MPLS design specified in this draft. And it does work for dense transport LSP connectivity between the access nodes without exhausting the MPLS 20-bit label space on any of the nodes by relying on LSP hierarchy provided by labeled BGP for inter-domain connectivity. See section 5.2 for scalability analysis, and numerical examples for access node connectivity in section 5.2.1.5. >=20 > On the other hand it would not be unreasonable to expect each of the > 10,000 aggregation nodes to be fully meshed or at least very densely > meshed. This can also create problems without some form of > aggregation as a worst case graph cut set with 5000 nodes on each side > would have 25,000,000 LSP. A cutset of 2-5 nodes (typical core) could > not support this (exceeds the 20 bit label space) without aggregation. We read your comment "without some form of aggregation" as meaning "without some form of hierarchy". If so, indeed this is why specified design used LSP hierarchy per earlier comment. >=20 > Some indication of how dense or sparse the connectivity would be > useful in this section (2.1. Why Seamless MPLS). =20 Indicative access node level connectivity has been described in section 5.2 Scalability Analysis, but we agree that it makes sense to give an indication in section 2.1 Following text added in section 2.1: Multiple Service Providers plan to deploy networks with 10k to 100k MPLS nodes, with varying levels of MPLS LSP connectivity between those nodes - sparse-mesh in access, partial-mesh in aggregation and full-mesh in core. This is typically at least one order of magnitude higher than typical deployments and may require a new architecture. > It may be worth > creating a new subsection (2.2 Scaling Goals) and going into a little > more detail. We believe this comment is addressed by above addition in section 2.1 and section 5.2. Scalability Analysis. Let us know if this does address your comment. >=20 > Then there is the question as to whether this draft should even go > forward at all. Can you pls be more specific why you don't see this draft proceeding ? There are production implementation by both vendors and providers of Seamless MPLS design as specified in this draft. >=20 > It is worth noting that a full mesh of 10.000 RSVP-TE LSP is feasible > using hierarch. Within the core of 100 nodes, PSC-4 can be used. > Each of the 1,000 backbone nodes can create a PSC-3 LSP to each other > backbone node (using above terminology, "edge" nodes in more common > core-edge-access or core-edge-aggregation-access terminology). If on > average there are 10 backbone nodes per core node pair, then each core > node has on the order of 10,000 ILM entries (about 20,000 if you > consider 50 pairs of core nodes, each serving 20 nodes). There are > only 100 LSP from each core node facing the core side, so FRR can be > very effectively deployed. The same holds for a full mesh of the > 10.000 aggregation nodes. If each of the 1,000 backbone nodes are > deployed in pairs serving on average 20 nodes per pair, then an ILM > siz on the order of 200,000 is needed. The PSC-3 LSP used to reach > the far side backbone node can be used, yielding only 1,000 LSP facing > the core per backbone node. Again, FRR can be used, with the protect > path using the alternate core node of the designated pair. >=20 > In this scenarion the access nodes may or may not be full meshed. If > they are full meshed, then they need to be able to support 100,000 DoD > mode LSP. If the are more sparsely meshed, they can support a lower > number of DoD mode LSP. We do not disagree that alternative design approach based on RFC 4206 and related h-LSP RFCs may be applied to address the LSP connectivity in this environment. However we believe the design specified in the Seamless MPLS draft better meets described requirements including better deployment flexibility, better scaling and easier troubleshooting. >=20 > If RSVP-TE is used in this way, there is no need for aggregating LDP > LSP. The LDP LSP are aggregated into RSVP-TE LSP and further > aggregated in PSC-3 LSP and PSC-4 LSP in tiers closer to the core. The draft does not propose aggregating LDP LSPs. In fact the design enables the operator to choose the transport LSP signalling protocol, LDP or RSVP-TE, per domain, per section 4.4. Intra-Domain Routing. >=20 > There are ultimate scaling limits to either approach, imposed by the > 20 bit label space. If a full mesh is needed at a given tier T with N > nodes, then the nodes in tier T-1 aggregating tier T needs an ILM size > of N times the number of T nodes the T-1 node serves. So for example, > with a full mesh of 100,000 tier T nodes if each tier T-1 node could > aggregate 8 tier T nodes without exceeding the 20 bit label space size > (ILM=3D800,000 in this case), but could not aggregate 20 tier T nodes > (ILM=3D2,000,000). If using RSVP-TE in the core, the core is limited by > the worst case cut set, but core sizes of on the order of hundreds are > OK (but smaller is better). In line with your comments the scaling limits are imposed not only by MPLS 20-bit label space, but also by the number of supported LFIB entries on specific MPLS node. Design in this draft relies on labeled BGP control plane to scale the MPLS label distribution and to optimize the MPLS data plane on ABR nodes by installing only the local labelled routes in its LFIB, as described in section 5.1.7. >=20 > Using either RSVP-TE or LDP for aggregation the outermost T-max tier > could have a million nodes or more as long as they were sufficiently > sparsely connected. This limit is independent of whether aggregation > is via LDP or RSVP-TE. Similarly, the scale of the design in this draft is restricted by the scale of AN at the outskirts of the MPLS network and their connectivity needs driving the scale of neighbouring AGNs. >=20 > With RSVP-TE used for aggregation, T-LDP is used among the sparse mesh > in the outermost T-max tier. A T-LDP session is only needed if FEC > information needs to be exchanged via LDP to support an underlying > service, otherwise RSVP-TE alone could be used. Using T-LDP the > number of T-LDP TCP sessions could be a limiting factor for very > highly connected tier T-max nodes. Either TCB state or the 16 bit TCP > port limit could be the limit depending on how much RAM the T-max node > has. OTOH if a tier T-max node out on the fringes is supporting on > the order of 50K T-LDP sessions, it can use multiple IP addresses to > get around the 16 bit TCP port number issue. In the draft, labeled BGP is used for labeled routes, providing excellent scaling properties in the control plane. >=20 > LDP could be extended to avoid the need for T-LDP sessions using LDP > distribution of labels that will make use of RSVP-TE LSP. A DoD > request would normally create a series of label bindings and swaps. > If a full mesh of RSVP-TE LSP is know to exist within a prefix (ie: > tier T), then the LSR can return a mapping of FEC,label,addr with its > address. This mapping can be passed back and at each hop that > actually does have a direct path to that address the mapping can be > installed and the RSVP-TE LSP used as an outer label, even if there is > no T-LDP session to that address. (btw- AFAIK no such extension > exists, I'd be happy to be wrong about that). >=20 > IMHO using RSPV-TE is a viable and IMHO better solution for the > problem posed in this draft. =20 It is opinion of the authors of this draft and WG members supporting this draft that the design described in the draft is more optimal for scaling MPLS into large access and aggregation deployments compared to RSVP-TE with hierarchical LSPs. The draft also efficiently accommodates capabilities of access device and the operational aspects. > It is also not encumbered by IPR AFAIK. IPRs are provided on non-discriminatory terms, per IETF standard. >=20 > I don't think the draft provides a good solution. Per earlier note, the design specified by this draft has been accepted by number of operators for production deployments. /maciek >=20 > Curtis >=20 >=20 >=20 > In message <525CD992.2020800@pi.nu> > Loa Andersson writes: >=20 > Working Group, >=20 > I'll will keep this wglc open until October 21st, there are several > reasons. >=20 > - the subject line did not explicitly say that this was a working group > last call > - we had a very late IPR disclosure, and we are still looking into that. > We should like to draw the attention to the expectation that IPRs > need to be disclosed in a timely fashion after your name appears on > on a document, we are talking days or weeks, rather than months; and > certainly not years > - we have not seen any comments on the list, we are therefore now also > asking if there is support to progress the draft. >=20 > /Loa >=20 >=20 >=20 > On 2013-09-26 13:37, Loa Andersson wrote: >> Working Group, >>=20 >> this is to start a two week+ working group last call on >> draft-ietf-mpls-seamless-mpls-05. >>=20 >> Please send your comment to working group mailing lists (mpls@ietf.org). >>=20 >> We did an IPR poll on this document prior to starting the wglc. >> All the authors responded to the IPR poll that they are not aware of >> any IPR's relating to this document other than the one already >> disclosed. >>=20 >> There are no IPRs disclosed directly against this document, disclosure >> #1920 was disclosed against an earlier individual version of the >> document. >>=20 >> It has also been pointed out that one of the components in the Seamless >> MPLS architecture is derived from RFC 5283 and that IPR disclosures >> # 686 and # 853 are applicable. >>=20 >> The working group last call will end Friday October 11, 2913. >>=20 >> /Loa >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Mon Jan 13 12:31:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5611AE000; Mon, 13 Jan 2014 12:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 90ay5x1IFPNC; Mon, 13 Jan 2014 12:31:23 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id C743A1ADFC3; Mon, 13 Jan 2014 12:31:22 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0DKV4iC081057; Mon, 13 Jan 2014 15:31:04 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401132031.s0DKV4iC081057@maildrop2.v6ds.occnc.com> To: "Eggert, Lars" From: Curtis Villamizar In-reply-to: Your message of "Mon, 13 Jan 2014 08:50:06 +0000." Date: Mon, 13 Jan 2014 15:31:04 -0500 Cc: "mpls@ietf.org" , Scott Brim , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 20:31:25 -0000 RFC5405 However, if the IP traffic in the tunnel is known to not be congestion-controlled, additional measures are RECOMMENDED in order to limit the impact of the tunneled traffic on other traffic sharing the path. RFC5405 | for tunnels carrying IP Traffic, | 3.1.3 | | SHOULD NOT perform congestion control | | | | | | for non-IP tunnels or rate not determined by traffic, | 3.1.3 | | SHOULD perform congestion control | | RECOMMENDED == SHOULD IMHO the intended usage of MPLS over UDP, like the widespread usage of PW, will not be deployed in a situation where congestion control is applicable and therefore will not be deployed with congestion control. And nothing bad will happen. If we want to define an optional congestion control in MPLS over UDP, that would meet the RFC5405 recommendation above. Curtis ps - Keep in mind that even for the case where Ethernet (L2VPN) over PW over MPLS over UDP over IP over some L2 is run, the thing run over the L2VPN Ethernet is predominantly IP. In message "Eggert, Lars" writes: --===============1602757442944542782== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D"; protocol="application/pgp-signature"; micalg=pgp-sha1 --Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi, On 2014-1-13, at 4:40, Xuxiaohu wrote: >> I don't think it's right to try to solve this in MPLS, because MPLS = is not a >> forwarding protocol - it's a connectivity protocol. right, MPLS is the wrong place to address is. The UDP encaps/decaps = function needs to have this functionality. >> In any use of UDP, congestion >> control is either left to something above UDP or ignored (left to = queue >> management). There are several cases, see Section 3.1.3 of RFC5405. MPLS-over-UDP can = fall into any of the three cases, depending on what traffic is inside = the LSP being encapsulated.=20 You'll notice that RFC5405 for the first case - encapsulation of = IP-based congestion controlled "normal" Internet traffic - even says = that the tunnel SHOULD NOT employ any congestion control scheme of its = own. Having layered control loops fighting is not productive. The issue with MPLS-in-UDP (and GRE-in-UDP, and any other encaps scheme = that can carry non-IP traffic) are with cases two and three. When the = workload that is being encapsulated isn't known to be congestion = controlled by its endpoints, it is the obligation of the tunnel to = detect congestion and react to it by reducing the traffic volume. = Because for the rest of the network, that tunnel is the UDP sender, and = we have IETF consensus that we don't want UDP senders that don't react = to congestion on the net. (That's one of the main reasons for the = existence of the RMCAT WG - we don't want non-congestion-controlled RTP = media traffic on the net.) The key difference between putting MPLS e.g. into IP compared to putting = it into UDP is that once it's in UDP, it can go pretty much anywhere on = the net, because UDP traverses NATs and firewalls much more easily than = IP traffic with a rare protocol number does. >> Similarly, you want the client of MPLS to be responsible for >> managing its traffic. MPLS gives you paths, it doesn't push packets = over them. Right. However, once you slap a UDP header on a packet during = encapsulation, you now subjected yourself to the rules for Internet UDP = senders. Those are documented in RFC5405, and require the tunnel to = implement some sort of congestion detection and control. I'd personally = consider a circuit breaker mechanism sufficient, like RTP and I think = PWE are using. > Fully agree. The congestion control should be performed either by the = UDP tunnel itself or the client of MPLS. In the former case, it'd better = to specify the practical congestion control mechanisms (if there were = any) in a generic draft (e.g., RFC5405bis) and then any use of the UDP = tunnel could refer to that generic draft with regard to congestion = control. The general concept of a circuit breaker is easy enough that it doesn't = really need to be written down. And it wouldn't be possible to describe = it in a generic fashion, because congestion detection is typically = specific to the protocol being encapsulated (e.g., RTP uses RTCP = feedback to derive loss information, etc.) And the reaction to = congestion is also dependent on the protocol being encapsulated (does it = support multiple rates or only on/off, what timescales are OK for = reaction, etc.) > In the latter case, if the client of MPLS is TCP-friendly, that is = great. Otherwise (e.g., circuit emulation service), it shouldn't be = deployed on the Internet at all, just as has been pointed out in = RFC3985, therefore there is no need for any specific congestion control = mechanism on the client. >=20 > "... In essence, this requirement states that it is > not acceptable to deploy an application (using PWE3 or any other > transport protocol) on the best-effort Internet, which consumes > bandwidth arbitrarily and does not compete fairly with TCP within an > order of magnitude." (quoted from Section 6.5 of RFC3985) >=20 > The above choice seems no conflict with the following congestion = control guidelines as quoted from Section 3.1.1 of RFC5405, as those = non-TCP-friendly traffic would be transported over a provisioned path, = rather than on the Internet. >=20 > "...Finally, some bulk transfer applications may choose not to = implement > any congestion control mechanism and instead rely on transmitting > across reserved path capacity. This might be an acceptable choice > for a subset of restricted networking environments, but is by no > means a safe practice for operation in the Internet." How is that in conflict? Both quotes say that Internet traffic needs = congestion control, which is a restatement of RFC2914. Lars --Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D 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----- iQCVAwUBUtOovdZcnpRveo1xAQICtAP+IEcc32eXYdPz7se0PX+ytfYOjHW1ExJt bF/Wc+1umMc/GXbLL9tf8fKJdSpe/+ZUhuL6WpYG9BoptbI0uCsWCCH98/WP7BUI Bzf3SgJE1Qxpv+HNXTtYV1OuKJuYxp4p6Lgujkz1aGtiT1VfpBjX7a5e2D290dCp Kwtms72DUPw= =PeLB -----END PGP SIGNATURE----- --Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D-- --===============1602757442944542782== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============1602757442944542782==-- From curtis@ipv6.occnc.com Mon Jan 13 17:33:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3EA1ADFC3; Mon, 13 Jan 2014 17:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 D_pBWGmJUxAC; Mon, 13 Jan 2014 17:33:22 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 673321A8028; Mon, 13 Jan 2014 17:33:22 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0E1Wkit084822; Mon, 13 Jan 2014 20:32:47 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401140132.s0E1Wkit084822@maildrop2.v6ds.occnc.com> To: "Joel M. Halpern" From: Curtis Villamizar In-reply-to: Your message of "Mon, 13 Jan 2014 10:51:45 -0500." <52D40B91.8040101@joelhalpern.com> Date: Mon, 13 Jan 2014 20:32:46 -0500 Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF , Scott Brim Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 01:33:25 -0000 In message <52D40B91.8040101@joelhalpern.com> "Joel M. Halpern" writes: > Lars, are you really asking that the document say: > 1) That the UDP encapsulation of MPLS can only be used when the devices > performing the encapsulation and decapsulation know what protocol (above > IP, if IP is being carried; above Ethernet and IP if the frame is > Ethernet carrying IP) is being used > 2) That those devices need to engage in a congestion control protocol if > the carried packets are not TCP, SCTP, or DCCP? > > Those both look like excessive and difficult requirements. Which is > fine if our goal is to pretend we are telling folks not to use UDP > encapsulation of MPLS. (I had not thought that was our goal.) > > In practice, I simply do not see how anyone implementing this will pay > any attention to either requirement. > > Yours, > Joel Joel, I agree that the requirement for the equipment to "know" what is in the MPLS traffic is ridiculous. A provider generally does know whether the traffic will be mostly IP or mostly PW and if PW mostly IP inside the PW. If stating that implementations SHOULD support a form of congestion control satisfies Lars, then its fine to add it. And then ignore it. Even if the document said MUST it is likely to be ignored in practice through a non-RFC compliant configuration knob. As to whether MPLS tunneled traffic in UDP could end up on the plain old Internet, that is exactly what most providers in effect do today with MPLS. The high margin legacy L2 protocols, such as TDM, ATM, FR, all ride on PW and MPLS over the very same infrastructure as plain IP. The low traffic volume high paying traffic gets queueing priority based on paying so much for it and an expectation of good or perfect service and the traffic volume is so low that the plain IP traffic doesn't notice. If a UDP and IP header got stuck in there, not much would change. And certainly any congestion control would be disabled. If OTOH, some end customer put their NFSv4 over UDP stream or their bittorrent stream over MPLS over UDP, it would behave just the same (just as badly but no worse) as plain NFSv4 over UDP over IP or plain bittorrent. No change. And the network hostile bittorrent site isn't going to enable congestion control on the UDP tunnel either. So this whole discussion is over nothing. But if putting a SHOULD in a document ends the discussion, it might be worth it. The technical sticky point is knowing that the congestion is occuring. Perhaps a LM like packet on another UDP port could be exchanged with the same caveats about inaccuracy if implemented in software and inaccuracy if reordering occurs, and a recommendation can be made to do something to introduce drop if congestion is indicated by this method. How to introduce drop should be an implementation detail, a form of AQM or leaky bucket being possible choices, but entirely a local matter. Since it is a SHOULD and if no real customer ever wants it we can all just ignore it. Curtis > On 1/13/14 3:50 AM, Eggert, Lars wrote: > > Hi, > > > > On 2014-1-13, at 4:40, Xuxiaohu wrote: > >>> I don't think it's right to try to solve this in MPLS, because > >>> MPLS is not a forwarding protocol - it's a connectivity > >>> protocol. > > > > right, MPLS is the wrong place to address is. The UDP encaps/decaps > > function needs to have this functionality. > > > >>> In any use of UDP, congestion control is either left to something > >>> above UDP or ignored (left to queue management). > > > > There are several cases, see Section 3.1.3 of RFC5405. MPLS-over-UDP > > can fall into any of the three cases, depending on what traffic is > > inside the LSP being encapsulated. > > > > You'll notice that RFC5405 for the first case - encapsulation of > > IP-based congestion controlled "normal" Internet traffic - even says > > that the tunnel SHOULD NOT employ any congestion control scheme of > > its own. Having layered control loops fighting is not productive. > > > > The issue with MPLS-in-UDP (and GRE-in-UDP, and any other encaps > > scheme that can carry non-IP traffic) are with cases two and three. > > When the workload that is being encapsulated isn't known to be > > congestion controlled by its endpoints, it is the obligation of the > > tunnel to detect congestion and react to it by reducing the traffic > > volume. Because for the rest of the network, that tunnel is the UDP > > sender, and we have IETF consensus that we don't want UDP senders > > that don't react to congestion on the net. (That's one of the main > > reasons for the existence of the RMCAT WG - we don't want > > non-congestion-controlled RTP media traffic on the net.) > > > > The key difference between putting MPLS e.g. into IP compared to > > putting it into UDP is that once it's in UDP, it can go pretty much > > anywhere on the net, because UDP traverses NATs and firewalls much > > more easily than IP traffic with a rare protocol number does. > > > >>> Similarly, you want the client of MPLS to be responsible for > >>> managing its traffic. MPLS gives you paths, it doesn't push > >>> packets over them. > > > > Right. However, once you slap a UDP header on a packet during > > encapsulation, you now subjected yourself to the rules for Internet > > UDP senders. Those are documented in RFC5405, and require the tunnel > > to implement some sort of congestion detection and control. I'd > > personally consider a circuit breaker mechanism sufficient, like RTP > > and I think PWE are using. > > > >> Fully agree. The congestion control should be performed either by > >> the UDP tunnel itself or the client of MPLS. In the former case, > >> it'd better to specify the practical congestion control mechanisms > >> (if there were any) in a generic draft (e.g., RFC5405bis) and then > >> any use of the UDP tunnel could refer to that generic draft with > >> regard to congestion control. > > > > The general concept of a circuit breaker is easy enough that it > > doesn't really need to be written down. And it wouldn't be possible > > to describe it in a generic fashion, because congestion detection is > > typically specific to the protocol being encapsulated (e.g., RTP uses > > RTCP feedback to derive loss information, etc.) And the reaction to > > congestion is also dependent on the protocol being encapsulated (does > > it support multiple rates or only on/off, what timescales are OK for > > reaction, etc.) > > > >> In the latter case, if the client of MPLS is TCP-friendly, that is > >> great. Otherwise (e.g., circuit emulation service), it shouldn't be > >> deployed on the Internet at all, just as has been pointed out in > >> RFC3985, therefore there is no need for any specific congestion > >> control mechanism on the client. > >> > >> "... In essence, this requirement states that it is not acceptable > >> to deploy an application (using PWE3 or any other transport > >> protocol) on the best-effort Internet, which consumes bandwidth > >> arbitrarily and does not compete fairly with TCP within an order of > >> magnitude." (quoted from Section 6.5 of RFC3985) > >> > >> The above choice seems no conflict with the following congestion > >> control guidelines as quoted from Section 3.1.1 of RFC5405, as > >> those non-TCP-friendly traffic would be transported over a > >> provisioned path, rather than on the Internet. > >> > >> "...Finally, some bulk transfer applications may choose not to > >> implement any congestion control mechanism and instead rely on > >> transmitting across reserved path capacity. This might be an > >> acceptable choice for a subset of restricted networking > >> environments, but is by no means a safe practice for operation in > >> the Internet." > > > > How is that in conflict? Both quotes say that Internet traffic needs > > congestion control, which is a restatement of RFC2914. > > > > Lars > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From xuxiaohu@huawei.com Mon Jan 13 19:32:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB131AD986; Mon, 13 Jan 2014 19:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.55 X-Spam-Level: * X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 FP__vBDA7iQa; Mon, 13 Jan 2014 19:32:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 83B371AD8DC; Mon, 13 Jan 2014 19:32:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCL68367; Tue, 14 Jan 2014 03:32:17 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Jan 2014 03:31:26 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Jan 2014 03:32:15 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 14 Jan 2014 11:32:10 +0800 From: Xuxiaohu To: "curtis@ipv6.occnc.com" , "Joel M. Halpern" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPEMiG7ChTi8dU4kyxN0iU+aYNwZqDihaw Date: Tue, 14 Jan 2014 03:32:09 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08244868@NKGEML512-MBS.china.huawei.com> References: Your message of "Mon, 13 Jan 2014 10:51:45 -0500." <52D40B91.8040101@joelhalpern.com> <201401140132.s0E1Wkit084822@maildrop2.v6ds.occnc.com> In-Reply-To: <201401140132.s0E1Wkit084822@maildrop2.v6ds.occnc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF , Scott Brim Subject: [mpls] =?gb2312?b?tPC4tDogIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg?= =?gb2312?b?dG8gUHJvcG9zZWQgU3RhbmRhcmQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 03:32:35 -0000 SGkgQ3VydGlzIGFuZCBKb2VsLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgZGV0YWlsZWQgY29t bWVudHMuDQoNCkhpIExhcnMsDQoNCkkgd29uZGVyIHdoZXRoZXIgdGhlIGZvbGxvd2luZyBjb21w cm9taXNlZCB0ZXh0IGZvciB0aGUgQ29uZ2VzdGlvbiBDb25zaWRlcmF0aW9uIHNlY3Rpb24gb2Yg dGhpcyBkb2MgaXMgcm91Z2hseSBhY2NlcHRhYmxlIHRvIHlvdS4NCg0KU2luY2UgdGhlIE1QTFMt aW4tVURQIGVuY2Fwc3VsYXRpb24gY2F1c2VzIE1QTFMgcGFja2V0cyB0byBiZSBmb3J3YXJkZWQg dGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGd1aWRlbGluZXMg Zm9yIFVEUCB0dW5uZWxzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuMyBvZiBbUkZDNTQwNV0g U0hPVUxEIGJlIGZvbGxvd2VkLiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5IGEgbnVtYmVy IG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMgcGF5bG9hZHMuIFdoZW4gdGhlIE1QTFMgcGF5bG9h ZCB0cmFmZmljIGlzIElQLWJhc2VkIGFuZCBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFAg dHVubmVsIFNIT1VMRCBOT1QgZW1wbG95IGl0cyBvd24gY29uZ2VzdGlvbiBjb250cm9sIG1lY2hh bmlzbSwgYmVjYXVzZSBjb25nZXN0aW9uIGxvc3NlcyBvZiB0dW5uZWxlZCB0cmFmZmljIHdpbGwg YWxyZWFkeSB0cmlnZ2VyIGFuIGFwcHJvcHJpYXRlIGNvbmdlc3Rpb24gcmVzcG9uc2UgYXQgdGhl IG9yaWdpbmFsIHNlbmRlcnMgb2YgdGhlIHR1bm5lbGVkIHRyYWZmaWMuIFdoZW4gdGhlIE1QTFMg cGF5bG9hZCB0cmFmZmljIGlzIG5vdCBrbm93biB0byBiZSBJUC1iYXNlZCwgb3IgaXMga25vd24g dG8gYmUgSVAtYmFzZWQgYnV0IG5vdCBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFAgdHVu bmVsIFNIT1VMRCBlbXBsb3kgYW4gYXBwcm9wcmlhdGUgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hh bmlzbSB3aGljaCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpCZXN0 IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBDdXJ0 aXMgVmlsbGFtaXphciBbbWFpbHRvOmN1cnRpc0BpcHY2Lm9jY25jLmNvbV0NCj4gt6LLzcqxvOQ6 IDIwMTTE6jHUwjE0yNUgOTozMw0KPiDK1bz+yMs6IEpvZWwgTS4gSGFscGVybg0KPiCzrcvNOiBF Z2dlcnQsIExhcnM7IFh1eGlhb2h1OyBtcGxzQGlldGYub3JnOyBTY290dCBCcmltOyBJRVRGDQo+ INb3zOI6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50 eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMNCj4gaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0K PiANCj4gDQo+IEluIG1lc3NhZ2UgPDUyRDQwQjkxLjgwNDAxMDFAam9lbGhhbHBlcm4uY29tPg0K PiAiSm9lbCBNLiBIYWxwZXJuIiB3cml0ZXM6DQo+IA0KPiA+IExhcnMsIGFyZSB5b3UgcmVhbGx5 IGFza2luZyB0aGF0IHRoZSBkb2N1bWVudCBzYXk6DQo+ID4gMSkgVGhhdCB0aGUgVURQIGVuY2Fw c3VsYXRpb24gb2YgTVBMUyBjYW4gb25seSBiZSB1c2VkIHdoZW4gdGhlDQo+ID4gZGV2aWNlcyBw ZXJmb3JtaW5nIHRoZSBlbmNhcHN1bGF0aW9uIGFuZCBkZWNhcHN1bGF0aW9uIGtub3cgd2hhdA0K PiA+IHByb3RvY29sIChhYm92ZSBJUCwgaWYgSVAgaXMgYmVpbmcgY2FycmllZDsgYWJvdmUgRXRo ZXJuZXQgYW5kIElQIGlmDQo+ID4gdGhlIGZyYW1lIGlzIEV0aGVybmV0IGNhcnJ5aW5nIElQKSBp cyBiZWluZyB1c2VkDQo+ID4gMikgVGhhdCB0aG9zZSBkZXZpY2VzIG5lZWQgdG8gZW5nYWdlIGlu IGEgY29uZ2VzdGlvbiBjb250cm9sIHByb3RvY29sDQo+ID4gaWYgdGhlIGNhcnJpZWQgcGFja2V0 cyBhcmUgbm90IFRDUCwgU0NUUCwgb3IgRENDUD8NCj4gPg0KPiA+IFRob3NlIGJvdGggbG9vayBs aWtlIGV4Y2Vzc2l2ZSBhbmQgZGlmZmljdWx0IHJlcXVpcmVtZW50cy4gIFdoaWNoIGlzDQo+ID4g ZmluZSBpZiBvdXIgZ29hbCBpcyB0byBwcmV0ZW5kIHdlIGFyZSB0ZWxsaW5nIGZvbGtzIG5vdCB0 byB1c2UgVURQDQo+ID4gZW5jYXBzdWxhdGlvbiBvZiBNUExTLiAgKEkgaGFkIG5vdCB0aG91Z2h0 IHRoYXQgd2FzIG91ciBnb2FsLikNCj4gPg0KPiA+IEluIHByYWN0aWNlLCBJIHNpbXBseSBkbyBu b3Qgc2VlIGhvdyBhbnlvbmUgaW1wbGVtZW50aW5nIHRoaXMgd2lsbCBwYXkNCj4gPiBhbnkgYXR0 ZW50aW9uIHRvIGVpdGhlciByZXF1aXJlbWVudC4NCj4gPg0KPiA+IFlvdXJzLA0KPiA+IEpvZWwN Cj4gDQo+IA0KPiBKb2VsLA0KPiANCj4gSSBhZ3JlZSB0aGF0IHRoZSByZXF1aXJlbWVudCBmb3Ig dGhlIGVxdWlwbWVudCB0byAia25vdyIgd2hhdCBpcyBpbiB0aGUgTVBMUw0KPiB0cmFmZmljIGlz IHJpZGljdWxvdXMuICBBIHByb3ZpZGVyIGdlbmVyYWxseSBkb2VzIGtub3cgd2hldGhlciB0aGUg dHJhZmZpYyB3aWxsIGJlDQo+IG1vc3RseSBJUCBvciBtb3N0bHkgUFcgYW5kIGlmIFBXIG1vc3Rs eSBJUCBpbnNpZGUgdGhlIFBXLg0KPiANCj4gSWYgc3RhdGluZyB0aGF0IGltcGxlbWVudGF0aW9u cyBTSE9VTEQgc3VwcG9ydCBhIGZvcm0gb2YgY29uZ2VzdGlvbiBjb250cm9sDQo+IHNhdGlzZmll cyBMYXJzLCB0aGVuIGl0cyBmaW5lIHRvIGFkZCBpdC4gIEFuZCB0aGVuIGlnbm9yZSBpdC4NCj4g DQo+IEV2ZW4gaWYgdGhlIGRvY3VtZW50IHNhaWQgTVVTVCBpdCBpcyBsaWtlbHkgdG8gYmUgaWdu b3JlZCBpbiBwcmFjdGljZSB0aHJvdWdoIGENCj4gbm9uLVJGQyBjb21wbGlhbnQgY29uZmlndXJh dGlvbiBrbm9iLg0KPiANCj4gQXMgdG8gd2hldGhlciBNUExTIHR1bm5lbGVkIHRyYWZmaWMgaW4g VURQIGNvdWxkIGVuZCB1cCBvbiB0aGUgcGxhaW4gb2xkDQo+IEludGVybmV0LCB0aGF0IGlzIGV4 YWN0bHkgd2hhdCBtb3N0IHByb3ZpZGVycyBpbiBlZmZlY3QgZG8gdG9kYXkgd2l0aCBNUExTLiAg VGhlDQo+IGhpZ2ggbWFyZ2luIGxlZ2FjeSBMMiBwcm90b2NvbHMsIHN1Y2ggYXMgVERNLCBBVE0s IEZSLCBhbGwgcmlkZSBvbiBQVyBhbmQNCj4gTVBMUyBvdmVyIHRoZSB2ZXJ5IHNhbWUgaW5mcmFz dHJ1Y3R1cmUgYXMgcGxhaW4gSVAuDQo+IFRoZSBsb3cgdHJhZmZpYyB2b2x1bWUgaGlnaCBwYXlp bmcgdHJhZmZpYyBnZXRzIHF1ZXVlaW5nIHByaW9yaXR5IGJhc2VkIG9uDQo+IHBheWluZyBzbyBt dWNoIGZvciBpdCBhbmQgYW4gZXhwZWN0YXRpb24gb2YgZ29vZCBvciBwZXJmZWN0IHNlcnZpY2Ug YW5kIHRoZQ0KPiB0cmFmZmljIHZvbHVtZSBpcyBzbyBsb3cgdGhhdCB0aGUgcGxhaW4gSVAgdHJh ZmZpYyBkb2Vzbid0IG5vdGljZS4gIElmIGEgVURQIGFuZCBJUA0KPiBoZWFkZXIgZ290IHN0dWNr IGluIHRoZXJlLCBub3QgbXVjaCB3b3VsZCBjaGFuZ2UuICBBbmQgY2VydGFpbmx5IGFueQ0KPiBj b25nZXN0aW9uIGNvbnRyb2wgd291bGQgYmUgZGlzYWJsZWQuDQo+IA0KPiBJZiBPVE9ILCBzb21l IGVuZCBjdXN0b21lciBwdXQgdGhlaXIgTkZTdjQgb3ZlciBVRFAgc3RyZWFtIG9yIHRoZWlyDQo+ IGJpdHRvcnJlbnQgc3RyZWFtIG92ZXIgTVBMUyBvdmVyIFVEUCwgaXQgd291bGQgYmVoYXZlIGp1 c3QgdGhlIHNhbWUgKGp1c3QgYXMNCj4gYmFkbHkgYnV0IG5vIHdvcnNlKSBhcyBwbGFpbiBORlN2 NCBvdmVyIFVEUCBvdmVyIElQIG9yIHBsYWluIGJpdHRvcnJlbnQuICBObw0KPiBjaGFuZ2UuICBB bmQgdGhlIG5ldHdvcmsgaG9zdGlsZSBiaXR0b3JyZW50IHNpdGUgaXNuJ3QgZ29pbmcgdG8gZW5h YmxlDQo+IGNvbmdlc3Rpb24gY29udHJvbCBvbiB0aGUgVURQIHR1bm5lbCBlaXRoZXIuDQo+IA0K PiBTbyB0aGlzIHdob2xlIGRpc2N1c3Npb24gaXMgb3ZlciBub3RoaW5nLiAgQnV0IGlmIHB1dHRp bmcgYSBTSE9VTEQgaW4gYQ0KPiBkb2N1bWVudCBlbmRzIHRoZSBkaXNjdXNzaW9uLCBpdCBtaWdo dCBiZSB3b3J0aCBpdC4gIFRoZSB0ZWNobmljYWwgc3RpY2t5IHBvaW50DQo+IGlzIGtub3dpbmcg dGhhdCB0aGUgY29uZ2VzdGlvbiBpcyBvY2N1cmluZy4gIFBlcmhhcHMgYSBMTSBsaWtlIHBhY2tl dCBvbg0KPiBhbm90aGVyIFVEUCBwb3J0IGNvdWxkIGJlIGV4Y2hhbmdlZCB3aXRoIHRoZSBzYW1l IGNhdmVhdHMgYWJvdXQgaW5hY2N1cmFjeQ0KPiBpZiBpbXBsZW1lbnRlZCBpbiBzb2Z0d2FyZSBh bmQgaW5hY2N1cmFjeSBpZiByZW9yZGVyaW5nIG9jY3VycywgYW5kIGENCj4gcmVjb21tZW5kYXRp b24gY2FuIGJlIG1hZGUgdG8gZG8gc29tZXRoaW5nIHRvIGludHJvZHVjZSBkcm9wIGlmIGNvbmdl c3Rpb24NCj4gaXMgaW5kaWNhdGVkIGJ5IHRoaXMgbWV0aG9kLiAgSG93IHRvIGludHJvZHVjZSBk cm9wIHNob3VsZCBiZSBhbg0KPiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwsIGEgZm9ybSBvZiBBUU0g b3IgbGVha3kgYnVja2V0IGJlaW5nIHBvc3NpYmxlIGNob2ljZXMsDQo+IGJ1dCBlbnRpcmVseSBh IGxvY2FsIG1hdHRlci4NCj4gU2luY2UgaXQgaXMgYSBTSE9VTEQgYW5kIGlmIG5vIHJlYWwgY3Vz dG9tZXIgZXZlciB3YW50cyBpdCB3ZSBjYW4gYWxsIGp1c3QgaWdub3JlDQo+IGl0Lg0KPiANCj4g Q3VydGlzDQo+IA0KPiANCj4gPiBPbiAxLzEzLzE0IDM6NTAgQU0sIEVnZ2VydCwgTGFycyB3cm90 ZToNCj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+IE9uIDIwMTQtMS0xMywgYXQgNDo0MCwgWHV4aWFv aHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ID4+PiBJIGRvbid0IHRoaW5rIGl0 J3MgcmlnaHQgdG8gdHJ5IHRvIHNvbHZlIHRoaXMgaW4gTVBMUywgYmVjYXVzZQ0KPiA+ID4+PiBN UExTIGlzIG5vdCBhIGZvcndhcmRpbmcgcHJvdG9jb2wgLSBpdCdzIGEgY29ubmVjdGl2aXR5IHBy b3RvY29sLg0KPiA+ID4NCj4gPiA+IHJpZ2h0LCBNUExTIGlzIHRoZSB3cm9uZyBwbGFjZSB0byBh ZGRyZXNzIGlzLiBUaGUgVURQIGVuY2Fwcy9kZWNhcHMNCj4gPiA+IGZ1bmN0aW9uIG5lZWRzIHRv IGhhdmUgdGhpcyBmdW5jdGlvbmFsaXR5Lg0KPiA+ID4NCj4gPiA+Pj4gSW4gYW55IHVzZSBvZiBV RFAsIGNvbmdlc3Rpb24gY29udHJvbCBpcyBlaXRoZXIgbGVmdCB0byBzb21ldGhpbmcNCj4gPiA+ Pj4gYWJvdmUgVURQIG9yIGlnbm9yZWQgKGxlZnQgdG8gcXVldWUgbWFuYWdlbWVudCkuDQo+ID4g Pg0KPiA+ID4gVGhlcmUgYXJlIHNldmVyYWwgY2FzZXMsIHNlZSBTZWN0aW9uIDMuMS4zIG9mIFJG QzU0MDUuIE1QTFMtb3Zlci1VRFANCj4gPiA+IGNhbiBmYWxsIGludG8gYW55IG9mIHRoZSB0aHJl ZSBjYXNlcywgZGVwZW5kaW5nIG9uIHdoYXQgdHJhZmZpYyBpcw0KPiA+ID4gaW5zaWRlIHRoZSBM U1AgYmVpbmcgZW5jYXBzdWxhdGVkLg0KPiA+ID4NCj4gPiA+IFlvdSdsbCBub3RpY2UgdGhhdCBS RkM1NDA1IGZvciB0aGUgZmlyc3QgY2FzZSAtIGVuY2Fwc3VsYXRpb24gb2YNCj4gPiA+IElQLWJh c2VkIGNvbmdlc3Rpb24gY29udHJvbGxlZCAibm9ybWFsIiBJbnRlcm5ldCB0cmFmZmljIC0gZXZl biBzYXlzDQo+ID4gPiB0aGF0IHRoZSB0dW5uZWwgU0hPVUxEIE5PVCBlbXBsb3kgYW55IGNvbmdl c3Rpb24gY29udHJvbCBzY2hlbWUgb2YNCj4gPiA+IGl0cyBvd24uIEhhdmluZyBsYXllcmVkIGNv bnRyb2wgbG9vcHMgZmlnaHRpbmcgaXMgbm90IHByb2R1Y3RpdmUuDQo+ID4gPg0KPiA+ID4gVGhl IGlzc3VlIHdpdGggTVBMUy1pbi1VRFAgKGFuZCBHUkUtaW4tVURQLCBhbmQgYW55IG90aGVyIGVu Y2Fwcw0KPiA+ID4gc2NoZW1lIHRoYXQgY2FuIGNhcnJ5IG5vbi1JUCB0cmFmZmljKSBhcmUgd2l0 aCBjYXNlcyB0d28gYW5kIHRocmVlLg0KPiA+ID4gV2hlbiB0aGUgd29ya2xvYWQgdGhhdCBpcyBi ZWluZyBlbmNhcHN1bGF0ZWQgaXNuJ3Qga25vd24gdG8gYmUNCj4gPiA+IGNvbmdlc3Rpb24gY29u dHJvbGxlZCBieSBpdHMgZW5kcG9pbnRzLCBpdCBpcyB0aGUgb2JsaWdhdGlvbiBvZiB0aGUNCj4g PiA+IHR1bm5lbCB0byBkZXRlY3QgY29uZ2VzdGlvbiBhbmQgcmVhY3QgdG8gaXQgYnkgcmVkdWNp bmcgdGhlIHRyYWZmaWMNCj4gPiA+IHZvbHVtZS4gQmVjYXVzZSBmb3IgdGhlIHJlc3Qgb2YgdGhl IG5ldHdvcmssIHRoYXQgdHVubmVsIGlzIHRoZSBVRFANCj4gPiA+IHNlbmRlciwgYW5kIHdlIGhh dmUgSUVURiBjb25zZW5zdXMgdGhhdCB3ZSBkb24ndCB3YW50IFVEUCBzZW5kZXJzDQo+ID4gPiB0 aGF0IGRvbid0IHJlYWN0IHRvIGNvbmdlc3Rpb24gb24gdGhlIG5ldC4gKFRoYXQncyBvbmUgb2Yg dGhlIG1haW4NCj4gPiA+IHJlYXNvbnMgZm9yIHRoZSBleGlzdGVuY2Ugb2YgdGhlIFJNQ0FUIFdH IC0gd2UgZG9uJ3Qgd2FudA0KPiA+ID4gbm9uLWNvbmdlc3Rpb24tY29udHJvbGxlZCBSVFAgbWVk aWEgdHJhZmZpYyBvbiB0aGUgbmV0LikNCj4gPiA+DQo+ID4gPiBUaGUga2V5IGRpZmZlcmVuY2Ug YmV0d2VlbiBwdXR0aW5nIE1QTFMgZS5nLiBpbnRvIElQIGNvbXBhcmVkIHRvDQo+ID4gPiBwdXR0 aW5nIGl0IGludG8gVURQIGlzIHRoYXQgb25jZSBpdCdzIGluIFVEUCwgaXQgY2FuIGdvIHByZXR0 eSBtdWNoDQo+ID4gPiBhbnl3aGVyZSBvbiB0aGUgbmV0LCBiZWNhdXNlIFVEUCB0cmF2ZXJzZXMg TkFUcyBhbmQgZmlyZXdhbGxzIG11Y2gNCj4gPiA+IG1vcmUgZWFzaWx5IHRoYW4gSVAgdHJhZmZp YyB3aXRoIGEgcmFyZSBwcm90b2NvbCBudW1iZXIgZG9lcy4NCj4gPiA+DQo+ID4gPj4+IFNpbWls YXJseSwgeW91IHdhbnQgdGhlIGNsaWVudCBvZiBNUExTIHRvIGJlIHJlc3BvbnNpYmxlIGZvcg0K PiA+ID4+PiBtYW5hZ2luZyBpdHMgdHJhZmZpYy4gTVBMUyBnaXZlcyB5b3UgcGF0aHMsIGl0IGRv ZXNuJ3QgcHVzaA0KPiA+ID4+PiBwYWNrZXRzIG92ZXIgdGhlbS4NCj4gPiA+DQo+ID4gPiBSaWdo dC4gSG93ZXZlciwgb25jZSB5b3Ugc2xhcCBhIFVEUCBoZWFkZXIgb24gYSBwYWNrZXQgZHVyaW5n DQo+ID4gPiBlbmNhcHN1bGF0aW9uLCB5b3Ugbm93IHN1YmplY3RlZCB5b3Vyc2VsZiB0byB0aGUg cnVsZXMgZm9yIEludGVybmV0DQo+ID4gPiBVRFAgc2VuZGVycy4gVGhvc2UgYXJlIGRvY3VtZW50 ZWQgaW4gUkZDNTQwNSwgYW5kIHJlcXVpcmUgdGhlIHR1bm5lbA0KPiA+ID4gdG8gaW1wbGVtZW50 IHNvbWUgc29ydCBvZiBjb25nZXN0aW9uIGRldGVjdGlvbiBhbmQgY29udHJvbC4gSSdkDQo+ID4g PiBwZXJzb25hbGx5IGNvbnNpZGVyIGEgY2lyY3VpdCBicmVha2VyIG1lY2hhbmlzbSBzdWZmaWNp ZW50LCBsaWtlIFJUUA0KPiA+ID4gYW5kIEkgdGhpbmsgUFdFIGFyZSB1c2luZy4NCj4gPiA+DQo+ ID4gPj4gRnVsbHkgYWdyZWUuIFRoZSBjb25nZXN0aW9uIGNvbnRyb2wgc2hvdWxkIGJlIHBlcmZv cm1lZCBlaXRoZXIgYnkNCj4gPiA+PiB0aGUgVURQIHR1bm5lbCBpdHNlbGYgb3IgdGhlIGNsaWVu dCBvZiBNUExTLiBJbiB0aGUgZm9ybWVyIGNhc2UsDQo+ID4gPj4gaXQnZCBiZXR0ZXIgdG8gc3Bl Y2lmeSB0aGUgcHJhY3RpY2FsIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc21zDQo+ID4gPj4g KGlmIHRoZXJlIHdlcmUgYW55KSBpbiBhIGdlbmVyaWMgZHJhZnQgKGUuZy4sIFJGQzU0MDViaXMp IGFuZCB0aGVuDQo+ID4gPj4gYW55IHVzZSBvZiB0aGUgVURQIHR1bm5lbCBjb3VsZCByZWZlciB0 byB0aGF0IGdlbmVyaWMgZHJhZnQgd2l0aA0KPiA+ID4+IHJlZ2FyZCB0byBjb25nZXN0aW9uIGNv bnRyb2wuDQo+ID4gPg0KPiA+ID4gVGhlIGdlbmVyYWwgY29uY2VwdCBvZiBhIGNpcmN1aXQgYnJl YWtlciBpcyBlYXN5IGVub3VnaCB0aGF0IGl0DQo+ID4gPiBkb2Vzbid0IHJlYWxseSBuZWVkIHRv IGJlIHdyaXR0ZW4gZG93bi4gQW5kIGl0IHdvdWxkbid0IGJlIHBvc3NpYmxlDQo+ID4gPiB0byBk ZXNjcmliZSBpdCBpbiBhIGdlbmVyaWMgZmFzaGlvbiwgYmVjYXVzZSBjb25nZXN0aW9uIGRldGVj dGlvbiBpcw0KPiA+ID4gdHlwaWNhbGx5IHNwZWNpZmljIHRvIHRoZSBwcm90b2NvbCBiZWluZyBl bmNhcHN1bGF0ZWQgKGUuZy4sIFJUUA0KPiA+ID4gdXNlcyBSVENQIGZlZWRiYWNrIHRvIGRlcml2 ZSBsb3NzIGluZm9ybWF0aW9uLCBldGMuKSBBbmQgdGhlDQo+ID4gPiByZWFjdGlvbiB0byBjb25n ZXN0aW9uIGlzIGFsc28gZGVwZW5kZW50IG9uIHRoZSBwcm90b2NvbCBiZWluZw0KPiA+ID4gZW5j YXBzdWxhdGVkIChkb2VzIGl0IHN1cHBvcnQgbXVsdGlwbGUgcmF0ZXMgb3Igb25seSBvbi9vZmYs IHdoYXQNCj4gPiA+IHRpbWVzY2FsZXMgYXJlIE9LIGZvciByZWFjdGlvbiwgZXRjLikNCj4gPiA+ DQo+ID4gPj4gSW4gdGhlIGxhdHRlciBjYXNlLCBpZiB0aGUgY2xpZW50IG9mIE1QTFMgaXMgVENQ LWZyaWVuZGx5LCB0aGF0IGlzDQo+ID4gPj4gZ3JlYXQuIE90aGVyd2lzZSAoZS5nLiwgY2lyY3Vp dCBlbXVsYXRpb24gc2VydmljZSksIGl0IHNob3VsZG4ndCBiZQ0KPiA+ID4+IGRlcGxveWVkIG9u IHRoZSBJbnRlcm5ldCBhdCBhbGwsIGp1c3QgYXMgaGFzIGJlZW4gcG9pbnRlZCBvdXQgaW4NCj4g PiA+PiBSRkMzOTg1LCB0aGVyZWZvcmUgdGhlcmUgaXMgbm8gbmVlZCBmb3IgYW55IHNwZWNpZmlj IGNvbmdlc3Rpb24NCj4gPiA+PiBjb250cm9sIG1lY2hhbmlzbSBvbiB0aGUgY2xpZW50Lg0KPiA+ ID4+DQo+ID4gPj4gIi4uLiBJbiBlc3NlbmNlLCB0aGlzIHJlcXVpcmVtZW50IHN0YXRlcyB0aGF0 IGl0IGlzIG5vdCBhY2NlcHRhYmxlDQo+ID4gPj4gdG8gZGVwbG95IGFuIGFwcGxpY2F0aW9uICh1 c2luZyBQV0UzIG9yIGFueSBvdGhlciB0cmFuc3BvcnQNCj4gPiA+PiBwcm90b2NvbCkgb24gdGhl IGJlc3QtZWZmb3J0IEludGVybmV0LCB3aGljaCBjb25zdW1lcyBiYW5kd2lkdGgNCj4gPiA+PiBh cmJpdHJhcmlseSBhbmQgZG9lcyBub3QgY29tcGV0ZSBmYWlybHkgd2l0aCBUQ1Agd2l0aGluIGFu IG9yZGVyIG9mDQo+ID4gPj4gbWFnbml0dWRlLiIgKHF1b3RlZCBmcm9tIFNlY3Rpb24gNi41IG9m IFJGQzM5ODUpDQo+ID4gPj4NCj4gPiA+PiBUaGUgYWJvdmUgY2hvaWNlIHNlZW1zIG5vIGNvbmZs aWN0IHdpdGggdGhlIGZvbGxvd2luZyBjb25nZXN0aW9uDQo+ID4gPj4gY29udHJvbCBndWlkZWxp bmVzIGFzIHF1b3RlZCBmcm9tIFNlY3Rpb24gMy4xLjEgb2YgUkZDNTQwNSwgYXMNCj4gPiA+PiB0 aG9zZSBub24tVENQLWZyaWVuZGx5IHRyYWZmaWMgd291bGQgYmUgdHJhbnNwb3J0ZWQgb3ZlciBh DQo+ID4gPj4gcHJvdmlzaW9uZWQgcGF0aCwgcmF0aGVyIHRoYW4gb24gdGhlIEludGVybmV0Lg0K PiA+ID4+DQo+ID4gPj4gIi4uLkZpbmFsbHksIHNvbWUgYnVsayB0cmFuc2ZlciBhcHBsaWNhdGlv bnMgbWF5IGNob29zZSBub3QgdG8NCj4gPiA+PiBpbXBsZW1lbnQgYW55IGNvbmdlc3Rpb24gY29u dHJvbCBtZWNoYW5pc20gYW5kIGluc3RlYWQgcmVseSBvbg0KPiA+ID4+IHRyYW5zbWl0dGluZyBh Y3Jvc3MgcmVzZXJ2ZWQgcGF0aCBjYXBhY2l0eS4gIFRoaXMgbWlnaHQgYmUgYW4NCj4gPiA+PiBh Y2NlcHRhYmxlIGNob2ljZSBmb3IgYSBzdWJzZXQgb2YgcmVzdHJpY3RlZCBuZXR3b3JraW5nDQo+ ID4gPj4gZW52aXJvbm1lbnRzLCBidXQgaXMgYnkgbm8gbWVhbnMgYSBzYWZlIHByYWN0aWNlIGZv ciBvcGVyYXRpb24gaW4NCj4gPiA+PiB0aGUgSW50ZXJuZXQuIg0KPiA+ID4NCj4gPiA+IEhvdyBp cyB0aGF0IGluIGNvbmZsaWN0PyBCb3RoIHF1b3RlcyBzYXkgdGhhdCBJbnRlcm5ldCB0cmFmZmlj IG5lZWRzDQo+ID4gPiBjb25nZXN0aW9uIGNvbnRyb2wsIHdoaWNoIGlzIGEgcmVzdGF0ZW1lbnQg b2YgUkZDMjkxNC4NCj4gPiA+DQo+ID4gPiBMYXJzDQo+ID4gPg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbXBscyBtYWlsaW5nIGxpc3QN Cj4gPiBtcGxzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo= From y-iizawa@cd.jp.nec.com Tue Jan 14 00:30:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4A1AE0A5 for ; Tue, 14 Jan 2014 00:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, 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 TzcjUalIphfz for ; Tue, 14 Jan 2014 00:30:03 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id A33491ADF72 for ; Tue, 14 Jan 2014 00:30:03 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id s0E8Tq2M015119 for ; Tue, 14 Jan 2014 17:29:52 +0900 (JST) Received: from mailsv.nec.co.jp (imss63.nec.co.jp [10.7.69.158]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id s0E8Tpm29710 for ; Tue, 14 Jan 2014 17:29:51 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id s0E8Tpet008391 for ; Tue, 14 Jan 2014 17:29:51 +0900 (JST) Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.131] [10.38.151.131]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-208859; Tue, 14 Jan 2014 17:29:21 +0900 Received: from BPXM02GP.gisp.nec.co.jp ([169.254.1.234]) by BPXC03GP.gisp.nec.co.jp ([10.38.151.131]) with mapi id 14.02.0328.011; Tue, 14 Jan 2014 17:29:20 +0900 From: Yohei Iizawa To: "mpls@ietf.org" Thread-Topic: iPOP2014 CFP Thread-Index: Ac8RAVgSwzDlgQ8+Txuauj0Pmra44Q== Date: Tue, 14 Jan 2014 08:29:19 +0000 Message-ID: <6D8CC8EB7FE4C444B73DF64E761A0DCC1D547099@BPXM02GP.gisp.nec.co.jp> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.56.47.179] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] iPOP2014 CFP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 08:30:05 -0000 (Apologies if you received multiple copies of this message.) Dear MPLS subscribers, iPOP2014 Call for Presentation is now open as follows. The deadline for submitting presentation proposal is February 7th, 2014. Best Regards, iPOP2014 TPC secretary Yohei Iizawa --------------------------------------------------------------------- Call for Presentation 10th International Conference on IP + Optical Network (iPOP 2014) May 22-23, 2014 NTT R&D center Musashino, Tokyo, Japan http://www.pilab.jp/ipop2014/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 7, 2014=20 Notification of acceptance: March 24, 2014 Submission deadline of final presentation slides: April 11, 2014 The Technical Program Committee for iPOP 2014 is soliciting presentation=20 proposals for this conference. Protocol design, experiment, theory,=20 implementation, and operational experiences are solicited. The topics of the conference will include but not be limited to the followi= ng: - Photonic network for NxGN and NwGN - Multi-Layer Network (MLN)/Multi-Region Network (MRN) - Inter-area/inter-AS network - Software Defined Networking (SDN) - Software Defined Optics (SDO) and its network application - SDN network services and monetization=20 - Open Source Software (OSS) activities for SDN - Network virtualization=20 - Data center and WAN orchestration - Path Computation Element (PCE) and traffic engineering - GMPLS/ASON technologies - Application with high-bandwidth demand - L0-L3 Virtual Private Network (VPN) - MPLS and Ethernet networking for inter-data center connectivity for cloud computing - Carrier Ethernet and MPLS-TP for backhauling - Optical networking/switching for cloud services - Testbed, field trial If you wish to submit a topic for consideration, please send an Extended=20 Abstracts of 400 words and a maximum of 1 page, including figures and=20 diagrams, speaker's name, affiliation, and contact information=20 to the Technical Program Committee at ipop2014-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2014/ for more details. ---------------------------------------------------------------------------= ---- From l.wood@surrey.ac.uk Tue Jan 14 00:33:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEA31AE01D; Tue, 14 Jan 2014 00:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 iU0vtlwPB9Fu; Tue, 14 Jan 2014 00:33:06 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF011ACCE9; Tue, 14 Jan 2014 00:33:05 -0800 (PST) Received: from [195.245.230.131:6188] by server-4.bemta-3.messagelabs.com id 3D/0C-10414-536F4D25; Tue, 14 Jan 2014 08:32:53 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-6.tower-78.messagelabs.com!1389688372!33605148!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23810 invoked from network); 14 Jan 2014 08:32:52 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-6.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 14 Jan 2014 08:32:52 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Tue, 14 Jan 2014 08:32:52 +0000 From: To: , , Date: Tue, 14 Jan 2014 08:28:05 +0000 Thread-Topic: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8OGeG46c8oWHrkQO+L1tKxoi92vgC6Kp6g Message-ID: <290E20B455C66743BE178C5C84F1240847E63346C3@EXMB01CMS.surrey.ac.uk> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com>, <52D01383.2080509@joelhalpern.com> In-Reply-To: <52D01383.2080509@joelhalpern.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 08:33:09 -0000 SXQgc3RhbmRzIHRvIHJlYXNvbiB0aGF0IGlmIHR1bm5lbGVycyBjYW4gdHVybiBvZmYgdWRwIGNo ZWNrc3Vtcw0KYmVjYXVzZSB0aGVpciBwZXJmb3JtYW5jZSBpcyBkZWdyYWRlZCwgdGhleSBjYW4g dHVybiBvZmYNCmNvbmdlc3Rpb24gY29udHJvbCBiZWNhdXNlIGl0IHdpbGwgZGVncmFkZSB0aGVp ciBwZXJmb3JtYW5jZS4NCg0KUmVzdCBvZiB0aGUgaW50ZXJuZXQgZ2V0dGluZyBjb25nZXN0ZWQg YW5kIGdldHRpbmcNCm1pc2RlbGl2ZXJlZCBjb3JydXB0ZWQgcGFja2V0cz8gUmVhbGx5IG5vdCB0 aGVpciBwcm9ibGVtLg0KDQpUaGVyZSBhcmUgaW1wb3J0YW50IHZlbmRvcnMgdHJ5aW5nIHRvIHNl bGwgcHJvZHVjdHMgaGVyZSwNCmFuZCB0aGV5IG5lZWQgcGVyZm9ybWFuY2UgdG8gZG8gc28uDQpH ZXQgd2l0aCB0aGUgcHJvZ3JhbSENCg0KTGxveWQgV29vZA0KaHR0cDovL2Fib3V0Lm1lL2xsb3lk d29vZA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogaWV0 ZiBbaWV0Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuIFtq bWhAam9lbGhhbHBlcm4uY29tXQ0KU2VudDogMTAgSmFudWFyeSAyMDE0IDE1OjM2DQpUbzogRWdn ZXJ0LCBMYXJzOyBYdXhpYW9odQ0KQ2M6IG1wbHNAaWV0Zi5vcmc7IElFVEYNClN1YmplY3Q6IFJl OiBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRp bmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCk1heWJlIEkgYW0gY29tcGxl dGVseSBtaXNzaW5nIHRoaW5ncywgYnV0IHRoaXMgbG9va3Mgd3JvbmcuDQpJZiB0aGUgTVBMUyBM U1AgaXMgY2FycnlpbmcgZml4ZWQgcmF0ZSBwc2V1ZG8td2lyZXMsIGFkZGluZyBjb25nZXN0aW9u DQpjb250cm9sIHdpbGwgbWFrZSBpdCBtb3JlIGxpa2VseSB0aGF0IHRoZSBzZXJ2aWNlIHdvbid0 IHdvcmsuICBJcyB0aGF0DQpyZWFsbHkgdGhlIGdvYWw/DQoNCldlIGRvIG5vdCBwZXJmb3JtIGNv bmdlc3Rpb24gY29udHJvbCBvbiBNUExTIExTUHMuDQpBc3N1bWluZyB0aGF0IGEgVURQIHR1bm5l bCBpcyBjYXJyeWluZyBqdXN0IE1QTFMgYW5kIHdhcyBlc3RhYmxpc2hlZA0KanVzdCBmb3IgTVBM Uywgd2h5IHdvdWxkIHdlIGV4cGVjdCBpdCB0byBiZWhhdmUgZGlmZmVyZW50bHkgdGhhbiBhbiBN UExTDQpMU1AgcnVubmluZyBvdmVyIHRoZSBleGFjdCBzYW1lIHBhdGgsIGNhcnJ5aW5nIHRoZSBl eGFjdCBzYW1lIHRyYWZmaWM/DQoNCllvdXJzLA0KSm9lbA0KDQpPbiAxLzEwLzE0IDM6NDcgQU0s IEVnZ2VydCwgTGFycyB3cm90ZToNCj4gSGksDQo+DQo+IHRoYXQgc291bmRzIGdvb2QuIFdoYXQg Y29uZ2VzdGlvbiBjb250cm9sIGFyZSB5b3UgZ29pbmcgdG8gYmUgc3BlY2lmeWluZyBmb3IgeW91 ciB0dW5uZWw/DQo+DQo+IExhcnMNCj4NCj4gT24gMjAxNC0xLTEwLCBhdCA0OjQ2LCBYdXhpYW9o dSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+DQo+PiBIaSBMYXJzLA0KPj4NCj4+IFRo YW5rcyBhIGxvdCBmb3IgeW91ciBjb21tZW50cy4NCj4+DQo+PiBJIHdvbmRlciB3aGV0aGVyIHRo ZSBmb2xsb3dpbmcgbW9kaWZpZWQgdGV4dCBmb3IgQ29uZ2VzdGlvbiBDb25zaWRlcmF0aW9uIHNl Y3Rpb24gaXMgT0sgZnJvbSB5b3VyIHBvaW50IG9mIHZpZXc6DQo+Pg0KPj4gU2luY2UgdGhlIE1Q TFMtaW4tVURQIGVuY2Fwc3VsYXRpb24gY2F1c2VzIE1QTFMgcGFja2V0cyB0byBiZSBmb3J3YXJk ZWQgdGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGd1aWRlbGlu ZXMgZm9yIFVEUCB0dW5uZWxzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuMyBvZiBbUkZDNTQw NV0gU0hPVUxEIGJlIGZvbGxvd2VkLiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5IGEgbnVt YmVyIG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMgcGF5bG9hZHMuIFdoZW4gdGhlIHBheWxvYWQg dHJhZmZpYyBpcyBJUC1iYXNlZCBhbmQgY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUgVURQIHR1 bm5lbCBTSE9VTEQgTk9UIGVtcGxveSBpdHMgb3duIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5p c20sIGJlY2F1c2UgY29uZ2VzdGlvbiBsb3NzZXMgb2YgdHVubmVsZWQgdHJhZmZpYyB3aWxsIGFs cmVhZHkgdHJpZ2dlciBhbiBhcHByb3ByaWF0ZSBjb25nZXN0aW9uIHJlc3BvbnNlIGF0IHRoZSBv cmlnaW5hbCBzZW5kZXJzIG9mIHRoZSB0dW5uZWxlZCB0cmFmZmljLiBXaGVuIHRoZSBwYXlsb2Fk IHRyYWZmaWMgaXMgbm90IGtub3duIHRvIGJlIElQLWJhc2VkLCBvciBpcyBrbm93biB0byBiZSBJ UC1iYXNlZCBidXQgbm90IGNvbmdlc3Rpb24tY29udHJvbGxlZCwgdGhlIFVEUCB0dW5uZWwgU0hP VUxEIGVtcGxveSBhbiBhcHByb3ByaWF0ZSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLiBG dXJ0aGVybW9yZSwgYmVjYXVzZSBVRFAgdHVubmVscyBhcmUgdXN1YWxseSBidWxrLXRyYW5zZmVy IGFwcGxpY2F0aW9ucyBhcyBmYXIgYXMgdGhlIGludGVybWVkaWF0ZSByb3V0ZXJzIGFyZSBjb25j ZXJuZWQsIHRoZSBndWlkZWxpbmVzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuMSBvZiBbUkZD NTQwNV0gU0hPVUxEIGFwcGx5Lg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+IFhpYW9odQ0KPj4N Cj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4+PiC3orz+yMs6IG1wbHMgW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gRWdnZXJ0LCBMYXJzDQo+Pj4gt6LLzcqxvOQ6IDIwMTTE6jHU wjjI1SAxODoyMg0KPj4+IMrVvP7IyzogSUVURg0KPj4+ILOty806IG1wbHNAaWV0Zi5vcmcNCj4+ PiDW98ziOiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQu dHh0PiAoRW5jYXBzdWxhdGluZyBNUExTDQo+Pj4gaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFy ZA0KPj4+DQo+Pj4gSGksDQo+Pj4NCj4+PiBPbiAyMDE0LTEtMiwgYXQgMTY6MTQsIFRoZSBJRVNH IDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4gd3JvdGU6DQo+Pj4+IC0gJ0VuY2Fwc3VsYXRpbmcg TVBMUyBpbiBVRFAnDQo+Pj4+IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gYXMgUHJv cG9zZWQgU3RhbmRhcmQNCj4+Pg0KPj4+DQo+Pj4gdGhpcyBkb2N1bWVudCBuZWVkcyB0byBkZXNj cmliZSBob3cgaXQgYWRkcmVzc2VzIHRoZSBpc3N1ZXMgcmFpc2VkIGluIEJDUDE0NQ0KPj4+IChS RkM1NDA1KS4gSXQgYWxyZWFkeSBjb250YWlucyBzb21lIHRleHQgYWJvdXQgbWVzc2FnZXMgc2l6 ZXMgYW5kIGNvbmdlc3Rpb24NCj4+PiBjb25zaWRlcmF0aW9ucywgd2hpY2ggaXMgZ3JlYXQuIFVu Zm9ydHVuYXRlbHksIHRoZSB0ZXh0IGFib3V0IGNvbmdlc3Rpb24NCj4+PiBjb25zaWRlcmF0aW9u cyBpcyBub3QgZnVsbHkgaW4gbGluZSB3aXRoIFJGQzU0MDUuDQo+Pj4NCj4+PiBMYXJzDQo+DQo= From stbryant@cisco.com Tue Jan 14 03:00:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BBC1AE091; Tue, 14 Jan 2014 03:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 uXw20RAIqpte; Tue, 14 Jan 2014 03:00:57 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id AD4EB1AE088; Tue, 14 Jan 2014 03:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=236; q=dns/txt; s=iport; t=1389697246; x=1390906846; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/PtE82acgaZJPm2WLe90D+x7T9KcTUuw1MCaN8Tx2oI=; b=S6eN/nSpuCDwhx+PGPRO46Q1QDa+WC+A7OPRCrNdp6MH+Xt3ZcR+bwtd P5Hy3/Ngn4qm0lmJrF7ZHdz8vPWyY4bPM1OZsYeGvIHGDoufEnR7UE2aw TrVcln28JM+mdESPH4e4cp9+7MiCfQtoFERvsyfb9g6QRfkVmo3GQBPit g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FANMX1VKQ/khR/2dsb2JhbABagwu7YIESFnSCJQEBAQQ4QAEQCxgJFgQLCQMCAQIBRQYBDAEFAgEBiADFRhePBweENwEDmB6SFYFvgT4 X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="2934106" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 14 Jan 2014 11:00:44 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0EB0iUm030735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 11:00:44 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0EB0fEC009012; Tue, 14 Jan 2014 11:00:42 GMT Message-ID: <52D518D9.7010703@cisco.com> Date: Tue, 14 Jan 2014 11:00:41 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Scott Brim , "Joel M. Halpern" References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 11:00:58 -0000 On 13/01/2014 19:09, Scott Brim wrote: > On Mon, Jan 13, 2014 at 10:51 AM, Joel M. Halpern wrote: > I'm concerned about TCP-over-X.25 scenarios. ... and how many b/s of that exist in the universe! Stewart From mark.tinka@seacom.mu Tue Jan 14 04:32:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABFA1AE0A8 for ; Tue, 14 Jan 2014 04:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 Pmjx9Vr0Igoa for ; Tue, 14 Jan 2014 04:32:21 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 09A151AE0BC for ; Tue, 14 Jan 2014 04:32:17 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W3396-0008Te-Fq; Tue, 14 Jan 2014 14:31:04 +0200 From: Mark Tinka Organization: SEACOM To: curtis@ipv6.occnc.com Date: Tue, 14 Jan 2014 14:31:00 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <201401132004.s0DK4DFO080786@maildrop2.v6ds.occnc.com> In-Reply-To: <201401132004.s0DK4DFO080786@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart66180887.yt9NZmRRKX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401141431.03808.mark.tinka@seacom.mu> Cc: "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 12:32:23 -0000 --nextPart66180887.yt9NZmRRKX Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Monday, January 13, 2014 10:04:13 PM Curtis Villamizar=20 wrote: > Perhaps someone needs to explain to you what a FEC is and > how MPLS traffic is routed in most LDP networks. Thanks for the 101, Curtis, but I think I'm doing alright=20 :-). Again, my input is rooted in operational situations that=20 I've experienced, present and past (I'm neither a vendor nor=20 a software developer): J's implementation of LDP treats LDP much like a routing=20 protocol (unlike C's implementation). In such cases, LDP-derived routing has a discrete routing=20 table different from the global routing table. Under certain=20 conditions (design or code), there could be a mis-alignment=20 between what LDP thinks is the best path vs. what the IGP=20 thinks is the best path. A knob exists within J's LDP implementation to synchronize=20 LDP and the IGP (i.e., the LDP and IGP metric is always the=20 same). Such a knob does not exist (AFAIK) with C because C=20 don't treat LDP like a routing protocol. Without this LDP=20 knob enabled in J's implementation (which is the default=20 case), LDP routes always retain a metric of 1, regardless of=20 the route and regardless of what the IGP metric is. I concede that this case may not be the norm when taking all=20 vendor implementations into account, but then again, my=20 experience is restricted to C and J. Mark. --nextPart66180887.yt9NZmRRKX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS1S4HAAoJEGcZuYTeKm+GeB4P/1SUWSQ9GDjij+npE6QrEfFb yCO2saxRtB8VCjtmXcEMFNz/BmwsIPxHm1W7P2srrYmY4r2XbHqO+Q8XFMKGzFF1 OZfrFr3BIReavyX3MS8RrWPvVQZTOSt1gguUOjFtotNjhJ83ofhOPVK5bMqlLvI6 lM5xH0dN9FoDnqqHck7yx9spzA1nWvlI6FUhOqR/WsziNqpvhJfc90P5KxoBpLVn RZemvyVZtorcSaAFEhDjzPDuZGlhzMAKFDHHPGpQ/SnSDS44Tv/fYm5KEvv8aqKS 4Da6urmc3J+dwrgwwrOKquKJB5c5QMJxhRWOtI3kIyGzZuTFyY/t5X5GH/epmdvl i6cOgiX7l5bvPB8IKsHab10whHUAeJA8rUZYl0Cyhs29VYsInIw5p4gSUb0k2lOP /L9ZznaArgbRC3Am3gYpV8rdBln0Vrua1dsarlg4n/ljccFNvLtXxQNRwa5jlATr 4mQr5eLqIjE8F8DqDLaUb+4P+s94NbvPm2UG0agtoElAj2W6RW61BxJMrp2gkZi+ XYSk6kRgkLJX/WFNWuL55q6/KzYyltNv2GvEDO/EwekK9e8KVHs69qP3p/Akl5UI 8JlwZYZXDUawDL32Rk8T41uug3UP17JFLg7P2U1cOOEIooTR0tHGJmbqvRaNXfei itWGI7pV2xljUprCwcls =vs3d -----END PGP SIGNATURE----- --nextPart66180887.yt9NZmRRKX-- From scott.brim@gmail.com Tue Jan 14 05:12:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276F01AE0D2; Tue, 14 Jan 2014 05:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5HCmf6PJhQP; Tue, 14 Jan 2014 05:11:57 -0800 (PST) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C66EE1AE0D1; Tue, 14 Jan 2014 05:11:49 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id l6so9507208oag.23 for ; Tue, 14 Jan 2014 05:11:38 -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=26v0ajTFWiDpEIK5le1Spsm0vQYR1AbrRr6GeKfRa5c=; b=s8ch4Xo2M9/nrfir6BxgTMfsoNU2h3pYpHOIewwaJcNua0kJBVRyfoB+3g/zMjEjya pbJKE35LN1KY9Am/h0WZj8KTDBUh33Xoe4+7VcktZ6QQiGWTZMaVsvDOz49Dj89T4xrR ockbJU15HOjG4h5WTo8XlcMknRWtxh4OfbBTPhmwxDBDmu21Ex/QyZhUfszIuMLlww54 j5xc9N63VS8luliGcHzTNnmvLXeeq0su9aWF963KMVpopw+4AdYcmID8HCgwKoM1/s7y NCrj5C/BKlSLCIB4U5Xd/RhhqH4X65SPQ5lE7pGKgQi36KC5c7VrOsxKlWKJ1Egpn7qD STkA== MIME-Version: 1.0 X-Received: by 10.60.174.167 with SMTP id bt7mr1019432oec.54.1389705098259; Tue, 14 Jan 2014 05:11:38 -0800 (PST) Received: by 10.182.48.9 with HTTP; Tue, 14 Jan 2014 05:11:38 -0800 (PST) Received: by 10.182.48.9 with HTTP; Tue, 14 Jan 2014 05:11:38 -0800 (PST) In-Reply-To: <52D518D9.7010703@cisco.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> Date: Tue, 14 Jan 2014 08:11:38 -0500 Message-ID: From: Scott Brim To: Stewart Bryant Content-Type: multipart/alternative; boundary=047d7bd6c03eb9759f04efedee24 Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:12:02 -0000 --047d7bd6c03eb9759f04efedee24 Content-Type: text/plain; charset=ISO-8859-1 On Jan 14, 2014 6:00 AM, "Stewart Bryant" wrote: > > On 13/01/2014 19:09, Scott Brim wrote: >> >> On Mon, Jan 13, 2014 at 10:51 AM, Joel M. Halpern wrote: >> I'm concerned about TCP-over-X.25 scenarios. > > ... and how many b/s of that exist in the universe! Stewart: none that I know of, of course, but it was in production at a significant time in Internet history and was one of our first experiences with multiple layers each trying to provide transport control and thereby destroying goodput. I'll never forget it. When I think of two layers each trying to do congestion management, with no way to coordinate with each other, that's the first example that comes to mind. Scott --047d7bd6c03eb9759f04efedee24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jan 14, 2014 6:00 AM, "Stewart Bryant" <stbryant@cisco.com> wrote:
>
> On 13/01/2014 19:09, Scott Brim wrote:
>>
>> On Mon, Jan 13, 2014 at 10:51 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>> I'm concerned about TCP-over-X.25 scenarios.
>
> ... and how many b/s of that exist in the universe!

Stewart: none that I know of, of course, but it was in produ= ction at a significant time in Internet history and was one of our first ex= periences with multiple layers each trying to provide transport control and= thereby destroying goodput. I'll never forget it. When I think of two = layers each trying to do congestion management,=A0 with no way to coordinat= e with each other, that's the first example that comes to mind.

Scott

--047d7bd6c03eb9759f04efedee24-- From farinacci@gmail.com Sun Jan 12 13:37:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6C11AE013; Sun, 12 Jan 2014 13:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNZFc2qXT733; Sun, 12 Jan 2014 13:37:15 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1F34B1ADFF3; Sun, 12 Jan 2014 13:37:15 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb1so303109pad.38 for ; Sun, 12 Jan 2014 13:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Hy0NAgTRz5/l6EPUl9CUfcPwWnRgwo5S+Vd1yW7irlc=; b=c8QwbDetVyvewmjJIiDiUYhvNHCiLfTxZB7CtqMNvpxZxqmYZkYKl84QQFvqtEEe0t 7dzxqYXB/uW/eFmIioRTk426DyS+ueO/YgRHQVZFXXsGW/gTaTvfe6TglpQiHi3kLTHE 3NFrhiSIxOvk8jbcZRl81d3/QSmmnOfRjbMPBPmI8wsT+T/hkEKJfxHFsh25wap674HF iuM+H4Hixw9gpGMLwVrHz3KpTGiz+CmSnx4ET7cYaFcDyaScl/TrwoKQyJWEi1i6bdWN xYOoUieMBixPWhu+Aoe1JuneE/h4qmMMrjm5j4J1GvsUzklLeBIN3n6XEaNT30Yu+9s7 6O1w== X-Received: by 10.66.136.107 with SMTP id pz11mr26215058pab.118.1389562624528; Sun, 12 Jan 2014 13:37:04 -0800 (PST) Received: from [192.168.1.15] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id sy10sm42330439pac.15.2014.01.12.13.37.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Jan 2014 13:37:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11B554a) In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346BE@EXMB01CMS.surrey.ac.uk> Date: Sun, 12 Jan 2014 13:37:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com> <012801cf0d24$9b80b180$d2821480$@olddog.co.uk> <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> <201401121426.23719.mark.tinka@seacom.mu> <290E20B455C66743BE178C5C84F1240847E63346BE@EXMB01CMS.surrey.ac.uk> To: "" X-Mailman-Approved-At: Tue, 14 Jan 2014 05:28:39 -0800 Cc: "" , "ietf@ietf.org" , "lisp@ietf.org" , "gorry@erg.abdn.ac.uk" , "david.black@emc.com" , "randy@psg.com" , "jnc@mit.edu" , "tsvwg@ietf.org" Subject: Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 21:37:16 -0000 > Do any routers count TCP/UDP checksum failures, much less > expose the count via SNMP? Typically they do but only for packets destined to them. Much like hosts wou= ld check the header checksum.=20 Dino= From gorry@erg.abdn.ac.uk Mon Jan 13 12:32:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0031AE000; Mon, 13 Jan 2014 12:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 DqlW6hSFAr4Q; Mon, 13 Jan 2014 12:31:56 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB0B1AE1A0; Mon, 13 Jan 2014 12:31:56 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8F1972B41C8; Mon, 13 Jan 2014 20:31:43 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 13 Jan 2014 20:31:43 -0000 Message-ID: In-Reply-To: <201401131911.s0DJBC1o079251@maildrop2.v6ds.occnc.com> References: <201401131911.s0DJBC1o079251@maildrop2.v6ds.occnc.com> Date: Mon, 13 Jan 2014 20:31:43 -0000 From: gorry@erg.abdn.ac.uk To: curtis@ipv6.occnc.com User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Tue, 14 Jan 2014 05:28:38 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, farinacci@gmail.com, jnc@mit.edu, ietf@ietf.org Subject: Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 20:32:00 -0000 > > One of the reasons that IPv6 (rfc2460) dropped the header checksum > that was in IPv4 is that with link layers all doing FCS it served no > purpose. > For the same reason TCP and UDP checksums server no purpose. > That's not what I understood, it is needed for endpoint delivery verification. But in this case, TCP & UDP checksums incorporate the IP address info in the pseudo header, and this was thought sufficient. > The link layer checksum fails and the packet is dropped. Since this > is usually not at the last hop (often a local Ethernet) but instead in > a WAN link, the packet never arrives at the destination for anything > to count IP header or TCP or UDP checksum errors. > Again, that presumes that everything above the link works flawlessly, which isn't always the case. > Also all of the following handle both data integrity and congestion > avoidance the same way: > > UDP over IP over Ethernet > UDP over IP over MPLS over Ethernet > UDP over IP over MPLS over UDP over IP over Ethernet > s/Ethernet/{POS,GFP,etc}/ for all of the above > s/^UDP over IP/PW/ for all of the above > > In all of the above cases data integrity is handled by the link layer. > In all of the above cases congestion avoidance is handled by the > application (or not at all). Whether MPLS is carried directly over a > link layer or over UDP/IP over a link layer makes no difference. > RFC 6936 section 3.1 says more about what happens when packets happen to be mis-delivered to the wrong host or socket. > Curtis > Gorry > In message > <290E20B455C66743BE178C5C84F1240847E63346BF@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > >> Really, you'd want to expose the pseudoheader check at endhosts; a >> well-instrumented Linux box could tell you a lot >> about checksum failures. >> >> But in this case, a router would be decapping UDP/MPLS tunnels as an >> endpoint, so could report on checksum failures - >> if the checksum wasn't zero. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Dino Farinacci [farinacci@gmail.com] >> Sent: 12 January 2014 21:37 >> To: Wood L Dr (Electronic Eng) >> Cc: ; ; gorry@erg.abdn.ac.uk; >> lisp@ietf.org; david.black@emc.com; randy@psg.com; tsvwg@ietf.org; >> jnc@mit.edu; ietf@ietf.org >> Subject: Re: [lisp] [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp >> draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) >> >> > Do any routers count TCP/UDP checksum failures, much less >> > expose the count via SNMP? >> >> Typically they do but only for packets destined to them. Much like hosts >> would check the header checksum. >> >> Dino >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From mkonstan@cisco.com Tue Jan 14 05:33:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2201AE0D9 for ; Tue, 14 Jan 2014 05:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.439 X-Spam-Level: X-Spam-Status: No, score=-9.439 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_35=0.6, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 WcWTmOeudkWz for ; Tue, 14 Jan 2014 05:33:05 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 353531AE055 for ; Tue, 14 Jan 2014 05:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14069; q=dns/txt; s=iport; t=1389706374; x=1390915974; h=from:to:cc:subject:date:message-id:references: in-reply-to:reply-to:content-id:content-transfer-encoding: mime-version; bh=//35RbvyVoqyRbJnqAih9b1+sC8smKqvH7CSPoaTg0E=; b=BZy0eb6zuPWplAhitonrWVAyY47hEuOgy2P61FoYbu6XQOJEtx8f6bRz tKc/2xZzj0QYCEwNMxxBfdeCEmLdXOZeqWuaVRIQR94F/KfrgZaEaKnTt Lat9xJk8p9IZ7Zd6QDN1rQlwixAbRsSpPoiZxrArSVDUb+fK/OUgUNhmK E=; X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="12722196" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-2.cisco.com with ESMTP; 14 Jan 2014 13:32:53 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0EDWrUt032434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 13:32:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.165]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 07:32:53 -0600 From: "Maciek Konstantynowicz (mkonstan)" To: Curtis Villamizar Thread-Topic: [mpls] Still open: working group lst call on draft-ietf-mpls-seamless-mpls Thread-Index: AQHPEJ39DWlOvSXkY0qTgSKWAAnxh5qEnZWA Date: Tue, 14 Jan 2014 13:32:53 +0000 Message-ID: <7C35CD44-6E5D-4E6D-9518-451BFAB424D6@cisco.com> References: <201310151709.r9FH98ts055454@gateway1.ipv6.occnc.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.98.226] Content-Type: text/plain; charset="us-ascii" Content-ID: <5CC99408F7ACBD4CACBDB6BDC8E9A305@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-seamless-mpls.all@tools.ietf.org" Subject: Re: [mpls] Still open: working group lst call on draft-ietf-mpls-seamless-mpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "maciek@cisco.com" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:33:09 -0000 Curtis, All, Please ignore the text I mis-quoted from Bruno below. I should not have don= e it - I apologise. The actual response to this point is: IPR #686 is applicable to RFC5283, and not to this draft. To our knowledge there is no other IPR related to this draft, apart from t= he ones that have been already disclosed. I replaced the original text accordingly. Hope this does address all concer= ned. /maciek On 13 Jan 2014, at 20:28, Maciek Konstantynowicz wrote= : > Curtis, >=20 > Pls see our comments inline, and let us know your thoughts. > We have also posted updated ID. >=20 > On 15 Oct 2013, at 18:09, Curtis Villamizar wrote: >=20 >>=20 >> Loa, >>=20 >> No details are given in IPR #686 (applicable to RFC 5283) for the >> "Reasonable and Non-Discriminatory License to All Implementers with >> Possible Royalty/Fee." At the very least, some terms should be given. >=20 > Update from Bruno in addition to the email he sent on > Date: 16 October 2013 08:43:46 GMT+01:00 >=20 >=20 IPR #686 is applicable to RFC5283, and not to this draft. To our knowledge there is no other IPR related to this draft, apart from t= he ones that have been already disclosed. >=20 >>=20 >> IPR #1920 and #2212 do provide details. >>=20 >> An alternate to the use of a prefix based LDP LSP is to use a prefix >> based RSVP-TE LSP and carry the individual end-to-end LSP within it. >> This is not mentioned in the draft. See below for details. >=20 > The use cases, proposed design and protocol choices have been driven by > the actual SP deployments. >=20 > Design based on the hierarchy of RSVP-TE LSPs may address the listed use > cases. However the labeled BGP design with LDP DoD has been chosen due > to the higher degree of out-of-the-box automation and operational > simplicity as well as compatibility with the existing backbone and > backhaul designs & deployments which use LDP and not RSVP-TE. >=20 > It also assumes relatively simple MPLS implementations on access nodes - > RFC 7032 goes into much more detail there. >=20 >>=20 >> Scaling numbers are given as: >>=20 >> Number of Aggregation Domains: 100 >> Number of Backbone Nodes: 1.000 >> Number of Aggregation Nodes: 10.000 >> Number of Access Nodes: 100.000 >>=20 >> This section should state that very sparse connectivity among the set >> of access nodes is expected. For exampls, you would not expect each >> access node to have an LSP to every other access node. Is so, more >> than 10 such access nodes aggregated prior to a prefix based LSP would >> exceed the limits of the MPLS 20 bit label space. >=20 > The requirement was to cater for service connectivity over transport > LSPs per scaling numbers provided for listed deployment use cases. The > required design was not to restrict the LSP based connectivity between > the access, aggregation and backbone nodes, catering equally well for > sparse and dense connectivity, but not the full-mesh. Full-mesh > connectivity between between all ANs will require each AN maintaining > LSP that they initiate and terminate, complicating the AN > implementation.=20 > Luckily this is not the case in the listed use cases and the actual > access deployments. >=20 >=20 > The result is the seamless MPLS design specified in this draft. And it > does work for dense transport LSP connectivity between the access nodes > without exhausting the MPLS 20-bit label space on any of the nodes by > relying on LSP hierarchy provided by labeled BGP for inter-domain > connectivity. >=20 > See section 5.2 for scalability analysis, and numerical examples for > access node connectivity in section 5.2.1.5. >=20 >>=20 >> On the other hand it would not be unreasonable to expect each of the >> 10,000 aggregation nodes to be fully meshed or at least very densely >> meshed. This can also create problems without some form of >> aggregation as a worst case graph cut set with 5000 nodes on each side >> would have 25,000,000 LSP. A cutset of 2-5 nodes (typical core) could >> not support this (exceeds the 20 bit label space) without aggregation. >=20 > We read your comment "without some form of aggregation" as meaning > "without some form of hierarchy". > If so, indeed this is why specified design used LSP hierarchy per > earlier comment. >=20 >>=20 >> Some indication of how dense or sparse the connectivity would be >> useful in this section (2.1. Why Seamless MPLS). =20 >=20 > Indicative access node level connectivity has been described in section > 5.2 Scalability Analysis, but we agree that it makes sense to give an > indication in section 2.1 >=20 > Following text added in section 2.1: >=20 > Multiple Service Providers plan to deploy networks with 10k to 100k MPLS > nodes, with varying levels of MPLS LSP connectivity between those nodes > - sparse-mesh in access, partial-mesh in aggregation and full-mesh in > core. This is typically at least one order of magnitude higher than > typical deployments and may require a new architecture. >=20 >> It may be worth >> creating a new subsection (2.2 Scaling Goals) and going into a little >> more detail. >=20 > We believe this comment is addressed by above addition in section 2.1 > and section 5.2. Scalability Analysis. Let us know if this does address > your comment. >=20 >>=20 >> Then there is the question as to whether this draft should even go >> forward at all. >=20 > Can you pls be more specific why you don't see this draft proceeding ? >=20 > There are production implementation by both vendors and providers of > Seamless MPLS design as specified in this draft. >=20 >>=20 >> It is worth noting that a full mesh of 10.000 RSVP-TE LSP is feasible >> using hierarch. Within the core of 100 nodes, PSC-4 can be used. >> Each of the 1,000 backbone nodes can create a PSC-3 LSP to each other >> backbone node (using above terminology, "edge" nodes in more common >> core-edge-access or core-edge-aggregation-access terminology). If on >> average there are 10 backbone nodes per core node pair, then each core >> node has on the order of 10,000 ILM entries (about 20,000 if you >> consider 50 pairs of core nodes, each serving 20 nodes). There are >> only 100 LSP from each core node facing the core side, so FRR can be >> very effectively deployed. The same holds for a full mesh of the >> 10.000 aggregation nodes. If each of the 1,000 backbone nodes are >> deployed in pairs serving on average 20 nodes per pair, then an ILM >> siz on the order of 200,000 is needed. The PSC-3 LSP used to reach >> the far side backbone node can be used, yielding only 1,000 LSP facing >> the core per backbone node. Again, FRR can be used, with the protect >> path using the alternate core node of the designated pair. >>=20 >> In this scenarion the access nodes may or may not be full meshed. If >> they are full meshed, then they need to be able to support 100,000 DoD >> mode LSP. If the are more sparsely meshed, they can support a lower >> number of DoD mode LSP. >=20 > We do not disagree that alternative design approach based on RFC 4206 > and related h-LSP RFCs may be applied to address the LSP connectivity in > this environment. >=20 > However we believe the design specified in the Seamless MPLS draft > better meets described requirements including better deployment > flexibility, better scaling and easier troubleshooting. >=20 >>=20 >> If RSVP-TE is used in this way, there is no need for aggregating LDP >> LSP. The LDP LSP are aggregated into RSVP-TE LSP and further >> aggregated in PSC-3 LSP and PSC-4 LSP in tiers closer to the core. >=20 > The draft does not propose aggregating LDP LSPs. In fact the design > enables the operator to choose the transport LSP signalling protocol, > LDP or RSVP-TE, per domain, per section 4.4. Intra-Domain Routing. >=20 >>=20 >> There are ultimate scaling limits to either approach, imposed by the >> 20 bit label space. If a full mesh is needed at a given tier T with N >> nodes, then the nodes in tier T-1 aggregating tier T needs an ILM size >> of N times the number of T nodes the T-1 node serves. So for example, >> with a full mesh of 100,000 tier T nodes if each tier T-1 node could >> aggregate 8 tier T nodes without exceeding the 20 bit label space size >> (ILM=3D800,000 in this case), but could not aggregate 20 tier T nodes >> (ILM=3D2,000,000). If using RSVP-TE in the core, the core is limited by >> the worst case cut set, but core sizes of on the order of hundreds are >> OK (but smaller is better). >=20 > In line with your comments the scaling limits are imposed not only by > MPLS 20-bit label space, but also by the number of supported LFIB > entries on specific MPLS node. >=20 > Design in this draft relies on labeled BGP control plane to scale the > MPLS label distribution and to optimize the MPLS data plane on ABR nodes > by installing only the local labelled routes in its LFIB, as described > in section 5.1.7. >=20 >>=20 >> Using either RSVP-TE or LDP for aggregation the outermost T-max tier >> could have a million nodes or more as long as they were sufficiently >> sparsely connected. This limit is independent of whether aggregation >> is via LDP or RSVP-TE. >=20 > Similarly, the scale of the design in this draft is restricted by the > scale of AN at the outskirts of the MPLS network and their connectivity > needs driving the scale of neighbouring AGNs. >=20 >>=20 >> With RSVP-TE used for aggregation, T-LDP is used among the sparse mesh >> in the outermost T-max tier. A T-LDP session is only needed if FEC >> information needs to be exchanged via LDP to support an underlying >> service, otherwise RSVP-TE alone could be used. Using T-LDP the >> number of T-LDP TCP sessions could be a limiting factor for very >> highly connected tier T-max nodes. Either TCB state or the 16 bit TCP >> port limit could be the limit depending on how much RAM the T-max node >> has. OTOH if a tier T-max node out on the fringes is supporting on >> the order of 50K T-LDP sessions, it can use multiple IP addresses to >> get around the 16 bit TCP port number issue. >=20 > In the draft, labeled BGP is used for labeled routes, providing excellent > scaling properties in the control plane. >=20 >>=20 >> LDP could be extended to avoid the need for T-LDP sessions using LDP >> distribution of labels that will make use of RSVP-TE LSP. A DoD >> request would normally create a series of label bindings and swaps. >> If a full mesh of RSVP-TE LSP is know to exist within a prefix (ie: >> tier T), then the LSR can return a mapping of FEC,label,addr with its >> address. This mapping can be passed back and at each hop that >> actually does have a direct path to that address the mapping can be >> installed and the RSVP-TE LSP used as an outer label, even if there is >> no T-LDP session to that address. (btw- AFAIK no such extension >> exists, I'd be happy to be wrong about that). >>=20 >> IMHO using RSPV-TE is a viable and IMHO better solution for the >> problem posed in this draft. =20 >=20 > It is opinion of the authors of this draft and WG members supporting > this draft that the design described in the draft is more optimal for > scaling MPLS into large access and aggregation deployments compared to > RSVP-TE with hierarchical LSPs. The draft also efficiently accommodates > capabilities of access device and the operational aspects. >=20 >> It is also not encumbered by IPR AFAIK. >=20 > IPRs are provided on non-discriminatory terms, per IETF standard. >=20 >>=20 >> I don't think the draft provides a good solution. >=20 > Per earlier note, the design specified by this draft has been accepted > by number of operators for production deployments. >=20 > /maciek >=20 >>=20 >> Curtis >>=20 >>=20 >>=20 >> In message <525CD992.2020800@pi.nu> >> Loa Andersson writes: >>=20 >> Working Group, >>=20 >> I'll will keep this wglc open until October 21st, there are several >> reasons. >>=20 >> - the subject line did not explicitly say that this was a working group >> last call >> - we had a very late IPR disclosure, and we are still looking into that. >> We should like to draw the attention to the expectation that IPRs >> need to be disclosed in a timely fashion after your name appears on >> on a document, we are talking days or weeks, rather than months; and >> certainly not years >> - we have not seen any comments on the list, we are therefore now also >> asking if there is support to progress the draft. >>=20 >> /Loa >>=20 >>=20 >>=20 >> On 2013-09-26 13:37, Loa Andersson wrote: >>> Working Group, >>>=20 >>> this is to start a two week+ working group last call on >>> draft-ietf-mpls-seamless-mpls-05. >>>=20 >>> Please send your comment to working group mailing lists (mpls@ietf.org)= . >>>=20 >>> We did an IPR poll on this document prior to starting the wglc. >>> All the authors responded to the IPR poll that they are not aware of >>> any IPR's relating to this document other than the one already >>> disclosed. >>>=20 >>> There are no IPRs disclosed directly against this document, disclosure >>> #1920 was disclosed against an earlier individual version of the >>> document. >>>=20 >>> It has also been pointed out that one of the components in the Seamless >>> MPLS architecture is derived from RFC 5283 and that IPR disclosures >>> # 686 and # 853 are applicable. >>>=20 >>> The working group last call will end Friday October 11, 2913. >>>=20 >>> /Loa >>=20 >> --=20 >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 From scott.brim@gmail.com Tue Jan 14 05:53:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44A31AE067; Tue, 14 Jan 2014 05:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBxxQKrIyaTW; Tue, 14 Jan 2014 05:53:05 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0521ADFF8; Tue, 14 Jan 2014 05:53:04 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id va2so1594234obc.36 for ; Tue, 14 Jan 2014 05:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R9WF7lpqrHz3yUu/yk2w6R6UPhTp6zscBTqQRiySacA=; b=q3i1c7mmDf/VmKxR6QRZlKh5ZED3IQjWcFhdWBkq2Nwt7toCFw3DWVdZdgXSE9AUJt w7S8aKuFO76kaJ938QqcE+HdyBjB9vdecrPjZaURljI/Xc4PufJzJf90tfIYSJQlIqSy HcQEsDse/2YVFo3YwSZ1XLO1Gm3MBzX6a7qk2QSt6xGOAoh2AC3WAkwBdLnvtlxec4DF xHHjKzQ+hwwg1g1HuKZgGeX6IGvSownMv8jfJh3xb78hSfptdUA9fkJreNz1XH14tj0B 3g7MBwxvSDyBCPgOd24joQlaal6J+laJlrXJLNi6T68XFGcFMizNpRA/O7U4o6i5QIC5 tTvw== X-Received: by 10.60.50.202 with SMTP id e10mr1126423oeo.39.1389707573469; Tue, 14 Jan 2014 05:52:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Tue, 14 Jan 2014 05:52:33 -0800 (PST) In-Reply-To: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> From: Scott Brim Date: Tue, 14 Jan 2014 08:52:33 -0500 Message-ID: To: Stewart Bryant Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:53:06 -0000 Now that I'm at a real keyboard, and since at least one person didn't get what I was trying to say with my reference, let me try to explain more clearly. Transport is pretty arcane. We sometimes get it more or less right when we're dealing with a single instance of it in endpoints and routers/switches. In this case, if we add congestion management to the encapsulating UDP, we have two possible instances of the same function stacked on top of each other, where each has no way of knowing whether the other exists, if so what it's doing, or if there's any way to communicate with it. We have examples in the past where we have got this badly wrong. IMHO this is more likely to be a problem than not. The best architectural answer I can think of in this case is the one with the least surprises built in: treat the lower level UDP as just an encapsulation, not an intelligent transport protocol. Yes there should be scope for congestion management but that is higher up, where the endpoints come in to play. Scott On Tue, Jan 14, 2014 at 8:11 AM, Scott Brim wrote: > > On Jan 14, 2014 6:00 AM, "Stewart Bryant" wrote: >> >> On 13/01/2014 19:09, Scott Brim wrote: >>> >>> On Mon, Jan 13, 2014 at 10:51 AM, Joel M. Halpern >>> wrote: >>> I'm concerned about TCP-over-X.25 scenarios. >> >> ... and how many b/s of that exist in the universe! > > Stewart: none that I know of, of course, but it was in production at a > significant time in Internet history and was one of our first experiences > with multiple layers each trying to provide transport control and thereby > destroying goodput. I'll never forget it. When I think of two layers each > trying to do congestion management, with no way to coordinate with each > other, that's the first example that comes to mind. > > Scott From stbryant@cisco.com Tue Jan 14 06:18:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB721ADFB6; Tue, 14 Jan 2014 06:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 Ua1uMtRFCfyR; Tue, 14 Jan 2014 06:18:02 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 94CBA1AE0CC; Tue, 14 Jan 2014 06:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1432; q=dns/txt; s=iport; t=1389709071; x=1390918671; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xplMTCVHK+awtKhL4j4qiFjX/qRtqYJJ+mcb0t8TCPQ=; b=MuL0HLKsGkW5uirCYPkznboY49qOHPXgW1qQEDK9jvECFkZim4P5dFQj gYywe5wX3lfnKFI3dNFamUDHbJVbDZhWgxMvrEYJqm/AxRzXdIMbZ45kw qgFso1FA2vyhLudcRmcx+rG63QMVHt7/jE5OTI6tBoaMTFmxkuBSDuwgP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FACVG1VKQ/khL/2dsb2JhbABaDoJ9uFeDDoESFnSCJgEBBDhAARALIRYECwkDAgECAUUHDAEHAQGIAMQrF48HB4Q3AQOYHpIVgW9/Pw X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="3611960" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 14 Jan 2014 14:17:49 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0EEHnZI012590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 14:17:49 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0EEHkTl019554; Tue, 14 Jan 2014 14:17:47 GMT Message-ID: <52D5470A.9020002@cisco.com> Date: Tue, 14 Jan 2014 14:17:46 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, curtis@ipv6.occnc.com References: Your message of "Sun, 12 Jan 2014 02:59:41 +0000." <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk>, <201401121809.s0CI91Y1053969@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:18:04 -0000 Lloyd I have just read the Stone paper and I have some significant concerns about its validity with modern h/w. Certainly it is hard to credit the notion that the error rate is in the range 1:1000 to 1:32000 as reported by the authors. The paper was written in 2000 with hardware that would have have been designed in the mid 1990s. In that era, h/w was far more marginal, with performance traded against signal integrity, and indeed a lot less signal integrity measurement and simulation took place at both board and chip level. This was also the era where metastability was just beginning to become widely understood, and its lack of understanding would be a possible source of DMA errors. I therefore do not think we should place much reliance on this paper, but should instead look at the rather more modern statistics. Such statistics ought to be readily available by looking at the tcp/udp c/s error stats in hosts and routers. As a tiny and perhaps erroneous sample I looked at three Macs in the office here and the tcp c/s error stats were 313/29144518, 0/3000000, 0/5000000. Only one of those three systems got within a factor of 3 of the lowest error rate reported by Stone. Bottom line, it seems that we could use more recent data and then an understanding of how important these low background error rates are in the tunneling application that we are considering here. - Stewart From stbryant@cisco.com Tue Jan 14 06:20:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6481AE077; Tue, 14 Jan 2014 06:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 26nHzKMCFeqz; Tue, 14 Jan 2014 06:20:48 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 509C11ADF76; Tue, 14 Jan 2014 06:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2209; q=dns/txt; s=iport; t=1389709237; x=1390918837; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YfXKPYRmwa5C/SxBI42KrVL1fSEBROnNPAWLSGBzDSg=; b=K9FwSFl2rYx9UNldm1n4+1TgdgxVSUuY1T8GfP0NVPlUm6I1yNgFxyA8 ++OcBv80itD9RO9LC2gxDXDzlvSSJuEZqTZISsM4+xcLEvFd79mBD3EFz ChmPg5zj6p2TqIBnaKntmyyQfRyfrX7tDxPUfdyHAngWkOCQ/bDvRNUvt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAEtH1VKQ/khR/2dsb2JhbABagws4uyyBEhZ0giUBAQEEOEABEAsYCRYECwkDAgECAQ82Bg0BBQIBAYdsAxENvmoNhR0XjHSCEweENwSWMoFsjFqFO4FvgT4 X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="3612131" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 14 Jan 2014 14:20:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0EEKaKO029154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 14:20:36 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0EEKY8s019773; Tue, 14 Jan 2014 14:20:34 GMT Message-ID: <52D547B2.1060302@cisco.com> Date: Tue, 14 Jan 2014 14:20:34 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Scott Brim References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:20:50 -0000 Yes, the inner (real) transport header is the only meaningful place to apply congestion avoidance. Stewart On 14/01/2014 13:52, Scott Brim wrote: > Now that I'm at a real keyboard, and since at least one person didn't > get what I was trying to say with my reference, let me try to explain > more clearly. > > Transport is pretty arcane. We sometimes get it more or less right > when we're dealing with a single instance of it in endpoints and > routers/switches. In this case, if we add congestion management to the > encapsulating UDP, we have two possible instances of the same function > stacked on top of each other, where each has no way of knowing whether > the other exists, if so what it's doing, or if there's any way to > communicate with it. We have examples in the past where we have got > this badly wrong. IMHO this is more likely to be a problem than not. > > The best architectural answer I can think of in this case is the one > with the least surprises built in: treat the lower level UDP as just > an encapsulation, not an intelligent transport protocol. Yes there > should be scope for congestion management but that is higher up, where > the endpoints come in to play. > > Scott > > On Tue, Jan 14, 2014 at 8:11 AM, Scott Brim wrote: >> On Jan 14, 2014 6:00 AM, "Stewart Bryant" wrote: >>> On 13/01/2014 19:09, Scott Brim wrote: >>>> On Mon, Jan 13, 2014 at 10:51 AM, Joel M. Halpern >>>> wrote: >>>> I'm concerned about TCP-over-X.25 scenarios. >>> ... and how many b/s of that exist in the universe! >> Stewart: none that I know of, of course, but it was in production at a >> significant time in Internet history and was one of our first experiences >> with multiple layers each trying to provide transport control and thereby >> destroying goodput. I'll never forget it. When I think of two layers each >> trying to do congestion management, with no way to coordinate with each >> other, that's the first example that comes to mind. >> >> Scott > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From lars@netapp.com Tue Jan 14 07:20:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9D91AE026; Tue, 14 Jan 2014 07:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.44 X-Spam-Level: X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 rFw3jrPCtiB8; Tue, 14 Jan 2014 07:20:31 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id E85B21ADFB6; Tue, 14 Jan 2014 07:20:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,658,1384329600"; d="asc'?scan'208";a="136895002" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 14 Jan 2014 07:20:18 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 07:20:18 -0800 From: "Eggert, Lars" To: Stewart Bryant Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAD31WAgABWjoCAAHXQgIAAN0wAgAEJtoCAACSXAIAAC26AgAAH1ACAABCuAA== Date: Tue, 14 Jan 2014 15:20:17 +0000 Message-ID: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> In-Reply-To: <52D547B2.1060302@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_13952AFE-BD28-4845-B407-D230F9474A8E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , Scott Brim , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:20:35 -0000 --Apple-Mail=_13952AFE-BD28-4845-B407-D230F9474A8E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On 2014-1-14, at 15:20, Stewart Bryant wrote: > Yes, the inner (real) transport header is the only meaningful place > to apply congestion avoidance. But what if the inner traffic isn't congestion controlled? Lars --Apple-Mail=_13952AFE-BD28-4845-B407-D230F9474A8E 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----- iQCVAwUBUtVVsdZcnpRveo1xAQJ1VAQAhxkwT+JiRKtboCUq5m++eRzf2BWOY+EM EKCyI4ec05hvp4GAfHLZbbhyphMTCEN0WjFkToXQx4Tr8/a4VF85s8ct9QZvXcNd ZnFPFW09w4jrMrgkabZN2KRvhNoyMGcRaTIjputkE4bOaeM6ivikUnD/CFDcfmwn dHedORaWP8Q= =HC0h -----END PGP SIGNATURE----- --Apple-Mail=_13952AFE-BD28-4845-B407-D230F9474A8E-- From jmh@joelhalpern.com Tue Jan 14 07:24:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEEB1ADFB6; Tue, 14 Jan 2014 07:24:28 -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 Pr7SUocXc_io; Tue, 14 Jan 2014 07:24:26 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A08111ADFAA; Tue, 14 Jan 2014 07:24:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9EE901BD695C; Tue, 14 Jan 2014 07:24:15 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 4824E1BD6957; Tue, 14 Jan 2014 07:24:07 -0800 (PST) Message-ID: <52D5568F.2070600@joelhalpern.com> Date: Tue, 14 Jan 2014 10:23:59 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Eggert, Lars" , Stewart Bryant References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , Scott Brim , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:24:29 -0000 Isn't that basically the problem of the inner traffic sender, not the problem of the tunnel that is carrying the traffic? Asking tunnel's to solve the problem of applications with undesirable behavior seems backwards. Yours, Joel On 1/14/14 10:20 AM, Eggert, Lars wrote: > On 2014-1-14, at 15:20, Stewart Bryant wrote: >> Yes, the inner (real) transport header is the only meaningful place >> to apply congestion avoidance. > > But what if the inner traffic isn't congestion controlled? > > Lars > From lars@netapp.com Tue Jan 14 07:29:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C861AE0FB; Tue, 14 Jan 2014 07:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 ftKSLCV8Zdhz; Tue, 14 Jan 2014 07:29:51 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id A2B001AE0FA; Tue, 14 Jan 2014 07:29:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,658,1384329600"; d="asc'?scan'208";a="95978130" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 14 Jan 2014 07:29:39 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 07:29:39 -0800 From: "Eggert, Lars" To: Joel Halpern Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAD31WAgABWjoCAAHXQgIAAN0wAgAEJtoCAACSXAIAAC26AgAAH1ACAABCuAIAAAQqAgAABkYA= Date: Tue, 14 Jan 2014 15:29:38 +0000 Message-ID: <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> In-Reply-To: <52D5568F.2070600@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_366B3B18-1301-40E5-9069-EBD52038CD8A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , Scott Brim , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:29:52 -0000 --Apple-Mail=_366B3B18-1301-40E5-9069-EBD52038CD8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 2014-1-14, at 16:23, Joel M. Halpern wrote: > Isn't that basically the problem of the inner traffic sender, not the = problem of the tunnel that is carrying the traffic? no, because the sender of the inner traffic may be blasting some L2 = traffic, for an L2 where that is OK behavior. But that traffic is now = being encapsulated inside UDP and can hence go anywhere on the net = *without the sender being aware of this*. > Asking tunnel's to solve the problem of applications with undesirable = behavior seems backwards. It is the *tunnel* that performs the encapsulation and allows that = traffic to go places it couldn't before. And so it's the tunnel's = responsibility to make sure that the traffic it injects into the = Internet complies with the BCPs we have on congestion control. Lars --Apple-Mail=_366B3B18-1301-40E5-9069-EBD52038CD8A 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----- iQCVAwUBUtVX39ZcnpRveo1xAQJ0AgP/RUgABtrQKRfecW3gluWKiGeCCbPpbZN6 XnNk5HxFonwIqbBIks+LzLPUHdMs2cu2R6pgz+WBGjduBBto4acZQK9+kDaW5PCl MtbLJPa26wtsKpQSudhghuM47F1RFTYFHZyOblAdMdeSQDzXa8AyLEfgIWvZYIXZ wpf9ze0B3H8= =z2Zb -----END PGP SIGNATURE----- --Apple-Mail=_366B3B18-1301-40E5-9069-EBD52038CD8A-- From scott.brim@gmail.com Tue Jan 14 07:39:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E9D1AE026; Tue, 14 Jan 2014 07:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO0StmABkHKl; Tue, 14 Jan 2014 07:39:31 -0800 (PST) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id A52BC1ADFC5; Tue, 14 Jan 2014 07:39:31 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id n16so9761708oag.36 for ; Tue, 14 Jan 2014 07:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qza43Jy0Kiz69LNr/wTvPX9ZiBCdI2k4nu0yFLoO+7c=; b=reN7efgFpOY2LmygEizwd6izGQaZr/MU7sTF3pgS0SYDPi1xsMzapPATcjitVD6ovX ZMyWL9DXKQzbvUqOuJp4jTW1YmThpQm4l7z7QhJcArR/6b4+tzQKN337ZrCB984+UG+L BuUeijx9NObcbAm2TnzBcPIHjQKHUaO9ndzny4KKzBunnZTirzBpa0F7gFn2CFwZoewz AfHqCne/wMTpNKHDSMLXMAsiS+A2vHP/pFOATYezkCxzvRMFo2IQEbvTaZMmfs7jX+Cc nUNUHJExeKkMYf1X0W+Y9TmdG/JRgBuq65+YXq6j315A2i1QNI1q09SomD9VnjeX6y3w DNSA== X-Received: by 10.182.42.105 with SMTP id n9mr1564979obl.33.1389713960209; Tue, 14 Jan 2014 07:39:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Tue, 14 Jan 2014 07:39:00 -0800 (PST) In-Reply-To: <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> From: Scott Brim Date: Tue, 14 Jan 2014 10:39:00 -0500 Message-ID: To: "Eggert, Lars" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:39:33 -0000 Lars, I know we're repeating arguments from the last decade. The choice is between (1) specifying congestion control around the substrate UDP that can be turned off if it causes problems, or (2) specifying nothing at this time and adding it later if operators want it. I guess if this can be written as a SHOULD, up to the implementor's discretion, then okay. Scott On Tue, Jan 14, 2014 at 10:29 AM, Eggert, Lars wrote: > Hi, > > On 2014-1-14, at 16:23, Joel M. Halpern wrote: >> Isn't that basically the problem of the inner traffic sender, not the pr= oblem of the tunnel that is carrying the traffic? > > no, because the sender of the inner traffic may be blasting some L2 traff= ic, for an L2 where that is OK behavior. But that traffic is now being enca= psulated inside UDP and can hence go anywhere on the net *without the sende= r being aware of this*. > >> Asking tunnel's to solve the problem of applications with undesirable be= havior seems backwards. > > It is the *tunnel* that performs the encapsulation and allows that traffi= c to go places it couldn't before. And so it's the tunnel's responsibility = to make sure that the traffic it injects into the Internet complies with th= e BCPs we have on congestion control. > > Lars From jmh@joelhalpern.com Tue Jan 14 07:49:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0D61AE09C; Tue, 14 Jan 2014 07:49:05 -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 9rnCSlRHlw0Z; Tue, 14 Jan 2014 07:49:03 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id AC34E1ADF7F; Tue, 14 Jan 2014 07:49:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 606CB1BD707C; Tue, 14 Jan 2014 07:48:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 1F6B81BD7056; Tue, 14 Jan 2014 07:48:47 -0800 (PST) Message-ID: <52D55C5C.80001@joelhalpern.com> Date: Tue, 14 Jan 2014 10:48:44 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Eggert, Lars" References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> In-Reply-To: <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , Scott Brim , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:49:06 -0000 So a customer buys an Ethernet service from an operator. And it is delivered via MPLS. Possibly across some other operators (Internet as a Service.) If it is tunneled in IP, or GRE (with or without MPLS), then that is fine. But if I add a UDP header I must suddenly add congestion control at the point I add the UDP header? I can understand (disagree with, but understand) Llyod's argument that the UDP header may reach a host, so the checksum might be an issue. I think taht is dealt with by the fact that the host will drop packets with 0 UDP checksums. But I understand the increased reach concern there. For congestion control? Adding an in-network control loop? When the UDP encapsulator may not even know what the service is being used for? And so is probably more likely to apply an inner congestion control to a TCP stream running over IP over Ethernet over MPLS over UDP as to some unconstrained flow? Yours, Joel On 1/14/14 10:29 AM, Eggert, Lars wrote: > Hi, > > On 2014-1-14, at 16:23, Joel M. Halpern wrote: >> Isn't that basically the problem of the inner traffic sender, not the problem of the tunnel that is carrying the traffic? > > no, because the sender of the inner traffic may be blasting some L2 traffic, for an L2 where that is OK behavior. But that traffic is now being encapsulated inside UDP and can hence go anywhere on the net *without the sender being aware of this*. > >> Asking tunnel's to solve the problem of applications with undesirable behavior seems backwards. > > It is the *tunnel* that performs the encapsulation and allows that traffic to go places it couldn't before. And so it's the tunnel's responsibility to make sure that the traffic it injects into the Internet complies with the BCPs we have on congestion control. > > Lars > From curtis@ipv6.occnc.com Tue Jan 14 07:51:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1BE1AE09C; Tue, 14 Jan 2014 07:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 NTFsiqOmpGvp; Tue, 14 Jan 2014 07:51:14 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 395E81AE0DF; Tue, 14 Jan 2014 07:51:14 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0EFojHp098066; Tue, 14 Jan 2014 10:50:46 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401141550.s0EFojHp098066@maildrop2.v6ds.occnc.com> To: mark.tinka@seacom.mu From: Curtis Villamizar In-reply-to: Your message of "Sun, 12 Jan 2014 21:04:40 +0200." <201401122104.44370.mark.tinka@seacom.mu> Date: Tue, 14 Jan 2014 10:50:45 -0500 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:51:17 -0000 In message <201401122104.44370.mark.tinka@seacom.mu> Mark Tinka writes: > On Sunday, January 12, 2014 08:37:16 PM Curtis Villamizar=20 > wrote: > > > Perhaps if you actully worked for a company that made > > line cards you would not make the above statement. > > I work for an operator that pays real money to deploy and=20 > use those line cards, and I make it my business to know what=20 > I'm paying for. > > > Many of the big router vendors use the same TCAM hardware > > for MPLS lookups as they do for IP lookups. Doing the > > lookup is not the rate limiting factor even in hardware > > that has an ILM SRAM table and some form of radix based > > lookup. All of the hardwre I've seen in the last 15 > > years or so forwards MPLS and IP at the same rate. > > Which was exactly my point - unless you somehow missed that. What you said was "Current-generation ASIC's have no problem forwarding MPLS frames at wire rate". Since you didn't mention IP packets I assumed you were making the 20 year old argument that MPLS forwarding was faster than IP. > > ... > > Except IPv6 before they decided to waste the lower half > > of the address space with 40 quintilion host in a > > bridged subnet and you really did have to look at the > > whole 128 bits. > > It is no secret that forwarding of IPv6 packets on some=20 > vendor equipment is about half the rate of IPv4 or MPLS. But=20 > then again, because MPLS control planes are IPv4-driven=20 > today, I'm hoping I didn't have to be explicit about not=20 > including IPv6 in that group, on this list. None of the equipment I have worked on (a while back) or the chips we evaluated recently had such a problem for IPv6 using only the top 64 bits for forwarding. An argument was made in the early 2000s (by me and others) that if we allocated global routes only from the top 64 bits all equipment at that time could forward at essentially the same rate as for IPv4. The reaction from the IPv6 community was to completely throw away the bottom half of the address and make it the host part. There are chips for which looking at a 32 bit prefix or a 64 bit prefix is done within the same pipeline and therefore takes the same amount of time. Other chips which parallelize packet handling budget enough microengines to get the job done (only a part of which is the MPLS ILM or IP destination lookup). > > Back when forwarding was done in > > software (circa 1995) your statement would have been > > true if MPLS preceeded forwarding ASICs which it did > > not. > > You might not know that line cards from C like the LSP=20 > (Label Switch Processor) and much of the PFE from J's PTX=20 > are forwarding engines that have been made cheaper by=20 > reducing the IP FIB on the assumption that all traffic will=20 > be carried in MPLS. This is, obviously, an assumption I do=20 > not support because: Those line cards (and designs I was recently involved in) assume what has historically been called a BGP-free core. Only the IGP routes are carried in the core. BGP is mapped onto the IGP routes. MPLS carries traffic across the core. The core has no BGP routes and therefore needs a lot fewer entries and the ILM can be put into SRAM rather than use a TCAM and only a small set of IP routes needs to be supported. That is done to eliminate a need for large external DRAM or TCAM which itself and the SERDES needed to go off chip produces heat and requires power, board space, and cooling and therefore reduces density. Putting more simple filters in the core also helps increase density. It is more a power to operate and floor space per Gb/s issue. For the most part IP/MPLS transport equipment seems to be going this way, though some people are stuck on MPLS-TP and trying to build a L2 overlay. If you go back to before 2000 at least one provider built a BGP-free core over Frame Relay, but FR itself soon died and the overlay didn't scale well. Some providers wanted to do this over MPLS but the RSVP-TE restoration times were too long and the fallback to IP routing was still needed to make up for that. > - I run IPv6 natively, and at the moment, there are > no production-grade IPv6 control planes for MPLS. > > - It assumes providers will run 6PE (in which case, > IPv6 traffic enjoys MPLS and IPv6 wire rate > forwarding speeds). > > I do not buy such line cards because for anyone running=20 > native IPv6, you could potentially run out of FIB slots to=20 > host IPv6 routes. Unless you run a BGP-free core, whether IPv4 or IPv6. Then you have plenty of FIB space. > That is why I say MPLS has allowed vendors to put out=20 > cheaper line cards compared to the costs of those which have=20 > large IPv4/IPv6 scale. Because MPLS forwarding is so=20 > mainstream, there is no additional cost associated with=20 > forwarding rates similar to IPv4. So much of the cost of=20 > line cards is in QoS queues and routing FIB slots (and MPLS- > biased line cards are stripped of that, hence making them=20 > cheaper). You put forwarding at full rate and cheaper line cards in the same paragraph with no mention of smaller FIB size due to eliminating the BGP routes. > > Also the statement "Current-generation ASIC's have no > > problem forwarding MPLS frames at wire rate" is not true > > for most (or all) hardware with 40 byte payloads (even > > with plus 4 with TCP SACK plus 4 if MPLS) and 100 Gb/s > > interfaces. It is true for "average packet size" > > traffic and on most hardware only true if bursts of 40 > > byte packets are very limited in duration. > > C'mon, Curtis. Everybody knows this already. Moreover, real=20 > world IP traffic is not all 40 bytes. > > If operators have doubts about what forwarding engines can=20 > do below 128 bytes, that is what PoC labs are for before you=20 > buy. And even then, several operators accept the=20 > restrictions up to a certain point, because the lab and real=20 > life vary significantly. > > Mark. OK ... so this is all interesting but I've lost the connection between this discussion and draft-ietf-mpls-in-udp. Hence the OT in the subject. Would you please remind me what that connection was. Curtis From Alexander.Vainshtein@ecitele.com Tue Jan 14 08:00:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF841AE017; Tue, 14 Jan 2014 08:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO1Kzly_Sx9l; Tue, 14 Jan 2014 08:00:24 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAD81AE101; Tue, 14 Jan 2014 08:00:23 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB530.eurprd03.prod.outlook.com (10.242.109.154) with Microsoft SMTP Server (TLS) id 15.0.851.11; Tue, 14 Jan 2014 16:00:10 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Tue, 14 Jan 2014 16:00:09 +0000 From: Alexander Vainshtein To: Scott Brim , "Eggert, Lars" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPEBE8NB1HxYhr0E+Bh7qVSMaw6pqCWMcAgAB1zoCAADdMAIABCbaAgAAklwCAAAtugIAAB9QAgAAQr4CAAAEJgIAAAZQAgAACngCAAAKz0A== Date: Tue, 14 Jan 2014 16:00:09 +0000 Message-ID: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(689001)(679001)(779001)(252514010)(377454003)(24454002)(51704005)(13464003)(377424004)(189002)(199002)(85852003)(80022001)(65816001)(81686001)(74366001)(47446002)(49866001)(51856001)(54316002)(33646001)(53806001)(79102001)(46102001)(87936001)(2656002)(47976001)(74316001)(56776001)(31966008)(76482001)(76796001)(54356001)(63696002)(69226001)(74662001)(81342001)(19580395003)(85306002)(87266001)(74502001)(80976001)(83072002)(19580405001)(83322001)(74706001)(81816001)(74876001)(50986001)(4396001)(59766001)(47736001)(66066001)(76576001)(77982001)(81542001)(76786001)(56816005)(92566001)(15975445006)(90146001)(93136001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB530; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:147.234.56.21; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:00:27 -0000 Lars, Scott and all, IMHO and FWIW the problem is not between congestion control requirements be= ing specified as SHOULD or MUST. Specifying some functionality as SHOULD without describing (even in a non-n= ormative way) how this functionality could be implemented because the proto= col specified does not provide any hooks for it is indeed meaningless. This is the way to guarantee that this functionality will never be implemen= ted even if we discover that in some cases it is needed. In the case of congestion control the minimal required hooks are: 1. Ability to detect congestion at the tail-end of the tunnel 2. Ability to pass this information to the head-end of the tunnel. To the best of my understanding, proposed protocol does not provide any of = these hooks. Hence specifying any requirements for congestion control does = not make any sense to me regardless of the level of these requirements (MUS= T, SHOULD or MAY) - these requirements cannot be implemented without some r= edesign of the protocol. I would also like to note that the declared purpose of the protocol is simp= lification of ECMP. One of the reasons to use ECMP is that the "fat" flow c= annot get the required BW on any specific link...=20 Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Scott Brim > Sent: Tuesday, January 14, 2014 5:39 PM > To: Eggert, Lars > Cc: mpls@ietf.org; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsula= ting > MPLS in UDP) to Proposed Standard >=20 > Lars, I know we're repeating arguments from the last decade. The choice i= s > between (1) specifying congestion control around the substrate UDP that c= an > be turned off if it causes problems, or (2) specifying nothing at this ti= me and > adding it later if operators want it. >=20 > I guess if this can be written as a SHOULD, up to the implementor's > discretion, then okay. >=20 > Scott >=20 > On Tue, Jan 14, 2014 at 10:29 AM, Eggert, Lars wrote: > > Hi, > > > > On 2014-1-14, at 16:23, Joel M. Halpern wrote: > >> Isn't that basically the problem of the inner traffic sender, not the > problem of the tunnel that is carrying the traffic? > > > > no, because the sender of the inner traffic may be blasting some L2 tra= ffic, > for an L2 where that is OK behavior. But that traffic is now being > encapsulated inside UDP and can hence go anywhere on the net *without > the sender being aware of this*. > > > >> Asking tunnel's to solve the problem of applications with undesirable > behavior seems backwards. > > > > It is the *tunnel* that performs the encapsulation and allows that traf= fic to > go places it couldn't before. And so it's the tunnel's responsibility to = make > sure that the traffic it injects into the Internet complies with the BCPs= we > have on congestion control. > > > > Lars > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Tue Jan 14 08:05:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A07F1AE0FC; Tue, 14 Jan 2014 08:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgibuoPPVc-q; Tue, 14 Jan 2014 08:05:37 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAB61AE0DC; Tue, 14 Jan 2014 08:05:35 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB531.eurprd03.prod.outlook.com (10.242.109.155) with Microsoft SMTP Server (TLS) id 15.0.851.11; Tue, 14 Jan 2014 16:05:22 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Tue, 14 Jan 2014 16:05:22 +0000 From: Alexander Vainshtein To: "Joel M. Halpern" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPEBE8NB1HxYhr0E+Bh7qVSMaw6pqCWMcAgAB1zoCAADdMAIABCbaAgAAklwCAAAtugIAAB9QAgAAQr4CAAAEJgIAAAZQAgAAFVgCAAANwMA== Date: Tue, 14 Jan 2014 16:05:21 +0000 Message-ID: <5b1067567abb40dca321c071a751d552@AM3PR03MB532.eurprd03.prod.outlook.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D55C5C.80001@joelhalpern.com> In-Reply-To: <52D55C5C.80001@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(689001)(679001)(779001)(377424004)(13464003)(51704005)(189002)(199002)(479174003)(377454003)(24454002)(252514010)(54356001)(53806001)(79102001)(49866001)(76796001)(54316002)(76786001)(50986001)(46102001)(63696002)(47976001)(65816001)(51856001)(83322001)(80976001)(19580395003)(47736001)(19580405001)(33646001)(93136001)(81816001)(56776001)(59766001)(92566001)(77982001)(76482001)(76576001)(74876001)(87936001)(31966008)(81686001)(4396001)(80022001)(81342001)(87266001)(85306002)(66066001)(69226001)(74662001)(2656002)(56816005)(15975445006)(83072002)(81542001)(90146001)(47446002)(74706001)(74366001)(74502001)(74316001)(85852003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB531; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:147.234.56.21; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Cc: "mpls@ietf.org" , Scott Brim , IETF discussion list , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:05:39 -0000 Joel, You have said (and I fully agree with you) that the UDP encapsulator does n= ot even know (in some cases) what the service is for. If this is the case, how will the UDP encapsulator assign entropy source UD= P ports to specific MPLS packets it encapsulates without breaking reorderin= g-sensitive micro-flows within this service? Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, January 14, 2014 5:49 PM > To: Eggert, Lars > Cc: mpls@ietf.org; Scott Brim; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsula= ting > MPLS in UDP) to Proposed Standard >=20 > So a customer buys an Ethernet service from an operator. And it is deliv= ered > via MPLS. Possibly across some other operators (Internet as a > Service.) > If it is tunneled in IP, or GRE (with or without MPLS), then that is fine= . > But if I add a UDP header I must suddenly add congestion control at the p= oint > I add the UDP header? >=20 > I can understand (disagree with, but understand) Llyod's argument that th= e > UDP header may reach a host, so the checksum might be an issue. I think > taht is dealt with by the fact that the host will drop packets with 0 UDP > checksums. But I understand the increased reach concern there. >=20 > For congestion control? Adding an in-network control loop? When the UDP > encapsulator may not even know what the service is being used for? > And so is probably more likely to apply an inner congestion control to a = TCP > stream running over IP over Ethernet over MPLS over UDP as to some > unconstrained flow? >=20 > Yours, > Joel >=20 > On 1/14/14 10:29 AM, Eggert, Lars wrote: > > Hi, > > > > On 2014-1-14, at 16:23, Joel M. Halpern wrote: > >> Isn't that basically the problem of the inner traffic sender, not the > problem of the tunnel that is carrying the traffic? > > > > no, because the sender of the inner traffic may be blasting some L2 tra= ffic, > for an L2 where that is OK behavior. But that traffic is now being > encapsulated inside UDP and can hence go anywhere on the net *without > the sender being aware of this*. > > > >> Asking tunnel's to solve the problem of applications with undesirable > behavior seems backwards. > > > > It is the *tunnel* that performs the encapsulation and allows that traf= fic to > go places it couldn't before. And so it's the tunnel's responsibility to = make > sure that the traffic it injects into the Internet complies with the BCPs= we > have on congestion control. > > > > Lars > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lars@netapp.com Tue Jan 14 08:06:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49C71AE110; Tue, 14 Jan 2014 08:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.44 X-Spam-Level: X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 xvQ2TnPvHlji; Tue, 14 Jan 2014 08:06:35 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id E1F7E1AE0DC; Tue, 14 Jan 2014 08:06:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,658,1384329600"; d="asc'?scan'208";a="136906970" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 14 Jan 2014 08:06:24 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 08:06:23 -0800 From: "Eggert, Lars" To: Scott Brim Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAD31WAgABWjoCAAHXQgIAAN0wAgAEJtoCAACSXAIAAC26AgAAH1ACAABCuAIAAAQqAgAABkYCAAAKhAIAAB6KA Date: Tue, 14 Jan 2014 16:06:21 +0000 Message-ID: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_5882EB94-8DA2-4AB3-A5E8-C5B083388DB5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:06:38 -0000 --Apple-Mail=_5882EB94-8DA2-4AB3-A5E8-C5B083388DB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 2014-1-14, at 16:39, Scott Brim wrote: > Lars, I know we're repeating arguments from the last decade. The > choice is between (1) specifying congestion control around the > substrate UDP that can be turned off if it causes problems, or (2) > specifying nothing at this time and adding it later if operators want > it. >=20 > I guess if this can be written as a SHOULD, up to the implementor's > discretion, then okay. I don't think we can leave this up to implementors discretion. We've had = IETF consensus that Internet communication requires congestion control = at least since RFC2914. A circuit breaker mechanisms seems = straightforward to implement. As is, I object to this document going forward. The minor benefits of = getting some better load balancing for MPLS are far outweighed by the = risks. (I'm also going to shut up now, and let others speak. I think I've said = my bit.) Lars --Apple-Mail=_5882EB94-8DA2-4AB3-A5E8-C5B083388DB5 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----- iQCVAwUBUtVge9ZcnpRveo1xAQKNnQP9H2LA07dypoVIEYhTCAqM4K2FsYc57jt5 qLo6yyLub6Gy9Uc2/3GgcTKWynfhlOSXGeu1dLAVN2o2ha41gjDRzYiKn9G6lsEI TAfzpLg7Wl0eSCJu0MmB2gommG/YfShWX5hSkmFx+T2q5aqd7NHb8WHagyChQb+A d+nUXryn4+o= =APg3 -----END PGP SIGNATURE----- --Apple-Mail=_5882EB94-8DA2-4AB3-A5E8-C5B083388DB5-- From mark.tinka@seacom.mu Tue Jan 14 08:10:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED6D1AE125; Tue, 14 Jan 2014 08:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_82=0.6] 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 VqBBn0Qgq4sF; Tue, 14 Jan 2014 08:10:28 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id A97D51AE10D; Tue, 14 Jan 2014 08:10:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W36Ye-0001n8-K5; Tue, 14 Jan 2014 18:09:40 +0200 From: Mark Tinka Organization: SEACOM To: curtis@ipv6.occnc.com Date: Tue, 14 Jan 2014 18:09:36 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <201401141550.s0EFojHp098066@maildrop2.v6ds.occnc.com> In-Reply-To: <201401141550.s0EFojHp098066@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2936459.czVGkbzpV0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401141809.40038.mark.tinka@seacom.mu> Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:10:33 -0000 --nextPart2936459.czVGkbzpV0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday, January 14, 2014 05:50:45 PM Curtis Villamizar=20 wrote: > None of the equipment I have worked on (a while back) or > the chips we evaluated recently had such a problem for > IPv6 using only the top 64 bits for forwarding. An > argument was made in the early 2000s (by me and others) > that if we allocated global routes only from the top 64 > bits all equipment at that time could forward at > essentially the same rate as for IPv4. The reaction > from the IPv6 community was to completely throw away the > bottom half of the address and make it the host part. Agree. > There are chips for which looking at a 32 bit prefix or a > 64 bit prefix is done within the same pipeline and > therefore takes the same amount of time. Other chips > which parallelize packet handling budget enough > microengines to get the job done (only a part of which > is the MPLS ILM or IP destination lookup). Agree. > Those line cards (and designs I was recently involved in) > assume what has historically been called a BGP-free > core. Only the IGP routes are carried in the core. BGP > is mapped onto the IGP routes. MPLS carries traffic > across the core. The core has no BGP routes and > therefore needs a lot fewer entries and the ILM can be > put into SRAM rather than use a TCAM and only a small > set of IP routes needs to be supported. Yes, but a "proper" BGP-free core is only true for IPv4. If you are running a native IPv6 backbone, you can't support=20 a BGP-free core for IPv6 (I'll just call it a BGPv6-free=20 core, for typing brevity). The only way you can have a BGPv6-free core is to do 6PE,=20 and like I mentioned before, I don't like tunneled IPv6 (but=20 lots of other providers do it, good for them). > That is done to eliminate a need for large external DRAM > or TCAM which itself and the SERDES needed to go off > chip produces heat and requires power, board space, and > cooling and therefore reduces density. Putting more > simple filters in the core also helps increase density. > It is more a power to operate and floor space per Gb/s > issue. All good and well, but where do my native BGPv6 routes go? > For the most part IP/MPLS transport equipment seems to be > going this way, though some people are stuck on MPLS-TP > and trying to build a L2 overlay. I think MPLS-TP is a way for the incumbents to migrate to=20 Ethernet and still keep their ITU point-to-point-everything=20 way of life that they know and love, but let's not digress=20 :-)... C have had the LSP forwarding engine for about three years=20 now. I've never once considered buying it (and I always=20 support new tech.), and most of my friends that I know=20 closely haven't either. I have no doubt that some operators=20 have bought it, but I have no empirical data to know how=20 quickly it's flying off the shelves. J's PTX and C's new NCS will continue this trend, but=20 without implementing IPv6 control planes for MPLS (and the=20 requisite data plane support), those of us that run native=20 IPv6 will never have a BGPv6-free core. So I can only afford line cards and forwarding engines that=20 don't skimp on FIB, so I can sleep at night knowing my IPv6=20 network won't fall over. > If you go back to before 2000 at least one provider built > a BGP-free core over Frame Relay, but FR itself soon > died and the overlay didn't scale well. Some providers > wanted to do this over MPLS but the RSVP-TE restoration > times were too long and the fallback to IP routing was > still needed to make up for that. Was before my time, but I can appreciate that :-). > Unless you run a BGP-free core, whether IPv4 or IPv6.=20 > Then you have plenty of FIB space. Again, without 6PE, no-can-do for BGPv6. > You put forwarding at full rate and cheaper line cards in > the same paragraph with no mention of smaller FIB size > due to eliminating the BGP routes. Because without FIB's, where will the native BGPv6 routes=20 go? > OK ... so this is all interesting but I've lost the > connection between this discussion and > draft-ietf-mpls-in-udp. Hence the OT in the subject.=20 > Would you please remind me what that connection was. I agree, this is quickly getting off topic, but the source=20 was: ***** On Sunday, January 12, 2014 04:59:41 AM l.wood@surrey.ac.uk=20 wrote: > The MPLS assumption is that it's protected and checked by > a strong link CRC like Ethernet, and checked/regenerated > by stack processing between hops; here, in a path > context, with zero UDP checksums MPLS has no checking at > all. Right, which is probably why routers today can count badly=20 checksum'ed Ethernet frames, but don't have the equivalent=20 for MPLS. > I'm sorry, when was MPLS cheap? Current-generation ASIC's have no problem forwarding MPLS=20 frames at wire rate. One could go so far as to say that MPLS=20 has allowed vendors to make cheaper line cards also because=20 IP FIB's and traffic queues can be scaled down dramatically=20 (not that I'd every buy such line cards, but...). Mark. ***** Cheers, Mark. --nextPart2936459.czVGkbzpV0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS1WFDAAoJEGcZuYTeKm+G12UP/0I3a8sOQVTRN8GjYlxB/IgO qaxNAchFW+dmsGEMWa5WC2V3LRsmBpUQwREBm8E6ADbULv2CdP7ixqnIVgSirESR 6JSX0MkRsiqW34VaOEa7u77c4+6iIuMS/O7lskPiKYjBZdjg3up2Xd5xlDUe+1OH 8N0MDRooTem/2HI3BFxeFD6Y5ulVNVTVahAA/Qj4juSR9OicRjWTAiBiWBowNxyP sasLrnjZZHtD5rBYPSzGlEwaOcx3kfBaop2KBETIfPWNtJyRwkdA01Ad7O9M27kv 0lzt/EJESlL0wueAlKP6kjhNPMm6C8ZlVwPW6LiU+C24BWrP0e2tdLTAN0mSzqVy ChLQERyaO0m1qOHRa+VZ1zZv/GwzRNjU4nEZqKsVaqhOSKpYT6/fI+fKGA8aRjGS hChWOmui0lI/4WsJ9otSNxq+/3TCXcP3ySVHNifik1a+6mU24GGkiWJpAGP1/CPT javmyEYsSRa7OGoSw34W9+SLhDBh99960fLhWaLIo3LMhEss48NZQJK7ybALh2DE wzItalLP6MSJhGVhKU16hSWZsCys7kGh7f16g3EbLwH27MzXIa1eDsIQmOCSyWd1 j7NXyEzOHUHrp18tFlbGeOwYGE9iFPXzLFIEedGFYoLMozpJ/gz1zHpmTgxFoJaR v6AhFuv/Q8w8gax0TQjA =uf6R -----END PGP SIGNATURE----- --nextPart2936459.czVGkbzpV0-- From rcallon@juniper.net Tue Jan 14 08:21:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40E21AE16F for ; Tue, 14 Jan 2014 08:21:47 -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 rmEB-BTbgY2y for ; Tue, 14 Jan 2014 08:21:46 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id C92201AE185 for ; Tue, 14 Jan 2014 08:21:30 -0800 (PST) Received: from mail3-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.22; Tue, 14 Jan 2014 16:21:19 +0000 Received: from mail3-am1 (localhost [127.0.0.1]) by mail3-am1-R.bigfish.com (Postfix) with ESMTP id 2078F48050B; Tue, 14 Jan 2014 16:21:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h9a9j1155h) Received-SPF: pass (mail3-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(189002)(199002)(164054003)(377454003)(13464003)(81542001)(92566001)(79102001)(93136001)(63696002)(80022001)(66066001)(65816001)(76176001)(74876001)(31966008)(81816001)(47446002)(74502001)(74662001)(76796001)(76786001)(2656002)(53806001)(81686001)(83072002)(76576001)(54356001)(85852003)(81342001)(69226001)(51856001)(85306002)(56816005)(90146001)(46102001)(19580395003)(33646001)(74366001)(74706001)(74316001)(49866001)(54316002)(56776001)(76482001)(47976001)(19580405001)(83322001)(47736001)(87936001)(59766001)(77982001)(87266001)(4396001)(80976001)(50986001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail3-am1 (localhost.localdomain [127.0.0.1]) by mail3-am1 (MessageSwitch) id 138971647737480_15052; Tue, 14 Jan 2014 16:21:17 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.238]) by mail3-am1.bigfish.com (Postfix) with ESMTP id EF385801FE; Tue, 14 Jan 2014 16:21:16 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 14 Jan 2014 16:21:16 +0000 Received: from CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.395.1; Tue, 14 Jan 2014 16:21:09 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) with Microsoft SMTP Server (TLS) id 15.0.851.11; Tue, 14 Jan 2014 16:21:08 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0851.011; Tue, 14 Jan 2014 16:21:07 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHOcA+GBN93jIrSvUqrfd3SsFnQwZp0ZWxggBFCRWA= Date: Tue, 14 Jan 2014 16:21:07 +0000 Message-ID: <0a68d00b76524ae6bc45a12d598b8838@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0091C8F1EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:21:47 -0000 Perhaps this is what I get for sending an IPR poll right after New Year's (= either that or there was an email glitch). However, at this point I have se= en only one response to this IPR poll.=20 Editor's, authors, and contributors, please respond to the IPR poll on draf= t-chen-mpls-p2mp-ingress-protection. For IPR that has already been disclose= d according to IETF rules, it is okay to say "all IPR that I know of has al= ready been disclosed in conformance to IETF rules".=20 Thanks, Ross -----Original Message----- From: Ross Callon=20 Sent: Friday, January 03, 2014 11:49 AM To: mpls@ietf.org; 'draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org' Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to=20 draft-chen-mpls-p2mp-ingress-protection? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The=20 documents will not advance to the next stage until a response has been received from each author and each contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) From wes@mti-systems.com Tue Jan 14 08:22:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE6B1AE10D for ; Tue, 14 Jan 2014 08:22:34 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky-ojuJbJhpn for ; Tue, 14 Jan 2014 08:22:32 -0800 (PST) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id CC9301AE16F for ; Tue, 14 Jan 2014 08:22:23 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s0EGMA0m002458 for ; Tue, 14 Jan 2014 11:22:10 -0500 Received: (qmail 17092 invoked by uid 0); 14 Jan 2014 16:22:10 -0000 X-TCPREMOTEIP: 107.48.137.115 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.48.137.115) by 0 with ESMTPA; 14 Jan 2014 16:22:10 -0000 Message-ID: <52D5642A.7090103@mti-systems.com> Date: Tue, 14 Jan 2014 11:22:02 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Eggert, Lars" , Scott Brim References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:22:34 -0000 On 1/14/2014 11:06 AM, Eggert, Lars wrote: > Hi, > > On 2014-1-14, at 16:39, Scott Brim wrote: >> Lars, I know we're repeating arguments from the last decade. The >> choice is between (1) specifying congestion control around the >> substrate UDP that can be turned off if it causes problems, or (2) >> specifying nothing at this time and adding it later if operators want >> it. >> >> I guess if this can be written as a SHOULD, up to the implementor's >> discretion, then okay. > > I don't think we can leave this up to implementors discretion. We've had IETF consensus that Internet communication requires congestion control at least since RFC2914. A circuit breaker mechanisms seems straightforward to implement. > > As is, I object to this document going forward. The minor benefits of getting some better load balancing for MPLS are far outweighed by the risks. > > (I'm also going to shut up now, and let others speak. I think I've said my bit.) > I'm in basic agreement. Assuming we might all agree that there are conceivable scenarios where a circuit breaker mechanism would be useful, is the real issue that we don't all agree that it could be implemented in a way that's not burdensome and doesn't degrade performance unnecessarily? Or is there still fundamental disagreement about whether the scenarios where the circuit breaker is useful are even valid? -- Wes Eddy MTI Systems From curtis@ipv6.occnc.com Tue Jan 14 09:06:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D00F1AE129; Tue, 14 Jan 2014 09:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 FV6exKOHUBXZ; Tue, 14 Jan 2014 09:06:37 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id CDDC21AE0FF; Tue, 14 Jan 2014 09:06:36 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0EH6Fbo099057; Tue, 14 Jan 2014 12:06:15 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Sun, 12 Jan 2014 21:22:58 +0000." <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> Date: Tue, 14 Jan 2014 12:06:15 -0500 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu Subject: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:06:40 -0000 Lloyd, Maybe you should reread the paper too before citing it as evidence. Check the date on it. Check the cited causes of errors. Packet traces from 1998 and 1999 are prehaps not so relevante today, particularly wrt error rates due to hosts, router memories, and link error rates. Look at the cited caused of errors and realize that many things have changed. The largest single error in the paper (paerhaps as high as 99.9% of the errors) was the ACK-of-FIN bug in Windows NT. They may have fixed that by now. Other large causes were host hardware and host software bugs (sent bad data in the first place). One fifth of campus errors were caused by two hosts. This is cited as a bug in Mac OS on Powermac 8100, fixed at the time of publication. A lot of host software errors are discussed, where the checksums are sent bad and therefore will pass any router link FCS. Sending host hardware errors were thought to be in large part caused by no data integrity check on host DMA transfers. I think progress has been made on that front. You can check PCIe. It has a 32bit CRC per lane in the link layer and retransmits on error. Router memory errors was thought to play a large role in the non-host part of the error rate in the paper. Routers use ECC now. Going that far back they didn't always have parity RAM (and sometimes ran parity disabled to avoid parity error reloads). VJHC software errors? Anyone still use VJHC? Those errors should be gone. IP over HDLC over T1 missed a few errors at the link layer in those days. That could be true and occurances dependent on the providers. In the paper that was thought to be a very small contributor. Both HDLC and PPP had an option for 16 bit or 32 bit FCS. Often 16 bit was used. Some HDLC equipment could be and was configured to count errors and send the packets on their way on the assumption that it was better to count errors and deliver bad packets rather than deliver no packet. Perhaps also to hide packet loss. Today all of the link layers in use have 32 bit FCS and count and toss errored packets. In most equipment all of the memories have ECC and all of the buses ECC or FCS if serialized. It is now 14 years since that paper was published in Signcomm and 16 years since some of the observations. Things have changed. Nice bit of nostangia but that paper may no longer be relevant. Curtis reference - http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf In message <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > Curtis > > I suggest reading Stone's work, particularly > ''When The CRC and TCP Checksum Disagree' > for discussion of corruption. > > Particularly its conclusions: 'In the internet, that means > we are sending large volumes of incorrect data without > anyone noticing'. > > The Layer-2 check is per link, not end-to-end. That matters. > > The MPLS assumption is that it crosses a link with a frame > checksum. Putting MPLS over UDP breaks that assumption. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 12 January 2014 18:09 > To: Wood L Dr (Electronic Eng) > Cc: adrian@olddog.co.uk; randy@psg.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; david.black@emc.com; jnc@mit.edu; tsvwg@ietf.org > Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) > > In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > On nested checksums, the question is how they are nested; it's a matter > > of scope. With a bunch of checksums checking only a payload and any > > inner checksums like Russian Matryoshka dolls, the end-to-end argument > > tells us that for reliable receipt of the payload, only the innermost checksum > > matters. > > > > But here, we are not solely checking the payload, but information on how to > > deliver and identify that payload - and while an outer Ethernet CRC is across > > the last link, the UDP checksum, though weak, provides a check on the IP > > addresses and UDP ports (via the pseudoheader check) and MPLS stack > > from UDP/IP source to UDP/IP destination (and the payload, which is the bit > > everyone focuses on as the performance hit as redundant and a processing > > cost when the payload has its own check, and the bit that UDP-Lite can leave out). > > > > Nothing else checks that scope. The scope is wider, and affects the network > > as a whole. Errors in these unchecked fields lead to misdirection and lead to > > misdelivery. Or pollution of other ports. > > > > The MPLS assumption is that it's protected and checked by a strong link CRC like > > Ethernet, and checked/regenerated by stack processing between hops; here, > > in a path context, with zero UDP checksums MPLS has no checking at all. > > That UDP would be running over IP over Ethernet or POS or GFP or ... > > There is no layer-2 currently in use that does not have a robust FCS, > generally a 32 FCS and therefore the MPLS assumption of checking at a > lower layer is still valid. > > Curtis > > > > "consequences for cheap hardware and for software implementations" > > > > I'm sorry, when was MPLS cheap? > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Adrian Farrel [adrian@olddog.co.uk] > > Sent: 09 January 2014 10:21 > > To: Wood L Dr (Electronic Eng); randy@psg.com > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > > Subject: RE: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) > > > > Lloyd and Randy, > > > > With respect to draft-ietf-mpls-in-udp, this is why we have IETF last calls, so > > thanks for the comments. > > > > We did take the precaution of sending this I-D for an early TSV Directorate > > review because of the concern about a number of factors and the overlap with > > tsvwg work, but the review came back "clean". Of course, such a review is just > > one person, so this conversation is good. > > > > Wrt zero checksum, where do you stand on nested checksums? There is some claim > > that they represent a waste of processing. I am not convinced by that when each > > layer is using dedicated hardware (that can presumably process checksums at line > > speed), but I am interested in the consequences for cheap hardware and for > > software implementations (as have been claimed to be some of the motivations for > > this work). > > > > Other TSV-related issues that surely pop up are: > > - allocation of ports for foo-in-UDP > > - congestion control > > > > Please note that there are a number of I-Ds that you missed in your broad sweep > > of "I am opposed". You should probably look at the NVGRE and VXLAN work (which I > > think is lurking around the NVO3 working group) because that is also looking at > > UDP encaps of a tunnelling protocol. > > > > Thanks, > > Adrian > > > > Health warnings: > > I am responsible AD for draft-ietf-mpls-in-udp > > I am a co-author of the gre-in-udp draft. > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk > > > Sent: 09 January 2014 08:07 > > > To: randy@psg.com > > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; > > > tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > > > Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: > > > [tsvwg] Milestones changed for tsvwg WG) > > > > > > Randy, > > > > > > okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get > > > consensus on it. And then the authors can adopt that consensus for > > mpls-in-udp, > > > which overlaps in authorship... > > > > > > thanks, > > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: Randy Bush [randy@psg.com] > > > Sent: 09 January 2014 07:51 > > > To: Wood L Dr (Electronic Eng) > > > Cc: david.black@emc.com; gorry@erg.abdn.ac.uk; ietf@ietf.org; mpls@ietf.org; > > > jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org > > > Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] > > > Milestones changed for tsvwg WG) > > > > > > > Because they specify zero UDP checksums, > > > > I oppose publication of draft-ietf-mpls-in-udp in its current form > > > > I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its current > > > form. > > > > I oppose the IETF lisp documents. > > > > > > lloyd, > > > > > > i think i understand your position. but i disagree with preventing wg > > > adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly > > > see wg adoption as how we get to discuss and work on a document, not as > > > approval of the document. as david said, i think we need to discuss it > > > so we can decide if it should be fixed. to do so, we have to adopt it. > > > > > > randy From curtis@ipv6.occnc.com Tue Jan 14 09:25:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5A81AE16A for ; Tue, 14 Jan 2014 09:25:40 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char B4 hex): Subject: Re: \264\360\270\264: [mpls] Las[...] X-Spam-Flag: NO X-Spam-Score: -0.573 X-Spam-Level: X-Spam-Status: No, score=-0.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJECT_NEEDS_ENCODING=0.049, SUBJ_ILLEGAL_CHARS=1.518] 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 xNAefWFKQATN for ; Tue, 14 Jan 2014 09:25:39 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 07C221AE14B for ; Tue, 14 Jan 2014 09:25:35 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0EHPN6T099308; Tue, 14 Jan 2014 12:25:23 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401141725.s0EHPN6T099308@maildrop2.v6ds.occnc.com> To: Xuxiaohu From: Curtis Villamizar Subject: Re: ´ð¸´: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard In-reply-to: Your message of "Tue, 14 Jan 2014 03:32:09 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08244868@NKGEML512-MBS.china.huawei.com> Date: Tue, 14 Jan 2014 12:25:23 -0500 Cc: "mpls@ietf.org" , IETF , "Eggert, Lars" , Scott Brim X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:25:40 -0000 In message <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08244868@NKGEML512-MBS.china.huawei.com> Xuxiaohu writes: > Hi Curtis and Joel, > > Thanks a lot for your detailed comments. > > Hi Lars, > > I wonder whether the following compromised text for the Congestion > Consideration section of this doc is roughly acceptable to you. > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > forwarded through "UDP tunnels", the congestion control guidelines > for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be > followed. Specifically, MPLS can carry a number of different > protocols as payloads. When the MPLS payload traffic is IP-based > and congestion-controlled, the UDP tunnel SHOULD NOT employ its own > congestion control mechanism, because congestion losses of tunneled > traffic will already trigger an appropriate congestion response at > the original senders of the tunneled traffic. When the MPLS payload > traffic is not known to be IP-based, or is known to be IP-based but > not congestion-controlled, the UDP tunnel SHOULD employ an > appropriate congestion control mechanism which is outside the scope > of this document. > > Best regards, > Xiaohu This works for me. If deployments indicate a need for congestion control another document can be written. I doubt it will be needed. If someone (Lars perhaps) feels a pressing need to wirte a congestion control for MPLS over UDP document (or for any tunneling over UDP) regardless of deployment experience, then they can go ahead. Whether it works for Lars may be the issue. Curtis From curtis@ipv6.occnc.com Tue Jan 14 10:11:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB601AE134 for ; Tue, 14 Jan 2014 10:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 b0L1I1LXuLkr for ; Tue, 14 Jan 2014 10:11:10 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 42B1F1AE0D5 for ; Tue, 14 Jan 2014 10:11:10 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0EIArai099817; Tue, 14 Jan 2014 13:10:53 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401141810.s0EIArai099817@maildrop2.v6ds.occnc.com> To: mark.tinka@seacom.mu From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 14:31:00 +0200." <201401141431.03808.mark.tinka@seacom.mu> Date: Tue, 14 Jan 2014 13:10:53 -0500 Cc: "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:11:17 -0000 In message <201401141431.03808.mark.tinka@seacom.mu> Mark Tinka writes: > On Monday, January 13, 2014 10:04:13 PM Curtis Villamizar > wrote: > > > Perhaps someone needs to explain to you what a FEC is and > > how MPLS traffic is routed in most LDP networks. > > Thanks for the 101, Curtis, but I think I'm doing alright > :-). > > Again, my input is rooted in operational situations that > I've experienced, present and past (I'm neither a vendor nor > a software developer): > > J's implementation of LDP treats LDP much like a routing > protocol (unlike C's implementation). > > In such cases, LDP-derived routing has a discrete routing > table different from the global routing table. Under certain > conditions (design or code), there could be a mis-alignment > between what LDP thinks is the best path vs. what the IGP > thinks is the best path. You need specific configuration to create the mis-alignment. You can also override an IP routing protocol with static routes. > A knob exists within J's LDP implementation to synchronize > LDP and the IGP (i.e., the LDP and IGP metric is always the > same). Such a knob does not exist (AFAIK) with C because C > don't treat LDP like a routing protocol. Without this LDP > knob enabled in J's implementation (which is the default > case), LDP routes always retain a metric of 1, regardless of > the route and regardless of what the IGP metric is. Both ISIS and OSPF have a TE metric and an IGP metric. The default AFAIK was to use the IGP metric for LDP, though if as you say J defaults to 1 and requires you to configure a separate LDP metric. If so, then the LDP hop count TLV would not match the IGP cost. Not a problem but an odd choice for default value on J's part. > I concede that this case may not be the norm when taking all > vendor implementations into account, but then again, my > experience is restricted to C and J. > > Mark. I'm not sure how any of this discussion changes anything wrt draft-ietf-mpls-in-udp. Is there relevance to draft-ietf-mpls-in-udp that I am missing? Curtis From stbryant@cisco.com Tue Jan 14 10:27:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6831AE101; Tue, 14 Jan 2014 10:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 PJ9XYVg8YGXD; Tue, 14 Jan 2014 10:27:03 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id B34301AE06C; Tue, 14 Jan 2014 10:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9804; q=dns/txt; s=iport; t=1389724012; x=1390933612; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=buqbYsHxbFMGj5If0RKN8HQZ1bI9G1YZmgKQfkEtu+U=; b=D7OWqqQoq5EtZSzcvA/g8OnQP3PVO+/BKJZSS+1ncu4+fvcNSXNXMkj4 XtQqqPjqlZag4UMglgIZbRtZjqJJNuy6fS401+6re7VpTrPfk7iHUXVtj SVc7/pkH3ANj4Z8PZwgwEBcbATFRVA0XVrrlfMU1tkRRWSQSoot+chwle Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4FAPKA1VKQ/khN/2dsb2JhbABQCg6CfThQumSBFRZ0giUBAQECAgEBATUwBgoBDAQLEQQBAQEJFgQEBwkDAgECARUfAwEFCAcJAwEFAgEBiAAIBcQoF44rOiIHBoQxBJgegTCLLYU4gW9/Pw X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="3622779" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 14 Jan 2014 18:26:50 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0EIQnea003901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 18:26:50 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0EIQm2s008555; Tue, 14 Jan 2014 18:26:48 GMT Message-ID: <52D58168.9060800@cisco.com> Date: Tue, 14 Jan 2014 18:26:48 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com, l.wood@surrey.ac.uk References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> In-Reply-To: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:27:07 -0000 I agree the paper is now obsolete. Stewart On 14/01/2014 17:06, Curtis Villamizar wrote: > Lloyd, > > Maybe you should reread the paper too before citing it as evidence. > Check the date on it. Check the cited causes of errors. > > Packet traces from 1998 and 1999 are prehaps not so relevante today, > particularly wrt error rates due to hosts, router memories, and link > error rates. Look at the cited caused of errors and realize that many > things have changed. > > The largest single error in the paper (paerhaps as high as 99.9% of > the errors) was the ACK-of-FIN bug in Windows NT. They may have fixed > that by now. Other large causes were host hardware and host software > bugs (sent bad data in the first place). > > One fifth of campus errors were caused by two hosts. This is cited as > a bug in Mac OS on Powermac 8100, fixed at the time of publication. > > A lot of host software errors are discussed, where the checksums are > sent bad and therefore will pass any router link FCS. > > Sending host hardware errors were thought to be in large part caused > by no data integrity check on host DMA transfers. I think progress > has been made on that front. You can check PCIe. It has a 32bit CRC > per lane in the link layer and retransmits on error. > > Router memory errors was thought to play a large role in the non-host > part of the error rate in the paper. Routers use ECC now. Going that > far back they didn't always have parity RAM (and sometimes ran parity > disabled to avoid parity error reloads). > > VJHC software errors? Anyone still use VJHC? Those errors should be > gone. > > IP over HDLC over T1 missed a few errors at the link layer in those > days. That could be true and occurances dependent on the providers. > In the paper that was thought to be a very small contributor. > > Both HDLC and PPP had an option for 16 bit or 32 bit FCS. Often 16 > bit was used. Some HDLC equipment could be and was configured to > count errors and send the packets on their way on the assumption that > it was better to count errors and deliver bad packets rather than > deliver no packet. Perhaps also to hide packet loss. Today all of > the link layers in use have 32 bit FCS and count and toss errored > packets. In most equipment all of the memories have ECC and all of > the buses ECC or FCS if serialized. > > It is now 14 years since that paper was published in Signcomm and 16 > years since some of the observations. Things have changed. Nice bit > of nostangia but that paper may no longer be relevant. > > Curtis > > reference - > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf > > In message <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: >> Curtis >> >> I suggest reading Stone's work, particularly >> ''When The CRC and TCP Checksum Disagree' >> for discussion of corruption. >> >> Particularly its conclusions: 'In the internet, that means >> we are sending large volumes of incorrect data without >> anyone noticing'. >> >> The Layer-2 check is per link, not end-to-end. That matters. >> >> The MPLS assumption is that it crosses a link with a frame >> checksum. Putting MPLS over UDP breaks that assumption. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Curtis Villamizar [curtis@ipv6.occnc.com] >> Sent: 12 January 2014 18:09 >> To: Wood L Dr (Electronic Eng) >> Cc: adrian@olddog.co.uk; randy@psg.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; david.black@emc.com; jnc@mit.edu; tsvwg@ietf.org >> Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) >> >> In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> >> l.wood@surrey.ac.uk writes: >> >>> On nested checksums, the question is how they are nested; it's a matter >>> of scope. With a bunch of checksums checking only a payload and any >>> inner checksums like Russian Matryoshka dolls, the end-to-end argument >>> tells us that for reliable receipt of the payload, only the innermost checksum >>> matters. >>> >>> But here, we are not solely checking the payload, but information on how to >>> deliver and identify that payload - and while an outer Ethernet CRC is across >>> the last link, the UDP checksum, though weak, provides a check on the IP >>> addresses and UDP ports (via the pseudoheader check) and MPLS stack >>> from UDP/IP source to UDP/IP destination (and the payload, which is the bit >>> everyone focuses on as the performance hit as redundant and a processing >>> cost when the payload has its own check, and the bit that UDP-Lite can leave out). >>> >>> Nothing else checks that scope. The scope is wider, and affects the network >>> as a whole. Errors in these unchecked fields lead to misdirection and lead to >>> misdelivery. Or pollution of other ports. >>> >>> The MPLS assumption is that it's protected and checked by a strong link CRC like >>> Ethernet, and checked/regenerated by stack processing between hops; here, >>> in a path context, with zero UDP checksums MPLS has no checking at all. >> >> That UDP would be running over IP over Ethernet or POS or GFP or ... >> >> There is no layer-2 currently in use that does not have a robust FCS, >> generally a 32 FCS and therefore the MPLS assumption of checking at a >> lower layer is still valid. >> >> Curtis >> >> >>> "consequences for cheap hardware and for software implementations" >>> >>> I'm sorry, when was MPLS cheap? >>> >>> Lloyd Wood >>> http://about.me/lloydwood >>> ________________________________________ >>> From: Adrian Farrel [adrian@olddog.co.uk] >>> Sent: 09 January 2014 10:21 >>> To: Wood L Dr (Electronic Eng); randy@psg.com >>> Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org >>> Subject: RE: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) >>> >>> Lloyd and Randy, >>> >>> With respect to draft-ietf-mpls-in-udp, this is why we have IETF last calls, so >>> thanks for the comments. >>> >>> We did take the precaution of sending this I-D for an early TSV Directorate >>> review because of the concern about a number of factors and the overlap with >>> tsvwg work, but the review came back "clean". Of course, such a review is just >>> one person, so this conversation is good. >>> >>> Wrt zero checksum, where do you stand on nested checksums? There is some claim >>> that they represent a waste of processing. I am not convinced by that when each >>> layer is using dedicated hardware (that can presumably process checksums at line >>> speed), but I am interested in the consequences for cheap hardware and for >>> software implementations (as have been claimed to be some of the motivations for >>> this work). >>> >>> Other TSV-related issues that surely pop up are: >>> - allocation of ports for foo-in-UDP >>> - congestion control >>> >>> Please note that there are a number of I-Ds that you missed in your broad sweep >>> of "I am opposed". You should probably look at the NVGRE and VXLAN work (which I >>> think is lurking around the NVO3 working group) because that is also looking at >>> UDP encaps of a tunnelling protocol. >>> >>> Thanks, >>> Adrian >>> >>> Health warnings: >>> I am responsible AD for draft-ietf-mpls-in-udp >>> I am a co-author of the gre-in-udp draft. >>> >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk >>>> Sent: 09 January 2014 08:07 >>>> To: randy@psg.com >>>> Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; >>>> tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org >>>> Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: >>>> [tsvwg] Milestones changed for tsvwg WG) >>>> >>>> Randy, >>>> >>>> okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get >>>> consensus on it. And then the authors can adopt that consensus for >>> mpls-in-udp, >>>> which overlaps in authorship... >>>> >>>> thanks, >>>> >>>> Lloyd Wood >>>> http://about.me/lloydwood >>>> ________________________________________ >>>> From: Randy Bush [randy@psg.com] >>>> Sent: 09 January 2014 07:51 >>>> To: Wood L Dr (Electronic Eng) >>>> Cc: david.black@emc.com; gorry@erg.abdn.ac.uk; ietf@ietf.org; mpls@ietf.org; >>>> jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org >>>> Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] >>>> Milestones changed for tsvwg WG) >>>> >>>>> Because they specify zero UDP checksums, >>>>> I oppose publication of draft-ietf-mpls-in-udp in its current form >>>>> I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its current >>>> form. >>>>> I oppose the IETF lisp documents. >>>> lloyd, >>>> >>>> i think i understand your position. but i disagree with preventing wg >>>> adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly >>>> see wg adoption as how we get to discuss and work on a document, not as >>>> approval of the document. as david said, i think we need to discuss it >>>> so we can decide if it should be fixed. to do so, we have to adopt it. >>>> >>>> randy > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From mark.tinka@seacom.mu Tue Jan 14 11:52:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0461AE113 for ; Tue, 14 Jan 2014 11:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 1S2AJBO6SYb7 for ; Tue, 14 Jan 2014 11:52:24 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBD31ADFB1 for ; Tue, 14 Jan 2014 11:52:23 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W3A1X-0002U9-RH; Tue, 14 Jan 2014 21:51:43 +0200 From: Mark Tinka Organization: SEACOM To: curtis@ipv6.occnc.com Date: Tue, 14 Jan 2014 21:51:42 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <201401141810.s0EIArai099817@maildrop2.v6ds.occnc.com> In-Reply-To: <201401141810.s0EIArai099817@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2864094.YLMcIW7czl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401142151.43057.mark.tinka@seacom.mu> Cc: "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 19:52:27 -0000 --nextPart2864094.YLMcIW7czl Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday, January 14, 2014 08:10:53 PM Curtis Villamizar=20 wrote: > You need specific configuration to create the > mis-alignment. You can also override an IP routing > protocol with static routes. Ships-in-the-night IGP operations (typically due to=20 migrations) and/or multiple paths available to an LSR/LER=20 can present a unique set of circumstances for this to brew=20 without synchronized metrics between LDP and the IGP. > Both ISIS and OSPF have a TE metric and an IGP metric.=20 > The default AFAIK was to use the IGP metric for LDP, This is C's way. =46or J, there are options for this, and the default is=20 opposite to what C do. > though if as you say J defaults to 1 and requires you to > configure a separate LDP metric. If so, then the LDP > hop count TLV would not match the IGP cost. Not a > problem but an odd choice for default value on J's part. I've been in situations, many years back, where this has led=20 to interesting problems (albeit, transient and/or easy to=20 detect). Situation could be aggregavated when you tunnel LDP in RSVP. > I'm not sure how any of this discussion changes anything > wrt draft-ietf-mpls-in-udp. >=20 > Is there relevance to draft-ietf-mpls-in-udp that I am > missing? Agree, we're now really off-topic, and maybe it's time to=20 circle back to relevance to draft-ietf-mpls-in-udp. Cheers, Mark. --nextPart2864094.YLMcIW7czl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS1ZVOAAoJEGcZuYTeKm+G88UP/2u4SDOIWBw9Rts1lAEtbu9M idSt7QWyEs878SrJM/y6iOuKhd7Dpb7y87fb1GQGCYsVHSKr35BJtcxWEV2ziyLD H2BefRMZbmEs6wxxob7mm1eQLJOw/pXCBksYSoFmpjVkwgX+l7lI7dF5p/vfc0Bq iQ5Aj9FlrffSDR+M96ShBuRCReTaFw99+/XBcz6bdWcrWZnQkXt0idRfQJTMqD9l mDOkf47GA1ax0YhkY7R0+xlGmJJvAbfOa+ZfWXFU6pmj+65WA8KJtJrNxN8Wo6lp ye24Oh/ttYDYmuVLmxICAIPK6zdkAoC0KO2ZpU2PYwjZG4gzcGKWN++6qaS4SEYs oHKQFz4gDMAGpg6hSzPXYOeY3DMLSF1j3THnsPiOoIygIACGo0jc9Dxght30dlXS Yi+Sk0dsTWLvCWgw82G1atC7FRv/0me2fX5Dcsoy8FEwgepJJLZo4QNYxLXDNsn0 OXYopUHKS9f7B+4Hbfi/6YXV3W6SveDTDuy5Zu26QhXW99LWHNEQSK4Znn3e9IHM 5/ycsAq67ban8QOGpXIUGDeJo7eMRc1k5CJFQNwxjTrtmj4oCDXLPwVgamJOFZgn 89+dU0VjODo4ZoYOsR06J7iHUpMDhz2YWZqFQuXbale4+PPnB8cMjIZkIcttnL/W x1gg4U/VXP1O3cBVjg8f =xMjv -----END PGP SIGNATURE----- --nextPart2864094.YLMcIW7czl-- From edc@google.com Tue Jan 14 12:29:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D981ADFCA for ; Tue, 14 Jan 2014 12:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQdXLob3ngf3 for ; Tue, 14 Jan 2014 12:29:08 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1411AE155 for ; Tue, 14 Jan 2014 12:29:07 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id x13so912977wgg.27 for ; Tue, 14 Jan 2014 12:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=emwcLnFtoLgKjo5q6JqhNprCT2HKexy5UDuof5KMLCw=; b=P/0cr2aG9vjb1ucgDmqqLh3LTuqSGaYCxHEXzPqJ5WXydECk5G/xuLJzxloYT7zyMN J4IS25xX/mE/D/KYPSA9n1gDOL12aWEN36x7SGeKab5oqix59MZUYQoNF5b2AQq7otHM GMRBHCrC46SrauQk+dC/AG3x7Iuq69kfAppD4mXkMAaOc105G2hXtNSYQ/lAhDjLgoCe ujRYi2gwi6oJzm+/Rd3X2EAu42Vt9pRgcfn7pVOXLuWnhjCowa38apGL8ITQ4k8ouGpo 1NaQYMudteB0tMA8KSLPHzy/OvZSGyYh9Awa4R0eVQdMLOt5Bdxolewh8vu3JfnvupBF 7dCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=emwcLnFtoLgKjo5q6JqhNprCT2HKexy5UDuof5KMLCw=; b=YbxpzR4exU+q90gNhNriYa0hFv2a4aamQuPeuM3icY2em4ZdjNWlkH1SZj4iRPwtic y/1nUbAXugtmFcEJ72kNbsxJYFBExdyFpst3We6OHGFaX0Idjdb0+INHICFDlngGad5z nJEXuVXLQRCAPtiBYfgvDEeia3afG/6a6veDUwI8Wbe+4RRYn+ZA88OkZISFMH8tRuaK dpTMP/SBi5sV0Fm3CmUPYi6CZ4/l8T1Treea1zqcsiiECK8x4g+PHKBejLrkpQFRtbnV t+Gq6ZRMoP0VZntrER3DMPzrFXxFcgJ7PjnCcrTURwyQNIIOqWLnj5NEy76Nv7owWVgc wIXA== X-Gm-Message-State: ALoCoQmsEg3PkpWY1YY4ncewz9olvQdJB4XaX28kGsCibZjYQ//w+UhCpTxIafU9vAonAQWbjH4rvRLRlF6nxlxEo+is3M/7YHS7MU2tS+7oyLtOurnqU4biSh2H4oamySlPlKVEBcEOzDPf2DCDTkZgsCtYlbRsr5yXlHj6lKkV2N6aH7NL1d8uO1baBVlRTDyRUXsnN6i+ X-Received: by 10.180.37.193 with SMTP id a1mr3942567wik.52.1389731336013; Tue, 14 Jan 2014 12:28:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Tue, 14 Jan 2014 12:28:14 -0800 (PST) In-Reply-To: <52D5568F.2070600@joelhalpern.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> From: Edward Crabbe Date: Tue, 14 Jan 2014 12:28:14 -0800 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=e89a8f502fa09ddfaf04eff40acb Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list , Scott Brim Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:29:10 -0000 --e89a8f502fa09ddfaf04eff40acb Content-Type: text/plain; charset=ISO-8859-1 +100 the same problem would exist with or without the additional encapsulation (this includes any L2 encaps that may exist in the case of L2 tunelling.) The only difference is /reach/. This same concern exists *most* common tunnels types in the internet today. On Tue, Jan 14, 2014 at 7:23 AM, Joel M. Halpern wrote: > Isn't that basically the problem of the inner traffic sender, not the > problem of the tunnel that is carrying the traffic? > Asking tunnel's to solve the problem of applications with undesirable > behavior seems backwards. > > Yours, > Joel > > > On 1/14/14 10:20 AM, Eggert, Lars wrote: > >> On 2014-1-14, at 15:20, Stewart Bryant wrote: >> >>> Yes, the inner (real) transport header is the only meaningful place >>> to apply congestion avoidance. >>> >> >> But what if the inner traffic isn't congestion controlled? >> >> Lars >> >> _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --e89a8f502fa09ddfaf04eff40acb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+100

the same problem would exist with = or without the additional encapsulation (this includes any L2 encaps that m= ay exist in the case of L2 tunelling.) =A0The only difference is /reach/. = =A0This same concern exists *most* common tunnels types in the internet tod= ay.



On Tue, Jan 14, 2014 at 7:23 AM, Joel M. Halpern <jmh@joelh= alpern.com> wrote:
Isn't that basically the problem of the = inner traffic sender, not the problem of the tunnel that is carrying the tr= affic?
Asking tunnel's to solve the problem of applications with undesirable b= ehavior seems backwards.

Yours,
Joel


On 1/14/14 10:20 AM, Eggert, Lars wrote:
On 2014-1-14, at 15:20, Stewart Bryant <stbryant@cisco.com> wrote:
Yes, the inner (real) transport header is the only meaningful place
to apply congestion avoidance.

But what if the inner traffic isn't congestion controlled?

Lars

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--e89a8f502fa09ddfaf04eff40acb-- From curtis@ipv6.occnc.com Tue Jan 14 12:54:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8CF1AE1A4; Tue, 14 Jan 2014 12:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RP_MATCHES_RCVD=-0.538, 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 trCvhlGHGOvf; Tue, 14 Jan 2014 12:54:29 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5071ADF99; Tue, 14 Jan 2014 12:54:29 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0EKsADA001944; Tue, 14 Jan 2014 15:54:11 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401142054.s0EKsADA001944@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 08:28:05 +0000." <290E20B455C66743BE178C5C84F1240847E63346C3@EXMB01CMS.surrey.ac.uk> Date: Tue, 14 Jan 2014 15:54:10 -0500 Cc: mpls@ietf.org, lars@netapp.com, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:54:32 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346C3@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > It stands to reason that if tunnelers can turn off udp checksums > because their performance is degraded, they can turn off > congestion control because it will degrade their performance. > > Rest of the internet getting congested and getting > misdelivered corrupted packets? Really not their problem. > > There are important vendors trying to sell products here, > and they need performance to do so. > Get with the program! > > Lloyd Wood > http://about.me/lloydwood OK, perhaps if you are running MPLS/UDP/IP over HDLC and the HDLC configuration is set to count FCS errors but not drop you will still *really* need the UDP checksum. Otherwise its isn't going to do much for you. Any checksum is really bad for some types of errors such as chunk reordering and multiple bit errors. Maybe on HDLC or PPP with 16 bit CRC you may see a low error rate, but in theory that would be much less than 10^-5 since few multiple bit errors will be coincidence match the CRC, even for a 16 bit CRC. I suspect most routers would be able to do the checksum anyway and for modern links if they come up with a zero error count that's fine. Modern OTN based transport networks use forward error correction FEC which accounts for a fair amount of overhead and a lot of processing gates on the receiving end. The measure of effectiveness of given FEC is in dB with 10 dB being a reduction of a factor of 10 in bit errors and typical FEC in the high tens of dB. The target corrected error rate is often 10^-15 or one bit error in 24 hours for 10 Gb/s, one bit error in 2.5 hours for 100 Gb/s. Any link with corrected bit error rates approaching 10^-12 is taken out of service. This is roughly equivalent to the old ES (errored seconds) and SES (severely errored seconds) metric where a ES is one second with any bit errors and an SES is one second with 10 or more errors (I think its 10). More than some number of ES or SES and a link is taken down. The uncorrected errors are passed through. A packet may traverse an entire continent with 2-3 such links separated by regeneration or could stop at a number of routers along the way. Typically today the router uses 10GbE or 100GbE (growing use) which are then passed as a bit stream in the transport network. At the other end the uncorrected errors from transport are picked up by Ethernet 32 bit FCS. Since a 32 bit FCS picks up 100% of single bit errors and most instances where a small number of bits are in error, and all but 1 in 2^32 where many bits are in error, few errors are going to get through. If GFP is used, the per packet FCS is checked at each hop and for GFP-T also checked end to end. A bad local ethernet is more likely to contribute an error (again better than 1 in 2^32 detection is expected) due to something like a bad CAT-{5,5e,6} connection or too many sharp turns. A DSL or DOCSIS link is also more likely to contribute an error. With CRC32 on all links and no bad hardware in between (ie: circa 1990s equipment with no parity RAM and no correction on DMA, buses, etc) you would expect on the order of 10^-8 errors (10^-9 per hop, a few errored hops). For example, two hosts on my home LAN had non-zero tcp checksums. Each had < 10^-6 packet error rate. It is hard to tell if this is host errors at the other end. The only hosts I have with non-zero are on the service provider DMZ LAN so that would include any bot attacks, etc, where sending hosts could be old junk. Host behind those have zero UDP and TCP checksum errors. This seems similar to Stewart's quick check. In the T1/T3 days the transport layer just had parity and just counted parity errors. Providers in those days were notorious for ignoring ES and SES counters until the customer complained. HDLC then had its 16 bit CRC, optional 32 bit. If an ISP wasn't paying attention to their HDLC error counters then it was up to the IP end customer to complain and hope the problem got escallated rather than dropped. As to whether congestion control is in practice needed see http://www.ietf.org/mail-archive/web/mpls/current/msg11222.html Its fine to make them both optional and to make congestion control mechanisms out of scope and the topic of a later document if needed. Curtis > ________________________________________ > From: ietf [ietf-bounces@ietf.org] On Behalf Of Joel M. Halpern [jmh@joelhalpern.com] > Sent: 10 January 2014 15:36 > To: Eggert, Lars; Xuxiaohu > Cc: mpls@ietf.org; IETF > Subject: Re: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > Maybe I am completely missing things, but this looks wrong. > If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion > control will make it more likely that the service won't work. Is that > really the goal? > > We do not perform congestion control on MPLS LSPs. > Assuming that a UDP tunnel is carrying just MPLS and was established > just for MPLS, why would we expect it to behave differently than an MPLS > LSP running over the exact same path, carrying the exact same traffic? > > Yours, > Joel > > On 1/10/14 3:47 AM, Eggert, Lars wrote: > > Hi, > > > > that sounds good. What congestion control are you going to be specifying for your tunnel? > > > > Lars > > > > On 2014-1-10, at 4:46, Xuxiaohu wrote: > > > >> Hi Lars, > >> > >> Thanks a lot for your comments. > >> > >> I wonder whether the following modified text for Congestion Consideration section is OK from your point of view: > >> > >> Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded through "UDP tunnels", the congestion control guidelines for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically, MPLS can carry a number of different protocols as payloads. When the payload traffic is IP-based and congestion-controlled, the UDP tunnel SHOULD NOT employ its own congestion control mechanism, because congestion losses of tunneled traffic will already trigger an appropriate congestion response at the original senders of the tunneled traffic. When the payload traffic is not known to be IP-based, or is known to be IP-based but not congestion-controlled, the UDP tunnel SHOULD employ an appropriate congestion control mechanism. Furthermore, because UDP tunnels are usually bulk-transfer applications as far as the intermediate routers are concerned, the guidelines as defined in Section 3.1.1 of [RFC5405] SHOULD apply. > >> > >> Best regards, > >> Xiaohu > >> > >>> -----ÓʼþÔ­¼þ----- > >>> ·¢¼þÈË: mpls [mailto:mpls-bounces@ietf.org] ´ú±í Eggert, Lars > >>> ·¢ËÍʱ¼ä: 2014Äê1ÔÂ8ÈÕ 18:22 > >>> ÊÕ¼þÈË: IETF > >>> ³­ËÍ: mpls@ietf.org > >>> Ö÷Ìâ: Re: [mpls] Last Call: (Encapsulating MPLS > >>> in UDP) to Proposed Standard > >>> > >>> Hi, > >>> > >>> On 2014-1-2, at 16:14, The IESG wrote: > >>>> - 'Encapsulating MPLS in UDP' > >>>> as Proposed Standard > >>> > >>> > >>> this document needs to describe how it addresses the issues raised in BCP145 > >>> (RFC5405). It already contains some text about messages sizes and congestion > >>> considerations, which is great. Unfortunately, the text about congestion > >>> considerations is not fully in line with RFC5405. > >>> > >>> Lars > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From l.wood@surrey.ac.uk Tue Jan 14 13:45:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E321AE102; Tue, 14 Jan 2014 13:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, 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 1HRSZo3uZblw; Tue, 14 Jan 2014 13:45:21 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.169]) by ietfa.amsl.com (Postfix) with ESMTP id BE2BD1ADF99; Tue, 14 Jan 2014 13:45:20 -0800 (PST) Received: from [85.158.137.99:20628] by server-9.bemta-3.messagelabs.com id F2/1A-13104-4EFA5D25; Tue, 14 Jan 2014 21:45:08 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-2.tower-217.messagelabs.com!1389735907!21370390!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1957 invoked from network); 14 Jan 2014 21:45:07 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-2.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 14 Jan 2014 21:45:07 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Tue, 14 Jan 2014 21:44:30 +0000 From: To: Date: Tue, 14 Jan 2014 21:44:29 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8RatT0ErGP8P+xT9qHx2FSHtJ1FgAA+RYU Message-ID: <290E20B455C66743BE178C5C84F1240847E63346C4@EXMB01CMS.surrey.ac.uk> References: Your message of "Tue, 14 Jan 2014 08:28:05 +0000." <290E20B455C66743BE178C5C84F1240847E63346C3@EXMB01CMS.surrey.ac.uk>, <201401142054.s0EKsADA001944@maildrop2.v6ds.occnc.com> In-Reply-To: <201401142054.s0EKsADA001944@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, lars@netapp.com, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 21:45:25 -0000 The HDLC part here is last link, not the scope of the whole path. Any 'low' bit error rate given actually becomes quite high once you consider no of bits per packet and line rate... Do read Jonathan Stone's papers on where errors creep in - not just in the link, by at any point along the path, including regeneration Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 14 January 2014 20:54 To: Wood L Dr (Electronic Eng) Cc: jmh@joelhalpern.com; lars@netapp.com; xuxiaohu@huawei.com; mpls@ietf.or= g; ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard In message <290E20B455C66743BE178C5C84F1240847E63346C3@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > It stands to reason that if tunnelers can turn off udp checksums > because their performance is degraded, they can turn off > congestion control because it will degrade their performance. > > Rest of the internet getting congested and getting > misdelivered corrupted packets? Really not their problem. > > There are important vendors trying to sell products here, > and they need performance to do so. > Get with the program! > > Lloyd Wood > http://about.me/lloydwood OK, perhaps if you are running MPLS/UDP/IP over HDLC and the HDLC configuration is set to count FCS errors but not drop you will still *really* need the UDP checksum. Otherwise its isn't going to do much for you. Any checksum is really bad for some types of errors such as chunk reordering and multiple bit errors. Maybe on HDLC or PPP with 16 bit CRC you may see a low error rate, but in theory that would be much less than 10^-5 since few multiple bit errors will be coincidence match the CRC, even for a 16 bit CRC. I suspect most routers would be able to do the checksum anyway and for modern links if they come up with a zero error count that's fine. Modern OTN based transport networks use forward error correction FEC which accounts for a fair amount of overhead and a lot of processing gates on the receiving end. The measure of effectiveness of given FEC is in dB with 10 dB being a reduction of a factor of 10 in bit errors and typical FEC in the high tens of dB. The target corrected error rate is often 10^-15 or one bit error in 24 hours for 10 Gb/s, one bit error in 2.5 hours for 100 Gb/s. Any link with corrected bit error rates approaching 10^-12 is taken out of service. This is roughly equivalent to the old ES (errored seconds) and SES (severely errored seconds) metric where a ES is one second with any bit errors and an SES is one second with 10 or more errors (I think its 10). More than some number of ES or SES and a link is taken down. The uncorrected errors are passed through. A packet may traverse an entire continent with 2-3 such links separated by regeneration or could stop at a number of routers along the way. Typically today the router uses 10GbE or 100GbE (growing use) which are then passed as a bit stream in the transport network. At the other end the uncorrected errors from transport are picked up by Ethernet 32 bit FCS. Since a 32 bit FCS picks up 100% of single bit errors and most instances where a small number of bits are in error, and all but 1 in 2^32 where many bits are in error, few errors are going to get through. If GFP is used, the per packet FCS is checked at each hop and for GFP-T also checked end to end. A bad local ethernet is more likely to contribute an error (again better than 1 in 2^32 detection is expected) due to something like a bad CAT-{5,5e,6} connection or too many sharp turns. A DSL or DOCSIS link is also more likely to contribute an error. With CRC32 on all links and no bad hardware in between (ie: circa 1990s equipment with no parity RAM and no correction on DMA, buses, etc) you would expect on the order of 10^-8 errors (10^-9 per hop, a few errored hops). For example, two hosts on my home LAN had non-zero tcp checksums. Each had < 10^-6 packet error rate. It is hard to tell if this is host errors at the other end. The only hosts I have with non-zero are on the service provider DMZ LAN so that would include any bot attacks, etc, where sending hosts could be old junk. Host behind those have zero UDP and TCP checksum errors. This seems similar to Stewart's quick check. In the T1/T3 days the transport layer just had parity and just counted parity errors. Providers in those days were notorious for ignoring ES and SES counters until the customer complained. HDLC then had its 16 bit CRC, optional 32 bit. If an ISP wasn't paying attention to their HDLC error counters then it was up to the IP end customer to complain and hope the problem got escallated rather than dropped. As to whether congestion control is in practice needed see http://www.ietf.org/mail-archive/web/mpls/current/msg11222.html Its fine to make them both optional and to make congestion control mechanisms out of scope and the topic of a later document if needed. Curtis > ________________________________________ > From: ietf [ietf-bounces@ietf.org] On Behalf Of Joel M. Halpern [jmh@joel= halpern.com] > Sent: 10 January 2014 15:36 > To: Eggert, Lars; Xuxiaohu > Cc: mpls@ietf.org; IETF > Subject: Re: Last Call: (Encapsulating MP= LS in UDP) to Proposed Standard > > Maybe I am completely missing things, but this looks wrong. > If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion > control will make it more likely that the service won't work. Is that > really the goal? > > We do not perform congestion control on MPLS LSPs. > Assuming that a UDP tunnel is carrying just MPLS and was established > just for MPLS, why would we expect it to behave differently than an MPLS > LSP running over the exact same path, carrying the exact same traffic? > > Yours, > Joel > > On 1/10/14 3:47 AM, Eggert, Lars wrote: > > Hi, > > > > that sounds good. What congestion control are you going to be specifyin= g for your tunnel? > > > > Lars > > > > On 2014-1-10, at 4:46, Xuxiaohu wrote: > > > >> Hi Lars, > >> > >> Thanks a lot for your comments. > >> > >> I wonder whether the following modified text for Congestion Considerat= ion section is OK from your point of view: > >> > >> Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarde= d through "UDP tunnels", the congestion control guidelines for UDP tunnels = as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically, = MPLS can carry a number of different protocols as payloads. When the payloa= d traffic is IP-based and congestion-controlled, the UDP tunnel SHOULD NOT = employ its own congestion control mechanism, because congestion losses of t= unneled traffic will already trigger an appropriate congestion response at = the original senders of the tunneled traffic. When the payload traffic is n= ot known to be IP-based, or is known to be IP-based but not congestion-cont= rolled, the UDP tunnel SHOULD employ an appropriate congestion control mech= anism. Furthermore, because UDP tunnels are usually bulk-transfer applicati= ons as far as the intermediate routers are concerned, the guidelines as def= ined in Section 3.1.1 of [RFC5405] SHOULD apply. > >> > >> Best regards, > >> Xiaohu > >> > >>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >>> =B7=A2=BC=FE=C8=CB: mpls [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED = Eggert, Lars > >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C28=C8=D5 18:22 > >>> =CA=D5=BC=FE=C8=CB: IETF > >>> =B3=AD=CB=CD: mpls@ietf.org > >>> =D6=F7=CC=E2: Re: [mpls] Last Call: (= Encapsulating MPLS > >>> in UDP) to Proposed Standard > >>> > >>> Hi, > >>> > >>> On 2014-1-2, at 16:14, The IESG wrote: > >>>> - 'Encapsulating MPLS in UDP' > >>>> as Proposed Standard > >>> > >>> > >>> this document needs to describe how it addresses the issues raised in= BCP145 > >>> (RFC5405). It already contains some text about messages sizes and con= gestion > >>> considerations, which is great. Unfortunately, the text about congest= ion > >>> considerations is not fully in line with RFC5405. > >>> > >>> Lars > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From l.wood@surrey.ac.uk Tue Jan 14 13:57:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C391AE2B8; Tue, 14 Jan 2014 13:57: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, RCVD_IN_DNSWL_MED=-2.3, 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 26j5X6uQdZK2; Tue, 14 Jan 2014 13:57:44 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0E41AE2AF; Tue, 14 Jan 2014 13:57:43 -0800 (PST) Received: from [193.109.255.147:47627] by server-10.bemta-14.messagelabs.com id D6/81-20752-BC2B5D25; Tue, 14 Jan 2014 21:57:31 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-72.messagelabs.com!1389736650!13624939!3 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13873 invoked from network); 14 Jan 2014 21:57:30 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-14.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 14 Jan 2014 21:57:30 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Tue, 14 Jan 2014 21:57:21 +0000 From: To: , Date: Tue, 14 Jan 2014 21:57:20 +0000 Thread-Topic: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) Thread-Index: Ac8RVjUkh7p2kMNVSGWEekhrdASM3gAHBvko Message-ID: <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com>, <52D58168.9060800@cisco.com> In-Reply-To: <52D58168.9060800@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu, lisp@ietf.org Subject: Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 21:57:46 -0000 I don't think sayng 'oh, that error source is no longer a problem' disprove= s Stone's overall point about undetected errors, though the examples he uses from the technology of the day are necessarily dated. Dismissing the overall point because the examples use obsolete technology is throwing the baby out with the bathwater; a host-to-host error check catches things that intermediate checks cannot. Measuring error rates across end-to-end Internet traffic is something that= has not received much attention , as error detection is not instrumented well - hence citing Stone's published work, in the absence of awareness of anything newer (and as high profile/immediately recognisabl= e as sigcomm) in the area. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: 14 January 2014 18:26 To: curtis@ipv6.occnc.com; Wood L Dr (Electronic Eng) Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; lisp@ietf.org; davi= d.black@emc.com; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu Subject: Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp d= raft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) I agree the paper is now obsolete. Stewart On 14/01/2014 17:06, Curtis Villamizar wrote: > Lloyd, > > Maybe you should reread the paper too before citing it as evidence. > Check the date on it. Check the cited causes of errors. > > Packet traces from 1998 and 1999 are prehaps not so relevante today, > particularly wrt error rates due to hosts, router memories, and link > error rates. Look at the cited caused of errors and realize that many > things have changed. > > The largest single error in the paper (paerhaps as high as 99.9% of > the errors) was the ACK-of-FIN bug in Windows NT. They may have fixed > that by now. Other large causes were host hardware and host software > bugs (sent bad data in the first place). > > One fifth of campus errors were caused by two hosts. This is cited as > a bug in Mac OS on Powermac 8100, fixed at the time of publication. > > A lot of host software errors are discussed, where the checksums are > sent bad and therefore will pass any router link FCS. > > Sending host hardware errors were thought to be in large part caused > by no data integrity check on host DMA transfers. I think progress > has been made on that front. You can check PCIe. It has a 32bit CRC > per lane in the link layer and retransmits on error. > > Router memory errors was thought to play a large role in the non-host > part of the error rate in the paper. Routers use ECC now. Going that > far back they didn't always have parity RAM (and sometimes ran parity > disabled to avoid parity error reloads). > > VJHC software errors? Anyone still use VJHC? Those errors should be > gone. > > IP over HDLC over T1 missed a few errors at the link layer in those > days. That could be true and occurances dependent on the providers. > In the paper that was thought to be a very small contributor. > > Both HDLC and PPP had an option for 16 bit or 32 bit FCS. Often 16 > bit was used. Some HDLC equipment could be and was configured to > count errors and send the packets on their way on the assumption that > it was better to count errors and deliver bad packets rather than > deliver no packet. Perhaps also to hide packet loss. Today all of > the link layers in use have 32 bit FCS and count and toss errored > packets. In most equipment all of the memories have ECC and all of > the buses ECC or FCS if serialized. > > It is now 14 years since that paper was published in Signcomm and 16 > years since some of the observations. Things have changed. Nice bit > of nostangia but that paper may no longer be relevant. > > Curtis > > reference - > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pd= f > > In message <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.a= c.uk> > l.wood@surrey.ac.uk writes: >> Curtis >> >> I suggest reading Stone's work, particularly >> ''When The CRC and TCP Checksum Disagree' >> for discussion of corruption. >> >> Particularly its conclusions: 'In the internet, that means >> we are sending large volumes of incorrect data without >> anyone noticing'. >> >> The Layer-2 check is per link, not end-to-end. That matters. >> >> The MPLS assumption is that it crosses a link with a frame >> checksum. Putting MPLS over UDP breaks that assumption. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Curtis Villamizar [curtis@ipv6.occnc.com] >> Sent: 12 January 2014 18:09 >> To: Wood L Dr (Electronic Eng) >> Cc: adrian@olddog.co.uk; randy@psg.com; gorry@erg.abdn.ac.uk; mpls@ietf.= org; lisp@ietf.org; ietf@ietf.org; david.black@emc.com; jnc@mit.edu; tsvwg@= ietf.org >> Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was= : RE: [tsvwg] Milestones changed for tsvwg WG) >> >> In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.= ac.uk> >> l.wood@surrey.ac.uk writes: >> >>> On nested checksums, the question is how they are nested; it's a matter >>> of scope. With a bunch of checksums checking only a payload and any >>> inner checksums like Russian Matryoshka dolls, the end-to-end argument >>> tells us that for reliable receipt of the payload, only the innermost c= hecksum >>> matters. >>> >>> But here, we are not solely checking the payload, but information on ho= w to >>> deliver and identify that payload - and while an outer Ethernet CRC is = across >>> the last link, the UDP checksum, though weak, provides a check on the I= P >>> addresses and UDP ports (via the pseudoheader check) and MPLS stack >>> from UDP/IP source to UDP/IP destination (and the payload, which is the= bit >>> everyone focuses on as the performance hit as redundant and a processin= g >>> cost when the payload has its own check, and the bit that UDP-Lite can = leave out). >>> >>> Nothing else checks that scope. The scope is wider, and affects the net= work >>> as a whole. Errors in these unchecked fields lead to misdirection and l= ead to >>> misdelivery. Or pollution of other ports. >>> >>> The MPLS assumption is that it's protected and checked by a strong link= CRC like >>> Ethernet, and checked/regenerated by stack processing between hops; her= e, >>> in a path context, with zero UDP checksums MPLS has no checking at all. >> >> That UDP would be running over IP over Ethernet or POS or GFP or ... >> >> There is no layer-2 currently in use that does not have a robust FCS, >> generally a 32 FCS and therefore the MPLS assumption of checking at a >> lower layer is still valid. >> >> Curtis >> >> >>> "consequences for cheap hardware and for software implementations" >>> >>> I'm sorry, when was MPLS cheap? >>> >>> Lloyd Wood >>> http://about.me/lloydwood >>> ________________________________________ >>> From: Adrian Farrel [adrian@olddog.co.uk] >>> Sent: 09 January 2014 10:21 >>> To: Wood L Dr (Electronic Eng); randy@psg.com >>> Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc= .com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org >>> Subject: RE: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (wa= s: RE: [tsvwg] Milestones changed for tsvwg WG) >>> >>> Lloyd and Randy, >>> >>> With respect to draft-ietf-mpls-in-udp, this is why we have IETF last c= alls, so >>> thanks for the comments. >>> >>> We did take the precaution of sending this I-D for an early TSV Directo= rate >>> review because of the concern about a number of factors and the overlap= with >>> tsvwg work, but the review came back "clean". Of course, such a review = is just >>> one person, so this conversation is good. >>> >>> Wrt zero checksum, where do you stand on nested checksums? There is som= e claim >>> that they represent a waste of processing. I am not convinced by that w= hen each >>> layer is using dedicated hardware (that can presumably process checksum= s at line >>> speed), but I am interested in the consequences for cheap hardware and = for >>> software implementations (as have been claimed to be some of the motiva= tions for >>> this work). >>> >>> Other TSV-related issues that surely pop up are: >>> - allocation of ports for foo-in-UDP >>> - congestion control >>> >>> Please note that there are a number of I-Ds that you missed in your bro= ad sweep >>> of "I am opposed". You should probably look at the NVGRE and VXLAN work= (which I >>> think is lurking around the NVO3 working group) because that is also lo= oking at >>> UDP encaps of a tunnelling protocol. >>> >>> Thanks, >>> Adrian >>> >>> Health warnings: >>> I am responsible AD for draft-ietf-mpls-in-udp >>> I am a co-author of the gre-in-udp draft. >>> >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of l.wood@surrey.a= c.uk >>>> Sent: 09 January 2014 08:07 >>>> To: randy@psg.com >>>> Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@em= c.com; >>>> tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org >>>> Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (w= as: RE: >>>> [tsvwg] Milestones changed for tsvwg WG) >>>> >>>> Randy, >>>> >>>> okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's ge= t >>>> consensus on it. And then the authors can adopt that consensus for >>> mpls-in-udp, >>>> which overlaps in authorship... >>>> >>>> thanks, >>>> >>>> Lloyd Wood >>>> http://about.me/lloydwood >>>> ________________________________________ >>>> From: Randy Bush [randy@psg.com] >>>> Sent: 09 January 2014 07:51 >>>> To: Wood L Dr (Electronic Eng) >>>> Cc: david.black@emc.com; gorry@erg.abdn.ac.uk; ietf@ietf.org; mpls@iet= f.org; >>>> jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org >>>> Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE:= [tsvwg] >>>> Milestones changed for tsvwg WG) >>>> >>>>> Because they specify zero UDP checksums, >>>>> I oppose publication of draft-ietf-mpls-in-udp in its current form >>>>> I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its c= urrent >>>> form. >>>>> I oppose the IETF lisp documents. >>>> lloyd, >>>> >>>> i think i understand your position. but i disagree with preventing wg >>>> adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strong= ly >>>> see wg adoption as how we get to discuss and work on a document, not a= s >>>> approval of the document. as david said, i think we need to discuss i= t >>>> so we can decide if it should be fixed. to do so, we have to adopt it= . >>>> >>>> randy > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From wes@mti-systems.com Tue Jan 14 14:07:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F151AE2BC for ; Tue, 14 Jan 2014 14:07:52 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FaEkdaoMHhr for ; Tue, 14 Jan 2014 14:07:51 -0800 (PST) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id E90151AE2B6 for ; Tue, 14 Jan 2014 14:07:50 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s0EM7cZQ032722 for ; Tue, 14 Jan 2014 17:07:38 -0500 Received: (qmail 28498 invoked by uid 0); 14 Jan 2014 22:07:38 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.107?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 14 Jan 2014 22:07:38 -0000 Message-ID: <52D5B524.5080408@mti-systems.com> Date: Tue, 14 Jan 2014 17:07:32 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, stbryant@cisco.com, curtis@ipv6.occnc.com References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com>, <52D58168.9060800@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 22:07:52 -0000 On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: > I don't think sayng 'oh, that error source is no longer a problem' disproves > Stone's overall point about undetected errors, though the > examples he uses from the technology of the day are necessarily > dated. Dismissing the overall point because the examples use obsolete > technology is throwing the baby out with the bathwater; a host-to-host > error check catches things that intermediate checks cannot. > > Measuring error rates across end-to-end Internet traffic is something that has > not received much attention , as error detection is not > instrumented well - hence citing Stone's published work, in the absence > of awareness of anything newer (and as high profile/immediately recognisable > as sigcomm) in the area. > +1 ... the message in the paper is applicable to layered systems and internetworks in general. Changes in the link technology since then don't invalidate it, especially since we know that the technology not only changes rapidly, but also is always growing in diverse directions, such that there things almost universally true today may be turned on their heads tomorrow. Designs for stacking layers need to follow solid general principles in order to be robust to changes (above and below). -- Wes Eddy MTI Systems From stbryant@cisco.com Tue Jan 14 14:46:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5EF1AE1DA; Tue, 14 Jan 2014 14:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 FL7ahKNLKCyc; Tue, 14 Jan 2014 14:46:30 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id B44B91ADFF3; Tue, 14 Jan 2014 14:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2042; q=dns/txt; s=iport; t=1389739579; x=1390949179; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b+SywIMTAblM9fWu2hAcy5jAKn01lzQaY41AddoBwHw=; b=cOu1uNj5AxFHOfLYjoNWnyhK4w0jOorac2i426vRM9UorERgDlLV9WXA xIkEVty/4owA6YAy1Gw00wMRxrPMEGJkeGM/ThzPb0ghWPjyOfMr/ayYy vIpmSj/F4iiyhhVJT9PzfAVmBiRPCcehQqUEQgQOA5B/yZY9o+CLAihhy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAAq91VKQ/khR/2dsb2JhbABaDoJ9u32BGRZ0giUBAQEEODwEARALDgoJFgQLCQMCAQIBRQYBDAEFAgEBiADEHxePBweENwEDlDiDZpIVgW9/Pw X-IronPort-AV: E=Sophos;i="4.95,659,1384300800"; d="scan'208";a="3628620" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 14 Jan 2014 22:46:17 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0EMkHAi001167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 22:46:17 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0EMkFsF021730; Tue, 14 Jan 2014 22:46:15 GMT Message-ID: <52D5BE37.4070301@cisco.com> Date: Tue, 14 Jan 2014 22:46:15 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Wesley Eddy , l.wood@surrey.ac.uk, curtis@ipv6.occnc.com References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com>, <52D58168.9060800@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> <52D5B524.5080408@mti-systems.com> In-Reply-To: <52D5B524.5080408@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 22:46:32 -0000 On 14/01/2014 22:07, Wesley Eddy wrote: > On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: >> I don't think sayng 'oh, that error source is no longer a problem' disproves >> Stone's overall point about undetected errors, though the >> examples he uses from the technology of the day are necessarily >> dated. Dismissing the overall point because the examples use obsolete >> technology is throwing the baby out with the bathwater; a host-to-host >> error check catches things that intermediate checks cannot. >> >> Measuring error rates across end-to-end Internet traffic is something that has >> not received much attention , as error detection is not >> instrumented well - hence citing Stone's published work, in the absence >> of awareness of anything newer (and as high profile/immediately recognisable >> as sigcomm) in the area. >> > > +1 ... the message in the paper is applicable to layered systems > and internetworks in general. Changes in the link technology > since then don't invalidate it, especially since we know that > the technology not only changes rapidly, but also is always > growing in diverse directions, such that there things almost > universally true today may be turned on their heads tomorrow. > > Designs for stacking layers need to follow solid general > principles in order to be robust to changes (above and below). > Note that it is not only the link layer technology that has moved on, the signal integrity of the h/w at all stages of the design and implementation process has moved on. Can we agree that the statistics in the paper are discredited? If not, why not? What is the error rate in modern h/w and network systems? Is this significant in the application under consideration? Finally if we are really concerned that we do actually need a c/s (I am not in tunnel applications) why are we still happy to use what is frankly a pathetic check in modern terms? Why for example are we not moving to something like the Fletcher 64 bit c/s? Stewart From l.wood@surrey.ac.uk Tue Jan 14 15:05:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBBF1AE2D2; Tue, 14 Jan 2014 15:05:58 -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, 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 xqvsxLNQq3Rn; Tue, 14 Jan 2014 15:05:56 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.161]) by ietfa.amsl.com (Postfix) with ESMTP id 58F8E1AE2B1; Tue, 14 Jan 2014 15:05:55 -0800 (PST) Received: from [195.245.230.131:34421] by server-1.bemta-3.messagelabs.com id 15/81-29598-5C2C5D25; Tue, 14 Jan 2014 23:05:41 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-78.messagelabs.com!1389740738!32661185!3 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10751 invoked from network); 14 Jan 2014 23:05:41 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-12.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 14 Jan 2014 23:05:41 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Tue, 14 Jan 2014 23:05:14 +0000 From: To: , , Date: Tue, 14 Jan 2014 23:05:14 +0000 Thread-Topic: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) Thread-Index: Ac8RenDjEgxt8NsvTwOY15/OAFCPrwAAX68d Message-ID: <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com>, <52D58168.9060800@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> <52D5B524.5080408@mti-systems.com>,<52D5BE37.4070301@cisco.com> In-Reply-To: <52D5BE37.4070301@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 23:05:58 -0000 Stewart, your 'I'm not in tunnel applications' suggests you've misunderstood the argument here. The point is not to protect the tunnel traffic (which can quite happily checksum itself), it is to protect everything else on the network from misdelivery. It's not the tunnel application, it's every application sharing the internet with the tunnel which has UDP checksums turned off. See all of RFC 6936 section 3.1. Tunnel is fine, sideeffects of misdelivery do not affect tunnel. And in IPv4 and IPv6, the pseudo-header checksum built into TCP and UDP is all we have. IPv6 deliberately copied v4 here. > What is the error rate in modern h/w and network systems? No-one measures end-to-end misdelivery. No-one knows. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: 14 January 2014 22:46 To: Wesley Eddy; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvw= g@ietf.org; jnc@mit.edu; lisp@ietf.org Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-= in-udp draft (was: RE: Milestones changed for tsvwg WG)) On 14/01/2014 22:07, Wesley Eddy wrote: > On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: >> I don't think sayng 'oh, that error source is no longer a problem' dispr= oves >> Stone's overall point about undetected errors, though the >> examples he uses from the technology of the day are necessarily >> dated. Dismissing the overall point because the examples use obsolete >> technology is throwing the baby out with the bathwater; a host-to-host >> error check catches things that intermediate checks cannot. >> >> Measuring error rates across end-to-end Internet traffic is something t= hat has >> not received much attention , as error detection is not >> instrumented well - hence citing Stone's published work, in the absence >> of awareness of anything newer (and as high profile/immediately recognis= able >> as sigcomm) in the area. >> > > +1 ... the message in the paper is applicable to layered systems > and internetworks in general. Changes in the link technology > since then don't invalidate it, especially since we know that > the technology not only changes rapidly, but also is always > growing in diverse directions, such that there things almost > universally true today may be turned on their heads tomorrow. > > Designs for stacking layers need to follow solid general > principles in order to be robust to changes (above and below). > Note that it is not only the link layer technology that has moved on, the signal integrity of the h/w at all stages of the design and implementation process has moved on. Can we agree that the statistics in the paper are discredited? If not, why not? What is the error rate in modern h/w and network systems? Is this significant in the application under consideration? Finally if we are really concerned that we do actually need a c/s (I am not in tunnel applications) why are we still happy to use what is frankly a pathetic check in modern terms? Why for example are we not moving to something like the Fletcher 64 bit c/s? Stewart= From curtis@ipv6.occnc.com Tue Jan 14 16:40:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21FE1AE194; Tue, 14 Jan 2014 16:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 p8fZwABG8QJj; Tue, 14 Jan 2014 16:40:54 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 10B7F1ADF47; Tue, 14 Jan 2014 16:40:53 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F0eZXj005169; Tue, 14 Jan 2014 19:40:35 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401150040.s0F0eZXj005169@maildrop2.v6ds.occnc.com> To: "Eggert, Lars" From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 15:20:17 +0000." Date: Tue, 14 Jan 2014 19:40:34 -0500 Cc: "mpls@ietf.org" , Scott Brim , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 00:40:56 -0000 In message "Eggert, Lars" writes: > On 2014-1-14, at 15:20, Stewart Bryant wrote: > > Yes, the inner (real) transport header is the only meaningful place > > to apply congestion avoidance. > > But what if the inner traffic isn't congestion controlled? > > Lars Lars, The exact same thing will happen in all of the following cases: NON-congestion controlled application --over-- UDP --over-- IP --over-- L2 NON-congestion controlled application --over-- UDP --over-- IP --over-- MPLS --over-- L2 NON-congestion controlled application --over-- UDP --over-- IP --over-- MPLS --over-- UDP --over-- IP --over-- L2 The non-congestion controlled application is what needs fixing. It would be wrong to try to put congestion control at every layer underneath the non-congestion controlled application except perhaps as a transparent replacement for UDP and that is out of scope for a draft-ietf-mpls-in-udp discussion. Curtis From curtis@ipv6.occnc.com Tue Jan 14 16:46:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7541AE1C9; Tue, 14 Jan 2014 16:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 RS8B2miUdmOu; Tue, 14 Jan 2014 16:46:41 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E81AE1B0; Tue, 14 Jan 2014 16:46:40 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F0kQr8005435; Tue, 14 Jan 2014 19:46:26 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401150046.s0F0kQr8005435@maildrop2.v6ds.occnc.com> To: "Joel M. Halpern" From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 10:23:59 -0500." <52D5568F.2070600@joelhalpern.com> Date: Tue, 14 Jan 2014 19:46:26 -0500 Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list , Scott Brim Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 00:46:42 -0000 In message <52D5568F.2070600@joelhalpern.com> "Joel M. Halpern" writes: > Isn't that basically the problem of the inner traffic sender, not the > problem of the tunnel that is carrying the traffic? > Asking tunnel's to solve the problem of applications with undesirable > behavior seems backwards. > > Yours, > Joel Or perhaps the job of some form of very fair AQM like SFQ. Any tunneling complicates the AQM notion of what a flow is and therefore may affect its assessment of what is fair in bad ways. This too is out of scope for a draft-ietf-mpls-in-udp discussion. Curtis > On 1/14/14 10:20 AM, Eggert, Lars wrote: > > On 2014-1-14, at 15:20, Stewart Bryant wrote: > >> Yes, the inner (real) transport header is the only meaningful place > >> to apply congestion avoidance. > > > > But what if the inner traffic isn't congestion controlled? > > > > Lars From curtis@ipv6.occnc.com Tue Jan 14 17:00:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3901D1AE008; Tue, 14 Jan 2014 17:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.538, 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 PYBy_y0qPvtu; Tue, 14 Jan 2014 17:00:26 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id B20381ADFDD; Tue, 14 Jan 2014 17:00:25 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F10C7J005674; Tue, 14 Jan 2014 20:00:12 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401150100.s0F10C7J005674@maildrop2.v6ds.occnc.com> To: "Eggert, Lars" From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 15:29:38 +0000." <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> Date: Tue, 14 Jan 2014 20:00:12 -0500 Cc: "mpls@ietf.org" , Scott Brim , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 01:00:27 -0000 In message <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> "Eggert, Lars" writes: > Hi, > > On 2014-1-14, at 16:23, Joel M. Halpern wrote: > > Isn't that basically the problem of the inner traffic sender, not the > > problem of the tunnel that is carrying the traffic? > > no, because the sender of the inner traffic may be blasting some > L2traffic, for an L2 where that is OK behavior. But that traffic is > nowbeing encapsulated inside UDP and can hence go anywhere on the > net*without the sender being aware of this*. That application would be a PW application and it would be more appropriate to fix that in PW if there is consensus for a need to do so, which afaik there is not. > > Asking tunnel's to solve the problem of applications with > > undesirablebehavior seems backwards. > > It is the *tunnel* that performs the encapsulation and allows > thattraffic to go places it couldn't before. And so it's the > tunnel'sresponsibility to make sure that the traffic it injects into > theInternet complies with the BCPs we have on congestion control. > > Lars If it is a service provider encapsulating traffic within their own network, then they know what they are doing. That is the anticipated use and among that community there is no consensus for need for congestion control. If it is some hostile hosts trying to send MPLS over UDP over IP, they, being hostile, are going to disable any congestion control. Besides, no hostile host has a T1 to tunnel over the Internet so they would be sending the same traffic they would normally just send of UDP over IP. Anything made up of frames (Ethernet, ATM, FR) over PW over MPLS is carrying IP and if frames drop, the IP applications see the drop and behave just as they would for any drop. (ATM shreadding thread to /dev/null please). If congestion aware or using a congestion aware transport, the top level applications are still congestion aware. If congestion ignoreant, they are still congestion ignoreant. If hostile, they are still hostile. Back to draft-ietf-mpls-in-udp. I think the most recent text proposed by the author is fine. Curtis From curtis@ipv6.occnc.com Tue Jan 14 17:13:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A4B1AE119; Tue, 14 Jan 2014 17:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 SdF59sbrdKAy; Tue, 14 Jan 2014 17:13:55 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id C1A6C1ADFD1; Tue, 14 Jan 2014 17:13:54 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F1DXSN005803; Tue, 14 Jan 2014 20:13:42 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401150113.s0F1DXSN005803@maildrop2.v6ds.occnc.com> To: Wesley Eddy From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 11:22:02 -0500." <52D5642A.7090103@mti-systems.com> Date: Tue, 14 Jan 2014 20:13:33 -0500 Cc: Scott Brim , "Eggert, Lars" , IETF discussion list , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 01:13:56 -0000 In message <52D5642A.7090103@mti-systems.com> Wesley Eddy writes: > On 1/14/2014 11:06 AM, Eggert, Lars wrote: > > Hi, > > > > On 2014-1-14, at 16:39, Scott Brim wrote: > >> Lars, I know we're repeating arguments from the last decade. The > >> choice is between (1) specifying congestion control around the > >> substrate UDP that can be turned off if it causes problems, or (2) > >> specifying nothing at this time and adding it later if operators want > >> it. > >> > >> I guess if this can be written as a SHOULD, up to the implementor's > >> discretion, then okay. > > > > I don't think we can leave this up to implementors discretion. We've had IETF consensus that Internet communication requires congestion control at least since RFC2914. A circuit breaker mechanisms seems straightforward to implement. > > > > As is, I object to this document going forward. The minor benefits of getting some better load balancing for MPLS are far outweighed by the risks. > > > > (I'm also going to shut up now, and let others speak. I think I've said my bit.) > > > > > I'm in basic agreement. > > Assuming we might all agree that there are conceivable scenarios where > a circuit breaker mechanism would be useful, is the real issue that > we don't all agree that it could be implemented in a way that's not > burdensome and doesn't degrade performance unnecessarily? > > Or is there still fundamental disagreement about whether the scenarios > where the circuit breaker is useful are even valid? A circuit breaker (drop all traffic on sign of congestion) at the MPLS over UDP level would be the worst thing you could specify and IMO it would guarentee zero implementations. A circuit breaker might be appropriate for TDM over PW but nothing else. This makes sense because TDM cannot change its bandwidth so the only choice is to shut it off. TDM over PW is an application that can run over MPLS (or GRE or L2TP). The best place to put that circuit breaker (if anywhere at all) is in TDM over PW. Curtis From ryoo@etri.re.kr Tue Jan 14 17:30:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B7D1AE1FF for ; Tue, 14 Jan 2014 17:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, 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 xYJ7BD5ywLtF for ; Tue, 14 Jan 2014 17:30:39 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id D2E2E1AE1F1 for ; Tue, 14 Jan 2014 17:30:38 -0800 (PST) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Jan 2014 10:30:28 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Wed, 15 Jan 2014 10:30:24 +0900 From: =?utf-8?B?66WY7KCV64+Z?= To: Loa Andersson , Yaacov Weingarten Thread-Topic: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHO9ATofTfzY1WrTkK6rDh0YabjsJpMSsLJgAAiYoCAGZTyhP//kS+AgAHUA6qAAxSFgIAGUXCZ///9boCAFG65gg== Date: Wed, 15 Jan 2014 01:30:23 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B1350@SMTP2.etri.info> References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info>, <52BBD59D.8000104@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEFF9@SMTP2.etri.info>, <52BFF3AB.3070609@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AF703@SMTP2.etri.info>, <52C53E51.9060307@pi.nu> In-Reply-To: <52C53E51.9060307@pi.nu> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B1350SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: [mpls] =?utf-8?b?7ZqM7IugOiAgUXVlc3Rpb24gcmVnYXJkaW5nIFNEIHByb3Rl?= =?utf-8?q?ction_in_draft-ietf-mpls-tp-psc-itu?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 01:30:45 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B1350SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClRoaXMgZW1haWwgaXMgdG8gc3VtbWFyaXplIHRoZSBpc3N1ZSB3aXRoIHRo ZSBTRCBwcm90ZWN0aW9uIGFuZCB0byBwcm9wb3NlIGEgcmVzb2x1dGlvbi4NCg0KVGhlIGlzc3Vl IHdpdGggdGhlIFNEIHByb3RlY3Rpb24gaGFzIGJlZW4gcmFpc2VkIGJ5IFlhYWNvdiBhIG1vbnRo IGFnby4NCkhpcyBtYWluIGFyZ3VtZW50IHdhcyB0aGF0IGN1cnJlbnQgZGVzY3JpcHRpb24gb24g U0QgcHJvdGVjdGlvbiBkZXNjcmliZWQgaW4gU2VjdGlvbiA3LjMgc2VlbWVkIHRvIGluZGljYXRl IHRoZSBiZWhhdmlvciBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgU0QgZGV0ZWN0aW9uIG1ldGhvZC4N Cg0KRXZlbiBhZnRlciBhIGZldyBlbWFpbCBleGNoYW5nZXMgdG8gY2xhcmlmeSB0aGUgb3BlcmF0 aW9uIG9mIFNEIHByb3RlY3Rpb24sIGVzcGVjaWFsbHkgdGhlIG9wZXJhdGlvbiBvZiB0aGUgYnJp ZGdlIHVzZWQgaW4gU0QgcHJvdGVjdGlvbiwgSSB3YXMgbm90IGFibGUgdG8gcmVjb2duaXplIHRo ZSBtYWluIHNvdXJjZSBvZiB0aGUgaXNzdWUgdW50aWwgc29tZSBvZiBwZW9wbGUsIFlhYWNvdiwg SHV1YiwgTG9hIGFuZCBteXNlbGYsIGRpc2N1c3NlZCBpbiBwcml2YXRlIG9mZiB0aGUgV0cgbGlz dCAoc29ycnkgZm9yIGJlaW5nIG9mZiB0aGUgV0cgbGlzdCkuDQoNCkZpbmFsbHksIHdlIGFncmVl ZCBvbiB0aGUgZm9sbG93aW5nIHRleHQgdG8gcmVwbGFjZSB0aGUgZm91cnRoIHBhcmFncmFwaCwg c3RhcnRpbmcgd2l0aCAiSWYgdGhlIGRldGVjdGlvbiBvZiBhIFNEIGRlcGVuZHMgb24gdGhlIHBy ZXNlbmNlIG9mIHVzZXIgZGF0YSBwYWNrZXRzIC4uLiIgaW4gU2VjdGlvbiA3LjM6DQotLS0tLS0N ClByb3RlY3Rpb24gc3dpdGNoaW5nIGFnYWluc3QgU0QgaXMgYWx3YXlzIHByb3ZpZGVkIGJ5IGEg c2VsZWN0b3IgYnJpZGdlIGR1cGxpY2F0aW5nIHVzZXIgZGF0YSB0cmFmZmljIGFuZCBmZWVkaW5n IGl0IHRvIGJvdGggd29ya2luZyBhbmQgcHJvdGVjdGlvbiBwYXRocyB1bmRlciBTRCBjb25kaXRp b24uIEluIHJldmVydGl2ZSBtb2RlLCB3aGVuIHRoZSBXVFIgdGltZXIgZXhwaXJlcyB0aGUgcGFj a2V0IGR1cGxpY2F0aW9uIFNIQUxMIGJlIHN0b3BwZWQgYW5kIHRoZSB1c2VyIGRhdGEgdHJhZmZp YyBTSEFMTCBiZSB0cmFuc3BvcnRlZCBvbiB0aGUgd29ya2luZyBwYXRoIG9ubHkuIEluIG5vbi1y ZXZlcnRpdmUgbW9kZSwgd2hlbiBTRCBpcyBjbGVhcmVkIHRoZSBwYWNrZXQgZHVwbGljYXRpb24g U0hBTEwgYmUgc3RvcHBlZCBhbmQgdGhlIHVzZXIgZGF0YSB0cmFmZmljIFNIQUxMIGJlIHRyYW5z cG9ydGVkIG9uIHRoZSBwcm90ZWN0aW9uIHBhdGggb25seS4NCi0tLS0tLQ0KDQpIb3dldmVyLCBp biB0aGUgZGlzY3Vzc2lvbiBhYm91dCB0aGUgdGV4dCB3aXRoIEVyaWMgR3JheSwgaGUgZnVydGhl ciBtYWRlIHRoZSBjb21tZW50cyBvbiB0aGUgb3BlcmF0aW9uIG9mIHRoZSBicmlkZ2UsIGFuZCBJ IGFtIG5vdyBwcm9wb3NpbmcgdGhlIGZvbGxvd2luZyB0ZXh0Og0KLS0tLS0tDQpQcm90ZWN0aW9u IHN3aXRjaGluZyBhZ2FpbnN0IFNEIGlzIGFsd2F5cyBwcm92aWRlZCBieSBhIHNlbGVjdG9yIGJy aWRnZSBkdXBsaWNhdGluZyB1c2VyIGRhdGEgdHJhZmZpYyBhbmQgZmVlZGluZyBpdCB0byBib3Ro IHRoZSB3b3JraW5nIHBhdGggYW5kIHRoZSBwcm90ZWN0aW9uIHBhdGggdW5kZXIgU0QgY29uZGl0 aW9uLiBXaGVuIGEgbG9jYWwgb3IgcmVtb3RlIFNEIG9jY3VycyBvbiBlaXRoZXIgdGhlIHdvcmtp bmcgcGF0aCBvciB0aGUgcHJvdGVjdGlvbiBwYXRoLCB0aGUgTEVSIFNIQUxMIGR1cGxpY2F0ZSB1 c2VyIGRhdGEgdHJhZmZpYyBhbmQgU0hBTEwgZmVlZCB0byBib3RoIHRoZSB3b3JraW5nIHBhdGgg YW5kIHRoZSBwcm90ZWN0aW9uIHBhdGguIFRoZSBwYWNrZXQgZHVwbGljYXRpb24gU0hBTEwgY29u dGludWUgYXMgbG9uZyBhcyBhbnkgU0QgY29uZGl0aW9uIGV4aXN0cyBpbiB0aGUgcHJvdGVjdGVk IGRvbWFpbiwgYW5kIFNIQUxMIHN0b3Agd2hlbiB0aGVyZSBpcyBubyBTRCBjb25kaXRpb24uIEFk ZGl0aW9uYWxseSwgdGhlIHBhY2tldCBkdXBsaWNhdGlvbiBTSEFMTCBjb250aW51ZSBpbiB0aGUg V1RSIHN0YXRlIGluIHJldmVydGl2ZSBtb2RlLiBJbiBub24tcmV2ZXJ0aXZlIG1vZGUsIHRoZSBw YWNrZXQgZHVwbGljYXRpb24gU0hBTEwgc3RvcCB3aGVuIHRoZXJlIGlzIG5vIFNEIGNvbmRpdGlv bi4NCi0tLS0tLQ0KSWYgeW91IGhhdmUgYW55IGNvbW1lbnRzIG9uIHRoaXMgcHJvcG9zYWwsIHBs ZWFzZSBsZXQgdXMga25vdy4NCk90aGVyd2lzZSwgSSB3aWxsIHB1dCB0aGUgcHJvcG9zZWQgdGV4 dCBpbiB0aGUgcmV2aXNpb24gb2YgdGhlIGRyYWZ0Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tIDogIkxvYSBBbmRlcnNzb24i IDxsb2FAcGkubnU+DQpTZW50IDogMjAxNC0wMS0wMiAxOToyNDoyOCAoICswOTowMCApDQpUbyA6 IOulmOygleuPmSA8cnlvb0BldHJpLnJlLmtyPiwgWWFhY292IFdlaW5nYXJ0ZW4gPHd5YWFjb3ZA Z21haWwuY29tPg0KQ2MgOiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPiwgZHJhZnQtaWV0 Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcgPGRyYWZ0LWlldGYtbXBscy10cC1wc2Mt aXR1QHRvb2xzLmlldGYub3JnPg0KU3ViamVjdCA6IFJlOiBbbXBsc10gUXVlc3Rpb24gcmVnYXJk aW5nIFNEIHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCg0KSmVvbmct ZG9uZywNCg0KSSBjb3VsZCB0cnksIGJ1dCB0aGF0IHdvdWxkIGJlIGEgbm92aWNlIHN0dW1ibGlu ZyBhcm91bmQuDQoNCkknZCBsaWtlIFlhYWNvIGFuZCBIdXViIHRvIHRha2UgYXQgc3BpbiBhdCB0 aGlzIGZpcnN0LCBJIGJlbGlldmUNCnRoYXQgdGhleSBoYXZlIGEgYmV0dGVyIGNoYW5jZSB0byB6 b29tIGluIG9uIHdoYXQgaXMgY3J1Y2lhbCBmcm9tDQp0aGUgYmVnaW5uaW5nLg0KDQovTG9hDQoN Ck9uIDIwMTQtMDEtMDIgMDk6MzksIFJ5b28sIEplb25nLWRvbmcgd3JvdGU6DQo+IExvYSwgdGhh bmtzIGZvciB0aGUgZW1haWwuDQo+IEkgZ290IHRoZSBwb2ludCBub3cuDQo+IEFzIHlvdSBtZW50 aW9uZWQgaW4gdGhlIGxhc3QgcGFydCBvZiB5b3VyIGVtYWlsLCB3ZSdkIGJldHRlciBmaW5kIHRo ZSB0ZXh0Lg0KPiBEbyB5b3UgaGF2ZSBhbnkgdGV4dCB0byBwcm9wb3NlPw0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IEplb25nLWRvbmcNCj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICpGcm9tIDogKiJM b2EgQW5kZXJzc29uIg0KPiAqU2VudCA6ICoyMDEzLTEyLTI5IDE5OjA0OjM4ICggKzA5OjAwICkN Cj4gKlRvIDogKlJ5b28sIEplb25nLWRvbmcgLCBZYWFjb3YgV2VpbmdhcnRlbg0KPg0KPiAqQ2Mg OiAqbXBsc0BpZXRmLm9yZyAsDQo+IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmll dGYub3JnDQo+DQo+ICpTdWJqZWN0IDogKlJlOiBbbXBsc10gUXVlc3Rpb24gcmVnYXJkaW5nIFNE IHByb3RlY3Rpb24gaW4NCj4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCj4NCj4gSmVvbmct ZG9uZywNCj4NCj4gSSBnb3QgY29uZmxpY3RpbmcgYW5zd2VycyB5b3UgYW5kIEh1dWIuIEkgZG9u J3QgaW1tZWRpYXRlbHkgd2FudCB0bw0KPiBjaGFuZ2UgdGhlIHRleHQgaW4gdGhlIGRvY3VtZW50 LCBidXQgcmF0aGVyIHVuZGVyc3RhbmQgaWYgaXQgbmVlZHMgdG8NCj4gYmUgY2hhbmdlZCB0byBn aXZlIGEgY29udGV4dCB0byByZXNvbHZlIFlhYWNvdidzIGNvbW1lbnRzLg0KPg0KPiBUaGUgcG9p bnQgSSB3YXMgdHJ5aW5nIHRvIG1ha2Ugd2FzIHRoYXQgeW91IGFuZCBZYWFjb3Ygc3RhbmQgb24g dHdvDQo+IGRpZmZlcmVudCBtb3VudGFpbnMgKG5ldHdvcmsgbGF5ZXJpbmcgbW9kZWxzKSBhbmQg Y2FuJ3QgYWdyZWUgaWYgeW91DQo+IHNlZSB0aGUgc3VuIHNldCBvciBub3QuIFlvdSBzYXkgeW91 IGNhbiwgYnV0IFlhYWNvIGRvbid0IGFncmVlLCBzaW5jZQ0KPiB0aGUgc3VuIGRpc2FwcGVhcmVk IGJlaGluZCB0aGUgbW91bnRhaW4geW91IGFyZSBzdGFuZGluZyBvbiBtb3JlIHRoYW4NCj4gYW4g aG91ciBhZ28uDQo+DQo+IFdoYXQgSSB0aGluayBoYXBwZW5zIGlzIHRoYXQgeW91IHRoaW5rIGFi b3V0IHByb3RlY3Rpb24gc3dpdGNoaW5nLA0KPiBzZWxlY3RvciBhbmQgYnJpZGdlIGluIHRoZSB0 ZXJtcyBvZiB0aGUgbW9kZWwgeW91IGFyZSB1c2VkIHRvLg0KPg0KPiBXaGVuIFlhYWNvdiBoZWFy IHRoYXQgaGUgdGhpbmtzIGFib3V0IHRoZW0gdGhlIHdheSBoZSBpcyB1c2VkIHRvIHVzZQ0KPiB0 aGVtIGZyb20gaGlzIG1vZGVsLg0KPg0KPiBOZWl0aGVyIG1vZGVsIGlzICJyaWdodCBvciB3cm9u ZyIgKGJvdGggbW91bnRhaW5zIGFyZSByZWFsKSBidXQgdGhlIGFyZQ0KPiBkaWZmZXJlbnQuDQo+ DQo+IFdoYXQgSSB0cmllZCB0byBzYXkgd2FzIHRoYXQgd2hlbiBZYWFjb3YgdGhpbmtzIGFib3V0 IGFzIHBoeXNpY2FsDQo+IG9iamVjdHMsIHdoaWxlIHlvdSBzZWVtIHRvIHVzZSB0aGVtIGFzIGEg Y2xhc3MgbmFtZSwgcGVyZm9ybWluZyB0aGUNCj4gc2FtZSBmdW5jdGlvbiBmb3IgYW55IGxheWVy LCBidXQgYWxzbyBpbXBsZW1lbnRlZCBkaWZmZXJlbnRseSBvbg0KPiBlYWNoIGxheWVyLg0KPg0K PiBJIHRoaW5rIHRoaXMgd2FzIHdoYXQgSHV1YiBhZ3JlZWQgdG8sIHJpZ2h0Pw0KPg0KPiBZYWFj b3Ygc3RlcCBvZiB0aGlzIHRyYWluIGhlcmUgaWYgeW91IGRvbid0IGFncmVlIQ0KPg0KPiBTbyB3 aGF0IEkgaW50ZW5kZWQgdG8gdG8gd2FzIHRvIGtlZXAgdGhlIGNsYXNzIG5hbWUgKGZvciBldmVy eSBleGlzdGluZw0KPiBicmlkZ2UgYW5kIHNlbGVjdG9yLCBjYWxsaW5nIHRoZW0ganVzdCB0aGF0 KSBhbmQgem9vbSBvbSBvbiBlLmcuIG9uZQ0KPiBuZXR3b3JrIGxheWVyaW5nIGluc3RhbmNlIG9m IHRoZSBjbGFzcywgdGFsa2luZyBhYm91dCAibXBscyBzZWxlY3Rvcg0KPiBmdW5jdGlvbiIgYW5k ICJtcGxzIGJyaWRnZSBmdW5jdGlvbiIuDQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgSSdtIG5vdCBz dWdnZXN0aW5nIG5hbWVzIG9yIHRlcm1pbm9sb2d5LCBqdXN0IHRyeWluZw0KPiB0byBmaWd1cmUg b3V0IGl0IGlmIHRoaXMgaXMgdGhlIHdoeSB5b3UgZG9uJ3Qgc2VlbSB0byBhZ3JlZS4NCj4NCj4g SWYgd2UgYWdyZWUgd2hhdCB0aGUgcHJvYmxlbSBpcyB0aGVuIGl0IGlzIGZhaXJseSBlYXN5IHRv IGZpbmQgdGhlDQo+IHRleHQgdGhhdCBuZWVkcyB0byBnbyBpbnRvIHRoZSBkb2N1bWVudC4NCj4N Cj4gL0xvYQ0KPg0KPiBPbiAyMDEzLTEyLTI3IDEwOjQxLCBSeW9vLCBKZW9uZy1kb25nIHdyb3Rl Og0KPiA+IExvYSwNCj4gPiBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9u IGNvcnJlY3RseSwgYnV0IEkgd291bGQgc2F5IHRoYXQ6DQo+ID4gRWFjaCBsYXllciBoYXMgaXRz IG93biBicmlkZ2UgYW5kIHNlbGVjdG9yIGZvciBwcm90ZWN0aW9uIHN3aXRjaGluZywgc28NCj4g PiB0aGF0IGVhY2ggbGF5ZXIgY2FuIHBlcmZvcm0gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb2YgaXRz IG93bi4NCj4gPiBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgImJyaWRnZS9zZWxlY3Rv ciBmdW5jdGlvbiIsIGJ1dCBpbiBJVFUtVA0KPiA+IHRlcm1pbm9sb2d5LCB0aGUgYnJpZGdlIGFu ZCBzZWxlY3RvciBhcmUgaW5jbHVkZWQgaW4gImNvbm5lY3Rpb24NCj4gPiBmdW5jdGlvbiIgb2Yg aXRzIG93biBsYXllciAoZm9yIGV4YW1wbGUsIE1UX0MgZm9yIE1QTFMtVFAgY29ubmVjdGlvbg0K PiA+IGZ1bmN0aW9uLCB3aGljaCBpbmNsdWRlcyB0aGUgYnJpZGdlIGFuZCB0aGUgc2VsZWN0b3Ig Zm9yIHRoZSBNUExTLVRQDQo+ID4gbGF5ZXIpLg0KPiA+IEZvciB0aGUgUFNDIFJGQywgSSBkb24n dCB0aGluayB3ZSBuZWVkIHRvIGludHJvZHVjZSBhbnkgbmV3IHRlcm1pbm9sb2d5DQo+ID4gc3Vj aCBhcyB0aGUgImJyaWRnZS9zZWxlY3RvciBmdW5jdGlvbiIgb3IgImNvbm5lY3Rpb24gZnVuY3Rp b24iLg0KPiA+IFRoZSBicmlkZ2Uvc2VsZWN0b3IgaGF2ZSBhbHJlYWR5IGJlZW4gaW50cm9kdWNl ZCBpbiB0aGUgUkZDNjM3OCAoTVBMUy1UUA0KPiA+IGxpbmVhciBwcm90ZWN0aW9uKS4NCj4gPiBC ZXN0IHJlZ2FyZHMsDQo+ID4gSmVvbmctZG9uZw0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ID4gKkZyb20gOiAqIkxvYSBBbmRlcnNzb24iDQo+ID4gKlNlbnQgOiAqMjAxMy0xMi0yNiAxNjow NzoxNSAoICswOTowMCApDQo+ID4gKlRvIDogKlJ5b28sIEplb25nLWRvbmcgLCBZYWFjb3YgV2Vp bmdhcnRlbg0KPiA+DQo+ID4gKkNjIDogKm1wbHNAaWV0Zi5vcmcgLA0KPiA+IGRyYWZ0LWlldGYt bXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnDQo+ID4NCj4gPiAqU3ViamVjdCA6ICpSZTog W21wbHNdIFF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9uIGluDQo+ID4gZHJhZnQtaWV0 Zi1tcGxzLXRwLXBzYy1pdHUNCj4gPg0KPiA+IEplb25nLWRvbmcsDQo+ID4NCj4gPiBJcyB0aGlz IHNpbXBseSBhIG1hdHRlciBvZiB0ZXJtaW5vbG9neS4gRWFjaCBsYXllciBuZWVkcyB0byBwZXJm b3JtIGl0cw0KPiA+IG93biBwcm90ZWN0aW9uIHN3aXRjaGluZywgaS5lLiB0aGVyZSBoYXMgdG8g YmUgYSAqYnJpZGdlIGZ1bnRpb24qIGFuZCBhDQo+ID4gKnNlbGVjdG9yIGZ1bmN0aW9uKiAob24g ZWFjaCBsYXllciBkZXBlbmRpbmcgb24gdGhlIGltcGxlbWVudGF0aW9uKTsNCj4gPiB3aGlsZSAq YnJpZGdlKiBhbmQgKnNlbGVjdG9yKiBhcmUgdGhlIHBoeXNpY2FsIGxheWVyIGVudGl0aWVzPw0K PiA+DQo+ID4gL0xvYQ0KPiA+DQo+ID4gT24gMjAxMy0xMi0yNiAxMjo1MSwgUnlvbywgSmVvbmct ZG9uZyB3cm90ZToNCj4gPiA+IFlhYWNvdiwgdGhhbmtzIGZvciB5b3VyIGVtYWlsLiBTb21laG93 LCBJIGZvcmdvdCB0byByZXNwb25kIGFuZCBhbQ0KPiBzb3JyeQ0KPiA+ID4gZm9yIHRoZSBkZWxh eS4NCj4gPiA+DQo+ID4gPiBGaXJzdCBvZiBhbGwsIFlhYWNvdiwgaXQgaXMgbm90IHRydWUgdGhh dCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb2YNCj4gPiA+IEV0aGVybmV0IG9yIFNESCBkZXNj cmliZXMgdGhlIG9wZXJhdGlvbiBvZiBhbnkgbGF5ZXIgYmVsb3cuIFJhdGhlciwNCj4gZWFjaA0K PiA+ID4gbGF5ZXIgaXMgc3VwcG9zZWQgdG8gb3BlcmF0ZSBpbmRlcGVuZGVudGx5LiBIb3dldmVy LCB0aGVyZSBhcmUgYSBmZXcNCj4gPiA+IGV4Y2VwdGlvbnMsIHN1Y2ggYXMgaG9sZC1vZmYgdGlt ZXIgYW5kIEFJUyAoYXMgYSB0cmlnZ2VyIGZyb20gbG93ZXINCj4gPiA+IGxheWVyKS4gRXZlbiB0 aG91Z2ggdGhlcmUgZXhpc3Qgc29tZSBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbnMgdGhhdA0K PiA+ID4gdXNlIG90aGVyIGluZm9ybWF0aW9uIGZyb20gbG93ZXIgbGF5ZXIsIG1vc3Qgb2YgdGhl bSBhcmUgbm90DQo+IHJlY29tbWVuZGVkDQo+ID4gPiBpbiBJVFUtVCBzdGFuZGFyZHMuDQo+ID4g Pg0KPiA+ID4gQnJpZGdlIGFuZCBzZWxlY3RvciBhcmUgbm90IGluIHRoZSBwaHlzaWNhbCBsYXll ciwgYnV0IHRoZXkgYXJlIHBhcnQgb2YNCj4gPiA+IHByb3RlY3Rpb24gc3dpdGNoaW5nLiBPbmUg b2YgdGhlIGltcG9ydGFudCBvdXRwdXQgYWN0aW9ucyBmcm9tIHRoZSBQU0MNCj4gPiA+IGNvbnRy b2wgbG9naWMgaXMgY29vcmRpbmF0aW5nIHRoZSBwb3NpdGlvbnMgb2YgYnJpZGdlIGFuZCBzZWxl Y3Rvci4NCj4gPiA+IEFsc28sIHRoZSBicmlkZ2Ugb3BlcmF0aW9uIHJlc3BvbmRpbmcgdG8gdGhl IFBTQyBjb250cm9sIGxvZ2ljIGlzIGFsc28NCj4gPiA+IHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcuIEhvd2V2ZXIsIGhvdyB0byByZWFsaXplIHRoZSBicmlkZ2UgYW5kDQo+ID4gPiBzZWxl Y3RvciAoZm9yIGV4YW1wbGUsIGhvdyB0byBtYW5pcHVsYXRlIGEgcGFja2V0IGZvcndhcmRpbmcg bWVjaGFuaXNtKQ0KPiA+ID4gaXMgYW4gaW1wbGVtZW50YXRpb24gbWF0dGVyLg0KPiA+ID4NCj4g PiA+IFdoZW4gd2UgbWVudGlvbiAxKzEgb3IgMToxIGluIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJl LCB3ZSBkZWFsIHdpdGggdGhlDQo+ID4gPiBvcGVyYXRpb24gb2YgYnJpZGdlLiBGb3IgMSsxIGFy Y2hpdGVjdHVyZSwgdGhlIHRyYWZmaWMgbmVlZHMgdG8gYmUNCj4gPiA+IGR1cGxpY2F0ZWQgYXQg dGhlIHNlbmRlciBhbmQgc2VudCB0byBib3RoIHBhdGhzIGFsbCB0aGUgdGltZSwgd2hpY2ggaXMN Cj4gPiA+IHRoZSBzYW1lIGRlc2NyaXB0aW9uIGFzIHRoZSDigJxwZXJtYW5lbnQgYnJpZGdl4oCd LiBGb3IgMToxIGFyY2hpdGVjdHVyZSwNCj4gPiA+IOKAnHNlbGVjdG9yIGJyaWRnZeKAnSBpcyB1 c2VkIHRvIHNlbmQgdGhlIHRyYWZmaWMgb25seSBvbmUgb2YgdGhlIHBhdGhzLiBBcw0KPiA+ID4g dGhlIHByb3RlY3Rpb24gcGF0aCBjYW4gYmUgdXNlZCBieSBiZXN0IHRyYWZmaWMgaW4gcGFja2V0 IG5ldHdvcmtzIGFuZA0KPiA+ID4gdGhlIHBhY2tldCBkdXBsaWNhdGlvbiB0YWtlcyBtdWNoIG1v cmUgZWZmb3J0L2ludGVybmFsIGJhbmR3aWR0aCBpbnNpZGUNCj4gPiA+IGEgc3dpdGNoIHRoYW4g dGhlIHRpbWUgc2xvdCBjb3B5IG9mIGNpcmN1aXQgbmV0d29ya3MuIDE6MSBpcyBjb25zaWRlcmVk DQo+ID4gPiBhcyBwcmVmZXJhYmxlIGFyY2hpdGVjdHVyZSBpbiBwYWNrZXQgbmV0d29ya3MuDQo+ ID4gPg0KPiA+ID4gQXMgeW91IG1pZ2h0IHJlY2FsbCBmcm9tIEcuODAzMSDigJMgRXRoZXJuZXQg bGluZWFyIHByb3RlY3Rpb24sIHRoZQ0KPiA+ID4gc2VsZWN0b3IgYnJpZGdlIGlzIG5vdCByZWNv bW1lbmRlZCBkdWUgdG8gdGhlIHRyYWZmaWMgZmxhcHBpbmcgdW5kZXIgU0QNCj4gPiA+IGNvbmRp dGlvbnMgb24gYm90aCBwYXRocy4gSW5zdGVhZCDigJxicm9hZGNhc3QgYnJpZGdl4oCdIGlzIGlu dHJvZHVjZWQgdG8NCj4gPiA+IHN1cHBvcnQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgYWdhaW5zdCBT RC4gQnV0LCB0aGlzIGJyb2FkY2FzdCBicmlkZ2UgaXMNCj4gPiA+IG5vdCByZWNvbW1lbmRlZCBp biBub24tcmV2ZXJ0aXZlIG1vZGUgYXMgdGhlIHdvcmtpbmcgcGF0aCBuZWVkcyB0byBiZQ0KPiA+ ID4gb2NjdXBpZWQgYnkgdHJhZmZpYyBhbGwgdGhlIHRpbWUuIEFsc28gdGhlIGJyb2FkY2FzdCBi cmlkZ2UgaXMgbm90DQo+ID4gPiBlZmZpY2llbnQsIHNpbmNlIGJ5IGRlZmluaXRpb24sIHRoZSBw YWNrZXQgZHVwbGljYXRpb24gc2hvdWxkIG9jY3VyDQo+ID4gPiBkdXJpbmcgbm90IG9ubHkgU0Qg YnV0IGFsc28gU0YsIEZTLCBNUywgZXRjLiBJbiB0aGlzIGRvY3VtZW50LCB3ZSBhcmUNCj4gPiA+ IGludHJvZHVjaW5nIGFuIGltcHJvdmVkIGJyaWRnZSBtZWNoYW5pc20sIHdoaWNoIGJlaGF2ZXMg bGlrZSBhIHNlbGVjdG9yDQo+ID4gPiBicmlkZ2UgYnV0IGR1cGxpY2F0ZXMgdGhlIHRyYWZmaWMg b25seSB1bmRlciBTRCBjb25kaXRpb24sIGFuZCB3ZQ0KPiA+ID4gYmVsaWV2ZSB0aGF0IGl0IGFk ZHJlc3NlcyBhbGwgdGhlIGlzc3VlcyB3aXRoIGV4aXN0aW5nIGJyaWRnZXMuDQo+ID4gPg0KPiA+ ID4gV2hhdCB3ZSBtZWFuIGJ5IFNEIHByb3RlY3Rpb24gaXMgYWdub3N0aWMgdG8gdGhlIFNEIGRl dGVjdGlvbiBtZXRob2QgaXMNCj4gPiA+IHRoYXQgdGhlIHByb3Bvc2VkIFNEIHByb3RlY3Rpb24g bWV0aG9kIChhZ2FpbiBob3cgdG8gb3BlcmF0ZSBhDQo+IGJyaWRnZSBvcg0KPiA+ID4gd2hhdCBi cmlnZSBpcyB1c2VkIGlzIGEgcGFydCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZykgY2FuIGJlIHVz ZWQgbm8NCj4gPiA+IG1hdHRlciB3aGF0IGtpbmQgb2YgU0QgZGV0ZWN0aW9uIG1ldGhvZHMgKGRh dGEgcGFja2V0IGNvdW50aW5nLCBDQ00NCj4gPiA+IHBhY2tldCBjb3VudGluZywgb3IgZXZlbiBw cm9wcmlldGFyeSBzZXJ2ZXIgbGF5ZXIgU0QgZGV0ZWN0aW9uKSBpcw0KPiB1c2VkLg0KPiA+ID4N Cj4gPiA+IEkgdGhpbmsgSSBhbnN3ZXJlZCBhbGwgdGhlIHF1ZXN0aW9ucyBvbiB5b3VyIGVtYWls Lg0KPiA+ID4NCj4gPiA+IFlhYWNvdiwgaWYgeW91IGhhdmUgYW55IGZ1cnRoZXIgY29uY2VybnMg b3IgcXVlc3Rpb25zLCBwbGVhc2UgbGV0IG1lDQo+ID4ga25vdy4NCj4gPiA+DQo+ID4gPiBCZXN0 IHJlZ2FyZHMsDQo+ID4gPg0KPiA+ID4gSmVvbmctZG9uZw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0K PiA+ID4NCj4gPiA+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gKkZyb20gOiAqIllhYWNvdiBX ZWluZ2FydGVuIg0KPiA+ID4gKlNlbnQgOiAqMjAxMy0xMi0xMCAxNjowNDoxNyAoICswOTowMCAp DQo+ID4gPiAqVG8gOiAqUnlvbywgSmVvbmctZG9uZw0KPiA+ID4gKkNjIDogKmRyYWZ0LWlldGYt bXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnDQo+ID4gPiAsIG1wbHNAaWV0Zi5vcmcNCj4g PiA+ICpTdWJqZWN0IDogKlJlOiBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbg0K PiA+ID4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCj4gPiA+DQo+ID4gPiBKZW9uZy1kb25n LCBoaQ0KPiA+ID4NCj4gPiA+IFRoYW5rIHlvdSBmb3IgeW91ciByZXBseS4gWW91ciBhbnN3ZXIg c2VlbXMgdG8gYmUgYW4gYXBwcm9wcmlhdGUgYW5zd2VyDQo+ID4gPiBmb3Igb3RoZXIgU0RPcywg bm90IHN1cmUgdGhhdCBpdCBpcyB0cnVlIGZvciB0aGUgY29udGV4dCBvZiBNUExTIGFuZA0KPiA+ ID4gSUVURiB3b3JrLg0KPiA+ID4NCj4gPiA+IDEuIFlvdSB3cm90ZSAiYW55IHByb3RlY3Rpb24g c3dpdGNoaW5nIChpbmNsdWRpbmcgUFNDKSBpcyBzdXBwb3NlZCB0bw0KPiA+ID4gZGVzY3JpYmUg dGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiIgLSB0aGlzIG1heSBiZSB0cnVl IGZvcg0KPiA+ID4gRXRoZXJuZXQgYW5kU0RIIGFuZCBmb3IgZG9jdW1lbnRzIHRoYXQgYXJlIGRl c2NyaWJpbmcgdGhlIG9wZXJhdGlvbiBvZg0KPiA+ID4gdGhlIHBoeXNpY2FsIGxheWVyLiBIb3dl dmVyLCB0aGUgSUVURiAodG8gbXkgdW5kZXJzdGFuZGluZyAtIGFuZCBJIGFtDQo+ID4gPiBjZXJ0 YWlubHkgd2lsbGluZyB0byBiZSBjb3JyZWN0ZWQgb24gdGhpcyBwb2ludCkgaXMgY29uY2VybmVk IHdpdGggdGhlDQo+ID4gPiBwcm90b2NvbCBhbmQgbGVhdmUgdGhlIGxvd2VyIGxheWVycyB0byBp bXBsZW1lbnRhdGlvbi4gQWxzbywgSSBhbSBub3QNCj4gPiA+IHN1cmUgdGhhdCB0aGUgY29uY2Vw dHMgb2YgQnJpZGdlIGFuZCBTZWxlY3RvciByZWFsbHkgYXBwbHkgdG8gTVBMUw0KPiA+ID4gKGFs dGhvdWdoIEkgYWRtaXQgdGhhdCB3ZSBkaWQgbWVudGlvbiB0aGVtIGluIHRoZSBvcmlnaW5hbCBQ U0MNCj4gPiBkZWZpbml0aW9uKS4NCj4gPiA+DQo+ID4gPiAyLiBZb3UgY2l0ZSB3aGF0IHdhcyB3 cml0dGVuIGluIEc4MDMxIGFzIGp1c3RpZmljYXRpb24gZm9yIGluY2x1ZGluZw0KPiA+ID4gY29u dGVudCBpbnRvIHlvdXIgZHJhZnQuIEFnYWluIGl0IGlzIGhhcmQgdG8gdHJhbnNmZXIgbWV0aG9k b2xvZ3kgZnJvbQ0KPiA+ID4gb25lIFNETyB0byBhbm90aGVyIGFuZCB0aGVyZWZvcmUsIHdoaWxl IEkgaGlnaGx5IHJlc3BlY3QgdGhlIHdvcmsNCj4gb2YgdGhlDQo+ID4gPiBJVFUsIEkgZG8gbm90 IGZlZWwgdGhhdCB0aGlzIGlzIGEgdmVyeSBjbGVhciBqdXN0aWZpY2F0aW9uIGZvcg0KPiBpbmNs dXNpb24NCj4gPiA+IGludG8gYW4gaW50ZXJuZXQtZHJhZnQuIEV2ZW4gd2hlbiB0aGUgZHJhZnQg c3RhdGVzIHRoYXQgaXRzIHB1cnBvc2UgaXMNCj4gPiA+IHRvIGFkZHJlc3MgdGhlIGNvbmNlcm5z IG9mIHRoZSBJVFUuDQo+ID4gPg0KPiA+ID4gMy4gVG8gdGhlIGFjdHVhbCBwb2ludCBvZiBteSBl YXJsaWVyIGNvbW1lbnQsIHRoYXQgeW91IGRvIG5vdCBzZWVtIHRvDQo+ID4gPiBhZGRyZXNzIC0g dGhlIHBhcmFncmFwaCBpbiBTZWN0aW9uIDcuMyBzZWVtcyB0byBzdGF0ZSB0aGF0IFNEDQo+IHBy b3RlY3Rpb24NCj4gPiA+IGNoYW5nZXMgYWNjb3JkaW5nIHRvIHRoZSBtZXRob2QgdGhhdCBpcyB1 c2VkIHRvIGRldGVjdCB0aGUgU0QuIFRoaXMNCj4gPiA+IG1lYW5zIHRoYXQgU0QgcHJvdGVjdGlv biBpcyBub3QgYWdub3N0aWMgdG8gdGhlIG1ldGhvZCB1c2VkIGZvciB0aGUNCj4gPiA+IGRldGVj dGlvbi4NCj4gPiA+IEFsdGVybmF0aXZlbHksIHdlIGNvdWxkIGJyZWFrIHRoaXMgZGVwZW5kZW5j ZSBhbmQgc3RhdGUgdGhhdCBTRA0KPiA+ID4gcHJvdGVjdGlvbiBpcyBhbHdheXMgcHJvdmlkZWQg YnkgY2hhbmdpbmcgdGhlIHRyYW5zbWlzc2lvbiBvZiB0aGUgZGF0YQ0KPiA+ID4gdG8gMSsxIHBy b3RlY3Rpb24gaW4gY2FzZXMgb2YgU0QgZGV0ZWN0aW9uLCB3aGljaCBpcyB3aGF0IHRoZSBwYXJh Z3JhcGgNCj4gPiA+IGlzIHN1Z2dlc3RpbmcgdG8gZG8gZm9yIHNvbWUgY2FzZXMuDQo+ID4gPg0K PiA+ID4gSSBob3BlIHRoaXMgZm9ybXVsYXRpb24gbWFrZSBteSBjb21tZW50IGNsZWFyZXIgYW5k IHdlIGFyZSBhYmxlIHRvDQo+ID4gPiBkaXNjdXNzIHRoZSB0ZWNobm9sb2dpY2FsIGFwcHJvYWNo IHJhdGhlciB0aGFuIHRoZSBwaGlsb3NvcGhpY2FsDQo+ID4gPiBkaWZmZXJlbmNlcy4NCj4gPiA+ DQo+ID4gPiBUaGFuayB5b3UsDQo+ID4gPiB5YWFjb3YNCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24g TW9uLCBEZWMgOSwgMjAxMyBhdCAxMDowNCBQTSwgUnlvbywgSmVvbmctZG9uZyA+ID4gd3JvdGU6 DQo+ID4gPg0KPiA+ID4gWWFhY292LA0KPiA+ID4NCj4gPiA+IFllcywgUFNDIGlzIHN1cHBvc2Vk IHRvIGJlIGFnbm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhlDQo+ID4gPiBkZXRlY3Rp b24gb2YgU0YvU0QuDQo+ID4gPg0KPiA+ID4gSXQgaXMgYWxzbyB0cnVlIHRoYXQgYW55IHByb3Rl Y3Rpb24gc3dpdGNoaW5nIChpbmNsdWRpbmcgUFNDKSBpcw0KPiA+ID4gc3VwcG9zZWQgdG8gZGVz Y3JpYmUgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLg0KPiA+ID4NCj4gPiA+ IEFzIHRoZXJlIGFyZSBtdWx0aXBsZSBvcHRpb25zIGZvciBkZXRlY3RpbmcgU0QsIHdlIG5lZWRl ZCB0bw0KPiA+ID4gZGVzY3JpYmUgdGhlIGJlaGF2aW9yIG9mIHRoZSBicmlkZ2UgdG8gY292ZXIg YWxsIHRoZSBwb3NzaWJsZQ0KPiA+ID4gZGV0ZWN0aW9uIG1ldGhvZHMuIERlc2NyaWJpbmcgdGhl IG9wZXJhdGlvbiBvZiBicmlkZ2UgZm9yIFNEDQo+ID4gPiBwcm90ZWN0aW9uIGlzIG5vdCBhIG5l dyB0aGluZy4gRm9yIGV4YW1wbGUsIEcuODAzMSAtIEV0aGVybmV0IGxpbmVhcg0KPiA+ID4gcHJv dGVjdGlvbiBhbHNvIGRlc2NyaWJlcyB3aGF0IGJyaWRnZSBjYW4gYmUgdXNlZCBpbiBvcmRlciB0 bw0KPiA+ID4gcHJvdmlkZSBwcm90ZWN0aW9uIGFnYWluc3QgU0QuDQo+ID4gPg0KPiA+ID4gQmVz dCByZWdhcmRzLA0KPiA+ID4NCj4gPiA+IEplb25nLWRvbmcNCj4gPiA+DQo+ID4gPg0KPiA+ID4N Cj4gPiA+DQo+ID4gPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ICpGcm9tIDogKiJZYWFjb3Yg V2VpbmdhcnRlbiIgPiA+DQo+ID4gPiAqU2VudCA6ICoyMDEzLTEyLTA4IDIwOjAxOjU1ICggKzA5 OjAwICkNCj4gPiA+ICpUbyA6ICpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRm Lm9yZw0KPiA+ID4NCj4gPiA+ID4gPiwgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPg0KPiA+ID4gKkNj IDogKg0KPiA+ID4gKlN1YmplY3QgOiAqUXVlc3Rpb24gcmVnYXJkaW5nIFNEIHByb3RlY3Rpb24g aW4NCj4gPiA+IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQo+ID4gPg0KPiA+ID4NCj4gPiA+ IEhpLA0KPiA+ID4NCj4gPiA+IEFmdGVyIHJlYWRpbmcgdGhyb3VnaCB5b3VyIGRyYWZ0IG9uIHRo ZSBleHRlbnNpb25zIHRvIFBTQyB0byBzdXBwb3J0DQo+ID4gPiBTRCBzaXR1YXRpb25zLCBJIGhh dmUgYSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbiAtDQo+ID4gPiBJbiB5b3VyIGludHJvZHVj dGlvbiAtIHlvdSBzdGF0ZSB0aGF0IHRoZSBtZXRob2QgdXNlZCB0byBkZXRlY3QgU0QNCj4gPiA+ IHNpdHVhdGlvbnMgaXMgb3V0LW9mLXNjb3BlIG9mIHRoZSBkb2N1bWVudC4gRG9lcyB0aGlzIG1l YW4gdGhhdCBQU0MNCj4gPiA+IGlzIHN1cHBvc2VkIHRvIGJlIGFnbm9zdGljIHRvIHRoZSBtZXRo b2QgdXNlZCBmb3IgdGhpcyBkZXRlY3Rpb24/IEl0DQo+ID4gPiBzaG91bGQgcmVhY3Qgb25seSB0 byB0aGUgaW5kaWNhdGlvbiwgc2ltaWxhcmx5IHRvIHRoZSByZWFjdGlvbiBhbmQNCj4gPiA+IHJl bGF0aW9uc2hpcCB0byB0aGUgbWV0aG9kIGZvciBkZXRlY3RpbmcgYW5kIGRlY2xhcmluZyBhIFNG IHNpdHVhdGlvbi4NCj4gPiA+IEhvd2V2ZXIsIHdoZW4geW91IGV4cGxhaW4gdGhlIGJlaGF2aW9y IG9mIHRoZSBTRCBwcm90ZWN0aW9uIGluDQo+ID4gPiBzZWN0aW9uIDcuMyB5b3UgaGF2ZSBhIHBh cmFncmFwaCB0aGF0IHN0YXJ0cyB3aXRoICJJZiB0aGUgZGV0ZWN0aW9uDQo+ID4gPiBvZiBhIFNE IGRlcGVuZHMgb24gdGhlIHByZXNlbmNlIG9mIHVzZXIgZGF0YSBwYWNrZXRzIC4uLiIgdGhhdA0K PiA+ID4gc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgYmVoYXZpb3Igb2YgdGhlIHN5c3RlbSBp cyBkZXBlbmRlbnQgdXBvbg0KPiA+ID4gdGhlIGRldGVjdGlvbiBtZXRob2QhIENsYXJpZmljYXRp b24gd291bGQgYmUgYXBwcmVjaWF0ZWQuDQo+ID4gPg0KPiA+ID4gLS0NCj4gPiA+IFRoYW54IGFu ZCBCUiwNCj4gPiA+IHlhYWNvdg0KPiA+ID4NCj4gPiA+IC9TdGlsbCBsb29raW5nIGZvciBuZXcg b3Bwb3J0dW5pdHkvDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gLS0NCj4gPiA+ IFRoYW54IGFuZCBCUiwNCj4gPiA+IHlhYWNvdg0KPiA+ID4NCj4gPiA+IC9TdGlsbCBsb29raW5n IGZvciBuZXcgb3Bwb3J0dW5pdHkvDQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBtcGxzIG1haWxpbmcgbGlz dA0KPiA+ID4gbXBsc0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzDQo+ID4gPg0KPiA+DQo+ID4gLS0NCj4gPg0KPiA+DQo+ID4gTG9hIEFu ZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+ID4gU2VuaW9yIE1QTFMgRXhw ZXJ0IGxvYUBwaS5udQ0KPiA+IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpIHBob25l OiArNDYgNzM5IDgxIDIxIDY0DQo+DQo+IC0tDQo+DQo+DQo+IExvYSBBbmRlcnNzb24gZW1haWw6 IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51DQo+ IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpIHBob25lOiArNDYgNzM5IDgxIDIxIDY0 DQoNCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpT ZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0 YW50KSBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B1350SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTog6rW066a8OyBGT05ULVNJWkU6IDEwcHQiIGlkPSJlekZvcm1Qcm9jX2RpdiI+ DQo8ZGl2IGlkPSJtc2dib2R5Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJ TjogMGNtIDBjbSAwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgV09SRC1C UkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywn c2Fucy1zZXJpZic7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFzdC1mb250 LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj5EZWFy IGFsbCw8L3NwYW4+PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hU OiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51 bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFu IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5n PSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBM SU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlk ZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdp ZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgbXNvLWJpZGktZm9udC1zaXplOiAx MC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6 IDBwdCIgbGFuZz0iRU4tVVMiPlRoaXMgZW1haWwgaXMgdG8gc3VtbWFyaXplIHRoZSBpc3N1ZSB3 aXRoIHRoZSBTRCBwcm90ZWN0aW9uIGFuZCB0byBwcm9wb3NlIGEgcmVzb2x1dGlvbi48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJH SU46IDBjbSAwY20gMHB0OyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQt QlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcs J3NhbnMtc2VyaWYnOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDog MTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1l cmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0i RU4tVVMiPlRoZSBpc3N1ZSB3aXRoIHRoZSBTRCBwcm90ZWN0aW9uIGhhcyBiZWVuIHJhaXNlZCBi eSBZYWFjb3YmbmJzcDthIG1vbnRoIGFnby4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgc3R5bGU9IlRF WFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBU RVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBt c28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVm dCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBtc28t YmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOq1tOumvDsg bXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+SGlzIG1haW4gYXJndW1lbnQgd2Fz IHRoYXQgY3VycmVudCBkZXNjcmlwdGlvbiBvbiBTRCBwcm90ZWN0aW9uIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDcuMyBzZWVtZWQgdG8gaW5kaWNhdGUgdGhlIGJlaGF2aW9yDQogaXMgZGVwZW5kZW50 IHVwb24gdGhlIFNEIGRldGVjdGlvbiBtZXRob2QuPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhU LUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVY VC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNv LXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi Pg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgbXNvLWJp ZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDqtbTrprw7IG1z by1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBz dHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgV09SRC1CUkVBSzoga2Vl cC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJsZWZ0Ij4NCjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJp Zic7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog 6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj5FdmVuIGFmdGVyIGEg ZmV3IGVtYWlsIGV4Y2hhbmdlcyB0byBjbGFyaWZ5IHRoZSBvcGVyYXRpb24gb2YgU0QgcHJvdGVj dGlvbiwgZXNwZWNpYWxseSB0aGUgb3BlcmF0aW9uIG9mIHRoZSBicmlkZ2UgdXNlZA0KIGluIFNE IHByb3RlY3Rpb24sIEkgd2FzIG5vdCBhYmxlIHRvIHJlY29nbml6ZSB0aGUgbWFpbiBzb3VyY2Ug b2YgdGhlIGlzc3VlIHVudGlsIHNvbWUgb2YgcGVvcGxlLCBZYWFjb3YsIEh1dWIsIExvYSBhbmQg bXlzZWxmLCZuYnNwO2Rpc2N1c3NlZCBpbiZuYnNwO3ByaXZhdGUmbmJzcDtvZmYgdGhlIFdHIGxp c3QgKHNvcnJ5IGZvciBiZWluZyBvZmYgdGhlIFdHIGxpc3QpLg0KPC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVw LWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiPg0KJm5ic3A7PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUt SEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBURVhULUFVVE9TUEFDRTogaWRlb2dy YXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lkb3ct b3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBw dDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0 IiBsYW5nPSJFTi1VUyI+RmluYWxseSwgd2UgYWdyZWVkIG9uIHRoZSBmb2xsb3dpbmcgdGV4dCB0 byByZXBsYWNlIHRoZSBmb3VydGggcGFyYWdyYXBoLCBzdGFydGluZyB3aXRoICZxdW90O0lmIHRo ZSBkZXRlY3Rpb24mbmJzcDtvZiBhIFNEIGRlcGVuZHMNCiBvbiB0aGUgcHJlc2VuY2Ugb2YgdXNl ciBkYXRhIHBhY2tldHMgLi4uJnF1b3Q7Jm5ic3A7aW4gU2VjdGlvbiA3LjM6PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFL OiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiPg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5z LXNlcmlmJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPi0tLS0tLTwv c3Bhbj48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlHSFQ6IDE1cHQ7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsg V09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nv dXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPlByb3Rl Y3Rpb24gc3dpdGNoaW5nIGFnYWluc3QgU0QgaXMgYWx3YXlzIHByb3ZpZGVkIGJ5IGEgc2VsZWN0 b3IgYnJpZGdlIGR1cGxpY2F0aW5nIHVzZXIgZGF0YSB0cmFmZmljIGFuZCBmZWVkaW5nIGl0IHRv IGJvdGgNCiB3b3JraW5nIGFuZCBwcm90ZWN0aW9uIHBhdGhzIHVuZGVyIFNEIGNvbmRpdGlvbi4g SW4gcmV2ZXJ0aXZlIG1vZGUsIHdoZW4gdGhlIFdUUiB0aW1lciBleHBpcmVzIHRoZSBwYWNrZXQg ZHVwbGljYXRpb24gU0hBTEwgYmUgc3RvcHBlZCBhbmQgdGhlIHVzZXIgZGF0YSB0cmFmZmljIFNI QUxMIGJlIHRyYW5zcG9ydGVkIG9uIHRoZSB3b3JraW5nIHBhdGggb25seS4gSW4gbm9uLXJldmVy dGl2ZSBtb2RlLCB3aGVuIFNEIGlzIGNsZWFyZWQgdGhlIHBhY2tldA0KIGR1cGxpY2F0aW9uIFNI QUxMIGJlIHN0b3BwZWQgYW5kIHRoZSB1c2VyIGRhdGEgdHJhZmZpYyBTSEFMTCBiZSB0cmFuc3Bv cnRlZCBvbiB0aGUgcHJvdGVjdGlvbiBwYXRoIG9ubHkuDQo8L3NwYW4+PC9wPg0KPHAgc3R5bGU9 IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0 OyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxs OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBt c28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOq1tOum vDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+LS0tLS0tPC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFL OiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiPg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5z LXNlcmlmJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlHSFQ6IDE1cHQ7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsg V09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Fy aWFsJywnc2Fucy1zZXJpZic7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFz dC1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVT Ij5Ib3dldmVyLCBpbiB0aGUgZGlzY3Vzc2lvbiBhYm91dCZuYnNwO3RoZSB0ZXh0Jm5ic3A7d2l0 aCZuYnNwO0VyaWMgR3JheSwgaGUgZnVydGhlciBtYWRlIHRoZSBjb21tZW50cyBvbiB0aGUgb3Bl cmF0aW9uIG9mIHRoZSBicmlkZ2UsDQogYW5kIEkgYW0gbm93IHByb3Bvc2luZyZuYnNwO3RoZSBm b2xsb3dpbmcgdGV4dDo8L3NwYW4+PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJ TkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBURVhULUFVVE9TUEFDRTogaWRl b2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lk b3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBtc28tYmlkaS1mb250LXNpemU6IDEw LjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzog MHB0IiBsYW5nPSJFTi1VUyI+LS0tLS0tPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdO OiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1BVVRP U1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLXBhZ2lu YXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPHNw YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogYmxhY2s7IG1zby1i aWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog6rW066a8OyBt c28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj5Qcm90ZWN0aW9uIHN3aXRjaGluZyBh Z2FpbnN0IFNEIGlzIGFsd2F5cyBwcm92aWRlZCBieSBhIHNlbGVjdG9yIGJyaWRnZSBkdXBsaWNh dGluZyB1c2VyIGRhdGEgdHJhZmZpYyBhbmQgZmVlZGluZw0KIGl0IHRvIGJvdGggdGhlIHdvcmtp bmcgcGF0aCBhbmQgdGhlIHByb3RlY3Rpb24gcGF0aCB1bmRlciBTRCBjb25kaXRpb24uIFdoZW4g YSBsb2NhbCBvciByZW1vdGUgU0Qgb2NjdXJzIG9uIGVpdGhlciB0aGUgd29ya2luZyBwYXRoIG9y IHRoZSBwcm90ZWN0aW9uIHBhdGgsIHRoZSBMRVIgU0hBTEwgZHVwbGljYXRlIHVzZXIgZGF0YSB0 cmFmZmljIGFuZCBTSEFMTCBmZWVkIHRvIGJvdGggdGhlIHdvcmtpbmcgcGF0aCBhbmQgdGhlIHBy b3RlY3Rpb24NCiBwYXRoLiBUaGUgcGFja2V0IGR1cGxpY2F0aW9uIFNIQUxMIGNvbnRpbnVlIGFz IGxvbmcgYXMmbmJzcDthbnkgU0QgY29uZGl0aW9uIGV4aXN0cyBpbiB0aGUgcHJvdGVjdGVkIGRv bWFpbiwgYW5kIFNIQUxMIHN0b3Agd2hlbiB0aGVyZSBpcyBubyBTRCBjb25kaXRpb24uJm5ic3A7 QWRkaXRpb25hbGx5LCZuYnNwO3RoZSBwYWNrZXQgZHVwbGljYXRpb24gU0hBTEwgY29udGludWUm bmJzcDtpbiB0aGUgV1RSIHN0YXRlIGluIHJldmVydGl2ZSBtb2RlLiBJbiBub24tcmV2ZXJ0aXZl IG1vZGUsDQogdGhlIHBhY2tldCBkdXBsaWNhdGlvbiBTSEFMTCBzdG9wIHdoZW4gdGhlcmUgaXMg bm8gU0QgY29uZGl0aW9uLiA8L3NwYW4+PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7 IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBURVhULUFVVE9TUEFDRTog aWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjog d2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBtc28tYmlkaS1mb250LXNpemU6 IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2Vybmlu ZzogMHB0IiBsYW5nPSJFTi1VUyI+LS0tLS0tPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0 ZXI6IGxpbmUtYnJlYWsiIGNsZWFyPSJhbGwiPg0KPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhU LUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVY VC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNv LXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi Pg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgbXNvLWJp ZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDqtbTrprw7IG1z by1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPklmIHlvdSBoYXZlIGFueSBjb21tZW50 cyBvbiB0aGlzIHByb3Bvc2FsLCBwbGVhc2UgbGV0IHVzIGtub3cuDQo8L3NwYW4+PC9wPg0KPHAg c3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAw Y20gMHB0OyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtl ZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2Vy aWYnOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+T3RoZXJ3aXNlLCBJ IHdpbGwgcHV0IHRoZSBwcm9wb3NlZCB0ZXh0IGluIHRoZSByZXZpc2lvbiBvZiB0aGUgZHJhZnQu PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVw dDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmlj OyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn QXJpYWwnLCdzYW5zLXNlcmlmJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1I RUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3Jh cGgtbnVtZXJpYzsgV09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1v cnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0 OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQi IGxhbmc9IkVOLVVTIj5CZXN0IHJlZ2FyZHMsPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhULUFM SUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1B VVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLXBh Z2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0K PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgbXNvLWJpZGkt Zm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1m b250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8YnI+DQo8 YnI+DQo8ZGl2IGlkPSJNYWlsU2lnblNlbnQiPjxicj4NCjwvZGl2Pg0KPGhyIHRhYmluZGV4PSIt MSI+DQo8Yj5Gcm9tIDogPC9iPiZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgJmx0O2xvYUBwaS5u dSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTQtMDEtMDIgMTk6MjQ6MjggKCAmIzQzOzA5OjAw ICk8YnI+DQo8Yj5UbyA6IDwvYj7rpZjsoJXrj5kgJmx0O3J5b29AZXRyaS5yZS5rciZndDssIFlh YWNvdiBXZWluZ2FydGVuICZsdDt3eWFhY292QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYyA6IDwv Yj5tcGxzQGlldGYub3JnICZsdDttcGxzQGlldGYub3JnJmd0OywgZHJhZnQtaWV0Zi1tcGxzLXRw LXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRv b2xzLmlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3QgOiA8L2I+UmU6IFttcGxzXSBRdWVzdGlv biByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxi cj4NCjxicj4NCkplb25nLWRvbmcsPGJyPg0KPGJyPg0KSSBjb3VsZCB0cnksIGJ1dCB0aGF0IHdv dWxkIGJlIGEgbm92aWNlIHN0dW1ibGluZyBhcm91bmQuPGJyPg0KPGJyPg0KSSdkIGxpa2UgWWFh Y28gYW5kIEh1dWIgdG8gdGFrZSBhdCBzcGluIGF0IHRoaXMgZmlyc3QsIEkgYmVsaWV2ZTxicj4N CnRoYXQgdGhleSBoYXZlIGEgYmV0dGVyIGNoYW5jZSB0byB6b29tIGluIG9uIHdoYXQgaXMgY3J1 Y2lhbCBmcm9tPGJyPg0KdGhlIGJlZ2lubmluZy48YnI+DQo8YnI+DQovTG9hPGJyPg0KPGJyPg0K T24gMjAxNC0wMS0wMiAwOTozOSwgUnlvbywgSmVvbmctZG9uZyB3cm90ZTo8YnI+DQomZ3Q7IExv YSwgdGhhbmtzIGZvciB0aGUgZW1haWwuPGJyPg0KJmd0OyBJIGdvdCB0aGUgcG9pbnQgbm93Ljxi cj4NCiZndDsgQXMgeW91IG1lbnRpb25lZCBpbiB0aGUgbGFzdCBwYXJ0IG9mIHlvdXIgZW1haWws IHdlJ2QgYmV0dGVyIGZpbmQgdGhlIHRleHQuPGJyPg0KJmd0OyBEbyB5b3UgaGF2ZSBhbnkgdGV4 dCB0byBwcm9wb3NlPzxicj4NCiZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgSmVvbmctZG9u Zzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7 ICpGcm9tIDogKiZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgPExPQUBQSS5OVT48YnI+DQomZ3Q7 ICpTZW50IDogKjIwMTMtMTItMjkgMTk6MDQ6MzggKCAmIzQzOzA5OjAwICk8YnI+DQomZ3Q7ICpU byA6ICpSeW9vLCBKZW9uZy1kb25nIDxSWU9PQEVUUkkuUkUuS1I+LCBZYWFjb3YgV2VpbmdhcnRl bjxicj4NCiZndDsgPFdZQUFDT1ZAR01BSUwuQ09NPjxicj4NCiZndDsgKkNjIDogKm1wbHNAaWV0 Zi5vcmcgPE1QTFNASUVURi5PUkc+LDxicj4NCiZndDsgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1p dHVAdG9vbHMuaWV0Zi5vcmc8YnI+DQomZ3Q7IDxEUkFGVC1JRVRGLU1QTFMtVFAtUFNDLUlUVUBU T09MUy5JRVRGLk9SRz48YnI+DQomZ3Q7ICpTdWJqZWN0IDogKlJlOiBbbXBsc10gUXVlc3Rpb24g cmVnYXJkaW5nIFNEIHByb3RlY3Rpb24gaW48YnI+DQomZ3Q7IGRyYWZ0LWlldGYtbXBscy10cC1w c2MtaXR1PGJyPg0KJmd0Ozxicj4NCiZndDsgSmVvbmctZG9uZyw8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJIGdvdCBjb25mbGljdGluZyBhbnN3ZXJzIHlvdSBhbmQgSHV1Yi4gSSBkb24ndCBpbW1lZGlh dGVseSB3YW50IHRvPGJyPg0KJmd0OyBjaGFuZ2UgdGhlIHRleHQgaW4gdGhlIGRvY3VtZW50LCBi dXQgcmF0aGVyIHVuZGVyc3RhbmQgaWYgaXQgbmVlZHMgdG88YnI+DQomZ3Q7IGJlIGNoYW5nZWQg dG8gZ2l2ZSBhIGNvbnRleHQgdG8gcmVzb2x2ZSBZYWFjb3YncyBjb21tZW50cy48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBUaGUgcG9pbnQgSSB3YXMgdHJ5aW5nIHRvIG1ha2Ugd2FzIHRoYXQgeW91IGFu ZCBZYWFjb3Ygc3RhbmQgb24gdHdvPGJyPg0KJmd0OyBkaWZmZXJlbnQgbW91bnRhaW5zIChuZXR3 b3JrIGxheWVyaW5nIG1vZGVscykgYW5kIGNhbid0IGFncmVlIGlmIHlvdTxicj4NCiZndDsgc2Vl IHRoZSBzdW4gc2V0IG9yIG5vdC4gWW91IHNheSB5b3UgY2FuLCBidXQgWWFhY28gZG9uJ3QgYWdy ZWUsIHNpbmNlPGJyPg0KJmd0OyB0aGUgc3VuIGRpc2FwcGVhcmVkIGJlaGluZCB0aGUgbW91bnRh aW4geW91IGFyZSBzdGFuZGluZyBvbiBtb3JlIHRoYW48YnI+DQomZ3Q7IGFuIGhvdXIgYWdvLjxi cj4NCiZndDs8YnI+DQomZ3Q7IFdoYXQgSSB0aGluayBoYXBwZW5zIGlzIHRoYXQgeW91IHRoaW5r IGFib3V0IHByb3RlY3Rpb24gc3dpdGNoaW5nLDxicj4NCiZndDsgc2VsZWN0b3IgYW5kIGJyaWRn ZSBpbiB0aGUgdGVybXMgb2YgdGhlIG1vZGVsIHlvdSBhcmUgdXNlZCB0by48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBXaGVuIFlhYWNvdiBoZWFyIHRoYXQgaGUgdGhpbmtzIGFib3V0IHRoZW0gdGhlIHdh eSBoZSBpcyB1c2VkIHRvIHVzZTxicj4NCiZndDsgdGhlbSBmcm9tIGhpcyBtb2RlbC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBOZWl0aGVyIG1vZGVsIGlzICZxdW90O3JpZ2h0IG9yIHdyb25nJnF1b3Q7 IChib3RoIG1vdW50YWlucyBhcmUgcmVhbCkgYnV0IHRoZSBhcmU8YnI+DQomZ3Q7IGRpZmZlcmVu dC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGF0IEkgdHJpZWQgdG8gc2F5IHdhcyB0aGF0IHdoZW4g WWFhY292IHRoaW5rcyBhYm91dCBhcyBwaHlzaWNhbDxicj4NCiZndDsgb2JqZWN0cywgd2hpbGUg eW91IHNlZW0gdG8gdXNlIHRoZW0gYXMgYSBjbGFzcyBuYW1lLCBwZXJmb3JtaW5nIHRoZTxicj4N CiZndDsgc2FtZSBmdW5jdGlvbiBmb3IgYW55IGxheWVyLCBidXQgYWxzbyBpbXBsZW1lbnRlZCBk aWZmZXJlbnRseSBvbjxicj4NCiZndDsgZWFjaCBsYXllci48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ IHRoaW5rIHRoaXMgd2FzIHdoYXQgSHV1YiBhZ3JlZWQgdG8sIHJpZ2h0Pzxicj4NCiZndDs8YnI+ DQomZ3Q7IFlhYWNvdiBzdGVwIG9mIHRoaXMgdHJhaW4gaGVyZSBpZiB5b3UgZG9uJ3QgYWdyZWUh PGJyPg0KJmd0Ozxicj4NCiZndDsgU28gd2hhdCBJIGludGVuZGVkIHRvIHRvIHdhcyB0byBrZWVw IHRoZSBjbGFzcyBuYW1lIChmb3IgZXZlcnkgZXhpc3Rpbmc8YnI+DQomZ3Q7IGJyaWRnZSBhbmQg c2VsZWN0b3IsIGNhbGxpbmcgdGhlbSBqdXN0IHRoYXQpIGFuZCB6b29tIG9tIG9uIGUuZy4gb25l PGJyPg0KJmd0OyBuZXR3b3JrIGxheWVyaW5nIGluc3RhbmNlIG9mIHRoZSBjbGFzcywgdGFsa2lu ZyBhYm91dCAmcXVvdDttcGxzIHNlbGVjdG9yPGJyPg0KJmd0OyBmdW5jdGlvbiZxdW90OyBhbmQg JnF1b3Q7bXBscyBicmlkZ2UgZnVuY3Rpb24mcXVvdDsuPGJyPg0KJmd0Ozxicj4NCiZndDsgUGxl YXNlIG5vdGUgdGhhdCBJJ20gbm90IHN1Z2dlc3RpbmcgbmFtZXMgb3IgdGVybWlub2xvZ3ksIGp1 c3QgdHJ5aW5nPGJyPg0KJmd0OyB0byBmaWd1cmUgb3V0IGl0IGlmIHRoaXMgaXMgdGhlIHdoeSB5 b3UgZG9uJ3Qgc2VlbSB0byBhZ3JlZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZiB3ZSBhZ3JlZSB3 aGF0IHRoZSBwcm9ibGVtIGlzIHRoZW4gaXQgaXMgZmFpcmx5IGVhc3kgdG8gZmluZCB0aGU8YnI+ DQomZ3Q7IHRleHQgdGhhdCBuZWVkcyB0byBnbyBpbnRvIHRoZSBkb2N1bWVudC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyAvTG9hPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMjAxMy0xMi0yNyAxMDo0MSwg UnlvbywgSmVvbmctZG9uZyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgTG9hLDxicj4NCiZndDsgJmd0 OyBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9uIGNvcnJlY3RseSwgYnV0 IEkgd291bGQgc2F5IHRoYXQ6PGJyPg0KJmd0OyAmZ3Q7IEVhY2ggbGF5ZXIgaGFzIGl0cyBvd24g YnJpZGdlIGFuZCBzZWxlY3RvciBmb3IgcHJvdGVjdGlvbiBzd2l0Y2hpbmcsIHNvPGJyPg0KJmd0 OyAmZ3Q7IHRoYXQgZWFjaCBsYXllciBjYW4gcGVyZm9ybSBwcm90ZWN0aW9uIHN3aXRjaGluZyBv ZiBpdHMgb3duLjxicj4NCiZndDsgJmd0OyBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkg JnF1b3Q7YnJpZGdlL3NlbGVjdG9yIGZ1bmN0aW9uJnF1b3Q7LCBidXQgaW4gSVRVLVQ8YnI+DQom Z3Q7ICZndDsgdGVybWlub2xvZ3ksIHRoZSBicmlkZ2UgYW5kIHNlbGVjdG9yIGFyZSBpbmNsdWRl ZCBpbiAmcXVvdDtjb25uZWN0aW9uPGJyPg0KJmd0OyAmZ3Q7IGZ1bmN0aW9uJnF1b3Q7IG9mIGl0 cyBvd24gbGF5ZXIgKGZvciBleGFtcGxlLCBNVF9DIGZvciBNUExTLVRQIGNvbm5lY3Rpb248YnI+ DQomZ3Q7ICZndDsgZnVuY3Rpb24sIHdoaWNoIGluY2x1ZGVzIHRoZSBicmlkZ2UgYW5kIHRoZSBz ZWxlY3RvciBmb3IgdGhlIE1QTFMtVFA8YnI+DQomZ3Q7ICZndDsgbGF5ZXIpLjxicj4NCiZndDsg Jmd0OyBGb3IgdGhlIFBTQyBSRkMsIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBpbnRyb2R1Y2Ug YW55IG5ldyB0ZXJtaW5vbG9neTxicj4NCiZndDsgJmd0OyBzdWNoIGFzIHRoZSAmcXVvdDticmlk Z2Uvc2VsZWN0b3IgZnVuY3Rpb24mcXVvdDsgb3IgJnF1b3Q7Y29ubmVjdGlvbiBmdW5jdGlvbiZx dW90Oy48YnI+DQomZ3Q7ICZndDsgVGhlIGJyaWRnZS9zZWxlY3RvciBoYXZlIGFscmVhZHkgYmVl biBpbnRyb2R1Y2VkIGluIHRoZSBSRkM2Mzc4IChNUExTLVRQPGJyPg0KJmd0OyAmZ3Q7IGxpbmVh ciBwcm90ZWN0aW9uKS48YnI+DQomZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgJmd0 OyBKZW9uZy1kb25nPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCiZndDsgJmd0OyAqRnJvbSA6IComcXVvdDtMb2EgQW5kZXJzc29uJnF1b3Q7PGJyPg0K Jmd0OyAmZ3Q7ICpTZW50IDogKjIwMTMtMTItMjYgMTY6MDc6MTUgKCAmIzQzOzA5OjAwICk8YnI+ DQomZ3Q7ICZndDsgKlRvIDogKlJ5b28sIEplb25nLWRvbmcgLCBZYWFjb3YgV2VpbmdhcnRlbjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAqQ2MgOiAqbXBsc0BpZXRmLm9yZyAsPGJyPg0K Jmd0OyAmZ3Q7IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICpTdWJqZWN0IDogKlJlOiBbbXBsc10gUXVlc3Rpb24g cmVnYXJkaW5nIFNEIHByb3RlY3Rpb24gaW48YnI+DQomZ3Q7ICZndDsgZHJhZnQtaWV0Zi1tcGxz LXRwLXBzYy1pdHU8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSmVvbmctZG9uZyw8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSXMgdGhpcyBzaW1wbHkgYSBtYXR0ZXIgb2YgdGVy bWlub2xvZ3kuIEVhY2ggbGF5ZXIgbmVlZHMgdG8gcGVyZm9ybSBpdHM8YnI+DQomZ3Q7ICZndDsg b3duIHByb3RlY3Rpb24gc3dpdGNoaW5nLCBpLmUuIHRoZXJlIGhhcyB0byBiZSBhICpicmlkZ2Ug ZnVudGlvbiogYW5kIGE8YnI+DQomZ3Q7ICZndDsgKnNlbGVjdG9yIGZ1bmN0aW9uKiAob24gZWFj aCBsYXllciBkZXBlbmRpbmcgb24gdGhlIGltcGxlbWVudGF0aW9uKTs8YnI+DQomZ3Q7ICZndDsg d2hpbGUgKmJyaWRnZSogYW5kICpzZWxlY3RvciogYXJlIHRoZSBwaHlzaWNhbCBsYXllciBlbnRp dGllcz88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgL0xvYTxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBPbiAyMDEzLTEyLTI2IDEyOjUxLCBSeW9vLCBKZW9uZy1kb25nIHdyb3Rl Ojxicj4NCiZndDsgJmd0OyAmZ3Q7IFlhYWNvdiwgdGhhbmtzIGZvciB5b3VyIGVtYWlsLiBTb21l aG93LCBJIGZvcmdvdCB0byByZXNwb25kIGFuZCBhbTxicj4NCiZndDsgc29ycnk8YnI+DQomZ3Q7 ICZndDsgJmd0OyBmb3IgdGhlIGRlbGF5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgRmlyc3Qgb2YgYWxsLCBZYWFjb3YsIGl0IGlzIG5vdCB0cnVlIHRoYXQgdGhlIHBy b3RlY3Rpb24gc3dpdGNoaW5nIG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRXRoZXJuZXQgb3IgU0RI IGRlc2NyaWJlcyB0aGUgb3BlcmF0aW9uIG9mIGFueSBsYXllciBiZWxvdy4gUmF0aGVyLDxicj4N CiZndDsgZWFjaDxicj4NCiZndDsgJmd0OyAmZ3Q7IGxheWVyIGlzIHN1cHBvc2VkIHRvIG9wZXJh dGUgaW5kZXBlbmRlbnRseS4gSG93ZXZlciwgdGhlcmUgYXJlIGEgZmV3PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgZXhjZXB0aW9ucywgc3VjaCBhcyBob2xkLW9mZiB0aW1lciBhbmQgQUlTIChhcyBhIHRy aWdnZXIgZnJvbSBsb3dlcjxicj4NCiZndDsgJmd0OyAmZ3Q7IGxheWVyKS4gRXZlbiB0aG91Z2gg dGhlcmUgZXhpc3Qgc29tZSBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbnMgdGhhdDxicj4NCiZn dDsgJmd0OyAmZ3Q7IHVzZSBvdGhlciBpbmZvcm1hdGlvbiBmcm9tIGxvd2VyIGxheWVyLCBtb3N0 IG9mIHRoZW0gYXJlIG5vdDxicj4NCiZndDsgcmVjb21tZW5kZWQ8YnI+DQomZ3Q7ICZndDsgJmd0 OyBpbiBJVFUtVCBzdGFuZGFyZHMuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyBCcmlkZ2UgYW5kIHNlbGVjdG9yIGFyZSBub3QgaW4gdGhlIHBoeXNpY2FsIGxheWVyLCBi dXQgdGhleSBhcmUgcGFydCBvZjxicj4NCiZndDsgJmd0OyAmZ3Q7IHByb3RlY3Rpb24gc3dpdGNo aW5nLiBPbmUgb2YgdGhlIGltcG9ydGFudCBvdXRwdXQgYWN0aW9ucyBmcm9tIHRoZSBQU0M8YnI+ DQomZ3Q7ICZndDsgJmd0OyBjb250cm9sIGxvZ2ljIGlzIGNvb3JkaW5hdGluZyB0aGUgcG9zaXRp b25zIG9mIGJyaWRnZSBhbmQgc2VsZWN0b3IuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQWxzbywgdGhl IGJyaWRnZSBvcGVyYXRpb24gcmVzcG9uZGluZyB0byB0aGUgUFNDIGNvbnRyb2wgbG9naWMgaXMg YWxzbzxicj4NCiZndDsgJmd0OyAmZ3Q7IHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIEhv d2V2ZXIsIGhvdyB0byByZWFsaXplIHRoZSBicmlkZ2UgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsg c2VsZWN0b3IgKGZvciBleGFtcGxlLCBob3cgdG8gbWFuaXB1bGF0ZSBhIHBhY2tldCBmb3J3YXJk aW5nIG1lY2hhbmlzbSk8YnI+DQomZ3Q7ICZndDsgJmd0OyBpcyBhbiBpbXBsZW1lbnRhdGlvbiBt YXR0ZXIuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBXaGVuIHdlIG1l bnRpb24gMSYjNDM7MSBvciAxOjEgaW4gcHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUsIHdlIGRlYWwg d2l0aCB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBvcGVyYXRpb24gb2YgYnJpZGdlLiBGb3IgMSYj NDM7MSBhcmNoaXRlY3R1cmUsIHRoZSB0cmFmZmljIG5lZWRzIHRvIGJlPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgZHVwbGljYXRlZCBhdCB0aGUgc2VuZGVyIGFuZCBzZW50IHRvIGJvdGggcGF0aHMgYWxs IHRoZSB0aW1lLCB3aGljaCBpczxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSBzYW1lIGRlc2NyaXB0 aW9uIGFzIHRoZSDigJxwZXJtYW5lbnQgYnJpZGdl4oCdLiBGb3IgMToxIGFyY2hpdGVjdHVyZSw8 YnI+DQomZ3Q7ICZndDsgJmd0OyDigJxzZWxlY3RvciBicmlkZ2XigJ0gaXMgdXNlZCB0byBzZW5k IHRoZSB0cmFmZmljIG9ubHkgb25lIG9mIHRoZSBwYXRocy4gQXM8YnI+DQomZ3Q7ICZndDsgJmd0 OyB0aGUgcHJvdGVjdGlvbiBwYXRoIGNhbiBiZSB1c2VkIGJ5IGJlc3QgdHJhZmZpYyBpbiBwYWNr ZXQgbmV0d29ya3MgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIHBhY2tldCBkdXBsaWNhdGlv biB0YWtlcyBtdWNoIG1vcmUgZWZmb3J0L2ludGVybmFsIGJhbmR3aWR0aCBpbnNpZGU8YnI+DQom Z3Q7ICZndDsgJmd0OyBhIHN3aXRjaCB0aGFuIHRoZSB0aW1lIHNsb3QgY29weSBvZiBjaXJjdWl0 IG5ldHdvcmtzLiAxOjEgaXMgY29uc2lkZXJlZDxicj4NCiZndDsgJmd0OyAmZ3Q7IGFzIHByZWZl cmFibGUgYXJjaGl0ZWN0dXJlIGluIHBhY2tldCBuZXR3b3Jrcy48YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEFzIHlvdSBtaWdodCByZWNhbGwgZnJvbSBHLjgwMzEg4oCT IEV0aGVybmV0IGxpbmVhciBwcm90ZWN0aW9uLCB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBzZWxl Y3RvciBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVkIGR1ZSB0byB0aGUgdHJhZmZpYyBmbGFwcGlu ZyB1bmRlciBTRDxicj4NCiZndDsgJmd0OyAmZ3Q7IGNvbmRpdGlvbnMgb24gYm90aCBwYXRocy4g SW5zdGVhZCDigJxicm9hZGNhc3QgYnJpZGdl4oCdIGlzIGludHJvZHVjZWQgdG88YnI+DQomZ3Q7 ICZndDsgJmd0OyBzdXBwb3J0IHByb3RlY3Rpb24gc3dpdGNoaW5nIGFnYWluc3QgU0QuIEJ1dCwg dGhpcyBicm9hZGNhc3QgYnJpZGdlIGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbm90IHJlY29tbWVu ZGVkIGluIG5vbi1yZXZlcnRpdmUgbW9kZSBhcyB0aGUgd29ya2luZyBwYXRoIG5lZWRzIHRvIGJl PGJyPg0KJmd0OyAmZ3Q7ICZndDsgb2NjdXBpZWQgYnkgdHJhZmZpYyBhbGwgdGhlIHRpbWUuIEFs c28gdGhlIGJyb2FkY2FzdCBicmlkZ2UgaXMgbm90PGJyPg0KJmd0OyAmZ3Q7ICZndDsgZWZmaWNp ZW50LCBzaW5jZSBieSBkZWZpbml0aW9uLCB0aGUgcGFja2V0IGR1cGxpY2F0aW9uIHNob3VsZCBv Y2N1cjxicj4NCiZndDsgJmd0OyAmZ3Q7IGR1cmluZyBub3Qgb25seSBTRCBidXQgYWxzbyBTRiwg RlMsIE1TLCBldGMuIEluIHRoaXMgZG9jdW1lbnQsIHdlIGFyZTxicj4NCiZndDsgJmd0OyAmZ3Q7 IGludHJvZHVjaW5nIGFuIGltcHJvdmVkIGJyaWRnZSBtZWNoYW5pc20sIHdoaWNoIGJlaGF2ZXMg bGlrZSBhIHNlbGVjdG9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYnJpZGdlIGJ1dCBkdXBsaWNhdGVz IHRoZSB0cmFmZmljIG9ubHkgdW5kZXIgU0QgY29uZGl0aW9uLCBhbmQgd2U8YnI+DQomZ3Q7ICZn dDsgJmd0OyBiZWxpZXZlIHRoYXQgaXQgYWRkcmVzc2VzIGFsbCB0aGUgaXNzdWVzIHdpdGggZXhp c3RpbmcgYnJpZGdlcy48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFdo YXQgd2UgbWVhbiBieSBTRCBwcm90ZWN0aW9uIGlzIGFnbm9zdGljIHRvIHRoZSBTRCBkZXRlY3Rp b24gbWV0aG9kIGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhhdCB0aGUgcHJvcG9zZWQgU0QgcHJv dGVjdGlvbiBtZXRob2QgKGFnYWluIGhvdyB0byBvcGVyYXRlIGE8YnI+DQomZ3Q7IGJyaWRnZSBv cjxicj4NCiZndDsgJmd0OyAmZ3Q7IHdoYXQgYnJpZ2UgaXMgdXNlZCBpcyBhIHBhcnQgb2YgcHJv dGVjdGlvbiBzd2l0Y2hpbmcpIGNhbiBiZSB1c2VkIG5vPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbWF0 dGVyIHdoYXQga2luZCBvZiBTRCBkZXRlY3Rpb24gbWV0aG9kcyAoZGF0YSBwYWNrZXQgY291bnRp bmcsIENDTTxicj4NCiZndDsgJmd0OyAmZ3Q7IHBhY2tldCBjb3VudGluZywgb3IgZXZlbiBwcm9w cmlldGFyeSBzZXJ2ZXIgbGF5ZXIgU0QgZGV0ZWN0aW9uKSBpczxicj4NCiZndDsgdXNlZC48YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgdGhpbmsgSSBhbnN3ZXJlZCBh bGwgdGhlIHF1ZXN0aW9ucyBvbiB5b3VyIGVtYWlsLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgWWFhY292LCBpZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb25jZXJucyBv ciBxdWVzdGlvbnMsIHBsZWFzZSBsZXQgbWU8YnI+DQomZ3Q7ICZndDsga25vdy48YnI+DQomZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEplb25nLWRvbmc8YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQom Z3Q7ICZndDsgJmd0OyAqRnJvbSA6IComcXVvdDtZYWFjb3YgV2VpbmdhcnRlbiZxdW90Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICpTZW50IDogKjIwMTMtMTItMTAgMTY6MDQ6MTcgKCAmIzQzOzA5OjAw ICk8YnI+DQomZ3Q7ICZndDsgJmd0OyAqVG8gOiAqUnlvbywgSmVvbmctZG9uZzxicj4NCiZndDsg Jmd0OyAmZ3Q7ICpDYyA6ICpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9y Zzxicj4NCiZndDsgJmd0OyAmZ3Q7ICwgbXBsc0BpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7 ICpTdWJqZWN0IDogKlJlOiBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbjxicj4N CiZndDsgJmd0OyAmZ3Q7IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1PGJyPg0KJmd0OyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBKZW9uZy1kb25nLCBoaTxicj4NCiZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5LiBZb3VyIGFu c3dlciBzZWVtcyB0byBiZSBhbiBhcHByb3ByaWF0ZSBhbnN3ZXI8YnI+DQomZ3Q7ICZndDsgJmd0 OyBmb3Igb3RoZXIgU0RPcywgbm90IHN1cmUgdGhhdCBpdCBpcyB0cnVlIGZvciB0aGUgY29udGV4 dCBvZiBNUExTIGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7IElFVEYgd29yay48YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IDEuIFlvdSB3cm90ZSAmcXVvdDthbnkgcHJvdGVj dGlvbiBzd2l0Y2hpbmcgKGluY2x1ZGluZyBQU0MpIGlzIHN1cHBvc2VkIHRvPGJyPg0KJmd0OyAm Z3Q7ICZndDsgZGVzY3JpYmUgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiZx dW90OyAtIHRoaXMgbWF5IGJlIHRydWUgZm9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRXRoZXJuZXQg YW5kU0RIIGFuZCBmb3IgZG9jdW1lbnRzIHRoYXQgYXJlIGRlc2NyaWJpbmcgdGhlIG9wZXJhdGlv biBvZjxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSBwaHlzaWNhbCBsYXllci4gSG93ZXZlciwgdGhl IElFVEYgKHRvIG15IHVuZGVyc3RhbmRpbmcgLSBhbmQgSSBhbTxicj4NCiZndDsgJmd0OyAmZ3Q7 IGNlcnRhaW5seSB3aWxsaW5nIHRvIGJlIGNvcnJlY3RlZCBvbiB0aGlzIHBvaW50KSBpcyBjb25j ZXJuZWQgd2l0aCB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBwcm90b2NvbCBhbmQgbGVhdmUgdGhl IGxvd2VyIGxheWVycyB0byBpbXBsZW1lbnRhdGlvbi4gQWxzbywgSSBhbSBub3Q8YnI+DQomZ3Q7 ICZndDsgJmd0OyBzdXJlIHRoYXQgdGhlIGNvbmNlcHRzIG9mIEJyaWRnZSBhbmQgU2VsZWN0b3Ig cmVhbGx5IGFwcGx5IHRvIE1QTFM8YnI+DQomZ3Q7ICZndDsgJmd0OyAoYWx0aG91Z2ggSSBhZG1p dCB0aGF0IHdlIGRpZCBtZW50aW9uIHRoZW0gaW4gdGhlIG9yaWdpbmFsIFBTQzxicj4NCiZndDsg Jmd0OyBkZWZpbml0aW9uKS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 IDIuIFlvdSBjaXRlIHdoYXQgd2FzIHdyaXR0ZW4gaW4gRzgwMzEgYXMganVzdGlmaWNhdGlvbiBm b3IgaW5jbHVkaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29udGVudCBpbnRvIHlvdXIgZHJhZnQu IEFnYWluIGl0IGlzIGhhcmQgdG8gdHJhbnNmZXIgbWV0aG9kb2xvZ3kgZnJvbTxicj4NCiZndDsg Jmd0OyAmZ3Q7IG9uZSBTRE8gdG8gYW5vdGhlciBhbmQgdGhlcmVmb3JlLCB3aGlsZSBJIGhpZ2hs eSByZXNwZWN0IHRoZSB3b3JrPGJyPg0KJmd0OyBvZiB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBJ VFUsIEkgZG8gbm90IGZlZWwgdGhhdCB0aGlzIGlzIGEgdmVyeSBjbGVhciBqdXN0aWZpY2F0aW9u IGZvcjxicj4NCiZndDsgaW5jbHVzaW9uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW50byBhbiBpbnRl cm5ldC1kcmFmdC4gRXZlbiB3aGVuIHRoZSBkcmFmdCBzdGF0ZXMgdGhhdCBpdHMgcHVycG9zZSBp czxicj4NCiZndDsgJmd0OyAmZ3Q7IHRvIGFkZHJlc3MgdGhlIGNvbmNlcm5zIG9mIHRoZSBJVFUu PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAzLiBUbyB0aGUgYWN0dWFs IHBvaW50IG9mIG15IGVhcmxpZXIgY29tbWVudCwgdGhhdCB5b3UgZG8gbm90IHNlZW0gdG88YnI+ DQomZ3Q7ICZndDsgJmd0OyBhZGRyZXNzIC0gdGhlIHBhcmFncmFwaCBpbiBTZWN0aW9uIDcuMyBz ZWVtcyB0byBzdGF0ZSB0aGF0IFNEPGJyPg0KJmd0OyBwcm90ZWN0aW9uPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgY2hhbmdlcyBhY2NvcmRpbmcgdG8gdGhlIG1ldGhvZCB0aGF0IGlzIHVzZWQgdG8gZGV0 ZWN0IHRoZSBTRC4gVGhpczxicj4NCiZndDsgJmd0OyAmZ3Q7IG1lYW5zIHRoYXQgU0QgcHJvdGVj dGlvbiBpcyBub3QgYWdub3N0aWMgdG8gdGhlIG1ldGhvZCB1c2VkIGZvciB0aGU8YnI+DQomZ3Q7 ICZndDsgJmd0OyBkZXRlY3Rpb24uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQWx0ZXJuYXRpdmVseSwg d2UgY291bGQgYnJlYWsgdGhpcyBkZXBlbmRlbmNlIGFuZCBzdGF0ZSB0aGF0IFNEPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgcHJvdGVjdGlvbiBpcyBhbHdheXMgcHJvdmlkZWQgYnkgY2hhbmdpbmcgdGhl IHRyYW5zbWlzc2lvbiBvZiB0aGUgZGF0YTxicj4NCiZndDsgJmd0OyAmZ3Q7IHRvIDEmIzQzOzEg cHJvdGVjdGlvbiBpbiBjYXNlcyBvZiBTRCBkZXRlY3Rpb24sIHdoaWNoIGlzIHdoYXQgdGhlIHBh cmFncmFwaDxicj4NCiZndDsgJmd0OyAmZ3Q7IGlzIHN1Z2dlc3RpbmcgdG8gZG8gZm9yIHNvbWUg Y2FzZXMuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIGhvcGUgdGhp cyBmb3JtdWxhdGlvbiBtYWtlIG15IGNvbW1lbnQgY2xlYXJlciBhbmQgd2UgYXJlIGFibGUgdG88 YnI+DQomZ3Q7ICZndDsgJmd0OyBkaXNjdXNzIHRoZSB0ZWNobm9sb2dpY2FsIGFwcHJvYWNoIHJh dGhlciB0aGFuIHRoZSBwaGlsb3NvcGhpY2FsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZGlmZmVyZW5j ZXMuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGFuayB5b3UsPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgeWFhY292PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIE1vbiwgRGVjIDksIDIwMTMgYXQgMTA6MDQg UE0sIFJ5b28sIEplb25nLWRvbmcgJmd0OyAmZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgWWFhY292LDxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgWWVzLCBQU0MgaXMgc3VwcG9zZWQgdG8gYmUgYWdub3N0aWMgdG8gdGhlIG1l dGhvZCB1c2VkIGZvciB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBkZXRlY3Rpb24gb2YgU0YvU0Qu PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBJdCBpcyBhbHNvIHRydWUg dGhhdCBhbnkgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGluY2x1ZGluZyBQU0MpIGlzPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgc3VwcG9zZWQgdG8gZGVzY3JpYmUgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2Ug YW5kIHNlbGVjdG9yLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXMg dGhlcmUgYXJlIG11bHRpcGxlIG9wdGlvbnMgZm9yIGRldGVjdGluZyBTRCwgd2UgbmVlZGVkIHRv PGJyPg0KJmd0OyAmZ3Q7ICZndDsgZGVzY3JpYmUgdGhlIGJlaGF2aW9yIG9mIHRoZSBicmlkZ2Ug dG8gY292ZXIgYWxsIHRoZSBwb3NzaWJsZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGRldGVjdGlvbiBt ZXRob2RzLiBEZXNjcmliaW5nIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGZvciBTRDxicj4NCiZn dDsgJmd0OyAmZ3Q7IHByb3RlY3Rpb24gaXMgbm90IGEgbmV3IHRoaW5nLiBGb3IgZXhhbXBsZSwg Ry44MDMxIC0gRXRoZXJuZXQgbGluZWFyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcHJvdGVjdGlvbiBh bHNvIGRlc2NyaWJlcyB3aGF0IGJyaWRnZSBjYW4gYmUgdXNlZCBpbiBvcmRlciB0bzxicj4NCiZn dDsgJmd0OyAmZ3Q7IHByb3ZpZGUgcHJvdGVjdGlvbiBhZ2FpbnN0IFNELjxicj4NCiZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSmVvbmctZG9uZzxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsg Jmd0OyAmZ3Q7ICpGcm9tIDogKiZxdW90O1lhYWNvdiBXZWluZ2FydGVuJnF1b3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICpTZW50IDogKjIwMTMtMTItMDggMjA6MDE6NTUgKCAmIzQz OzA5OjAwICk8YnI+DQomZ3Q7ICZndDsgJmd0OyAqVG8gOiAqZHJhZnQtaWV0Zi1tcGxzLXRwLXBz Yy1pdHVAdG9vbHMuaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OywgbXBsc0BpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAqQ2MgOiAqPGJyPg0KJmd0OyAmZ3Q7ICZndDsgKlN1YmplY3QgOiAq UXVlc3Rpb24gcmVnYXJkaW5nIFNEIHByb3RlY3Rpb24gaW48YnI+DQomZ3Q7ICZndDsgJmd0OyBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7IEFmdGVyIHJlYWRpbmcgdGhyb3VnaCB5b3VyIGRyYWZ0IG9uIHRoZSBl eHRlbnNpb25zIHRvIFBTQyB0byBzdXBwb3J0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU0Qgc2l0dWF0 aW9ucywgSSBoYXZlIGEgcXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb24gLTxicj4NCiZndDsgJmd0 OyAmZ3Q7IEluIHlvdXIgaW50cm9kdWN0aW9uIC0geW91IHN0YXRlIHRoYXQgdGhlIG1ldGhvZCB1 c2VkIHRvIGRldGVjdCBTRDxicj4NCiZndDsgJmd0OyAmZ3Q7IHNpdHVhdGlvbnMgaXMgb3V0LW9m LXNjb3BlIG9mIHRoZSBkb2N1bWVudC4gRG9lcyB0aGlzIG1lYW4gdGhhdCBQU0M8YnI+DQomZ3Q7 ICZndDsgJmd0OyBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQg Zm9yIHRoaXMgZGV0ZWN0aW9uPyBJdDxicj4NCiZndDsgJmd0OyAmZ3Q7IHNob3VsZCByZWFjdCBv bmx5IHRvIHRoZSBpbmRpY2F0aW9uLCBzaW1pbGFybHkgdG8gdGhlIHJlYWN0aW9uIGFuZDxicj4N CiZndDsgJmd0OyAmZ3Q7IHJlbGF0aW9uc2hpcCB0byB0aGUgbWV0aG9kIGZvciBkZXRlY3Rpbmcg YW5kIGRlY2xhcmluZyBhIFNGIHNpdHVhdGlvbi48YnI+DQomZ3Q7ICZndDsgJmd0OyBIb3dldmVy LCB3aGVuIHlvdSBleHBsYWluIHRoZSBiZWhhdmlvciBvZiB0aGUgU0QgcHJvdGVjdGlvbiBpbjxi cj4NCiZndDsgJmd0OyAmZ3Q7IHNlY3Rpb24gNy4zIHlvdSBoYXZlIGEgcGFyYWdyYXBoIHRoYXQg c3RhcnRzIHdpdGggJnF1b3Q7SWYgdGhlIGRldGVjdGlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7IG9m IGEgU0QgZGVwZW5kcyBvbiB0aGUgcHJlc2VuY2Ugb2YgdXNlciBkYXRhIHBhY2tldHMgLi4uJnF1 b3Q7IHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IHRoZSBi ZWhhdmlvciBvZiB0aGUgc3lzdGVtIGlzIGRlcGVuZGVudCB1cG9uPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgdGhlIGRldGVjdGlvbiBtZXRob2QhIENsYXJpZmljYXRpb24gd291bGQgYmUgYXBwcmVjaWF0 ZWQuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLTxicj4NCiZndDsg Jmd0OyAmZ3Q7IFRoYW54IGFuZCBCUiw8YnI+DQomZ3Q7ICZndDsgJmd0OyB5YWFjb3Y8YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IC9TdGlsbCBsb29raW5nIGZvciBuZXcg b3Bwb3J0dW5pdHkvPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAt LTxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoYW54IGFuZCBCUiw8YnI+DQomZ3Q7ICZndDsgJmd0OyB5 YWFjb3Y8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IC9TdGlsbCBsb29r aW5nIGZvciBuZXcgb3Bwb3J0dW5pdHkvPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbXBscyBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7ICZndDsgJmd0OyBtcGxzQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgLS08YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5o dWF3ZWkuY29tPGJyPg0KJmd0OyAmZ3Q7IFNlbmlvciBNUExTIEV4cGVydCBsb2FAcGkubnU8YnI+ DQomZ3Q7ICZndDsgSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICYjNDM7 NDYgNzM5IDgxIDIxIDY0PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPGJy Pg0KJmd0OyBTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51PGJyPg0KJmd0OyBIdWF3ZWkgVGVj aG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogJiM0Mzs0NiA3MzkgODEgMjEgNjQ8YnI+DQo8 YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAx Lmh1YXdlaS5jb208YnI+DQpTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51PGJyPg0KSHVhd2Vp IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B1350SMTP2etriinfo_-- From curtis@ipv6.occnc.com Tue Jan 14 17:42:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E0E1AE143 for ; Tue, 14 Jan 2014 17:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RP_MATCHES_RCVD=-0.538, 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 fi26HDFR2-Uz for ; Tue, 14 Jan 2014 17:42:44 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id E92841AE1F1 for ; Tue, 14 Jan 2014 17:42:43 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F1gVJP006084; Tue, 14 Jan 2014 20:42:31 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401150142.s0F1gVJP006084@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 21:44:29 +0000." <290E20B455C66743BE178C5C84F1240847E63346C4@EXMB01CMS.surrey.ac.uk> Date: Tue, 14 Jan 2014 20:42:31 -0500 Cc: mpls@ietf.org, ietf@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 01:42:47 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346C4@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > The HDLC part here is last link, not the scope of the whole path. Any > 'low' bit error rate given actually becomes quite high once you > consider no of bits per packet and line rate... > > Do read Jonathan Stone's papers on where errors creep in - not just in > the link, by at any point along the path, including regeneration > > Lloyd Wood Lloyd, There is no HDLC hop. No one has used HDLC for internet infrastructure in ages. It was a joke, like Scott's comment on wanting to use X.25. HDLC was disappearing when the Stone/Partridge Sigcomm 2000 paper was written. Links please. And how old is that paper? Not another 15 year old work is it? If you have one bit error per day, how many packets do you lose that day? (hint: one). If you have one bit error per day, how many undetactable packet errors do you have? (hint: crc32 gets all one bit errors, therefore zero). 10^-12 bit errors is one per 10 second on 100 Gb/s, one per 100 second on 10 Gb/s and is generally considered high enough to take a link down immediately. A 1500 byte packet is 12,000 bits, about ~10^4. That would yield a packet rate as high as 10^-8 if bit errors were mostly one bit error per packet. In that case all errors would be detectable. It is only when there are a lot of bit errors or more per packet that the CRC can be defeated and then its about 10^-9 chance. So at an error rate much less than 10^-8 packets (tightly bunched errors with multiple bit errors per packet) some 10^-9 might be undetectable with a CRC32. One packet every 10^6 seconds at 100 Gb/s could have an undetectable error. About one undetectable error a day or one a week for continuous full out 100 Gb/s link. Note that the same low error rate does not apply to a GbE or 10GbE over colored optics over ROADM in the metro since there is no FEC there. It also may not apply to the enterprise or campus Ethernets. In those hops the error rate is likely to be higher. Needless to say, wireless hops can have very high error rates. This is why it could make sense to have the UDP checksum optional in MPLS over UDP. It wouldn't hurt to provide the checksums but in some cases it might be OK to disable them. That is what SHOULD is for in an IETF document. Curtis > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 14 January 2014 20:54 > To: Wood L Dr (Electronic Eng) > Cc: jmh@joelhalpern.com; lars@netapp.com; xuxiaohu@huawei.com; mpls@ietf.org; ietf@ietf.org > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > In message <290E20B455C66743BE178C5C84F1240847E63346C3@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > It stands to reason that if tunnelers can turn off udp checksums > > because their performance is degraded, they can turn off > > congestion control because it will degrade their performance. > > > > Rest of the internet getting congested and getting > > misdelivered corrupted packets? Really not their problem. > > > > There are important vendors trying to sell products here, > > and they need performance to do so. > > Get with the program! > > > > Lloyd Wood > > http://about.me/lloydwood > > > OK, perhaps if you are running MPLS/UDP/IP over HDLC and the HDLC > configuration is set to count FCS errors but not drop you will still > *really* need the UDP checksum. Otherwise its isn't going to do much > for you. Any checksum is really bad for some types of errors such as > chunk reordering and multiple bit errors. > > Maybe on HDLC or PPP with 16 bit CRC you may see a low error rate, but > in theory that would be much less than 10^-5 since few multiple bit > errors will be coincidence match the CRC, even for a 16 bit CRC. > > I suspect most routers would be able to do the checksum anyway and for > modern links if they come up with a zero error count that's fine. > > > > Modern OTN based transport networks use forward error correction FEC > which accounts for a fair amount of overhead and a lot of processing > gates on the receiving end. The measure of effectiveness of given FEC > is in dB with 10 dB being a reduction of a factor of 10 in bit errors > and typical FEC in the high tens of dB. The target corrected error > rate is often 10^-15 or one bit error in 24 hours for 10 Gb/s, one bit > error in 2.5 hours for 100 Gb/s. Any link with corrected bit error > rates approaching 10^-12 is taken out of service. This is roughly > equivalent to the old ES (errored seconds) and SES (severely errored > seconds) metric where a ES is one second with any bit errors and an > SES is one second with 10 or more errors (I think its 10). More than > some number of ES or SES and a link is taken down. The uncorrected > errors are passed through. > > A packet may traverse an entire continent with 2-3 such links > separated by regeneration or could stop at a number of routers along > the way. Typically today the router uses 10GbE or 100GbE (growing > use) which are then passed as a bit stream in the transport network. > At the other end the uncorrected errors from transport are picked up > by Ethernet 32 bit FCS. Since a 32 bit FCS picks up 100% of single > bit errors and most instances where a small number of bits are in > error, and all but 1 in 2^32 where many bits are in error, few errors > are going to get through. If GFP is used, the per packet FCS is > checked at each hop and for GFP-T also checked end to end. > > A bad local ethernet is more likely to contribute an error (again > better than 1 in 2^32 detection is expected) due to something like a > bad CAT-{5,5e,6} connection or too many sharp turns. A DSL or DOCSIS > link is also more likely to contribute an error. With CRC32 on all > links and no bad hardware in between (ie: circa 1990s equipment with > no parity RAM and no correction on DMA, buses, etc) you would expect > on the order of 10^-8 errors (10^-9 per hop, a few errored hops). > > For example, two hosts on my home LAN had non-zero tcp checksums. > Each had < 10^-6 packet error rate. It is hard to tell if this is > host errors at the other end. The only hosts I have with non-zero are > on the service provider DMZ LAN so that would include any bot attacks, > etc, where sending hosts could be old junk. Host behind those have > zero UDP and TCP checksum errors. This seems similar to Stewart's > quick check. > > In the T1/T3 days the transport layer just had parity and just counted > parity errors. Providers in those days were notorious for ignoring ES > and SES counters until the customer complained. HDLC then had its 16 > bit CRC, optional 32 bit. If an ISP wasn't paying attention to their > HDLC error counters then it was up to the IP end customer to complain > and hope the problem got escallated rather than dropped. > > > > As to whether congestion control is in practice needed see > http://www.ietf.org/mail-archive/web/mpls/current/msg11222.html > > Its fine to make them both optional and to make congestion control > mechanisms out of scope and the topic of a later document if needed. > > Curtis > > > > > ________________________________________ > > From: ietf [ietf-bounces@ietf.org] On Behalf Of Joel M. Halpern [jmh@joelhalpern.com] > > Sent: 10 January 2014 15:36 > > To: Eggert, Lars; Xuxiaohu > > Cc: mpls@ietf.org; IETF > > Subject: Re: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > > > Maybe I am completely missing things, but this looks wrong. > > If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion > > control will make it more likely that the service won't work. Is that > > really the goal? > > > > We do not perform congestion control on MPLS LSPs. > > Assuming that a UDP tunnel is carrying just MPLS and was established > > just for MPLS, why would we expect it to behave differently than an MPLS > > LSP running over the exact same path, carrying the exact same traffic? > > > > Yours, > > Joel > > > > On 1/10/14 3:47 AM, Eggert, Lars wrote: > > > Hi, > > > > > > that sounds good. What congestion control are you going to be specifying for your tunnel? > > > > > > Lars > > > > > > On 2014-1-10, at 4:46, Xuxiaohu wrote: > > > > > >> Hi Lars, > > >> > > >> Thanks a lot for your comments. > > >> > > >> I wonder whether the following modified text for Congestion Consideration section is OK from your point of view: > > >> > > >> Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded through "UDP tunnels", the congestion control guidelines for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically, MPLS can carry a number of different protocols as payloads. When the payload traffic is IP-based and congestion-controlled, the UDP tunnel SHOULD NOT employ its own congestion control mechanism, because congestion losses of tunneled traffic will already trigger an appropriate congestion response at the original senders of the tunneled traffic. When the payload traffic is not known to be IP-based, or is known to be IP-based but not congestion-controlled, the UDP tunnel SHOULD employ an appropriate congestion control mechanism. Furthermore, because UDP tunnels are usually bulk-transfer applications as far as the intermediate routers are concerned, the guidelines as defined in Section 3.1.1 of [RFC5405] SHOULD apply. > > >> > > >> Best regards, > > >> Xiaohu > > >> > > >>> -----ÓʼþÔ­¼þ----- > > >>> ·¢¼þÈË: mpls [mailto:mpls-bounces@ietf.org] ´ú±í Eggert, Lars > > >>> ·¢ËÍʱ¼ä: 2014Äê1ÔÂ8ÈÕ 18:22 > > >>> ÊÕ¼þÈË: IETF > > >>> ³­ËÍ: mpls@ietf.org > > >>> Ö÷Ìâ: Re: [mpls] Last Call: (Encapsulating MPLS > > >>> in UDP) to Proposed Standard > > >>> > > >>> Hi, > > >>> > > >>> On 2014-1-2, at 16:14, The IESG wrote: > > >>>> - 'Encapsulating MPLS in UDP' > > >>>> as Proposed Standard > > >>> > > >>> > > >>> this document needs to describe how it addresses the issues raised in BCP145 > > >>> (RFC5405). It already contains some text about messages sizes and congestion > > >>> considerations, which is great. Unfortunately, the text about congestion > > >>> considerations is not fully in line with RFC5405. > > >>> > > >>> Lars > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From xuxiaohu@huawei.com Tue Jan 14 19:07:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1091AE1CD; Tue, 14 Jan 2014 19:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 o8YfEzJwIAPB; Tue, 14 Jan 2014 19:07:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 977261AE1C5; Tue, 14 Jan 2014 19:07:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZY31235; Wed, 15 Jan 2014 03:06:49 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jan 2014 03:05:57 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jan 2014 03:06:48 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 15 Jan 2014 11:06:44 +0800 From: Xuxiaohu To: "curtis@ipv6.occnc.com" , Wesley Eddy Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPEY8CmZemCkyvYUuoIcxHPrslpZqFEdhw Date: Wed, 15 Jan 2014 03:06:44 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08244E41@NKGEML512-MBS.china.huawei.com> References: Your message of "Tue, 14 Jan 2014 11:22:02 -0500." <52D5642A.7090103@mti-systems.com> <201401150113.s0F1DXSN005803@maildrop2.v6ds.occnc.com> In-Reply-To: <201401150113.s0F1DXSN005803@maildrop2.v6ds.occnc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Eggert, Lars" , Scott Brim , IETF discussion list , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 03:07:04 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBscyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBDdXJ0aXMgVmlsbGFtaXphcg0KPiC3osvNyrG85DogMjAxNMTq MdTCMTXI1SA5OjE0DQo+IMrVvP7IyzogV2VzbGV5IEVkZHkNCj4gs63LzTogU2NvdHQgQnJpbTsg RWdnZXJ0LCBMYXJzOyBJRVRGIGRpc2N1c3Npb24gbGlzdDsgbXBsc0BpZXRmLm9yZw0KPiDW98zi OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAo RW5jYXBzdWxhdGluZyBNUExTDQo+IGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+ IA0KPiBJbiBtZXNzYWdlIDw1MkQ1NjQyQS43MDkwMTAzQG10aS1zeXN0ZW1zLmNvbT4NCj4gV2Vz bGV5IEVkZHkgd3JpdGVzOg0KPiANCj4gPiBPbiAxLzE0LzIwMTQgMTE6MDYgQU0sIEVnZ2VydCwg TGFycyB3cm90ZToNCj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+IE9uIDIwMTQtMS0xNCwgYXQgMTY6 MzksIFNjb3R0IEJyaW0gPHNjb3R0LmJyaW1AZ21haWwuY29tPiB3cm90ZToNCj4gPiA+PiBMYXJz LCBJIGtub3cgd2UncmUgcmVwZWF0aW5nIGFyZ3VtZW50cyBmcm9tIHRoZSBsYXN0IGRlY2FkZS4g VGhlDQo+ID4gPj4gY2hvaWNlIGlzIGJldHdlZW4gKDEpIHNwZWNpZnlpbmcgY29uZ2VzdGlvbiBj b250cm9sIGFyb3VuZCB0aGUNCj4gPiA+PiBzdWJzdHJhdGUgVURQIHRoYXQgY2FuIGJlIHR1cm5l ZCBvZmYgaWYgaXQgY2F1c2VzIHByb2JsZW1zLCBvciAoMikNCj4gPiA+PiBzcGVjaWZ5aW5nIG5v dGhpbmcgYXQgdGhpcyB0aW1lIGFuZCBhZGRpbmcgaXQgbGF0ZXIgaWYgb3BlcmF0b3JzDQo+ID4g Pj4gd2FudCBpdC4NCj4gPiA+Pg0KPiA+ID4+IEkgZ3Vlc3MgaWYgdGhpcyBjYW4gYmUgd3JpdHRl biBhcyBhIFNIT1VMRCwgdXAgdG8gdGhlIGltcGxlbWVudG9yJ3MNCj4gPiA+PiBkaXNjcmV0aW9u LCB0aGVuIG9rYXkuDQo+ID4gPg0KPiA+ID4gSSBkb24ndCB0aGluayB3ZSBjYW4gbGVhdmUgdGhp cyB1cCB0byBpbXBsZW1lbnRvcnMgZGlzY3JldGlvbi4gV2UndmUgaGFkDQo+IElFVEYgY29uc2Vu c3VzIHRoYXQgSW50ZXJuZXQgY29tbXVuaWNhdGlvbiByZXF1aXJlcyBjb25nZXN0aW9uIGNvbnRy b2wgYXQgbGVhc3QNCj4gc2luY2UgUkZDMjkxNC4gQSBjaXJjdWl0IGJyZWFrZXIgbWVjaGFuaXNt cyBzZWVtcyBzdHJhaWdodGZvcndhcmQgdG8NCj4gaW1wbGVtZW50Lg0KPiA+ID4NCj4gPiA+IEFz IGlzLCBJIG9iamVjdCB0byB0aGlzIGRvY3VtZW50IGdvaW5nIGZvcndhcmQuIFRoZSBtaW5vciBi ZW5lZml0cyBvZiBnZXR0aW5nDQo+IHNvbWUgYmV0dGVyIGxvYWQgYmFsYW5jaW5nIGZvciBNUExT IGFyZSBmYXIgb3V0d2VpZ2hlZCBieSB0aGUgcmlza3MuDQo+ID4gPg0KPiA+ID4gKEknbSBhbHNv IGdvaW5nIHRvIHNodXQgdXAgbm93LCBhbmQgbGV0IG90aGVycyBzcGVhay4gSSB0aGluayBJJ3Zl DQo+ID4gPiBzYWlkIG15IGJpdC4pDQo+ID4gPg0KPiA+DQo+ID4NCj4gPiBJJ20gaW4gYmFzaWMg YWdyZWVtZW50Lg0KPiA+DQo+ID4gQXNzdW1pbmcgd2UgbWlnaHQgYWxsIGFncmVlIHRoYXQgdGhl cmUgYXJlIGNvbmNlaXZhYmxlIHNjZW5hcmlvcyB3aGVyZQ0KPiA+IGEgY2lyY3VpdCBicmVha2Vy IG1lY2hhbmlzbSB3b3VsZCBiZSB1c2VmdWwsIGlzIHRoZSByZWFsIGlzc3VlIHRoYXQgd2UNCj4g PiBkb24ndCBhbGwgYWdyZWUgdGhhdCBpdCBjb3VsZCBiZSBpbXBsZW1lbnRlZCBpbiBhIHdheSB0 aGF0J3Mgbm90DQo+ID4gYnVyZGVuc29tZSBhbmQgZG9lc24ndCBkZWdyYWRlIHBlcmZvcm1hbmNl IHVubmVjZXNzYXJpbHk/DQo+ID4NCj4gPiBPciBpcyB0aGVyZSBzdGlsbCBmdW5kYW1lbnRhbCBk aXNhZ3JlZW1lbnQgYWJvdXQgd2hldGhlciB0aGUgc2NlbmFyaW9zDQo+ID4gd2hlcmUgdGhlIGNp cmN1aXQgYnJlYWtlciBpcyB1c2VmdWwgYXJlIGV2ZW4gdmFsaWQ/DQo+IA0KPiANCj4gQSBjaXJj dWl0IGJyZWFrZXIgKGRyb3AgYWxsIHRyYWZmaWMgb24gc2lnbiBvZiBjb25nZXN0aW9uKSBhdCB0 aGUgTVBMUyBvdmVyIFVEUA0KPiBsZXZlbCB3b3VsZCBiZSB0aGUgd29yc3QgdGhpbmcgeW91IGNv dWxkIHNwZWNpZnkgYW5kIElNTyBpdCB3b3VsZCBndWFyZW50ZWUNCj4gemVybyBpbXBsZW1lbnRh dGlvbnMuDQo+IA0KPiBBIGNpcmN1aXQgYnJlYWtlciBtaWdodCBiZSBhcHByb3ByaWF0ZSBmb3Ig VERNIG92ZXIgUFcgYnV0IG5vdGhpbmcgZWxzZS4gIFRoaXMNCj4gbWFrZXMgc2Vuc2UgYmVjYXVz ZSBURE0gY2Fubm90IGNoYW5nZSBpdHMgYmFuZHdpZHRoIHNvIHRoZSBvbmx5IGNob2ljZSBpcyB0 bw0KPiBzaHV0IGl0IG9mZi4gIFRETSBvdmVyIFBXIGlzIGFuIGFwcGxpY2F0aW9uIHRoYXQgY2Fu IHJ1biBvdmVyIE1QTFMgKG9yIEdSRSBvcg0KPiBMMlRQKS4gIFRoZSBiZXN0IHBsYWNlIHRvIHB1 dCB0aGF0IGNpcmN1aXQgYnJlYWtlciAoaWYgYW55d2hlcmUgYXQgYWxsKSBpcyBpbiBURE0NCj4g b3ZlciBQVy4NCg0KSSBjb3VsZG4ndCBhZ3JlZSBtb3JlIHdpdGggQ3VydGlzJ3MgcG9pbnQuIFNp bmNlIFJGQzM5ODUgaGFzIGFscmVhZHkgbWFkZSBhIGRldGFpbGVkIGRlc2NyaXB0aW9uIG9mIGNv bmdlc3Rpb24gY29uc2lkZXJhdGlvbnMgYWJvdXQgUFdzLCBpdCBzZWVtcyB0aGF0IHRoZSBzaW1w bGVzdCB3YXkgaXMganVzdCB0byBhZGQgYSByZWZlcmVuY2UgdG8gdGhhdCBSRkMgaW4gdGhpcyBk b2MsIGluIGFkZGl0aW9uIHRvIHRoZSB0ZXh0IEkgaGF2ZSBwcm9wb3NlZCBpbiBhIHByZXZpb3Vz IGVtYWlsLiBUaGUgYWR2YW50YWdlIG9mIHRoaXMgY2hvaWNlIGlzOiBzaW5jZSB0aGVyZSBpcyBv bmx5IG9uZSBwbGFjZSB3aGVyZSB0aGUgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSBmb3Ig TVBMUy9QVyB0cmFmZmljIGlzIHNwZWNpZmllZCwgaXQncyBtdWNoIGVhc2llciBmb3Igb3BlcmF0 b3JzIGFuZCBpbXBsZW1lbnRvcnMgdG8gcmVmZXIuIEluIGFkZGl0aW9uLCBvbmNlIGEgbW9yZSBw cmFjdGljYWwgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSB3YXMgZm91bmQgaW4gdGhlIGZ1 dHVyZSwgaXQgb25seSBuZWVkcyB0byB1cGRhdGUgb25lIFJGQywgcmF0aGVyIHRoYW4gdXBkYXRp bmcgbWFueSBSRkNzLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBDdXJ0aXMNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWls aW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCg== From curtis@ipv6.occnc.com Tue Jan 14 19:30:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94431AE261; Tue, 14 Jan 2014 19:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 PEO0_74N9T4p; Tue, 14 Jan 2014 19:30:02 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 37E571AE25B; Tue, 14 Jan 2014 19:30:01 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F3TX9p007369; Tue, 14 Jan 2014 22:29:34 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401150329.s0F3TX9p007369@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 21:57:20 +0000." <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> Date: Tue, 14 Jan 2014 22:29:33 -0500 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 03:30:07 -0000 Lloyd, At this point in time those who would know what error rates are for current technologies are likely to be people who work for transport vendors, router vendors, and operators and those are the type of people you have been arguing with. You don't really think that no one has thought about improving error rates in 15 years, right? That said, if an academic can do a direct measurement *today* the results might add something to the discussion. A paper that old adds little for this particualar topic because too much has changed. I anyone thought today's rates of undetectable errors were a problem they would be adding something more robust such as a 64 bit CRC to important link layers. [Some bandwidth would be chewed up. TCP ACK packets would get bigger. Mpps rates for "small packets" would be easier to hit. What's not to like. :-) ] Curtis In message <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: I don't think sayng 'oh, that error source is no longer a problem' disproves Stone's overall point about undetected errors, though the examples he uses from the technology of the day are necessarily dated. Dismissing the overall point because the examples use obsolete technology is throwing the baby out with the bathwater; a host-to-host error check catches things that intermediate checks cannot. Measuring error rates across end-to-end Internet traffic is something that has not received much attention , as error detection is not instrumented well - hence citing Stone's published work, in the absence of awareness of anything newer (and as high profile/immediately recognisable as sigcomm) in the area. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: 14 January 2014 18:26 To: curtis@ipv6.occnc.com; Wood L Dr (Electronic Eng) Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; lisp@ietf.org; david.black@emc.com; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu Subject: Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) I agree the paper is now obsolete. Stewart On 14/01/2014 17:06, Curtis Villamizar wrote: > Lloyd, > > Maybe you should reread the paper too before citing it as evidence. > Check the date on it. Check the cited causes of errors. > > Packet traces from 1998 and 1999 are prehaps not so relevante today, > particularly wrt error rates due to hosts, router memories, and link > error rates. Look at the cited caused of errors and realize that many > things have changed. > > The largest single error in the paper (paerhaps as high as 99.9% of > the errors) was the ACK-of-FIN bug in Windows NT. They may have fixed > that by now. Other large causes were host hardware and host software > bugs (sent bad data in the first place). > > One fifth of campus errors were caused by two hosts. This is cited as > a bug in Mac OS on Powermac 8100, fixed at the time of publication. > > A lot of host software errors are discussed, where the checksums are > sent bad and therefore will pass any router link FCS. > > Sending host hardware errors were thought to be in large part caused > by no data integrity check on host DMA transfers. I think progress > has been made on that front. You can check PCIe. It has a 32bit CRC > per lane in the link layer and retransmits on error. > > Router memory errors was thought to play a large role in the non-host > part of the error rate in the paper. Routers use ECC now. Going that > far back they didn't always have parity RAM (and sometimes ran parity > disabled to avoid parity error reloads). > > VJHC software errors? Anyone still use VJHC? Those errors should be > gone. > > IP over HDLC over T1 missed a few errors at the link layer in those > days. That could be true and occurances dependent on the providers. > In the paper that was thought to be a very small contributor. > > Both HDLC and PPP had an option for 16 bit or 32 bit FCS. Often 16 > bit was used. Some HDLC equipment could be and was configured to > count errors and send the packets on their way on the assumption that > it was better to count errors and deliver bad packets rather than > deliver no packet. Perhaps also to hide packet loss. Today all of > the link layers in use have 32 bit FCS and count and toss errored > packets. In most equipment all of the memories have ECC and all of > the buses ECC or FCS if serialized. > > It is now 14 years since that paper was published in Signcomm and 16 > years since some of the observations. Things have changed. Nice bit > of nostangia but that paper may no longer be relevant. > > Curtis > > reference - > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf > > In message <290E20B455C66743BE178C5C84F1240847E63346BD@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: >> Curtis >> >> I suggest reading Stone's work, particularly >> ''When The CRC and TCP Checksum Disagree' >> for discussion of corruption. >> >> Particularly its conclusions: 'In the internet, that means >> we are sending large volumes of incorrect data without >> anyone noticing'. >> >> The Layer-2 check is per link, not end-to-end. That matters. >> >> The MPLS assumption is that it crosses a link with a frame >> checksum. Putting MPLS over UDP breaks that assumption. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Curtis Villamizar [curtis@ipv6.occnc.com] >> Sent: 12 January 2014 18:09 >> To: Wood L Dr (Electronic Eng) >> Cc: adrian@olddog.co.uk; randy@psg.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; david.black@emc.com; jnc@mit.edu; tsvwg@ietf.org >> Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) >> >> In message <290E20B455C66743BE178C5C84F1240847E63346BA@EXMB01CMS.surrey.ac.uk> >> l.wood@surrey.ac.uk writes: >> >>> On nested checksums, the question is how they are nested; it's a matter >>> of scope. With a bunch of checksums checking only a payload and any >>> inner checksums like Russian Matryoshka dolls, the end-to-end argument >>> tells us that for reliable receipt of the payload, only the innermost checksum >>> matters. >>> >>> But here, we are not solely checking the payload, but information on how to >>> deliver and identify that payload - and while an outer Ethernet CRC is across >>> the last link, the UDP checksum, though weak, provides a check on the IP >>> addresses and UDP ports (via the pseudoheader check) and MPLS stack >>> from UDP/IP source to UDP/IP destination (and the payload, which is the bit >>> everyone focuses on as the performance hit as redundant and a processing >>> cost when the payload has its own check, and the bit that UDP-Lite can leave out). >>> >>> Nothing else checks that scope. The scope is wider, and affects the network >>> as a whole. Errors in these unchecked fields lead to misdirection and lead to >>> misdelivery. Or pollution of other ports. >>> >>> The MPLS assumption is that it's protected and checked by a strong link CRC like >>> Ethernet, and checked/regenerated by stack processing between hops; here, >>> in a path context, with zero UDP checksums MPLS has no checking at all. >> >> That UDP would be running over IP over Ethernet or POS or GFP or ... >> >> There is no layer-2 currently in use that does not have a robust FCS, >> generally a 32 FCS and therefore the MPLS assumption of checking at a >> lower layer is still valid. >> >> Curtis >> >> >>> "consequences for cheap hardware and for software implementations" >>> >>> I'm sorry, when was MPLS cheap? >>> >>> Lloyd Wood >>> http://about.me/lloydwood >>> ________________________________________ >>> From: Adrian Farrel [adrian@olddog.co.uk] >>> Sent: 09 January 2014 10:21 >>> To: Wood L Dr (Electronic Eng); randy@psg.com >>> Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org >>> Subject: RE: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) >>> >>> Lloyd and Randy, >>> >>> With respect to draft-ietf-mpls-in-udp, this is why we have IETF last calls, so >>> thanks for the comments. >>> >>> We did take the precaution of sending this I-D for an early TSV Directorate >>> review because of the concern about a number of factors and the overlap with >>> tsvwg work, but the review came back "clean". Of course, such a review is just >>> one person, so this conversation is good. >>> >>> Wrt zero checksum, where do you stand on nested checksums? There is some claim >>> that they represent a waste of processing. I am not convinced by that when each >>> layer is using dedicated hardware (that can presumably process checksums at line >>> speed), but I am interested in the consequences for cheap hardware and for >>> software implementations (as have been claimed to be some of the motivations for >>> this work). >>> >>> Other TSV-related issues that surely pop up are: >>> - allocation of ports for foo-in-UDP >>> - congestion control >>> >>> Please note that there are a number of I-Ds that you missed in your broad sweep >>> of "I am opposed". You should probably look at the NVGRE and VXLAN work (which I >>> think is lurking around the NVO3 working group) because that is also looking at >>> UDP encaps of a tunnelling protocol. >>> >>> Thanks, >>> Adrian >>> >>> Health warnings: >>> I am responsible AD for draft-ietf-mpls-in-udp >>> I am a co-author of the gre-in-udp draft. >>> >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk >>>> Sent: 09 January 2014 08:07 >>>> To: randy@psg.com >>>> Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; david.black@emc.com; >>>> tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org >>>> Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: >>>> [tsvwg] Milestones changed for tsvwg WG) >>>> >>>> Randy, >>>> >>>> okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get >>>> consensus on it. And then the authors can adopt that consensus for >>> mpls-in-udp, >>>> which overlaps in authorship... >>>> >>>> thanks, >>>> >>>> Lloyd Wood >>>> http://about.me/lloydwood >>>> ________________________________________ >>>> From: Randy Bush [randy@psg.com] >>>> Sent: 09 January 2014 07:51 >>>> To: Wood L Dr (Electronic Eng) >>>> Cc: david.black@emc.com; gorry@erg.abdn.ac.uk; ietf@ietf.org; mpls@ietf.org; >>>> jnc@mit.edu; lisp@ietf.org; tsvwg@ietf.org >>>> Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] >>>> Milestones changed for tsvwg WG) >>>> >>>>> Because they specify zero UDP checksums, >>>>> I oppose publication of draft-ietf-mpls-in-udp in its current form >>>>> I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its current >>>> form. >>>>> I oppose the IETF lisp documents. >>>> lloyd, >>>> >>>> i think i understand your position. but i disagree with preventing wg >>>> adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly >>>> see wg adoption as how we get to discuss and work on a document, not as >>>> approval of the document. as david said, i think we need to discuss it >>>> so we can decide if it should be fixed. to do so, we have to adopt it. >>>> >>>> randy > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From curtis@ipv6.occnc.com Tue Jan 14 19:44:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60CC1AE1EF; Tue, 14 Jan 2014 19:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 K2fVlAnyRXIR; Tue, 14 Jan 2014 19:44:09 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 952DB1AE1E2; Tue, 14 Jan 2014 19:44:09 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F3hqwR007521; Tue, 14 Jan 2014 22:43:52 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401150343.s0F3hqwR007521@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Tue, 14 Jan 2014 23:05:14 +0000." <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> Date: Tue, 14 Jan 2014 22:43:52 -0500 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 03:44:12 -0000 Lloyd, The part about RFC 6936 section 3.1 most relevant might be: There is extensive experience with deployments using tunnel protocols in well-managed networks (e.g., corporate networks and service provider core networks). This has shown the robustness of methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS that do not employ a transport protocol checksum and that have not specified mechanisms to protect from corruption of the unprotected headers (such as the VPN Identifier in MPLS). Reasons for the robustness may include: If the rate of undetected modified packets is extremely low in "well-managed networks", as we beleive is the case, then UDP checksums won't change the situration much. So why *not* make them optional if experience has shown they are not needed in the types of deployments we are talking about. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > Stewart, > > your 'I'm not in tunnel applications' suggests you've misunderstood > the argument here. The point is not to protect the tunnel traffic > (which can quite happily checksum itself), it is to protect everything > else on the network from misdelivery. It's not the tunnel application, > it's every application sharing the internet with the tunnel which > has UDP checksums turned off. See all of RFC 6936 section 3.1. > Tunnel is fine, sideeffects of misdelivery do not affect tunnel. > > And in IPv4 and IPv6, the pseudo-header checksum built into > TCP and UDP is all we have. IPv6 deliberately copied v4 here. > > > What is the error rate in modern h/w and network systems? > > No-one measures end-to-end misdelivery. No-one knows. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: 14 January 2014 22:46 > To: Wesley Eddy; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > > On 14/01/2014 22:07, Wesley Eddy wrote: > > On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: > >> I don't think sayng 'oh, that error source is no longer a problem' disproves > >> Stone's overall point about undetected errors, though the > >> examples he uses from the technology of the day are necessarily > >> dated. Dismissing the overall point because the examples use obsolete > >> technology is throwing the baby out with the bathwater; a host-to-host > >> error check catches things that intermediate checks cannot. > >> > >> Measuring error rates across end-to-end Internet traffic is something that has > >> not received much attention , as error detection is not > >> instrumented well - hence citing Stone's published work, in the absence > >> of awareness of anything newer (and as high profile/immediately recognisable > >> as sigcomm) in the area. > >> > > > > +1 ... the message in the paper is applicable to layered systems > > and internetworks in general. Changes in the link technology > > since then don't invalidate it, especially since we know that > > the technology not only changes rapidly, but also is always > > growing in diverse directions, such that there things almost > > universally true today may be turned on their heads tomorrow. > > > > Designs for stacking layers need to follow solid general > > principles in order to be robust to changes (above and below). > > > Note that it is not only the link layer technology that has moved on, > the signal integrity of the h/w at all stages of the design and > implementation process has moved on. > > Can we agree that the statistics in the paper are discredited? > > If not, why not? > > What is the error rate in modern h/w and network systems? > > Is this significant in the application under consideration? > > Finally if we are really concerned that we do actually need a > c/s (I am not in tunnel applications) why are we still happy to > use what is frankly a pathetic check in modern terms? Why > for example are we not moving to something like > the Fletcher 64 bit c/s? > > Stewart From l.wood@surrey.ac.uk Tue Jan 14 21:21:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267DF1AE2BE for ; Tue, 14 Jan 2014 21:21: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc-WYAFD76sF for ; Tue, 14 Jan 2014 21:21:44 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) by ietfa.amsl.com (Postfix) with ESMTP id 935631AE2E8 for ; Tue, 14 Jan 2014 21:21:42 -0800 (PST) Received: from [195.245.231.67:43619] by server-6.bemta-5.messagelabs.com id E9/73-16310-8DA16D25; Wed, 15 Jan 2014 05:21:28 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-6.tower-82.messagelabs.com!1389763287!33356230!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19034 invoked from network); 15 Jan 2014 05:21:27 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-6.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 15 Jan 2014 05:21:27 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 15 Jan 2014 05:21:27 +0000 From: To: Date: Wed, 15 Jan 2014 05:20:27 +0000 Thread-Topic: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) Thread-Index: Ac8RpAQNDX8cAMV9TnqV5Ulgc44euAADXwfJ Message-ID: <290E20B455C66743BE178C5C84F1240847E63346C7@EXMB01CMS.surrey.ac.uk> References: Your message of "Tue, 14 Jan 2014 23:05:14 +0000." <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk>, <201401150343.s0F3hqwR007521@maildrop2.v6ds.occnc.com> In-Reply-To: <201401150343.s0F3hqwR007521@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 05:21:47 -0000 That's robustness _for the tunnelled traffic_. Not for anything else sharing the network - that hasn't been instrumented a= nd measured. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 15 January 2014 03:43 To: Wood L Dr (Electronic Eng) Cc: stbryant@cisco.com; wes@mti-systems.com; curtis@ipv6.occnc.com; gorry@e= rg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvwg@ietf.org;= jnc@mit.edu; lisp@ietf.org Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-= in-udp draft (was: RE: Milestones changed for tsvwg WG)) Lloyd, The part about RFC 6936 section 3.1 most relevant might be: There is extensive experience with deployments using tunnel protocols in well-managed networks (e.g., corporate networks and service provider core networks). This has shown the robustness of methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS that do not employ a transport protocol checksum and that have not specified mechanisms to protect from corruption of the unprotected headers (such as the VPN Identifier in MPLS). Reasons for the robustness may include: If the rate of undetected modified packets is extremely low in "well-managed networks", as we beleive is the case, then UDP checksums won't change the situration much. So why *not* make them optional if experience has shown they are not needed in the types of deployments we are talking about. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > > Stewart, > > your 'I'm not in tunnel applications' suggests you've misunderstood > the argument here. The point is not to protect the tunnel traffic > (which can quite happily checksum itself), it is to protect everything > else on the network from misdelivery. It's not the tunnel application, > it's every application sharing the internet with the tunnel which > has UDP checksums turned off. See all of RFC 6936 section 3.1. > Tunnel is fine, sideeffects of misdelivery do not affect tunnel. > > And in IPv4 and IPv6, the pseudo-header checksum built into > TCP and UDP is all we have. IPv6 deliberately copied v4 here. > > > What is the error rate in modern h/w and network systems? > > No-one measures end-to-end misdelivery. No-one knows. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: 14 January 2014 22:46 > To: Wesley Eddy; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; ts= vwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gr= e-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > > On 14/01/2014 22:07, Wesley Eddy wrote: > > On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: > >> I don't think sayng 'oh, that error source is no longer a problem' dis= proves > >> Stone's overall point about undetected errors, though the > >> examples he uses from the technology of the day are necessarily > >> dated. Dismissing the overall point because the examples use obsolete > >> technology is throwing the baby out with the bathwater; a host-to-host > >> error check catches things that intermediate checks cannot. > >> > >> Measuring error rates across end-to-end Internet traffic is something= that has > >> not received much attention , as error detection is not > >> instrumented well - hence citing Stone's published work, in the absen= ce > >> of awareness of anything newer (and as high profile/immediately recogn= isable > >> as sigcomm) in the area. > >> > > > > +1 ... the message in the paper is applicable to layered systems > > and internetworks in general. Changes in the link technology > > since then don't invalidate it, especially since we know that > > the technology not only changes rapidly, but also is always > > growing in diverse directions, such that there things almost > > universally true today may be turned on their heads tomorrow. > > > > Designs for stacking layers need to follow solid general > > principles in order to be robust to changes (above and below). > > > Note that it is not only the link layer technology that has moved on, > the signal integrity of the h/w at all stages of the design and > implementation process has moved on. > > Can we agree that the statistics in the paper are discredited? > > If not, why not? > > What is the error rate in modern h/w and network systems? > > Is this significant in the application under consideration? > > Finally if we are really concerned that we do actually need a > c/s (I am not in tunnel applications) why are we still happy to > use what is frankly a pathetic check in modern terms? Why > for example are we not moving to something like > the Fletcher 64 bit c/s? > > Stewart From l.wood@surrey.ac.uk Tue Jan 14 21:40:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE131ADEA6; Tue, 14 Jan 2014 21:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, 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 L3iad7TG8zw5; Tue, 14 Jan 2014 21:40:22 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5BE1ADEA0; Tue, 14 Jan 2014 21:40:20 -0800 (PST) Received: from [195.245.230.131:15100] by server-5.bemta-3.messagelabs.com id 46/4F-25188-83F16D25; Wed, 15 Jan 2014 05:40:08 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-11.tower-78.messagelabs.com!1389764407!32710652!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8400 invoked from network); 15 Jan 2014 05:40:07 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-11.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 15 Jan 2014 05:40:07 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Wed, 15 Jan 2014 05:40:00 +0000 From: To: Date: Wed, 15 Jan 2014 05:39:59 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8RkxlnzH0wNAEATBaHj60siCfQ0gAHrv95 Message-ID: <290E20B455C66743BE178C5C84F1240847E63346C9@EXMB01CMS.surrey.ac.uk> References: Your message of "Tue, 14 Jan 2014 21:44:29 +0000." <290E20B455C66743BE178C5C84F1240847E63346C4@EXMB01CMS.surrey.ac.uk>, <201401150142.s0F1gVJP006084@maildrop2.v6ds.occnc.com> In-Reply-To: <201401150142.s0F1gVJP006084@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, lars@netapp.com, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 05:40:25 -0000 Curtis http://lmgtfy.com/?q=3DJonathan+Stone+CRC+checksum HDLC is just whatever is over the last hop. You said HDLC, I reused that as an example. Any link technology could be substituted - 10Mbps Ethernet, say, though you'd criticise that as not being 10Gbps Ethernet and therefore out of date= . Again, the point is that the link check is not end-to-end, and that errors can creep in from the most unexpected places. By analogy with security, if I have security across each hop, why would I need security end-to-end? I already have it across each hop! Each link is highly and absolutely unrbreakably secure! What is this end-to-end of which you speak? If you don't get that point because it's a bit abstract and timeless, that'= s fine. (and if you have to explain the joke, the joke wasn't funny.) The link CRC doesn't apply across the entire path; do the maths for the path and a series of concatenated links. [As it happens, I'm familiar with UDP/IP/HDLC internet infrastructure insta= lled within the decade and in daily operational use to deliver imagery from orb= it. But the paper I wrote on that dates from 2007, so is old and won't be of interest to you.] Wait, this thread is all about putting 90s MPLS technology over UDP technology specified in 1980. Clearly, if MPLS has to rely on an older technology in this way, the MPLS crowd should give up and go home.=20 We've learned repeatedly that zero checksums are a bad idea. IPv6 RFC2460: Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it must be changed to hex FFFF for placement in the UDP header. IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error. which RFC6935 simply rewote as inconvenient to tunnelers without considering how it affected everything else in the network. Those that do not learn from history are doomed to repeat it. (Unless it's recent history, in which case they're doomed to reject it as irrelevant.) Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 15 January 2014 01:42 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com; jmh@joelhalpern.com; lars@netapp.com; xuxiaohu@h= uawei.com; mpls@ietf.org; ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard In message <290E20B455C66743BE178C5C84F1240847E63346C4@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > The HDLC part here is last link, not the scope of the whole path. Any > 'low' bit error rate given actually becomes quite high once you > consider no of bits per packet and line rate... > > Do read Jonathan Stone's papers on where errors creep in - not just in > the link, by at any point along the path, including regeneration > > Lloyd Wood Lloyd, There is no HDLC hop. No one has used HDLC for internet infrastructure in ages. It was a joke, like Scott's comment on wanting to use X.25. HDLC was disappearing when the Stone/Partridge Sigcomm 2000 paper was written. Links please. And how old is that paper? Not another 15 year old work is it? If you have one bit error per day, how many packets do you lose that day? (hint: one). If you have one bit error per day, how many undetactable packet errors do you have? (hint: crc32 gets all one bit errors, therefore zero). 10^-12 bit errors is one per 10 second on 100 Gb/s, one per 100 second on 10 Gb/s and is generally considered high enough to take a link down immediately. A 1500 byte packet is 12,000 bits, about ~10^4. That would yield a packet rate as high as 10^-8 if bit errors were mostly one bit error per packet. In that case all errors would be detectable. It is only when there are a lot of bit errors or more per packet that the CRC can be defeated and then its about 10^-9 chance. So at an error rate much less than 10^-8 packets (tightly bunched errors with multiple bit errors per packet) some 10^-9 might be undetectable with a CRC32. One packet every 10^6 seconds at 100 Gb/s could have an undetectable error. About one undetectable error a day or one a week for continuous full out 100 Gb/s link. Note that the same low error rate does not apply to a GbE or 10GbE over colored optics over ROADM in the metro since there is no FEC there. It also may not apply to the enterprise or campus Ethernets. In those hops the error rate is likely to be higher. Needless to say, wireless hops can have very high error rates. This is why it could make sense to have the UDP checksum optional in MPLS over UDP. It wouldn't hurt to provide the checksums but in some cases it might be OK to disable them. That is what SHOULD is for in an IETF document. Curtis > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 14 January 2014 20:54 > To: Wood L Dr (Electronic Eng) > Cc: jmh@joelhalpern.com; lars@netapp.com; xuxiaohu@huawei.com; mpls@ietf.= org; ietf@ietf.org > Subject: Re: [mpls] Last Call: (Encapsula= ting MPLS in UDP) to Proposed Standard > > In message <290E20B455C66743BE178C5C84F1240847E63346C3@EXMB01CMS.surrey.a= c.uk> > l.wood@surrey.ac.uk writes: > > > It stands to reason that if tunnelers can turn off udp checksums > > because their performance is degraded, they can turn off > > congestion control because it will degrade their performance. > > > > Rest of the internet getting congested and getting > > misdelivered corrupted packets? Really not their problem. > > > > There are important vendors trying to sell products here, > > and they need performance to do so. > > Get with the program! > > > > Lloyd Wood > > http://about.me/lloydwood > > > OK, perhaps if you are running MPLS/UDP/IP over HDLC and the HDLC > configuration is set to count FCS errors but not drop you will still > *really* need the UDP checksum. Otherwise its isn't going to do much > for you. Any checksum is really bad for some types of errors such as > chunk reordering and multiple bit errors. > > Maybe on HDLC or PPP with 16 bit CRC you may see a low error rate, but > in theory that would be much less than 10^-5 since few multiple bit > errors will be coincidence match the CRC, even for a 16 bit CRC. > > I suspect most routers would be able to do the checksum anyway and for > modern links if they come up with a zero error count that's fine. > > > > Modern OTN based transport networks use forward error correction FEC > which accounts for a fair amount of overhead and a lot of processing > gates on the receiving end. The measure of effectiveness of given FEC > is in dB with 10 dB being a reduction of a factor of 10 in bit errors > and typical FEC in the high tens of dB. The target corrected error > rate is often 10^-15 or one bit error in 24 hours for 10 Gb/s, one bit > error in 2.5 hours for 100 Gb/s. Any link with corrected bit error > rates approaching 10^-12 is taken out of service. This is roughly > equivalent to the old ES (errored seconds) and SES (severely errored > seconds) metric where a ES is one second with any bit errors and an > SES is one second with 10 or more errors (I think its 10). More than > some number of ES or SES and a link is taken down. The uncorrected > errors are passed through. > > A packet may traverse an entire continent with 2-3 such links > separated by regeneration or could stop at a number of routers along > the way. Typically today the router uses 10GbE or 100GbE (growing > use) which are then passed as a bit stream in the transport network. > At the other end the uncorrected errors from transport are picked up > by Ethernet 32 bit FCS. Since a 32 bit FCS picks up 100% of single > bit errors and most instances where a small number of bits are in > error, and all but 1 in 2^32 where many bits are in error, few errors > are going to get through. If GFP is used, the per packet FCS is > checked at each hop and for GFP-T also checked end to end. > > A bad local ethernet is more likely to contribute an error (again > better than 1 in 2^32 detection is expected) due to something like a > bad CAT-{5,5e,6} connection or too many sharp turns. A DSL or DOCSIS > link is also more likely to contribute an error. With CRC32 on all > links and no bad hardware in between (ie: circa 1990s equipment with > no parity RAM and no correction on DMA, buses, etc) you would expect > on the order of 10^-8 errors (10^-9 per hop, a few errored hops). > > For example, two hosts on my home LAN had non-zero tcp checksums. > Each had < 10^-6 packet error rate. It is hard to tell if this is > host errors at the other end. The only hosts I have with non-zero are > on the service provider DMZ LAN so that would include any bot attacks, > etc, where sending hosts could be old junk. Host behind those have > zero UDP and TCP checksum errors. This seems similar to Stewart's > quick check. > > In the T1/T3 days the transport layer just had parity and just counted > parity errors. Providers in those days were notorious for ignoring ES > and SES counters until the customer complained. HDLC then had its 16 > bit CRC, optional 32 bit. If an ISP wasn't paying attention to their > HDLC error counters then it was up to the IP end customer to complain > and hope the problem got escallated rather than dropped. > > > > As to whether congestion control is in practice needed see > http://www.ietf.org/mail-archive/web/mpls/current/msg11222.html > > Its fine to make them both optional and to make congestion control > mechanisms out of scope and the topic of a later document if needed. > > Curtis > > > > > ________________________________________ > > From: ietf [ietf-bounces@ietf.org] On Behalf Of Joel M. Halpern [jmh@jo= elhalpern.com] > > Sent: 10 January 2014 15:36 > > To: Eggert, Lars; Xuxiaohu > > Cc: mpls@ietf.org; IETF > > Subject: Re: Last Call: (Encapsulating = MPLS in UDP) to Proposed Standard > > > > Maybe I am completely missing things, but this looks wrong. > > If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion > > control will make it more likely that the service won't work. Is that > > really the goal? > > > > We do not perform congestion control on MPLS LSPs. > > Assuming that a UDP tunnel is carrying just MPLS and was established > > just for MPLS, why would we expect it to behave differently than an MPL= S > > LSP running over the exact same path, carrying the exact same traffic? > > > > Yours, > > Joel > > > > On 1/10/14 3:47 AM, Eggert, Lars wrote: > > > Hi, > > > > > > that sounds good. What congestion control are you going to be specify= ing for your tunnel? > > > > > > Lars > > > > > > On 2014-1-10, at 4:46, Xuxiaohu wrote: > > > > > >> Hi Lars, > > >> > > >> Thanks a lot for your comments. > > >> > > >> I wonder whether the following modified text for Congestion Consider= ation section is OK from your point of view: > > >> > > >> Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwar= ded through "UDP tunnels", the congestion control guidelines for UDP tunnel= s as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically= , MPLS can carry a number of different protocols as payloads. When the payl= oad traffic is IP-based and congestion-controlled, the UDP tunnel SHOULD NO= T employ its own congestion control mechanism, because congestion losses of= tunneled traffic will already trigger an appropriate congestion response a= t the original senders of the tunneled traffic. When the payload traffic is= not known to be IP-based, or is known to be IP-based but not congestion-co= ntrolled, the UDP tunnel SHOULD employ an appropriate congestion control me= chanism. Furthermore, because UDP tunnels are usually bulk-transfer applica= tions as far as the intermediate routers are concerned, the guidelines as d= efined in Section 3.1.1 of [RFC5405] SHOULD apply. > > >> > > >> Best regards, > > >> Xiaohu > > >> > > >>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > >>> =B7=A2=BC=FE=C8=CB: mpls [mailto:mpls-bounces@ietf.org] =B4=FA=B1= =ED Eggert, Lars > > >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C28=C8=D5 18:22 > > >>> =CA=D5=BC=FE=C8=CB: IETF > > >>> =B3=AD=CB=CD: mpls@ietf.org > > >>> =D6=F7=CC=E2: Re: [mpls] Last Call: = (Encapsulating MPLS > > >>> in UDP) to Proposed Standard > > >>> > > >>> Hi, > > >>> > > >>> On 2014-1-2, at 16:14, The IESG wrote: > > >>>> - 'Encapsulating MPLS in UDP' > > >>>> as Proposed Standard > > >>> > > >>> > > >>> this document needs to describe how it addresses the issues raised = in BCP145 > > >>> (RFC5405). It already contains some text about messages sizes and c= ongestion > > >>> considerations, which is great. Unfortunately, the text about conge= stion > > >>> considerations is not fully in line with RFC5405. > > >>> > > >>> Lars > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From l.wood@surrey.ac.uk Tue Jan 14 21:46:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39191AE2D5; Tue, 14 Jan 2014 21:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 tzo_5OTM5n58; Tue, 14 Jan 2014 21:46:41 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2645A1AE1BF; Tue, 14 Jan 2014 21:46:41 -0800 (PST) Received: from [85.158.136.51:38639] by server-13.bemta-5.messagelabs.com id 56/97-11357-5B026D25; Wed, 15 Jan 2014 05:46:29 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-16.tower-49.messagelabs.com!1389764788!23096706!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14276 invoked from network); 15 Jan 2014 05:46:28 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-16.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 15 Jan 2014 05:46:28 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 15 Jan 2014 05:46:27 +0000 From: To: , Date: Wed, 15 Jan 2014 05:45:43 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8RjS132P0/ZYvoS3qqFjAC/swR5wAJ9pSN Message-ID: <290E20B455C66743BE178C5C84F1240847E63346CA@EXMB01CMS.surrey.ac.uk> References: Your message of "Tue, 14 Jan 2014 15:29:38 +0000." <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com>, <201401150100.s0F10C7J005674@maildrop2.v6ds.occnc.com> In-Reply-To: <201401150100.s0F10C7J005674@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, scott.brim@gmail.com, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 05:46:43 -0000 this draft should be about mpls in TCP - a TCP tunnel. That will fix all congestion concerns. I look forward to reading justification of why TCP checksums can be turned = off. Lloyd Wood http://about.me/lloydwood ________________________________________ From: mpls [mpls-bounces@ietf.org] On Behalf Of Curtis Villamizar [curtis@i= pv6.occnc.com] Sent: 15 January 2014 01:00 To: Eggert, Lars Cc: mpls@ietf.org; Scott Brim; IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulat= ing MPLS in UDP) to Proposed Standard In message <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> "Eggert, Lars" writes: > Hi, > > On 2014-1-14, at 16:23, Joel M. Halpern wrote: > > Isn't that basically the problem of the inner traffic sender, not the > > problem of the tunnel that is carrying the traffic? > > no, because the sender of the inner traffic may be blasting some > L2traffic, for an L2 where that is OK behavior. But that traffic is > nowbeing encapsulated inside UDP and can hence go anywhere on the > net*without the sender being aware of this*. That application would be a PW application and it would be more appropriate to fix that in PW if there is consensus for a need to do so, which afaik there is not. > > Asking tunnel's to solve the problem of applications with > > undesirablebehavior seems backwards. > > It is the *tunnel* that performs the encapsulation and allows > thattraffic to go places it couldn't before. And so it's the > tunnel'sresponsibility to make sure that the traffic it injects into > theInternet complies with the BCPs we have on congestion control. > > Lars If it is a service provider encapsulating traffic within their own network, then they know what they are doing. That is the anticipated use and among that community there is no consensus for need for congestion control. If it is some hostile hosts trying to send MPLS over UDP over IP, they, being hostile, are going to disable any congestion control. Besides, no hostile host has a T1 to tunnel over the Internet so they would be sending the same traffic they would normally just send of UDP over IP. Anything made up of frames (Ethernet, ATM, FR) over PW over MPLS is carrying IP and if frames drop, the IP applications see the drop and behave just as they would for any drop. (ATM shreadding thread to /dev/null please). If congestion aware or using a congestion aware transport, the top level applications are still congestion aware. If congestion ignoreant, they are still congestion ignoreant. If hostile, they are still hostile. Back to draft-ietf-mpls-in-udp. I think the most recent text proposed by the author is fine. Curtis _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Wed Jan 15 03:02:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503701AE343; Wed, 15 Jan 2014 03:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 ht8tehBTC2RA; Wed, 15 Jan 2014 03:02:38 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id BEF471AE061; Wed, 15 Jan 2014 03:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12079; q=dns/txt; s=iport; t=1389783746; x=1390993346; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=ajcuDD8h7TBbs+OZZLo3Di3WoXtXcZR7hQVGnmaIaS4=; b=DyKNNHxL4EpK3YHIeZSImEcUoJB5eij8kG32fxysWZCWS/B1HzWJcSub FCqcrc8vQHBRfyymx57rKot3NN9faDuyMtynQ5EOf8OdQhoDwPhHJIk04 bt4To4k1KYX8TWBzncoBXo8NwzKzF4SjdE+L0npDCx2YAwhSmF1lYOg5s k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAO9p1lKQ/khM/2dsb2JhbABaDoI5RDhQuwKBFhZ0giUBAQEDAXQFBQsLEQQBAQEJGgsPAj4IBwwBBQIBAYd4CAgFxAAXjmUiBwaEMQSUOINmgTCLLYU4gW9/Pw X-IronPort-AV: E=Sophos;i="4.95,662,1384300800"; d="scan'208,217";a="3655006" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 15 Jan 2014 11:02:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0FB2Ns5010692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jan 2014 11:02:23 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0FB2K4m022493; Wed, 15 Jan 2014 11:02:21 GMT Message-ID: <52D66ABC.40606@cisco.com> Date: Wed, 15 Jan 2014 11:02:20 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, wes@mti-systems.com, curtis@ipv6.occnc.com References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com>, <52D58168.9060800@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346C5@EXMB01CMS.surrey.ac.uk> <52D5B524.5080408@mti-systems.com>, <52D5BE37.4070301@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> Content-Type: multipart/alternative; boundary="------------090007090508030409010602" Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 11:02:40 -0000 This is a multi-part message in MIME format. --------------090007090508030409010602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sent from my iPad > On 14 Jan 2014, at 23:05,"l.wood@surrey.ac.uk" wrote: > > Stewart, > > your 'I'm not in tunnel applications' suggests you've misunderstood > the argument here. The point is not to protect the tunnel traffic > (which can quite happily checksum itself), it is to protect everything > else on the network from misdelivery. It's not the tunnel application, > it's every application sharing the internet with the tunnel which > has UDP checksums turned off. See all of RFC 6936 section 3.1. > Tunnel is fine, sideeffects of misdelivery do not affect tunnel. > > And in IPv4 and IPv6, the pseudo-header checksum built into > TCP and UDP is all we have. IPv6 deliberately copied v4 here. Lloyd, With the significant improvements in h/w design methodology and the addressing of the s/w bugs that Curtis and I have been explaining to you, it would seem that the fundamental paper that underpins your argument is without credibility, and by your own admission below, it seems that there are no valid statistics for the current Internet to sustain your case. Unless you can show that the misdelivery rate from this effect exceeds the current rather high unwanted packet rate that hosts need to fend off, I cannot see any basis to maintain your assertion that the c/s is required in tunnel applications to protect the rest of the net. With regard to the IPv4, the IP checksum, which, in all router implementations I have seen, is checked at every hop and only incrementally changed, there is surely adequate protection against misdelivery to another endpoint. With regard to IPv6, I find it difficult to understand that the threat is of any significance given that absence of demand for the retrofit of a similar checksum in MPLS to protect PEs and prevent the incorrect egress of traffic. >> What is the error rate in modern h/w and network systems? > No-one measures end-to-end misdelivery. No-one knows. The upper bound is the packet loss rate less the congestion discard rate. Do we have a figure for that? Stewart > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: 14 January 2014 22:46 > To: Wesley Eddy; Wood L Dr (Electronic Eng);curtis@ipv6.occnc.com > Cc:gorry@erg.abdn.ac.uk;mpls@ietf.org;ietf@ietf.org;randy@psg.com;tsvwg@ietf.org;jnc@mit.edu;lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > >> On 14/01/2014 22:07, Wesley Eddy wrote: >>> On 1/14/2014 4:57 PM,l.wood@surrey.ac.uk wrote: >>> I don't think sayng 'oh, that error source is no longer a problem' disproves >>> Stone's overall point about undetected errors, though the >>> examples he uses from the technology of the day are necessarily >>> dated. Dismissing the overall point because the examples use obsolete >>> technology is throwing the baby out with the bathwater; a host-to-host >>> error check catches things that intermediate checks cannot. >>> >>> Measuring error rates across end-to-end Internet traffic is something that has >>> not received much attention , as error detection is not >>> instrumented well - hence citing Stone's published work, in the absence >>> of awareness of anything newer (and as high profile/immediately recognisable >>> as sigcomm) in the area. >> +1 ... the message in the paper is applicable to layered systems >> and internetworks in general. Changes in the link technology >> since then don't invalidate it, especially since we know that >> the technology not only changes rapidly, but also is always >> growing in diverse directions, such that there things almost >> universally true today may be turned on their heads tomorrow. >> >> Designs for stacking layers need to follow solid general >> principles in order to be robust to changes (above and below). > Note that it is not only the link layer technology that has moved on, > the signal integrity of the h/w at all stages of the design and > implementation process has moved on. > > Can we agree that the statistics in the paper are discredited? > > If not, why not? > > What is the error rate in modern h/w and network systems? > > Is this significant in the application under consideration? > > Finally if we are really concerned that we do actually need a > c/s (I am not in tunnel applications) why are we still happy to > use what is frankly a pathetic check in modern terms? Why > for example are we not moving to something like > the Fletcher 64 bit c/s? > > Stewart . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------090007090508030409010602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Sent from my iPad


On 14 Jan 2014, at 23:05, "l.wood@surrey.ac.uk" <l.wood@surrey.ac.uk> wrote:

Stewart,

your 'I'm not in tunnel applications' suggests you've misunderstood
the argument here. The point is not to protect the tunnel traffic
(which can quite happily checksum itself), it is to protect everything
else on the network from misdelivery. It's not the tunnel application,
it's every application sharing the internet with the tunnel which
has UDP checksums turned off. See all of  RFC 6936 section 3.1.
Tunnel is fine, sideeffects of misdelivery  do not affect tunnel.

And in IPv4 and IPv6, the pseudo-header checksum built into
TCP and UDP is all we have. IPv6 deliberately copied v4 here.

Lloyd,

With the significant improvements in h/w design methodology
and the addressing of the s/w bugs that Curtis and I have been
explaining to you, it would seem that the fundamental
paper that underpins your argument is without credibility, and
by your own admission below, it seems that there are no 
valid statistics for the current Internet to sustain your case.

Unless you can show that the misdelivery rate from this effect
exceeds the current rather high unwanted packet rate that
hosts need to fend off, I cannot see any basis to maintain 
your assertion that the c/s is required in tunnel applications 
to protect the rest of the net.

With regard to the IPv4, the IP checksum, which, in all router
implementations I have seen, is checked at every hop and
only incrementally changed, there is surely adequate 
protection against misdelivery to another endpoint.

With regard to IPv6, I find it difficult to understand that
the threat is of any significance given that absence of demand
for the retrofit of a similar checksum in MPLS to protect
PEs and prevent the incorrect egress of traffic.


What is the error rate in modern h/w and network systems?

No-one measures end-to-end misdelivery. No-one knows.

The upper bound is the packet loss rate less the congestion
discard rate. Do we have a figure for that?

Stewart


Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Stewart Bryant [stbryant@cisco.com]
Sent: 14 January 2014 22:46
To: Wesley Eddy; Wood L  Dr (Electronic Eng); curtis@ipv6.occnc.com
Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org
Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))


On 14/01/2014 22:07, Wesley Eddy wrote:

On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote:
I don't think sayng 'oh, that error source is no longer a problem' disproves
Stone's overall point about undetected errors, though the
examples he uses from the technology of the day are necessarily
dated. Dismissing the overall  point because the examples use obsolete
technology is throwing the baby out with the bathwater; a host-to-host
error check catches things that intermediate checks cannot.

Measuring error rates across end-to-end  Internet traffic is something that has
not received much attention , as error detection is not
instrumented well - hence citing Stone's published work,  in the absence
of awareness of anything newer (and as high profile/immediately recognisable
as sigcomm) in the area.

+1 ... the message in the paper is applicable to layered systems
and internetworks in general.  Changes in the link technology
since then don't invalidate it, especially since we know that
the technology not only changes rapidly, but also is always
growing in diverse directions, such that there things almost
universally true today may be turned on their heads tomorrow.

Designs for stacking layers need to follow solid general
principles in order to be robust to changes (above and below).

Note that it is not only the link layer technology that has moved on,
the signal integrity of the h/w at all stages of the design and
implementation process has moved on.

Can we agree that the statistics in the paper are discredited?

If not, why not?

What is the error rate in modern h/w and network systems?

Is this significant in the application under consideration?

Finally if we are really concerned that we do actually need a
c/s (I am not in tunnel applications) why are we still happy to
use what is frankly a pathetic check in modern terms? Why
for example are we not moving to something like
the  Fletcher 64 bit c/s?

Stewart

.




-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------090007090508030409010602-- From randy@psg.com Wed Jan 15 03:08:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF32C1AE34D; Wed, 15 Jan 2014 03:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 L-R--m2BjUPl; Wed, 15 Jan 2014 03:08:43 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5FD1AE078; Wed, 15 Jan 2014 03:08:43 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W3OKV-0005Bp-1G; Wed, 15 Jan 2014 11:08:16 +0000 Date: Wed, 15 Jan 2014 17:08:09 +0600 Message-ID: From: Randy Bush To: Stewart Bryant In-Reply-To: <52D66ABC.40606@cisco.com> References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_Jan_15_17:08:04_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 11:08:45 -0000 --pgp-sign-Multipart_Wed_Jan_15_17:08:04_2014-1 Content-Type: text/plain; charset=US-ASCII [ you insist on cc:ing me, so you get to endure my opinions ] > it seems that there are no valid statistics for the current Internet > to sustain your case. as we discussed privately, there seem to be no real measurements to sustain any case. this is all conjecturbation. what i do not understand is why, given the lack of solid evidence that we are in a safe space, you and others are not willing to spend a few euro cents to have a reasonable level of assurance at this layer. randy --pgp-sign-Multipart_Wed_Jan_15_17:08:04_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJS1mwYAAoJEMzMBey4OgLt1G8H/1ADrpB+HoSbUN8FTgBHlpk2 GeozioIalHzyBniV8tmqiBFYHwJZC35ylMPig8bCFuVXLpaiYPCUMcQQDb5w9Ck9 OKHupmxO5AiIbPR0PaTLCYzCHU/jNmhz+xMfAarlf8eJ3Nl0p9SdsNVn21GV7i1V z3+OhlPPDojCxjjQj/9dUW6Cc1PKufrM9ius+eXGUO7iaWd34V5de2laJrM39lr6 yRtmQX9zdZKzfMqNztwAFOl5oK0696k2JlVQi5i2NcSRb6P/GrFZ4aFOgy+18yQ4 LB8gDRgaQ4IhhyVfPrZOZoL3Feukxm7cgRTnEHqJKz+0jhVzEIvmKNfDMe1A+m4= =4bC4 -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Jan_15_17:08:04_2014-1-- From stbryant@cisco.com Wed Jan 15 03:31:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1E31AE35F; Wed, 15 Jan 2014 03:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 sUOUCgwX97T5; Wed, 15 Jan 2014 03:31:33 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4D41A1AE35E; Wed, 15 Jan 2014 03:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1164; q=dns/txt; s=iport; t=1389785481; x=1390995081; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=up0UvBh6yHD7U+HgE9fAGIoHx81lC42/wIrmS7ggc90=; b=bulh0VR/VA9c110y44jV9LGZvY7ZEJagtPMVi3LPwz7RekcalnbmeYVc p01qfycr18VloSHVRsIFpsFLqSF7l1UTHTXNSSAScADzqGJqXqOKFCWMa +jvFNgeUJV/ja3UkgcsN4wOaqkNLI9PFRcPsndwBEvPWRVY0swpz9U3Oo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAJNw1lKQ/khR/2dsb2JhbABagwu4fIMOgRcWdIIlAQEBBDgxAQ4BEAsYCRYECwkDAgECAUUGDQEHAQGIAMQRF48HB4Q3AQOYHpIVgW+BPg X-IronPort-AV: E=Sophos;i="4.95,662,1384300800"; d="scan'208";a="2986762" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 15 Jan 2014 11:31:20 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0FBVJnF019333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jan 2014 11:31:20 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0FBVIHK024290; Wed, 15 Jan 2014 11:31:18 GMT Message-ID: <52D67186.8080008@cisco.com> Date: Wed, 15 Jan 2014 11:31:18 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Randy Bush References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 11:31:34 -0000 On 15/01/2014 11:08, Randy Bush wrote: > [ you insist on cc:ing me, so you get to endure my opinions ] > >> it seems that there are no valid statistics for the current Internet >> to sustain your case. > as we discussed privately, there seem to be no real measurements to > sustain any case. this is all conjecturbation. > > what i do not understand is why, given the lack of solid evidence that > we are in a safe space, you and others are not willing to spend a few > euro cents to have a reasonable level of assurance at this layer. > > randy Randy, It is not a few cents, it is likely the re-engineering of a lot of silicon. The reason that UDP is of interest is that the on path silicon knows how to process it, for example it knows how to to ECMP it. The reason that the UDP c/s is a problem for a tunneler is that it needs to have access to the whole pkt to calculate the c/s, but as you know the silicon optimised that access away a long time ago. The alternative would be UDP-lite, but the ability of on path silicon to process that as competently and as completely as it processes UDP is by no means clear. - Stewart From Alexander.Vainshtein@ecitele.com Wed Jan 15 03:54:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68F01AE099; Wed, 15 Jan 2014 03:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOlBlzvmBw69; Wed, 15 Jan 2014 03:54:31 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id A4AF21AE085; Wed, 15 Jan 2014 03:54:30 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) with Microsoft SMTP Server (TLS) id 15.0.851.11; Wed, 15 Jan 2014 11:54:17 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Wed, 15 Jan 2014 11:54:17 +0000 From: Alexander Vainshtein To: "stbryant@cisco.com" Thread-Topic: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) Thread-Index: AQHPEeVeWllrh86W50KmWq92akl6n5qFqI4g Date: Wed, 15 Jan 2014 11:54:17 +0000 Message-ID: References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> <52D67186.8080008@cisco.com> In-Reply-To: <52D67186.8080008@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(252514010)(51704005)(13464003)(24454002)(199002)(189002)(377454003)(479174003)(77982001)(65816001)(74662001)(80022001)(66066001)(79102001)(74366001)(92566001)(74876001)(76786001)(76576001)(76796001)(74502001)(63696002)(47446002)(31966008)(59766001)(81686001)(74316001)(56776001)(87266001)(85852003)(69226001)(54356001)(85306002)(76482001)(87936001)(56816005)(90146001)(83072002)(2656002)(46102001)(47976001)(81816001)(15975445006)(81342001)(50986001)(74706001)(93136001)(53806001)(51856001)(80976001)(83322001)(4396001)(54316002)(19580395003)(93516001)(49866001)(81542001)(19580405001)(47736001)(33646001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB532; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:147.234.56.21; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Cc: "gorry@erg.abdn.ac.uk" , "mpls@ietf.org" , "ietf@ietf.org" , "tsvwg@ietf.org" , "wes@mti-systems.com" , Randy Bush , "jnc@mit.edu" , "lisp@ietf.org" Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 11:54:33 -0000 Stewart, and all, I fully agree that UDP checksums is not a real-life issue with the protocol= in question. They could probably help to check corrupted packets if corrup= tion happens when a packet passes thru a router (i.e. when the ingress data= link FCS has already been terminated and the egress data link FCS has not = been generated yet). But this is hopefully rare - and since MPLS does not c= are about it, why should the MPLS encapsulator care? I also do not think that congestion control is a serious issue for this pro= tocol, not in the least because the primary purpose of this protocol is ECM= P. But I would like to understand whether this protocol can really result in r= easonable distribution of traffic. "Reasonable" means that (a) there is suf= ficient entropy and (b) that the order in specific micro-flows is preserved= . The draft skips this issue (unless you consider a recommendation to use a= fixed randomly selected source port value if the tunnel does not need ECM= P a valid answer) . Any ideas as to how reasonable distribution of traffic can be achieved wit= h this protocol?=20 Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Wednesday, January 15, 2014 1:31 PM > To: Randy Bush > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; > wes@mti-systems.com; tsvwg@ietf.org; jnc@mit.edu > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gr= e-in- > udp draft (was: RE: Milestones changed for tsvwg WG)) >=20 > On 15/01/2014 11:08, Randy Bush wrote: > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > >> it seems that there are no valid statistics for the current Internet > >> to sustain your case. > > as we discussed privately, there seem to be no real measurements to > > sustain any case. this is all conjecturbation. > > > > what i do not understand is why, given the lack of solid evidence that > > we are in a safe space, you and others are not willing to spend a few > > euro cents to have a reasonable level of assurance at this layer. > > > > randy > Randy, >=20 > It is not a few cents, it is likely the re-engineering of a lot of silico= n. >=20 > The reason that UDP is of interest is that the on path silicon knows how = to > process it, for example it knows how to to ECMP it. >=20 > The reason that the UDP c/s is a problem for a tunneler is that it needs = to > have access to the whole pkt to calculate the c/s, but as you know the si= licon > optimised that access away a long time ago. >=20 > The alternative would be UDP-lite, but the ability of on path silicon to = process > that as competently and as completely as it processes UDP is by no means > clear. >=20 > - Stewart >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From l.wood@surrey.ac.uk Wed Jan 15 04:00:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE881AE35A; Wed, 15 Jan 2014 04:00:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 WXLAwN-sOj12; Wed, 15 Jan 2014 04:00:50 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1E10F1AE099; Wed, 15 Jan 2014 04:00:48 -0800 (PST) Received: from [85.158.136.51:52908] by server-4.bemta-5.messagelabs.com id 1A/93-26791-46876D25; Wed, 15 Jan 2014 12:00:36 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-10.tower-49.messagelabs.com!1389787235!29314441!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16991 invoked from network); 15 Jan 2014 12:00:35 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-10.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 15 Jan 2014 12:00:35 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 15 Jan 2014 12:00:35 +0000 From: To: , Date: Wed, 15 Jan 2014 11:57:18 +0000 Thread-Topic: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) Thread-Index: Ac8R5VMR2UUHMLGDRP+DhjlaFb7ztAAA52BF Message-ID: <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk> References: <201401141706.s0EH6Fbo099057@maildrop2.v6ds.occnc.com> ,<52D67186.8080008@cisco.com> In-Reply-To: <52D67186.8080008@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, tsvwg@ietf.org, wes@mti-systems.com, jnc@mit.edu, ietf@ietf.org Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 12:00:52 -0000 you've got the perfect application to encourage UDP lite adoption and deplo= yment here. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: 15 January 2014 11:31 To: Randy Bush Cc: Wood L Dr (Electronic Eng); wes@mti-systems.com; curtis@ipv6.occnc.com= ; gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; jnc@m= it.edu; lisp@ietf.org Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-= in-udp draft (was: RE: Milestones changed for tsvwg WG)) On 15/01/2014 11:08, Randy Bush wrote: > [ you insist on cc:ing me, so you get to endure my opinions ] > >> it seems that there are no valid statistics for the current Internet >> to sustain your case. > as we discussed privately, there seem to be no real measurements to > sustain any case. this is all conjecturbation. > > what i do not understand is why, given the lack of solid evidence that > we are in a safe space, you and others are not willing to spend a few > euro cents to have a reasonable level of assurance at this layer. > > randy Randy, It is not a few cents, it is likely the re-engineering of a lot of silicon. The reason that UDP is of interest is that the on path silicon knows how to process it, for example it knows how to to ECMP it. The reason that the UDP c/s is a problem for a tunneler is that it needs to have access to the whole pkt to calculate the c/s, but as you know the silicon optimised that access away a long time ago. The alternative would be UDP-lite, but the ability of on path silicon to process that as competently and as completely as it processes UDP is by no means clear. - Stewart From mehmet_toy@cable.comcast.com Wed Jan 15 06:27:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC901AE0F4 for ; Wed, 15 Jan 2014 06:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 ptg_NNE8DynO for ; Wed, 15 Jan 2014 06:27:36 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id EDA961AE0D2 for ; Wed, 15 Jan 2014 06:27:35 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.112790558; Wed, 15 Jan 2014 07:27:08 -0700 Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.77]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.03.0158.001; Wed, 15 Jan 2014 09:27:17 -0500 From: "Toy, Mehmet" To: "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJp09VgggBDyynCAAAGXQA== Date: Wed, 15 Jan 2014 14:27:16 +0000 Message-ID: References: <5316A0AB3C851246A7CA5758973207D445C30FB3@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C30FB3@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 14:27:37 -0000 As the co-author, I am not aware of any IPR issues related to draft-chen-mp= ls-p2mp-ingress-protection. Mehmet -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, January 03, 2014 8:49 AM To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the workin= g group chairs that the draft is ready to be adopted as a working group doc= ument. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-ingress-prote= ction? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From erosen@cisco.com Wed Jan 15 08:35:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9251AE136 for ; Wed, 15 Jan 2014 08:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 L0Gcc1sIA-F4 for ; Wed, 15 Jan 2014 08:35:15 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B24291AE128 for ; Wed, 15 Jan 2014 08:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=940; q=dns/txt; s=iport; t=1389803703; x=1391013303; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=3jEl9yjMmyjZbqMtWP+Qafe3IKlVVw/vLR42W0FS3ek=; b=CZCjayvIYN4RH82mFcXqcOEBYBvbBYeBm2FSKkf2FL2MJ5eYYvWf+e5W tnjmJnkGo6ed+xLtUmqj2rPgPDKwjWME+NpPQ123k7d63FrYJMSiYceDV uEezq2ae4YHvqeyynK5AlgS9tzxsphfIOOISpnKvW1mnW0yJfGaVrOdJy 8=; X-IronPort-AV: E=Sophos;i="4.95,663,1384300800"; d="scan'208";a="103019656" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 15 Jan 2014 16:35:02 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.71.43]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0FGZ01X007549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jan 2014 16:35:02 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id s0FGZ026006734; Wed, 15 Jan 2014 11:35:00 -0500 From: Eric Rosen To: Alexander Vainshtein In-reply-to: Your message of Wed, 15 Jan 2014 11:54:17 +0000. Date: Wed, 15 Jan 2014 11:35:00 -0500 Message-ID: <6733.1389803700@erosen-linux> Cc: "mpls@ietf.org" Subject: Re: [mpls] mpls-in-udp entropy X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 16:35:16 -0000 (Changed subject line and trimmed cc-list.) Sasha> I would like to understand whether this protocol can really result in Sasha> reasonable distribution of traffic. "Reasonable" means that (a) there Sasha> is sufficient entropy and (b) that the order in specific micro-flows Sasha> is preserved. I thought the intention was that the encapsulator would set the UDP source port based upon the entropy of the packet being encapsulated. This only requires that the encapsulator know how to properly apply ECMP to the MPLS packet that is being encapsulated. That is, compute the hash that would be used to apply ECMP to the MPLS packet, and then map from that hash to a UDP source port. E.g., two MPLS packets with the same entropy label would get the same UDP source port, two MPLS packets with no entropy label but containing the same TCP flow would get the same source port, etc. Do you think there is a problem here? From akatlas@gmail.com Wed Jan 15 08:54:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CE61AE11D for ; Wed, 15 Jan 2014 08:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phJGVOXfU4zj for ; Wed, 15 Jan 2014 08:54:31 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 062A21AE118 for ; Wed, 15 Jan 2014 08:54:30 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id tq11so425174ieb.26 for ; Wed, 15 Jan 2014 08:54:19 -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=9cxqwEtR2l66YCOjP4S9d41BYvCM1TBsTjU/qoj5yDk=; b=iooFU+HhoDnBJyRBPA7v7PAfFTKT+QzSZmYUHSNeWWwyNhI4Q5sjNHipuYSQBuc4Ye jAn2uVzTTFV5MroHWLeW1D7bkekYMAC65uRFOu9itT/hiqLOvzhPb758RW0yxaoqfFMK 9M39bu24hOa38+VGbBdisRLBMP2qkxoAFt6jfDXtSYEyO7xb+gT77q+Sveerx47KCK9t CaTtCYTb6FK+xYw7SZ7dPDs4iHUw2bhOTd271ys2MbXlxDVsC7oadiH9d7Yb6Cj38zXZ lECKkI3Gwr/WMyyAHxILtdRqzHfz1BmIvGkP1QCuF9+mX52T99gjo5KrBVwZXaJMWdlv kKtQ== MIME-Version: 1.0 X-Received: by 10.43.155.147 with SMTP id li19mr2493392icc.94.1389804859132; Wed, 15 Jan 2014 08:54:19 -0800 (PST) Received: by 10.64.72.132 with HTTP; Wed, 15 Jan 2014 08:54:19 -0800 (PST) In-Reply-To: References: <5316A0AB3C851246A7CA5758973207D445C30FB3@SJCEML701-CHM.china.huawei.com> Date: Wed, 15 Jan 2014 11:54:19 -0500 Message-ID: From: Alia Atlas To: "Toy, Mehmet" Content-Type: multipart/alternative; boundary=001a11c3002aefaffd04f0052810 Cc: "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 16:54:33 -0000 --001a11c3002aefaffd04f0052810 Content-Type: text/plain; charset=ISO-8859-1 As a co-author, I am not aware of any IPR issues related to draft-chen-mpls-p2mp-ingress-protection. Alia On Wed, Jan 15, 2014 at 9:27 AM, Toy, Mehmet wrote: > As the co-author, I am not aware of any IPR issues related to > draft-chen-mpls-p2mp-ingress-protection. > Mehmet > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: Friday, January 03, 2014 8:49 AM > To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org > Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection > > Working Group, > > The authors of draft-chen-mpls-p2mp-ingress-protection have told the > working group chairs that the draft is ready to be adopted as a working > group document. > > Before starting the the poll to see if we have consensus to make this a > working group document we need to do an IPR poll. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-chen-mpls-p2mp-ingress-protection? > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant IPR. > The response needs to be sent to the MPLS wg mailing list. The documents > will not advance to the next stage until a response has been received from > each author and each contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Ross > (as MPLS WG co-chair) > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11c3002aefaffd04f0052810 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As a co-author, =A0I am not aware of any IPR issues relate= d to draft-chen-mpls-p2mp-ingress-protection.

Alia


On Wed, Jan 15,= 2014 at 9:27 AM, Toy, Mehmet <Mehmet_Toy@cable.comcast.com= > wrote:
As the co-author, I am not aware of any IPR = issues related to draft-chen-mpls-p2mp-ingress-protection.
Mehmet
-----Original Message-----
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ross Callon
Sent: Friday, January 03, 2014 8:49 AM
To: mpls@ietf.org; draft-chen-mpls-p2mp= -ingress-protection@tools.ietf.org
Cc: mpls-chairs@tools.ietf.or= g
Subject: [mpls] IPR Poll on d= raft-chen-mpls-p2mp-ingress-protection

Working Group,

The authors of draft-chen-mpls-p2mp-ingress-protection have told the workin= g group chairs that the draft is ready to be adopted as a working group doc= ument.

Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-chen-mpls-p2mp-ingress-prote= ction?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor.

If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules.

Thanks, Ross
(as MPLS WG co-chair)


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--001a11c3002aefaffd04f0052810-- From curtis@ipv6.occnc.com Wed Jan 15 08:58:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4031B1AE0D4; Wed, 15 Jan 2014 08:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 WGXl277OMqp3; Wed, 15 Jan 2014 08:58:19 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7AF1AE017; Wed, 15 Jan 2014 08:58:19 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FGvsQ9019368; Wed, 15 Jan 2014 11:57:54 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401151657.s0FGvsQ9019368@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 05:20:27 +0000." <290E20B455C66743BE178C5C84F1240847E63346C7@EXMB01CMS.surrey.ac.uk> Date: Wed, 15 Jan 2014 11:57:54 -0500 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 16:58:22 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346C7@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > That's robustness _for the tunnelled traffic_. > > Not for anything else sharing the network - that hasn't been > instrumented and measured. > > Lloyd Wood > http://about.me/lloydwood The reason that MPLS and PWE3 are successfully deployed is that this traffic is carried over "well-managed networks" as RFC 6936 puts it. If a UDP and IP encapsulation is added, then nothing changes. If the UDP encapsulation occurs on a lower end router, it is likely that the whole packet is available on which to perform a checksum. On a really low end router the checksum is likely to be done in software. If it occurs on a high end router then the part of the hardware that can today modify checksums only, doesn't even have access to the packet to do a checksum and put it into the front of the packet. There are two reasons for this. 1. A lot of high end routers split off the top 128-256 bytes and send it to a decision engine which can call for header modifications. The rest of the packet takes another path and is later concatonated before sending out. This works fine for checksum modifications but does not work for creating a new checksum. 2. A lot of high end hardware, particularly hardware intended for high end enterprise and data centers, uses a technique called "cut-through". The first 128-256 bytes go to a decision engine and get processed before the packet has been entirely received. The decision and header modifications are done and if there is no standing output queue, the header starts going out before all of the packet has been received. This is done to reduce latency. In these implementations if the incoming FCS is bad, an outgoing runt packet occurs. In the second case the UDP header is sent before the bytes over which the UDP header is computed are received. That is a consequence of putting the UDP checksum before the data. L2 encapsulation put the FCS after the data for this reason. So what you are asking, a UDP checksum on a fresh new encapsulation is impossible for some hardware. [ps - thanks to an offline discussion with Joel Halpern for bringing this up.] Perhaps we need a new UDP with a robust FCS at the back of the packet, but without that making a UDP checksum manditory for MPLS over UDP is guarenteed to be ignored in some deployments and with no adverse consequences. Is that what we want? Perhaps there can be discussion added to the draft to indicate why a UDP checksum is desirable and why in some circumstances it may be impossible to generate or difficult to check. This along with a SHOULD use a UDP checksum might be the best course of action. Curtis > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 15 January 2014 03:43 > To: Wood L Dr (Electronic Eng) > Cc: stbryant@cisco.com; wes@mti-systems.com; curtis@ipv6.occnc.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > > Lloyd, > > The part about RFC 6936 section 3.1 most relevant might be: > > There is extensive experience with deployments using tunnel > protocols in well-managed networks (e.g., corporate networks and > service provider core networks). This has shown the robustness of > methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS > that do not employ a transport protocol checksum and that have not > specified mechanisms to protect from corruption of the unprotected > headers (such as the VPN Identifier in MPLS). Reasons for the > robustness may include: > > If the rate of undetected modified packets is extremely low in > "well-managed networks", as we beleive is the case, then UDP checksums > won't change the situration much. > > So why *not* make them optional if experience has shown they are not > needed in the types of deployments we are talking about. > > Curtis > > > In message <290E20B455C66743BE178C5C84F1240847E63346C6@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > > Stewart, > > > > your 'I'm not in tunnel applications' suggests you've misunderstood > > the argument here. The point is not to protect the tunnel traffic > > (which can quite happily checksum itself), it is to protect everything > > else on the network from misdelivery. It's not the tunnel application, > > it's every application sharing the internet with the tunnel which > > has UDP checksums turned off. See all of RFC 6936 section 3.1. > > Tunnel is fine, sideeffects of misdelivery do not affect tunnel. > > > > And in IPv4 and IPv6, the pseudo-header checksum built into > > TCP and UDP is all we have. IPv6 deliberately copied v4 here. > > > > > What is the error rate in modern h/w and network systems? > > > > No-one measures end-to-end misdelivery. No-one knows. > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Stewart Bryant [stbryant@cisco.com] > > Sent: 14 January 2014 22:46 > > To: Wesley Eddy; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; randy@psg.com; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > > > > On 14/01/2014 22:07, Wesley Eddy wrote: > > > On 1/14/2014 4:57 PM, l.wood@surrey.ac.uk wrote: > > >> I don't think sayng 'oh, that error source is no longer a problem' disproves > > >> Stone's overall point about undetected errors, though the > > >> examples he uses from the technology of the day are necessarily > > >> dated. Dismissing the overall point because the examples use obsolete > > >> technology is throwing the baby out with the bathwater; a host-to-host > > >> error check catches things that intermediate checks cannot. > > >> > > >> Measuring error rates across end-to-end Internet traffic is something that has > > >> not received much attention , as error detection is not > > >> instrumented well - hence citing Stone's published work, in the absence > > >> of awareness of anything newer (and as high profile/immediately recognisable > > >> as sigcomm) in the area. > > >> > > > > > > +1 ... the message in the paper is applicable to layered systems > > > and internetworks in general. Changes in the link technology > > > since then don't invalidate it, especially since we know that > > > the technology not only changes rapidly, but also is always > > > growing in diverse directions, such that there things almost > > > universally true today may be turned on their heads tomorrow. > > > > > > Designs for stacking layers need to follow solid general > > > principles in order to be robust to changes (above and below). > > > > > Note that it is not only the link layer technology that has moved on, > > the signal integrity of the h/w at all stages of the design and > > implementation process has moved on. > > > > Can we agree that the statistics in the paper are discredited? > > > > If not, why not? > > > > What is the error rate in modern h/w and network systems? > > > > Is this significant in the application under consideration? > > > > Finally if we are really concerned that we do actually need a > > c/s (I am not in tunnel applications) why are we still happy to > > use what is frankly a pathetic check in modern terms? Why > > for example are we not moving to something like > > the Fletcher 64 bit c/s? > > > > Stewart From rtorvi@juniper.net Wed Jan 15 09:07:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6735F1AE14E for ; Wed, 15 Jan 2014 09:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 H2gD2oBSNpzr for ; Wed, 15 Jan 2014 09:07:31 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 54E481AE128 for ; Wed, 15 Jan 2014 09:07:31 -0800 (PST) Received: from mail146-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE031.bigfish.com (10.236.130.94) with Microsoft SMTP Server id 14.1.225.22; Wed, 15 Jan 2014 17:07:19 +0000 Received: from mail146-co9 (localhost [127.0.0.1]) by mail146-co9-R.bigfish.com (Postfix) with ESMTP id 58D615E01DD; Wed, 15 Jan 2014 17:07:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzc2hdchz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h9a9j1155h) Received-SPF: pass (mail146-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rtorvi@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(779001)(679001)(689001)(189002)(199002)(377454003)(13464003)(164054003)(2656002)(33646001)(83072002)(85852003)(56816005)(63696002)(47976001)(59766001)(50986001)(4396001)(90146001)(85306002)(54316002)(79102001)(19580395003)(65816001)(81816001)(93136001)(83322001)(87266001)(80022001)(93516002)(92566001)(66066001)(2201001)(49866001)(77982001)(87936001)(19580405001)(47736001)(1941001)(74662001)(76796001)(31966008)(74502001)(76576001)(76786001)(81686001)(81542001)(76482001)(81342001)(47446002)(74316001)(51856001)(46102001)(74366001)(54356001)(56776001)(74706001)(80976001)(74876001)(69226001)(53806001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB638; H:DM2PR05MB720.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail146-co9 (localhost.localdomain [127.0.0.1]) by mail146-co9 (MessageSwitch) id 1389805637253069_10167; Wed, 15 Jan 2014 17:07:17 +0000 (UTC) Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.252]) by mail146-co9.bigfish.com (Postfix) with ESMTP id 396A6C8004D; Wed, 15 Jan 2014 17:07:17 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 15 Jan 2014 17:07:17 +0000 Received: from DM2PR05MB638.namprd05.prod.outlook.com (10.141.157.149) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Wed, 15 Jan 2014 17:07:16 +0000 Received: from DM2PR05MB720.namprd05.prod.outlook.com (10.141.177.152) by DM2PR05MB638.namprd05.prod.outlook.com (10.141.157.149) with Microsoft SMTP Server (TLS) id 15.0.842.7; Wed, 15 Jan 2014 17:07:14 +0000 Received: from DM2PR05MB720.namprd05.prod.outlook.com ([10.141.177.152]) by DM2PR05MB720.namprd05.prod.outlook.com ([10.141.177.152]) with mapi id 15.00.0842.003; Wed, 15 Jan 2014 17:07:14 +0000 From: Raveendra Torvi To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJqGFpfw Date: Wed, 15 Jan 2014 17:07:14 +0000 Message-ID: <8f6e8efb035141fcb98b4eefed70f7cb@DM2PR05MB720.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-forefront-prvs: 00922518D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 17:07:33 -0000 I am not aware of any IPR for draft-chen-mpls-p2mp-ingress-protection. Thanks, Ravi -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Friday, January 03, 2014 11:49 AM To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the workin= g group chairs that the draft is ready to be adopted as a working group doc= ument. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-ingress-prote= ction? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) From fengman.xu@verizon.com Wed Jan 15 06:52:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7066A1AE397 for ; Wed, 15 Jan 2014 06:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 WjFhQ5zLJNPZ for ; Wed, 15 Jan 2014 06:52:49 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6635D1AE396 for ; Wed, 15 Jan 2014 06:52:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 15 Jan 2014 14:52:30 +0000 From: "Xu, Fengman" X-IronPort-AV: E=Sophos;i="4.95,663,1384300800"; d="scan'208";a="648624581" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 15 Jan 2014 14:52:28 +0000 Received: from FHDP1LUMXC7V33.us.one.verizon.com ([166.68.125.34]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Wed, 15 Jan 2014 09:52:28 -0500 To: "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Date: Wed, 15 Jan 2014 09:52:27 -0500 Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJp09VgggBDyO9CAAAmDwA== Message-ID: <65017ED8D0F1E343AF27F9E2F24859F216B1324AA6@FHDP1LUMXC7V33.us.one.verizon.com> References: <5316A0AB3C851246A7CA5758973207D445C30FA6@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C30FA6@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 15 Jan 2014 09:44:07 -0800 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 14:52:51 -0000 I am not aware of any related IPR. Thanks, Fengman co-author of the draft -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, January 03, 2014 8:49 AM To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the workin= g group chairs that the draft is ready to be adopted as a working group doc= ument. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-ingress-prote= ction? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From renwei.li@huawei.com Wed Jan 15 10:05:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE811AE3DE for ; Wed, 15 Jan 2014 10:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 l6TRSm5tHW4g for ; Wed, 15 Jan 2014 10:05:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 067011AE1A9 for ; Wed, 15 Jan 2014 10:05:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCN32608; Wed, 15 Jan 2014 18:05:09 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jan 2014 18:03:07 +0000 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; Wed, 15 Jan 2014 18:03:51 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Wed, 15 Jan 2014 10:03:40 -0800 From: Richard Li To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJqGJhqA Date: Wed, 15 Jan 2014 18:03:39 +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.213.49.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 18:05:24 -0000 I am not aware of any IPRs other than those disclosed. Thanks, /Renwei (as a contributor of this draft) -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, January 03, 2014 8:49 AM To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the workin= g group chairs that the draft is ready to be adopted as a working group doc= ument. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-ingress-prote= ction? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Wed Jan 15 10:35:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500A61AE3DC for ; Wed, 15 Jan 2014 10:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RP_MATCHES_RCVD=-0.538, 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 86ntZCep77dL for ; Wed, 15 Jan 2014 10:35:36 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id A4BA21AE125 for ; Wed, 15 Jan 2014 10:35:35 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FIZK1E020750; Wed, 15 Jan 2014 13:35:21 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401151835.s0FIZK1E020750@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 05:39:59 +0000." <290E20B455C66743BE178C5C84F1240847E63346C9@EXMB01CMS.surrey.ac.uk> Date: Wed, 15 Jan 2014 13:35:20 -0500 Cc: mpls@ietf.org, ietf@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 18:35:41 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346C9@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > Curtis > > http://lmgtfy.com/?q=Jonathan+Stone+CRC+checksum That is the Sigcomm 2000 paper that a number of people have said is no longer relevant, in some cases giving quite a bit of detail about the error causes in the paper and why these will be rare today. I thought you were refering to something more recent. > HDLC is just whatever is over the last hop. You said HDLC, I reused that as > an example. I gave HDLC as an example because in 2000 it was in use and a source of errors but in 2014 it is likely not to be in use just about anywhere in North America and Europe at least. > Any link technology could be substituted - 10Mbps Ethernet, say, though > you'd criticise that as not being 10Gbps Ethernet and therefore out of date. My point was that if you substituted 10Mbps Ethernet with a 32 bit FCS, for HDLC which often just counted and passed along errored packets, you would have far fewer errors, almost none. > Again, the point is that the link check is not end-to-end, and that errors > can creep in from the most unexpected places. By analogy with security, > if I have security across each hop, why would I need security end-to-end? > I already have it across each hop! Each link is highly and absolutely > unrbreakably secure! What is this end-to-end of which you speak? You have security end to end because someone may have a motivation to monitor or alter your packet. If you have robust L2 FCS, then there is no one with a motivation to disable that FCS and corrupt your data. If they did for MPLS carrying IP, then there is a check, albiet not a great one, that might catch it. If the MPLS payload is PW carrying a L2 carrying IP, same applies. Note that if the PW payload is TDM, Ethernet, or most other L2, at least a checksum if not more is available in the payload so the errors would be detected and the customer of the PW would complain. Those types of complaints have been a complete non-issue. > If you don't get that point because it's a bit abstract and timeless, that's > fine. (and if you have to explain the joke, the joke wasn't funny.) > The link CRC doesn't apply across the entire path; do the maths for > the path and a series of concatenated links. The joke is that you didn't realize any mention of HDLC being used now, just like X.25 being used now, was a joke. It actually isn't funny at all, except perhaps until someone doesn't get it. > [As it happens, I'm familiar with UDP/IP/HDLC internet infrastructure installed > within the decade and in daily operational use to deliver imagery from orbit. > But the paper I wrote on that dates from 2007, so is old and > won't be of interest to you.] That is clearly the exception. TDM is still alive and well in the third world and in access parts of the developed world that have not been upgraded but elsewhere alternative exist for terestrial Internet and TDM is gone from any non-third world network core that I am aware of. So don't run MPLS over UDP without a UDP checksum *on that infrastructure* if you can avoid it. But for most modern infrastructures MPLS over UDP without a UDP checksum would be fine. We are asking for a SHOULD, not a MUST NOT wrt UDP checksum. > Wait, this thread is all about putting 90s MPLS technology over UDP > technology specified in 1980. Clearly, if MPLS has to rely on an older > technology in this way, the MPLS crowd should give up and go home. And MPLS carried nothing but IP in those days so from a error detection standpoint it was and still is a NOOP. > We've learned repeatedly that zero checksums are a bad idea. IPv6 > RFC2460: > > Unlike IPv4, when UDP packets are originated by an IPv6 node, > the UDP checksum is not optional. That is, whenever > originating a UDP packet, an IPv6 node must compute a UDP > checksum over the packet and the pseudo-header, and, if that > computation yields a result of zero, it must be changed to hex > FFFF for placement in the UDP header. IPv6 receivers must > discard UDP packets containing a zero checksum, and should log > the error. > > which RFC6935 simply rewote as inconvenient to tunnelers without > considering how it affected everything else in the network. How it affects other everything else in the network should be considered before ignoring a SHOULD, as is always the case. > Those that do not learn from history are doomed to repeat it. > (Unless it's recent history, in which case they're doomed to reject it > as irrelevant.) > > Lloyd Wood > http://about.me/lloydwood Lloyd. There are a lot of papers that are still relevant. Almost all of the causes of errors studied in the 2000 network. Apparently an exception is your HDLC infrastructure, and that would be gone too as an issue if 32 bit CRC is enabled for HDLC and packets dropped on error, not just counted. That paper reported: 2,209 M packets 468,434 errors 389,934 ACK-of-FIN bug (old Window NT bug, fixed) 78,500 remaining Other errors cited but often not quantified CRLF replacement (thought to be Solaris bug) VJHC or other header comprssion bug possible PowerMac OS-X bug (fixed by publication) router memory error (ECC is used now) bad host DMA (PCIe has CRC32 today) The paper has a breakdown by type of error and discussion of the causes. In some cases a particular type of error came mostly from a small set of hosts but the cause is only likely to be host related and the entire type of error category can't with certainty be attributed to host error. Bad Hosts Another surprise in our traces was the large fraction of errors where are due to persistantly-misbehaving hosts. In fact the paper says: In general, link errors should be caught by the CRC. However there are cases where the link level protocol can interact to cause higher level checksum errors. The most notable situation is header compression and we looked vigorously for errors of this sort. Link errors are really not considered in the paper as a significant source of errors. Router memory and other hardware errors are cited but with today's hardware those types of errors should also be gone. I discussed the sources of errors in this paper previously in http://www.ietf.org/mail-archive/web/mpls/current/msg11247.html You did respond to that but only by top posting and ignoring the discussion in that email of the causes of errors in the paper. "No longer relevant" does not mean "not good work". It would be worth it for the Stone/Partridge study to be repeated. For this context it would have to be with cooperation of a provider and over the type of infrastructure that MPLS is intended to be run. Curtis > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 15 January 2014 01:42 > To: Wood L Dr (Electronic Eng) > Cc: curtis@ipv6.occnc.com; jmh@joelhalpern.com; lars@netapp.com; xuxiaohu@huawei.com; mpls@ietf.org; ietf@ietf.org > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > In message <290E20B455C66743BE178C5C84F1240847E63346C4@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > The HDLC part here is last link, not the scope of the whole path. Any > > 'low' bit error rate given actually becomes quite high once you > > consider no of bits per packet and line rate... > > > > Do read Jonathan Stone's papers on where errors creep in - not just in > > the link, by at any point along the path, including regeneration > > > > Lloyd Wood > > > Lloyd, > > There is no HDLC hop. No one has used HDLC for internet > infrastructure in ages. It was a joke, like Scott's comment on > wanting to use X.25. HDLC was disappearing when the Stone/Partridge > Sigcomm 2000 paper was written. > > Links please. And how old is that paper? Not another 15 year old > work is it? > > If you have one bit error per day, how many packets do you lose that > day? (hint: one). > > If you have one bit error per day, how many undetactable packet errors > do you have? (hint: crc32 gets all one bit errors, therefore zero). > > 10^-12 bit errors is one per 10 second on 100 Gb/s, one per 100 second > on 10 Gb/s and is generally considered high enough to take a link down > immediately. A 1500 byte packet is 12,000 bits, about ~10^4. That > would yield a packet rate as high as 10^-8 if bit errors were mostly > one bit error per packet. In that case all errors would be > detectable. It is only when there are a lot of bit errors or more per > packet that the CRC can be defeated and then its about 10^-9 chance. > > So at an error rate much less than 10^-8 packets (tightly bunched > errors with multiple bit errors per packet) some 10^-9 might be > undetectable with a CRC32. One packet every 10^6 seconds at 100 Gb/s > could have an undetectable error. About one undetectable error a day > or one a week for continuous full out 100 Gb/s link. > > Note that the same low error rate does not apply to a GbE or 10GbE > over colored optics over ROADM in the metro since there is no FEC > there. It also may not apply to the enterprise or campus Ethernets. > In those hops the error rate is likely to be higher. Needless to say, > wireless hops can have very high error rates. > > This is why it could make sense to have the UDP checksum optional in > MPLS over UDP. It wouldn't hurt to provide the checksums but in some > cases it might be OK to disable them. That is what SHOULD is for in > an IETF document. > > Curtis > > > > From: Curtis Villamizar [curtis@ipv6.occnc.com] > > Sent: 14 January 2014 20:54 > > To: Wood L Dr (Electronic Eng) > > Cc: jmh@joelhalpern.com; lars@netapp.com; xuxiaohu@huawei.com; mpls@ietf.org; ietf@ietf.org > > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > > > In message <290E20B455C66743BE178C5C84F1240847E63346C3@EXMB01CMS.surrey.ac.uk> > > l.wood@surrey.ac.uk writes: > > > > > It stands to reason that if tunnelers can turn off udp checksums > > > because their performance is degraded, they can turn off > > > congestion control because it will degrade their performance. > > > > > > Rest of the internet getting congested and getting > > > misdelivered corrupted packets? Really not their problem. > > > > > > There are important vendors trying to sell products here, > > > and they need performance to do so. > > > Get with the program! > > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > > > > OK, perhaps if you are running MPLS/UDP/IP over HDLC and the HDLC > > configuration is set to count FCS errors but not drop you will still > > *really* need the UDP checksum. Otherwise its isn't going to do much > > for you. Any checksum is really bad for some types of errors such as > > chunk reordering and multiple bit errors. > > > > Maybe on HDLC or PPP with 16 bit CRC you may see a low error rate, but > > in theory that would be much less than 10^-5 since few multiple bit > > errors will be coincidence match the CRC, even for a 16 bit CRC. > > > > I suspect most routers would be able to do the checksum anyway and for > > modern links if they come up with a zero error count that's fine. > > > > > > > > Modern OTN based transport networks use forward error correction FEC > > which accounts for a fair amount of overhead and a lot of processing > > gates on the receiving end. The measure of effectiveness of given FEC > > is in dB with 10 dB being a reduction of a factor of 10 in bit errors > > and typical FEC in the high tens of dB. The target corrected error > > rate is often 10^-15 or one bit error in 24 hours for 10 Gb/s, one bit > > error in 2.5 hours for 100 Gb/s. Any link with corrected bit error > > rates approaching 10^-12 is taken out of service. This is roughly > > equivalent to the old ES (errored seconds) and SES (severely errored > > seconds) metric where a ES is one second with any bit errors and an > > SES is one second with 10 or more errors (I think its 10). More than > > some number of ES or SES and a link is taken down. The uncorrected > > errors are passed through. > > > > A packet may traverse an entire continent with 2-3 such links > > separated by regeneration or could stop at a number of routers along > > the way. Typically today the router uses 10GbE or 100GbE (growing > > use) which are then passed as a bit stream in the transport network. > > At the other end the uncorrected errors from transport are picked up > > by Ethernet 32 bit FCS. Since a 32 bit FCS picks up 100% of single > > bit errors and most instances where a small number of bits are in > > error, and all but 1 in 2^32 where many bits are in error, few errors > > are going to get through. If GFP is used, the per packet FCS is > > checked at each hop and for GFP-T also checked end to end. > > > > A bad local ethernet is more likely to contribute an error (again > > better than 1 in 2^32 detection is expected) due to something like a > > bad CAT-{5,5e,6} connection or too many sharp turns. A DSL or DOCSIS > > link is also more likely to contribute an error. With CRC32 on all > > links and no bad hardware in between (ie: circa 1990s equipment with > > no parity RAM and no correction on DMA, buses, etc) you would expect > > on the order of 10^-8 errors (10^-9 per hop, a few errored hops). > > > > For example, two hosts on my home LAN had non-zero tcp checksums. > > Each had < 10^-6 packet error rate. It is hard to tell if this is > > host errors at the other end. The only hosts I have with non-zero are > > on the service provider DMZ LAN so that would include any bot attacks, > > etc, where sending hosts could be old junk. Host behind those have > > zero UDP and TCP checksum errors. This seems similar to Stewart's > > quick check. > > > > In the T1/T3 days the transport layer just had parity and just counted > > parity errors. Providers in those days were notorious for ignoring ES > > and SES counters until the customer complained. HDLC then had its 16 > > bit CRC, optional 32 bit. If an ISP wasn't paying attention to their > > HDLC error counters then it was up to the IP end customer to complain > > and hope the problem got escallated rather than dropped. > > > > > > > > As to whether congestion control is in practice needed see > > http://www.ietf.org/mail-archive/web/mpls/current/msg11222.html > > > > Its fine to make them both optional and to make congestion control > > mechanisms out of scope and the topic of a later document if needed. > > > > Curtis > > > > > > > > > ________________________________________ > > > From: ietf [ietf-bounces@ietf.org] On Behalf Of Joel M. Halpern [jmh@joelhalpern.com] > > > Sent: 10 January 2014 15:36 > > > To: Eggert, Lars; Xuxiaohu > > > Cc: mpls@ietf.org; IETF > > > Subject: Re: Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > Maybe I am completely missing things, but this looks wrong. > > > If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion > > > control will make it more likely that the service won't work. Is that > > > really the goal? > > > > > > We do not perform congestion control on MPLS LSPs. > > > Assuming that a UDP tunnel is carrying just MPLS and was established > > > just for MPLS, why would we expect it to behave differently than an MPLS > > > LSP running over the exact same path, carrying the exact same traffic? > > > > > > Yours, > > > Joel > > > > > > On 1/10/14 3:47 AM, Eggert, Lars wrote: > > > > Hi, > > > > > > > > that sounds good. What congestion control are you going to be specifying for your tunnel? > > > > > > > > Lars > > > > > > > > On 2014-1-10, at 4:46, Xuxiaohu wrote: > > > > > > > >> Hi Lars, > > > >> > > > >> Thanks a lot for your comments. > > > >> > > > >> I wonder whether the following modified text for Congestion Consideration section is OK from your point of view: > > > >> > > > >> Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded through "UDP tunnels", the congestion control guidelines for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically, MPLS can carry a number of different protocols as payloads. When the payload traffic is IP-based and congestion-controlled, the UDP tunnel SHOULD NOT employ its own congestion control mechanism, because congestion losses of tunneled traffic will already trigger an appropriate congestion response at the original senders of the tunneled traffic. When the payload traffic is not known to be IP-based, or is known to be IP-based but not congestion-controlled, the UDP tunnel SHOULD employ an appropriate congestion control mechanism. Furthermore, because UDP tunnels are usually bulk-transfer applications as far as the intermediate routers are concerned, the guidelines as defined in Section 3.1.1 of [RFC5405] SHOULD apply. > > > >> > > > >> Best regards, > > > >> Xiaohu > > > >> > > > >>> -----ÓʼþÔ­¼þ----- > > > >>> ·¢¼þÈË: mpls [mailto:mpls-bounces@ietf.org] ´ú±í Eggert, Lars > > > >>> ·¢ËÍʱ¼ä: 2014Äê1ÔÂ8ÈÕ 18:22 > > > >>> ÊÕ¼þÈË: IETF > > > >>> ³­ËÍ: mpls@ietf.org > > > >>> Ö÷Ìâ: Re: [mpls] Last Call: (Encapsulating MPLS > > > >>> in UDP) to Proposed Standard > > > >>> > > > >>> Hi, > > > >>> > > > >>> On 2014-1-2, at 16:14, The IESG wrote: > > > >>>> - 'Encapsulating MPLS in UDP' > > > >>>> as Proposed Standard > > > >>> > > > >>> > > > >>> this document needs to describe how it addresses the issues raised in BCP145 > > > >>> (RFC5405). It already contains some text about messages sizes and congestion > > > >>> considerations, which is great. Unfortunately, the text about congestion > > > >>> considerations is not fully in line with RFC5405. > > > >>> > > > >>> Lars > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Wed Jan 15 11:20:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFFB1AE389; Wed, 15 Jan 2014 11:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.538, 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 hUfHYSR1KgAw; Wed, 15 Jan 2014 11:20:11 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id F38761AE378; Wed, 15 Jan 2014 11:20:10 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FJJuT0021269; Wed, 15 Jan 2014 14:19:56 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401151919.s0FJJuT0021269@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 05:45:43 +0000." <290E20B455C66743BE178C5C84F1240847E63346CA@EXMB01CMS.surrey.ac.uk> Date: Wed, 15 Jan 2014 14:19:56 -0500 Cc: mpls@ietf.org, lars@netapp.com, ietf@ietf.org, scott.brim@gmail.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 19:20:13 -0000 Lloyd, Suggesting MPLS over TCP brings us back to the X.25 comment. You can do PPP in TCP. It has the benefit of getting a tunnle past firewalls. It has the drawback of TCP over IP over PPP over TCP where the upper and lower TCPs don't know about each other and interact, with the upper TCP doing redundant retransmits and a lot of unnecessary retransmits when the lower TCP is stalled. As a host solution this particular tunnel over TCP serves a purpose. As a router solution, a tunnel over TCP would cause massive redundant or unnecessary retransmits due to lots of TCP running over it unaware that retransmits are occurring at a lower layer. Another problem is the TCP state that would have to be held in hardware. Normally the router functions that use TCP are in the control plane and in software. All packets would also have to be bufferred in hardware until acknowledged. There are the save feasibility issues with a TCP checksum in most high end hardware. MPLS over TCP would likely be only feasible if done in software and therefore is not an appropriate solution for the deployment scenarios considered for MPLS over UDP. There are congestion control mechanisms that would be feasible for MPLS over UDP but mostly involve feedback, the programming of a leaky bucket, aka traffic shaper, and (preferably) some form of AQM on the shaper queue. This would involve no retransmissions and use the types of hardware building blocks available in forwarding chips. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346CA@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > this draft should be about mpls in TCP - a TCP tunnel. > > That will fix all congestion concerns. > > I look forward to reading justification of why TCP checksums can be turned off. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: mpls [mpls-bounces@ietf.org] On Behalf Of Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 15 January 2014 01:00 > To: Eggert, Lars > Cc: mpls@ietf.org; Scott Brim; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > In message <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> > "Eggert, Lars" writes: > > > Hi, > > > > On 2014-1-14, at 16:23, Joel M. Halpern wrote: > > > Isn't that basically the problem of the inner traffic sender, not the > > > problem of the tunnel that is carrying the traffic? > > > > no, because the sender of the inner traffic may be blasting some > > L2traffic, for an L2 where that is OK behavior. But that traffic is > > nowbeing encapsulated inside UDP and can hence go anywhere on the > > net*without the sender being aware of this*. > > That application would be a PW application and it would be more > appropriate to fix that in PW if there is consensus for a need to do > so, which afaik there is not. > > > > Asking tunnel's to solve the problem of applications with > > > undesirablebehavior seems backwards. > > > > It is the *tunnel* that performs the encapsulation and allows > > thattraffic to go places it couldn't before. And so it's the > > tunnel'sresponsibility to make sure that the traffic it injects into > > theInternet complies with the BCPs we have on congestion control. > > > > Lars > > If it is a service provider encapsulating traffic within their own > network, then they know what they are doing. That is the anticipated > use and among that community there is no consensus for need for > congestion control. > > If it is some hostile hosts trying to send MPLS over UDP over IP, > they, being hostile, are going to disable any congestion control. > Besides, no hostile host has a T1 to tunnel over the Internet so they > would be sending the same traffic they would normally just send of UDP > over IP. > > Anything made up of frames (Ethernet, ATM, FR) over PW over MPLS is > carrying IP and if frames drop, the IP applications see the drop and > behave just as they would for any drop. (ATM shreadding thread to > /dev/null please). > > If congestion aware or using a congestion aware transport, the top > level applications are still congestion aware. If congestion > ignoreant, they are still congestion ignoreant. If hostile, they are > still hostile. > > Back to draft-ietf-mpls-in-udp. I think the most recent text proposed > by the author is fine. > > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Wed Jan 15 11:45:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46631AE1A3 for ; Wed, 15 Jan 2014 11:45: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 7GM8uKxyHoKf for ; Wed, 15 Jan 2014 11:45:08 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0010.outbound.protection.outlook.com [213.199.154.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9777A1AE13F for ; Wed, 15 Jan 2014 11:45:07 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) with Microsoft SMTP Server (TLS) id 15.0.851.11; Wed, 15 Jan 2014 19:44:54 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Wed, 15 Jan 2014 19:44:54 +0000 From: Alexander Vainshtein To: "erosen@cisco.com" Thread-Topic: mpls-in-udp entropy Thread-Index: AQHPEg/DqrG2RffskkmH2n3OOLdVh5qGLwCX Date: Wed, 15 Jan 2014 19:44:53 +0000 Message-ID: <5b0765246d204750a50e1aad52a3b72e@AM3PR03MB532.eurprd03.prod.outlook.com> References: Your message of Wed, 15 Jan 2014 11:54:17 +0000. , <6733.1389803700@erosen-linux> In-Reply-To: <6733.1389803700@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.66.126.123] x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(199002)(189002)(377454003)(65816001)(77982001)(79102001)(80022001)(74662001)(66066001)(74366001)(92566001)(74876001)(76576001)(76786001)(76796001)(47446002)(63696002)(74502001)(31966008)(59766001)(81686001)(93516002)(74316001)(56776001)(87266001)(85852003)(69226001)(54356001)(85306002)(76482001)(87936001)(56816005)(90146001)(83072002)(2656002)(46102001)(47976001)(50986001)(81816001)(81342001)(74706001)(93136001)(51856001)(53806001)(49866001)(80976001)(83322001)(19580395003)(4396001)(33646001)(81542001)(19580405001)(54316002)(47736001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB532; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:109.66.126.123; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Cc: "mpls@ietf.org" Subject: Re: [mpls] mpls-in-udp entropy X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 19:45:12 -0000 Eric,=0A= Lots of thanks for a prompt and highly informative response.=0A= =0A= I have been actually thinking about the same thing, namely that the entropy= port should be the result of some hash over the label stack. =0A= =0A= If this is indeed the intention of the authors, it would make sense (at lea= st, from my point of view) of saying so in the draft. There is no need to m= ake such a statement normative, but it would really help the readers (both = implementors and operators) to understand what it is about.=0A= =0A= Regards,=0A= Sasha =0A= =0A= ________________________________________=0A= From: Eric Rosen =0A= Sent: Wednesday, January 15, 2014 6:35 PM=0A= To: Alexander Vainshtein=0A= Cc: mpls@ietf.org=0A= Subject: Re: mpls-in-udp entropy=0A= =0A= (Changed subject line and trimmed cc-list.)=0A= =0A= Sasha> I would like to understand whether this protocol can really result i= n=0A= Sasha> reasonable distribution of traffic. "Reasonable" means that (a) ther= e=0A= Sasha> is sufficient entropy and (b) that the order in specific micro-flows= =0A= Sasha> is preserved.=0A= =0A= I thought the intention was that the encapsulator would set the UDP source= =0A= port based upon the entropy of the packet being encapsulated. This only=0A= requires that the encapsulator know how to properly apply ECMP to the MPLS= =0A= packet that is being encapsulated. That is, compute the hash that would be= =0A= used to apply ECMP to the MPLS packet, and then map from that hash to a UDP= =0A= source port.=0A= =0A= E.g., two MPLS packets with the same entropy label would get the same UDP= =0A= source port, two MPLS packets with no entropy label but containing the same= =0A= TCP flow would get the same source port, etc.=0A= =0A= Do you think there is a problem here?=0A= From curtis@ipv6.occnc.com Wed Jan 15 12:02:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2231AE1A6; Wed, 15 Jan 2014 12:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 BFERJXjAteJ6; Wed, 15 Jan 2014 12:02:28 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 30DF71AE199; Wed, 15 Jan 2014 12:02:28 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FK28cx022175; Wed, 15 Jan 2014 15:02:08 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401152002.s0FK28cx022175@maildrop2.v6ds.occnc.com> To: Randy Bush From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 17:08:09 +0600." Date: Wed, 15 Jan 2014 15:02:07 -0500 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:02:29 -0000 In message Randy Bush writes: > > [ you insist on cc:ing me, so you get to endure my opinions ] Not a problem (this time). :-) > > it seems that there are no valid statistics for the current Internet > > to sustain your case. > > as we discussed privately, there seem to be no real measurements to > sustain any case. this is all conjecturbation. > > what i do not understand is why, given the lack of solid evidence that > we are in a safe space, you and others are not willing to spend a few > euro cents to have a reasonable level of assurance at this layer. > > randy Randy, See http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html for reasons why routers would want to avoid having to fill in a checksum. It would have been more feasible for an FCS at the end of the packet for these cases but the UDP checksum is in the front. This entire discussion is over putting in a SHOULD rather than a MUST in two places, UDP checksum and congestion control, plus deferring defining the congestion control for MPLS over UDP until deployments show a need for it. Curtis From curtis@ipv6.occnc.com Wed Jan 15 12:05:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2C1AE389; Wed, 15 Jan 2014 12:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 AVnar5yR1lmb; Wed, 15 Jan 2014 12:05:52 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5B50A1AE373; Wed, 15 Jan 2014 12:05:52 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FK5VIU022303; Wed, 15 Jan 2014 15:05:31 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401152005.s0FK5VIU022303@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 11:57:18 +0000." <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk> Date: Wed, 15 Jan 2014 15:05:31 -0500 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:05:54 -0000 Or perhaps UDP heavy with a FCS at the end and no checksum at all. You do make a good point that perhaps UDP lite should be mentioned in MPLS over UDP as an option. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > you've got the perfect application to encourage UDP lite adoption and > deployment here. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: 15 January 2014 11:31 > To: Randy Bush > Cc: Wood L Dr (Electronic Eng); wes@mti-systems.com; curtis@ipv6.occnc.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > > On 15/01/2014 11:08, Randy Bush wrote: > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > >> it seems that there are no valid statistics for the current Internet > >> to sustain your case. > > as we discussed privately, there seem to be no real measurements to > > sustain any case. this is all conjecturbation. > > > > what i do not understand is why, given the lack of solid evidence that > > we are in a safe space, you and others are not willing to spend a few > > euro cents to have a reasonable level of assurance at this layer. > > > > randy > Randy, > > It is not a few cents, it is likely the re-engineering of a lot > of silicon. > > The reason that UDP is of interest is that the on path silicon > knows how to process it, for example it knows how to to ECMP it. > > The reason that the UDP c/s is a problem for a tunneler is that > it needs to have access to the whole pkt to calculate the > c/s, but as you know the silicon optimised that access away > a long time ago. > > The alternative would be UDP-lite, but the ability of on path > silicon to process that as competently and as completely as it > processes UDP is by no means clear. > > - Stewart From ningso@yahoo.com Wed Jan 15 12:17:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A901AE112 for ; Wed, 15 Jan 2014 12:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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, RP_MATCHES_RCVD=-0.538] 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 xttfxVxb9W9q for ; Wed, 15 Jan 2014 12:17:00 -0800 (PST) Received: from nm46-vm10.bullet.mail.bf1.yahoo.com (nm46-vm10.bullet.mail.bf1.yahoo.com [216.109.114.203]) by ietfa.amsl.com (Postfix) with ESMTP id 87D481AE373 for ; Wed, 15 Jan 2014 12:16:59 -0800 (PST) Received: from [98.139.215.140] by nm46.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jan 2014 20:16:47 -0000 Received: from [98.139.212.234] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jan 2014 20:16:47 -0000 Received: from [127.0.0.1] by omp1043.mail.bf1.yahoo.com with NNFMP; 15 Jan 2014 20:16:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 698933.3998.bm@omp1043.mail.bf1.yahoo.com Received: (qmail 66739 invoked by uid 60001); 15 Jan 2014 20:16:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1389817006; bh=DzSxKAr4GdPhF/zpbagHhWwfwNG1QmsDZUzc3F/aTS0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=3Q9opTw7cJIeYAlMJafUTdNfdwKEQWlPVBMdwTgFlOl2dVzGqHnD1ys51h7CwogApDgMvGKHofTEbZzDkn33v+y+ZX6lbngcKTf/yLNcJ4jlEV0UdXwWi7Xre3gZeitjqXun7h+OoVE30KEBO9YylY2TKvolSAAQc7O4UAUQfNE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=VUyjA9cDtJyas/jDxEf9GIMHsxD/zn7CVFAYWz3ukGULLzBIBoV67qMVH8TDWgQbYDomo7WpEUVrpoqjhOp2wUDp2rRTdfSzFJZw3Z1d4PearbSzU5pAmNT9awsxaovUMu9NIxl9RaLy0eNWUfTDSu6EKwpt1TkvH6kenU5XC6E=; X-YMail-OSG: J51fM_oVM1lST03yyjw5PYYrRXNlcEddneJDE0SMG9x8Ywn LcX67dljRvUCtjwAw4uuqeJCbR9s99.NEwdBay5Z.pbUHbDiH6tj5ho.ulNI SxqVaUeq0Cx7cac9YEw4mLlXwi5mxYGvOamh20K2Xu.EogQr.vAt0nT8n6Ag a8crLOxVHBUmTopYvYg3QkH9I3pJWsjy.RiztXXru7xPsYu5o2Iw8FCayJpj Rc3BGRGflTL9E.Q2cyx66GBMt3GbV423Ixe3QLk5qtEDnNzRL.FjfRAwf8xG yUlCAZbcyVxT7ZeK4iCTYnVcSeFKUYNZmBZre9jwNd8DOWNreKPU_FS5JXur 8d.o9GMibe7k6Cb9FCENrBuZD6QFG3CdPEmEjOZZWAi9sJE326O4F6QkdyGI rW9MPyY_yFeLS3I68_a5uA1CxPhK.LxSXuUj76c4zoNxJ_qtUW.UagZTZTUB cfyUTULGHh0lLvyBAYeyqp2p94CuvGC06TMflNY0imkBmTl5sqOSpIa2ghFl 2mXkg6w19Y6pnnQ6N4v3rIzwCot40p.kDmS3rzYPUPQbwYDNRyxh1oeD0p1w M3vIlY.0SPw-- Received: from [173.71.53.5] by web162605.mail.bf1.yahoo.com via HTTP; Wed, 15 Jan 2014 12:16:46 PST X-Rocket-MIMEInfo: 002.001, SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhc3NvY2lhdGVkIHdpdGggdGhlIGRyYWZ0LgoKTmluZyBTbwo5NzItOTU1LTA5MTQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: Message-ID: <1389817006.43531.YahooMailNeo@web162605.mail.bf1.yahoo.com> Date: Wed, 15 Jan 2014 12:16:46 -0800 (PST) From: ningso@yahoo.com To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1157309285-1975745792-1389817006=:43531" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ningso@yahoo.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:17:01 -0000 --1157309285-1975745792-1389817006=:43531 Content-Type: text/plain; charset=us-ascii I am not aware of any IPR associated with the draft. Ning So 972-955-0914 --1157309285-1975745792-1389817006=:43531 Content-Type: text/html; charset=us-ascii
I am not aware of any IPR associated with the draft.
 
Ning So
972-955-0914
--1157309285-1975745792-1389817006=:43531-- From gorry@erg.abdn.ac.uk Wed Jan 15 12:18:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FFB1AE19A; Wed, 15 Jan 2014 12:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 Tprr68sz72YW; Wed, 15 Jan 2014 12:18:24 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 119351AE112; Wed, 15 Jan 2014 12:18:24 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7E0802B4230; Wed, 15 Jan 2014 20:18:11 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 15 Jan 2014 20:18:11 -0000 Message-ID: In-Reply-To: <201401152005.s0FK5VIU022303@maildrop2.v6ds.occnc.com> References: <201401152005.s0FK5VIU022303@maildrop2.v6ds.occnc.com> Date: Wed, 15 Jan 2014 20:18:11 -0000 From: gorry@erg.abdn.ac.uk To: curtis@ipv6.occnc.com User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Wed, 15 Jan 2014 12:28:50 -0800 Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:18:26 -0000 You may care to reference this to Section 2.2 of RFC 6936, which provides some background to where UDP-Lite may help, and some of the potential pitfalls. Gorry > > Or perhaps UDP heavy with a FCS at the end and no checksum at all. > > You do make a good point that perhaps UDP lite should be mentioned in > MPLS over UDP as an option. > > Curtis > > > In message > <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > >> you've got the perfect application to encourage UDP lite adoption and >> deployment here. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Stewart Bryant [stbryant@cisco.com] >> Sent: 15 January 2014 11:31 >> To: Randy Bush >> Cc: Wood L Dr (Electronic Eng); wes@mti-systems.com; >> curtis@ipv6.occnc.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; >> ietf@ietf.org; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org >> Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: >> gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) >> >> On 15/01/2014 11:08, Randy Bush wrote: >> > [ you insist on cc:ing me, so you get to endure my opinions ] >> > >> >> it seems that there are no valid statistics for the current Internet >> >> to sustain your case. >> > as we discussed privately, there seem to be no real measurements to >> > sustain any case. this is all conjecturbation. >> > >> > what i do not understand is why, given the lack of solid evidence that >> > we are in a safe space, you and others are not willing to spend a few >> > euro cents to have a reasonable level of assurance at this layer. >> > >> > randy >> Randy, >> >> It is not a few cents, it is likely the re-engineering of a lot >> of silicon. >> >> The reason that UDP is of interest is that the on path silicon >> knows how to process it, for example it knows how to to ECMP it. >> >> The reason that the UDP c/s is a problem for a tunneler is that >> it needs to have access to the whole pkt to calculate the >> c/s, but as you know the silicon optimised that access away >> a long time ago. >> >> The alternative would be UDP-lite, but the ability of on path >> silicon to process that as competently and as completely as it >> processes UDP is by no means clear. >> >> - Stewart > From curtis@ipv6.occnc.com Wed Jan 15 12:34:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413911AE19A; Wed, 15 Jan 2014 12:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 cb0wpl-l9VAq; Wed, 15 Jan 2014 12:34:57 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1EB1AE0D5; Wed, 15 Jan 2014 12:34:57 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FKYYKO022696; Wed, 15 Jan 2014 15:34:34 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401152034.s0FKYYKO022696@maildrop2.v6ds.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 11:54:17 +0000." Date: Wed, 15 Jan 2014 15:34:34 -0500 Cc: "gorry@erg.abdn.ac.uk" , "mpls@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" , "wes@mti-systems.com" , Randy Bush , "jnc@mit.edu" , "ietf@ietf.org" Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:34:59 -0000 In message Alexander Vainshtein writes: > > Stewart, and all, > > I fully agree that UDP checksums is not a real-life issue with the > protocol in question. They could probably help to check corrupted > packets if corruption happens when a packet passes thru a router > (i.e. when the ingress data link FCS has already been terminated and > the egress data link FCS has not been generated yet). But this is > hopefully rare - and since MPLS does not care about it, why should the > MPLS encapsulator care? Why the MPLS over UDP encapsulation cares is in http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html > I also do not think that congestion control is a serious issue for > this protocol, not in the least because the primary purpose of this > protocol is ECMP. The chips I had worked with all did a lookup and retrieved a next-hop index. That could point to a single hop or and entry into the multipath hardware gunk (tables for some not so good implementations). My guess is Stewart is concerned about hardware than can lookup an IP adddress and do multipath but not do an MPLS ILM lookup and then do multipath. [I find that hard to believe since it would be tough to do MPLS over a LAG. Most chips that had not anticipated this could do this with firmware changes because there was enough flexibility in the hardware intended for LAG to get the job done. Some might have limitations with ECMP where component links of the ECMP were LAG. OTOH the further you go back in time the more severe chip limitations you will run into.] IMHO the draft should remove the ECMP motivation from the introduction and then there would be no need to debate this. The draft need only define the protocol. > But I would like to understand whether this protocol can really result > in reasonable distribution of traffic. "Reasonable" means that (a) > there is sufficient entropy and (b) that the order in specific > micro-flows is preserved. The draft skips this issue (unless you > consider a recommendation to use a fixed randomly selected source port > value if the tunnel does not need ECMP a valid answer) . > > Any ideas as to how reasonable distribution of traffic can be achieved > with this protocol? ECMP has been around for a long time and providers carefully tune IGP metrics to get a better but often not very good load balance with ECMP. With other multipath methods you can get non-equal load balance and remove the equal cost limitiation but that might need more recent hardware than Steward and others are faced with. ECMP is a blunt tool. > Regards, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 Curtis > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > > Sent: Wednesday, January 15, 2014 1:31 PM > > To: Randy Bush > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; > > wes@mti-systems.com; tsvwg@ietf.org; jnc@mit.edu > > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in- > > udp draft (was: RE: Milestones changed for tsvwg WG)) > > > > On 15/01/2014 11:08, Randy Bush wrote: > > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > > > >> it seems that there are no valid statistics for the current Internet > > >> to sustain your case. > > > as we discussed privately, there seem to be no real measurements to > > > sustain any case. this is all conjecturbation. > > > > > > what i do not understand is why, given the lack of solid evidence that > > > we are in a safe space, you and others are not willing to spend a few > > > euro cents to have a reasonable level of assurance at this layer. > > > > > > randy > > Randy, > > > > It is not a few cents, it is likely the re-engineering of a lot of silicon. > > > > The reason that UDP is of interest is that the on path silicon knows how to > > process it, for example it knows how to to ECMP it. > > > > The reason that the UDP c/s is a problem for a tunneler is that it needs to > > have access to the whole pkt to calculate the c/s, but as you know the silicon > > optimised that access away a long time ago. > > > > The alternative would be UDP-lite, but the ability of on path silicon to process > > that as competently and as completely as it processes UDP is by no means > > clear. > > > > - Stewart From curtis@ipv6.occnc.com Wed Jan 15 12:49:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848D51AE248; Wed, 15 Jan 2014 12:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 reuQK5rr6cLn; Wed, 15 Jan 2014 12:49:05 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9DA1AE0D5; Wed, 15 Jan 2014 12:49:04 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FKmlsn022848; Wed, 15 Jan 2014 15:48:48 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401152048.s0FKmlsn022848@maildrop2.v6ds.occnc.com> To: gorry@erg.abdn.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 20:18:11 +0000." Date: Wed, 15 Jan 2014 15:48:47 -0500 Cc: mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:49:07 -0000 In message gorry@erg.abdn.ac.uk writes: > > You may care to reference this to Section 2.2 of RFC 6936, which provides > some background to where UDP-Lite may help, and some of the potential > pitfalls. > > Gorry The right tool for the job but ... Expect some pushback because older hardware looks at TCP and UDP in the protocol field and then checks port numbers for ECMP load balance. That older hardware will not do this for UDP-Lite. With MPLS over UDP, only the dest port number matters and the src port number can be used like the MPLS Entropy Label. That is about the only thing that would not work in some networks with UDP-Lite. IMHO it would be advantageous to provide the option to use UDP-Lite rather than UDP with no checksum at all. The section in RFC 6936 could be cited. The limitation I mentioned could also be cited. Curtis > > Or perhaps UDP heavy with a FCS at the end and no checksum at all. > > > > You do make a good point that perhaps UDP lite should be mentioned in > > MPLS over UDP as an option. > > > > Curtis > > > > > > In message > > <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk> > > l.wood@surrey.ac.uk writes: > > > >> you've got the perfect application to encourage UDP lite adoption and > >> deployment here. > >> > >> Lloyd Wood > >> http://about.me/lloydwood > >> ________________________________________ > >> From: Stewart Bryant [stbryant@cisco.com] > >> Sent: 15 January 2014 11:31 > >> To: Randy Bush > >> Cc: Wood L Dr (Electronic Eng); wes@mti-systems.com; > >> curtis@ipv6.occnc.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; > >> ietf@ietf.org; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org > >> Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: > >> gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) > >> > >> On 15/01/2014 11:08, Randy Bush wrote: > >> > [ you insist on cc:ing me, so you get to endure my opinions ] > >> > > >> >> it seems that there are no valid statistics for the current Internet > >> >> to sustain your case. > >> > as we discussed privately, there seem to be no real measurements to > >> > sustain any case. this is all conjecturbation. > >> > > >> > what i do not understand is why, given the lack of solid evidence that > >> > we are in a safe space, you and others are not willing to spend a few > >> > euro cents to have a reasonable level of assurance at this layer. > >> > > >> > randy > >> Randy, > >> > >> It is not a few cents, it is likely the re-engineering of a lot > >> of silicon. > >> > >> The reason that UDP is of interest is that the on path silicon > >> knows how to process it, for example it knows how to to ECMP it. > >> > >> The reason that the UDP c/s is a problem for a tunneler is that > >> it needs to have access to the whole pkt to calculate the > >> c/s, but as you know the silicon optimised that access away > >> a long time ago. > >> > >> The alternative would be UDP-lite, but the ability of on path > >> silicon to process that as competently and as completely as it > >> processes UDP is by no means clear. > >> > >> - Stewart From curtis@ipv6.occnc.com Wed Jan 15 12:56:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73261AE248 for ; Wed, 15 Jan 2014 12:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 XThJPZZdouPX for ; Wed, 15 Jan 2014 12:56:29 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id E7FED1AE0D5 for ; Wed, 15 Jan 2014 12:56:28 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FKuBNT022977; Wed, 15 Jan 2014 15:56:11 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401152056.s0FKuBNT022977@maildrop2.v6ds.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Jan 2014 19:44:53 +0000." <5b0765246d204750a50e1aad52a3b72e@AM3PR03MB532.eurprd03.prod.outlook.com> Date: Wed, 15 Jan 2014 15:56:11 -0500 Cc: "mpls@ietf.org" Subject: Re: [mpls] mpls-in-udp entropy X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:56:30 -0000 In message <5b0765246d204750a50e1aad52a3b72e@AM3PR03MB532.eurprd03.prod.outlook.com> Alexander Vainshtein writes: > Eric, > Lots of thanks for a prompt and highly informative response. > > I have been actually thinking about the same thing, namely that the entropy port should be the result of some hash over the label stack. > > If this is indeed the intention of the authors, it would make sense (at least, from my point of view) of saying so in the draft. There is no need to make such a statement normative, but it would really help the readers (both implementors and operators) to understand what it is about. > > Regards, > Sasha Avoiding the lower 8K of the port number space might not be a bad idea to avoid a return port being a WKP including the non-root WKP space used by X-Windows and other things. Curtis > ________________________________________ > From: Eric Rosen > Sent: Wednesday, January 15, 2014 6:35 PM > To: Alexander Vainshtein > Cc: mpls@ietf.org > Subject: Re: mpls-in-udp entropy > > (Changed subject line and trimmed cc-list.) > > Sasha> I would like to understand whether this protocol can really result in > Sasha> reasonable distribution of traffic. "Reasonable" means that (a) there > Sasha> is sufficient entropy and (b) that the order in specific micro-flows > Sasha> is preserved. > > I thought the intention was that the encapsulator would set the UDP source > port based upon the entropy of the packet being encapsulated. This only > requires that the encapsulator know how to properly apply ECMP to the MPLS > packet that is being encapsulated. That is, compute the hash that would be > used to apply ECMP to the MPLS packet, and then map from that hash to a UDP > source port. > > E.g., two MPLS packets with the same entropy label would get the same UDP > source port, two MPLS packets with no entropy label but containing the same > TCP flow would get the same source port, etc. > > Do you think there is a problem here? > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lizhenbin@huawei.com Wed Jan 15 17:35:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091101AE13E for ; Wed, 15 Jan 2014 17:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.211 X-Spam-Level: * X-Spam-Status: No, score=1.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 sSL1VCSD8XfP for ; Wed, 15 Jan 2014 17:35:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B98E41ADFD1 for ; Wed, 15 Jan 2014 17:35:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZZ22945; Thu, 16 Jan 2014 01:35:29 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 01:34:43 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 01:35:27 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 16 Jan 2014 09:35:20 +0800 From: Lizhenbin To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/BN93jIrSvUqrfd3SsFnQwZqGJhqAgAB+4LA= Date: Thu, 16 Jan 2014 01:35:20 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081E7118@nkgeml506-mbx.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.76.77] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogSVBSIFBvbGwgb24gZHJhZnQtY2hlbi1tcGxz?= =?gb2312?b?LXAybXAtaW5ncmVzcy1wcm90ZWN0aW9u?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 01:35:45 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUnMgb3RoZXIgdGhhbiB0aG9zZSBkaXNjbG9zZWQuDQoN ClRoYW5rcywNCg0KL1poZW5iaW4gKGFzIGEgY29udHJpYnV0b3Igb2YgdGhpcyBkcmFmdCkNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9zcyBDYWxsb24NClNlbnQ6IEZyaWRheSwg SmFudWFyeSAwMywgMjAxNCA4OjQ5IEFNDQpUbzogbXBsc0BpZXRmLm9yZzsgZHJhZnQtY2hlbi1t cGxzLXAybXAtaW5ncmVzcy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnDQpDYzogbXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzXSBJUFIgUG9sbCBvbiBkcmFmdC1jaGVu LW1wbHMtcDJtcC1pbmdyZXNzLXByb3RlY3Rpb24NCg0KV29ya2luZyBHcm91cCwNCg0KVGhlIGF1 dGhvcnMgb2YgZHJhZnQtY2hlbi1tcGxzLXAybXAtaW5ncmVzcy1wcm90ZWN0aW9uIGhhdmUgdG9s ZCB0aGUgd29ya2luZyBncm91cCBjaGFpcnMgdGhhdCB0aGUgZHJhZnQgaXMgcmVhZHkgdG8gYmUg YWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNCkJlZm9yZSBzdGFydGluZyB0 aGUgdGhlIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgY29uc2Vuc3VzIHRvIG1ha2UgdGhpcyBhIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQgd2UgbmVlZCB0byBkbyBhbiBJUFIgcG9sbC4NCg0KVGhpcyBt YWlsIHN0YXJ0cyB0aGF0IElQUiBwb2xsLg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhh dCBhcHBsaWVzIHRvIGRyYWZ0LWNoZW4tbXBscy1wMm1wLWluZ3Jlc3MtcHJvdGVjdGlvbj8NCg0K SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVU RiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUg ZGV0YWlscykuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNv bnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0 aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoZSByZXNwb25z ZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIHdnIG1haWxpbmcgbGlzdC4gVGhlIGRvY3Vt ZW50cyB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2Ug aGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgZWFjaCBjb250cmlidXRvci4N Cg0KSWYgeW91IGFyZSBvbiB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3Rl ZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVz cG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJl ZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCg0KVGhhbmtzLCBS b3NzDQooYXMgTVBMUyBXRyBjby1jaGFpcikNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQpt cGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cg== From liulei.kddi@gmail.com Wed Jan 15 21:05:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893961AE4CE for ; Wed, 15 Jan 2014 21:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF3PpJWpJXg5 for ; Wed, 15 Jan 2014 21:05:56 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id AFA841AE4CF for ; Wed, 15 Jan 2014 21:05:55 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id uq10so6617403igb.5 for ; Wed, 15 Jan 2014 21:05:43 -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=uEjHFG2meSyEVQnYUAlcey5r0TF0msZ3NeZNEgN50PY=; b=iO02BQHM0tXL3KXU83rVaSj8vzD8j1A51ErOf+wdx5nKFE+/Ww0Dr0IAWExMt+KUW/ rEnKE02/aCIS0bOzClvHrn3Ohi+GCsA7rEFzR7ii5jXQQgeGMVeMrFyYXPxxAOJppNtJ 9NAolymVJlHgoNCFuSkxdLguxEkxx+scjTWY8ABQdH48eA22SzLKJ/xNR1S8n/9l4omb HH0wZsnMmL5hJCyiOUihtv8FsmcTApTm0efpzZ3kZMm25xC8WyBqC6nAn8w7G29oWFcN Q8pLPLMMD5xNqMxfk4T4VlbuJvEW4Xmv7tXOa36gqh041DBBaKRN0ED8NQl+Ta3RGPaO +k2A== MIME-Version: 1.0 X-Received: by 10.50.43.225 with SMTP id z1mr7006800igl.41.1389848743708; Wed, 15 Jan 2014 21:05:43 -0800 (PST) Received: by 10.50.65.37 with HTTP; Wed, 15 Jan 2014 21:05:43 -0800 (PST) In-Reply-To: References: Date: Wed, 15 Jan 2014 21:05:43 -0800 Message-ID: From: LEI LIU To: Ross Callon Content-Type: multipart/alternative; boundary=089e010d8dd6a90c1804f00f6006 Cc: "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 05:05:58 -0000 --089e010d8dd6a90c1804f00f6006 Content-Type: text/plain; charset=ISO-8859-1 I am not aware of any IPR associated with the draft. Thanks, Lei Liu (as co-author of this draft) 2014/1/3 Ross Callon > Working Group, > > The authors of draft-chen-mpls-p2mp-ingress-protection have told the > working group chairs that the draft is ready to be adopted as a working > group document. > > Before starting the the poll to see if we have consensus to make this a > working group document we need to do an IPR poll. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-chen-mpls-p2mp-ingress-protection? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. The response needs to be sent to the MPLS wg mailing list. The > documents will not advance to the next stage until a response > has been received from each author and each contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Ross > (as MPLS WG co-chair) > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- -- __________________________________ Best Regards, Sincerely Yours, Lei Liu, Ph.D -------------------- --089e010d8dd6a90c1804f00f6006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR associated with the draft.<= br>
Thanks,
Lei Liu (as co-author of this draft)


2014/1= /3 Ross Callon <rcallon@juniper.net>
Working Group,

The authors of draft-chen-mpls-p2mp-ingress-protection have told the
working group chairs that the draft is ready to be adopted as a working
group document.

Before starting the the poll to see if we have consensus to make this a
working group document we need to do an IPR poll.

This mail starts that IPR poll.

Are you aware of any IPR that applies to
draft-chen-mpls-p2mp-ingress-protection?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. The response needs to be sent to the MPLS wg mailing list. The
documents will not advance to the next stage until a response
has been received from each author and each contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks, Ross
(as MPLS WG co-chair)


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
--=A0
__________________________________
Best Regards,

Sincerely Yours,
Lei Liu, Ph.D
------= --------------

--089e010d8dd6a90c1804f00f6006-- From Alexander.Vainshtein@ecitele.com Wed Jan 15 21:35:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778C61AE4C7 for ; Wed, 15 Jan 2014 21:35:56 -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 e4omjf3WsoF6 for ; Wed, 15 Jan 2014 21:35:53 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) by ietfa.amsl.com (Postfix) with ESMTP id D3CF21AE4BE for ; Wed, 15 Jan 2014 21:35:52 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB531.eurprd03.prod.outlook.com (10.242.109.155) with Microsoft SMTP Server (TLS) id 15.0.851.11; Thu, 16 Jan 2014 05:35:39 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Thu, 16 Jan 2014 05:35:39 +0000 From: Alexander Vainshtein To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] mpls-in-udp entropy Thread-Index: AQHPEjRCieRBwKl/XESIAXm8KkwTF5qG07e6 Date: Thu, 16 Jan 2014 05:35:38 +0000 Message-ID: <75996b50f08c46b5b3809ee628dadcba@AM3PR03MB532.eurprd03.prod.outlook.com> References: Your message of "Wed, 15 Jan 2014 19:44:53 +0000." <5b0765246d204750a50e1aad52a3b72e@AM3PR03MB532.eurprd03.prod.outlook.com>, <201401152056.s0FKuBNT022977@maildrop2.v6ds.occnc.com> In-Reply-To: <201401152056.s0FKuBNT022977@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.66.126.123] x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(779001)(689001)(679001)(51704005)(189002)(199002)(377454003)(50986001)(46102001)(54356001)(53806001)(79102001)(49866001)(56776001)(76786001)(54316002)(76796001)(63696002)(47976001)(83322001)(19580395003)(80976001)(19580405001)(47736001)(33646001)(93136001)(81816001)(59766001)(92566001)(77982001)(76482001)(76576001)(87936001)(31966008)(74876001)(81686001)(4396001)(80022001)(47446002)(90146001)(74706001)(56816005)(15975445006)(81342001)(51856001)(2656002)(65816001)(74662001)(66066001)(85306002)(69226001)(87266001)(81542001)(83072002)(74502001)(74366001)(85852003)(74316001)(93516002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB531; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:109.66.126.123; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Cc: "mpls@ietf.org" Subject: Re: [mpls] mpls-in-udp entropy X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 05:35:56 -0000 Curtis, =0A= IMHO and FWIW it is preferable to allocate the entropy port from the Dynami= c/Private space.=0A= 14K values should suffice for any reasonable ECMP scenarios.=0A= =0A= My 2c,=0A= Sasha=0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Wednesday, January 15, 2014 10:56 PM=0A= To: Alexander Vainshtein=0A= Cc: erosen@cisco.com; mpls@ietf.org=0A= Subject: Re: [mpls] mpls-in-udp entropy=0A= =0A= In message <5b0765246d204750a50e1aad52a3b72e@AM3PR03MB532.eurprd03.prod.out= look.com>=0A= Alexander Vainshtein writes:=0A= =0A= > Eric,=0A= > Lots of thanks for a prompt and highly informative response.=0A= >=0A= > I have been actually thinking about the same thing, namely that the entro= py port should be the result of some hash over the label stack.=0A= >=0A= > If this is indeed the intention of the authors, it would make sense (at l= east, from my point of view) of saying so in the draft. There is no need to= make such a statement normative, but it would really help the readers (bot= h implementors and operators) to understand what it is about.=0A= >=0A= > Regards,=0A= > Sasha=0A= =0A= Avoiding the lower 8K of the port number space might not be a bad idea=0A= to avoid a return port being a WKP including the non-root WKP space=0A= used by X-Windows and other things.=0A= =0A= Curtis=0A= =0A= =0A= > ________________________________________=0A= > From: Eric Rosen =0A= > Sent: Wednesday, January 15, 2014 6:35 PM=0A= > To: Alexander Vainshtein=0A= > Cc: mpls@ietf.org=0A= > Subject: Re: mpls-in-udp entropy=0A= >=0A= > (Changed subject line and trimmed cc-list.)=0A= >=0A= > Sasha> I would like to understand whether this protocol can really result= in=0A= > Sasha> reasonable distribution of traffic. "Reasonable" means that (a) th= ere=0A= > Sasha> is sufficient entropy and (b) that the order in specific micro-flo= ws=0A= > Sasha> is preserved.=0A= >=0A= > I thought the intention was that the encapsulator would set the UDP sourc= e=0A= > port based upon the entropy of the packet being encapsulated. This only= =0A= > requires that the encapsulator know how to properly apply ECMP to the MPL= S=0A= > packet that is being encapsulated. That is, compute the hash that would = be=0A= > used to apply ECMP to the MPLS packet, and then map from that hash to a U= DP=0A= > source port.=0A= >=0A= > E.g., two MPLS packets with the same entropy label would get the same UDP= =0A= > source port, two MPLS packets with no entropy label but containing the sa= me=0A= > TCP flow would get the same source port, etc.=0A= >=0A= > Do you think there is a problem here?=0A= > _______________________________________________=0A= > mpls mailing list=0A= > mpls@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/mpls=0A= From loa@pi.nu Wed Jan 15 21:39:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787B91AE4CF for ; Wed, 15 Jan 2014 21:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 1lEQiinPzLg9 for ; Wed, 15 Jan 2014 21:39:10 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 46A1D1AE4BE for ; Wed, 15 Jan 2014 21:39:10 -0800 (PST) Received: from [192.168.1.3] (unknown [49.147.219.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 568AB180145E; Thu, 16 Jan 2014 06:38:53 +0100 (CET) Message-ID: <52D77069.2050405@pi.nu> Date: Thu, 16 Jan 2014 13:38:49 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" , mpls-forwarding co-authors Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] IPR poll on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 05:39:12 -0000 Working Group, we have just requested publication of draft-ietf-mpls-forwarding-04. Since the IPR poll on the individual document is fairly recent, we will do the final poll in parallel to the initial steps of post publication request steps. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-forwarding? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are three IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From michelg@upperside.fr Thu Jan 16 03:22:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501CD1AE2E7 for ; Thu, 16 Jan 2014 03:22:14 -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 cNHaKhV6RL0Z for ; Thu, 16 Jan 2014 03:22:11 -0800 (PST) Received: from smtp02.msg.oleane.net (smtp02.msg.oleane.net [62.161.4.2]) by ietfa.amsl.com (Postfix) with ESMTP id 14A511AE306 for ; Thu, 16 Jan 2014 03:22:10 -0800 (PST) Received: from MGosseDellM6800 ([195.6.217.229]) (authenticated) by smtp02.msg.oleane.net (MSA) with ESMTP id s0GBLuAA001013 for ; Thu, 16 Jan 2014 12:21:56 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Thu, 16 Jan 2014 12:21:55 +0100 Message-ID: <000a01cf12ad$29eb4380$7dc1ca80$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CF12B5.8BB306E0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8SrRWpRj217dRVQ2qYvdS7KrHilg== Content-Language: fr X-Backend: vm-smtp-sophos09 X-PMX-Spam: Probability=11% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.16.103624 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS SDN World Paris, from 18 to 21 March, 2014 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 11:22:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000B_01CF12B5.8BB306E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 2014 agenda will privilege operator and enterprises scenarios and testimonies. The main focus will be on Data Center Virtualization, especially overlays and WAN interconnection issues. A large session will be dedicated to the Segment Routing initiative, launched during the 2013 edition of the Congress. Other sessions will cover OpenFlow aspects, performance and traffic engineering issues and mobile SDN. More info.: http://www.uppersideconferences.com/index.htm ------=_NextPart_000_000B_01CF12B5.8BB306E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 2014 agenda will = privilege operator and enterprises scenarios and testimonies. 

The main focus will = be on Data Center Virtualization, especially overlays and WAN = interconnection issues. A large session will be dedicated to the Segment = Routing initiative, launched during the 2013 edition of the = Congress.

 

Other sessions will = cover OpenFlow aspects, performance and = traffic engineering issues and mobile SDN.

 

More info.: http://www.uppersideconferences.com/ind= ex.htm

<= /html> ------=_NextPart_000_000B_01CF12B5.8BB306E0-- From quintin.zhao@huawei.com Thu Jan 16 06:07:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C911AE357 for ; Thu, 16 Jan 2014 06:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.211 X-Spam-Level: * X-Spam-Status: No, score=1.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 fOfYooXUZDnW for ; Thu, 16 Jan 2014 06:07:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BD2611AE1CF for ; Thu, 16 Jan 2014 06:07:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCO25034; Thu, 16 Jan 2014 14:06:54 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 14:06:07 +0000 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, 16 Jan 2014 14:06:52 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Thu, 16 Jan 2014 06:06:43 -0800 From: Quintin zhao To: "mpls-chairs@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJp09VgggBEI8oCAAXgAAA== Date: Thu, 16 Jan 2014 14:06:43 +0000 Message-ID: <11208E03C9803E4CB4C3D898F153D6C030715989@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.221.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: [mpls] =?gb2312?b?16q3ojogSVBSIFBvbGwgb24gZHJhZnQtY2hlbi1tcGxz?= =?gb2312?b?LXAybXAtaW5ncmVzcy1wcm90ZWN0aW9u?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 14:07:09 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUnMgb3RoZXIgdGhhbiB0aG9zZSBkaXNjbG9zZWQuDQoN ClF1aW50aW4gKGFzIGEgY29udHJpYnV0b3Igb2YgdGhpcyBkcmFmdCkNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBSb3NzIENhbGxvbg0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDAzLCAyMDE0 IDg6NDkgQU0NClRvOiBtcGxzQGlldGYub3JnOyBkcmFmdC1jaGVuLW1wbHMtcDJtcC1pbmdyZXNz LXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcNCkNjOiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y Zw0KU3ViamVjdDogW21wbHNdIElQUiBQb2xsIG9uIGRyYWZ0LWNoZW4tbXBscy1wMm1wLWluZ3Jl c3MtcHJvdGVjdGlvbg0KDQpXb3JraW5nIEdyb3VwLA0KDQpUaGUgYXV0aG9ycyBvZiBkcmFmdC1j aGVuLW1wbHMtcDJtcC1pbmdyZXNzLXByb3RlY3Rpb24gaGF2ZSB0b2xkIHRoZSB3b3JraW5nIGdy b3VwIGNoYWlycyB0aGF0IHRoZSBkcmFmdCBpcyByZWFkeSB0byBiZSBhZG9wdGVkIGFzIGEgd29y a2luZyBncm91cCBkb2N1bWVudC4NCg0KQmVmb3JlIHN0YXJ0aW5nIHRoZSB0aGUgcG9sbCB0byBz ZWUgaWYgd2UgaGF2ZSBjb25zZW5zdXMgdG8gbWFrZSB0aGlzIGEgd29ya2luZyBncm91cCBkb2N1 bWVudCB3ZSBuZWVkIHRvIGRvIGFuIElQUiBwb2xsLg0KDQpUaGlzIG1haWwgc3RhcnRzIHRoYXQg SVBSIHBvbGwuDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJh ZnQtY2hlbi1tcGxzLXAybXAtaW5ncmVzcy1wcm90ZWN0aW9uPw0KDQpJZiBzbywgaGFzIHRoaXMg SVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2Vl IFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KSWYg eW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNl IHJlc3BvbmQgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBh cmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNl bnQgdG8gdGhlIE1QTFMgd2cgbWFpbGluZyBsaXN0LiBUaGUgZG9jdW1lbnRzIHdpbGwgbm90IGFk dmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZl ZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBlYWNoIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG9u IHRoZSBNUExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBv ciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91 IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4g Y29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KDQpUaGFua3MsIFJvc3MNCihhcyBNUExTIFdH IGNvLWNoYWlyKQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From Boris.Zhang@telus.com Thu Jan 16 06:47:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC571AE377 for ; Thu, 16 Jan 2014 06:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.24 X-Spam-Level: X-Spam-Status: No, score=-3.24 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_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 L1KDdJvSMByc for ; Thu, 16 Jan 2014 06:47:09 -0800 (PST) Received: from orkaan.nssi.telus.com (orkaan.nssi.telus.com [208.38.59.78]) by ietfa.amsl.com (Postfix) with ESMTP id 742401AE2FE for ; Thu, 16 Jan 2014 06:47:09 -0800 (PST) DomainKey-Signature: s=orkaan.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:CC:Date:Subject:Thread-Topic: Thread-Index:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:acceptlanguage:Content-Type: Content-Transfer-Encoding:MIME-Version; b=hOelvTV91zkJ69NfYJlL1VESJO+sg2ShvE0nrrJ3nqvEzIPEaofafc4l Vho43EJkJX4duqL67Xpld4n6O/0EIS+bhKPla85CdBIV4OglCcwuvdh9v B4t4CtHLVtT9OZCXMTfbucYd+5QGonyv29tttEZX9P290BPTeziFPNJhb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAMbv11KOP4Bp/2dsb2JhbABZgmohOKMumDOBCxZ0giUBAQEEAQEBNxkbBgUMBAIBCA0EBAEBHwkHJwsUCQgCBAENBQiHfAEMxDYTBI4dEAIBHjEHBoMegRQEiUeVSIspg0s X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="scan'208";a="283748438" Received: from unknown (HELO WP40057.corp.ads) ([142.63.128.105]) by orkaan-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 16 Jan 2014 14:46:55 +0000 Received: from wp40067.corp.ads ([::1]) by WP40057.corp.ads ([::1]) with mapi; Thu, 16 Jan 2014 09:46:24 -0500 From: Boris Zhang To: "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Date: Thu, 16 Jan 2014 09:46:23 -0500 Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJp09VgggBDzhMCAAZiVMA== Message-ID: <3CC752382EB88F48ADAC4AF9F478A153168AE22B9A@WP40067.corp.ads> References: <5316A0AB3C851246A7CA5758973207D445C30FD1@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C30FD1@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 16 Jan 2014 06:51:14 -0800 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 14:47:11 -0000 Working-Group, I am not aware of any related IPR. B regards, Boris Zhang (Contributor of this draft) -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, January 03, 2014 8:49 AM To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the workin= g group chairs that the draft is ready to be adopted as a working group doc= ument. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-ingress-prote= ction? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From agmalis@gmail.com Thu Jan 16 07:14:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A401AE4C5 for ; Thu, 16 Jan 2014 07:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm2R-eBSolwb for ; Thu, 16 Jan 2014 07:14:53 -0800 (PST) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id EEC8D1AE4C0 for ; Thu, 16 Jan 2014 07:14:52 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id d4so1911296qej.10 for ; Thu, 16 Jan 2014 07:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RqxO7YFQuQwEtaubJgH6aAZZ3UDO8bm1wu2pVq0fJGA=; b=oBlsw4PEa8SJR0nHKKMd2VEvzMS8BYyI2DzesQ/Jzzkxy4Dp0nGbJSW28uKL48xz81 7gKzbwL56ZPYMZ5mt2QFWKXQkLPXelGk34S0OpTO+nmnaiWkCYJBl2HacqB+nkuz2EM6 5KV/S6H3ChAYS5PDPRlbz5w3/caSg6NhKVWJ8sr05IAYu1U8y7dPsRKGcNT3uyIn3O4n a0u6RdqXNltB116LeruwzG+84c2Dat9Y9tVRh3zvl8HheWrL1u/9yHYGc7ucSlONylMf NhfWh/2cds5waXfvWhASg9eJikModBWGLwlOpq1YutmkKcLYH50ZPiSuhisNaqPnrX4e eZqg== X-Received: by 10.224.166.70 with SMTP id l6mr16749680qay.25.1389885280694; Thu, 16 Jan 2014 07:14:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.120.130 with HTTP; Thu, 16 Jan 2014 07:14:19 -0800 (PST) In-Reply-To: <52D77069.2050405@pi.nu> References: <52D77069.2050405@pi.nu> From: "Andrew G. Malis" Date: Thu, 16 Jan 2014 10:14:19 -0500 Message-ID: To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] IPR poll on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 15:14:55 -0000 Loa, I am not aware of any non-disclosed IPR with regards to this draft. Cheers, Andy On Thu, Jan 16, 2014 at 12:38 AM, Loa Andersson wrote: > Working Group, > > we have just requested publication of draft-ietf-mpls-forwarding-04. > > Since the IPR poll on the individual document is fairly recent, we will > do the final poll in parallel to the initial steps of post publication > request steps. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-forwarding? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are three IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huaimo.chen@huawei.com Thu Jan 16 07:32:15 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9A01AE45E for ; Thu, 16 Jan 2014 07:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 XN6c-hYtPz5l for ; Thu, 16 Jan 2014 07:32:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3F71AE377 for ; Thu, 16 Jan 2014 07:32:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAA28636; Thu, 16 Jan 2014 15:31:59 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 15:31:12 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 15:31:59 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Thu, 16 Jan 2014 07:31:46 -0800 From: Huaimo Chen To: "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJp09VgggBDzhMCAAZiVMIAAC2ZA Date: Thu, 16 Jan 2014 15:31:46 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C3141D@SJCEML701-CHM.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D445C30FD1@SJCEML701-CHM.china.huawei.com> <3CC752382EB88F48ADAC4AF9F478A153168AE22B9A@WP40067.corp.ads> In-Reply-To: <3CC752382EB88F48ADAC4AF9F478A153168AE22B9A@WP40067.corp.ads> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 15:32:15 -0000 I am not aware of any related IPRs other than those disclosed. Best Regards, Huaimo (as a author of the draft) -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, January 03, 2014 8:49 AM To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the workin= g group chairs that the draft is ready to be adopted as a working group doc= ument. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-ingress-prote= ction? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From yshen@juniper.net Thu Jan 16 08:37:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55BC1AE106 for ; Thu, 16 Jan 2014 08:37:10 -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 F6l85OvqAVZe for ; Thu, 16 Jan 2014 08:37:08 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id BCC361ADFC9 for ; Thu, 16 Jan 2014 08:37:08 -0800 (PST) Received: from mail110-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Thu, 16 Jan 2014 16:36:56 +0000 Received: from mail110-ch1 (localhost [127.0.0.1]) by mail110-ch1-R.bigfish.com (Postfix) with ESMTP id 695D0420174; Thu, 16 Jan 2014 16:36:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzc2hdchz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h9a9j1155h) Received-SPF: pass (mail110-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=yshen@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(13464003)(164054003)(189002)(199002)(377454003)(87936001)(74876001)(81342001)(87266001)(74706001)(47446002)(31966008)(81686001)(76576001)(1941001)(15975445006)(74366001)(85852003)(90146001)(74316001)(74502001)(85306002)(83072002)(2656002)(56816005)(69226001)(4396001)(74662001)(76786001)(47976001)(66066001)(65816001)(63696002)(51856001)(83322001)(80976001)(19580395003)(19580405001)(47736001)(53806001)(79102001)(54356001)(50986001)(49866001)(46102001)(54316002)(2201001)(92566001)(80022001)(76796001)(59766001)(77982001)(76482001)(56776001)(81542001)(81816001)(33646001)(93136001)(93516002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB632; H:BY2PR05MB728.namprd05.prod.outlook.com; CLIP:66.129.241.14; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail110-ch1 (localhost.localdomain [127.0.0.1]) by mail110-ch1 (MessageSwitch) id 1389890214116829_23892; Thu, 16 Jan 2014 16:36:54 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail110-ch1.bigfish.com (Postfix) with ESMTP id 0ED3E80047; Thu, 16 Jan 2014 16:36:54 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 16 Jan 2014 16:36:51 +0000 Received: from BY2PR05MB632.namprd05.prod.outlook.com (10.141.218.23) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 16 Jan 2014 16:36:46 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB632.namprd05.prod.outlook.com (10.141.218.23) with Microsoft SMTP Server (TLS) id 15.0.851.15; Thu, 16 Jan 2014 16:36:43 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0842.003; Thu, 16 Jan 2014 16:36:44 +0000 From: Yimin Shen To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJqHoN7w Date: Thu, 16 Jan 2014 16:36:43 +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: [66.129.241.14] x-forefront-prvs: 0093C80C01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 16:37:11 -0000 I am not aware of any IPR related to this draft. Thanks, /Yimin -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, January 03, 2014 11:49 AM To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the workin= g group chairs that the draft is ready to be adopted as a working group doc= ument. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-ingress-prote= ction? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From joelja@bogus.com Thu Jan 16 09:07:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F6A1AE375; Thu, 16 Jan 2014 09:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 b_F2I8GoTVFm; Thu, 16 Jan 2014 09:07:10 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9783C1AE364; Thu, 16 Jan 2014 09:07:10 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0GH6lff037145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Jan 2014 17:06:48 GMT (envelope-from joelja@bogus.com) Message-ID: <52D811A2.9070606@bogus.com> Date: Thu, 16 Jan 2014 09:06:42 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: "Eggert, Lars" , Joel Halpern References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> In-Reply-To: <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cuuPvSot3F6CMwfoP6dclG7jGku0IKmaJ" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 16 Jan 2014 17:06:48 +0000 (UTC) Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 17:07:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cuuPvSot3F6CMwfoP6dclG7jGku0IKmaJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/14/14, 7:29 AM, Eggert, Lars wrote: > Hi, >=20 > On 2014-1-14, at 16:23, Joel M. Halpern wrote: >> Isn't that basically the problem of the inner traffic sender, not >> the problem of the tunnel that is carrying the traffic? >=20 > no, because the sender of the inner traffic may be blasting some L2 > traffic, for an L2 where that is OK behavior. But that traffic is now > being encapsulated inside UDP and can hence go anywhere on the net > *without the sender being aware of this*. >=20 >> Asking tunnel's to solve the problem of applications with >> undesirable behavior seems backwards. >=20 > It is the *tunnel* that performs the encapsulation and allows that > traffic to go places it couldn't before. And so it's the tunnel's > responsibility to make sure that the traffic it injects into the > Internet complies with the BCPs we have on congestion control. There seems assertion on the part of transport that tunnel endpoints should be aware of congestion on intermediate hops. This seems to be the assertion here, it certainly is with respect to AMT. This certainly not a property that we demand of routers in other contexts. my observations These tunnels are stateless The endpoints not the encapsulators have visibility into the end-to-end loss latency properties of the path. the encapsulator is an intermediate hop, similar to any other router in the path. > Lars >=20 --cuuPvSot3F6CMwfoP6dclG7jGku0IKmaJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLYEaIACgkQ8AA1q7Z/VrJmNQCfTxdzgsVe2VFYTOvDoKBaBoJE FNEAnArIl+tSQHM/GJIWvWRK1PTdvZP0 =mp6l -----END PGP SIGNATURE----- --cuuPvSot3F6CMwfoP6dclG7jGku0IKmaJ-- From lars@netapp.com Thu Jan 16 09:20:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A011AE3D3; Thu, 16 Jan 2014 09:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 885b57WWSJ5W; Thu, 16 Jan 2014 09:20:03 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1C41AE3B2; Thu, 16 Jan 2014 09:20:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,668,1384329600"; d="asc'?scan'208";a="96430293" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 16 Jan 2014 09:19:51 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Thu, 16 Jan 2014 09:19:51 -0800 From: "Eggert, Lars" To: Joel Jaeggli Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAD31WAgABWjoCAAHXQgIAAN0wAgAEJtoCAACSXAIAAC26AgAAH1ACAABCuAIAAAQqAgAABkYCAAz/MAIAAA6eA Date: Thu, 16 Jan 2014 17:19:50 +0000 Message-ID: <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> In-Reply-To: <52D811A2.9070606@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_2C0E3627-B95F-40C6-B47D-E6E2ED1733A4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 17:20:04 -0000 --Apple-Mail=_2C0E3627-B95F-40C6-B47D-E6E2ED1733A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 2014-1-16, at 18:06, joel jaeggli wrote: > These tunnels are stateless yep. (But they don't have to be.) > The endpoints not the encapsulators have visibility into the > end-to-end loss latency properties of the path. Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 = domains - where not reacting to congestion may be OK - can now go over = the wider Internet, where this is not OK. I'd be great if those apps would change. But in the meantime, it's the = duty of the encapsulator - who enables this traffic to break out of an = L2 domain and go over the wider net - to make sure the traffic it emits = conforms to our BCPs. > the encapsulator is an intermediate hop, similar to any other router > in the path. It's not. For the rest of the network, that encapsulator is = indistinguishable from any other app that sends UDP traffic. UDP is a transport-layer protocol, and we have practices how it is to be = used on the net. If you want to use it for encapsulation, you bind = yourself to these BCPs. Look at it the other way: if transport area folks would want to send = MPLS packets into the network in some problematic way, I'm sure the = routing and ops folks would not be amused. Lars --Apple-Mail=_2C0E3627-B95F-40C6-B47D-E6E2ED1733A4 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----- iQCVAwUBUtgUs9ZcnpRveo1xAQLOoQQAu4C8E4L95wEG/1bGt2CrmxDFf23uBFzW 6+WaxtQdyehM64Cy1IKxfugZHGcz7dhylCuAzhBOhhMRgYdTsrwAqhKhuckOddtC 87DR0Ywq31R5Vib8EfqTMk9t5ekZqtskMG3zdkQVBiytHLNZtLRYqXx+71u4Hh+R YHzHFyO2CKE= =UzEf -----END PGP SIGNATURE----- --Apple-Mail=_2C0E3627-B95F-40C6-B47D-E6E2ED1733A4-- From stbryant@cisco.com Thu Jan 16 09:35:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF0E1AE3B2; Thu, 16 Jan 2014 09:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 oTcPCmXfVirS; Thu, 16 Jan 2014 09:35:40 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 016791AE171; Thu, 16 Jan 2014 09:35:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1647; q=dns/txt; s=iport; t=1389893728; x=1391103328; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=j48mynpc5hG6DbeSEhHkM39BT3WuQm+m2pQHoMW9puk=; b=fd+D/u2vKK6V/LJdKiDNdm+evxV5El/IZiWh/SkFXMPH6Z75L+ybPYU0 bSoDz514bBYlos56MzMtfjnr5fclECnY6UB7j5vdwYpDpxGvkMy1E/Q4t lCJli0ROg1ewA+qBBaINJ+famc6ZkFCY7D946IzPxM1V/Zo+tOkPXxBDE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAF8X2FKQ/khL/2dsb2JhbABZgwu8GYEOFnSCJQEBAQQ4QAEQCxgJFgQLCQMCAQIBRQYBDAEFAgEBiADEaxeOJ1gHhDgBA5ghkheBb4E+gWg X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="scan'208";a="3729242" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 16 Jan 2014 17:35:27 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0GHZQa5022059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jan 2014 17:35:27 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0GHZPSY003228; Thu, 16 Jan 2014 17:35:25 GMT Message-ID: <52D8185D.1010902@cisco.com> Date: Thu, 16 Jan 2014 17:35:25 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Eggert, Lars" , Joel Jaeggli References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> In-Reply-To: <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 17:35:41 -0000 On 16/01/2014 17:19, Eggert, Lars wrote: > Hi, > > On 2014-1-16, at 18:06, joel jaeggli wrote: >> These tunnels are stateless > yep. (But they don't have to be.) Ah, they do if they are to scale. State at speed is really hard. The sort of systems we are talking about do things like pipeline counters and it is loooooots of packets later before the counter is actually incremented. >> The endpoints not the encapsulators have visibility into the >> end-to-end loss latency properties of the path. > Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 domains - where not reacting to congestion may be OK - can now go over the wider Internet, where this is not OK. > > I'd be great if those apps would change. But in the meantime, it's the duty of the encapsulator - who enables this traffic to break out of an L2 domain and go over the wider net - to make sure the traffic it emits conforms to our BCPs. > >> the encapsulator is an intermediate hop, similar to any other router >> in the path. > It's not. For the rest of the network, that encapsulator is indistinguishable from any other app that sends UDP traffic. > > UDP is a transport-layer protocol, and we have practices how it is to be used on the net. If you want to use it for encapsulation, you bind yourself to these BCPs. > > Look at it the other way: if transport area folks would want to send MPLS packets into the network in some problematic way, I'm sure the routing and ops folks would not be amused. The root cause of the problem here is that UDP, has bifurcated into a general purpose encapsulation. Stewart From loa@pi.nu Thu Jan 16 09:58:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6E81A1F3D for ; Thu, 16 Jan 2014 09:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 EsxwAg6k7j6g for ; Thu, 16 Jan 2014 09:57:59 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 03A7E1A1F1F for ; Thu, 16 Jan 2014 09:57:58 -0800 (PST) Received: from [192.168.1.6] (unknown [112.208.61.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 02A01180150F; Thu, 16 Jan 2014 18:57:29 +0100 (CET) Message-ID: <52D81D81.4010708@pi.nu> Date: Fri, 17 Jan 2014 01:57:21 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Andrew G. Malis" References: <52D77069.2050405@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] IPR poll on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 17:58:02 -0000 Andy, Thanks - I suspect that you and everyone have spotted the copy and paste error in this IPR poll. I claim that there are three IPR disclosures against this document. This is not right - there are no disclosures against this document. /Loa On 2014-01-16 23:14, Andrew G. Malis wrote: > Loa, > > I am not aware of any non-disclosed IPR with regards to this draft. > > Cheers, > Andy > > On Thu, Jan 16, 2014 at 12:38 AM, Loa Andersson wrote: >> Working Group, >> >> we have just requested publication of draft-ietf-mpls-forwarding-04. >> >> Since the IPR poll on the individual document is fairly recent, we will >> do the final poll in parallel to the initial steps of post publication >> request steps. >> >> This mail starts that IPR poll. >> >> Are you aware of any IPR that applies to draft-ietf-mpls-forwarding? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> Currently there are three IPR disclosures that relates to this document. >> >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >> document will not advance to the next stage until a response has been >> received from each author and contributor. >> >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >> >> Thanks, Loa >> (as MPLS WG co-chair) >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From agmalis@gmail.com Thu Jan 16 10:16:48 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7601A1F00 for ; Thu, 16 Jan 2014 10:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LaF6AcmmkxL for ; Thu, 16 Jan 2014 10:16:43 -0800 (PST) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 15F891A16F0 for ; Thu, 16 Jan 2014 10:16:43 -0800 (PST) Received: by mail-qe0-f42.google.com with SMTP id b4so2951810qen.29 for ; Thu, 16 Jan 2014 10:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WwM8WdTwVlFC7n/I4b156NwU1lTeM6yIBaAT1Sbl47o=; b=GBzgSY2osTG8NdaQqoP78NT2xjOGP5eYT1dt4fcogep047mmnZgmvcr9pvIpIWBaSd LG99yeXsGnw9Q6DwPrjF/OrjGQMdygtq27W7wC9putm+VBMsj7O7mTnt4VdpDzUka88X CD5kDWKrPRRLNEJq0MOlKuwO1LjiFebDDTFdWBeEnLzE1+Gz5pSS3S77p2WtzK0xyWo5 tWW7zhTN9CPns5QACvw3vvolsTb5X57l/R6Pa0/JecD5HNxwG6jZB4fmADzHsaapqpbg nwkQ2X3a4POUc5RteUw14JJ2p5Qjx9cTc0v6kiYZFinDIvNH642HIQmMuUEzWJAN0T5F oAiQ== X-Received: by 10.224.151.142 with SMTP id c14mr2322027qaw.70.1389896190783; Thu, 16 Jan 2014 10:16:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.120.130 with HTTP; Thu, 16 Jan 2014 10:16:10 -0800 (PST) In-Reply-To: <52D81D81.4010708@pi.nu> References: <52D77069.2050405@pi.nu> <52D81D81.4010708@pi.nu> From: "Andrew G. Malis" Date: Thu, 16 Jan 2014 13:16:10 -0500 Message-ID: To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] IPR poll on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 18:16:48 -0000 Loa, That's what I thought, but just in case, I worded my response as I did. Cheers, Andy On Thu, Jan 16, 2014 at 12:57 PM, Loa Andersson wrote: > Andy, > > Thanks - I suspect that you and everyone have spotted the copy and > paste error in this IPR poll. > > I claim that there are three IPR disclosures against this document. > This is not right - there are no disclosures against this document. > > /Loa > > > On 2014-01-16 23:14, Andrew G. Malis wrote: >> >> Loa, >> >> I am not aware of any non-disclosed IPR with regards to this draft. >> >> Cheers, >> Andy >> >> On Thu, Jan 16, 2014 at 12:38 AM, Loa Andersson wrote: >>> >>> Working Group, >>> >>> we have just requested publication of draft-ietf-mpls-forwarding-04. >>> >>> Since the IPR poll on the individual document is fairly recent, we will >>> do the final poll in parallel to the initial steps of post publication >>> request steps. >>> >>> This mail starts that IPR poll. >>> >>> Are you aware of any IPR that applies to draft-ietf-mpls-forwarding? >>> >>> If so, has this IPR been disclosed in compliance with IETF IPR rules >>> (see RFCs 3979, 4879, 3669 and 5378 for more details). >>> >>> Currently there are three IPR disclosures that relates to this document. >>> >>> If you are listed as a document author or contributor please respond to >>> this email regardless of whether or not you are aware of any relevant >>> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >>> document will not advance to the next stage until a response has been >>> received from each author and contributor. >>> >>> If you are on the MPLS WG email list but are not listed as an author or >>> contributor, then please explicitly respond only if you are aware of any >>> IPR that has not yet been disclosed in conformance with IETF rules. >>> >>> Thanks, Loa >>> (as MPLS WG co-chair) >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From rjsparks@nostrum.com Thu Jan 16 10:58:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD331A1F79; Thu, 16 Jan 2014 10:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 mt6NNQ3jn7HH; Thu, 16 Jan 2014 10:58:31 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 54DDB1A1F72; Thu, 16 Jan 2014 10:58:31 -0800 (PST) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0GIwIaw001256 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 16 Jan 2014 12:58:19 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <52D82BAA.1010007@nostrum.com> Date: Thu, 16 Jan 2014 12:57:46 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: General Area Review Team , mpls@ietf.org, draft-ietf-mpls-moving-iana-registries@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism) Subject: [mpls] Gen-Art LC review of draft-ietf-mpls-moving-iana-registries X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 18:58:32 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-moving-iana-registries Reviewer: Robert Sparks Review Date: 16-Jan-2014 IETF LC End Date: 17-Jan-2014 IESG Telechat date: 23-Jan-2014 Summary: This document is ready for publication as Proposed Standard From huaimo.chen@huawei.com Thu Jan 16 11:45:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A321A1F54 for ; Thu, 16 Jan 2014 11:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 bgpzr9FJshOv for ; Thu, 16 Jan 2014 11:45:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5793A1AC404 for ; Thu, 16 Jan 2014 11:45:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAA43071; Thu, 16 Jan 2014 19:45:05 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 19:44:18 +0000 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; Thu, 16 Jan 2014 19:45:04 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Thu, 16 Jan 2014 11:44:53 -0800 From: Huaimo Chen To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJqH0GJg Date: Thu, 16 Jan 2014 19:44:52 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C31542@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.245.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 19:45:23 -0000 I am not aware of any IPR that has not been disclosed. There is one IPR tha= t has been disclosed and being processed by the IETF disclosure system. The= application number is 61,828,099. Best Regards, Huaimo -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Friday, January 03, 2014 11:49 AM To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Working Group, The authors of draft-chen-mpls-p2mp-ingress-protection have told the workin= g group chairs that the draft is ready to be adopted as a working group doc= ument. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-ingress-prote= ction? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) From internet-drafts@ietf.org Thu Jan 16 11:47:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172351A1F54; Thu, 16 Jan 2014 11:47: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 1nzELnfiCxDY; Thu, 16 Jan 2014 11:47:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1108E1A1F6F; Thu, 16 Jan 2014 11:47:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140116194744.8635.93327.idtracker@ietfa.amsl.com> Date: Thu, 16 Jan 2014 11:47:44 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-extended-admin-group-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 19:47:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Extended Administrative Groups in MPLS-TE Author : Eric Osborne Filename : draft-ietf-mpls-extended-admin-group-01.txt Pages : 6 Date : 2014-01-16 Abstract: This document provides additional administrative groups (sometimes referred to as "link colors") to the IGP extensions for MPLS-TE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-extended-admin-group/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-extended-admin-group-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-extended-admin-group-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mjork@juniper.net Thu Jan 16 13:54:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850141AD672 for ; Thu, 16 Jan 2014 13:54:39 -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 ny56sWdiUDCf for ; Thu, 16 Jan 2014 13:54:37 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id F0D501AC4AB for ; Thu, 16 Jan 2014 13:54:36 -0800 (PST) Received: from mail57-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.22; Thu, 16 Jan 2014 21:54:24 +0000 Received: from mail57-am1 (localhost [127.0.0.1]) by mail57-am1-R.bigfish.com (Postfix) with ESMTP id 1E79B80205; Thu, 16 Jan 2014 21:54:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzc2hdchz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h9a9j1155h) Received-SPF: pass (mail57-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=mjork@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(51704005)(377454003)(164054003)(199002)(189002)(13464003)(15975445006)(81686001)(33646001)(81816001)(79102001)(56776001)(80976001)(46102001)(77982001)(59766001)(66066001)(49866001)(47736001)(80022001)(47976001)(50986001)(63696002)(4396001)(65816001)(54356001)(54316002)(76482001)(19580395003)(51856001)(19580405001)(83322001)(53806001)(76796001)(76786001)(76576001)(77096001)(1941001)(85852003)(83072002)(92566001)(2201001)(93136001)(74706001)(31966008)(47446002)(74502001)(74662001)(90146001)(93516002)(56816005)(2656002)(81542001)(87936001)(81342001)(74316001)(74366001)(85306002)(87266001)(69226001)(74876001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB628; H:BLUPR05MB230 Received: from mail57-am1 (localhost.localdomain [127.0.0.1]) by mail57-am1 (MessageSwitch) id 1389909261587374_18271; Thu, 16 Jan 2014 21:54:21 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.242]) by mail57-am1.bigfish.com (Postfix) with ESMTP id 81E713A004B; Thu, 16 Jan 2014 21:54:21 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 16 Jan 2014 21:54:21 +0000 Received: from BLUPR05MB628.namprd05.prod.outlook.com (10.141.204.156) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 16 Jan 2014 21:54:21 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com (10.255.191.20) by BLUPR05MB628.namprd05.prod.outlook.com (10.141.204.156) with Microsoft SMTP Server (TLS) id 15.0.851.15; Thu, 16 Jan 2014 21:54:19 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.161]) by BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.161]) with mapi id 15.00.0851.011; Thu, 16 Jan 2014 21:54:19 +0000 From: Markus Jork To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-ingress-protection Thread-Index: AQHPCKO/xRT1pWwSv0iFK3jtHYlCoJqH+O7g Date: Thu, 16 Jan 2014 21:54:18 +0000 Message-ID: <5aeb23785cdd4cb5a3e14ec6db08cc43@BLUPR05MB230.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0093C80C01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 21:54:39 -0000 I am not aware of any IPR related to this draft. -Markus (contributor to the draft) > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: Friday, January 03, 2014 11:49 AM > To: mpls@ietf.org; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org > Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-ingress-protection >=20 > Working Group, >=20 > The authors of draft-chen-mpls-p2mp-ingress-protection have told the > working group chairs that the draft is ready to be adopted as a working > group document. >=20 > Before starting the the poll to see if we have consensus to make this a > working group document we need to do an IPR poll. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to > draft-chen-mpls-p2mp-ingress-protection? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. The response needs to be sent to the MPLS wg mailing list. The > documents will not advance to the next stage until a response > has been received from each author and each contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Ross > (as MPLS WG co-chair) >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From rcallon@juniper.net Thu Jan 16 14:32:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665891A1F76; Thu, 16 Jan 2014 14:32:41 -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 XQ3yua-8N6Xc; Thu, 16 Jan 2014 14:32:39 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 46EE61A1F62; Thu, 16 Jan 2014 14:32:38 -0800 (PST) Received: from mail136-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE021.bigfish.com (10.43.70.78) with Microsoft SMTP Server id 14.1.225.22; Thu, 16 Jan 2014 22:32:26 +0000 Received: from mail136-ch1 (localhost [127.0.0.1]) by mail136-ch1-R.bigfish.com (Postfix) with ESMTP id 8B542C0116; Thu, 16 Jan 2014 22:32:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(z579ehz98dI9371I936eI15bfK542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h9a9j1155h) Received-SPF: pass (mail136-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(51704005)(377454003)(377424004)(55674002)(24454002)(199002)(189002)(13464003)(81686001)(33646001)(81816001)(79102001)(56776001)(80976001)(46102001)(77982001)(59766001)(66066001)(49866001)(47736001)(80022001)(47976001)(50986001)(63696002)(4396001)(65816001)(54356001)(54316002)(76482001)(19580395003)(51856001)(19580405001)(83322001)(53806001)(76796001)(76786001)(76576001)(85852003)(83072002)(92566001)(93136001)(74706001)(31966008)(47446002)(74502001)(74662001)(90146001)(93516002)(56816005)(2656002)(81542001)(87936001)(81342001)(74316001)(74366001)(85306002)(87266001)(69226001)(74876001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail136-ch1 (localhost.localdomain [127.0.0.1]) by mail136-ch1 (MessageSwitch) id 1389911544490974_30073; Thu, 16 Jan 2014 22:32:24 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail136-ch1.bigfish.com (Postfix) with ESMTP id 707C938004A; Thu, 16 Jan 2014 22:32:24 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 16 Jan 2014 22:32:24 +0000 Received: from CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 16 Jan 2014 22:32:23 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) with Microsoft SMTP Server (TLS) id 15.0.851.11; Thu, 16 Jan 2014 22:32:20 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0851.011; Thu, 16 Jan 2014 22:32:20 +0000 From: Ross Callon To: "Eggert, Lars" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81jtn8uxkZO2EiBZeT7DEf4ppp6pziAgAK2KYCAAFQ7gIAAckaAgAAJRICAAAZDAIAD31WAgABWkACAAHXPgIAAN0wAgAEJtoCAACSWAIAAC2+AgAAH1ACAABCvgIAAAQmAgAABlACAAz/IAIAAA6wAgABUpZA= Date: Thu, 16 Jan 2014 22:32:19 +0000 Message-ID: <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> In-Reply-To: <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-forefront-prvs: 0093C80C01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "EXT - joelja@bogus.com" , "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 22:32:41 -0000 >> These tunnels are stateless > > yep. (But they don't have to be.) The tunnels strictly speaking do not have to be stateless. However, if you = want routers to actually implement them, and you want to scale in both forw= arding speed and number of tunnels, then yes they do have to be stateless.= =20 Ross (speaking only as an individual contributor)=20 -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: Thursday, January 16, 2014 12:20 PM To: EXT - joelja@bogus.com Cc: mpls@ietf.org; IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Hi, On 2014-1-16, at 18:06, joel jaeggli wrote: > These tunnels are stateless yep. (But they don't have to be.) > The endpoints not the encapsulators have visibility into the > end-to-end loss latency properties of the path. Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 domai= ns - where not reacting to congestion may be OK - can now go over the wider= Internet, where this is not OK. I'd be great if those apps would change. But in the meantime, it's the duty= of the encapsulator - who enables this traffic to break out of an L2 domai= n and go over the wider net - to make sure the traffic it emits conforms to= our BCPs. > the encapsulator is an intermediate hop, similar to any other router > in the path. It's not. For the rest of the network, that encapsulator is indistinguishab= le from any other app that sends UDP traffic. UDP is a transport-layer protocol, and we have practices how it is to be us= ed on the net. If you want to use it for encapsulation, you bind yourself t= o these BCPs. Look at it the other way: if transport area folks would want to send MPLS p= ackets into the network in some problematic way, I'm sure the routing and o= ps folks would not be amused. Lars From l.wood@surrey.ac.uk Thu Jan 16 17:20:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9D11AC421; Thu, 16 Jan 2014 17:20: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 XiYWqPUW1Yja; Thu, 16 Jan 2014 17:20:49 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6369E1A9313; Thu, 16 Jan 2014 17:20:48 -0800 (PST) Received: from [195.245.231.67:38745] by server-7.bemta-5.messagelabs.com id B3/5E-04824-36588D25; Fri, 17 Jan 2014 01:20:35 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-7.tower-82.messagelabs.com!1389921634!28548228!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26895 invoked from network); 17 Jan 2014 01:20:34 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-7.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 17 Jan 2014 01:20:34 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 17 Jan 2014 01:20:34 +0000 From: To: , Date: Fri, 17 Jan 2014 01:19:41 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81jtn8uxkZO2EiBZeT7DEf4ppp6pziAgAK2KYCAAFQ7gIAAckaAgAAJRICAAAZDAIAD31WAgABWkACAAHXPgIAAN0wAgAEJtoCAACSWAIAAC2+AgAAH1ACAABCvgIAAAQmAgAABlACAAz/IAIAAA6wAgABUpZCAADFtow== Message-ID: <290E20B455C66743BE178C5C84F1240847E63346CE@EXMB01CMS.surrey.ac.uk> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com>, <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 01:20:52 -0000 Surely you mean minimised state? The tunnels have to know where the other tunnel endpoint is - state. This i= s distinct from having a congestion-aware state machine that e.g. TCP inclu= des... Lloyd Wood http://about.me/lloydwood ________________________________________ From: mpls [mpls-bounces@ietf.org] On Behalf Of Ross Callon [rcallon@junipe= r.net] Sent: 16 January 2014 22:32 To: Eggert, Lars Cc: EXT - joelja@bogus.com; mpls@ietf.org; IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard >> These tunnels are stateless > > yep. (But they don't have to be.) The tunnels strictly speaking do not have to be stateless. However, if you = want routers to actually implement them, and you want to scale in both forw= arding speed and number of tunnels, then yes they do have to be stateless. Ross (speaking only as an individual contributor) -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: Thursday, January 16, 2014 12:20 PM To: EXT - joelja@bogus.com Cc: mpls@ietf.org; IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Hi, On 2014-1-16, at 18:06, joel jaeggli wrote: > These tunnels are stateless yep. (But they don't have to be.) > The endpoints not the encapsulators have visibility into the > end-to-end loss latency properties of the path. Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 domai= ns - where not reacting to congestion may be OK - can now go over the wider= Internet, where this is not OK. I'd be great if those apps would change. But in the meantime, it's the duty= of the encapsulator - who enables this traffic to break out of an L2 domai= n and go over the wider net - to make sure the traffic it emits conforms to= our BCPs. > the encapsulator is an intermediate hop, similar to any other router > in the path. It's not. For the rest of the network, that encapsulator is indistinguishab= le from any other app that sends UDP traffic. UDP is a transport-layer protocol, and we have practices how it is to be us= ed on the net. If you want to use it for encapsulation, you bind yourself t= o these BCPs. Look at it the other way: if transport area folks would want to send MPLS p= ackets into the network in some problematic way, I'm sure the routing and o= ps folks would not be amused. Lars _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From l.wood@surrey.ac.uk Thu Jan 16 19:06:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F691ADE87; Thu, 16 Jan 2014 19:06:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 TjEAOtZQdtJa; Thu, 16 Jan 2014 19:06:34 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id 3A20A1ADE86; Thu, 16 Jan 2014 19:06:33 -0800 (PST) Received: from [85.158.136.51:60836] by server-1.bemta-5.messagelabs.com id 28/01-21065-D2E98D25; Fri, 17 Jan 2014 03:06:21 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-16.tower-49.messagelabs.com!1389927980!23311593!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26557 invoked from network); 17 Jan 2014 03:06:20 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-16.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 17 Jan 2014 03:06:20 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 17 Jan 2014 03:06:20 +0000 From: To: , , Date: Fri, 17 Jan 2014 03:03:05 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8S4Wu6DFHO19nLS4OJGfloEdinxgATzjW0 Message-ID: <290E20B455C66743BE178C5C84F1240847E63346CF@EXMB01CMS.surrey.ac.uk> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com>, <52D8185D.1010902@cisco.com> In-Reply-To: <52D8185D.1010902@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 03:06:37 -0000 There's an opportunity to define a simple generic IPv6 encapsulating mechan= ism a la UDP, but with a payload checksum of varying coverage (header only, partial payload, = full payload) and with the (stronger than UDP) checksum placed at the end of the packet. Lloyd Wood http://about.me/lloydwood ________________________________________ From: ietf [ietf-bounces@ietf.org] On Behalf Of Stewart Bryant [stbryant@ci= sco.com] Sent: 16 January 2014 17:35 To: Eggert, Lars; Joel Jaeggli Cc: mpls@ietf.org; IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard On 16/01/2014 17:19, Eggert, Lars wrote: > Hi, > > On 2014-1-16, at 18:06, joel jaeggli wrote: >> These tunnels are stateless > yep. (But they don't have to be.) Ah, they do if they are to scale. State at speed is really hard. The sort of systems we are talking about do things like pipeline counters and it is loooooots of packets later before the counter is actually incremented. >> The endpoints not the encapsulators have visibility into the >> end-to-end loss latency properties of the path. > Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 dom= ains - where not reacting to congestion may be OK - can now go over the wid= er Internet, where this is not OK. > > I'd be great if those apps would change. But in the meantime, it's the du= ty of the encapsulator - who enables this traffic to break out of an L2 dom= ain and go over the wider net - to make sure the traffic it emits conforms = to our BCPs. > >> the encapsulator is an intermediate hop, similar to any other router >> in the path. > It's not. For the rest of the network, that encapsulator is indistinguish= able from any other app that sends UDP traffic. > > UDP is a transport-layer protocol, and we have practices how it is to be = used on the net. If you want to use it for encapsulation, you bind yourself= to these BCPs. > > Look at it the other way: if transport area folks would want to send MPLS= packets into the network in some problematic way, I'm sure the routing and= ops folks would not be amused. The root cause of the problem here is that UDP, has bifurcated into a general purpose encapsulation. Stewart From shane@castlepoint.net Thu Jan 16 20:38:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEE61ADF44 for ; Thu, 16 Jan 2014 20:38:24 -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 r8UOKGIzhB94 for ; Thu, 16 Jan 2014 20:38:22 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE1F1ADF2E for ; Thu, 16 Jan 2014 20:38:22 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 3D4C3300086 for ; Fri, 17 Jan 2014 04:38:10 +0000 (UTC) Received: from [10.0.1.5] (c-67-188-218-56.hsd1.ca.comcast.net [67.188.218.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 6BB8B300083; Thu, 16 Jan 2014 21:38:07 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: <52D81D81.4010708@pi.nu> Date: Thu, 16 Jan 2014 20:38:06 -0800 Content-Transfer-Encoding: 7bit Message-Id: <472D78DD-B17F-4F7E-A223-B3A25305D67A@castlepoint.net> References: <52D77069.2050405@pi.nu> <52D81D81.4010708@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Jan 16 21:38:10 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 52d8b3b242071203520559 X-DSPAM-Factors: 27, request+steps, 0.40000, 739+81, 0.40000, 739+81, 0.40000, conformance+#+IETF, 0.40000, or+#+#+#+aware, 0.40000, mail01+#+com, 0.40000, mail01+#+com, 0.40000, document+#+fairly, 0.40000, the+individual, 0.40000, 01+16, 0.40000, steps+#+post, 0.40000, 3979+#+#+#+5378, 0.40000, parallel+#+#+initial, 0.40000, 12+38, 0.40000, steps+#+mail, 0.40000, Loa+#+loa, 0.40000, Loa+#+loa, 0.40000, and+#+#+#+the, 0.40000, the+IPR, 0.40000, The+#+#+to, 0.40000, 01+#+#+14, 0.40000, three+#+#+#+this, 0.40000, document+author, 0.40000, IETF+rules, 0.40000, shane+#+Jan, 0.40000, 01+#+#+#+Andrew, 0.40000, nu+#+Technologies, 0.40000 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] IPR poll on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 04:38:24 -0000 I am not aware of any IPR related to this draft. -shane On Jan 16, 2014, at 9:57 AM, Loa Andersson wrote: > Andy, > > Thanks - I suspect that you and everyone have spotted the copy and > paste error in this IPR poll. > > I claim that there are three IPR disclosures against this document. > This is not right - there are no disclosures against this document. > > /Loa > > On 2014-01-16 23:14, Andrew G. Malis wrote: >> Loa, >> >> I am not aware of any non-disclosed IPR with regards to this draft. >> >> Cheers, >> Andy >> >> On Thu, Jan 16, 2014 at 12:38 AM, Loa Andersson wrote: >>> Working Group, >>> >>> we have just requested publication of draft-ietf-mpls-forwarding-04. >>> >>> Since the IPR poll on the individual document is fairly recent, we will >>> do the final poll in parallel to the initial steps of post publication >>> request steps. >>> >>> This mail starts that IPR poll. >>> >>> Are you aware of any IPR that applies to draft-ietf-mpls-forwarding? >>> >>> If so, has this IPR been disclosed in compliance with IETF IPR rules >>> (see RFCs 3979, 4879, 3669 and 5378 for more details). >>> >>> Currently there are three IPR disclosures that relates to this document. >>> >>> If you are listed as a document author or contributor please respond to >>> this email regardless of whether or not you are aware of any relevant >>> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >>> document will not advance to the next stage until a response has been >>> received from each author and contributor. >>> >>> If you are on the MPLS WG email list but are not listed as an author or >>> contributor, then please explicitly respond only if you are aware of any >>> IPR that has not yet been disclosed in conformance with IETF rules. >>> >>> Thanks, Loa >>> (as MPLS WG co-chair) >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From joelja@bogus.com Thu Jan 16 23:38:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880541ADFA8; Thu, 16 Jan 2014 23:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 VSkRdsFf0hGv; Thu, 16 Jan 2014 23:38:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2625B1ADFA7; Thu, 16 Jan 2014 23:38:39 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0H7cHHJ042299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Jan 2014 07:38:18 GMT (envelope-from joelja@bogus.com) Message-ID: <52D8DDE4.4020508@bogus.com> Date: Thu, 16 Jan 2014 23:38:12 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: "Eggert, Lars" References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> In-Reply-To: <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PTB8idFLvG0WvUqCJnR2Cn1E3EKCRKOsX" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 17 Jan 2014 07:38:19 +0000 (UTC) Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 07:38:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PTB8idFLvG0WvUqCJnR2Cn1E3EKCRKOsX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/16/14, 9:19 AM, Eggert, Lars wrote: > Hi, >=20 > On 2014-1-16, at 18:06, joel jaeggli wrote: >> These tunnels are stateless >=20 > yep. (But they don't have to be.) They do in-fact have to be stateless with respect to the contents. They will no doubt be created in a same distributed forwarding engines that currently do IP-MPLS encapsulation and L2-MPLS encapsulation. likewise their decapsulation will occur in such devices. > Look at it the other way: if transport area folks would want to send > MPLS packets into the network in some problematic way, I'm sure the > routing and ops folks would not be amused. Today congestion occurs on MPLS networks. intermediate hops that are congested have no choice but to drop packets. > Lars >=20 --PTB8idFLvG0WvUqCJnR2Cn1E3EKCRKOsX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLY3eQACgkQ8AA1q7Z/VrKRiACeNJwruJc6ZxAtze2GyK0NGi3j etQAn1O9s33glGXzGVt/tTtvvEYq971f =3puk -----END PGP SIGNATURE----- --PTB8idFLvG0WvUqCJnR2Cn1E3EKCRKOsX-- From internet-drafts@ietf.org Fri Jan 17 05:48:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0755B1AE0CD; Fri, 17 Jan 2014 05:48:54 -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 TxDxsa2OJxbR; Fri, 17 Jan 2014 05:48:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B19221AE0CF; Fri, 17 Jan 2014 05:48:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140117134852.25272.87457.idtracker@ietfa.amsl.com> Date: Fri, 17 Jan 2014 05:48:52 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-p2mp-framework-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 13:48:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : A Framework for Point-to-Multipoint MPLS in Trans= port Networks Authors : Dan Frost Stewart Bryant Matthew Bocci Lou Berger Filename : draft-ietf-mpls-tp-p2mp-framework-06.txt Pages : 12 Date : 2014-01-16 Abstract: The Multiprotocol Label Switching Transport Profile is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture applicable specifically to supporting point-to- multipoint transport paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-p2mp-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-p2mp-framework-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-p2mp-framework-06 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 curtis@ipv6.occnc.com Fri Jan 17 08:00:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD841AE155 for ; Fri, 17 Jan 2014 08:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 cHPTl1_YiYqu for ; Fri, 17 Jan 2014 08:00:57 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id BE8591AE153 for ; Fri, 17 Jan 2014 08:00:56 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HG0R5F062090; Fri, 17 Jan 2014 11:00:27 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401171600.s0HG0R5F062090@maildrop2.v6ds.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Thu, 16 Jan 2014 05:35:38 +0000." <75996b50f08c46b5b3809ee628dadcba@AM3PR03MB532.eurprd03.prod.outlook.com> Date: Fri, 17 Jan 2014 11:00:27 -0500 Cc: "mpls@ietf.org" Subject: Re: [mpls] mpls-in-udp entropy X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 16:00:59 -0000 In message <75996b50f08c46b5b3809ee628dadcba@AM3PR03MB532.eurprd03.prod.outlook.com> Alexander Vainshtein writes: > > Curtis, > > IMHO and FWIW it is preferable to allocate the entropy port from the > Dynamic/Private space. 14K values should suffice for any reasonable > ECMP scenarios. > > My 2c, > Sasha The return address should be the sender and maybe it would be a good idea to use port numbers that are not otherwise in use by the sender in case something gets the packet and tries to reply, but even that is extremely unlikely. For the source port to get abused the host at the other end would have to be running the wrong service on that port and trying to reply. Avoiding the WKP space might be a good idea only to avoid a error reply to an error reply loop if both ends think they have a WKP. Even if no loop is formed a misconfigured other end could bombard your UDP socket space. Mistyping the dest address of the MPLS over UDP tunnel could be quite harmfull but more likely to the other end that has to drop a lot of misdirected packets. Absent severe misconfiguration where the destination has another service on that port, even using the WKP space in the source port would be OK. (BTW- A UDP packet with two WKPs was the basis for an old forged packet denial of service attack before some of the very old low number UDP echo and daytime type services were shut off by default. For this reason it used to be useful to run sockstat -p udp -l and make sure you understand what is running on which port and which UDP sockets could potentially send a "badly formed packet" reply and create a loop. These days you are unlikely to find this situation.). Curtis > ________________________________________ > From: Curtis Villamizar > Sent: Wednesday, January 15, 2014 10:56 PM > To: Alexander Vainshtein > Cc: erosen@cisco.com; mpls@ietf.org > Subject: Re: [mpls] mpls-in-udp entropy > > In message <5b0765246d204750a50e1aad52a3b72e@AM3PR03MB532.eurprd03.prod.outlook.com> > Alexander Vainshtein writes: > > > Eric, > > Lots of thanks for a prompt and highly informative response. > > > > I have been actually thinking about the same thing, namely that the > > entropy port should be the result of some hash over the label > > stack. > > > > If this is indeed the intention of the authors, it would make sense > > (at least, from my point of view) of saying so in the draft. There > > is no need to make such a statement normative, but it would really > > help the readers (both implementors and operators) to understand > > what it is about. > > > > Regards, > > Sasha > > Avoiding the lower 8K of the port number space might not be a bad idea > to avoid a return port being a WKP including the non-root WKP space > used by X-Windows and other things. > > Curtis > > > > ________________________________________ > > From: Eric Rosen > > Sent: Wednesday, January 15, 2014 6:35 PM > > To: Alexander Vainshtein > > Cc: mpls@ietf.org > > Subject: Re: mpls-in-udp entropy > > > > (Changed subject line and trimmed cc-list.) > > > > Sasha> I would like to understand whether this protocol can really result in > > Sasha> reasonable distribution of traffic. "Reasonable" means that (a) there > > Sasha> is sufficient entropy and (b) that the order in specific micro-flows > > Sasha> is preserved. > > > > I thought the intention was that the encapsulator would set the UDP source > > port based upon the entropy of the packet being encapsulated. This only > > requires that the encapsulator know how to properly apply ECMP to the MPLS > > packet that is being encapsulated. That is, compute the hash that would be > > used to apply ECMP to the MPLS packet, and then map from that hash to a UDP > > source port. > > > > E.g., two MPLS packets with the same entropy label would get the same UDP > > source port, two MPLS packets with no entropy label but containing the same > > TCP flow would get the same source port, etc. > > > > Do you think there is a problem here? > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From saku@ytti.fi Fri Jan 17 08:33:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6561AE12F for ; Fri, 17 Jan 2014 08:33:29 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zPQzoQORxSt for ; Fri, 17 Jan 2014 08:33:28 -0800 (PST) Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by ietfa.amsl.com (Postfix) with ESMTP id 179D91AE135 for ; Fri, 17 Jan 2014 08:33:24 -0800 (PST) Received: by mail-bk0-f41.google.com with SMTP id u12so1599218bkz.28 for ; Fri, 17 Jan 2014 08:33:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=fOExXz/vu7Y2EmPTN7KeV7eiMgKQomSy+C+1ovhn/KA=; b=RlOhid9pzJCSa1KZ8YtaYTa6rDlX8T3Pog9qjlQqSvEcrWUlCvaw0bGs/DuMp7BfvY xJIy1OaYREo98mx9Lgclm6wBJLHdrmPr278rApcdRNvCE/pVT1Sz/AfmrxiU7gnjYX1A yf6+tLSHb9QnGZhuawMJW7GNJawJs3V/AGy09ZMOlY5+P3Cdcbm3kw5msFhGe8xEUZLm 5yTlhZadxFC7zenFE52ZnU4FACDHCvAIEYX1WAd9kZM+n1I35hdh9V+g0Y3XUgxECEuq 7AGxc1rjq9/SjpAi4+rRnJVOOZ6FR2D4y7PVmfvRnQASsavMnS/TY4YXLOcATEV53gIx cKiA== X-Gm-Message-State: ALoCoQnET6Bz8c8RpyqJqGA0gaAwKH3D71FrJI7SJR3L3QUCxoUTqWvSOYm4M8pYg36CVToV7Gfo X-Received: by 10.205.67.199 with SMTP id xv7mr15190bkb.149.1389976391762; Fri, 17 Jan 2014 08:33:11 -0800 (PST) Received: from pob.ytti.fi (up.ip.fi. [2001:6e8:288::d]) by mx.google.com with ESMTPSA id d5sm10022809bkc.9.2014.01.17.08.33.09 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 Jan 2014 08:33:10 -0800 (PST) Date: Fri, 17 Jan 2014 18:33:07 +0200 From: Saku Ytti To: tsvwg@ietf.org, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org Message-ID: <20140117163307.GA4577@pob.ytti.fi> References: <290E20B455C66743BE178C5C84F1240847E63346BF@EXMB01CMS.surrey.ac.uk> <201401131911.s0DJBC1o079251@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401131911.s0DJBC1o079251@maildrop2.v6ds.occnc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 16:33:29 -0000 On (2014-01-13 14:11 -0500), Curtis Villamizar wrote: > One of the reasons that IPv6 (rfc2460) dropped the header checksum > that was in IPv4 is that with link layers all doing FCS it served no > purpose. For the same reason TCP and UDP checksums server no purpose. One datapoint from today. Peering router has 4xLACP to core and in one of these LACP members it is sometimes mangling packets during send and FCS is being calculated for this mangled data. All egress PE boxes start logging errors (maybe 1 error per 30min), because they check IP checksum, which is now incorrect. Router is latest generation service provider router from major vendor running recent software and affected router is logging no errors. Can't imagine when, if ever, would this issue have been found without IP checksums. -- ++ytti From curtis@ipv6.occnc.com Fri Jan 17 08:58:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4B01AE085 for ; Fri, 17 Jan 2014 08:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 jCxNWWFebgzk for ; Fri, 17 Jan 2014 08:58:09 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 19EE01AE0D6 for ; Fri, 17 Jan 2014 08:58:09 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HGvtYW062709; Fri, 17 Jan 2014 11:57:56 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401171657.s0HGvtYW062709@maildrop2.v6ds.occnc.com> To: Loa Andersson From: Curtis Villamizar In-reply-to: Your message of "Thu, 16 Jan 2014 13:38:49 +0800." <52D77069.2050405@pi.nu> Date: Fri, 17 Jan 2014 11:57:55 -0500 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] IPR poll on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 16:58:10 -0000 Loa, I know of no IPR on this documnet. There may be IPR disclosed by others on some of the referenced RFCs. I didn't check. Should I? Curtis In message <52D77069.2050405@pi.nu> Loa Andersson writes: Working Group, we have just requested publication of draft-ietf-mpls-forwarding-04. Since the IPR poll on the individual document is fairly recent, we will do the final poll in parallel to the initial steps of post publication request steps. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-forwarding? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are three IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Fri Jan 17 09:20:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E701AE155; Fri, 17 Jan 2014 09:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RP_MATCHES_RCVD=-0.538, 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 OOEX1DlxWCOm; Fri, 17 Jan 2014 09:20:10 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 148EA1AE0DB; Fri, 17 Jan 2014 09:20:09 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HHJqHY062965; Fri, 17 Jan 2014 12:19:52 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401171719.s0HHJqHY062965@maildrop2.v6ds.occnc.com> To: "Eggert, Lars" From: Curtis Villamizar In-reply-to: Your message of "Thu, 16 Jan 2014 17:19:50 +0000." <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> Date: Fri, 17 Jan 2014 12:19:52 -0500 Cc: Joel Jaeggli , "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 17:20:12 -0000 Lars, We seem to be in an endless loop here. You have made your assertions about your desire to uphold the purity of any new UDP applications and adhere to the BCP you wrote. You appear to be very nearly alone in this argument and certainly no one that works with MPLS is siding with you. In the end we can put anything we want in the RFC *but* IETF has never truly had the final word on what vendors and operators do in provider networks. In this case, regardless of what changes are made to the draft, implementations will offer at least the option for non-RFC behavior by using zero checksums and not using any congestion control. And providers will make use of it, perhaps exclusively. The document might as well reflect reality, despite reality not conforming to your notions of architectural purity. The best course of action is to put a SHOULD in regarding checksums and put a SHOULD in regarding congestion avoidance. Even the BCP does not go any further than to say a tunneling protocol SHOULD use congestion control and there were reasons that the word MUST was not acceptable in the BCP. If we are still arguing over two instances of SHOULD vs MUST we have wasted a lot of bandwidth on those two words. IMHO The only remaining question is whether the document can go forward with the definition of congestion control for MPLS over UDP left out of scope and for another document if a need arises. If this is not acceptable to you (I doubt it is) please indicate what you would like to see in the document and since this is IETF last call where consensus matters and no one individual has veto power, we'll have to see if there is consensus behind your proposed changes. Curtis In message <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> "Eggert, Lars" writes: > Hi, > > On 2014-1-16, at 18:06, joel jaeggli wrote: > > These tunnels are stateless > > yep. (But they don't have to be.) > > > The endpoints not the encapsulators have visibility into the > > end-to-end loss latency properties of the path. > > Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 = > domains - where not reacting to congestion may be OK - can now go over = > the wider Internet, where this is not OK. > > I'd be great if those apps would change. But in the meantime, it's the = > duty of the encapsulator - who enables this traffic to break out of an = > L2 domain and go over the wider net - to make sure the traffic it emits = > conforms to our BCPs. > > > the encapsulator is an intermediate hop, similar to any other router > > in the path. > > It's not. For the rest of the network, that encapsulator is = > indistinguishable from any other app that sends UDP traffic. > > UDP is a transport-layer protocol, and we have practices how it is to be = > used on the net. If you want to use it for encapsulation, you bind = > yourself to these BCPs. > > Look at it the other way: if transport area folks would want to send = > MPLS packets into the network in some problematic way, I'm sure the = > routing and ops folks would not be amused. > > Lars From curtis@ipv6.occnc.com Fri Jan 17 09:49:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3C81A1F1B for ; Fri, 17 Jan 2014 09:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 Qr4cghRbMVzX for ; Fri, 17 Jan 2014 09:49:14 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 92A981A16F0 for ; Fri, 17 Jan 2014 09:49:14 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HHn1A2063330; Fri, 17 Jan 2014 12:49:01 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401171749.s0HHn1A2063330@maildrop2.v6ds.occnc.com> To: mpls@ietf.org From: Curtis Villamizar MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <20624.1389980750.0@harbor3.ipv6.occnc.com> Date: Fri, 17 Jan 2014 12:49:01 -0500 Subject: [mpls] fwd Re: mpls-rt review of draft-akiya-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 17:49:17 -0000 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20624.1389980750.1@harbor3.ipv6.occnc.com> My bad. Replied to wrong email with mpls WG not on the Cc. Subject and message-id/reply-to searches might be unhappy but here it is. I hope the mailing list is OK with rfc822 mime type. Curtis ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-ID: <20624.1389980750.2@harbor3.ipv6.occnc.com> Return-Path: Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) by harbor3.ipv6.occnc.com (8.14.7/8.14.7) with ESMTP id s0HHRS4i019779 for ; Fri, 17 Jan 2014 12:27:28 -0500 (EST) (envelope-from loa@pi.nu) Received: (from curtis@localhost) by harbor3.ipv6.occnc.com (8.14.7/8.14.7/Submit) id s0HHRSJV019778 for curtis; Fri, 17 Jan 2014 12:27:28 -0500 (EST) (envelope-from loa@pi.nu) Received: from maildrop2.v6ds.occnc.com [2001:470:88e6:3::232] by harbor3.ipv6.occnc.com with IMAP (fetchmail-6.3.26) for (single-drop); Fri, 17 Jan 2014 12:27:28 -0500 (EST) Received: from deliver ([unix socket]) by maildrop2.v6ds.occnc.com (Cyrus v2.4.17) with LMTPA; Fri, 17 Jan 2014 00:11:37 -0500 X-Sieve: CMU Sieve 2.4 Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0H5BVUd051842 for ; Fri, 17 Jan 2014 00:11:36 -0500 (EST) (envelope-from loa@pi.nu) Received: from [192.168.1.3] (unknown [49.147.219.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E0812180150F for ; Fri, 17 Jan 2014 06:11:29 +0100 (CET) Message-ID: <52D8BB7D.10008@pi.nu> Date: Fri, 17 Jan 2014 13:11:25 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com Subject: Re: Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping References: <201401170508.s0H585kF051738@maildrop2.v6ds.occnc.com> In-Reply-To: <201401170508.s0H585kF051738@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Curtis, I can take the review as it is, but I prefer to have on the working group mailing list. If it is OK to you, please send it. /Loa On 2014-01-17 13:08, Curtis Villamizar wrote: > In message <52C67349.4020701@pi.nu> > Loa Andersson writes: > >> Folks, >> >> This was the wrong document - I intended to have the review >> done for draft-akiya-mpls-entropy-lsp-ping sorry for the confusion. >> >> All other cordinates correct! >> >> On 2014-01-03 14:44, Loa Andersson wrote: >>> Sri, Xiaohu, Curtis and Dan, >>> >>> You have been selected as MPLS Review team reviewers for >>> draft-akiya-mpls-entropy-lsp-ping-01. >>> >>> Note to authors: You have been CC'd on this email so that you can know >>> that this review is going on. However, please do not review your own >>> document. >>> >>> Reviews should comment on whether the document is coherent, is it >>> useful (ie, is it likely to be actually useful in operational >>> networks), and is the document technically sound? We are interested >>> in knowing whether the document is ready to be considered for WG >>> adoption (ie, it doesn't have to be perfect at this point, but should be >>> a good start). >>> >>> Reviews should be sent to the document authors, WG co-chairs and >>> WG secretary, and CC'd to the MPLS WG email list. If necessary, comments >>> may be sent privately to only the WG chairs. >>> >>> Are you able to review this draft by January 20, 2014? >>> >>> Thanks, Loa >>> (as MPLS WG chair) >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com > > > > Loa, > > Overall a good draft and should become a WG doc as it is an > improvement to a fairly badly designed feature of MPLS Ping that > remains fairly badly designed but now a little less broken for ELI/EL. > > I'm not sure the procedures that are defined work correctly if an LSR > does load split on the label stack (or part of it) up to and then > including the EL, but nothing after the EL. There seems to be an > assumption that only the EL is used if present. The way the RFC 6790 > reads the search for entropy stops at the EL (a SHOULD that would have > been better made a MUST). > > Some (big) issues: > > {L=0, E=0} LSR load balances based on IP and does not push ELI/EL. > {L=0, E=1} LSR load balances based on IP and pushes ELI/EL. > {L=1, E=0} LSR load balances based on label and does not push ELI/EL. > {L=1, E=1} LSR load balances based on label and pushes ELI/EL. > > What about the case where the LSR load balances on both labels and on > IP? If the payload is IP, the entropy from the IP header is used *in > addition to* the entropy from the label stack. > > There should also be a flag to indicate that the LSR will terminate > the search for entropy at the EL as it SHOULD according to RFC 6790. > > The flags points to an issue with RFC 4379 even without ELI/EL that is > still not addressed here. What if the typical payload contains both > additional labels (payload is MPLS) and IP under the labels and some > LSR look at only the IP and some look at only the labels and some look > at both and some that look at labels can only look at the top N or the > bottom N labels. > > Also the max depth in RFC 4379 is inadequate since some LSR can look > at labels up to some depth D1 and can find an IP header if it appears > at up to some depth D2 and D1 != D2. These two depths are not > independent in RFC 4379. > > A few additional flags and values need to be carried if these cases > are all to be covered. OTOH, RFC 4379 works fine for a single vendor > network if all their products behave in the same way. > > This draft acknowledges that there are some issues (including with > E=0 that existing in RFC 4379 prior to ELI/EL) but doesn't fix them > even though they are fixable: > > In following conditions, initiating LSR may have lost the ability > to exercise specific ECMP paths. Initiating LSR MAY continue with > "best effort". > > o Received echo reply contains empty multipath information. > > o Received echo reply contains {L=0, E=} DS flags, but does > not contain IP multipath information. > > o Received echo reply contains {L=1, E=} DS flags, but does > not contain label multipath information. > > o Received echo reply contains {L=, E=1} DS flags, but does > not contain associated label multipath information. > > o IP multipath information types {2, 4, 8} sent, and received echo > reply with {L=1, E=0} in DS flags. > > o Multipath information type {10} sent, and received echo reply > with multipath information type other than {10}. > > On the topic of flags, the N bit was always problematic. When TTL is > incremented the LSR will behave as if the packet is IP, because it is. > > The flags and defined behavior for this failure is an improvement over > RFC 4379 where the behavior was undefined both in terms of what to put > in the reply and how the initiator should interpret it. > > Througout the document it is not clear what an IP load balancer is. > For example:` > > o When initiating LSR is IP based load balancer (not pushing ELI/ > EL), initialize EL_LSP=False. > > The initiating LSR may be a carrying MPLS traffic (ie: a PSC LSP). > Therefore is may get traffic that already has an ELI/EL in the stack. > > This is not worded clearly for the case where the LSR is capable of IP > based load balance but is not pushing an ELI/EL but it has already > seen an ELI/EL on the stack. Need to clarify whether the LSR is an > "IP based load balancer" if it is capable of IP based load balance or > if it would have done IP based load balance on this stack. > > The term "IP Based Load Balancer" is never defined. > > The term "Label Based Load Balancer" is never defined. > > It is not clear which to pick if an LSR can use both types of > information as would be the case for many routers when no ELI/EL is > found in the stack. > > In "9. Unsupported Cases" you might as well admit "won't ever work > for some vendor's equipment that uses the whole label stack to load > balance plus can use IP stack". The two unsupported cases are: > > o When one or more LSP transit node(s) performs label based load > balancing on a label that is not bottom-of-stack label when > Entropy Label Indicator is not included. > > A lot of equipment uses all of the labels. Did you means does not use > the bottom label? > > o When one or more LSP transit node(s) performs label based load > balancing on a label other than Entropy Label when Entropy Label > Indicator and Entropy Label pair is included. > > It is also legal (and I think preferred) to use all of the labels up > to and including the first EL (but not the ELI and any other reserved > label). Did you means a label after the EL? > > Either these unsupported cases are worded wrong or something is very > seriously wrong with LSP Ping. > > Some minor points: > > RFC 6424 should be mentioned as soon as RFC 4379 is mentioned in the > intro since RFC 6424 changes RFC 4379 behavior and depricated a RFC > 4379 TLV and replaces it. > > When an MPLS echo request message is received containing a > FEC-Stack with an EL-FEC at the bottom of the FEC stack and is not > preceded by an entropy label, the responder must behave (for load > balancing purposes) as if the first word of the message were a > Pseudowire Control Word. > > This is asking for the DD-MAP or DS-MAP response to be constructed as > if CW was at bottom, but doesn't read that way. It reads as if > forwarding was changed. > > Note that this procedure only traces to the end of the MPLS LSP at > transport layer (e.g. LDP and/or RSVP). > > That is not what "transport layer" means to a lot of people. Very bad > wording. > > * Else initiating LSR MUST use multipath information type {2, > 4, 8, 9}. > > Exactly what should it do if load balance is affected by *either* > another label on the stack or a different IP under the stack? What if > both peices of information are used in creating load balance entropy > (ie: what if the IP map depends on any additional labels)? > > Nits: > > s/indicate and entropy/indicate and entropy/ > > In "5.2. IP Based Load Balancer & Pushes ELI/EL" third bullet is a > massive run-on paragraph. Split into sub-bullets for the multiple > case within it. Probably good for other bullets containing more than > one sentence starting with "If". > > probably plenty more nits that I missed. > > Curtis > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 ------- =_aaaaaaaaaa0-- From curtis@ipv6.occnc.com Fri Jan 17 10:02:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E209D1AC421; Fri, 17 Jan 2014 10:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 etx0bFqg6eoS; Fri, 17 Jan 2014 10:02:54 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id A0C331A16F0; Fri, 17 Jan 2014 10:02:54 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HI2cI6063577; Fri, 17 Jan 2014 13:02:38 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401171802.s0HI2cI6063577@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Fri, 17 Jan 2014 01:19:41 +0000." <290E20B455C66743BE178C5C84F1240847E63346CE@EXMB01CMS.surrey.ac.uk> Date: Fri, 17 Jan 2014 13:02:37 -0500 Cc: rcallon@juniper.net, joelja@bogus.com, lars@netapp.com, ietf@ietf.org, mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:02:57 -0000 Lloyd, If we really want to get silly we can claim that a UDP control block or socket state on a UDP listen is state and therefore UDP is not a stateless protocol. But we don't want to get silly. Do we? Or are we long past that point? Curtis PS - type "man setsocopt" on a BSD system to see a list of state, most of which applies to any socket including UDP sockets. In message <290E20B455C66743BE178C5C84F1240847E63346CE@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > Surely you mean minimised state? > > The tunnels have to know where the other tunnel endpoint is - > state. This is distinct from having a congestion-aware state machine > that e.g. TCP includes... > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: mpls [mpls-bounces@ietf.org] On Behalf Of Ross Callon [rcallon@juniper.net] > Sent: 16 January 2014 22:32 > To: Eggert, Lars > Cc: EXT - joelja@bogus.com; mpls@ietf.org; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > >> These tunnels are stateless > > > > yep. (But they don't have to be.) > > The tunnels strictly speaking do not have to be stateless. However, if you want routers to actually implement them, and you want to scale in both forwarding speed and number of tunnels, then yes they do have to be stateless. > > Ross > (speaking only as an individual contributor) > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars > Sent: Thursday, January 16, 2014 12:20 PM > To: EXT - joelja@bogus.com > Cc: mpls@ietf.org; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > Hi, > > On 2014-1-16, at 18:06, joel jaeggli wrote: > > These tunnels are stateless > > yep. (But they don't have to be.) > > > The endpoints not the encapsulators have visibility into the > > end-to-end loss latency properties of the path. > > Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 domains - where not reacting to congestion may be OK - can now go over the wider Internet, where this is not OK. > > I'd be great if those apps would change. But in the meantime, it's the duty of the encapsulator - who enables this traffic to break out of an L2 domain and go over the wider net - to make sure the traffic it emits conforms to our BCPs. > > > the encapsulator is an intermediate hop, similar to any other router > > in the path. > > It's not. For the rest of the network, that encapsulator is indistinguishable from any other app that sends UDP traffic. > > UDP is a transport-layer protocol, and we have practices how it is to be used on the net. If you want to use it for encapsulation, you bind yourself to these BCPs. > > Look at it the other way: if transport area folks would want to send MPLS packets into the network in some problematic way, I'm sure the routing and ops folks would not be amused. > > Lars From curtis@ipv6.occnc.com Fri Jan 17 10:06:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC1B1AC421; Fri, 17 Jan 2014 10:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 Bf9pvr_JNmjs; Fri, 17 Jan 2014 10:06:06 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 576021A16F0; Fri, 17 Jan 2014 10:06:06 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HI5kUC063603; Fri, 17 Jan 2014 13:05:46 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401171805.s0HI5kUC063603@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Fri, 17 Jan 2014 03:03:05 +0000." <290E20B455C66743BE178C5C84F1240847E63346CF@EXMB01CMS.surrey.ac.uk> Date: Fri, 17 Jan 2014 13:05:46 -0500 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:06:08 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346CF@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > There's an opportunity to define a simple generic IPv6 encapsulating > mechanism a la UDP, but with a payload checksum of varying coverage > (header only, partial payload, full payload) and with the (stronger > than UDP) checksum placed at the end of the packet. > > Lloyd Wood > http://about.me/lloydwood Go for it! When a critical mass of routers hash on this new protocol number and port space we'll let you know and the MPLS WG can obsolete MPLS over UDP and replace it with MPLS over this new protocol. Thanks for offering to write this. Curtis > ________________________________________ > From: ietf [ietf-bounces@ietf.org] On Behalf Of Stewart Bryant [stbryant@cisco.com] > Sent: 16 January 2014 17:35 > To: Eggert, Lars; Joel Jaeggli > Cc: mpls@ietf.org; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > On 16/01/2014 17:19, Eggert, Lars wrote: > > Hi, > > > > On 2014-1-16, at 18:06, joel jaeggli wrote: > >> These tunnels are stateless > > yep. (But they don't have to be.) > Ah, they do if they are to scale. State at speed is really hard. The sort > of systems we are talking about do things like pipeline counters > and it is loooooots of packets later before the counter is actually > incremented. > >> The endpoints not the encapsulators have visibility into the > >> end-to-end loss latency properties of the path. > > Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 domains - where not reacting to congestion may be OK - can now go over the wider Internet, where this is not OK. > > > > I'd be great if those apps would change. But in the meantime, it's the duty of the encapsulator - who enables this traffic to break out of an L2 domain and go over the wider net - to make sure the traffic it emits conforms to our BCPs. > > > >> the encapsulator is an intermediate hop, similar to any other router > >> in the path. > > It's not. For the rest of the network, that encapsulator is indistinguishable from any other app that sends UDP traffic. > > > > UDP is a transport-layer protocol, and we have practices how it is to be used on the net. If you want to use it for encapsulation, you bind yourself to these BCPs. > > > > Look at it the other way: if transport area folks would want to send MPLS packets into the network in some problematic way, I'm sure the routing and ops folks would not be amused. > The root cause of the problem here is that UDP, has bifurcated into > a general purpose encapsulation. > > Stewart > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Fri Jan 17 10:16:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7A1A1F64; Fri, 17 Jan 2014 10:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 59XwkD_sYlYW; Fri, 17 Jan 2014 10:16:26 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8D37F1A1F4A; Fri, 17 Jan 2014 10:16:26 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HIGBJa063724; Fri, 17 Jan 2014 13:16:12 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401171816.s0HIGBJa063724@maildrop2.v6ds.occnc.com> To: joel jaeggli From: Curtis Villamizar In-reply-to: Your message of "Thu, 16 Jan 2014 23:38:12 -0800." <52D8DDE4.4020508@bogus.com> Date: Fri, 17 Jan 2014 13:16:11 -0500 Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:16:28 -0000 In message <52D8DDE4.4020508@bogus.com> joel jaeggli writes: > On 1/16/14, 9:19 AM, Eggert, Lars wrote: > > Hi, > > > > On 2014-1-16, at 18:06, joel jaeggli wrote: > >> These tunnels are stateless > > > > yep. (But they don't have to be.) > > They do in-fact have to be stateless with respect to the contents. They > will no doubt be created in a same distributed forwarding engines that > currently do IP-MPLS encapsulation and L2-MPLS encapsulation. likewise > their decapsulation will occur in such devices. > > > Look at it the other way: if transport area folks would want to send > > MPLS packets into the network in some problematic way, I'm sure the > > routing and ops folks would not be amused. They would never notice since MPLS packets are only passed around internally and in some cases among peer providers. If you did try to do that and succeeded in getting even one packet through there are some security holes to worry about. Point is that you can't get MPLS packets into provider networks unless something is very seriously wrong and the already persistant attackers would have a picnic. > Today congestion occurs on MPLS networks. intermediate hops that are > congested have no choice but to drop packets. And nothing bad happens because providers that allow any congestion to occur by provisioning so that it can happen (usually occasionally or very rarely) carry two kinds of traffic in that network. One is IP in MPLS or IP native. The other is high margin VPN services and emulated legacy L2 services that are given a different TC value. What the providers want to happen on light congestion happens. Slight drop gets IP (mostly TCP still to this date) to reduce load. The high paying VPN and emulated legacy L2 services are completely unaffected (as the provider wants given they are paying a lot for that). So I'm agreeing with you (Joel). > > Lars Curtis From lberger@labn.net Fri Jan 17 11:15:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D739B1AE17F; Fri, 17 Jan 2014 11:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.188 X-Spam-Level: ** X-Spam-Status: No, score=2.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793, SPF_NEUTRAL=0.779] 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 t_HcWel49cae; Fri, 17 Jan 2014 11:15:24 -0800 (PST) Received: from newdragon.webhostserver.biz (unknown [69.25.137.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0E11C1AE0E9; Fri, 17 Jan 2014 11:15:23 -0800 (PST) Received: from localhost ([::1]:35483 helo=[127.0.0.1]) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W4Esp-0004kQ-5K; Fri, 17 Jan 2014 22:15:11 +0300 Message-ID: <52D9813D.7040904@labn.net> Date: Fri, 17 Jan 2014 14:15:09 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mpls@ietf.org References: <20140117134852.25272.87457.idtracker@ietfa.amsl.com> In-Reply-To: <20140117134852.25272.87457.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Cc: gen-art@ietf.org Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-p2mp-framework-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lberger@labn.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 19:15:27 -0000 Hello, This version addresses received editorial comments (some of which may not have been cc'ed to the mpls list), and update's Dan's contact info. Lou (and co-authors) On 01/17/2014 08:48 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : A Framework for Point-to-Multipoint MPLS in Transport Networks > Authors : Dan Frost > Stewart Bryant > Matthew Bocci > Lou Berger > Filename : draft-ietf-mpls-tp-p2mp-framework-06.txt > Pages : 12 > Date : 2014-01-16 > > Abstract: > The Multiprotocol Label Switching Transport Profile is the common set > of MPLS protocol functions defined to enable the construction and > operation of packet transport networks. The MPLS-TP supports both > point-to-point and point-to-multipoint transport paths. This > document defines the elements and functions of the MPLS-TP > architecture applicable specifically to supporting point-to- > multipoint transport paths. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-p2mp-framework/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-tp-p2mp-framework-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-p2mp-framework-06 > > > 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/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From Alexander.Vainshtein@ecitele.com Fri Jan 17 11:19:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E421A1F4E for ; Fri, 17 Jan 2014 11:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzM_GbRVt3Wx for ; Fri, 17 Jan 2014 11:19:48 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) by ietfa.amsl.com (Postfix) with ESMTP id 153131ADEA1 for ; Fri, 17 Jan 2014 11:19:47 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB529.eurprd03.prod.outlook.com (10.242.109.153) with Microsoft SMTP Server (TLS) id 15.0.851.11; Fri, 17 Jan 2014 19:19:34 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Fri, 17 Jan 2014 19:19:34 +0000 From: Alexander Vainshtein To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] mpls-in-udp entropy Thread-Index: AQHPE508ieRBwKl/XESIAXm8KkwTF5qJR9Ve Date: Fri, 17 Jan 2014 19:19:33 +0000 Message-ID: <6618bdb86bb94b8b875ea43fb3906e3b@AM3PR03MB532.eurprd03.prod.outlook.com> References: Your message of "Thu, 16 Jan 2014 05:35:38 +0000." <75996b50f08c46b5b3809ee628dadcba@AM3PR03MB532.eurprd03.prod.outlook.com>, <201401171600.s0HG0R5F062090@maildrop2.v6ds.occnc.com> In-Reply-To: <201401171600.s0HG0R5F062090@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.66.126.123] x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(51704005)(189002)(199002)(377454003)(74876001)(59766001)(4396001)(50986001)(47736001)(66066001)(83322001)(81816001)(19580405001)(74706001)(92566001)(90146001)(15975445006)(93136001)(93516002)(47976001)(76576001)(56816005)(76786001)(77982001)(83072002)(53806001)(54316002)(33646001)(81542001)(51856001)(80022001)(2656002)(87936001)(74502001)(46102001)(79102001)(81686001)(85852003)(65816001)(74366001)(47446002)(54356001)(87266001)(85306002)(19580395003)(31966008)(49866001)(80976001)(74316001)(76796001)(74662001)(76482001)(81342001)(56776001)(69226001)(63696002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB529; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:109.66.126.123; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Cc: "mpls@ietf.org" Subject: Re: [mpls] mpls-in-udp entropy X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 19:19:51 -0000 Curtis,=0A= This may be a bit paranoid, but I am worried about "rogue" applications li= ke PTP 2-step transparent clock.=0A= A router running this application, if it mistakenly associates a transit UD= P packet as PTP Delay_Resp based on Source UDP port (matching the UDP port= assigned by IANA for PTP) , may try to modify what it thinks to be the "co= rrection field" in its PTP header... =0A= =0A= Of course this should be a rare event, but still an extremely unpleasant on= e.=0A= =0A= My 2c,=0A= Sasha=0A= =0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Friday, January 17, 2014 6:00 PM=0A= To: Alexander Vainshtein=0A= Cc: curtis@ipv6.occnc.com; erosen@cisco.com; mpls@ietf.org=0A= Subject: Re: [mpls] mpls-in-udp entropy=0A= =0A= In message <75996b50f08c46b5b3809ee628dadcba@AM3PR03MB532.eurprd03.prod.out= look.com>=0A= Alexander Vainshtein writes:=0A= >=0A= > Curtis,=0A= >=0A= > IMHO and FWIW it is preferable to allocate the entropy port from the=0A= > Dynamic/Private space. 14K values should suffice for any reasonable=0A= > ECMP scenarios.=0A= >=0A= > My 2c,=0A= > Sasha=0A= =0A= The return address should be the sender and maybe it would be a good=0A= idea to use port numbers that are not otherwise in use by the sender=0A= in case something gets the packet and tries to reply, but even that is=0A= extremely unlikely. For the source port to get abused the host at the=0A= other end would have to be running the wrong service on that port and=0A= trying to reply. Avoiding the WKP space might be a good idea only to=0A= avoid a error reply to an error reply loop if both ends think they=0A= have a WKP. Even if no loop is formed a misconfigured other end could=0A= bombard your UDP socket space. Mistyping the dest address of the MPLS=0A= over UDP tunnel could be quite harmfull but more likely to the other=0A= end that has to drop a lot of misdirected packets.=0A= =0A= Absent severe misconfiguration where the destination has another=0A= service on that port, even using the WKP space in the source port=0A= would be OK.=0A= =0A= (BTW- A UDP packet with two WKPs was the basis for an old forged=0A= packet denial of service attack before some of the very old low number=0A= UDP echo and daytime type services were shut off by default. For this=0A= reason it used to be useful to run sockstat -p udp -l and make sure=0A= you understand what is running on which port and which UDP sockets=0A= could potentially send a "badly formed packet" reply and create a=0A= loop. These days you are unlikely to find this situation.).=0A= =0A= Curtis=0A= =0A= > ________________________________________=0A= > From: Curtis Villamizar =0A= > Sent: Wednesday, January 15, 2014 10:56 PM=0A= > To: Alexander Vainshtein=0A= > Cc: erosen@cisco.com; mpls@ietf.org=0A= > Subject: Re: [mpls] mpls-in-udp entropy=0A= >=0A= > In message <5b0765246d204750a50e1aad52a3b72e@AM3PR03MB532.eurprd03.prod.o= utlook.com>=0A= > Alexander Vainshtein writes:=0A= >=0A= > > Eric,=0A= > > Lots of thanks for a prompt and highly informative response.=0A= > >=0A= > > I have been actually thinking about the same thing, namely that the=0A= > > entropy port should be the result of some hash over the label=0A= > > stack.=0A= > >=0A= > > If this is indeed the intention of the authors, it would make sense=0A= > > (at least, from my point of view) of saying so in the draft. There=0A= > > is no need to make such a statement normative, but it would really=0A= > > help the readers (both implementors and operators) to understand=0A= > > what it is about.=0A= > >=0A= > > Regards,=0A= > > Sasha=0A= >=0A= > Avoiding the lower 8K of the port number space might not be a bad idea=0A= > to avoid a return port being a WKP including the non-root WKP space=0A= > used by X-Windows and other things.=0A= >=0A= > Curtis=0A= >=0A= >=0A= > > ________________________________________=0A= > > From: Eric Rosen =0A= > > Sent: Wednesday, January 15, 2014 6:35 PM=0A= > > To: Alexander Vainshtein=0A= > > Cc: mpls@ietf.org=0A= > > Subject: Re: mpls-in-udp entropy=0A= > >=0A= > > (Changed subject line and trimmed cc-list.)=0A= > >=0A= > > Sasha> I would like to understand whether this protocol can really resu= lt in=0A= > > Sasha> reasonable distribution of traffic. "Reasonable" means that (a) = there=0A= > > Sasha> is sufficient entropy and (b) that the order in specific micro-f= lows=0A= > > Sasha> is preserved.=0A= > >=0A= > > I thought the intention was that the encapsulator would set the UDP sou= rce=0A= > > port based upon the entropy of the packet being encapsulated. This onl= y=0A= > > requires that the encapsulator know how to properly apply ECMP to the M= PLS=0A= > > packet that is being encapsulated. That is, compute the hash that woul= d be=0A= > > used to apply ECMP to the MPLS packet, and then map from that hash to a= UDP=0A= > > source port.=0A= > >=0A= > > E.g., two MPLS packets with the same entropy label would get the same U= DP=0A= > > source port, two MPLS packets with no entropy label but containing the = same=0A= > > TCP flow would get the same source port, etc.=0A= > >=0A= > > Do you think there is a problem here?=0A= > > _______________________________________________=0A= > > mpls mailing list=0A= > > mpls@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/mpls=0A= =0A= From curtis@ipv6.occnc.com Fri Jan 17 12:28:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771411AC3FA; Fri, 17 Jan 2014 12:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 tEyVjjnDGtlV; Fri, 17 Jan 2014 12:28:33 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7021A802D; Fri, 17 Jan 2014 12:28:32 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HKSJP6065706; Fri, 17 Jan 2014 15:28:19 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401172028.s0HKSJP6065706@maildrop2.v6ds.occnc.com> To: Saku Ytti From: Curtis Villamizar In-reply-to: Your message of "Fri, 17 Jan 2014 18:33:07 +0200." <20140117163307.GA4577@pob.ytti.fi> Date: Fri, 17 Jan 2014 15:28:19 -0500 Cc: mpls@ietf.org, lisp@ietf.org, tsvwg@ietf.org, ietf@ietf.org Subject: Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 20:28:35 -0000 In message <20140117163307.GA4577@pob.ytti.fi> Saku Ytti writes: > On (2014-01-13 14:11 -0500), Curtis Villamizar wrote: > > > One of the reasons that IPv6 (rfc2460) dropped the header checksum > > that was in IPv4 is that with link layers all doing FCS it served no > > purpose. For the same reason TCP and UDP checksums server no purpose. > > One datapoint from today. Peering router has 4xLACP to core and in one of > these LACP members it is sometimes mangling packets during send and FCS is > being calculated for this mangled data. > All egress PE boxes start logging errors (maybe 1 error per 30min), because > they check IP checksum, which is now incorrect. > > Router is latest generation service provider router from major vendor running > recent software and affected router is logging no errors. Can't imagine > when, if ever, would this issue have been found without IP checksums. > > -- > ++ytti > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls This sounds like a router acting as a host for the given packet. The forwarding data paths in routers are usually protected. If the router was forwarding and mangled packets, that speak well for the router vendor since the major vendors claim to protect their data paths from this sort of thing. Less so for the path from the route processor. If this was originated at the router it would also be caught if AH was enabled. Were these unauthenticated control plane packets? You've made a good anecdotal case for keeping TCP and UDP checksums. Curtis From joelja@bogus.com Fri Jan 17 12:43:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1121AC829; Fri, 17 Jan 2014 12:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 LE5mSixiKu7f; Fri, 17 Jan 2014 12:43:26 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 432D71AC3FA; Fri, 17 Jan 2014 12:43:26 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0HKh3Od046197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Jan 2014 20:43:04 GMT (envelope-from joelja@bogus.com) Message-ID: <52D995D2.8080301@bogus.com> Date: Fri, 17 Jan 2014 12:42:58 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: stbryant@cisco.com, "Eggert, Lars" References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> <52D8185D.1010902@cisco.com> In-Reply-To: <52D8185D.1010902@cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GuGkHp4QL3d7iFsdeIdh6Hbc3lHN8oka2" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 17 Jan 2014 20:43:04 +0000 (UTC) Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 20:43:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GuGkHp4QL3d7iFsdeIdh6Hbc3lHN8oka2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/16/14, 9:35 AM, Stewart Bryant wrote: >> Look at it the other way: if transport area folks would want to=20 >> send MPLS packets into the network in some problematic way, I'm=20 >> sure the routing and ops folks would not be amused. > The root cause of the problem here is that UDP, has bifurcated into a > general purpose encapsulation. One observation with respect to general purpose use of UDP as an mpls encapsulation on the internet as a whole that seems to have been missed in this discussion is the rather dire prospects for MTU and potential for= fragmentation. Effectively, assuring, that you do not need to fragment requires as certain amount of coordination. 1500 mtu hops pretty effectively (imho) preclude the use of this encapsulation on the internet as a whole (if encapsulated traffic is not aware of a correspondingly lower MTU) this is especially true for L2vpn where you don't have recourse to PMTUD). As the document notes (section 4= ) preventing fragmentation is rather important. > Stewart >=20 --GuGkHp4QL3d7iFsdeIdh6Hbc3lHN8oka2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLZldIACgkQ8AA1q7Z/VrLhogCdHy2PVsXywjUA9w7lZE0MCNmy xBsAnRqNZrp2CA75dUJgKFoiT8Aw8dMW =JzkE -----END PGP SIGNATURE----- --GuGkHp4QL3d7iFsdeIdh6Hbc3lHN8oka2-- From curtis@ipv6.occnc.com Fri Jan 17 13:21:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB6E1AD627 for ; Fri, 17 Jan 2014 13:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 NjENejGDENOW for ; Fri, 17 Jan 2014 13:21:56 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id ACD741ACD04 for ; Fri, 17 Jan 2014 13:21:55 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HLLRDH066328; Fri, 17 Jan 2014 16:21:27 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401172121.s0HLLRDH066328@maildrop2.v6ds.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Fri, 17 Jan 2014 19:19:33 +0000." <6618bdb86bb94b8b875ea43fb3906e3b@AM3PR03MB532.eurprd03.prod.outlook.com> Date: Fri, 17 Jan 2014 16:21:27 -0500 Cc: "mpls@ietf.org" Subject: Re: [mpls] mpls-in-udp entropy X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 21:21:59 -0000 In message <6618bdb86bb94b8b875ea43fb3906e3b@AM3PR03MB532.eurprd03.prod.outlook.com> Alexander Vainshtein writes: > Curtis, > > This may be a bit paranoid, but I am worried about "rogue" > applications like PTP 2-step transparent clock. A router running this > application, if it mistakenly associates a transit UDP packet as PTP > Delay_Resp based on Source UDP port (matching the UDP port assigned by > IANA for PTP) , may try to modify what it thinks to be the "correction > field" in its PTP header... > > Of course this should be a rare event, but still an extremely > unpleasant one. > > My 2c, > Sasha Sasha, Maybe off line you can tell me more about rogue PTP packet modifications. I think modifying packets based on their source UDP port doesn't happen. I admit not having looked but I think the destination port would have to indicate that the traffic was PTP. Also PTP over UDP uses a fixed multicast destination address so I think the packet would have to match that address. It is worth noting that I was also unable to find any RFC or draft (expired or not) about PTP over UDP in a quick search. You would think if widely implemented or if deployed anywhere that there would at least be an informational draft indicating that IEEE had done something. The only mention is in draft-ietf-tictoc-ptp-enterprise-profile-01, except for two expired drafts about MIBs. I think PTP over IP modifications in flight isn't all that widely supported if at all, but that is another story. If someone wants to correct me on that on list OK, but offline with the details please. I'm not aware of any other application where a UDP payload might be modified along the way. btw- port 319 and 320 for PTP are in the WKP region so if you avoided WKP numbers all would be OK even if there was such a thing as a unicast PTP that looked as src port and not dst port. Curtis btw- If anyone wants to discuss PTP in any detail, pleae take it to tictoc WG. > ________________________________________ > From: Curtis Villamizar > Sent: Friday, January 17, 2014 6:00 PM > To: Alexander Vainshtein > Cc: curtis@ipv6.occnc.com; erosen@cisco.com; mpls@ietf.org > Subject: Re: [mpls] mpls-in-udp entropy > > In message <75996b50f08c46b5b3809ee628dadcba@AM3PR03MB532.eurprd03.prod.outlook.com> > Alexander Vainshtein writes: > > > > Curtis, > > > > IMHO and FWIW it is preferable to allocate the entropy port from the > > Dynamic/Private space. 14K values should suffice for any reasonable > > ECMP scenarios. > > > > My 2c, > > Sasha > > The return address should be the sender and maybe it would be a good > idea to use port numbers that are not otherwise in use by the sender > in case something gets the packet and tries to reply, but even that is > extremely unlikely. For the source port to get abused the host at the > other end would have to be running the wrong service on that port and > trying to reply. Avoiding the WKP space might be a good idea only to > avoid a error reply to an error reply loop if both ends think they > have a WKP. Even if no loop is formed a misconfigured other end could > bombard your UDP socket space. Mistyping the dest address of the MPLS > over UDP tunnel could be quite harmfull but more likely to the other > end that has to drop a lot of misdirected packets. > > Absent severe misconfiguration where the destination has another > service on that port, even using the WKP space in the source port > would be OK. > > (BTW- A UDP packet with two WKPs was the basis for an old forged > packet denial of service attack before some of the very old low number > UDP echo and daytime type services were shut off by default. For this > reason it used to be useful to run sockstat -p udp -l and make sure > you understand what is running on which port and which UDP sockets > could potentially send a "badly formed packet" reply and create a > loop. These days you are unlikely to find this situation.). > > Curtis > > > ________________________________________ > > From: Curtis Villamizar > > Sent: Wednesday, January 15, 2014 10:56 PM > > To: Alexander Vainshtein > > Cc: erosen@cisco.com; mpls@ietf.org > > Subject: Re: [mpls] mpls-in-udp entropy > > > > In message <5b0765246d204750a50e1aad52a3b72e@AM3PR03MB532.eurprd03.prod.outlook.com> > > Alexander Vainshtein writes: > > > > > Eric, > > > Lots of thanks for a prompt and highly informative response. > > > > > > I have been actually thinking about the same thing, namely that the > > > entropy port should be the result of some hash over the label > > > stack. > > > > > > If this is indeed the intention of the authors, it would make sense > > > (at least, from my point of view) of saying so in the draft. There > > > is no need to make such a statement normative, but it would really > > > help the readers (both implementors and operators) to understand > > > what it is about. > > > > > > Regards, > > > Sasha > > > > Avoiding the lower 8K of the port number space might not be a bad idea > > to avoid a return port being a WKP including the non-root WKP space > > used by X-Windows and other things. > > > > Curtis > > > > > > > ________________________________________ > > > From: Eric Rosen > > > Sent: Wednesday, January 15, 2014 6:35 PM > > > To: Alexander Vainshtein > > > Cc: mpls@ietf.org > > > Subject: Re: mpls-in-udp entropy > > > > > > (Changed subject line and trimmed cc-list.) > > > > > > Sasha> I would like to understand whether this protocol can really result in > > > Sasha> reasonable distribution of traffic. "Reasonable" means that (a) there > > > Sasha> is sufficient entropy and (b) that the order in specific micro-flows > > > Sasha> is preserved. > > > > > > I thought the intention was that the encapsulator would set the UDP source > > > port based upon the entropy of the packet being encapsulated. This only > > > requires that the encapsulator know how to properly apply ECMP to the MPLS > > > packet that is being encapsulated. That is, compute the hash that would be > > > used to apply ECMP to the MPLS packet, and then map from that hash to a UDP > > > source port. > > > > > > E.g., two MPLS packets with the same entropy label would get the same UDP > > > source port, two MPLS packets with no entropy label but containing the same > > > TCP flow would get the same source port, etc. > > > > > > Do you think there is a problem here? > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From saku@ytti.fi Fri Jan 17 14:33:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F6A1ACCDF for ; Fri, 17 Jan 2014 14:33: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, 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 J8wNA8EEtNcn for ; Fri, 17 Jan 2014 14:33:01 -0800 (PST) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id B5B931ACCEA for ; Fri, 17 Jan 2014 14:33:00 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id r7so1846216bkg.21 for ; Fri, 17 Jan 2014 14:32:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ghRO5DRJKlNVgt4RvXMoNoXDkyNXVZev0O5yIWKwBnU=; b=J1AuLo91OhmtrVQYjcEeRHzZYSOCBjwddALD0pw1I8vX48azE9yl0WqkyXJzYjdG8F FMBnd/pO04YStd1+MD6LlvQWM8uuWTq/JIHqQ6O33/StCTuxZGs8ouhS5Dt+r4G0zfGt R1tDE5mHUmhcPc2KoXrkhtrEsUy3Ifvfg5PlSRcCw7wibEDZV72nhl1IELw3xq5xBNgV 4TSrxM3snyfrI0kN3dlc2RW+VOZpdIKlVQ+pVPuEZ+OntdmpQy92Uncy/odk08EEdYPd iesb3LQ8ZXoQHWT3F34uw3ChSxVhzEqpvrfDX0EZBM9smmrLzn8si1V85l9rV+MRpewG b0Ow== X-Gm-Message-State: ALoCoQmM7JWogk6pKeJ0lDYA2bVGRq7W3Um7SWe3MgFbAVQ7G/uTGjpEiPD44g5WWyZrRBF3siUX X-Received: by 10.205.10.66 with SMTP id oz2mr21880bkb.142.1389997966847; Fri, 17 Jan 2014 14:32:46 -0800 (PST) Received: from pob.ytti.fi (up.ip.fi. [2001:6e8:288::d]) by mx.google.com with ESMTPSA id d5sm10751384bkc.9.2014.01.17.14.32.45 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 Jan 2014 14:32:45 -0800 (PST) Date: Sat, 18 Jan 2014 00:32:43 +0200 From: Saku Ytti To: Curtis Villamizar Message-ID: <20140117223243.GA21841@pob.ytti.fi> References: <20140117163307.GA4577@pob.ytti.fi> <201401172028.s0HKSJP6065706@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401172028.s0HKSJP6065706@maildrop2.v6ds.occnc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mpls@ietf.org, lisp@ietf.org, tsvwg@ietf.org, ietf@ietf.org Subject: Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 22:33:03 -0000 On (2014-01-17 15:28 -0500), Curtis Villamizar wrote: > This sounds like a router acting as a host for the given packet. The > forwarding data paths in routers are usually protected. If the router This was transit packets ingressing as IP packet, egressing as MPLS packet. Consequently the peer router needed to touch TTL and checksum. Then generate new L2 frame. MPLS core obviously need not to worry about packet being broken, as frame is fine. > was forwarding and mangled packets, that speak well for the router > vendor since the major vendors claim to protect their data paths from Are such claims realistic or practical? I think it sounds like snakeoil when someone claims such absolutes. > this sort of thing. Less so for the path from the route processor. This was forwarding plane. > You've made a good anecdotal case for keeping TCP and UDP checksums. This would actually require IP checksum specifically, otherwise we would have probably never found it. If each egress PE suffers from it maybe once 30min, each customer suffers from it less than once a month, even if everyone would catch it and open trouble ticket, we couldn't correlate the cases to any single peering router, without having historic routing data for each egress PE. Disclaimer, I'm not for or against checksum/FCS in any particular layer, I've not thought about the matter deeply. It was just extremely timely thing in real-life network I wanted to share. -- ++ytti From l.wood@surrey.ac.uk Fri Jan 17 15:02:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F371ACCFC; Fri, 17 Jan 2014 15:02:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 jq-S5rQz7nl1; Fri, 17 Jan 2014 15:02:50 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) by ietfa.amsl.com (Postfix) with ESMTP id 16F501ACCEC; Fri, 17 Jan 2014 15:02:49 -0800 (PST) Received: from [195.245.231.67:50151] by server-16.bemta-5.messagelabs.com id 59/ED-11843-C86B9D25; Fri, 17 Jan 2014 23:02:36 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-7.tower-82.messagelabs.com!1389999756!28651413!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20611 invoked from network); 17 Jan 2014 23:02:36 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-7.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 17 Jan 2014 23:02:36 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Fri, 17 Jan 2014 23:02:35 +0000 From: To: Date: Fri, 17 Jan 2014 23:00:33 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8Tr7KVwfV8Zc1FQSC8mGxyu7YwzAAKDq3C Message-ID: <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk> References: Your message of "Fri, 17 Jan 2014 03:03:05 +0000." <290E20B455C66743BE178C5C84F1240847E63346CF@EXMB01CMS.surrey.ac.uk>, <201401171805.s0HI5kUC063603@maildrop2.v6ds.occnc.com> In-Reply-To: <201401171805.s0HI5kUC063603@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 23:02:52 -0000 Yes, it would be unreasonable for the router vendors themselves to design something with a trailing checksum and pseudo-header check that would meet their forwarding needs while ensuring reliability. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 17 January 2014 18:05 To: Wood L Dr (Electronic Eng) Cc: stbryant@cisco.com; lars@netapp.com; joelja@bogus.com; mpls@ietf.org; i= etf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard In message <290E20B455C66743BE178C5C84F1240847E63346CF@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > There's an opportunity to define a simple generic IPv6 encapsulating > mechanism a la UDP, but with a payload checksum of varying coverage > (header only, partial payload, full payload) and with the (stronger > than UDP) checksum placed at the end of the packet. > > Lloyd Wood > http://about.me/lloydwood Go for it! When a critical mass of routers hash on this new protocol number and port space we'll let you know and the MPLS WG can obsolete MPLS over UDP and replace it with MPLS over this new protocol. Thanks for offering to write this. Curtis > ________________________________________ > From: ietf [ietf-bounces@ietf.org] On Behalf Of Stewart Bryant [stbryant@= cisco.com] > Sent: 16 January 2014 17:35 > To: Eggert, Lars; Joel Jaeggli > Cc: mpls@ietf.org; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsula= ting MPLS in UDP) to Proposed Standard > > On 16/01/2014 17:19, Eggert, Lars wrote: > > Hi, > > > > On 2014-1-16, at 18:06, joel jaeggli wrote: > >> These tunnels are stateless > > yep. (But they don't have to be.) > Ah, they do if they are to scale. State at speed is really hard. The sort > of systems we are talking about do things like pipeline counters > and it is loooooots of packets later before the counter is actually > incremented. > >> The endpoints not the encapsulators have visibility into the > >> end-to-end loss latency properties of the path. > > Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 d= omains - where not reacting to congestion may be OK - can now go over the w= ider Internet, where this is not OK. > > > > I'd be great if those apps would change. But in the meantime, it's the = duty of the encapsulator - who enables this traffic to break out of an L2 d= omain and go over the wider net - to make sure the traffic it emits conform= s to our BCPs. > > > >> the encapsulator is an intermediate hop, similar to any other router > >> in the path. > > It's not. For the rest of the network, that encapsulator is indistingui= shable from any other app that sends UDP traffic. > > > > UDP is a transport-layer protocol, and we have practices how it is to b= e used on the net. If you want to use it for encapsulation, you bind yourse= lf to these BCPs. > > > > Look at it the other way: if transport area folks would want to send MP= LS packets into the network in some problematic way, I'm sure the routing a= nd ops folks would not be amused. > The root cause of the problem here is that UDP, has bifurcated into > a general purpose encapsulation. > > Stewart > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From mach.chen@huawei.com Fri Jan 17 22:52:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DFA1A1F56 for ; Fri, 17 Jan 2014 22:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 bllDRNi_oahd for ; Fri, 17 Jan 2014 22:52:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E9C501A1F1F for ; Fri, 17 Jan 2014 22:52:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCP73933; Sat, 18 Jan 2014 06:51:49 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 18 Jan 2014 06:50:56 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 18 Jan 2014 06:51:47 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Sat, 18 Jan 2014 14:51:39 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping Thread-Index: AQHPCQpE1PBOBWzj0kqicPNieRqIFZqKHe/A Date: Sat, 18 Jan 2014 06:51:39 +0000 Message-ID: References: <52C795FE.7060801@pi.nu> In-Reply-To: <52C795FE.7060801@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 06:52:07 -0000 Hi Authors, I just reviewed the draft, here are my comments, hope this help. General comments: It would be better if you could adjust the structure of the draft to put Se= ction 3 behind Section 5. Then the reader will not need to check definition= s of the Messages and TLVs in the back and then return back keep reading th= e document. Specific comments: 1. Section 2 If the source address of the MPLS echo request is not to be set to the Proxy Request source address, the initiator must include a Reply-to Address TLV containing the source address to use in the MPLS echo request. Why we need the Reply-to Address TLV? Which address will be included in the= Reply-to Address TLV? If the address is neither the initiror or the proxy = LSR, this may import some security isses? 2. Section 3.1 2.1=20 "The message MUST contain a Target FEC Stack that describes the FEC being tested. The topmost FEC in the target FEC stack is used at the Proxy LSR to lookup the MPLS label stack that will be used to encapsulate the MPLS echo request packet. " Seems that it only needs to carry the topmost FEC, and no need to carry oth= er FECs. And even if carried, it does not make sense. Right? 2.2 =20 s /MPLS Proxy Ping message/MPLS proxy ping request message, need to look th= rough the document to make them consistent.=20 3. Section 3.1 the sixth paragraph: "The Proxy Request reply mode is set with one of the reply modes defined in [RFC4379] as appropriate." Is the reply mode here referred to the reply mode of the MPLS proxy request= , or the reply mode of the Proxy Echo Parameter. I think it's the former, r= ight?=20 And section 5.1 said: "The MPLS Proxy Echo request echo header's Reply Mode should be set to "Rep= ly with Proxy Info"." Seems they are self-contradictory here.=20 4. Section 3.1 the last second paragraph: s /DDSMAP)/(DDSMAP) 5. Section 3.2, in the middle of the fourth paragraph. "Other filters on FECs or MPLS echo request contents MAY be applied." For a Proxy LSR, it will not receive any MPLS echo request, should it be th= e MPLS proxy ping request here? 6. Section 3.2.1 6.1 In the middle of third paragraph: "If the Proxy LSR is a Budnode but not requested to return a Proxy reply, the Proxy LSR should send packets to the downstream neighbors (no Echo reply is sent to the Proxy Initiator to indicate that the Proxy LSR is an egress). =20 " What packets will be sent to the downstream neighbors? 6.2=20 If there is no DS/DDMAPs returned, how does the initiator determine the pro= xy LSR is budnode or egress? 6.3 Last paragraph, last sentence s / M2MP leaf /MP2MP leaf 7. Section 3.2.4.1 7.1 What's is "base MPLS echo request"? I suggest to remove the "base" here= . 7.2=20 "If the Explicit Differentiated Services Code Point (DSCP) flag is set, the Requested DSCP byte is examined. If the setting is permitted then the DSCP byte of the IP header of the MPLS Echo Request message is set to that value. If the Proxy LSR does not permit explicit control for the DSCP byte, the MPLS Proxy Echo Parameters with the Explicit DSCP flag cleared MUST be included in any MPLS proxy ping reply message to indicate why an Echo Request was not sent. The return code MUST be set to , "Proxy ping parameters need to be modified". If the Explicit DSCP flag is not set, the Proxy LSR should set the Echo Request DSCP settings to the value normally used to source LSP ping packets." I am not sure whether this is the right choice to let the Proxy LSR to cont= rol whether the DSCP is permitted or not. IMO, this permission should be co= ntrolled by the Receiver or Responder. 8. Section 3.2.4.2 "If any additional labels are pushed onto the stack, their TTLs are set to 255." what's this case? Can you clarify more about the case? 9. Section 4.2 " The MPLS proxy ping request message MAY contain the following TLVs: " You may also need to contain the Type 21 and 22 TLV. 10.Section 5.1 s /MPLS Proxy Echo Request message /MPLS proxy ping request message, same a= s the above comment 2.2 Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Saturday, January 04, 2014 1:03 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-proxy-lsp-ping@tools.ietf= .org > Subject: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping >=20 > Working Group, >=20 > this is to start a two week working group last call on > draft-ietf-mpls-proxy-lsp-ping-01.txt >=20 > Please send your comments to working group mailing lists (mpls@ietf.org). >=20 > We will do an IPR poll on this document in parallel thee wglc. >=20 > There are three IPRs disclosures that relates to this document. >=20 > The working group last call will end Friday January 20, 2914. >=20 > /Loa > mpls wg co-chair >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Sat Jan 18 01:50:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B501ADE86 for ; Sat, 18 Jan 2014 01:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWCNA7gPJvKZ for ; Sat, 18 Jan 2014 01:50:45 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) by ietfa.amsl.com (Postfix) with ESMTP id E8C771AD935 for ; Sat, 18 Jan 2014 01:50:44 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB530.eurprd03.prod.outlook.com (10.242.109.154) with Microsoft SMTP Server (TLS) id 15.0.851.11; Sat, 18 Jan 2014 09:50:30 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Sat, 18 Jan 2014 09:50:30 +0000 From: Alexander Vainshtein To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] mpls-in-udp entropy Thread-Index: AQHPE8oUieRBwKl/XESIAXm8KkwTF5qKPMqr Date: Sat, 18 Jan 2014 09:50:29 +0000 Message-ID: <55c3eab9f8b849dfb837ffc6b951537b@AM3PR03MB532.eurprd03.prod.outlook.com> References: Your message of "Fri, 17 Jan 2014 19:19:33 +0000." <6618bdb86bb94b8b875ea43fb3906e3b@AM3PR03MB532.eurprd03.prod.outlook.com>, <201401172121.s0HLLRDH066328@maildrop2.v6ds.occnc.com> In-Reply-To: <201401172121.s0HLLRDH066328@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.66.126.123] x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(51704005)(189002)(199002)(377454003)(74876001)(4396001)(59766001)(50986001)(83072002)(66066001)(47736001)(19580405001)(74706001)(83322001)(81816001)(92566001)(15975445006)(90146001)(93136001)(86362001)(47976001)(56816005)(76576001)(93516002)(81542001)(33646001)(77982001)(53806001)(54316002)(76786001)(79102001)(2656002)(87936001)(74502001)(46102001)(85306002)(81686001)(85852003)(65816001)(74366001)(47446002)(54356001)(87266001)(80022001)(31966008)(80976001)(49866001)(51856001)(74316001)(76796001)(74662001)(76482001)(81342001)(56776001)(19580395003)(63696002)(69226001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB530; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:109.66.126.123; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Cc: "mpls@ietf.org" Subject: Re: [mpls] mpls-in-udp entropy X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 09:50:50 -0000 Curtis,=0A= =0A= =0A= I will provide more detailed explanation of what PTP transparent Clock is s= upposed to do to a transit packet offline.=0A= One thing that iz worth noting on the list is that Delay Request and Delay = Response packets are unicast (between a specific Slave clock and a specifi= c Master clock. Sync and Follow-up can be multicast or unicast.=0A= =0A= Regards,=0A= Sasha=0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Friday, January 17, 2014 11:21 PM=0A= To: Alexander Vainshtein=0A= Cc: curtis@ipv6.occnc.com; erosen@cisco.com; mpls@ietf.org=0A= Subject: Re: [mpls] mpls-in-udp entropy=0A= =0A= In message <6618bdb86bb94b8b875ea43fb3906e3b@AM3PR03MB532.eurprd03.prod.out= look.com>=0A= Alexander Vainshtein writes:=0A= =0A= > Curtis,=0A= >=0A= > This may be a bit paranoid, but I am worried about "rogue"=0A= > applications like PTP 2-step transparent clock. A router running this=0A= > application, if it mistakenly associates a transit UDP packet as PTP=0A= > Delay_Resp based on Source UDP port (matching the UDP port assigned by=0A= > IANA for PTP) , may try to modify what it thinks to be the "correction=0A= > field" in its PTP header...=0A= >=0A= > Of course this should be a rare event, but still an extremely=0A= > unpleasant one.=0A= >=0A= > My 2c,=0A= > Sasha=0A= =0A= =0A= Sasha,=0A= =0A= Maybe off line you can tell me more about rogue PTP packet=0A= modifications. I think modifying packets based on their source UDP=0A= port doesn't happen. I admit not having looked but I think the=0A= destination port would have to indicate that the traffic was PTP.=0A= Also PTP over UDP uses a fixed multicast destination address so I=0A= think the packet would have to match that address.=0A= =0A= It is worth noting that I was also unable to find any RFC or draft=0A= (expired or not) about PTP over UDP in a quick search. You would=0A= think if widely implemented or if deployed anywhere that there would=0A= at least be an informational draft indicating that IEEE had done=0A= something. The only mention is in=0A= draft-ietf-tictoc-ptp-enterprise-profile-01, except for two expired=0A= drafts about MIBs.=0A= =0A= I think PTP over IP modifications in flight isn't all that widely=0A= supported if at all, but that is another story. If someone wants to=0A= correct me on that on list OK, but offline with the details please.=0A= =0A= I'm not aware of any other application where a UDP payload might be=0A= modified along the way.=0A= =0A= btw- port 319 and 320 for PTP are in the WKP region so if you avoided=0A= WKP numbers all would be OK even if there was such a thing as a=0A= unicast PTP that looked as src port and not dst port.=0A= =0A= Curtis=0A= =0A= btw- If anyone wants to discuss PTP in any detail, pleae take it to=0A= tictoc WG.=0A= =0A= =0A= > ________________________________________=0A= > From: Curtis Villamizar =0A= > Sent: Friday, January 17, 2014 6:00 PM=0A= > To: Alexander Vainshtein=0A= > Cc: curtis@ipv6.occnc.com; erosen@cisco.com; mpls@ietf.org=0A= > Subject: Re: [mpls] mpls-in-udp entropy=0A= >=0A= > In message <75996b50f08c46b5b3809ee628dadcba@AM3PR03MB532.eurprd03.prod.o= utlook.com>=0A= > Alexander Vainshtein writes:=0A= > >=0A= > > Curtis,=0A= > >=0A= > > IMHO and FWIW it is preferable to allocate the entropy port from the=0A= > > Dynamic/Private space. 14K values should suffice for any reasonable=0A= > > ECMP scenarios.=0A= > >=0A= > > My 2c,=0A= > > Sasha=0A= >=0A= > The return address should be the sender and maybe it would be a good=0A= > idea to use port numbers that are not otherwise in use by the sender=0A= > in case something gets the packet and tries to reply, but even that is=0A= > extremely unlikely. For the source port to get abused the host at the=0A= > other end would have to be running the wrong service on that port and=0A= > trying to reply. Avoiding the WKP space might be a good idea only to=0A= > avoid a error reply to an error reply loop if both ends think they=0A= > have a WKP. Even if no loop is formed a misconfigured other end could=0A= > bombard your UDP socket space. Mistyping the dest address of the MPLS=0A= > over UDP tunnel could be quite harmfull but more likely to the other=0A= > end that has to drop a lot of misdirected packets.=0A= >=0A= > Absent severe misconfiguration where the destination has another=0A= > service on that port, even using the WKP space in the source port=0A= > would be OK.=0A= >=0A= > (BTW- A UDP packet with two WKPs was the basis for an old forged=0A= > packet denial of service attack before some of the very old low number=0A= > UDP echo and daytime type services were shut off by default. For this=0A= > reason it used to be useful to run sockstat -p udp -l and make sure=0A= > you understand what is running on which port and which UDP sockets=0A= > could potentially send a "badly formed packet" reply and create a=0A= > loop. These days you are unlikely to find this situation.).=0A= >=0A= > Curtis=0A= >=0A= > > ________________________________________=0A= > > From: Curtis Villamizar =0A= > > Sent: Wednesday, January 15, 2014 10:56 PM=0A= > > To: Alexander Vainshtein=0A= > > Cc: erosen@cisco.com; mpls@ietf.org=0A= > > Subject: Re: [mpls] mpls-in-udp entropy=0A= > >=0A= > > In message <5b0765246d204750a50e1aad52a3b72e@AM3PR03MB532.eurprd03.prod= .outlook.com>=0A= > > Alexander Vainshtein writes:=0A= > >=0A= > > > Eric,=0A= > > > Lots of thanks for a prompt and highly informative response.=0A= > > >=0A= > > > I have been actually thinking about the same thing, namely that the= =0A= > > > entropy port should be the result of some hash over the label=0A= > > > stack.=0A= > > >=0A= > > > If this is indeed the intention of the authors, it would make sense= =0A= > > > (at least, from my point of view) of saying so in the draft. There=0A= > > > is no need to make such a statement normative, but it would really=0A= > > > help the readers (both implementors and operators) to understand=0A= > > > what it is about.=0A= > > >=0A= > > > Regards,=0A= > > > Sasha=0A= > >=0A= > > Avoiding the lower 8K of the port number space might not be a bad idea= =0A= > > to avoid a return port being a WKP including the non-root WKP space=0A= > > used by X-Windows and other things.=0A= > >=0A= > > Curtis=0A= > >=0A= > >=0A= > > > ________________________________________=0A= > > > From: Eric Rosen =0A= > > > Sent: Wednesday, January 15, 2014 6:35 PM=0A= > > > To: Alexander Vainshtein=0A= > > > Cc: mpls@ietf.org=0A= > > > Subject: Re: mpls-in-udp entropy=0A= > > >=0A= > > > (Changed subject line and trimmed cc-list.)=0A= > > >=0A= > > > Sasha> I would like to understand whether this protocol can really re= sult in=0A= > > > Sasha> reasonable distribution of traffic. "Reasonable" means that (a= ) there=0A= > > > Sasha> is sufficient entropy and (b) that the order in specific micro= -flows=0A= > > > Sasha> is preserved.=0A= > > >=0A= > > > I thought the intention was that the encapsulator would set the UDP s= ource=0A= > > > port based upon the entropy of the packet being encapsulated. This o= nly=0A= > > > requires that the encapsulator know how to properly apply ECMP to the= MPLS=0A= > > > packet that is being encapsulated. That is, compute the hash that wo= uld be=0A= > > > used to apply ECMP to the MPLS packet, and then map from that hash to= a UDP=0A= > > > source port.=0A= > > >=0A= > > > E.g., two MPLS packets with the same entropy label would get the same= UDP=0A= > > > source port, two MPLS packets with no entropy label but containing th= e same=0A= > > > TCP flow would get the same source port, etc.=0A= > > >=0A= > > > Do you think there is a problem here?=0A= > > > _______________________________________________=0A= > > > mpls mailing list=0A= > > > mpls@ietf.org=0A= > > > https://www.ietf.org/mailman/listinfo/mpls=0A= =0A= From loa@pi.nu Sat Jan 18 04:53:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7351A1F5F for ; Sat, 18 Jan 2014 04:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 4NCMUC0YHSoH for ; Sat, 18 Jan 2014 04:53:40 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id BAB3C1A1F1A for ; Sat, 18 Jan 2014 04:53:40 -0800 (PST) Received: from [192.168.1.3] (unknown [49.147.219.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 72B7918029FB; Sat, 18 Jan 2014 13:53:25 +0100 (CET) Message-ID: <52DA7941.6060908@pi.nu> Date: Sat, 18 Jan 2014 20:53:21 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201401171657.s0HGvtYW062709@maildrop2.v6ds.occnc.com> In-Reply-To: <201401171657.s0HGvtYW062709@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] IPR poll on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 12:53:43 -0000 Curtis, You don't need to do an IPR search, we are asking about what you know. Meaning that if you have been involved in IPR development that relates to your draft you have to disclose that; also if someone told told that he or she know about an IPR tht needs to be disclosed also. /Loa On 2014-01-18 00:57, Curtis Villamizar wrote: > Loa, > > I know of no IPR on this documnet. > > There may be IPR disclosed by others on some of the referenced RFCs. > I didn't check. Should I? > > Curtis > > > In message <52D77069.2050405@pi.nu> > Loa Andersson writes: > > Working Group, > > we have just requested publication of draft-ietf-mpls-forwarding-04. > > Since the IPR poll on the individual document is fairly recent, we will > do the final poll in parallel to the initial steps of post publication > request steps. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-forwarding? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are three IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobo@cisco.com Sun Jan 19 09:03:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F308C1ADF86 for ; Sun, 19 Jan 2014 09:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.14 X-Spam-Level: X-Spam-Status: No, score=-13.14 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 SjGe21wqqLm3 for ; Sun, 19 Jan 2014 09:03:04 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8E51ADF70 for ; Sun, 19 Jan 2014 09:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12257; q=dns/txt; s=iport; t=1390150971; x=1391360571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oqSAnMTtjLsSut26BRrtumou/pzJHV/OI96+F1QUECM=; b=eM5QncOMR1ktxoM6BDOCY2hC5KKvkCqxnZUopSetU4Rp9zhmDXe9yXw3 Bp/y9z5J/Cx9KkUR9IrXkcb2UB6cB4GarOijnMTjcm/h2q/0VM0o7pHn3 2tYhBeyhbjEe1TI4g/WCDM6P8f2njFmGjdu0JRW97k5M4kTfPnRPtiBbH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FANsE3FKtJXHA/2dsb2JhbABZgmohgQ67NoEGFnSCJQEBAQMBDiwrAhIFCwIBCCIUBQsyJQIEAQ0Nh3UIAcQTF44nJzEHgySBFASqOoFvgT6BaEI X-IronPort-AV: E=Sophos;i="4.95,685,1384300800"; d="scan'208";a="298300826" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 19 Jan 2014 17:02:50 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0JH2oOg009877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Jan 2014 17:02:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sun, 19 Jan 2014 11:02:50 -0600 From: "Nobo Akiya (nobo)" To: "curtis@ipv6.occnc.com" , Loa Andersson Thread-Topic: Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping Thread-Index: AQHPE0I6qNAJ0+0KI0u/55coQMgJMJqMLZBg Date: Sun, 19 Jan 2014 17:02:49 +0000 Message-ID: References: Your message of "Fri, 03 Jan 2014 16:22:33 +0800." <52C67349.4020701@pi.nu> <201401170508.s0H585kF051738@maildrop2.v6ds.occnc.com> In-Reply-To: <201401170508.s0H585kF051738@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org" , Curtis Villamizar , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 17:03:07 -0000 Hi Curtis, Thanks for detailed comments. > Overall a good draft and should become a WG doc as it is an improvement > to a fairly badly designed feature of MPLS Ping that remains fairly badly > designed but now a little less broken for ELI/EL. >=20 > I'm not sure the procedures that are defined work correctly if an LSR doe= s > load split on the label stack (or part of it) up to and then including th= e EL, > but nothing after the EL. There seems to be an assumption that only the = EL > is used if present. The way the RFC 6790 reads the search for entropy st= ops > at the EL (a SHOULD that would have been better made a MUST). Assumption here is that label stack up to ELI/EL is constant for LSP tracin= g purpose, thus defined procedure will work whether transit LSR load balanc= es on just (EL) or (label stack up to EL + EL). This assumption is most pro= bably worth being mentioned in the document, and we will plan to do so. The other tricky aspect depends on the outcome of draft-ravisingh-mpls-el-f= or-seamless-mpls. If multiple ELI/ELs are allowed in the label stack, and t= here are no clear defined forwarding rule on load balancing in that case, t= hen defined procedures will not work, since we now have 2 (or more) non-con= stant values. I spoke to R. Singh and Y. Shen at Vancouver and communicated= this concern on from OAM perspective. >=20 > Some (big) issues: >=20 > {L=3D0, E=3D0} LSR load balances based on IP and does not push ELI/EL. > {L=3D0, E=3D1} LSR load balances based on IP and pushes ELI/EL. > {L=3D1, E=3D0} LSR load balances based on label and does not push ELI/E= L. > {L=3D1, E=3D1} LSR load balances based on label and pushes ELI/EL. >=20 > What about the case where the LSR load balances on both labels and on IP? > If the payload is IP, the entropy from the IP header is used *in addition= to* > the entropy from the label stack. You are right, that is still allowed by RFC6790. [snip] Some transit LSRs look beyond the label stack for better load- balancing information. This is a simple, backward-compatible approach in networks where some ingress LSRs impose ELs and others don't. However, this is of limited incremental value if an EL is indeed present and requires more packet processing from the LSR. A transit LSR MAY choose to parse the label stack for the presence of the ELI and look beyond the label stack only if it does not find it, thus retaining the old behavior when needed, yet avoiding unnecessary work if not needed. [snip] Adding LSP traceroute support for such will require [even more] complexitie= s in the tools, which I personally would prefer to avoid if possible. I'd l= ike to hear from WG on this, particularly those implementing ELI/EL. If the= re are any vendors looking at EL + IP for load balancing when EL is present= , and if we want this scenario to also be supported by LSP traceroute, then= we need to address this. >=20 > There should also be a flag to indicate that the LSR will terminate the s= earch > for entropy at the EL as it SHOULD according to RFC 6790. Wouldn't such flag potentially cause load balancing deviation between traff= ic vs. MPLS echo request? >=20 > The flags points to an issue with RFC 4379 even without ELI/EL that is st= ill > not addressed here. What if the typical payload contains both additional > labels (payload is MPLS) and IP under the labels and some LSR look at onl= y > the IP and some look at only the labels and some look at both and some > that look at labels can only look at the top N or the bottom N labels. Prior to this draft, supported scenarios were: 1. LSP which all LSR load balances just on IP as entropy. 2. LSP which all LSR load balances just on label stack as entropy. With this draft, we intend to add support for following scenario. 3. LSP which all LSR load balances on IP as entropy OR label stack as entro= py (assuming constant label stack + one EL). 4. Stitched/Hierarchical LSPs with ELI/EL push/pop operations by transit no= des. Which both scenario a very likely realistic scenario. Agree that there are many load balance implementations possibilities. I wis= h there was a clear load balance rules defined from the beginning. I also w= ish there _is_ a clear load balance rules defined today ... is there one? W= ithout clear defined rules, OAM is placed in a very difficult position: i.e= . solving all theoretically possible scenarios will significantly complicat= e the tools to the point where desire to implement will likely significantl= y diminish. All this to say, your comment raises a great point that perhaps we should t= ake a step back and find out the realistic combinations which WG plans to s= olve from OAM perspective. >=20 > Also the max depth in RFC 4379 is inadequate since some LSR can look at > labels up to some depth D1 and can find an IP header if it appears at up = to > some depth D2 and D1 !=3D D2. These two depths are not independent in RF= C > 4379. Noted. >=20 > A few additional flags and values need to be carried if these cases are a= ll to > be covered. OTOH, RFC 4379 works fine for a single vendor network if all > their products behave in the same way. >=20 > This draft acknowledges that there are some issues (including with > E=3D0 that existing in RFC 4379 prior to ELI/EL) but doesn't fix them eve= n > though they are fixable: >=20 > In following conditions, initiating LSR may have lost the ability > to exercise specific ECMP paths. Initiating LSR MAY continue with > "best effort". >=20 > o Received echo reply contains empty multipath information. >=20 > o Received echo reply contains {L=3D0, E=3D} DS flags, but does > not contain IP multipath information. >=20 > o Received echo reply contains {L=3D1, E=3D} DS flags, but does > not contain label multipath information. >=20 > o Received echo reply contains {L=3D, E=3D1} DS flags, but does > not contain associated label multipath information. >=20 > o IP multipath information types {2, 4, 8} sent, and received echo > reply with {L=3D1, E=3D0} in DS flags. >=20 > o Multipath information type {10} sent, and received echo reply > with multipath information type other than {10}. Correct, we acknowledge the scenarios which we do not support. This goes ba= ck to the point [above] of what scenarios we want to fix. We can use some h= elp from WG to define this space. >=20 > On the topic of flags, the N bit was always problematic. When TTL is > incremented the LSR will behave as if the packet is IP, because it is. Interesting point, didn't think about this one, but yes I agree, it's troub= lesome. >=20 > The flags and defined behavior for this failure is an improvement over RF= C > 4379 where the behavior was undefined both in terms of what to put in the > reply and how the initiator should interpret it. >=20 > Througout the document it is not clear what an IP load balancer is. > For example:` >=20 > o When initiating LSR is IP based load balancer (not pushing ELI/ > EL), initialize EL_LSP=3DFalse. >=20 > The initiating LSR may be a carrying MPLS traffic (ie: a PSC LSP). > Therefore is may get traffic that already has an ELI/EL in the stack. >=20 > This is not worded clearly for the case where the LSR is capable of IP ba= sed > load balance but is not pushing an ELI/EL but it has already seen an ELI/= EL > on the stack. Need to clarify whether the LSR is an "IP based load balan= cer" > if it is capable of IP based load balance or if it would have done IP bas= ed > load balance on this stack. To trace the LSP starting from such LSR, I don't believe *stitching behavio= r* of the LSR is not relevant. Yes such LSR can be egress of ELC LSP, but [= some] packets MAY or MAY NOT come in with ELI/EL, when ELI/EL is pushed is = up to ingress to decide. If we want to diagnose the *stitching behavior* of= the LSR, we will have to initiate the LSP traceroute from prior LSP. >=20 > The term "IP Based Load Balancer" is never defined. >=20 > The term "Label Based Load Balancer" is never defined. Good point. We will add a terminology for those. >=20 > It is not clear which to pick if an LSR can use both types of information= as > would be the case for many routers when no ELI/EL is found in the stack. This one, again, goes back to the problem-space point above. >=20 > In "9. Unsupported Cases" you might as well admit "won't ever work for > some vendor's equipment that uses the whole label stack to load balance > plus can use IP stack". ACK. Until problem-space is defined, we will clarify these assumption which= proposal is intended work. > The two unsupported cases are: >=20 > o When one or more LSP transit node(s) performs label based load > balancing on a label that is not bottom-of-stack label when > Entropy Label Indicator is not included. >=20 > A lot of equipment uses all of the labels. Did you means does not use th= e > bottom label? Good point. We will rephrase above. >=20 > o When one or more LSP transit node(s) performs label based load > balancing on a label other than Entropy Label when Entropy Label > Indicator and Entropy Label pair is included. >=20 > It is also legal (and I think preferred) to use all of the labels up to a= nd > including the first EL (but not the ELI and any other reserved label). D= id you > means a label after the EL? It would be a good idea to rephrase above as well, thank you for pointing t= his out. >=20 > Either these unsupported cases are worded wrong or something is very > seriously wrong with LSP Ping. >=20 > Some minor points: >=20 > RFC 6424 should be mentioned as soon as RFC 4379 is mentioned in the > intro since RFC 6424 changes RFC 4379 behavior and depricated a RFC > 4379 TLV and replaces it. ACK. >=20 > When an MPLS echo request message is received containing a > FEC-Stack with an EL-FEC at the bottom of the FEC stack and is not > preceded by an entropy label, the responder must behave (for load > balancing purposes) as if the first word of the message were a > Pseudowire Control Word. >=20 > This is asking for the DD-MAP or DS-MAP response to be constructed as if > CW was at bottom, but doesn't read that way. It reads as if forwarding w= as > changed. I will check with George on this, but I believe what he meant was: When an MPLS echo request message is received containing a FEC-Stack with an EL-FEC at the bottom of the FEC stack and is not preceded by an Nil-FEC indicating ELI, the responder must behave=20 (for load balancing purposes) as if the first word of the message=20 were a Pseudowire Control Word. >=20 > Note that this procedure only traces to the end of the MPLS LSP at > transport layer (e.g. LDP and/or RSVP). >=20 > That is not what "transport layer" means to a lot of people. Very bad > wording. Sorry for newbie mistake. Any wording you can suggest? >=20 > * Else initiating LSR MUST use multipath information type {2, > 4, 8, 9}. >=20 > Exactly what should it do if load balance is affected by *either* another > label on the stack or a different IP under the stack? What if both peice= s of > information are used in creating load balance entropy > (ie: what if the IP map depends on any additional labels)? Yes, let's get consensus on problem-space first. >=20 > Nits: >=20 > s/indicate and entropy/indicate and entropy/ Thanks & ACK on s/indicate and entropy/indicate an entropy/ >=20 > In "5.2. IP Based Load Balancer & Pushes ELI/EL" third bullet is a massi= ve > run-on paragraph. Split into sub-bullets for the multiple case within it= . > Probably good for other bullets containing more than one sentence startin= g > with "If". Ok, will do. And again, thank you for providing detailed comments!! -Nobo >=20 > probably plenty more nits that I missed. >=20 > Curtis From internet-drafts@ietf.org Sun Jan 19 16:59:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1C1A0015; Sun, 19 Jan 2014 16:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 NSQf5K-V7X85; Sun, 19 Jan 2014 16:59:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B271A0002; Sun, 19 Jan 2014 16:59:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140120005902.22790.27186.idtracker@ietfa.amsl.com> Date: Sun, 19 Jan 2014 16:59:02 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-psc-itu-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 00:59:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS Transport Profile (MPLS-TP) Linear Protectio= n to Match the Operational Expectations of SDH, OTN and Ethernet Transport = Network Operators Authors : Jeong-dong Ryoo Eric Gray Huub van Helvoort Alessandro D'Alessandro Taesik Cheung Eric Osborne Filename : draft-ietf-mpls-tp-psc-itu-01.txt Pages : 39 Date : 2014-01-19 Abstract: This document describes alternate mechanisms to perform some of the sub-functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-psc-itu-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-psc-itu-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ryoo@etri.re.kr Sun Jan 19 17:34:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9063C1A0015 for ; Sun, 19 Jan 2014 17:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.246 X-Spam-Level: X-Spam-Status: No, score=-100.246 tagged_above=-999 required=5 tests=[HTML_FONT_FACE_BAD=0.289, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 pv-e57Z2p6iR for ; Sun, 19 Jan 2014 17:34:30 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 611281A0010 for ; Sun, 19 Jan 2014 17:34:29 -0800 (PST) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Jan 2014 10:34:27 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP3.etri.info ([169.254.157.203]) with mapi id 14.01.0355.002; Mon, 20 Jan 2014 10:34:25 +0900 From: "Ryoo, Jeong-dong" To: "mpls@ietf.org" Thread-Topic: Summary of the changes in 01 version of draft-ietf-mpls-tp-psc-itu Thread-Index: Ac8Vf8DSUgTW+9UGS0SUM7V8gO0qmw== Date: Mon, 20 Jan 2014 01:34:25 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B258B@SMTP2.etri.info> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B258BSMTP2etriinfo_" MIME-Version: 1.0 Subject: [mpls] Summary of the changes in 01 version of draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 01:34:32 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B258BSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbC4NCg0KImRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAxIiBpcyBzdWJtaXR0ZWQs IGFuZCB0aGlzIGVtYWlsIGlzIHRvIGdpdmUgeW91IHRoZSBzdW1tYXJ5IG9mIHRoZSBjaGFuZ2Vz IG1hZGUgaW4gdGhpcyB2ZXJzaW9uLg0KSWYgeW91IGhhdmUgYW55IGNvbW1lbnRzLCBwbGVhc2Ug bGV0IHVzIGtub3cuDQoNCkJlc3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQojIyMgU3VtbWFy eSBvZiB0aGUgY2hhbmdlcyAjIyMNCjEuIFRoZSB0aXRsZSBoYXMgYmVlbiBjaGFuZ2VkIGZyb20g 4oCcTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbiBpbiBTdXBwb3J0IG9mIElUVS1UJ3MgUmVxdWly ZW1lbnRz4oCdIHRvIOKAnE1QTFMtVFAgTGluZWFyIFByb3RlY3Rpb24gdG8gTWF0Y2ggdGhlIE9w ZXJhdGlvbmFsIEV4cGVjdGF0aW9ucyBvZiBTREgsIE9UTiBhbmQgRXRoZXJuZXQgVHJhbnNwb3J0 IE5ldHdvcmsgT3BlcmF0b3Jz4oCdLiBBY2NvcmRpbmdseSwgdGhlIHBocmFzZSBvZiDigJxtZWV0 IHRoZSBJVFUtVOKAmXMgKHByb3RlY3Rpb24pIHJlcXVpcmVtZW50c+KAnSBoYXMgYmVlbiByZXBs YWNlZCBpbiB3aG9sZSBkb2N1bWVudC4gVGhpcyBjaGFuZ2UgaGFzIGJlZW4gbWFkZSB0byByZXNv bHZlIHRoZSBpc3N1ZSBvbiB0aGUg4oCcSVRVLVTigJlzIHJlcXVpcmVtZW50c+KAnSByYWlzZWQg YnkgbWFueSBwZW9wbGUuDQoyLiBUaGUgQWJzdHJhY3QgaGFzIGJlZW4gcmVwbGFjZWQgd2l0aCB0 aGUgbmV3IHRleHQgKHByb3Bvc2VkIGJ5IEFkcmlhbikgYWZ0ZXIgdHJpbW1pbmcgb2ZmIHNvbWUg dGV4dCB0byBtZWV0IHRoZSAyMCBsaW5lIGxpbWl0YXRpb24uIFRoZSB0ZXh0IHRoYXQgaGFzIGJl ZW4gdHJpbW1lZCBhcHBlYXJzIGluIHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbi4NCjMuIFRoZSBJ bnRyb2R1Y3Rpb24gc2VjdGlvbiBoYXMgYmVlbiBjaGFuZ2VkIHRvIHJlZmxlY3QgdGhlIEFkcmlh buKAmXMgcHJvcG9zZWQgdGV4dCBhbmQgdGhlIGZlZWRiYWNrcyB0aGF0IExvYSBoYWQgYmVlbiBy ZWNlaXZlZCBmcm9tIHRoZSBwZW9wbGUgd2l0aCBkaWZmZXJlbnQgYmFja2dyb3VuZHMuDQo0LiBJ biBTZWN0aW9uIDcuMywgdGhlIGJlaGF2aW9yIG9mIHByb3RlY3Rpb24gYWdhaW5zdCBTRCAodGhl IGlzc3VlIHJhaXNlZCBieSBZYWFjb3YpIGlzIHJld3JpdHRlbiB0byBtYWtlIHN1cmUgdGhhdCB0 aGUgU0QgcHJvdGVjdGlvbiBpcyBpbmRlcGVuZGVudCBvZiB0aGUgU0QgZGV0ZWN0aW9uIG1lY2hh bmlzbS4gVGhlIG5ldyB0ZXh0IGlzIHRoZSBzYW1lIGFzIHRoZSBvbmUgdGhhdCBJIHByb3Bvc2Vk IGluIG15IHByZXZpb3VzIGVtYWlsIHRvIHRoZSBNUExTIFdHIGxpc3Qgb24gSmFuLiAxNC4NCjUu IEluIFNlY3Rpb24gNy4zLCB0aGUgMToxIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJlIGZvciB0aGUg c2VsZWN0b3IgYnJpZGdlIHdpdGggcGFja2V0IGR1cGxpY2F0aW9uIGhhcyBiZWVuIGNsYXJpZmll ZCB0byByZWZsZWN0IHRoZSBjb21tZW50IGFwcGVhcmVkIGluIHRoZSBXRyBsaXN0IChmcm9tIFFp biBXdSkuDQo2LiBUaGUgZGVzY3JpcHRpb25zIG9uIHNpbXVsdGFuZW91cyByZXF1ZXN0cyAoTVMg YW5kIFNEKSBpbiBTZWN0aW9uIDcuMyBhbmQgZXF1YWwgcHJpb3JpdHkgcmVzb2x1dGlvbiBhbmQg aW4gU2VjdGlvbiA3LjQgYXJlIHJld3JpdHRlbiBmb3IgYmV0dGVyIGNsYXJpZmljYXRpb24sIGFu ZCB0aGUgc2ltaWxhciB0ZXh0cyB0aGF0IGhhdmUgYmVlbiBhcHBlYXJlZCB0d28gZGlmZmVyZW50 IHBsYWNlcyBhcmUgbWVyZ2VkLg0KNy4gVGhlIGV4ZW1wbGFyeSBDYXBhYmlsaXRpZXMgVExWIHNl dHMgaW4gU2VjdGlvbiA5LjEuMy4zIGFyZSBjaGFuZ2VkIHRvIGZvbGxvdyB0aGUgY2FwYWJpbGl0 eSBiaXQgYXNzaWdubWVudCBjb3JyZWN0bHkuDQo4LiBJbiBTZWN0aW9uIDEwLjIsIHRoZSBvcGVy YXRpb25zIG9mIHByaW9yaXR5IGV2YWx1YXRpb24gYW5kIHN0YXRlIHRyYW5zaXRpb24gdGFibGUg bG9va3VwIGFyZSBjbGFyaWZpZWQuDQo5LCBJbiBTZWN0aW9uIDEwLjIsIHRoZSBkZXNjcmlwdGlv biBvbiB0aGUgcHJpb3JpdGllcyBvZiBsb2NhbCBpbnB1dHMgYW5kIHJlbW90ZSByZXF1ZXN0cyBp cyBhZGRlZCBmb3IgYmV0dGVyIGNsYXJpZmljYXRpb24uDQoxMC4gSW4gU2VjdGlvbiAxMC4yLCB0 aGUgb3BlcmF0aW9uIG9mIGVxdWFsIHByaW9yaXR5IHJlc29sdXRpb24gaXMgY2xhcmlmaWVkLg0K MTEuIEluIFNlY3Rpb24gMTAuMiwgdGhlIHByaW9yaXR5IGV2YWx1YXRpb24gYmV0d2VlbiBsb2Nh bCBubyByZXF1ZXN0IGFuZCByZW1vdGUgbm8gcmVxdWVzdCBpcyBhZGRlZCB0byBwZXJmb3JtIHRo ZSBzdGF0ZSB0cmFuc2l0aW9uIHRhYmxlIGxvb2t1cCBjb3JyZWN0bHkuDQoxMi4gU2VjdGlvbiAx MC4zIGlzIG5ld2x5IGFkZGVkIHRvIGRlc2NyaWJlIHRoZSBhY2NlcHRhbmNlIGFuZCByZXRlbnRp b24gb2YgbG9jYWwgaW5wdXRzLg0KMTMuIEluIFNlY3Rpb24gMTEsIHRoZSBzdGF0ZSB0cmFuc2l0 aW9uIHRhYmxlcyBoYXZlIGJlZW4gZml4ZWQgZm9yIGNvcnJlY3QgcHJvdG9jb2wgb3BlcmF0aW9u cy4NCjE0LiBJbiBTZWN0aW9uIDExLCBhIG5ldyB0cmFuc2l0aW9uIChjZWxsKSBpcyByZS1kZWZp bmVkIHRvIGd1YXJhbnRlZSBpbnRlcndvcmtpbmcgYmV0d2VlbiByZXZlcnRpdmUgYW5kIG5vbi1y ZXZlcnRpdmUgb3BlcmF0aW9ucy4NCjE1LiBJbiBTZWN0aW9uIDExLCB0aGUgZm9vdG5vdGVzIGZv ciB0aGUgc3RhdGUgdHJhbnNpdGlvbiB0YWJsZXMgYXJlIGRpdmlkZWQgYW5kIHBsYWNlZCBiZWxv dyB0aGUgbG9jYWwgdGFibGUgYW5kIHRoZSByZW1vdGUgdGFibGUgc2VwYXJhdGVseS4NCjE2LiBU aGUgZm9vdG5vdGUgdGV4dHMgZm9yIHJlbW90ZSBTRCByZXF1ZXN0cyBhcmUgbW9kaWZpZWQgdG8g Zml4IHNvbWUgYnVncywgYW5kIGFsc28gdG8gZGVjb3VwbGUgdGhlIHN0YXRlIHRyYW5zaXRpb24g dGFibGUgbG9va3VwIGZyb20gdGhlIHByaW9yaXR5IGV2YWx1YXRpb24gZm9yIFNEIHJlcXVlc3Qu DQoxNy4gU2VjdGlvbiAxMS4zIGlzIG5ld2x5IGFkZGVkIHRvIGRlZmluZSB0aGUgc3RhdGUgdHJh bnNpdGlvbiBmb3IgMSsxIHVuaWRpcmVjdGlvbmFsIHByb3RlY3Rpb24uDQoxOC4gU2VjdGlvbiAx MiBpcyBuZXdseSBhZGRlZCB0byBkZXNjcmliZSB0aGUgb3BlcmF0aW9ucyBpbiBjYXNlcyBvZiBw cm92aXNpb25pbmcgbWlzbWF0Y2ggYW5kIHByb3RvY29sIGZhaWx1cmVzIGluIHRoZSBBUFMgbW9k ZS4NCjE5LiBTZWN0aW9uIDE0IChJQU5BIGNvbnNpZGVyYXRpb25zKSBpcyByZXdyaXR0ZW4sIGFu ZCB0aGUgZWRpdG9y4oCZcyBub3RlIGlzIHJlcGxhY2VkIHdpdGggdGhlIGFjdHVhbCB0ZXh0IGZv ciBhIG5ldyByZWdpc3RyeSwg4oCcTVBMUyBQU0MgQ2FwYWJpbGl0eSBGbGFnIFJlZ2lzdHJ54oCd Lg0KMjAuIFRocmVlIG9wZXJhdGlvbiBleGFtcGxlcyBvZiB0aGUgQVBTIG1vZGUgYXJlIGFkZGVk IGluIEFwcGVuZGl4IEQuDQoyMS4gUmVwbGFjZWQg4oCcZmFyLWVuZC9uZWFyLWVuZOKAnSB3aXRo IOKAnHJlbW90ZSBMRVIvbG9jYWwgTEVS4oCdIGluIG9yZGVyIHRvIGVsaW1pbmF0ZSB1bm5lY2Vz c2FyeSBjb25mdXNpb24uDQoyMi4gT3RoZXIgZWRpdG9yaWFsIGNoYW5nZXMgZm9yIEFtZXJpY2Fu IEVuZ2xpc2gsIGNvcnJlY3Qgc3BlbGxpbmcsIGFuZCBhY3JvbnltcywgZXRjLg0KDQoNCg0KDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B258BSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxw IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5I aSwgYWxsLg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7 IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+JnF1 b3Q7ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDEmcXVvdDsgaXMgc3VibWl0dGVkLCBhbmQg dGhpcyBlbWFpbCBpcyB0byBnaXZlIHlvdSB0aGUgc3VtbWFyeSBvZiB0aGUgY2hhbmdlcyBtYWRl IGluIHRoaXMgdmVyc2lvbi4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPklmIHlvdSBoYXZlIGFueSBj b21tZW50cywgcGxlYXNlIGxldCB1cyBrbm93LjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAw Y20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPkJlc3QgcmVnYXJkcyw8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20g MGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj5KZW9uZy1kb25nPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i TElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBj bSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i 66eR7J2AIOqzoOuUlSI+IyMjIFN1bW1hcnkgb2YgdGhlIGNoYW5nZXMgIyMjPC9mb250Pjwvc3Bh bj48L3A+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+DQo8 cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4xLiBUaGUgdGl0bGUgaGFzIGJlZW4gY2hhbmdlZCBmcm9tIOKAnE1QTFMtVFAg TGluZWFyIFByb3RlY3Rpb24gaW4gU3VwcG9ydCBvZiBJVFUtVCdzIFJlcXVpcmVtZW50c+KAnSB0 byDigJxNUExTLVRQIExpbmVhciBQcm90ZWN0aW9uIHRvIE1hdGNoIHRoZSBPcGVyYXRpb25hbCBF eHBlY3RhdGlvbnMgb2YgU0RILCBPVE4gYW5kIEV0aGVybmV0DQogVHJhbnNwb3J0IE5ldHdvcmsg T3BlcmF0b3Jz4oCdLiBBY2NvcmRpbmdseSwgdGhlIHBocmFzZSBvZiDigJxtZWV0IHRoZSBJVFUt VOKAmXMgKHByb3RlY3Rpb24pIHJlcXVpcmVtZW50c+KAnSBoYXMgYmVlbiByZXBsYWNlZCBpbiB3 aG9sZSBkb2N1bWVudC4NCjxzcGFuIHN0eWxlPSJMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1J TFk6ICfrp5HsnYAg6rOg65SVJzsgRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LXNpemU6 IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC10 aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0 aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhl bWUtZm9udDogbWlub3ItYmlkaTsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgbGFuZz0iRU4tVVMiPg0K VGhpcyBjaGFuZ2UmbmJzcDtoYXMgYmVlbiZuYnNwO21hZGUgdG8gcmVzb2x2ZSB0aGUgaXNzdWUg b24gdGhlIOKAnElUVS1U4oCZcyByZXF1aXJlbWVudHPigJ0gcmFpc2VkIGJ5IG1hbnkgcGVvcGxl Lg0KPC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4yLiBUaGUgQWJzdHJhY3QgaGFzIGJl ZW4gcmVwbGFjZWQgd2l0aCB0aGUgbmV3IHRleHQgKHByb3Bvc2VkIGJ5IEFkcmlhbikgYWZ0ZXIg dHJpbW1pbmcgb2ZmIHNvbWUgdGV4dCB0byBtZWV0IHRoZSAyMCBsaW5lIGxpbWl0YXRpb24uIFRo ZSB0ZXh0IHRoYXQgaGFzIGJlZW4gdHJpbW1lZCBhcHBlYXJzIGluIHRoZSBJbnRyb2R1Y3Rpb24N CiBzZWN0aW9uLjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4zLiBUaGUgSW50cm9kdWN0aW9uIHNl Y3Rpb24gaGFzIGJlZW4gY2hhbmdlZCB0byByZWZsZWN0IHRoZSBBZHJpYW7igJlzIHByb3Bvc2Vk IHRleHQgYW5kIHRoZSBmZWVkYmFja3MgdGhhdCBMb2EgaGFkIGJlZW4gcmVjZWl2ZWQgZnJvbSB0 aGUgcGVvcGxlIHdpdGggZGlmZmVyZW50IGJhY2tncm91bmRzLjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9y bWFsIj48L2ZvbnQ+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj40LiBJbiBTZWN0aW9uIDcuMywgdGhlIGJlaGF2aW9yIG9mIHByb3RlY3Rpb24gYWdh aW5zdCBTRCAodGhlIGlzc3VlIHJhaXNlZCBieSBZYWFjb3YpIGlzIHJld3JpdHRlbiB0byBtYWtl IHN1cmUgdGhhdCB0aGUgU0QgcHJvdGVjdGlvbiBpcw0KIGluZGVwZW5kZW50IG9mIHRoZSBTRCBk ZXRlY3Rpb24gbWVjaGFuaXNtLiBUaGUgbmV3IHRleHQgaXMgdGhlIHNhbWUgYXMgdGhlIG9uZSB0 aGF0IEkgcHJvcG9zZWQgaW4gbXkgcHJldmlvdXMgZW1haWwgdG8gdGhlIE1QTFMgV0cgbGlzdCBv biBKYW4uIDE0Lg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+NS4gSW4gU2VjdGlvbiA3LjMsIHRoZSAx OjEgcHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUgZm9yIHRoZSBzZWxlY3RvciBicmlkZ2Ugd2l0aCBw YWNrZXQgZHVwbGljYXRpb24gaGFzIGJlZW4gY2xhcmlmaWVkIHRvIHJlZmxlY3QgdGhlIGNvbW1l bnQgYXBwZWFyZWQNCiBpbiB0aGUgV0cgbGlzdCAoZnJvbSBRaW4gV3UpLiA8L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQi IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj42LiBUaGUgZGVzY3JpcHRpb25zIG9uIHNpbXVsdGFuZW91cyByZXF1ZXN0cyAoTVMg YW5kIFNEKSBpbiBTZWN0aW9uIDcuMyBhbmQgZXF1YWwgcHJpb3JpdHkgcmVzb2x1dGlvbiBhbmQg aW4gU2VjdGlvbiA3LjQgYXJlIHJld3JpdHRlbiBmb3IgYmV0dGVyIGNsYXJpZmljYXRpb24sDQog YW5kIHRoZSBzaW1pbGFyIHRleHRzIHRoYXQgaGF2ZSBiZWVuIGFwcGVhcmVkIHR3byBkaWZmZXJl bnQgcGxhY2VzIGFyZSBtZXJnZWQuIDwvZm9udD4NCjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+Ny4gVGhlIGV4ZW1w bGFyeSBDYXBhYmlsaXRpZXMgVExWIHNldHMgaW4gU2VjdGlvbiA5LjEuMy4zIGFyZSBjaGFuZ2Vk IHRvIGZvbGxvdyB0aGUgY2FwYWJpbGl0eSBiaXQgYXNzaWdubWVudCBjb3JyZWN0bHkuPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBj bSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i 66eR7J2AIOqzoOuUlSI+OC4gSW4gU2VjdGlvbiAxMC4yLCB0aGUgb3BlcmF0aW9ucyBvZiBwcmlv cml0eSBldmFsdWF0aW9uIGFuZCBzdGF0ZSB0cmFuc2l0aW9uIHRhYmxlIGxvb2t1cCBhcmUgY2xh cmlmaWVkLjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBN QVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjksIEluIFNlY3Rpb24gMTAuMiwgdGhlIGRlc2Ny aXB0aW9uIG9uIHRoZSBwcmlvcml0aWVzIG9mIGxvY2FsIGlucHV0cyBhbmQgcmVtb3RlIHJlcXVl c3RzIGlzIGFkZGVkIGZvciBiZXR0ZXIgY2xhcmlmaWNhdGlvbi48L2ZvbnQ+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SV Ij4xMC4gSW4gU2VjdGlvbiAxMC4yLCB0aGUgb3BlcmF0aW9uIG9mIGVxdWFsIHByaW9yaXR5IHJl c29sdXRpb24gaXMgY2xhcmlmaWVkLg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+MTEuIEluIFNlY3Rp b24gMTAuMiwgdGhlIHByaW9yaXR5IGV2YWx1YXRpb24gYmV0d2VlbiBsb2NhbCBubyByZXF1ZXN0 IGFuZCByZW1vdGUgbm8gcmVxdWVzdCBpcyBhZGRlZCB0byBwZXJmb3JtIHRoZSBzdGF0ZSB0cmFu c2l0aW9uIHRhYmxlIGxvb2t1cCBjb3JyZWN0bHkuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4xMi4g U2VjdGlvbiAxMC4zIGlzIG5ld2x5IGFkZGVkIHRvIGRlc2NyaWJlIHRoZSBhY2NlcHRhbmNlIGFu ZCByZXRlbnRpb24gb2YgbG9jYWwgaW5wdXRzLjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjEzLiBJbiBT ZWN0aW9uIDExLCB0aGUgc3RhdGUgdHJhbnNpdGlvbiB0YWJsZXMgaGF2ZSBiZWVuIGZpeGVkIGZv ciBjb3JyZWN0IHByb3RvY29sIG9wZXJhdGlvbnMuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4xNC4g SW4gU2VjdGlvbiAxMSwgYSBuZXcgdHJhbnNpdGlvbiAoY2VsbCkgaXMgcmUtZGVmaW5lZCB0byBn dWFyYW50ZWUgaW50ZXJ3b3JraW5nIGJldHdlZW4gcmV2ZXJ0aXZlIGFuZCBub24tcmV2ZXJ0aXZl IG9wZXJhdGlvbnMuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4xNS4gSW4gU2VjdGlvbiAxMSwgdGhl IGZvb3Rub3RlcyBmb3IgdGhlIHN0YXRlIHRyYW5zaXRpb24gdGFibGVzIGFyZSBkaXZpZGVkIGFu ZCBwbGFjZWQgYmVsb3cgdGhlIGxvY2FsIHRhYmxlIGFuZCB0aGUgcmVtb3RlIHRhYmxlIHNlcGFy YXRlbHkuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1B UkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+MTYuIFRoZSBmb290bm90ZSB0ZXh0cyBmb3IgcmVt b3RlIFNEIHJlcXVlc3RzIGFyZSBtb2RpZmllZCB0byBmaXggc29tZSBidWdzLCBhbmQgYWxzbyB0 byBkZWNvdXBsZSB0aGUgc3RhdGUgdHJhbnNpdGlvbiB0YWJsZSBsb29rdXAgZnJvbSB0aGUgcHJp b3JpdHkNCiBldmFsdWF0aW9uIGZvciBTRCByZXF1ZXN0LjwvZm9udD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjE3 LiBTZWN0aW9uIDExLjMgaXMgbmV3bHkgYWRkZWQgdG8gZGVmaW5lIHRoZSBzdGF0ZSB0cmFuc2l0 aW9uIGZvciAxJiM0MzsxIHVuaWRpcmVjdGlvbmFsIHByb3RlY3Rpb24uPC9mb250Pjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqz oOuUlSI+MTguIFNlY3Rpb24gMTIgaXMgbmV3bHkgYWRkZWQgdG8gZGVzY3JpYmUgdGhlIG9wZXJh dGlvbnMgaW4gY2FzZXMgb2YgcHJvdmlzaW9uaW5nIG1pc21hdGNoIGFuZCBwcm90b2NvbCBmYWls dXJlcyBpbiB0aGUgQVBTIG1vZGUuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4xOS4gU2VjdGlvbiAx NCAoSUFOQSBjb25zaWRlcmF0aW9ucykgaXMgcmV3cml0dGVuLCBhbmQgdGhlIGVkaXRvcuKAmXMg bm90ZSBpcyByZXBsYWNlZCB3aXRoIHRoZSBhY3R1YWwgdGV4dCBmb3IgYSBuZXcgcmVnaXN0cnks IOKAnE1QTFMgUFNDIENhcGFiaWxpdHkgRmxhZw0KIFJlZ2lzdHJ54oCdLiA8L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQi IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj4yMC4gVGhyZWUgb3BlcmF0aW9uIGV4YW1wbGVzIG9mIHRoZSBBUFMgbW9kZSBhcmUg YWRkZWQgaW4gQXBwZW5kaXggRC48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4yMS4gUmVwbGFjZWQg4oCc ZmFyLWVuZC9uZWFyLWVuZOKAnSB3aXRoIOKAnHJlbW90ZSBMRVIvbG9jYWwgTEVS4oCdIGluIG9y ZGVyIHRvIGVsaW1pbmF0ZSB1bm5lY2Vzc2FyeSBjb25mdXNpb24uPC9mb250Pjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PHNwYW4gc3R5bGU9IkxJTkUtSEVJR0hU OiAxMTUlOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBGT05ULVNJWkU6IDEwcHQ7IG1z by1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0 aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVt ZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tYW5zaS1sYW5ndWFnZTog RU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNB IiBsYW5nPSJFTi1VUyI+MjIuDQogT3RoZXIgZWRpdG9yaWFsIGNoYW5nZXMgZm9yIEFtZXJpY2Fu IEVuZ2xpc2gsIGNvcnJlY3Qgc3BlbGxpbmcsIGFuZCBhY3JvbnltcywgZXRjLjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48c3BhbiBzdHlsZT0iTElORS1IRUlH SFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IEZPTlQtU0laRTogMTBwdDsg bXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1s YXRpbjsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRo ZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby1hbnNpLWxhbmd1YWdl OiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVIt U0EiIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJBcmlhbCI+PC9mb250Pjwvc3Bhbj48YnI+DQo8 YnI+DQombmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBpZD0iTWFp bFNpZ24iPjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxicj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B258BSMTP2etriinfo_-- From loa@pi.nu Sun Jan 19 18:28:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE961A0019 for ; Sun, 19 Jan 2014 18:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.535] 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 qcmz-3wpO-jz for ; Sun, 19 Jan 2014 18:28:26 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3241A001F for ; Sun, 19 Jan 2014 18:28:26 -0800 (PST) Received: from [192.168.1.3] (unknown [49.147.219.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 00337180150F; Mon, 20 Jan 2014 03:28:23 +0100 (CET) Message-ID: <52DC89C3.3030003@pi.nu> Date: Mon, 20 Jan 2014 10:28:19 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 02:28:29 -0000 Working Group, This is to start a two week working group last call on draft-ietf-mpls-tp-psc-itu. Please find the document at: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ The document editors has also supplied a "diff-list" between version -00 and -01 at: http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html ITU-T SG15 has advised us that this document is a necessary reference for documents that is planned to go into the ITU-T approval process from the SG15 meeting end of March / beginning of April. Editors, authors and chairs has put in quite an effort to make this document ready. The schedule is very tight. We are now doing several review steps in parallel - the normal working group last call, please send your comments to the mpls working group mailing list (mpls@ietf.org) - the working group chairs reviewed this document as part of the mpls-rt review, normally we do a wg chair review before starting the wglc, this review will now take place in parallel - after the wglc and publication request there is an AD evaluation, this will now also take place in parallel with the wglc The editors and authors are advised to try to resolve as many of the comments as possible (on the mailing list) as they come in, but not to post the new version of the draft until the wglc is closed and the comments are resolved. This working group last call ends February 3rd. /Loa for the MPLS WG co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From david.black@emc.com Sun Jan 19 19:30:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531511A0023; Sun, 19 Jan 2014 19:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, 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 5JfuNn8B0eEV; Sun, 19 Jan 2014 19:30:35 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 77D8A1A001F; Sun, 19 Jan 2014 19:30:35 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0K3USCQ012964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jan 2014 22:30:31 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s0K3USCQ012964 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390188631; bh=ghRaPwbG9paVbA4AQIMVTuwKqco=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=tl47hZk9YoCepxFBFavWk7ql6RN9J666YJF4VhgMuVTogAFfEe67v3ccxw2rTXGzd GwNLpF7s1BboR9aGRGmTvGvjxvRRSw6aVaRMxxEmr/+lAlj/3GyPFlsUyYgvpNIfsR 1OC/6AscMgshcMP6RB6VUNgLq/OlcOJ5r9aLbFVw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s0K3USCQ012964 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd53.lss.emc.com (RSA Interceptor); Sun, 19 Jan 2014 22:30:13 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0K3UACp011719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Jan 2014 22:30:12 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Sun, 19 Jan 2014 22:30:10 -0500 From: "Black, David" To: Alexander Vainshtein , "stbryant@cisco.com" Date: Sun, 19 Jan 2014 22:30:08 -0500 Thread-Topic: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp) Thread-Index: Ac8Vj+sUxkixdvZlQDyGimrIKN8dNQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026F047824@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Cc: "mpls@ietf.org" , "lisp@ietf.org" , "Black, David" , Randy Bush , "tsvwg@ietf.org" , "ietf@ietf.org" Subject: [mpls] GRE in UDP - traffic distribution ( was RE: [tsvwg] OT (was Re: draft-ietf-mpls-in-udp) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 03:30:38 -0000 Sasha, > But I would like to understand whether this protocol can really result in > reasonable distribution of traffic. "Reasonable" means that (a) there is > sufficient entropy and (b) that the order in specific micro-flows is > preserved. The draft skips this issue (unless you consider a recommendati= on to > use a fixed randomly selected source port value if the tunnel does not n= eed > ECMP a valid answer) . Well, there's a bit more in the draft than just a "randomly selected" value= , as the ability to use ECMP on these tunnels is rather important (text quote= d is from Section 3 in the draft): The ingress device SHOULD set the UDP source port based on flow invariant fields from the payload header, otherwise it should be set to a randomly selected constant value, e.g. zero, to avoid packet flow reordering. How a tunnel ingress generates entropy from the payload is outside the scope of this document. I suppose that more discussion and examples of "flow invariant fields" would be useful, although an attempt at a comprehensive listing would be pointless, IMHO. An important situation is one where the tunnel ingress "knows" (because the network operator actually does know) what the protocol stack(s) is/are for the encapsulated traffic (e.g., HTTP/TCP/IP/GRE/IP) and hence can find the flow-invariant fields that it wants to use for that (those) specific stack(s). With good selection of flow-invariant fields wrt traffic mix, good distribution is possible. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander Vainsh= tein > Sent: Wednesday, January 15, 2014 6:54 AM > To: stbryant@cisco.com > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; R= andy > Bush; jnc@mit.edu; lisp@ietf.org > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gr= e-in- > udp draft (was: RE: Milestones changed for tsvwg WG)) >=20 > Stewart, and all, > I fully agree that UDP checksums is not a real-life issue with the protoc= ol in > question. They could probably help to check corrupted packets if corrupti= on > happens when a packet passes thru a router (i.e. when the ingress data li= nk > FCS has already been terminated and the egress data link FCS has not been > generated yet). But this is hopefully rare - and since MPLS does not care > about it, why should the MPLS encapsulator care? >=20 > I also do not think that congestion control is a serious issue for this > protocol, not in the least because the primary purpose of this protocol i= s > ECMP. >=20 > But I would like to understand whether this protocol can really result in > reasonable distribution of traffic. "Reasonable" means that (a) there is > sufficient entropy and (b) that the order in specific micro-flows is > preserved. The draft skips this issue (unless you consider a recommendati= on to > use a fixed randomly selected source port value if the tunnel does not n= eed > ECMP a valid answer) . >=20 > Any ideas as to how reasonable distribution of traffic can be achieved w= ith > this protocol? >=20 > Regards, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > > Sent: Wednesday, January 15, 2014 1:31 PM > > To: Randy Bush > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org; > > wes@mti-systems.com; tsvwg@ietf.org; jnc@mit.edu > > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: = gre- > in- > > udp draft (was: RE: Milestones changed for tsvwg WG)) > > > > On 15/01/2014 11:08, Randy Bush wrote: > > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > > > >> it seems that there are no valid statistics for the current Internet > > >> to sustain your case. > > > as we discussed privately, there seem to be no real measurements to > > > sustain any case. this is all conjecturbation. > > > > > > what i do not understand is why, given the lack of solid evidence tha= t > > > we are in a safe space, you and others are not willing to spend a few > > > euro cents to have a reasonable level of assurance at this layer. > > > > > > randy > > Randy, > > > > It is not a few cents, it is likely the re-engineering of a lot of sili= con. > > > > The reason that UDP is of interest is that the on path silicon knows ho= w to > > process it, for example it knows how to to ECMP it. > > > > The reason that the UDP c/s is a problem for a tunneler is that it need= s to > > have access to the whole pkt to calculate the c/s, but as you know the > silicon > > optimised that access away a long time ago. > > > > The alternative would be UDP-lite, but the ability of on path silicon t= o > process > > that as competently and as completely as it processes UDP is by no mean= s > > clear. > > > > - Stewart > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Sun Jan 19 21:44:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902D11A0034; Sun, 19 Jan 2014 21:44: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 2pOvGj5Jhxfy; Sun, 19 Jan 2014 21:44:40 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) by ietfa.amsl.com (Postfix) with ESMTP id 91DF11A0023; Sun, 19 Jan 2014 21:44:36 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB531.eurprd03.prod.outlook.com (10.242.109.155) with Microsoft SMTP Server (TLS) id 15.0.851.11; Mon, 20 Jan 2014 05:44:34 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Mon, 20 Jan 2014 05:44:34 +0000 From: Alexander Vainshtein To: "Black, David" , "stbryant@cisco.com" Thread-Topic: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp) Thread-Index: Ac8Vj+sUxkixdvZlQDyGimrIKN8dNQAD35l5 Date: Mon, 20 Jan 2014 05:44:33 +0000 Message-ID: <3568aff546054a748d73d029c110c97b@AM3PR03MB532.eurprd03.prod.outlook.com> References: <8D3D17ACE214DC429325B2B98F3AE712026F047824@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026F047824@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.66.126.123] x-forefront-prvs: 00979FCB3A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(13464003)(51704005)(252514010)(24454002)(189002)(199002)(164054003)(479174003)(377454003)(81686001)(31966008)(87936001)(74876001)(74706001)(90146001)(80022001)(4396001)(47446002)(15202345003)(76576001)(87266001)(83072002)(85852003)(81542001)(74316001)(86362001)(74366001)(93516002)(81342001)(74502001)(51856001)(56816005)(47976001)(69226001)(74662001)(15975445006)(65816001)(66066001)(85306002)(2656002)(19580395003)(83322001)(19580405001)(47736001)(80976001)(92566001)(53806001)(54356001)(79102001)(46102001)(50986001)(76786001)(49866001)(54316002)(76796001)(56776001)(33646001)(93136001)(59766001)(76482001)(63696002)(77982001)(81816001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB531; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:109.66.126.123; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Cc: Randy Bush , "mpls@ietf.org" , "lisp@ietf.org" , "ietf@ietf.org" , "tsvwg@ietf.org" Subject: Re: [mpls] GRE in UDP - traffic distribution ( was RE: [tsvwg] OT (was Re: draft-ietf-mpls-in-udp) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 05:44:43 -0000 David,=0A= Lots of thanks for a detailed response.=0A= =0A= My original question dealt with the MPLS-in-UDP draft, where the relevant t= ext was quite brief:=0A= =0A= =0A= Source Port of UDP =0A= =0A= This field contains a 16-bit entropy value that is =0A= generated by the ingress PE router. What algorithm is =0A= actually used by the ingress PE router to generate an =0A= entropy value is outside the scope of this doc. In the =0A= case where the flow does not need entropy, this field =0A= SHOULD be set to a randomly selected constant value to =0A= avoid packet reordering. =0A= =0A= =0A= The answer given by Eric Rosen in http://www.ietf.org/mail-archive/web/mpls= /current/msg11277.html (use the hash of the label stack of the packet to be= encapsulated ) resolves, IMO, this issue because the head-end of the UDP t= unnel (the encapsulator) looks at the label stack of the packet to be encap= sulated in any case. Of course other methods are not precluded, but there i= s at least one method that is both reasonably simple and meaningful, especi= ally because it is possible to add entropy to the label stack (RFC 6790).= =0A= =0A= In the case of GRE-in-UDP the text goes into more detail, but, IMHO and FWI= W, these details are not sufficient. AFAIK , the GRE encapsulators in most = cases follows RFC 2784 and not RFC 1701. The reduced GRE header adopted RFC= 2784 does not leave any place for meaningful "flow invariant fields" (unle= ss you count the prtotocol type as such). This means that the head-end of = the UDP tunnel has to look beyond the IP and GRE headers of the packet to b= e encapsulated for these fields - and this is something that, to the best o= f my understanding, GRE tries to prevent.=0A= =0A= My 2c,=0A= Sasha=0A= ________________________________________=0A= From: Black, David =0A= Sent: Monday, January 20, 2014 5:30 AM=0A= To: Alexander Vainshtein; stbryant@cisco.com=0A= Cc: mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; Randy Bush; lisp@ietf.org= ; Black, David=0A= Subject: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was= Re: draft-ietf-mpls-in-udp)=0A= =0A= Sasha,=0A= =0A= > But I would like to understand whether this protocol can really result in= =0A= > reasonable distribution of traffic. "Reasonable" means that (a) there is= =0A= > sufficient entropy and (b) that the order in specific micro-flows is=0A= > preserved. The draft skips this issue (unless you consider a recommendati= on to=0A= > use a fixed randomly selected source port value if the tunnel does not n= eed=0A= > ECMP a valid answer) .=0A= =0A= Well, there's a bit more in the draft than just a "randomly selected" value= ,=0A= as the ability to use ECMP on these tunnels is rather important (text quote= d=0A= is from Section 3 in the draft):=0A= =0A= The ingress device SHOULD set=0A= the UDP source port based on flow invariant fields from the payload=0A= header, otherwise it should be set to a randomly selected constant=0A= value, e.g. zero, to avoid packet flow reordering. How a tunnel=0A= ingress generates entropy from the payload is outside the scope of=0A= this document.=0A= =0A= I suppose that more discussion and examples of "flow invariant fields"=0A= would be useful, although an attempt at a comprehensive listing would be=0A= pointless, IMHO. An important situation is one where the tunnel ingress=0A= "knows" (because the network operator actually does know) what the protocol= =0A= stack(s) is/are for the encapsulated traffic (e.g., HTTP/TCP/IP/GRE/IP) and= =0A= hence can find the flow-invariant fields that it wants to use for that=0A= (those) specific stack(s).=0A= =0A= With good selection of flow-invariant fields wrt traffic mix, good=0A= distribution is possible.=0A= =0A= Thanks,=0A= --David=0A= =0A= > -----Original Message-----=0A= > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander Vainsh= tein=0A= > Sent: Wednesday, January 15, 2014 6:54 AM=0A= > To: stbryant@cisco.com=0A= > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; R= andy=0A= > Bush; jnc@mit.edu; lisp@ietf.org=0A= > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gr= e-in-=0A= > udp draft (was: RE: Milestones changed for tsvwg WG))=0A= >=0A= > Stewart, and all,=0A= > I fully agree that UDP checksums is not a real-life issue with the protoc= ol in=0A= > question. They could probably help to check corrupted packets if corrupti= on=0A= > happens when a packet passes thru a router (i.e. when the ingress data li= nk=0A= > FCS has already been terminated and the egress data link FCS has not been= =0A= > generated yet). But this is hopefully rare - and since MPLS does not care= =0A= > about it, why should the MPLS encapsulator care?=0A= >=0A= > I also do not think that congestion control is a serious issue for this= =0A= > protocol, not in the least because the primary purpose of this protocol i= s=0A= > ECMP.=0A= >=0A= > But I would like to understand whether this protocol can really result in= =0A= > reasonable distribution of traffic. "Reasonable" means that (a) there is= =0A= > sufficient entropy and (b) that the order in specific micro-flows is=0A= > preserved. The draft skips this issue (unless you consider a recommendati= on to=0A= > use a fixed randomly selected source port value if the tunnel does not n= eed=0A= > ECMP a valid answer) .=0A= >=0A= > Any ideas as to how reasonable distribution of traffic can be achieved w= ith=0A= > this protocol?=0A= >=0A= > Regards,=0A= > Sasha=0A= > Email: Alexander.Vainshtein@ecitele.com=0A= > Mobile: 054-9266302=0A= >=0A= > > -----Original Message-----=0A= > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant= =0A= > > Sent: Wednesday, January 15, 2014 1:31 PM=0A= > > To: Randy Bush=0A= > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org;= =0A= > > wes@mti-systems.com; tsvwg@ietf.org; jnc@mit.edu=0A= > > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: = gre-=0A= > in-=0A= > > udp draft (was: RE: Milestones changed for tsvwg WG))=0A= > >=0A= > > On 15/01/2014 11:08, Randy Bush wrote:=0A= > > > [ you insist on cc:ing me, so you get to endure my opinions ]=0A= > > >=0A= > > >> it seems that there are no valid statistics for the current Internet= =0A= > > >> to sustain your case.=0A= > > > as we discussed privately, there seem to be no real measurements to= =0A= > > > sustain any case. this is all conjecturbation.=0A= > > >=0A= > > > what i do not understand is why, given the lack of solid evidence tha= t=0A= > > > we are in a safe space, you and others are not willing to spend a few= =0A= > > > euro cents to have a reasonable level of assurance at this layer.=0A= > > >=0A= > > > randy=0A= > > Randy,=0A= > >=0A= > > It is not a few cents, it is likely the re-engineering of a lot of sili= con.=0A= > >=0A= > > The reason that UDP is of interest is that the on path silicon knows ho= w to=0A= > > process it, for example it knows how to to ECMP it.=0A= > >=0A= > > The reason that the UDP c/s is a problem for a tunneler is that it need= s to=0A= > > have access to the whole pkt to calculate the c/s, but as you know the= =0A= > silicon=0A= > > optimised that access away a long time ago.=0A= > >=0A= > > The alternative would be UDP-lite, but the ability of on path silicon t= o=0A= > process=0A= > > that as competently and as completely as it processes UDP is by no mean= s=0A= > > clear.=0A= > >=0A= > > - Stewart=0A= > >=0A= > >=0A= > > _______________________________________________=0A= > > mpls mailing list=0A= > > mpls@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/mpls=0A= =0A= From internet-drafts@ietf.org Mon Jan 20 07:30:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB001A01B4; Mon, 20 Jan 2014 07:30: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 aB4iBluAv61U; Mon, 20 Jan 2014 07:30:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F91B1A01BE; Mon, 20 Jan 2014 07:30:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140120153032.17386.53687.idtracker@ietfa.amsl.com> Date: Mon, 20 Jan 2014 07:30:32 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-applicability-label-adv-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 15:30:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Label Advertisement Discipline for LDP FECs Authors : Kamran Raza Sami Boutros Luca Martini Nicolai Leymann Filename : draft-ietf-mpls-ldp-applicability-label-adv-02.txt Pages : 6 Date : 2014-01-20 Abstract: The label advertising behavior of an LDP speaker for a given FEC is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear, as well as updates RFC 3212, RFC 4447, RFC 5918, and RFC 6388 by specifying the label advertisement mode for all currently defined FECs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-applicability-label-ad= v/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-applicability-label-adv-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-applicability-label-= adv-02 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 david.black@emc.com Mon Jan 20 09:28:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46AD1A01B2; Mon, 20 Jan 2014 09:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 pJfcwtG2YSN4; Mon, 20 Jan 2014 09:27:57 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 73EA61A01A2; Mon, 20 Jan 2014 09:27:57 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0KHPgUZ032284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jan 2014 12:25:45 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s0KHPgUZ032284 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390238746; bh=RT/4T7uY/z4f6y23zmetvQNNNGE=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=SmTvDHLET61jTrFQ8/uI2oOJnpXmf0fGcQat+JhguuD9mf8wAVFX1z+Lzf6XTaJsT PLaCyYmlMtTT/PbalgUJwq2KTjXChROpjjW47gY/Fh90innGucbJ1iqB901UMoI0wI cK+DqvbAAuq9V2nyII61o+JD19Y63CT1DFE1Ff70= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s0KHPgUZ032284 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 20 Jan 2014 09:25:32 -0800 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0KHPTsH019845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jan 2014 12:25:31 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Mon, 20 Jan 2014 12:25:28 -0500 From: "Black, David" To: Alexander Vainshtein , "stbryant@cisco.com" Date: Mon, 20 Jan 2014 12:25:28 -0500 Thread-Topic: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp) Thread-Index: Ac8Vj+sUxkixdvZlQDyGimrIKN8dNQAD35l5ABkZW3A= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026F04796A@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712026F047824@MX15A.corp.emc.com> <3568aff546054a748d73d029c110c97b@AM3PR03MB532.eurprd03.prod.outlook.com> In-Reply-To: <3568aff546054a748d73d029c110c97b@AM3PR03MB532.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Cc: "mpls@ietf.org" , "lisp@ietf.org" , "Black, David" , Randy Bush , "tsvwg@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] GRE in UDP - traffic distribution ( was RE: [tsvwg] OT (was Re: draft-ietf-mpls-in-udp) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 17:28:01 -0000 Alex, > In the case of GRE-in-UDP the text goes into more detail, but, IMHO and F= WIW, > these details are not sufficient. AFAIK , the GRE encapsulators in most c= ases > follows RFC 2784 and not RFC 1701. The reduced GRE header adopted RFC 278= 4 > does not leave any place for meaningful "flow invariant fields" (unless y= ou > count the protocol type as such). This means that the head-end of the UD= P > tunnel has to look beyond the IP and GRE headers of the packet to be > encapsulated for these fields - and this is something that, to the best o= f my > understanding, GRE tries to prevent. My understanding of the intent of the GRE in UDP draft is that the encapsul= ator really has to look beyond the GRE header to set the UDP source port in orde= r to get load balancing. E.g., for MPLS/GRE/UDP, the ECMP hash for MPLS would b= e the basis for setting the UDP source port in a fashion analogous to Eric's = message. This requires encapsulators that can do that, and do analogous things for o= ther protocol stacks above GRE (e.g., those that do not use MPLS). Thanks, --David > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, January 20, 2014 12:45 AM > To: Black, David; stbryant@cisco.com > Cc: mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; Randy Bush; lisp@ietf.o= rg > Subject: RE: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] O= T > (was Re: draft-ietf-mpls-in-udp) >=20 > David, > Lots of thanks for a detailed response. >=20 > My original question dealt with the MPLS-in-UDP draft, where the relevant= text > was quite brief: >=20 > > Source Port of UDP >=20 > This field contains a 16-bit entropy value that is > generated by the ingress PE router. What algorithm is > actually used by the ingress PE router to generate an > entropy value is outside the scope of this doc. In the > case where the flow does not need entropy, this field > SHOULD be set to a randomly selected constant value to > avoid packet reordering. > >=20 > The answer given by Eric Rosen in http://www.ietf.org/mail- > archive/web/mpls/current/msg11277.html (use the hash of the label stack o= f the > packet to be encapsulated ) resolves, IMO, this issue because the head-en= d of > the UDP tunnel (the encapsulator) looks at the label stack of the packet = to be > encapsulated in any case. Of course other methods are not precluded, but = there > is at least one method that is both reasonably simple and meaningful, > especially because it is possible to add entropy to the label stack (RFC > 6790). >=20 > In the case of GRE-in-UDP the text goes into more detail, but, IMHO and F= WIW, > these details are not sufficient. AFAIK , the GRE encapsulators in most c= ases > follows RFC 2784 and not RFC 1701. The reduced GRE header adopted RFC 278= 4 > does not leave any place for meaningful "flow invariant fields" (unless y= ou > count the prtotocol type as such). This means that the head-end of the U= DP > tunnel has to look beyond the IP and GRE headers of the packet to be > encapsulated for these fields - and this is something that, to the best o= f my > understanding, GRE tries to prevent. >=20 > My 2c, > Sasha > ________________________________________ > From: Black, David > Sent: Monday, January 20, 2014 5:30 AM > To: Alexander Vainshtein; stbryant@cisco.com > Cc: mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; Randy Bush; lisp@ietf.o= rg; > Black, David > Subject: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (w= as > Re: draft-ietf-mpls-in-udp) >=20 > Sasha, >=20 > > But I would like to understand whether this protocol can really result = in > > reasonable distribution of traffic. "Reasonable" means that (a) there i= s > > sufficient entropy and (b) that the order in specific micro-flows is > > preserved. The draft skips this issue (unless you consider a recommenda= tion > to > > use a fixed randomly selected source port value if the tunnel does not= need > > ECMP a valid answer) . >=20 > Well, there's a bit more in the draft than just a "randomly selected" val= ue, > as the ability to use ECMP on these tunnels is rather important (text quo= ted > is from Section 3 in the draft): >=20 > The ingress device SHOULD set > the UDP source port based on flow invariant fields from the payload > header, otherwise it should be set to a randomly selected constant > value, e.g. zero, to avoid packet flow reordering. How a tunnel > ingress generates entropy from the payload is outside the scope of > this document. >=20 > I suppose that more discussion and examples of "flow invariant fields" > would be useful, although an attempt at a comprehensive listing would be > pointless, IMHO. An important situation is one where the tunnel ingress > "knows" (because the network operator actually does know) what the protoc= ol > stack(s) is/are for the encapsulated traffic (e.g., HTTP/TCP/IP/GRE/IP) a= nd > hence can find the flow-invariant fields that it wants to use for that > (those) specific stack(s). >=20 > With good selection of flow-invariant fields wrt traffic mix, good > distribution is possible. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander > Vainshtein > > Sent: Wednesday, January 15, 2014 6:54 AM > > To: stbryant@cisco.com > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; > Randy > > Bush; jnc@mit.edu; lisp@ietf.org > > Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: = gre- > in- > > udp draft (was: RE: Milestones changed for tsvwg WG)) > > > > Stewart, and all, > > I fully agree that UDP checksums is not a real-life issue with the prot= ocol > in > > question. They could probably help to check corrupted packets if corrup= tion > > happens when a packet passes thru a router (i.e. when the ingress data = link > > FCS has already been terminated and the egress data link FCS has not be= en > > generated yet). But this is hopefully rare - and since MPLS does not ca= re > > about it, why should the MPLS encapsulator care? > > > > I also do not think that congestion control is a serious issue for this > > protocol, not in the least because the primary purpose of this protocol= is > > ECMP. > > > > But I would like to understand whether this protocol can really result = in > > reasonable distribution of traffic. "Reasonable" means that (a) there i= s > > sufficient entropy and (b) that the order in specific micro-flows is > > preserved. The draft skips this issue (unless you consider a recommenda= tion > to > > use a fixed randomly selected source port value if the tunnel does not= need > > ECMP a valid answer) . > > > > Any ideas as to how reasonable distribution of traffic can be achieved= with > > this protocol? > > > > Regards, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > > > Sent: Wednesday, January 15, 2014 1:31 PM > > > To: Randy Bush > > > Cc: gorry@erg.abdn.ac.uk; mpls@ietf.org; lisp@ietf.org; ietf@ietf.org= ; > > > wes@mti-systems.com; tsvwg@ietf.org; jnc@mit.edu > > > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE= : > gre- > > in- > > > udp draft (was: RE: Milestones changed for tsvwg WG)) > > > > > > On 15/01/2014 11:08, Randy Bush wrote: > > > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > > > > > >> it seems that there are no valid statistics for the current Intern= et > > > >> to sustain your case. > > > > as we discussed privately, there seem to be no real measurements to > > > > sustain any case. this is all conjecturbation. > > > > > > > > what i do not understand is why, given the lack of solid evidence t= hat > > > > we are in a safe space, you and others are not willing to spend a f= ew > > > > euro cents to have a reasonable level of assurance at this layer. > > > > > > > > randy > > > Randy, > > > > > > It is not a few cents, it is likely the re-engineering of a lot of > silicon. > > > > > > The reason that UDP is of interest is that the on path silicon knows = how > to > > > process it, for example it knows how to to ECMP it. > > > > > > The reason that the UDP c/s is a problem for a tunneler is that it ne= eds > to > > > have access to the whole pkt to calculate the c/s, but as you know th= e > > silicon > > > optimised that access away a long time ago. > > > > > > The alternative would be UDP-lite, but the ability of on path silicon= to > > process > > > that as competently and as completely as it processes UDP is by no me= ans > > > clear. > > > > > > - Stewart > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls >=20 From daniel@olddog.co.uk Mon Jan 20 14:03:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA301A024B for ; Mon, 20 Jan 2014 14:03:58 -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_20=-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 ICuRUwY-SqDo for ; Mon, 20 Jan 2014 14:03:56 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 02E971A0233 for ; Mon, 20 Jan 2014 14:03:55 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0KM3nmn015765; Mon, 20 Jan 2014 22:03:51 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0KM3mOo015759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Jan 2014 22:03:48 GMT From: "Daniel King" To: , "'Martin Vigoureux'" , Date: Mon, 20 Jan 2014 22:03:44 -0000 Message-ID: <000f01cf162b$7cee4ab0$76cae010$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8WK1t1++A1SQXVRGCzuMh7DOHDzg== Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] mpls-rt review for draft-akiya-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 22:03:58 -0000 Hi All, As requested (MPLS RT), please find my brief review of draft-akiya-mpls-entropy-lsp-ping. The I-D updates LSP verification mechanism and Entropy Label LSPs. The I-D is well written with a clear intention and should be polled for WG adoption. A few suggested comments/updates/NITs: - Abstract mentions RFC4379, but this I-D is updated by RFC6424? - Although you expand acronyms in the "Abstract", you may want to expand them again in the Introduction, and other parts of the document (ECMP, EL, ELI, FAT, FEC, MS-PW, etc.). - The last two sentences of the final paragraph from the "Introduction" is slightly truncated. I would suggest the following updated text: >> Section 3 of this document updates the procedures for multipath information type {9} described in [RFC4379]. The rest of this document describes extensions required to restore ECMP discovery and tracing capabilities for the scenarios described. << - "Overview " section, second paragraph needs some minor grammar updates and acronyms expanded. Suggest updating the text to: >> LSP Ping initiating LSR sends MPLS echo request with multipath information. This multipath information is described in Downstream Mapping TLV and Downstream Detailed Mapping TLV (DSMAP/DMAP) echo request, and may contain a set of IP addresses or set of labels. Multipath information types {2, 4, 8} carry a set of IP addresses and multipath information type {9} carries a set of labels. Responder LSR (receiver of MPLS echo request) will determine the subset of initiator specified multipath information which load balances to each downstream (outgoing interface). Responder LSR sends MPLS echo reply with resulting multipath information per downstream (outgoing interface) back to the initiating LSR. Initiating LSR is then able to use specific IP destination address or specific label to exercise specific ECMP path on the responder LSR. << - "Overview" section, third bullet. Suggest updating text to: >> Initiating LSR sends existing multipath information to LSR which pushes ELI/EL in label stack, but the initiating LSR can only continue to discover and exercise specific path of ECMP, if the LSR which pushes ELI/EL responds with both IP addresses and associated EL corresponding to each IP address. << - "Multipath Type 9" section, uses "non-FAT pseudowire" terminology, then later expands acronym to "Flow-Aware Transport Pseudowire", suggest expanding acronym on first use. - "Multipath Type 9" section, fourth paragraph, the use of "must" looks like it should "MUST". - "Initiating LSR Procedures" section, not really sure what a " IP based load balancer" is? - "FAT MS-PW Stitching LSR" section, suggest updating "xconnects" to "cross-connects". - General observation for your figures, I would suggest you provide figure numbers/titles. Br, Dan. -----Original Message----- From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] Sent: 17 January 2014 05:08 To: Loa Andersson Cc: Sriganesh Kini; Xuxiaohu; Curtis Villamizar; Daniel King; mpls-chairs@tools.ietf.org; draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org; draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org Subject: Re: Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping In message <52C67349.4020701@pi.nu> Loa Andersson writes: > Folks, > > This was the wrong document - I intended to have the review done for > draft-akiya-mpls-entropy-lsp-ping sorry for the confusion. > > All other cordinates correct! > > On 2014-01-03 14:44, Loa Andersson wrote: > > Sri, Xiaohu, Curtis and Dan, > > > > You have been selected as MPLS Review team reviewers for > > draft-akiya-mpls-entropy-lsp-ping-01. > > > > Note to authors: You have been CC'd on this email so that you can > > know that this review is going on. However, please do not review > > your own document. > > > > Reviews should comment on whether the document is coherent, is it > > useful (ie, is it likely to be actually useful in operational > > networks), and is the document technically sound? We are interested > > in knowing whether the document is ready to be considered for WG > > adoption (ie, it doesn't have to be perfect at this point, but > > should be a good start). > > > > Reviews should be sent to the document authors, WG co-chairs and WG > > secretary, and CC'd to the MPLS WG email list. If necessary, > > comments may be sent privately to only the WG chairs. > > > > Are you able to review this draft by January 20, 2014? > > > > Thanks, Loa > > (as MPLS WG chair) > > -- > > > Loa Andersson email: loa@mail01.huawei.com From curtis@ipv6.occnc.com Mon Jan 20 14:47:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D081A0259 for ; Mon, 20 Jan 2014 14:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 bZ4s7HSmsx8n for ; Mon, 20 Jan 2014 14:47:48 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3821A0266 for ; Mon, 20 Jan 2014 14:47:48 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0KMllSl047284; Mon, 20 Jan 2014 17:47:47 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Fri, 17 Jan 2014 23:00:33 +0000." <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk> Date: Mon, 20 Jan 2014 17:47:47 -0500 Cc: mpls@ietf.org, ietf@ietf.org, joelja@bogus.com, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 22:47:51 -0000 We are continuing to stray off topic, but... Router vendors focus on real needs identified by customers. If this were to become something customers were bugging them about, then they'll do it. OTOH, most hardware in the field today can only track one 32 bit FCS, given that only one L2 header would need this. The ability to run on existing hardware is important. Perhaps you missed this: > When a critical mass of routers hash on this new protocol number and > port space we'll let you know and the MPLS WG can obsolete MPLS over > UDP and replace it with MPLS over this new protocol. Providers and router vendors are also aware that most routers look only for protocol numbers 6 and 17 for load balancing on port numbers. So if the motivation of MPLS over UDP is an interim solution to get ECMP, then not using UDP is not an option. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > Yes, it would be unreasonable for the router vendors themselves to design > something with a trailing checksum and pseudo-header check that would meet > their forwarding needs while ensuring reliability. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 17 January 2014 18:05 > To: Wood L Dr (Electronic Eng) > Cc: stbryant@cisco.com; lars@netapp.com; joelja@bogus.com; mpls@ietf.org; ietf@ietf.org > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > In message <290E20B455C66743BE178C5C84F1240847E63346CF@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > There's an opportunity to define a simple generic IPv6 encapsulating > > mechanism a la UDP, but with a payload checksum of varying coverage > > (header only, partial payload, full payload) and with the (stronger > > than UDP) checksum placed at the end of the packet. > > > > Lloyd Wood > > http://about.me/lloydwood > > > Go for it! > > When a critical mass of routers hash on this new protocol number and > port space we'll let you know and the MPLS WG can obsolete MPLS over > UDP and replace it with MPLS over this new protocol. > > Thanks for offering to write this. > > Curtis > > > > ________________________________________ > > From: ietf [ietf-bounces@ietf.org] On Behalf Of Stewart Bryant [stbryant@cisco.com] > > Sent: 16 January 2014 17:35 > > To: Eggert, Lars; Joel Jaeggli > > Cc: mpls@ietf.org; IETF discussion list > > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > > > On 16/01/2014 17:19, Eggert, Lars wrote: > > > Hi, > > > > > > On 2014-1-16, at 18:06, joel jaeggli wrote: > > >> These tunnels are stateless > > > yep. (But they don't have to be.) > > Ah, they do if they are to scale. State at speed is really hard. The sort > > of systems we are talking about do things like pipeline counters > > and it is loooooots of packets later before the counter is actually > > incremented. > > >> The endpoints not the encapsulators have visibility into the > > >> end-to-end loss latency properties of the path. > > > Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 domains - where not reacting to congestion may be OK - can now go over the wider Internet, where this is not OK. > > > > > > I'd be great if those apps would change. But in the meantime, it's the duty of the encapsulator - who enables this traffic to break out of an L2 domain and go over the wider net - to make sure the traffic it emits conforms to our BCPs. > > > > > >> the encapsulator is an intermediate hop, similar to any other router > > >> in the path. > > > It's not. For the rest of the network, that encapsulator is indistinguishable from any other app that sends UDP traffic. > > > > > > UDP is a transport-layer protocol, and we have practices how it is to be used on the net. If you want to use it for encapsulation, you bind yourself to these BCPs. > > > > > > Look at it the other way: if transport area folks would want to send MPLS packets into the network in some problematic way, I'm sure the routing and ops folks would not be amused. > > The root cause of the problem here is that UDP, has bifurcated into > > a general purpose encapsulation. > > > > Stewart From l.wood@surrey.ac.uk Mon Jan 20 15:13:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061A01A0272; Mon, 20 Jan 2014 15:13:02 -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, 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 8ONO69m9g_X7; Mon, 20 Jan 2014 15:12:58 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id 551E41A022B; Mon, 20 Jan 2014 15:12:57 -0800 (PST) Received: from [85.158.136.51:2109] by server-17.bemta-5.messagelabs.com id 31/E9-19152-87DADD25; Mon, 20 Jan 2014 23:12:56 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-49.messagelabs.com!1390259575!25528403!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1613 invoked from network); 20 Jan 2014 23:12:55 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-14.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 20 Jan 2014 23:12:55 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Mon, 20 Jan 2014 23:12:54 +0000 From: To: Date: Mon, 20 Jan 2014 23:11:05 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8WM2X1RbWDYR4VRMe+b3I1p2VF1gAAX75U Message-ID: <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> References: Your message of "Fri, 17 Jan 2014 23:00:33 +0000." <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk>, <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> In-Reply-To: <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 23:13:02 -0000 > Router vendors focus on real needs identified by customers. If this > were to become something customers were bugging them about, then > they'll do it. And pollution of ports for other traffic, like congestion, is something experienced by people who are not customers - the rest of the net. Which is why this draft does not address the possibility of missent traffic= , and does not address congestion. Not a tunnel customer problem, therefore not a vendor problem. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 20 January 2014 22:47 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com; stbryant@cisco.com; lars@netapp.com; joelja@bogu= s.com; mpls@ietf.org; ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard We are continuing to stray off topic, but... Router vendors focus on real needs identified by customers. If this were to become something customers were bugging them about, then they'll do it. OTOH, most hardware in the field today can only track one 32 bit FCS, given that only one L2 header would need this. The ability to run on existing hardware is important. Perhaps you missed this: > When a critical mass of routers hash on this new protocol number and > port space we'll let you know and the MPLS WG can obsolete MPLS over > UDP and replace it with MPLS over this new protocol. Providers and router vendors are also aware that most routers look only for protocol numbers 6 and 17 for load balancing on port numbers. So if the motivation of MPLS over UDP is an interim solution to get ECMP, then not using UDP is not an option. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > > Yes, it would be unreasonable for the router vendors themselves to design > something with a trailing checksum and pseudo-header check that would mee= t > their forwarding needs while ensuring reliability. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 17 January 2014 18:05 > To: Wood L Dr (Electronic Eng) > Cc: stbryant@cisco.com; lars@netapp.com; joelja@bogus.com; mpls@ietf.org;= ietf@ietf.org > Subject: Re: [mpls] Last Call: (Encapsula= ting MPLS in UDP) to Proposed Standard > > In message <290E20B455C66743BE178C5C84F1240847E63346CF@EXMB01CMS.surrey.a= c.uk> > l.wood@surrey.ac.uk writes: > > > There's an opportunity to define a simple generic IPv6 encapsulating > > mechanism a la UDP, but with a payload checksum of varying coverage > > (header only, partial payload, full payload) and with the (stronger > > than UDP) checksum placed at the end of the packet. > > > > Lloyd Wood > > http://about.me/lloydwood > > > Go for it! > > When a critical mass of routers hash on this new protocol number and > port space we'll let you know and the MPLS WG can obsolete MPLS over > UDP and replace it with MPLS over this new protocol. > > Thanks for offering to write this. > > Curtis > > > > ________________________________________ > > From: ietf [ietf-bounces@ietf.org] On Behalf Of Stewart Bryant [stbryan= t@cisco.com] > > Sent: 16 January 2014 17:35 > > To: Eggert, Lars; Joel Jaeggli > > Cc: mpls@ietf.org; IETF discussion list > > Subject: Re: [mpls] Last Call: (Encapsu= lating MPLS in UDP) to Proposed Standard > > > > On 16/01/2014 17:19, Eggert, Lars wrote: > > > Hi, > > > > > > On 2014-1-16, at 18:06, joel jaeggli wrote: > > >> These tunnels are stateless > > > yep. (But they don't have to be.) > > Ah, they do if they are to scale. State at speed is really hard. The so= rt > > of systems we are talking about do things like pipeline counters > > and it is loooooots of packets later before the counter is actually > > incremented. > > >> The endpoints not the encapsulators have visibility into the > > >> end-to-end loss latency properties of the path. > > > Yep. But when you tunnel some L2 in UDP, apps that were limited to L2= domains - where not reacting to congestion may be OK - can now go over the= wider Internet, where this is not OK. > > > > > > I'd be great if those apps would change. But in the meantime, it's th= e duty of the encapsulator - who enables this traffic to break out of an L2= domain and go over the wider net - to make sure the traffic it emits confo= rms to our BCPs. > > > > > >> the encapsulator is an intermediate hop, similar to any other rout= er > > >> in the path. > > > It's not. For the rest of the network, that encapsulator is indisting= uishable from any other app that sends UDP traffic. > > > > > > UDP is a transport-layer protocol, and we have practices how it is to= be used on the net. If you want to use it for encapsulation, you bind your= self to these BCPs. > > > > > > Look at it the other way: if transport area folks would want to send = MPLS packets into the network in some problematic way, I'm sure the routing= and ops folks would not be amused. > > The root cause of the problem here is that UDP, has bifurcated into > > a general purpose encapsulation. > > > > Stewart= From curtis@ipv6.occnc.com Mon Jan 20 22:52:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059BD1A02BD for ; Mon, 20 Jan 2014 22:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 QAqvHOZcmQQ7 for ; Mon, 20 Jan 2014 22:52:35 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 598FA1A02BC for ; Mon, 20 Jan 2014 22:52:35 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0L6qDAc053024; Tue, 21 Jan 2014 01:52:13 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401210652.s0L6qDAc053024@maildrop2.v6ds.occnc.com> To: "Nobo Akiya (nobo)" From: Curtis Villamizar In-reply-to: Your message of "Sun, 19 Jan 2014 17:02:49 +0000." Date: Tue, 21 Jan 2014 01:52:13 -0500 Cc: "mpls@ietf.org" , "draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org" , Curtis Villamizar , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 06:52:39 -0000 In message "Nobo Akiya (nobo)" writes: > > Hi Curtis, > > Thanks for detailed comments. > > > Overall a good draft and should become a WG doc as it is an improvement > > to a fairly badly designed feature of MPLS Ping that remains fairly badly > > designed but now a little less broken for ELI/EL. > > > > I'm not sure the procedures that are defined work correctly if an LSR does > > load split on the label stack (or part of it) up to and then including the EL, > > but nothing after the EL. There seems to be an assumption that only the EL > > is used if present. The way the RFC 6790 reads the search for entropy stops > > at the EL (a SHOULD that would have been better made a MUST). > > Assumption here is that label stack up to ELI/EL is constant for LSP > tracing purpose, thus defined procedure will work whether transit LSR > load balances on just (EL) or (label stack up to EL + EL). This > assumption is most probably worth being mentioned in the document, and > we will plan to do so. What I meant was you don't know what an LSR will do with the label entries below ELI/EL since RFC 6790 makes stopping the search for further entropy a SHOULD. An LSP carrying MPLS traffic will have other things under the ELI/EL. > The other tricky aspect depends on the outcome of > draft-ravisingh-mpls-el-for-seamless-mpls. If multiple ELI/ELs are > allowed in the label stack, and there are no clear defined forwarding > rule on load balancing in that case, then defined procedures will not > work, since we now have 2 (or more) non-constant values. I spoke to > R. Singh and Y. Shen at Vancouver and communicated this concern on > from OAM perspective. As I understand it, the load balancing SHOULD be based on the top EL according to RFC 6790. OTOH it is only SHOULD. > > Some (big) issues: > > > > {L=0, E=0} LSR load balances based on IP and does not push ELI/EL. > > {L=0, E=1} LSR load balances based on IP and pushes ELI/EL. > > {L=1, E=0} LSR load balances based on label and does not push ELI/EL. > > {L=1, E=1} LSR load balances based on label and pushes ELI/EL. > > > > What about the case where the LSR load balances on both labels and on IP? > > If the payload is IP, the entropy from the IP header is used *in addition to* > > the entropy from the label stack. > > You are right, that is still allowed by RFC6790. And load balance on labels plus IP was always allowed before RFC 6790. > [snip] > Some transit LSRs look beyond the label stack for better load- > balancing information. This is a simple, backward-compatible > approach in networks where some ingress LSRs impose ELs and others > don't. However, this is of limited incremental value if an EL is > indeed present and requires more packet processing from the LSR. A > transit LSR MAY choose to parse the label stack for the presence of > the ELI and look beyond the label stack only if it does not find it, > thus retaining the old behavior when needed, yet avoiding unnecessary > work if not needed. > [snip] > > Adding LSP traceroute support for such will require [even more] > complexities in the tools, which I personally would prefer to avoid if > possible. I'd like to hear from WG on this, particularly those > implementing ELI/EL. If there are any vendors looking at EL + IP for > load balancing when EL is present, and if we want this scenario to > also be supported by LSP traceroute, then we need to address this. Do you want tools that work for some networks and not others? If you want tools that work for all allowed behavior then you will need some complexity given the way the RFCs are defined. > > There should also be a flag to indicate that the LSR will terminate the search > > for entropy at the EL as it SHOULD according to RFC 6790. > > Wouldn't such flag potentially cause load balancing deviation between > traffic vs. MPLS echo request? The flag would be set in the Echo Reply and indicate which of these behaviors the LSR will be using on the traffic. > > The flags points to an issue with RFC 4379 even without ELI/EL that is still > > not addressed here. What if the typical payload contains both additional > > labels (payload is MPLS) and IP under the labels and some LSR look at only > > the IP and some look at only the labels and some look at both and some > > that look at labels can only look at the top N or the bottom N labels. > > Prior to this draft, supported scenarios were: > 1. LSP which all LSR load balances just on IP as entropy. > 2. LSP which all LSR load balances just on label stack as entropy. Which is why I've mentioned a number of times on MPLS WG mailing list and at meetings that the support for multipath in LSP Ping was broken. There are LSR that use both. > With this draft, we intend to add support for following scenario. > 3. LSP which all LSR load balances on IP as entropy OR label stack as > entropy (assuming constant label stack + one EL). > 4. Stitched/Hierarchical LSPs with ELI/EL push/pop operations by transit nodes. > > Which both scenario a very likely realistic scenario. And if that is all you cover, then LSP Ping remains broken. > Agree that there are many load balance implementations > possibilities. I wish there was a clear load balance rules defined > from the beginning. I also wish there _is_ a clear load balance rules > defined today ... is there one? Without clear defined rules, OAM is > placed in a very difficult position: i.e. solving all theoretically > possible scenarios will significantly complicate the tools to the > point where desire to implement will likely significantly diminish. > > All this to say, your comment raises a great point that perhaps we > should take a step back and find out the realistic combinations which > WG plans to solve from OAM perspective. LSP Ping should cover all of the cases that are legal: IP only labels only both IP and labels No EL support EL support also using labels above ELI/EL EL support throwing out anything above ELI/EL, using EL only EL support terminating at EL EL support but also using labels below EL There are quite a few combinations. Add to this: only the top N labels up to M bottom labels for label stack of up to N labels (M < N) can only find IP stack if label stack <= depth of N hash on special labels special labels are skipped skip special labels but count toward limits This is why some flags are needed so that the LSR can in the Echo Reply indicate how it behaves. Any change to RFC 4379 should document how to deal with each of the cases as best as possible. > > Also the max depth in RFC 4379 is inadequate since some LSR can look at > > labels up to some depth D1 and can find an IP header if it appears at up to > > some depth D2 and D1 != D2. These two depths are not independent in RFC > > 4379. > > Noted. > > > > > A few additional flags and values need to be carried if these cases are all to > > be covered. OTOH, RFC 4379 works fine for a single vendor network if all > > their products behave in the same way. > > > > This draft acknowledges that there are some issues (including with > > E=0 that existing in RFC 4379 prior to ELI/EL) but doesn't fix them even > > though they are fixable: > > > > In following conditions, initiating LSR may have lost the ability > > to exercise specific ECMP paths. Initiating LSR MAY continue with > > "best effort". > > > > o Received echo reply contains empty multipath information. > > > > o Received echo reply contains {L=0, E=} DS flags, but does > > not contain IP multipath information. > > > > o Received echo reply contains {L=1, E=} DS flags, but does > > not contain label multipath information. > > > > o Received echo reply contains {L=, E=1} DS flags, but does > > not contain associated label multipath information. > > > > o IP multipath information types {2, 4, 8} sent, and received echo > > reply with {L=1, E=0} in DS flags. > > > > o Multipath information type {10} sent, and received echo reply > > with multipath information type other than {10}. > > Correct, we acknowledge the scenarios which we do not support. This > goes back to the point [above] of what scenarios we want to fix. We > can use some help from WG to define this space. The problem here is that if one LSR uses labels only and another uses IP only and the LSP is carrying MPLS traffic (traffic payload already has labels) with IP under it, then the traffic exercises all paths but the OAM just gives up. > > On the topic of flags, the N bit was always problematic. When TTL is > > incremented the LSR will behave as if the packet is IP, because it is. > > Interesting point, didn't think about this one, but yes I agree, it's > troublesome. So the N bit does nothing useful. > > The flags and defined behavior for this failure is an improvement over RFC > > 4379 where the behavior was undefined both in terms of what to put in the > > reply and how the initiator should interpret it. > > > > Througout the document it is not clear what an IP load balancer is. > > For example:` > > > > o When initiating LSR is IP based load balancer (not pushing ELI/ > > EL), initialize EL_LSP=False. > > > > The initiating LSR may be a carrying MPLS traffic (ie: a PSC LSP). > > Therefore is may get traffic that already has an ELI/EL in the stack. > > > > This is not worded clearly for the case where the LSR is capable of IP based > > load balance but is not pushing an ELI/EL but it has already seen an ELI/EL > > on the stack. Need to clarify whether the LSR is an "IP based load balancer" > > if it is capable of IP based load balance or if it would have done IP based > > load balance on this stack. > > To trace the LSP starting from such LSR, I don't believe *stitching > behavior* of the LSR is not relevant. Yes such LSR can be egress of > ELC LSP, but [some] packets MAY or MAY NOT come in with ELI/EL, when > ELI/EL is pushed is up to ingress to decide. If we want to diagnose > the *stitching behavior* of the LSR, we will have to initiate the LSP > traceroute from prior LSP. I'm thinking of hierarchy, not stitching. The existing ELI/EL in the traffic is on the stack after the client LSP label. > > The term "IP Based Load Balancer" is never defined. > > > > The term "Label Based Load Balancer" is never defined. > > Good point. We will add a terminology for those. Thanks. > > It is not clear which to pick if an LSR can use both types of information as > > would be the case for many routers when no ELI/EL is found in the stack. > > This one, again, goes back to the problem-space point above. If that is the behavior of an LSR then LSP Ping doesn't work. Leaving a big hole in LSP Ping is not a good thing. > > In "9. Unsupported Cases" you might as well admit "won't ever work for > > some vendor's equipment that uses the whole label stack to load balance > > plus can use IP stack". > > ACK. Until problem-space is defined, we will clarify these assumption > which proposal is intended work. > > > The two unsupported cases are: > > > > o When one or more LSP transit node(s) performs label based load > > balancing on a label that is not bottom-of-stack label when > > Entropy Label Indicator is not included. > > > > A lot of equipment uses all of the labels. Did you means does not use the > > bottom label? > > Good point. We will rephrase above. > > > > > o When one or more LSP transit node(s) performs label based load > > balancing on a label other than Entropy Label when Entropy Label > > Indicator and Entropy Label pair is included. > > > > It is also legal (and I think preferred) to use all of the labels up to and > > including the first EL (but not the ELI and any other reserved label). Did you > > means a label after the EL? > > It would be a good idea to rephrase above as well, thank you for > pointing this out. > > > > > Either these unsupported cases are worded wrong or something is very > > seriously wrong with LSP Ping. > > > > Some minor points: > > > > RFC 6424 should be mentioned as soon as RFC 4379 is mentioned in the > > intro since RFC 6424 changes RFC 4379 behavior and depricated a RFC > > 4379 TLV and replaces it. > > ACK. > > > > > When an MPLS echo request message is received containing a > > FEC-Stack with an EL-FEC at the bottom of the FEC stack and is not > > preceded by an entropy label, the responder must behave (for load > > balancing purposes) as if the first word of the message were a > > Pseudowire Control Word. > > > > This is asking for the DD-MAP or DS-MAP response to be constructed as if > > CW was at bottom, but doesn't read that way. It reads as if forwarding was > > changed. > > I will check with George on this, but I believe what he meant was: > > When an MPLS echo request message is received containing a > FEC-Stack with an EL-FEC at the bottom of the FEC stack and is not > preceded by an Nil-FEC indicating ELI, the responder must behave > (for load balancing purposes) as if the first word of the message > were a Pseudowire Control Word. For LSR that look past the EL when TTL is incremented the data plane will not behave that way. The Echo Reply should indicate that this is going to happen. > > Note that this procedure only traces to the end of the MPLS LSP at > > transport layer (e.g. LDP and/or RSVP). > > > > That is not what "transport layer" means to a lot of people. Very bad > > wording. > > Sorry for newbie mistake. Any wording you can suggest? I think what you were trying to say here was: Note that this procedure only traces to the end of the MPLS LSP that is under test and will not verify the PW FEC. Also: To actually verify the PW-FEC or in the case of a MS-PW, to determine the next pseudowire label value, the initiator MUST repeat that step of the trace, (i.e., repeating the TTL value used) but with the FEC- Stack modified to contain the appropriate PW-FEC. I don't think this (the whole procedure in this paragraph actually works for LSR that use the whole label stack up to the EL (or fat PW label). For fat PW the PW and flow label will both be used. You need to put the PW label in the stack. That is where the VCCV CW comes in handy, allowing the OAM IP payload to be carried but not treated as IP. This CW usage (or GAL) can be carried into LSP Ping. > > * Else initiating LSR MUST use multipath information type {2, > > 4, 8, 9}. > > > > Exactly what should it do if load balance is affected by *either* another > > label on the stack or a different IP under the stack? What if both peices of > > information are used in creating load balance entropy > > (ie: what if the IP map depends on any additional labels)? > > Yes, let's get consensus on problem-space first. In the past I've advocated either fixing or depricating LSP Ping multipath support. > > Nits: > > > > s/indicate and entropy/indicate and entropy/ > > Thanks & ACK on s/indicate and entropy/indicate an entropy/ oops > > In "5.2. IP Based Load Balancer & Pushes ELI/EL" third bullet is a massive > > run-on paragraph. Split into sub-bullets for the multiple case within it. > > Probably good for other bullets containing more than one sentence starting > > with "If". > > Ok, will do. > > And again, thank you for providing detailed comments!! > > -Nobo Thanks, Curtis > > probably plenty more nits that I missed. > > > > Curtis From loa@pi.nu Tue Jan 21 00:42:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1821F1A0068 for ; Tue, 21 Jan 2014 00:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 B4muz8M2lLqv for ; Tue, 21 Jan 2014 00:42:31 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5E71A006B for ; Tue, 21 Jan 2014 00:42:31 -0800 (PST) Received: from [192.168.1.3] (unknown [49.147.219.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 58B7A1802AAA; Tue, 21 Jan 2014 09:42:29 +0100 (CET) Message-ID: <52DE32F0.3050005@pi.nu> Date: Tue, 21 Jan 2014 16:42:24 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <52C795FE.7060801@pi.nu> In-Reply-To: <52C795FE.7060801@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org Subject: [mpls] Closed: Working group last call on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 08:42:33 -0000 Working Group, This working group last call is closed. There has been comments, could the authors please address the comments and re-post a new version of the document as necessary. Please make sure that the reviewers are comfortable with how the comments are resolved. /Loa mpls wg co-chair On 2014-01-04 13:02, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-proxy-lsp-ping-01.txt > > Please send your comments to working group mailing lists > (mpls@ietf.org). > > We will do an IPR poll on this document in parallel thee wglc. > > There are three IPRs disclosures that relates to this document. > > The working group last call will end Friday January 20, 2914. > > /Loa > mpls wg co-chair > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Tue Jan 21 02:28:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302891A009E for ; Tue, 21 Jan 2014 02:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 74WI-tfuvKyn for ; Tue, 21 Jan 2014 02:28:15 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 02E331A0050 for ; Tue, 21 Jan 2014 02:28:14 -0800 (PST) Received: from [192.168.1.3] (unknown [49.147.219.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 3CE4018029FB; Tue, 21 Jan 2014 11:28:11 +0100 (CET) Message-ID: <52DE4BB7.80408@pi.nu> Date: Tue, 21 Jan 2014 18:28:07 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org" Subject: [mpls] Short working group last call on draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 10:28:16 -0000 Working Group, We did a working group last call on draft-ietf-mpls-ldp-applicability- label-adv in March 2013. The draft was updated according to the wglc comments and Publication Requested. The AD evaluation and the discussion with the authors resultetd in changes that makes it reasonable to verify that the working group are comfortable with the changes that has been doen. Please send your comments to the working group mailing list (mpls@ietf.org). In this case silence will be interpreted as agreement. This working group last call ends January 28th, 2014. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From stbryant@cisco.com Tue Jan 21 03:50:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1601A009A for ; Tue, 21 Jan 2014 03:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 F2gP8ptHjUvV for ; Tue, 21 Jan 2014 03:50:55 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id DB6C01A0061 for ; Tue, 21 Jan 2014 03:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=260; q=dns/txt; s=iport; t=1390305055; x=1391514655; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8END1lBHfte59BHDDtZxm/D3Its2pY1iNPJg1lpfE4k=; b=UoTXB1UKOWby+UTaMaHZpW1Ljx0ZEezG2yoM428LvsUSH4j41yW3WywI y+FJ8Cjz9+jlvB3meQEpvgU8/EnoCyBdbZ0enM6fkUtFW1PK4RcqUSlQf Ms6VasnjCfkG+Pj3ExVixH9YOi0Y/UwKbmL3+srWuqwz2HQIETe6c4rcl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAONe3lKQ/khM/2dsb2JhbABZDoJ9vHSBExZ0giYBAQQ4QAEQCyEWBAsJAwIBAgFFBwwBBwEBiAHECReOfweEOAEDmCKSGIFvfz8 X-IronPort-AV: E=Sophos;i="4.95,696,1384300800"; d="scan'208";a="3272367" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 21 Jan 2014 11:50:54 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0LBorLr024563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jan 2014 11:50:54 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0LBonpc014129; Tue, 21 Jan 2014 11:50:49 GMT Message-ID: <52DE5F19.1060907@cisco.com> Date: Tue, 21 Jan 2014 11:50:49 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, curtis@ipv6.occnc.com References: Your message of "Fri, 17 Jan 2014 23:00:33 +0000." <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk>, <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 11:50:56 -0000 Removing IETF from this lists In terms of congestion and misdelivery it is interesting looking at the number of horses that are already bounding around in the paddock outside the stable: IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. Stewart From lars@netapp.com Tue Jan 21 04:07:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C301A0092 for ; Tue, 21 Jan 2014 04:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 Uoulz6XhRHJE for ; Tue, 21 Jan 2014 04:07:37 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id B021F1A006A for ; Tue, 21 Jan 2014 04:07:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,696,1384329600"; d="asc'?scan'208";a="97213246" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 21 Jan 2014 04:07:37 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 04:07:38 -0800 From: "Eggert, Lars" To: Stewart Bryant Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPFjGjZzPPQlRcgk6ua2U45NfiYJqOw4KAgADURICAAAStgA== Date: Tue, 21 Jan 2014 12:07:35 +0000 Message-ID: <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> References: Your message of "Fri, 17 Jan 2014 23:00:33 +0000." <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk>, <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> <52DE5F19.1060907@cisco.com> In-Reply-To: <52DE5F19.1060907@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_8A98B6E9-85F5-4702-B782-B2F0BEC5D315"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 12:07:39 -0000 --Apple-Mail=_8A98B6E9-85F5-4702-B782-B2F0BEC5D315 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 2014-1-21, at 12:50, Stewart Bryant wrote: > In terms of congestion and misdelivery it is interesting looking > at the number of horses that are already bounding around > in the paddock outside the stable: >=20 > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. there is a big difference between encapsulation in IP and encapsulation = in UDP. Everything encapsulated with "obscure" IP protocol numbers will = get dropped by default at NATs and firewalls, whereas UDO traffic = happily traverses them. The reach of UDP traffic is much broader. Lars --Apple-Mail=_8A98B6E9-85F5-4702-B782-B2F0BEC5D315 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----- iQCVAwUBUt5jBdZcnpRveo1xAQJzewP+PZPeHqKtlsUl1OMDlkou6UbEHCjwS/7l IeqvL0dBIa46ym24v5hLW4VTAzs4sy6N43ZT/ITuMGv+0F96aKpeCky+JHj3AJUp twlADGKNkD9xl2fqeH/zIZ/afoYV0fIct078vJp8snoTDMGfOccIZdrQLL17gc+b HC/GorjD+/4= =INwU -----END PGP SIGNATURE----- --Apple-Mail=_8A98B6E9-85F5-4702-B782-B2F0BEC5D315-- From stbryant@cisco.com Tue Jan 21 04:29:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941B01A00CD for ; Tue, 21 Jan 2014 04:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 Fz_Mhi6-jRZK for ; Tue, 21 Jan 2014 04:29:03 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id CB0521A00C8 for ; Tue, 21 Jan 2014 04:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1019; q=dns/txt; s=iport; t=1390307343; x=1391516943; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TJIlpsBFnZ6KHsYRqeAOFHJOiCZNxDCu4UWv9jbwUzM=; b=WgLD76UO0F5RepGytb69yP54axImxqADUURbfU/NzybsBgy2acz+TFCv rKpqtY0siyRqubWtOFhZrXp5WEqJl/LRactlA9jrXc7ocoYDPAGQYHAIP UjZJTovahLpR5xo6ixDXU+9lJKWakfG2TTICgRyKA3cRc71nm/iSj1vzS s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFABRn3lKQ/khN/2dsb2JhbABZgwu8d4EQFnSCJQEBAQQ4QRALGAkaCw8CRgYNAQUCAQGIAcQMF45/B4Q4AQOYIpIYgW+BPg X-IronPort-AV: E=Sophos;i="4.95,696,1384300800"; d="scan'208";a="3273979" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 21 Jan 2014 12:29:01 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0LCT1jF006155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jan 2014 12:29:02 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0LCT08k016251; Tue, 21 Jan 2014 12:29:00 GMT Message-ID: <52DE680C.30704@cisco.com> Date: Tue, 21 Jan 2014 12:29:00 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Eggert, Lars" References: Your message of "Fri, 17 Jan 2014 23:00:33 +0000." <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk>, <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> <52DE5F19.1060907@cisco.com> <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> In-Reply-To: <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 12:29:04 -0000 On 21/01/2014 12:07, Eggert, Lars wrote: > Hi, > > On 2014-1-21, at 12:50, Stewart Bryant wrote: >> In terms of congestion and misdelivery it is interesting looking >> at the number of horses that are already bounding around >> in the paddock outside the stable: >> >> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > there is a big difference between encapsulation in IP and encapsulation in UDP. Everything encapsulated with "obscure" IP protocol numbers will get dropped by default at NATs and firewalls, whereas UDO traffic happily traverses them. The reach of UDP traffic is much broader. > > Lars So we have established that it's not the load on the NATs and Firewalls we are worried about. Seemingly from the above congestion is off the table as well. Now surely those same NATs and firewalls will be looking for an SA, DA, Type, SP, DP match and that is a lot of things that have to be right for a header corruption misdelivery to get through. - Stewart From lars@netapp.com Tue Jan 21 04:31:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3EB1A00C9 for ; Tue, 21 Jan 2014 04:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.437 X-Spam-Level: X-Spam-Status: No, score=-7.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 YN8YIzOP56Gs for ; Tue, 21 Jan 2014 04:31:35 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id D1C881A00BD for ; Tue, 21 Jan 2014 04:31:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,696,1384329600"; d="asc'?scan'208";a="138153533" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 21 Jan 2014 04:31:35 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 04:31:35 -0800 From: "Eggert, Lars" To: Stewart Bryant Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPFjGjZzPPQlRcgk6ua2U45NfiYJqOw4KAgADURICAAAStgIAABf8AgAAAtwA= Date: Tue, 21 Jan 2014 12:31:34 +0000 Message-ID: References: Your message of "Fri, 17 Jan 2014 23:00:33 +0000." <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk>, <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> <52DE5F19.1060907@cisco.com> <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> <52DE680C.30704@cisco.com> In-Reply-To: <52DE680C.30704@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_784D3809-7870-4E96-A1CA-722F73BAD5BB"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 12:31:37 -0000 --Apple-Mail=_784D3809-7870-4E96-A1CA-722F73BAD5BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2014-1-21, at 13:29, Stewart Bryant wrote: > So we have established that it's not the load on the NATs and = Firewalls we are worried about. >=20 > Seemingly from the above congestion is off the table as well. >=20 > Now surely those same NATs and firewalls will be looking for an SA, = DA, Type, SP, DP match > and that is a lot of things that have to be right for a header = corruption misdelivery to get > through. Of course it's not the load. It's that if someone encapsulates congestion-unresponsive traffic in = UDP, it can go places where it can't go when it is encapsulated in IP. = So the potential harm is greater if the encapsulator doesn't implement = congestion control or a circuit breaker. Lars --Apple-Mail=_784D3809-7870-4E96-A1CA-722F73BAD5BB 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----- iQCVAwUBUt5optZcnpRveo1xAQKf0wQAlA4BW56ehpFQrSRCqTAB8zVIUi7n85AC BXdkeas4xtIPfBvE+AGF0V0u84KOInf63IrPJRDsaXuyJI6nEVGSGJzgxs87LMht /NJVz/Lc5O0D6q5/00NuUrC/K2QelrcfytekKvQza1tM8U8YRl78PWuWsuG12DVN HKwfZxVpGao= =T+A2 -----END PGP SIGNATURE----- --Apple-Mail=_784D3809-7870-4E96-A1CA-722F73BAD5BB-- From lars@netapp.com Tue Jan 21 05:22:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F1F1A00EC; Tue, 21 Jan 2014 05:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 TZ34nwMaV9-w; Tue, 21 Jan 2014 05:22:51 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 88C0F1A00CF; Tue, 21 Jan 2014 05:22:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,696,1384329600"; d="asc'?scan'208";a="97226067" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 21 Jan 2014 05:22:51 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 05:22:51 -0800 From: "Eggert, Lars" To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPE6hVZzPPQlRcgk6ua2U45NfiYJqPto2A Date: Tue, 21 Jan 2014 13:22:50 +0000 Message-ID: References: <201401171719.s0HHJqHY062965@maildrop2.v6ds.occnc.com> In-Reply-To: <201401171719.s0HHJqHY062965@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_43F78036-C5EC-458C-9F4D-22B8DDF299CC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Joel Jaeggli , "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 13:22:53 -0000 --Apple-Mail=_43F78036-C5EC-458C-9F4D-22B8DDF299CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-1-17, at 18:19, Curtis Villamizar wrote: > You have made your assertions about your desire to uphold the purity > of any new UDP applications and adhere to the BCP you wrote. >=20 > You appear to be very nearly alone in this argument and certainly no > one that works with MPLS is siding with you. the reason we wrote the RFC when I was TSV AD was that we were seeing a = whole bunch of questionable uses of UDP over the eyars and we were = having the same arguments over and over. That's why we decided to write = down the practices we expect users of UDP to follow. This is yet another = such questionable use. (Also, I don't appreciate you turning this into a personal argument.) > In the end we can put anything we want in the RFC *but* IETF has never > truly had the final word on what vendors and operators do in provider > networks. Aka the "take my toys and go home" argument. Heard it many times. > In this case, regardless of what changes are made to the draft, > implementations will offer at least the option for non-RFC behavior by > using zero checksums and not using any congestion control. And > providers will make use of it, perhaps exclusively. And there's nothing wrong with that - the BCP even says that one SHOULD = NOT use congestion control for some deployment cases. But for others, one SHOULD. For those, a mechanism needs to be = available, i.e., it needs to be specified and implemented. > The document might as well reflect reality, despite reality not > conforming to your notions of architectural purity. I'm sorry, but we have certain architectural principles in the Internet = that we have IETF consensus on. At least since RFC2914, that includes = the need to have congestion control in place. There are always special deployment scenarios where these principles do = not apply, and we typically explain in applicability statements when out = specifications can only be safely used under certain conditions. I don't = see any such statement in draft-ietf-mpls-in-udp, which to me means it's = targeted at general Internet-wide use. > The best course of action is to put a SHOULD in regarding checksums > and put a SHOULD in regarding congestion avoidance. Even the BCP does > not go any further than to say a tunneling protocol SHOULD use > congestion control and there were reasons that the word MUST was not > acceptable in the BCP. The SHOULD for congestion control needs to actually describe a mechanism = that can be used when needed. It can't be a blanket "you SHOULD use = something but we don't tell you what it is"-statement. > If we are still arguing over two instances of SHOULD vs MUST we have > wasted a lot of bandwidth on those two words. It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it needs = to be specified what is to be done. In the case of checksums, that's = obvious (calculate it and check it); in the case of congestion control, = some actual mechanism needs to be described (e.g., a circuit breaker). > IMHO The only remaining question is whether the document can go = forward > with the definition of congestion control for MPLS over UDP left out > of scope and for another document if a need arises. In my opinion, it cannot. > If this is not acceptable to you (I doubt it is) please indicate what > you would like to see in the document and since this is IETF last call > where consensus matters and no one individual has veto power, we'll > have to see if there is consensus behind your proposed changes. I would like the document to specify at the very least a circuit breaker = mechanism, that stops the tunneled traffic if severe packet loss is = detected along the path. And this isn't about an "individual veto". This is about a document that = is at the moment in violation of IETF consensus at least as far back as = RFC2914. Lars --Apple-Mail=_43F78036-C5EC-458C-9F4D-22B8DDF299CC 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----- iQCVAwUBUt50qdZcnpRveo1xAQK2uQP/ZqatIuOb8OeFnQecASThxV/kogHB2Q8h qojxxjDxE7YLzI82TnOt0GF04I9ns4eZ8vd+wvz9ZLrEWlASpR4Ws7DmmBCs6GdX y/g1rNsN5bE7J53EWM84baxWdE7EeKTliax8NDNd1YKoElcHrmJdU+QqmASEUCjB nOwB1XSpTbc= =LDDc -----END PGP SIGNATURE----- --Apple-Mail=_43F78036-C5EC-458C-9F4D-22B8DDF299CC-- From skraza@cisco.com Tue Jan 21 06:22:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3612E1A012E for ; Tue, 21 Jan 2014 06:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 7rHh9aG3WxaO for ; Tue, 21 Jan 2014 06:22:48 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 435871A00F4 for ; Tue, 21 Jan 2014 06:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1439; q=dns/txt; s=iport; t=1390314169; x=1391523769; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VeMWSmfKW1XffJiwHFQGgcKi4+mVVyKoPRuY6XWVC6o=; b=hUerqXOQLYeySQvABR4jcuPkZiLr1dH6vZEVaf4jqZUGWJ/aycRkD1V4 PhwY/V5XNeqUKJd/VBuHvrGiUpp4RZIZ9JyE74UdG9FsMBJiZAJIOpRkZ fxrGzqUgPKc5NGdMQ9cWHaihOzG0orWMe/hboqEy6PBblWfOMRVnQTYE/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAEmC3lKtJV2c/2dsb2JhbABagwuBDrttgQ8WdIIsOjEDCw4EAQg2KxclAgQOBYgFxH4XBI4ZEQFQB4Q4AQOYIpIYgW+BPoFxOQ X-IronPort-AV: E=Sophos;i="4.95,696,1384300800"; d="scan'208";a="295677211" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 21 Jan 2014 14:22:48 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0LEMl0e008848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 14:22:47 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.14]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 08:22:47 -0600 From: "Kamran Raza (skraza)" To: "mpls@ietf.org" Thread-Topic: Short working group last call on draft-ietf-mpls-ldp-applicability-label-adv Thread-Index: AQHPFpODKUI/m5ffZEyLlyb4Ov6XI5qPTB2A Date: Tue, 21 Jan 2014 14:22:47 +0000 Message-ID: In-Reply-To: <52DE4BB7.80408@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [161.44.212.195] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B8FBAC4FDC0B240BEB7A953A345921C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org" Subject: Re: [mpls] Short working group last call on draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:22:53 -0000 FYR, the main changes in this rev are: - This document now covers all the currently defined FECs and states their label adv mode; - The doc title is renamed to "Label Advertisement Discipline for LDP FECs"; - Cleanup/removal of introductory text - Update to RFC 5036 - Specification of mode for all standardized FEC types and updates to their respective RFCs - IANA considerations: Add a new column "Label Advertisement Discipline" in LDP FEC Type namespace Thanks for your review, -- Kamran (On behalf of I.D. authors) On 2014-01-21 5:28 AM, "Loa Andersson" wrote: >Working Group, > >We did a working group last call on draft-ietf-mpls-ldp-applicability- >label-adv in March 2013. The draft was updated according to the wglc >comments and Publication Requested. > >The AD evaluation and the discussion with the authors resultetd in >changes that makes it reasonable to verify that the working group are >comfortable with the changes that has been doen. > >Please send your comments to the working group mailing list >(mpls@ietf.org). In this case silence will be interpreted as >agreement. > >This working group last call ends January 28th, 2014. > >/Loa >mpls wg co-chair > > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From l.wood@surrey.ac.uk Tue Jan 21 09:56:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2930B1A0365 for ; Tue, 21 Jan 2014 09:56: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 UP4WFX2A43jC for ; Tue, 21 Jan 2014 09:56:35 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAB21A018E for ; Tue, 21 Jan 2014 09:56:35 -0800 (PST) Received: from [195.245.231.67:27711] by server-3.bemta-5.messagelabs.com id C8/E5-04773-2D4BED25; Tue, 21 Jan 2014 17:56:34 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-9.tower-82.messagelabs.com!1390326993!29955923!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12403 invoked from network); 21 Jan 2014 17:56:33 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-9.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jan 2014 17:56:33 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Tue, 21 Jan 2014 17:56:33 +0000 From: To: , Date: Tue, 21 Jan 2014 17:56:32 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8WpF8KNXZ4WxXGQNSyADM25xOoDgALJ+Sx Message-ID: <290E20B455C66743BE178C5C84F1240847E63346D9@EXMB01CMS.surrey.ac.uk> References: Your message of "Fri, 17 Jan 2014 23:00:33 +0000." <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk>, <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> <52DE5F19.1060907@cisco.com> <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com>,<52DE680C.30704@cisco.com> In-Reply-To: <52DE680C.30704@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:56:38 -0000 Stewart the IP header check is not the UDP pseudoheader check - and IPv6 has neithe= r. If a NAT gets a corrupted header, won't it open up new state and attempt to= translate for that header? Remember, this is UDP, not TCP - it's not on an= existing connection that must have already been opened by SYN/ACK, where t= he NAT is more likely to reject it as unknown. 'NATs, which rewrite and can trash headers, demonstrate and validate the in= tegrity of the Internet' is not a good argument imo. I'd like to see some evidence for '"obscure" IP protocol numbers will get d= ropped by default at NATs and firewalls.'. IP/GRE is relatively state-free,= nothing much to translate at transport there - it's not SCTP. I've spent a= couple of years running an ISP, and the 'oh, that protocol won't go throug= h your NAT' has not come up. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: 21 January 2014 12:29 To: Eggert, Lars Cc: Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com; Joel Jaeggli; mpls@= ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard On 21/01/2014 12:07, Eggert, Lars wrote: > Hi, > > On 2014-1-21, at 12:50, Stewart Bryant wrote: >> In terms of congestion and misdelivery it is interesting looking >> at the number of horses that are already bounding around >> in the paddock outside the stable: >> >> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > there is a big difference between encapsulation in IP and encapsulation i= n UDP. Everything encapsulated with "obscure" IP protocol numbers will get = dropped by default at NATs and firewalls, whereas UDO traffic happily trave= rses them. The reach of UDP traffic is much broader. > > Lars So we have established that it's not the load on the NATs and Firewalls we are worried about. Seemingly from the above congestion is off the table as well. Now surely those same NATs and firewalls will be looking for an SA, DA, Type, SP, DP match and that is a lot of things that have to be right for a header corruption misdelivery to get through. - Stewart From edc@google.com Tue Jan 21 11:20:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C721A01EB for ; Tue, 21 Jan 2014 11:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, 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 slQbSShUasW1 for ; Tue, 21 Jan 2014 11:20:10 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F1B451A01B8 for ; Tue, 21 Jan 2014 11:20:09 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id y10so8466477wgg.10 for ; Tue, 21 Jan 2014 11:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EW9LgIeK4q+2SxMCcshgt5j2HCuP8rbWawyBVWDlcRk=; b=LtAUlCfLhOQd2dbOY9mIcZohYWDPXEeO0lA1ezKtRkHa8O3xrFqD9CDV4hOBQXYtlE gbpF3vu7CHgquAoSh3hn+JcgiWwyUY20L20HH+ItajUozwpHZ62MYMuwMiWC5LhHhgVv drv6VNltfzwt6inBBXWNdpYNafseDV6RyLn9629W7VZT4NHOIxa00Q2WcVKDin2JABei fCK9WTWXkCqFmzsvdEw9WHAo+3DLP4VwKGxmTES8E15Kc7FFaQ7uMniT/tjs29kqsB+E Ul6bEYdtgkev0kcytimFPPgSq4n0kiCQgVNgr5sr8qwan70brchRwnJ/nuaRGsmrcKe+ WfIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EW9LgIeK4q+2SxMCcshgt5j2HCuP8rbWawyBVWDlcRk=; b=kY3Z7om0i5HxIvmCMyN59QC1Qd0y7sQTpP3ryD6tHv/GxhBcT8+BgUf3kFG4jiaT6m u8ce1hFyRU4qtP7NBFinGYZYF3NxRHvypIY/9JBeLu1F6uLW0NRaUHQKfO+viBMQmtPh w61QZG7YSvN4P3bt1TMDU9XeJrfkX6AG//fawEvV5k1cn7t6pu/Xwv5+9EN44cxDn8vD ueZCKMP1q3TV1eA6jgcP+1xHtCwJNZxLbloeaBINcfqv+OrRTboE9R9Yoz7bF0TPdiZq BNb60kRq7THHzbvT04q9Djjw/kNbEzJyXQxKAkDoL9Z77YyFHDB5tnKn0rgId/a8Tp/u tEDw== X-Gm-Message-State: ALoCoQnknyecVQTAd/qToLFXIVvLvqGqc546PKTnQO9PcyJ10fvm6q0hjtqh9k+kwF1H+h09KoyRv0OP5PloYxHDAQtXDpqq2M1vHJdCk4cbezoAUGYip6z8hGeugmcmWEmPWNmaHoTHmev0ht9Z2fe+3D21Q4Apu/jnTqO12PrLFcpayp35QbW3vP3oyoDL5KnZ7bg8GA7a X-Received: by 10.180.205.204 with SMTP id li12mr7726751wic.34.1390332008911; Tue, 21 Jan 2014 11:20:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Tue, 21 Jan 2014 11:19:28 -0800 (PST) In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346D9@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk> <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> <52DE5F19.1060907@cisco.com> <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> <52DE680C.30704@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346D9@EXMB01CMS.surrey.ac.uk> From: Edward Crabbe Date: Tue, 21 Jan 2014 11:19:28 -0800 Message-ID: To: l.wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=001a11c37bea82fe3a04f07fe553 Cc: joelja@bogus.com, "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:20:13 -0000 --001a11c37bea82fe3a04f07fe553 Content-Type: text/plain; charset=ISO-8859-1 I don't think the 'experience' card is such a good play here Lloyd. Many people on this list, and certainly a few of the ones you've been directly arguing with, have no small amount experience running *extremely* large, geographically distributed networks. I've spent a bit of time running some very large backbones and major content providers myself, and I have to say, I'm finding most of your arguments here to be unconvincing at best. I do find it a bit ironic that you're asking for (difficult to gather, vendor variable and generally poorly documented) data form Stewart, when your own argument has yet to be substantiated via any form of quantitative impact analysis, either empirically or theoretically in a modern setting. I'd be interested in seeing empirical (back)scatter collection data (similar to what Morley or Savage have done) to get some idea of impact here. I strongly suspect that corruption scatter will be trivial, and certainly completely overwhelmed in terms volume by typical, day to day DDoS backscatter. Perhaps this may be an idea for your next research paper? With regard to the congestion-control-of-all-tunnel-protocols argument: I find the argument to be specious. Curtis summed up the end-to-end version of this argument pretty succinctly in an earlier email, to wit: If congestion aware or using a congestion aware transport, the top level applications are still congestion aware. If congestion ignorant, they are still congestion ignorant. If hostile, they are still hostile. On Tue, Jan 21, 2014 at 9:56 AM, wrote: > Stewart > > the IP header check is not the UDP pseudoheader check - and IPv6 has > neither. > > If a NAT gets a corrupted header, won't it open up new state and attempt > to translate for that header? Remember, this is UDP, not TCP - it's not on > an existing connection that must have already been opened by SYN/ACK, where > the NAT is more likely to reject it as unknown. > > 'NATs, which rewrite and can trash headers, demonstrate and validate the > integrity of the Internet' is not a good argument imo. > > I'd like to see some evidence for '"obscure" IP protocol numbers will get > dropped by default at NATs and firewalls.'. IP/GRE is relatively > state-free, nothing much to translate at transport there - it's not SCTP. > I've spent a couple of years running an ISP, and the 'oh, that protocol > won't go through your NAT' has not come up. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: 21 January 2014 12:29 > To: Eggert, Lars > Cc: Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com; Joel Jaeggli; > mpls@ietf.org > Subject: Re: [mpls] Last Call: > (Encapsulating MPLS in UDP) to Proposed Standard > > On 21/01/2014 12:07, Eggert, Lars wrote: > > Hi, > > > > On 2014-1-21, at 12:50, Stewart Bryant wrote: > >> In terms of congestion and misdelivery it is interesting looking > >> at the number of horses that are already bounding around > >> in the paddock outside the stable: > >> > >> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > there is a big difference between encapsulation in IP and encapsulation > in UDP. Everything encapsulated with "obscure" IP protocol numbers will get > dropped by default at NATs and firewalls, whereas UDO traffic happily > traverses them. The reach of UDP traffic is much broader. > > > > Lars > So we have established that it's not the load on the NATs and Firewalls > we are worried about. > > Seemingly from the above congestion is off the table as well. > > Now surely those same NATs and firewalls will be looking for an SA, DA, > Type, SP, DP match > and that is a lot of things that have to be right for a header > corruption misdelivery to get > through. > > - Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11c37bea82fe3a04f07fe553 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't think the 'experience' card is such a = good play here Lloyd. =A0Many people on this list, and certainly a few of t= he ones you've been directly arguing with, have no small amount experie= nce running *extremely* large, geographically distributed networks. =A0 I&#= 39;ve spent a bit of time running some very large backbones and major conte= nt providers myself, and I have to say, I'm finding most of your argume= nts here to be unconvincing at best.=A0

I do find it a bit ironic that you're asking for (diffic= ult to gather, vendor variable and generally poorly documented) data form S= tewart, when your own argument has yet to be substantiated via any form of = quantitative impact analysis, either empirically or theoretically in a mode= rn setting. =A0I'd be interested in seeing empirical (back)scatter coll= ection data (similar to what Morley or Savage have done) to get some idea o= f impact here. =A0I strongly suspect that corruption scatter will be trivia= l, and certainly completely overwhelmed in terms volume by typical, day to = day DDoS backscatter. =A0Perhaps this may be an idea for your next research= paper?

With regard to the congestion-control-of-all-tunnel-pro= tocols argument: I find the argument to be specious. =A0Curtis summed up th= e end-to-end version of this argument pretty succinctly in an earlier email= , to wit:

= If congestion aware or using a congestion aware transport, the toplevel applications are still conge= stion aware. =A0If congestion
ignorant, they = are still congestion ignorant. =A0If hostile, they are
still hostile.=A0


On Tue, Jan 2= 1, 2014 at 9:56 AM, <l.wood@surrey.ac.uk> wrote:
Stewart

the IP header check is not the UDP pseudoheader check - and IPv6 has neithe= r.

If a NAT gets a corrupted header, won't it open up new state and attemp= t to translate for that header? Remember, this is UDP, not TCP - it's n= ot on an existing connection that must have already been opened by SYN/ACK,= where the NAT is more likely to reject it as unknown.

'NATs, which rewrite and can trash headers, demonstrate and validate th= e integrity of the Internet' is not a good argument imo.

I'd like to see some evidence for '"obscure" IP protocol = numbers will get dropped by default at NATs and firewalls.'. IP/GRE is = relatively state-free, nothing much to translate at transport there - it= 9;s not SCTP. I've spent a couple of years running an ISP, and the '= ;oh, that protocol won't go through your NAT' has not come up.

Lloyd Wood
http://about.me/llo= ydwood
________________________________________
From: Stewart Bryant [stbryant@cisco.com]
Sent: 21 January 2014 12:29
To: Eggert, Lars
Cc: Wood L =A0Dr (Electronic Eng); curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (= Encapsulating MPLS in UDP) to Proposed Standard

On 21/01/2014 12:07, Eggert, Lars wrote:
> Hi,
>
> On 2014-1-21, at 12:50, Stewart Bryant <stbryant@cisco.com> wrote:
>> In terms of congestion and misdelivery it is interesting looking >> at the number of horses that are already bounding around
>> in the paddock outside the stable:
>>
>> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example.
> there is a big difference between encapsulation in IP and encapsulatio= n in UDP. Everything encapsulated with "obscure" IP protocol numb= ers will get dropped by default at NATs and firewalls, whereas UDO traffic = happily traverses them. The reach of UDP traffic is much broader.
>
> Lars
So we have established that it's not the load on the NATs and Firewalls=
we are worried about.

Seemingly from the above congestion is off the table as well.

Now surely those same NATs and firewalls will be looking for an SA, DA,
Type, SP, DP match
and that is a lot of things that have to be right for a header
corruption misdelivery to get
through.

- Stewart


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--001a11c37bea82fe3a04f07fe553-- From l.wood@surrey.ac.uk Tue Jan 21 11:37:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0AF1A0232 for ; Tue, 21 Jan 2014 11:37:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 0Qv1M9dE8xwV for ; Tue, 21 Jan 2014 11:37:27 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.148]) by ietfa.amsl.com (Postfix) with ESMTP id E62381A01ED for ; Tue, 21 Jan 2014 11:37:26 -0800 (PST) Received: from [85.158.136.51:34409] by server-12.bemta-5.messagelabs.com id 3E/04-30017-67CCED25; Tue, 21 Jan 2014 19:37:26 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-10.tower-49.messagelabs.com!1390332991!29909075!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12294 invoked from network); 21 Jan 2014 19:37:25 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-10.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jan 2014 19:37:25 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Tue, 21 Jan 2014 19:36:30 +0000 From: To: Date: Tue, 21 Jan 2014 19:36:30 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8W3dhMoMWsRNvVSsmvqFpwUBTccgAAMmsV Message-ID: <290E20B455C66743BE178C5C84F1240847E63346DA@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk> <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> <52DE5F19.1060907@cisco.com> <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> <52DE680C.30704@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346D9@EXMB01CMS.surrey.ac.uk>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:37:31 -0000 Oh, 'experience' is never a good play; after all, all experience is ultimat= ely anecdotal. But as an argument, it's being used by all sides. We haven't= seen missent traffic errors, because we're not looking for them. The question is, what does the end-to-end argument support? And surely the burden of proof falls on those making the change (this draft= ); first, do no harm. The end-to-end principle and the precautionary princi= ple are strong arguments. Stone's papers, though technologically dated, support the underlying princi= ple and provide analysis - you want a modern setting, I'm quite happy with = proof of principle. Weird stuff happens; an end-to-end check can catch it. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Edward Crabbe [edc@google.com] Sent: 21 January 2014 19:19 To: Wood L Dr (Electronic Eng) Cc: stbryant@cisco.com; Eggert, Lars; joelja@bogus.com; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard I don't think the 'experience' card is such a good play here Lloyd. Many p= eople on this list, and certainly a few of the ones you've been directly ar= guing with, have no small amount experience running *extremely* large, geog= raphically distributed networks. I've spent a bit of time running some ve= ry large backbones and major content providers myself, and I have to say, I= 'm finding most of your arguments here to be unconvincing at best. I do find it a bit ironic that you're asking for (difficult to gather, vend= or variable and generally poorly documented) data form Stewart, when your o= wn argument has yet to be substantiated via any form of quantitative impact= analysis, either empirically or theoretically in a modern setting. I'd be= interested in seeing empirical (back)scatter collection data (similar to w= hat Morley or Savage have done) to get some idea of impact here. I strongl= y suspect that corruption scatter will be trivial, and certainly completely= overwhelmed in terms volume by typical, day to day DDoS backscatter. Perh= aps this may be an idea for your next research paper? With regard to the congestion-control-of-all-tunnel-protocols argument: I f= ind the argument to be specious. Curtis summed up the end-to-end version o= f this argument pretty succinctly in an earlier email, to wit: If congestion aware or using a congestion aware transport, the top level applications are still congestion aware. If congestion ignorant, they are still congestion ignorant. If hostile, they are still hostile. On Tue, Jan 21, 2014 at 9:56 AM, > wrote: Stewart the IP header check is not the UDP pseudoheader check - and IPv6 has neithe= r. If a NAT gets a corrupted header, won't it open up new state and attempt to= translate for that header? Remember, this is UDP, not TCP - it's not on an= existing connection that must have already been opened by SYN/ACK, where t= he NAT is more likely to reject it as unknown. 'NATs, which rewrite and can trash headers, demonstrate and validate the in= tegrity of the Internet' is not a good argument imo. I'd like to see some evidence for '"obscure" IP protocol numbers will get d= ropped by default at NATs and firewalls.'. IP/GRE is relatively state-free,= nothing much to translate at transport there - it's not SCTP. I've spent a= couple of years running an ISP, and the 'oh, that protocol won't go throug= h your NAT' has not come up. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: 21 January 2014 12:29 To: Eggert, Lars Cc: Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard On 21/01/2014 12:07, Eggert, Lars wrote: > Hi, > > On 2014-1-21, at 12:50, Stewart Bryant > wrote: >> In terms of congestion and misdelivery it is interesting looking >> at the number of horses that are already bounding around >> in the paddock outside the stable: >> >> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > there is a big difference between encapsulation in IP and encapsulation i= n UDP. Everything encapsulated with "obscure" IP protocol numbers will get = dropped by default at NATs and firewalls, whereas UDO traffic happily trave= rses them. The reach of UDP traffic is much broader. > > Lars So we have established that it's not the load on the NATs and Firewalls we are worried about. Seemingly from the above congestion is off the table as well. Now surely those same NATs and firewalls will be looking for an SA, DA, Type, SP, DP match and that is a lot of things that have to be right for a header corruption misdelivery to get through. - Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From edc@google.com Tue Jan 21 12:04:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A8E1A0341 for ; Tue, 21 Jan 2014 12:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, 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 MN5B3SrXydEt for ; Tue, 21 Jan 2014 12:04:14 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 30ACE1A0349 for ; Tue, 21 Jan 2014 12:04:14 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hr1so4831051wib.0 for ; Tue, 21 Jan 2014 12:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=28PwozEsKPVJCcg1IPGPdHG7dP++qF+/6Vp5YWK9UNo=; b=i3wqLYSXfPGsuQkDVw7hW6fROzkz9eS65urLQS1G9KUUbk+zk4ISsuFM3AEvULv23p nLCT26He1Fg1f6SThy7eM32HeWRUnjsIGDJBbpoG2Srmy8sMBXRXSYW5RS0ftFOkiwA0 1vPMNX9vBjkeBP94X4A0Lv9mjGaSubScK2hl/AdAX/gOwYGN9xJ8UoG1RtQgWU3YNkt8 aXBciwJsBdIrp5ueUrhXMVrC5xlL8EOuNt9aVAU16xnomdRExXZd/0bHoHsPJ+Qftefw WuGXXC/3Xz4W7HOobajSApg9o1rqXrKoDtJZWOs4RHSyGLz4PEZrP7Cla5qjvegCz/9j EnhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=28PwozEsKPVJCcg1IPGPdHG7dP++qF+/6Vp5YWK9UNo=; b=El4uX1kWE+PJdDglk96SsJ9QJKTaEBwOCGmJ1qJrFOMAmRYBmNRtR4CHyvtzdLrbf5 Awxeo9OMWvk0NVIIOcMBJruuGqXVzEmTVeoudXhQo6andW1L76UuxIxzNN2vUGyX00SH gYzQKpVI7NskYtgritHC+BX+VWYxGo0h64wmn21RYFRca+O+9l0hUHR/uB/dgWR4Aklr oiH6T48EVzoJq7LBtVqcxCT77NTXG3i+Ls3jZXZPXknaWFJ0L4YAaiTcNwbIxytGhxgw vRg82lMVUOajrooReQGzdcqy8wY6bwFFwxaJpjYZc4ctPs7MYjiuNEz5E1rIp1q1xRgX xDdg== X-Gm-Message-State: ALoCoQn5zueTWEeLrFzji9bq8ix8c+1zKeGJLcBofZ/aSn+peqWf7ZfWRCciQtVnEXp6FaTuOoCVaDX/34IypS2rplYoJ4fOzdeX/4nQ17ELPnP2PsMkVXggcvKSiO0jwZlzBzSiU29c7+nVGbBzAClJY42WXt5dcLq9JAO2Ay1ZYKAsB1DYKENrowg5YY4Qvqno0cU6oE9k X-Received: by 10.180.93.169 with SMTP id cv9mr16301047wib.3.1390334653469; Tue, 21 Jan 2014 12:04:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Tue, 21 Jan 2014 12:03:32 -0800 (PST) In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346DA@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk> <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> <52DE5F19.1060907@cisco.com> <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> <52DE680C.30704@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346D9@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F1240847E63346DA@EXMB01CMS.surrey.ac.uk> From: Edward Crabbe Date: Tue, 21 Jan 2014 12:03:32 -0800 Message-ID: To: l.wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=f46d043c7fc023b60b04f0808325 Cc: joel jaeggli , "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:04:18 -0000 --f46d043c7fc023b60b04f0808325 Content-Type: text/plain; charset=ISO-8859-1 Please see 6935,6936. You've conveniently ignored most if not all of the arguments Curtis has made in the past ~30 messages. I won't repeat them again here. If you really are so concerned about potential corruption scatter and header integrity issues beyond FEC/FCS for v6 protocols, perhaps you should propose a v6 checksum hop-by-hop extension header. :) On Tue, Jan 21, 2014 at 11:36 AM, wrote: > Oh, 'experience' is never a good play; after all, all experience is > ultimately anecdotal. But as an argument, it's being used by all sides. We > haven't seen missent traffic errors, because we're not looking for them. > > The question is, what does the end-to-end argument support? > > And surely the burden of proof falls on those making the change (this > draft); first, do no harm. The end-to-end principle and the precautionary > principle are strong arguments. > > Stone's papers, though technologically dated, support the underlying > principle and provide analysis - you want a modern setting, I'm quite happy > with proof of principle. Weird stuff happens; an end-to-end check can catch > it. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Edward Crabbe [edc@google.com] > Sent: 21 January 2014 19:19 > To: Wood L Dr (Electronic Eng) > Cc: stbryant@cisco.com; Eggert, Lars; joelja@bogus.com; mpls@ietf.org > Subject: Re: [mpls] Last Call: > (Encapsulating MPLS in UDP) to Proposed Standard > > I don't think the 'experience' card is such a good play here Lloyd. Many > people on this list, and certainly a few of the ones you've been directly > arguing with, have no small amount experience running *extremely* large, > geographically distributed networks. I've spent a bit of time running > some very large backbones and major content providers myself, and I have to > say, I'm finding most of your arguments here to be unconvincing at best. > > I do find it a bit ironic that you're asking for (difficult to gather, > vendor variable and generally poorly documented) data form Stewart, when > your own argument has yet to be substantiated via any form of quantitative > impact analysis, either empirically or theoretically in a modern setting. > I'd be interested in seeing empirical (back)scatter collection data > (similar to what Morley or Savage have done) to get some idea of impact > here. I strongly suspect that corruption scatter will be trivial, and > certainly completely overwhelmed in terms volume by typical, day to day > DDoS backscatter. Perhaps this may be an idea for your next research paper? > > With regard to the congestion-control-of-all-tunnel-protocols argument: I > find the argument to be specious. Curtis summed up the end-to-end version > of this argument pretty succinctly in an earlier email, to wit: > > If congestion aware or using a congestion aware transport, the top > level applications are still congestion aware. If congestion > ignorant, they are still congestion ignorant. If hostile, they are > still hostile. > > > On Tue, Jan 21, 2014 at 9:56 AM, l.wood@surrey.ac.uk>> wrote: > Stewart > > the IP header check is not the UDP pseudoheader check - and IPv6 has > neither. > > If a NAT gets a corrupted header, won't it open up new state and attempt > to translate for that header? Remember, this is UDP, not TCP - it's not on > an existing connection that must have already been opened by SYN/ACK, where > the NAT is more likely to reject it as unknown. > > 'NATs, which rewrite and can trash headers, demonstrate and validate the > integrity of the Internet' is not a good argument imo. > > I'd like to see some evidence for '"obscure" IP protocol numbers will get > dropped by default at NATs and firewalls.'. IP/GRE is relatively > state-free, nothing much to translate at transport there - it's not SCTP. > I've spent a couple of years running an ISP, and the 'oh, that protocol > won't go through your NAT' has not come up. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: 21 January 2014 12:29 > To: Eggert, Lars > Cc: Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com curtis@ipv6.occnc.com>; Joel Jaeggli; mpls@ietf.org > Subject: Re: [mpls] Last Call: > (Encapsulating MPLS in UDP) to Proposed Standard > > On 21/01/2014 12:07, Eggert, Lars wrote: > > Hi, > > > > On 2014-1-21, at 12:50, Stewart Bryant stbryant@cisco.com>> wrote: > >> In terms of congestion and misdelivery it is interesting looking > >> at the number of horses that are already bounding around > >> in the paddock outside the stable: > >> > >> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > there is a big difference between encapsulation in IP and encapsulation > in UDP. Everything encapsulated with "obscure" IP protocol numbers will get > dropped by default at NATs and firewalls, whereas UDO traffic happily > traverses them. The reach of UDP traffic is much broader. > > > > Lars > So we have established that it's not the load on the NATs and Firewalls > we are worried about. > > Seemingly from the above congestion is off the table as well. > > Now surely those same NATs and firewalls will be looking for an SA, DA, > Type, SP, DP match > and that is a lot of things that have to be right for a header > corruption misdelivery to get > through. > > - Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --f46d043c7fc023b60b04f0808325 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please see 6935,6936. =A0

You've co= nveniently ignored most if not all of the arguments Curtis has made in the = past ~30 messages. =A0I won't repeat them again here.=A0

=
If you really are so concerned about potential corruption scatter and = header integrity issues beyond FEC/FCS for v6 protocols, perhaps you should= propose a v6 checksum hop-by-hop extension header. =A0:)


On Tue, Jan 2= 1, 2014 at 11:36 AM, <l.wood@surrey.ac.uk> wrote:
Oh, 'experience' is never a good play; after all, all experience is= ultimately anecdotal. But as an argument, it's being used by all sides= . We haven't seen missent traffic errors, because we're not looking= for them.

The question is, what does the end-to-end argument support?

And surely the burden of proof falls on those making the change (this draft= ); first, do no harm. The end-to-end principle and the precautionary princi= ple are strong arguments.

Stone's papers, though technologically dated, support the underlying pr= inciple and provide analysis - you want a modern setting, I'm quite hap= py with proof of principle. Weird stuff happens; an end-to-end check can ca= tch it.

Lloyd Wood
http://about.me/llo= ydwood
________________________________________
From: Edward Crabbe [edc@google.com]
Sent: 21 January 2014 19:19
To: Wood L =A0Dr (Electronic Eng)
Cc: stbryant@cisco.= com; Eggert, Lars; joelja@bogus.com; = mpls@ietf.org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (= Encapsulating MPLS in UDP) to Proposed Standard

I don't think the 'experience' card is such a good p= lay here Lloyd. =A0Many people on this list, and certainly a few of the one= s you've been directly arguing with, have no small amount experience ru= nning *extremely* large, geographically distributed networks. =A0 I've = spent a bit of time running some very large backbones and major content pro= viders myself, and I have to say, I'm finding most of your arguments he= re to be unconvincing at best.

I do find it a bit ironic that you're asking for (difficult to gather, = vendor variable and generally poorly documented) data form Stewart, when yo= ur own argument has yet to be substantiated via any form of quantitative im= pact analysis, either empirically or theoretically in a modern setting. =A0= I'd be interested in seeing empirical (back)scatter collection data (si= milar to what Morley or Savage have done) to get some idea of impact here. = =A0I strongly suspect that corruption scatter will be trivial, and certainl= y completely overwhelmed in terms volume by typical, day to day DDoS backsc= atter. =A0Perhaps this may be an idea for your next research paper?

With regard to the congestion-control-of-all-tunnel-protocols argument: I f= ind the argument to be specious. =A0Curtis summed up the end-to-end version= of this argument pretty succinctly in an earlier email, to wit:

If congestion aware or using a congestion aware transport, the top
level applications are still congestion aware. =A0If congestion
ignorant, they are still congestion ignorant. =A0If hostile, they are
still hostile.


On Tue, Jan 21, 2014 at 9:56 AM, <l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>&g= t; wrote:
Stewart

the IP header check is not the UDP pseudoheader check - and IPv6 has neithe= r.

If a NAT gets a corrupted header, won't it open up new state and attemp= t to translate for that header? Remember, this is UDP, not TCP - it's n= ot on an existing connection that must have already been opened by SYN/ACK,= where the NAT is more likely to reject it as unknown.

'NATs, which rewrite and can trash headers, demonstrate and validate th= e integrity of the Internet' is not a good argument imo.

I'd like to see some evidence for '"obscure" IP protocol = numbers will get dropped by default at NATs and firewalls.'. IP/GRE is = relatively state-free, nothing much to translate at transport there - it= 9;s not SCTP. I've spent a couple of years running an ISP, and the '= ;oh, that protocol won't go through your NAT' has not come up.

Lloyd Wood
http://about.me/llo= ydwood
________________________________________
From: Stewart Bryant [stbryant@cisco.com<mailto:stbryant@cisco.com>]
Sent: 21 January 2014 12:29
To: Eggert, Lars
Cc: Wood L =A0Dr (Electronic Eng); curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com>;= Joel Jaeggli; mpls@ietf= .org<mailto:mpls@= ietf.org>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (= Encapsulating MPLS in UDP) to Proposed Standard

On 21/01/2014 12:07, Eggert, Lars wrote:
> Hi,
>
> On 2014-1-21, at 12:50, Stewart Bryant <stbryant@cisco.com<mailto:stbryant@cisco.com>> wrote:
>> In terms of congestion and misdelivery it is interesting looking >> at the number of horses that are already bounding around
>> in the paddock outside the stable:
>>
>> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example.
> there is a big difference between encapsulation in IP and encapsulatio= n in UDP. Everything encapsulated with "obscure" IP protocol numb= ers will get dropped by default at NATs and firewalls, whereas UDO traffic = happily traverses them. The reach of UDP traffic is much broader.
>
> Lars
So we have established that it's not the load on the NATs and Firewalls=
we are worried about.

Seemingly from the above congestion is off the table as well.

Now surely those same NATs and firewalls will be looking for an SA, DA,
Type, SP, DP match
and that is a lot of things that have to be right for a header
corruption misdelivery to get
through.

- Stewart


_______________________________________________
mpls mailing list
mpls@ietf.org&= lt;mailto:mpls@ietf.org<= /a>>
ht= tps://www.ietf.org/mailman/listinfo/mpls


--f46d043c7fc023b60b04f0808325-- From curtis@ipv6.occnc.com Tue Jan 21 12:14:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F761A014D for ; Tue, 21 Jan 2014 12:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 CFl8K9KZEPQn for ; Tue, 21 Jan 2014 12:14:25 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id BE5B01A0127 for ; Tue, 21 Jan 2014 12:14:24 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0LKEDXM065730; Tue, 21 Jan 2014 15:14:14 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> To: "Eggert, Lars" From: Curtis Villamizar In-reply-to: Your message of "Tue, 21 Jan 2014 12:07:35 +0000." <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> Date: Tue, 21 Jan 2014 15:14:13 -0500 Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:14:28 -0000 In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> "Eggert, Lars" writes: > Hi, > > On 2014-1-21, at 12:50, Stewart Bryant wrote: > > In terms of congestion and misdelivery it is interesting looking > > at the number of horses that are already bounding around > > in the paddock outside the stable: > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > there is a big difference between encapsulation in IP and > encapsulation in UDP. Everything encapsulated with "obscure" IP > protocol numbers will get dropped by default at NATs and firewalls, > whereas UDO traffic happily traverses them. The reach of UDP traffic > is much broader. > > Lars Stray UDP packets carrying MPLS getting to grandma's firewall is really stretching the argument but ... When encapsulating in UDP, the UDP checksum might be zero but the IP checksum can still be filled in so the IP destination is checked and grandma need not worry about these packets. But ... Grandma's firewall would block since there is no state established on the firewall with the opposite port pair pattern. But ... Even if it went through when the packet reached grandma's subnet the payload is junk bound to an unused port. Maybe it hits grandma's DNS server and is interpreted as a badly malformed DNS request. So grandma seems safe from these bad packets. Lack of UDP checksum should at worst mean that the destination gets a packet with a munged payload, pulls off the IP and UDP headers and continues to forward. At worst has the wrong MPLS label and gets blackholed in the provider network somewhere. If it ends up at the correct MPLS egress, if IP, the IP checksum is checked. If a TCP or UDP payload carried in that IP got munged the packet could end up at the destination with a bad TCP or UDP checksum and get dropped. Curtis From akatlas@gmail.com Tue Jan 21 12:20:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15001A0166; Tue, 21 Jan 2014 12:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiTZSpujKlzJ; Tue, 21 Jan 2014 12:20:02 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 134111A0125; Tue, 21 Jan 2014 12:20:01 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id ar20so5604565iec.6 for ; Tue, 21 Jan 2014 12:20:01 -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=Q9npFE35PfGotROmpBpR21Umf76VJaEmtFP5VBTEmzc=; b=ZuYGVDBL8IecI+uY33+AbSVGErHdrLkJgoQCkOqA/imun2MYPeB4m0SdNSxnPJCfID rS6k47J45wBoWsMsbyhbYxUp4UhLpF8taUHfrXToSAAihTlnJBNT9yqQ5RCVDjjBaHx/ +GqhdknSz+DaiMsFqY24gTcqndtLko/qpGvNz4A5Cws/YrgJPAmJlMg7qtMElp47YlrO jdvrGLjiT10EmHdol1Lr4vWK3Xqib6Nn5eS/eKL/mnIHCumUhv4pSGdFwiC3Z04KaYCd BLdb+K0Ew3Hjsvx/OuUyhP1bUKOnIxeRaK0cPXc25L5MT2YazR08NJVl/qwzIuh6nWAH bJDA== MIME-Version: 1.0 X-Received: by 10.50.79.198 with SMTP id l6mr19754960igx.23.1390335601836; Tue, 21 Jan 2014 12:20:01 -0800 (PST) Received: by 10.64.72.132 with HTTP; Tue, 21 Jan 2014 12:20:01 -0800 (PST) In-Reply-To: References: <201401171719.s0HHJqHY062965@maildrop2.v6ds.occnc.com> Date: Tue, 21 Jan 2014 15:20:01 -0500 Message-ID: From: Alia Atlas To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=089e013a1102aa89de04f080bbd2 Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:20:04 -0000 --089e013a1102aa89de04f080bbd2 Content-Type: text/plain; charset=ISO-8859-1 Apologies for top-posting, but what struck me as very useful that Lars said is: "There are always special deployment scenarios where these principles do not apply, and we typically explain in applicability statements when out specifications can only be safely used under certain conditions. I don't see any such statement in draft-ietf-mpls-in-udp, which to me means it's targeted at general Internet-wide use." Why don't we add an applicability statement? That seems easier than trying to define the appropriate congestion control mechanism which is highly likely to interact badly with the congestion control applied to the encapsulated traffic? Alia Alia On Tue, Jan 21, 2014 at 8:22 AM, Eggert, Lars wrote: > Hi, > > On 2014-1-17, at 18:19, Curtis Villamizar wrote: > > You have made your assertions about your desire to uphold the purity > > of any new UDP applications and adhere to the BCP you wrote. > > > > You appear to be very nearly alone in this argument and certainly no > > one that works with MPLS is siding with you. > > the reason we wrote the RFC when I was TSV AD was that we were seeing a > whole bunch of questionable uses of UDP over the eyars and we were having > the same arguments over and over. That's why we decided to write down the > practices we expect users of UDP to follow. This is yet another such > questionable use. > > (Also, I don't appreciate you turning this into a personal argument.) > > > In the end we can put anything we want in the RFC *but* IETF has never > > truly had the final word on what vendors and operators do in provider > > networks. > > Aka the "take my toys and go home" argument. Heard it many times. > > > In this case, regardless of what changes are made to the draft, > > implementations will offer at least the option for non-RFC behavior by > > using zero checksums and not using any congestion control. And > > providers will make use of it, perhaps exclusively. > > And there's nothing wrong with that - the BCP even says that one SHOULD > NOT use congestion control for some deployment cases. > > But for others, one SHOULD. For those, a mechanism needs to be available, > i.e., it needs to be specified and implemented. > > > The document might as well reflect reality, despite reality not > > conforming to your notions of architectural purity. > > I'm sorry, but we have certain architectural principles in the Internet > that we have IETF consensus on. At least since RFC2914, that includes the > need to have congestion control in place. > > There are always special deployment scenarios where these principles do > not apply, and we typically explain in applicability statements when out > specifications can only be safely used under certain conditions. I don't > see any such statement in draft-ietf-mpls-in-udp, which to me means it's > targeted at general Internet-wide use. > > > The best course of action is to put a SHOULD in regarding checksums > > and put a SHOULD in regarding congestion avoidance. Even the BCP does > > not go any further than to say a tunneling protocol SHOULD use > > congestion control and there were reasons that the word MUST was not > > acceptable in the BCP. > > The SHOULD for congestion control needs to actually describe a mechanism > that can be used when needed. It can't be a blanket "you SHOULD use > something but we don't tell you what it is"-statement. > > > If we are still arguing over two instances of SHOULD vs MUST we have > > wasted a lot of bandwidth on those two words. > > It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it needs to > be specified what is to be done. In the case of checksums, that's obvious > (calculate it and check it); in the case of congestion control, some actual > mechanism needs to be described (e.g., a circuit breaker). > > > IMHO The only remaining question is whether the document can go forward > > with the definition of congestion control for MPLS over UDP left out > > of scope and for another document if a need arises. > > In my opinion, it cannot. > > > If this is not acceptable to you (I doubt it is) please indicate what > > you would like to see in the document and since this is IETF last call > > where consensus matters and no one individual has veto power, we'll > > have to see if there is consensus behind your proposed changes. > > I would like the document to specify at the very least a circuit breaker > mechanism, that stops the tunneled traffic if severe packet loss is > detected along the path. > > And this isn't about an "individual veto". This is about a document that > is at the moment in violation of IETF consensus at least as far back as > RFC2914. > > Lars > --089e013a1102aa89de04f080bbd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Apologies for top-posting, but what struck me as very usef= ul that Lars said is:

"There are always special deployment scenari= os where these principles do not apply, and we typically explain in applica= bility statements when out specifications can only be safely used under cer= tain conditions. I don't see any such statement in draft-ietf-mpls-in-u= dp, which to me means it's targeted at general Internet-wide use."=

Why= don't we add an applicability statement? =A0That seems easier than try= ing to define the appropriate congestion control mechanism which is highly = likely to interact badly with the congestion control applied to the encapsu= lated traffic?

Ali= a

Alia


On Tue, Jan 21, 2014 at 8:22 AM, Eggert, Lars <lars@netapp.com<= /a>> wrote:
Hi,

On 2014-1-17, at 18:19, Curtis Villamizar <curtis@ipv6.occnc.com> wrote:
> You have made your assertions about your desire to uphold the purity > of any new UDP applications and adhere to the BCP you wrote.
>
> You appear to be very nearly alone in this argument and certainly no > one that works with MPLS is siding with you.

the reason we wrote the RFC when I was TSV AD was that we were seeing a who= le bunch of questionable uses of UDP over the eyars and we were having the = same arguments over and over. That's why we decided to write down the p= ractices we expect users of UDP to follow. This is yet another such questio= nable use.

(Also, I don't appreciate you turning this into a personal argument.)
> In the end we can put anything we want in the RFC *but* IETF has never=
> truly had the final word on what vendors and operators do in provider<= br> > networks.

Aka the "take my toys and go home" argument. Heard it many times.=

> In this case, regardless of what changes are made to the draft,
> implementations will offer at least the option for non-RFC behavior by=
> using zero checksums and not using any congestion control. =A0And
> providers will make use of it, perhaps exclusively.

And there's nothing wrong with that - the BCP even says that one SHOULD= NOT use congestion control for some deployment cases.

But for others, one SHOULD. For those, a mechanism needs to be available, i= .e., it needs to be specified and implemented.

> The document might as well reflect reality, despite reality not
> conforming to your notions of architectural purity.

I'm sorry, but we have certain architectural principles in the Internet= that we have IETF consensus on. At least since RFC2914, that includes the = need to have congestion control in place.

There are always special deployment scenarios where these principles do not= apply, and we typically explain in applicability statements when out speci= fications can only be safely used under certain conditions. I don't see= any such statement in draft-ietf-mpls-in-udp, which to me means it's t= argeted at general Internet-wide use.

> The best course of action is to put a SHOULD in regarding checksums > and put a SHOULD in regarding congestion avoidance. =A0Even the BCP do= es
> not go any further than to say a tunneling protocol SHOULD use
> congestion control and there were reasons that the word MUST was not > acceptable in the BCP.

The SHOULD for congestion control needs to actually describe a mechanism th= at can be used when needed. It can't be a blanket "you SHOULD use = something but we don't tell you what it is"-statement.

> If we are still arguing over two instances of SHOULD vs MUST we have > wasted a lot of bandwidth on those two words.

It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it ne= eds to be specified what is to be done. In the case of checksums, that'= s obvious (calculate it and check it); in the case of congestion control, s= ome actual mechanism needs to be described (e.g., a circuit breaker).

> IMHO The only remaining question is whether the document can go forwar= d
> with the definition of congestion control for MPLS over UDP left out > of scope and for another document if a need arises.

In my opinion, it cannot.

> If this is not acceptable to you (I doubt it is) please indicate what<= br> > you would like to see in the document and since this is IETF last call=
> where consensus matters and no one individual has veto power, we'l= l
> have to see if there is consensus behind your proposed changes.

I would like the document to specify at the very least a circuit breaker me= chanism, that stops the tunneled traffic if severe packet loss is detected = along the path.

And this isn't about an "individual veto". This is about a do= cument that is at the moment in violation of IETF consensus at least as far= back as RFC2914.

Lars

--089e013a1102aa89de04f080bbd2-- From adrian@olddog.co.uk Tue Jan 21 12:49:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C678C1A02E8 for ; Tue, 21 Jan 2014 12:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.346 X-Spam-Level: * X-Spam-Status: No, score=1.346 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 tO_0QnUuY2fA for ; Tue, 21 Jan 2014 12:49:06 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 89A6E1A0343 for ; Tue, 21 Jan 2014 12:49:05 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0LKn4WN000972; Tue, 21 Jan 2014 20:49:04 GMT Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0LKn16A000949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jan 2014 20:49:02 GMT From: "Adrian Farrel" To: "'Loa Andersson'" , Date: Tue, 21 Jan 2014 20:49:03 -0000 Message-ID: <0bc301cf16ea$3981cd00$ac856700$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8W6jHMZ8uZf2LMS56KIUdobofaHQ== Content-Language: en-gb X-TM-AS-MML: No Cc: mpls-ads@tools.ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject: [mpls] AD review : working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:49:10 -0000 Hi, Congratulations on sailing a very difficult course between technical and political. You have produced a readable and coherent document. I have conducted my usual AD review of this document early (i.e., during working group last call) on request of the working group chairs. The purpose of my review is to catch and clean up any issues that might otherwise be found during IETF last call and IESG evaluation. Thus, the intention is to produce a higher quality document and ensure smoother passage through those later stages. As should be obvious, by reviewing the document before it has seen working group last call and been updated I may have found more issues and concerns than I would have done had I reviewed it later. Nevertheless, I find the document to be basically sound. There are quite a lot of comments below, but they are almost exclusively editorial in nature. The editorial comments fall into three categories: - pure nits (should be entirely uncontentious) - issues of clarity and readability (hopefully these are also easy to accept, but please check that my "cleaning up" of your text has preserved the meaning you intended) - issues of spin/politics (sometimes saying the same thing in slightly different words can make everyone happy) I think I found only two technical issues - in Section 9.1.1 and 9.1.3.3. In all cases I have tried to suggest alternative wording so that you don't have to guess what I mean. But please (please, please) do not feel that I am insisting on any of these changes or on my precise words: I am just trying to polish and move this document along; everything is open for discussion. One last point: if some enthusiastic native speaker was to review and edit the final revision (perhaps in return for beer or an acknowledgement) they would be doing us all a great favor. I have not pointed out every minor issue of language in my review. Thanks for the work. Adrian === The Abstract and the Introduction say: Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This leaves the question: where is the protocol including priority logic and state machine defined for the PSC mode? I hope the answer is "in RFC 6378, in which case you can easily add a node such as: The PSC protocol behavior for the PSC mode is as defined in RFC 6378. --- The last paragraph of the Introduction reads This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. For an existing implementation of RFC 6378, it is recommended to be updated with the bug-fixes in [I-D.ietf-mpls-psc-updates] and the capability advertisement in this document. I suggest replacing this with the text below. There are two reasons for my suggested changes: 1. It looks very odd for this document to recommend using changes in another document. The result of such a statement is likely to be a requirement that you bundle the two documents together. I think that [I-D.ietf-mpls-psc-updates] can stand on its own. 2. While you can recommend that the installed base is updated, you cannot force it to happen. It is, therefore, useful to draw attention to the important backward compatibility text you have in Section 9.3. So my suggested text is: This document updates RFC 6378 by adding a capability advertisement mechanism. It is recommended that existing implementations of RFC 6378 should be updated to support this capability, however the issue of backward compatibility with existing implementations is described in Section 9.3. --- Section 4 In this document, the priorities of FS and SF-P are swapped and the priority of Clear SF (SFc) is raised. In addition to the priority modification, this document introduces the use of Freeze command in Appendix C. The reasons for these changes are explained in the following sub-sections from technical and network operational aspects. The issue I have with this text is that a swap has to be relative to something. So we should make it clear what is in 6378 and then describe what this document does... [RFC6378] defines the priority of FS to be higher than that of SF-P. That document also defines the priority of Clear SF (SFc) to be low. This document the defines the Priority Modification capability whereby the priorities of FS and SF-P are swapped and the priority of Clear SF (SFc) is raised. In addition, this capability introduces the use of Freeze command as described in Appendix C. The reasons for these changes are explained in the following sub-sections from technical and network operational aspects. --- Section 4.1 No technical change, just ease of reading. OLD Setting the priority of any input that is supposed to be signaled to the other end to be higher than that of SF-P can result in unpredictable protection switching state, when the protection path has failed and consequently the PSC communication stopped. NEW When the protection path fails PSC communication may stop as a result. In this case, if any input that is supposed to be signaled to the other end has a higher priority that SF-P then this can result in unpredictable protection switching state. END --- Section 4.1 According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to operate an MPLS-TP network without using a control plane. This means that external switch commands, e.g., FS, can be transferred to the remote Label Edge Router (LER) only by using the PSC communication channel and should not rely on the presence of a control plane. This paragraph has several issues. 1. It is not true! Not using a control plane leaves the option of PSC as you say, and also leaves the option of the management plane. Indeed, the PSC communication channel is probably a special case of the in- band OAM channel. 2. This statement does not appear to have anything to do with swapping the priorities of FS and SF-P. I suggest that if you can show how this statement is related to the swap of priorities you should add it. In that case you should also say... This means that external switch commands, e.g., FS, can be transferred to the remote Label Edge Router (LER) only by using the management plane or the in-band OAM channel and should not rely on the presence of a control plane. The use of the OAM channel as used by PSC messages is considered more appropriate for coherence with other PSC messages. If, on the other hand, you can't show how this statement is relevant for the swapping of the priorities, I suggest removing the paragraph. --- Section 4.1 I think this one is mainly political :-) OLD As the priority of SF-P has been higher than FS in other transport networks, such as SDH, OTN and Ethernet transport networks, for network operators it is important that the MPLS-TP protection switching preserves the network operation behavior to which network operators have become accustomed. NEW In other transport networks (such as SDH, OTN, and Ethernet transport networks) the priority of SF-P is been higher than FS. It is therefore important to offer network operators the option of having the same behavior in their MPLS-TP network so that they can have the same operational protection switching behavior to which they have become accustomed. END --- Section 4.3 s/broken, the Freeze command,/broken. The Freeze command,/ --- Section 4.4 As you have already established earlier in this document, the modifications to 6378 are the addition of the capabilities advertisement. So I think the language used in this section is too strong. I suggest... OLD 4.4. Modifications to RFC 6378 The list of local requests in order of priority SHALL be modified as follows: (from higher to lower) o Clear Signal Fail o Signal Fail on Protection path o Forced Switch o Signal Fail on Working path The change of the PSC Control logic including the state machine due to this priority modification is incorporated in the PSC Control logic description in Section 10 and Section 11 when all the capabilities are enabled. NEW 4.4. Procedures in Support of Capability 1 When this capability is in use the list of local requests in order of priority SHALL be as follows: (from highest to lowest) o Clear Signal Fail o Signal Fail on Protection path o Forced Switch o Signal Fail on Working path This requires different PSC control logic (including the state machine) compared to that shown in [RFC6378]. Sections 10 and 11 show the PSC control logic and state machine when all of the capabilities in APS mode are enabled. END --- Section 5 Similar changes to those proposed for Sections 4.1 and 4.4. OLD However, PSC protocol defined in RFC 6378 [RFC6378] supports this operation only when recovering from a defect condition, but does not operate as non-revertive when an operator's switch-over command such as FS or Manual Switch (MS) is cleared. To be aligned with legacy transport network behavior and RFC 4427, a node should go into the Do-not-Revert (DNR) state not only when a failure condition on the working path is cleared but also when an operator command requesting switch-over is cleared. The change of the PSC Control logic including the state machine due to the modification of non-revertive operation is incorporated into the PSC Control logic description in Section 10 and Section 11 when all the capabilities are enabled. NEW However, the PSC protocol defined in RFC 6378 [RFC6378] supports this operation only when recovering from a defect condition: it does not support the non-revertive function when an operator's switch-over command, such as FS or Manual Switch (MS), is cleared. To be aligned with the behaviour in other transport networks and to be consistent with RFC 4427, a node should go into the Do-not-Revert (DNR) state not only when a failure condition on the working path is cleared, but also when an operator command that requested switch-over is cleared. This requires different PSC control logic (including the state machine) compared to that shown in [RFC6378]. Sections 10 and 11 show the PSC control logic and state machine when all of the capabilities in APS mode are enabled. END --- Section 6.1 OLD Changing the non-revertive operation NEW Changing the non-revertive operation as described in Section 5 END --- Section 6.1 OLD Manual Switch-over for recovery LSP/span command, defined in RFC 4427 [RFC4427] and also defined in RFC 5654 [RFC5654], Requirement 83, as one of the mandatory external commands, should be used for this purpose, but is not included in RFC 6378. Note that the "Manual Switch-over for recovery LSP/span" command is the same as MS-W command. NEW Manual Switch-over for recovery LSP/span command is defined in RFC 4427 [RFC4427]. Requirement 83 in RFC 5654 [RFC5654] states that the external commands defined in RFC 4427 must be supported. No such command is supported in PSC as defined in RFC 6378 so there is a need to provide support for that feature. Note that the "Manual Switch- over for recovery LSP/span" command is the same as the MS-W command. END --- In Section 6.2, when you say "replaced" it implies that this is making a specific update to 6378. But I don't think you need to do that (and possibly that wasn't the intention. I think it is enough to define the terms you use in this document. So I suggest... OLD The term "Manual Switch" and its acronym "MS" used in RFC 6378 are replaced respectively by "Manual Switch to Protection path" and "MS-P" by this document to avoid confusion with "Manual Switch to Working path" and its acronym "MS-W". Also, the term "Protecting administrative state" used in RFC 6378 is replaced by "Switching administrative state" by this document to include the case where traffic is switched back to the working path by administrative MS-W command. NEW RFC 6378 uses the term "Manual Switch" and its acronym "MS". This document uses the term "Manual Switch to Protection path" and "MS-P" to have the same meaning, but avoid confusion with "Manual Switch to Working path" and its acronym "MS-W". Similarly, RFC 6378 uses the term "Protecting administrative state", and this document uses "Switching administrative state" to cover the same concept but also include the case where traffic is switched back to the working path by administrative MS-W command. END In keeping with this, it might be better to change the section title to 6.2. Terminology to support MS-W --- Section 6.3 There is a slight discrepancy in the text because it says that the MS-P and MS-W commands have the same priority, but also gives an example of when they don't have the same priority. I think all the relevant material is present, so it is just a matter of re-ordering it.... OLD The MS-P and MS-W commands SHALL have the same priority. If one of these commands is already issued and accepted, then the other command that is issued afterwards SHALL be ignored. If two LERs are requesting opposite operations simultaneously, i.e. one LER is sending MS-P while the other LER is sending MS-W, the MS-W SHALL be considered to have a higher priority than MS-P, and MS-P SHALL be ignored and cancelled. NEW If one of the MS-P and MS-W commands is received and processed after the other, the two commands SHALL have the same priority such that if one of the commands is already issued and accepted, the command that is issued afterwards SHALL be ignored. However, if two LERs request opposite operations simultaneously (i.e., one LER sends MS-P and the other sends MS-W), the MS-W SHALL be considered to have a higher priority than MS-P, and MS-P SHALL NOT be accepted and SHALL be cancelled. END --- Section 6.4 Just as 4.1, 4.4, and 5... OLD The change of the PSC Control logic including the state machine due to the support of MS-W command is incorporated into the PSC Control logic description in Section 10 and Section 11 when all the capabilities are enabled NEW Support or this function requires changes to the PSC control logic (including the state machine) compared to that shown in [RFC6378]. Sections 10 and 11 show the PSC control logic and state machine when all of the capabilities in APS mode are enabled. END --- Section 7.1 The PSC protocol associated with SD is covered in this document, and the specifics for the method of identifying SD is out of the scope of the protection protocol similar to the facts that how SF is detect and how MS and FS commands are initiated in a management system and signaled to protection switching are out of its scope. s/and the specifics/but the specifics/ It is OK to include the "similar to..." but it is not necessary to give this reasoning. --- Section 7.2 Just like Section 6.2 the word "replaced" may be misinterpreted. So I suggest naming the section... 7.2. Terminology to support SD ... and replacing OLD Instead of SFc, Clear Signal Fail or Degrade (SFDc) is used to indicate the clearance of either a degraded condition or a failure condition. NEW In this document the term Clear Signal Fail or Degrade (SFDc) is used to indicate the clearance of either a degraded condition or a failure condition. END --- Section 7.3 Again, just a small political change... OLD In order to maintain the network operation behavior to which transport network operators have become accustomed, the priorities of SD-P and SD-W are defined to be equal as in other transport networks, such as SDH, OTN and Ethernet transport networks. NEW In order to make the behavior of MPLS-TP networks consistent with that of other transport networks (such as SDH, OTN and Ethernet transport networks), the priorities of SD-P and SD-W are defined to be equal. END --- In Section 7.4, for clarity, I think you should intend and bullet the two paragraphs beginning When MS-W and MS-P... and When SD-W and SD-P... --- And, as now is becoming familiar, at the end of 7.4 OLD The change of the PSC Control logic including the state machine due to the support of protection against SD is incorporated into the PSC Control logic description in Section 10 and Section 11 when all the capabilities are enabled. NEW The addition of support for protection against SD requires different PSC control logic (including the state machine) compared to that shown in [RFC6378]. Sections 10 and 11 show the PSC control logic and state machine when all of the capabilities in APS mode are enabled. END --- Section 8 is unclear in the race logic. You have... When Exercise commands are input at both ends, an EXER, instead of RR, SHALL be transmitted from both ends. I think that this means that EXER shall be taken as a valid response to EXER and that if an LER that has issued an EXER and has not received an RR then, if it receives an EXER it does not need to (SHOULD NOT) send RR. We could capture this as... OLD When Exercise commands are input at both ends, an EXER, instead of RR, SHALL be transmitted from both ends. NEW If Exercise commands are input at both ends, then a race condition may arrise. This is resolved as follows: o If an LER has issued EXER and receives EXER before receiving RR, it o MUST treat the received EXER as it would an RR. o SHOULD NOT respond with RR. END --- Section 8 The following PSC Requests SHALL be added to PSC Request field to support Exercise: We don't need to use RFC 2119 language here. You can just say... The following PSC Requests are added to the PSC Request field to support the Exercise command (see also Section 14.1): --- Section 8 The priority of Exercise SHALL be inserted between the priorities of WTR Expires and No Request. For the avoidance of doubt it is nice to actually give the ordering. And since we end up with Exercise not being immediately adjacent to No Request, I suggest this is best handled by a forward reference to Section 10.2. The relative priority of Exercise is shown in the table in Section 10.2. --- Section 9.1.1 We do not design protocols to make them resilient against bugs in implementations of the protocol. This is because any tick you come up with will, itself, be vulnerable to a bug in the implementation. Thus, when you say... PSC sends messages in response to external events and in periodic retransmission of current status. It may be expensive to send and to parse an Capabilities TLV attached to a packet intended to trigger a protection switch or other real-time behavior. However, if a node does not periodically send its Capabilities TLV, the receiving node cannot discriminate a deliberate omission of the Capabilities TLV for performance reasons from an accidental omission due to an implementation issue. To guard against this, a node MUST include its Capabilities TLV in every PSC message that it sends. ...you are neglecting to consider that each and very omission of a capability might be due to an implementation issue. So requiring inclusion in every PSC message does not resolve this. However, you *do* still need to include the Capabilities TLV in every PSC message (if the implementation supports the Capabilities TLV) if and only if, an LER is allowed to change the capabilities it supports during the lifetime of an LSP. The reason for this is that the absence of the Capabilities TLV is valid for backward compatibility reasons: therefore there is no way to distinguish "I have stopped supporting all of the capabilities" from "I have left out the Capabilities TLV because nothing has changed." (...but see my comment on 9.1.3.2 wrt the final paragraph of 9.3). So, you must decide: can an LER change the capabilities it supports? If yes, then you make *that* the reason for requiring the TLV to be present in every message. If no, then the TLV does not need to be present in each message, but you do need to make sure the message that was carrying it got delivered. It looks to me, from 9.1.2 that you are set on requiring retransmission and continual checking of Capabilities even though it would be impossible to achieve a synchronised change (that is, if one end were to change its capabilities this would automatically result in an error conditions). So it really seems to me that this is unnecessary processing. --- Section 9.1.2 This comment only applies if you don't make any change as a result of my comment on the previous section. I think you should advise an implementation on whether it should compare the Capabilities TLV as described in this section before or after acting on the received PSC message. That is (for example), should a protection switch be triggered before or after the Capabilities have been checked? --- Section 9.1.3.2 I think the final paragraph of Section 9.3 is very relevant here. You should either copy the text here or you should provide a forward pointer to Section 9.3. --- Section 9.1.3.3 Several things are not clear in the description of the error handling: - if a mismatch (9.1.3.2) is received, should the timer be stopped? - if there is a timeout (9.1.3.1) and then a PSC message is received, should the capabilities be compared? - if a mismatch (9.1.3.2) is received and then a PSC message is received, should the capabilities be compared? - how should alerts to be the operator be handled in the event of continued mismatches or timeouts? - what actions are available to an operator to resolve capabilities mismatches? --- Section 9.2.1 OLD A node can send a Capabilities TLV of 0x0 NEW A node can send a Capabilities TLV with Flags value set to 0x0 END --- Similarly in 9.2.3 OLD Capabilities TLV of 0x0 NEW Capabilities TLV with Flags value set to 0x0 END --- Section 10.1 You really scared me! The values of "Request" field in PSC protocol message, which is shown in Figure 2 of RFC 6378 [RFC6378], are redefined as follows: Fortunately you are not redefining the Request types from RFC 6378. You are just defining two new ones. Phew! So you can replace the whole of Section 10.1 with... NEW This document defines two new values for the "Request" field in the PSC protocol message that is shown in Figure 2 of RFC 6378 [RFC6378] as follows: (3) Exercise (2) Reverse Request See also Section 14.1 of this document. END --- Either fill in or delete Section 15. --- I think that [I-D.ietf-mpls-psc-updates] can be moved from normative to informative reference. This doesn't decrease its value, but I don't think that *this* document requires [I-D.ietf-mpls-psc-updates]. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 20 January 2014 02:28 > To: mpls@ietf.org > Cc: ; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp- > psc-itu@tools.ietf.org > Subject: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 > > Working Group, > > This is to start a two week working group last call on > draft-ietf-mpls-tp-psc-itu. From curtis@ipv6.occnc.com Tue Jan 21 12:58:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B321A0358; Tue, 21 Jan 2014 12:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RP_MATCHES_RCVD=-0.535, 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 MdACCtiEuEiR; Tue, 21 Jan 2014 12:58:53 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 871EE1A02DC; Tue, 21 Jan 2014 12:58:40 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0LKwcu2066223; Tue, 21 Jan 2014 15:58:39 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401212058.s0LKwcu2066223@maildrop2.v6ds.occnc.com> To: "Eggert, Lars" From: Curtis Villamizar In-reply-to: Your message of "Tue, 21 Jan 2014 13:22:50 +0000." Date: Tue, 21 Jan 2014 15:58:38 -0500 Cc: Joel Jaeggli , "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:58:55 -0000 Lars, The IETF consensus in RFC5405 was to put a SHOULD in regarding use of congestion control in tunneling protocols. RFC2119 states: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. We have discussed the reasons why congestion control is in general a good thing. We have also discussed why there may be valid reasons to not include congestion control in MPLS over UDP. The question is not whether there is already IETF consensus on congestion control in UDP in general. There is consensus and that consensus was to use the word "SHOULD". The question we now face is whether MPLS in UDP needs to up the prior consensus to a MUST or can keep it as SHOULD. I see one or maybe two people vigorously arguing to upgrade this to a MUST and otherwise consensus to keep this as SHOULD. Further I see no objection except the same one or maybe two people to making the congestion control the topic of a later work if a need for it arises. Consensus does not require unanimous agreeement. If we are trying to gauge consensus, maybe both you and I should sit back and let other people weigh in. Curtis In message "Eggert, Lars" writes: > > Hi, > > On 2014-1-17, at 18:19, Curtis Villamizar wrote: > > You have made your assertions about your desire to uphold the purity > > of any new UDP applications and adhere to the BCP you wrote. > >=20 > > You appear to be very nearly alone in this argument and certainly no > > one that works with MPLS is siding with you. > > the reason we wrote the RFC when I was TSV AD was that we were seeing a = > whole bunch of questionable uses of UDP over the eyars and we were = > having the same arguments over and over. That's why we decided to write = > down the practices we expect users of UDP to follow. This is yet another = > such questionable use. > > (Also, I don't appreciate you turning this into a personal argument.) Nothing personal intended. The important point is the sentence "You appear to be very nearly alone in this argument and certainly no one that works with MPLS is siding with you." was intended to point out that there is no consensus behind your argument regardless of how vigorously you make that argument. > > In the end we can put anything we want in the RFC *but* IETF has never > > truly had the final word on what vendors and operators do in provider > > networks. > > Aka the "take my toys and go home" argument. Heard it many times. It has been successful many times in the past. It turns into the "its deployed so get over it" argument after a few years. > > In this case, regardless of what changes are made to the draft, > > implementations will offer at least the option for non-RFC behavior by > > using zero checksums and not using any congestion control. And > > providers will make use of it, perhaps exclusively. > > And there's nothing wrong with that - the BCP even says that one SHOULD = > NOT use congestion control for some deployment cases. > > But for others, one SHOULD. For those, a mechanism needs to be = > available, i.e., it needs to be specified and implemented. > > > The document might as well reflect reality, despite reality not > > conforming to your notions of architectural purity. > > I'm sorry, but we have certain architectural principles in the Internet = > that we have IETF consensus on. At least since RFC2914, that includes = > the need to have congestion control in place. > > There are always special deployment scenarios where these principles do = > not apply, and we typically explain in applicability statements when out = > specifications can only be safely used under certain conditions. I don't = > see any such statement in draft-ietf-mpls-in-udp, which to me means it's = > targeted at general Internet-wide use. > > > The best course of action is to put a SHOULD in regarding checksums > > and put a SHOULD in regarding congestion avoidance. Even the BCP does > > not go any further than to say a tunneling protocol SHOULD use > > congestion control and there were reasons that the word MUST was not > > acceptable in the BCP. > > The SHOULD for congestion control needs to actually describe a mechanism = > that can be used when needed. It can't be a blanket "you SHOULD use = > something but we don't tell you what it is"-statement. > > > If we are still arguing over two instances of SHOULD vs MUST we have > > wasted a lot of bandwidth on those two words. > > It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it needs = > to be specified what is to be done. In the case of checksums, that's = > obvious (calculate it and check it); in the case of congestion control, = > some actual mechanism needs to be described (e.g., a circuit breaker). > > > IMHO The only remaining question is whether the document can go = > forward > > with the definition of congestion control for MPLS over UDP left out > > of scope and for another document if a need arises. > > In my opinion, it cannot. > > > If this is not acceptable to you (I doubt it is) please indicate what > > you would like to see in the document and since this is IETF last call > > where consensus matters and no one individual has veto power, we'll > > have to see if there is consensus behind your proposed changes. > > I would like the document to specify at the very least a circuit breaker = > mechanism, that stops the tunneled traffic if severe packet loss is = > detected along the path. > > And this isn't about an "individual veto". This is about a document that = > is at the moment in violation of IETF consensus at least as far back as = > RFC2914. > > Lars From l.wood@surrey.ac.uk Tue Jan 21 13:16:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B126F1A0169 for ; Tue, 21 Jan 2014 13:16:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 DDSSRGLTym2W for ; Tue, 21 Jan 2014 13:16:51 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4681A0125 for ; Tue, 21 Jan 2014 13:16:50 -0800 (PST) Received: from [195.245.231.67:9601] by server-10.bemta-5.messagelabs.com id 1D/ED-01405-1C3EED25; Tue, 21 Jan 2014 21:16:49 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-13.tower-82.messagelabs.com!1390339005!36510989!15 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31054 invoked from network); 21 Jan 2014 21:16:49 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-13.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jan 2014 21:16:49 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Tue, 21 Jan 2014 21:15:28 +0000 From: To: Date: Tue, 21 Jan 2014 21:11:59 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8W59UyyVVsp9FER8uHgsmcEGA8iQABZazk Message-ID: <290E20B455C66743BE178C5C84F1240847E63346DD@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk> <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> <52DE5F19.1060907@cisco.com> <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> <52DE680C.30704@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346D9@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F1240847E63346DA@EXMB01CMS.surrey.ac.uk>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:16:54 -0000 Yes, RFC6936 section 3 cites these concerns. I've cited it previously a num= ber of times in this discussion, perhaps you've just ignored those messages= ? RFC6935 ignores the concerns raised by RFC 6936 because, hey, tunnel perfo= rmance. And RFC6936, while emphasising considering the effect on the protocol using= zero cUP hecksums, does not emphasise considering the effect of those chec= ksums on other applications. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Edward Crabbe [edc@google.com] Sent: 21 January 2014 20:03 To: Wood L Dr (Electronic Eng) Cc: stbryant@cisco.com; Eggert, Lars; joel jaeggli; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Please see 6935,6936. You've conveniently ignored most if not all of the arguments Curtis has mad= e in the past ~30 messages. I won't repeat them again here. If you really are so concerned about potential corruption scatter and heade= r integrity issues beyond FEC/FCS for v6 protocols, perhaps you should prop= ose a v6 checksum hop-by-hop extension header. :) On Tue, Jan 21, 2014 at 11:36 AM, > wrote: Oh, 'experience' is never a good play; after all, all experience is ultimat= ely anecdotal. But as an argument, it's being used by all sides. We haven't= seen missent traffic errors, because we're not looking for them. The question is, what does the end-to-end argument support? And surely the burden of proof falls on those making the change (this draft= ); first, do no harm. The end-to-end principle and the precautionary princi= ple are strong arguments. Stone's papers, though technologically dated, support the underlying princi= ple and provide analysis - you want a modern setting, I'm quite happy with = proof of principle. Weird stuff happens; an end-to-end check can catch it. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Edward Crabbe [edc@google.com] Sent: 21 January 2014 19:19 To: Wood L Dr (Electronic Eng) Cc: stbryant@cisco.com; Eggert, Lars; joelja@bog= us.com; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard I don't think the 'experience' card is such a good play here Lloyd. Many p= eople on this list, and certainly a few of the ones you've been directly ar= guing with, have no small amount experience running *extremely* large, geog= raphically distributed networks. I've spent a bit of time running some ve= ry large backbones and major content providers myself, and I have to say, I= 'm finding most of your arguments here to be unconvincing at best. I do find it a bit ironic that you're asking for (difficult to gather, vend= or variable and generally poorly documented) data form Stewart, when your o= wn argument has yet to be substantiated via any form of quantitative impact= analysis, either empirically or theoretically in a modern setting. I'd be= interested in seeing empirical (back)scatter collection data (similar to w= hat Morley or Savage have done) to get some idea of impact here. I strongl= y suspect that corruption scatter will be trivial, and certainly completely= overwhelmed in terms volume by typical, day to day DDoS backscatter. Perh= aps this may be an idea for your next research paper? With regard to the congestion-control-of-all-tunnel-protocols argument: I f= ind the argument to be specious. Curtis summed up the end-to-end version o= f this argument pretty succinctly in an earlier email, to wit: If congestion aware or using a congestion aware transport, the top level applications are still congestion aware. If congestion ignorant, they are still congestion ignorant. If hostile, they are still hostile. On Tue, Jan 21, 2014 at 9:56 AM, >> wrote: Stewart the IP header check is not the UDP pseudoheader check - and IPv6 has neithe= r. If a NAT gets a corrupted header, won't it open up new state and attempt to= translate for that header? Remember, this is UDP, not TCP - it's not on an= existing connection that must have already been opened by SYN/ACK, where t= he NAT is more likely to reject it as unknown. 'NATs, which rewrite and can trash headers, demonstrate and validate the in= tegrity of the Internet' is not a good argument imo. I'd like to see some evidence for '"obscure" IP protocol numbers will get d= ropped by default at NATs and firewalls.'. IP/GRE is relatively state-free,= nothing much to translate at transport there - it's not SCTP. I've spent a= couple of years running an ISP, and the 'oh, that protocol won't go throug= h your NAT' has not come up. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@cisco.com>] Sent: 21 January 2014 12:29 To: Eggert, Lars Cc: Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com>; Joel= Jaeggli; mpls@ietf.org> Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard On 21/01/2014 12:07, Eggert, Lars wrote: > Hi, > > On 2014-1-21, at 12:50, Stewart Bryant >> wrote: >> In terms of congestion and misdelivery it is interesting looking >> at the number of horses that are already bounding around >> in the paddock outside the stable: >> >> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > there is a big difference between encapsulation in IP and encapsulation i= n UDP. Everything encapsulated with "obscure" IP protocol numbers will get = dropped by default at NATs and firewalls, whereas UDO traffic happily trave= rses them. The reach of UDP traffic is much broader. > > Lars So we have established that it's not the load on the NATs and Firewalls we are worried about. Seemingly from the above congestion is off the table as well. Now surely those same NATs and firewalls will be looking for an SA, DA, Type, SP, DP match and that is a lot of things that have to be right for a header corruption misdelivery to get through. - Stewart _______________________________________________ mpls mailing list mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls From l.wood@surrey.ac.uk Tue Jan 21 13:28:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E061A0263 for ; Tue, 21 Jan 2014 13:28:36 -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, 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 l3yDljq1kp7N for ; Tue, 21 Jan 2014 13:28:32 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9601A0250 for ; Tue, 21 Jan 2014 13:28:32 -0800 (PST) Received: from [85.158.137.99:63562] by server-5.bemta-3.messagelabs.com id AA/AF-25188-F76EED25; Tue, 21 Jan 2014 21:28:31 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-7.tower-217.messagelabs.com!1390339710!17322058!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28649 invoked from network); 21 Jan 2014 21:28:30 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-7.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jan 2014 21:28:30 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Tue, 21 Jan 2014 21:28:30 +0000 From: To: , Date: Tue, 21 Jan 2014 21:28:30 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8W5wNrNVCRkxLlSdiKUO4rBj1TjwABvlMs Message-ID: <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> References: Your message of "Tue, 21 Jan 2014 12:07:35 +0000." <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com>, <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> In-Reply-To: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:28:36 -0000 > When encapsulating in UDP, the UDP checksum might be zero but the IP > checksum can still be filled in so the IP destination is checked IPv6 doesn't have an IP header checksum. So with an error in the header the packet can go anywhere. > Lack of UDP checksum should at worst mean that the destination gets a > packet with a munged payload, pulls off the IP and UDP headers and > continues to forward ... or a munged header, and forwards to a different application on a differ= ent port. See RFC 6936 section 3, which goes through the scenarios - but plays light on the side-effects. My beef is with: A protocol or application that uses the zero UDP checksum method must ensure that the lack of checksum does not affect the protocol operation. This includes being robust to receiving an unintended packet from another protocol or context following corruption of a destination or source address and/or port value. It also includes considering the need for additional implicit protection mechanisms required when using the payload of a UDP packet received with a zero checksum. Lack of a UDP checksum in one protocol can affect the operation of other protocols minding their own business, until they receive and try to handle a corrupted packet from the first protocol because port or address is corrupted. There are a lot of applications that presume that the data they are given is error-free, and they presume that rogue data is not injected i= nto their conversation. I mean, if you're going to use a zero UDP checksum, and your application messes up and gives itself corrupt data, fine. More fool you. By analogy as a risk, it's like speeding while talking on a cellphone and crashing int= o a tree. But if your lack of checksum means you affect other applications who have to now protect themselves against your data, you're effectively now crashin= g into and harming other people. They weren't in armoured cars to protect against this? They had no right to be on the road! Zero UDP checksums are hit-and-run accidents waiting to happen. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 21 January 2014 20:14 To: Eggert, Lars Cc: Stewart Bryant; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com; Joe= l Jaeggli; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> "Eggert, Lars" writes: > Hi, > > On 2014-1-21, at 12:50, Stewart Bryant wrote: > > In terms of congestion and misdelivery it is interesting looking > > at the number of horses that are already bounding around > > in the paddock outside the stable: > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > there is a big difference between encapsulation in IP and > encapsulation in UDP. Everything encapsulated with "obscure" IP > protocol numbers will get dropped by default at NATs and firewalls, > whereas UDO traffic happily traverses them. The reach of UDP traffic > is much broader. > > Lars Stray UDP packets carrying MPLS getting to grandma's firewall is really stretching the argument but ... When encapsulating in UDP, the UDP checksum might be zero but the IP checksum can still be filled in so the IP destination is checked and grandma need not worry about these packets. But ... Grandma's firewall would block since there is no state established on the firewall with the opposite port pair pattern. But ... Even if it went through when the packet reached grandma's subnet the payload is junk bound to an unused port. Maybe it hits grandma's DNS server and is interpreted as a badly malformed DNS request. So grandma seems safe from these bad packets. Lack of UDP checksum should at worst mean that the destination gets a packet with a munged payload, pulls off the IP and UDP headers and continues to forward. At worst has the wrong MPLS label and gets blackholed in the provider network somewhere. If it ends up at the correct MPLS egress, if IP, the IP checksum is checked. If a TCP or UDP payload carried in that IP got munged the packet could end up at the destination with a bad TCP or UDP checksum and get dropped. Curtis= From adrian@olddog.co.uk Tue Jan 21 13:52:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918811A03D8 for ; Tue, 21 Jan 2014 13:52:30 -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, 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 uDFje3fhNseU for ; Tue, 21 Jan 2014 13:52:28 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 997201A03CD for ; Tue, 21 Jan 2014 13:52:28 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0LLqQg0005520; Tue, 21 Jan 2014 21:52:26 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0LLq9Y6005460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jan 2014 21:52:25 GMT From: "Adrian Farrel" To: References: <20140121214750.13233.68712.idtracker@ietfa.amsl.com> In-Reply-To: <20140121214750.13233.68712.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2014 21:52:11 -0000 Message-ID: <0c0e01cf16f3$14035360$3c09fa20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJrSyNW413zlmJ2jncG01mERPobdZlXTuqA Content-Language: en-gb Cc: stephen.farrell@cs.tcd.ie Subject: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:52:30 -0000 Hi, This document still remains a focus for discussion and is not (yet?) a = concrete proposal for implementation. Our purpose is to establish what = could be done and to have the discussion about whether there could be = value. You can, of course, diff out the changes in this revision. The main = change is to add some discussion of the nonce (nonce-sense) and to add = text to the applicability discussion in section 5. As before, Stephen and I remain at your disposal for entertaining and = enlightening conversation on this topic. Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 21 January 2014 21:48 > To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell > Subject: New Version Notification for = draft-farrelll-mpls-opportunistic-encrypt- > 01.txt >=20 >=20 > A new version of I-D, draft-farrelll-mpls-opportunistic-encrypt-01.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-farrelll-mpls-opportunistic-encrypt > Revision: 01 > Title: Opportunistic Encryption in MPLS Networks > Document date: 2014-01-21 > Group: Individual Submission > Pages: 25 > URL: = http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic- > encrypt-01.txt > Status: = https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic- > encrypt/ > Htmlized: = http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt- > 01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-farrelll-mpls-opportunistic- > encrypt-01 >=20 > Abstract: > This document describes a way to apply opportunistic encryption > between adjacent nodes on an MPLS Label Switched Path (LSP) or > between end points of an LSP. It explains how keys may be = exchanged > to enable the encryption, and indicates how key identifiers are > exchanged in encrypted MPLS packets. Finally, this document > describes the applicability of opportunistic encryption in MPLS > networks with an indication of the level of improved security as = well > as the continued vulnerabilities. >=20 > This document does not describe security for MPLS control plane > protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From jari.arkko@piuha.net Tue Jan 21 14:11:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195B51A01B9; Tue, 21 Jan 2014 14:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 ayaUbIKZwi4h; Tue, 21 Jan 2014 14:11:26 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 503401A01BB; Tue, 21 Jan 2014 14:11:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C5C052CEB6; Wed, 22 Jan 2014 00:11:24 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVubkAdSVrQT; Wed, 22 Jan 2014 00:11:22 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id B84162CC48; Wed, 22 Jan 2014 00:11:22 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jari Arkko In-Reply-To: <52D82BAA.1010007@nostrum.com> Date: Wed, 22 Jan 2014 00:11:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9F8D043A-DDA7-4B0C-BFCB-71935EA99DD6@piuha.net> References: <52D82BAA.1010007@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1510) Cc: mpls@ietf.org, General Area Review Team , draft-ietf-mpls-moving-iana-registries@tools.ietf.org Subject: Re: [mpls] [Gen-art] Gen-Art LC review of draft-ietf-mpls-moving-iana-registries X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 22:11:28 -0000 Thanks for your review, Robert. These reviews are important for helping = me to determine whether a document needs further review or if there are = issues that I'd need to pay special attention to. I have balloted no-obj = for this document on the upcoming IESG telechat. Jari On Jan 16, 2014, at 8:57 PM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-mpls-moving-iana-registries > Reviewer: Robert Sparks > Review Date: 16-Jan-2014 > IETF LC End Date: 17-Jan-2014 > IESG Telechat date: 23-Jan-2014 >=20 > Summary: This document is ready for publication as Proposed Standard >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From curtis@ipv6.occnc.com Tue Jan 21 16:25:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967351A01BC for ; Tue, 21 Jan 2014 16:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 wPFp4kqQLuPn for ; Tue, 21 Jan 2014 16:25:06 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 82DFE1A0125 for ; Tue, 21 Jan 2014 16:25:06 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0M0OwGW068768; Tue, 21 Jan 2014 19:24:58 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401220024.s0M0OwGW068768@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Tue, 21 Jan 2014 21:28:30 +0000." <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> Date: Tue, 21 Jan 2014 19:24:57 -0500 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 00:25:09 -0000 Lloyd, Since MPLS over UDP is intended to be used within a provider, how about if we recommend the following: If no MPLS over UDP is intended to go outside a service provider, then packet filters should be added to block traffic with the UDP port number for MPLS over UDP to prevent misconfiguation or packet error to cause MPLS over UDP packets to escape, If either the IP destination address or the UDP destination port were corrupted, then the packet would not leave. The former because the intended destination within the provider would get the packet. The latter because with the UDP port intact the provider's filter would block it. This would also prevent ordinary users from making use of MPLS over UDP, which with its absense of congestion control is causing some objections. Providers would already be blocking traffic coming into their net with this UDP port, particularly to their own infrastructure. The filters might cover only their own addresses allowing users to make use of MPLS over UDP, or could block it entirely. This is in line with Alia's suggestion that we define a profile of intended use being for service providers internal use. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > checksum can still be filled in so the IP destination is checked > > IPv6 doesn't have an IP header checksum. So with an error in the > header the packet can go anywhere. > > > > Lack of UDP checksum should at worst mean that the destination gets a > > packet with a munged payload, pulls off the IP and UDP headers and > > continues to forward > > ... or a munged header, and forwards to a different application on a different port. > > See RFC 6936 section 3, which goes through the scenarios - but plays light > on the side-effects. My beef is with: > > A protocol or application that uses the zero UDP checksum method must > ensure that the lack of checksum does not affect the protocol > operation. This includes being robust to receiving an unintended > packet from another protocol or context following corruption of a > destination or source address and/or port value. It also includes > considering the need for additional implicit protection mechanisms > required when using the payload of a UDP packet received with a zero > checksum. > > Lack of a UDP checksum in one protocol can affect the operation of other > protocols minding their own business, until they receive and try to handle > a corrupted packet from the first protocol because port or address is > corrupted. There are a lot of applications that presume that the data they > are given is error-free, and they presume that rogue data is not injected into > their conversation. > > I mean, if you're going to use a zero UDP checksum, and your application > messes up and gives itself corrupt data, fine. More fool you. By analogy > as a risk, it's like speeding while talking on a cellphone and crashing into a tree. > But if your lack of checksum means you affect other applications who have > to now protect themselves against your data, you're effectively now crashing > into and harming other people. They weren't in armoured cars to protect > against this? They had no right to be on the road! > > Zero UDP checksums are hit-and-run accidents waiting to happen. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 21 January 2014 20:14 > To: Eggert, Lars > Cc: Stewart Bryant; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> > "Eggert, Lars" writes: > > > Hi, > > > > On 2014-1-21, at 12:50, Stewart Bryant wrote: > > > In terms of congestion and misdelivery it is interesting looking > > > at the number of horses that are already bounding around > > > in the paddock outside the stable: > > > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > > > there is a big difference between encapsulation in IP and > > encapsulation in UDP. Everything encapsulated with "obscure" IP > > protocol numbers will get dropped by default at NATs and firewalls, > > whereas UDO traffic happily traverses them. The reach of UDP traffic > > is much broader. > > > > Lars > > > Stray UDP packets carrying MPLS getting to grandma's firewall is > really stretching the argument but ... > > When encapsulating in UDP, the UDP checksum might be zero but the IP > checksum can still be filled in so the IP destination is checked and > grandma need not worry about these packets. But ... > > Grandma's firewall would block since there is no state established on > the firewall with the opposite port pair pattern. But ... > > Even if it went through when the packet reached grandma's subnet the > payload is junk bound to an unused port. Maybe it hits grandma's DNS > server and is interpreted as a badly malformed DNS request. > > So grandma seems safe from these bad packets. > > Lack of UDP checksum should at worst mean that the destination gets a > packet with a munged payload, pulls off the IP and UDP headers and > continues to forward. At worst has the wrong MPLS label and gets > blackholed in the provider network somewhere. If it ends up at the > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > UDP payload carried in that IP got munged the packet could end up at > the destination with a bad TCP or UDP checksum and get dropped. > > Curtis From xuxiaohu@huawei.com Tue Jan 21 16:54:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBED31A01BC for ; Tue, 21 Jan 2014 16:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 YjIrqxmIZxAm for ; Tue, 21 Jan 2014 16:54:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 17C7D1A0125 for ; Tue, 21 Jan 2014 16:54:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAF59662; Wed, 22 Jan 2014 00:54:21 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 00:53:19 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 00:54:19 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 08:54:16 +0800 From: Xuxiaohu To: Alia Atlas , "Eggert, Lars" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPFqwJQAEpMFZHYEa9xrEKIf1dSJqPGN6AgADOQ+A= Date: Wed, 22 Jan 2014 00:54:15 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246B7D@NKGEML512-MBS.china.huawei.com> References: <201401171719.s0HHJqHY062965@maildrop2.v6ds.occnc.com> 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.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246B7DNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 00:54:25 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246B7DNKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxpYSwNCg0KWW91ciBzdWdnZXN0aW9uIHNvdW5kcyByZWFzb25hYmxlIHRvIG1lLg0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0Kt6K8/sjLOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIEFsaWEgQXRsYXMNCreiy83KsbzkOiAyMDE0xOox1MIyMsjVIDQ6MjAN CsrVvP7IyzogRWdnZXJ0LCBMYXJzDQqzrcvNOiBtcGxzQGlldGYub3JnOyBJRVRGIGRpc2N1c3Np b24gbGlzdA0K1vfM4jogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4t dWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5k YXJkDQoNCkFwb2xvZ2llcyBmb3IgdG9wLXBvc3RpbmcsIGJ1dCB3aGF0IHN0cnVjayBtZSBhcyB2 ZXJ5IHVzZWZ1bCB0aGF0IExhcnMgc2FpZCBpczoNCg0KIlRoZXJlIGFyZSBhbHdheXMgc3BlY2lh bCBkZXBsb3ltZW50IHNjZW5hcmlvcyB3aGVyZSB0aGVzZSBwcmluY2lwbGVzIGRvIG5vdCBhcHBs eSwgYW5kIHdlIHR5cGljYWxseSBleHBsYWluIGluIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50cyB3 aGVuIG91dCBzcGVjaWZpY2F0aW9ucyBjYW4gb25seSBiZSBzYWZlbHkgdXNlZCB1bmRlciBjZXJ0 YWluIGNvbmRpdGlvbnMuIEkgZG9uJ3Qgc2VlIGFueSBzdWNoIHN0YXRlbWVudCBpbiBkcmFmdC1p ZXRmLW1wbHMtaW4tdWRwLCB3aGljaCB0byBtZSBtZWFucyBpdCdzIHRhcmdldGVkIGF0IGdlbmVy YWwgSW50ZXJuZXQtd2lkZSB1c2UuIg0KDQpXaHkgZG9uJ3Qgd2UgYWRkIGFuIGFwcGxpY2FiaWxp dHkgc3RhdGVtZW50PyAgVGhhdCBzZWVtcyBlYXNpZXIgdGhhbiB0cnlpbmcgdG8gZGVmaW5lIHRo ZSBhcHByb3ByaWF0ZSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIHdoaWNoIGlzIGhpZ2hs eSBsaWtlbHkgdG8gaW50ZXJhY3QgYmFkbHkgd2l0aCB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGFw cGxpZWQgdG8gdGhlIGVuY2Fwc3VsYXRlZCB0cmFmZmljPw0KDQpBbGlhDQoNCkFsaWENCg0KT24g VHVlLCBKYW4gMjEsIDIwMTQgYXQgODoyMiBBTSwgRWdnZXJ0LCBMYXJzIDxsYXJzQG5ldGFwcC5j b208bWFpbHRvOmxhcnNAbmV0YXBwLmNvbT4+IHdyb3RlOg0KSGksDQoNCk9uIDIwMTQtMS0xNywg YXQgMTg6MTksIEN1cnRpcyBWaWxsYW1pemFyIDxjdXJ0aXNAaXB2Ni5vY2NuYy5jb208bWFpbHRv OmN1cnRpc0BpcHY2Lm9jY25jLmNvbT4+IHdyb3RlOg0KPiBZb3UgaGF2ZSBtYWRlIHlvdXIgYXNz ZXJ0aW9ucyBhYm91dCB5b3VyIGRlc2lyZSB0byB1cGhvbGQgdGhlIHB1cml0eQ0KPiBvZiBhbnkg bmV3IFVEUCBhcHBsaWNhdGlvbnMgYW5kIGFkaGVyZSB0byB0aGUgQkNQIHlvdSB3cm90ZS4NCj4N Cj4gWW91IGFwcGVhciB0byBiZSB2ZXJ5IG5lYXJseSBhbG9uZSBpbiB0aGlzIGFyZ3VtZW50IGFu ZCBjZXJ0YWlubHkgbm8NCj4gb25lIHRoYXQgd29ya3Mgd2l0aCBNUExTIGlzIHNpZGluZyB3aXRo IHlvdS4NCg0KdGhlIHJlYXNvbiB3ZSB3cm90ZSB0aGUgUkZDIHdoZW4gSSB3YXMgVFNWIEFEIHdh cyB0aGF0IHdlIHdlcmUgc2VlaW5nIGEgd2hvbGUgYnVuY2ggb2YgcXVlc3Rpb25hYmxlIHVzZXMg b2YgVURQIG92ZXIgdGhlIGV5YXJzIGFuZCB3ZSB3ZXJlIGhhdmluZyB0aGUgc2FtZSBhcmd1bWVu dHMgb3ZlciBhbmQgb3Zlci4gVGhhdCdzIHdoeSB3ZSBkZWNpZGVkIHRvIHdyaXRlIGRvd24gdGhl IHByYWN0aWNlcyB3ZSBleHBlY3QgdXNlcnMgb2YgVURQIHRvIGZvbGxvdy4gVGhpcyBpcyB5ZXQg YW5vdGhlciBzdWNoIHF1ZXN0aW9uYWJsZSB1c2UuDQoNCihBbHNvLCBJIGRvbid0IGFwcHJlY2lh dGUgeW91IHR1cm5pbmcgdGhpcyBpbnRvIGEgcGVyc29uYWwgYXJndW1lbnQuKQ0KDQo+IEluIHRo ZSBlbmQgd2UgY2FuIHB1dCBhbnl0aGluZyB3ZSB3YW50IGluIHRoZSBSRkMgKmJ1dCogSUVURiBo YXMgbmV2ZXINCj4gdHJ1bHkgaGFkIHRoZSBmaW5hbCB3b3JkIG9uIHdoYXQgdmVuZG9ycyBhbmQg b3BlcmF0b3JzIGRvIGluIHByb3ZpZGVyDQo+IG5ldHdvcmtzLg0KDQpBa2EgdGhlICJ0YWtlIG15 IHRveXMgYW5kIGdvIGhvbWUiIGFyZ3VtZW50LiBIZWFyZCBpdCBtYW55IHRpbWVzLg0KDQo+IElu IHRoaXMgY2FzZSwgcmVnYXJkbGVzcyBvZiB3aGF0IGNoYW5nZXMgYXJlIG1hZGUgdG8gdGhlIGRy YWZ0LA0KPiBpbXBsZW1lbnRhdGlvbnMgd2lsbCBvZmZlciBhdCBsZWFzdCB0aGUgb3B0aW9uIGZv ciBub24tUkZDIGJlaGF2aW9yIGJ5DQo+IHVzaW5nIHplcm8gY2hlY2tzdW1zIGFuZCBub3QgdXNp bmcgYW55IGNvbmdlc3Rpb24gY29udHJvbC4gIEFuZA0KPiBwcm92aWRlcnMgd2lsbCBtYWtlIHVz ZSBvZiBpdCwgcGVyaGFwcyBleGNsdXNpdmVseS4NCg0KQW5kIHRoZXJlJ3Mgbm90aGluZyB3cm9u ZyB3aXRoIHRoYXQgLSB0aGUgQkNQIGV2ZW4gc2F5cyB0aGF0IG9uZSBTSE9VTEQgTk9UIHVzZSBj b25nZXN0aW9uIGNvbnRyb2wgZm9yIHNvbWUgZGVwbG95bWVudCBjYXNlcy4NCg0KQnV0IGZvciBv dGhlcnMsIG9uZSBTSE9VTEQuIEZvciB0aG9zZSwgYSBtZWNoYW5pc20gbmVlZHMgdG8gYmUgYXZh aWxhYmxlLCBpLmUuLCBpdCBuZWVkcyB0byBiZSBzcGVjaWZpZWQgYW5kIGltcGxlbWVudGVkLg0K DQo+IFRoZSBkb2N1bWVudCBtaWdodCBhcyB3ZWxsIHJlZmxlY3QgcmVhbGl0eSwgZGVzcGl0ZSBy ZWFsaXR5IG5vdA0KPiBjb25mb3JtaW5nIHRvIHlvdXIgbm90aW9ucyBvZiBhcmNoaXRlY3R1cmFs IHB1cml0eS4NCg0KSSdtIHNvcnJ5LCBidXQgd2UgaGF2ZSBjZXJ0YWluIGFyY2hpdGVjdHVyYWwg cHJpbmNpcGxlcyBpbiB0aGUgSW50ZXJuZXQgdGhhdCB3ZSBoYXZlIElFVEYgY29uc2Vuc3VzIG9u LiBBdCBsZWFzdCBzaW5jZSBSRkMyOTE0LCB0aGF0IGluY2x1ZGVzIHRoZSBuZWVkIHRvIGhhdmUg Y29uZ2VzdGlvbiBjb250cm9sIGluIHBsYWNlLg0KDQpUaGVyZSBhcmUgYWx3YXlzIHNwZWNpYWwg ZGVwbG95bWVudCBzY2VuYXJpb3Mgd2hlcmUgdGhlc2UgcHJpbmNpcGxlcyBkbyBub3QgYXBwbHks IGFuZCB3ZSB0eXBpY2FsbHkgZXhwbGFpbiBpbiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudHMgd2hl biBvdXQgc3BlY2lmaWNhdGlvbnMgY2FuIG9ubHkgYmUgc2FmZWx5IHVzZWQgdW5kZXIgY2VydGFp biBjb25kaXRpb25zLiBJIGRvbid0IHNlZSBhbnkgc3VjaCBzdGF0ZW1lbnQgaW4gZHJhZnQtaWV0 Zi1tcGxzLWluLXVkcCwgd2hpY2ggdG8gbWUgbWVhbnMgaXQncyB0YXJnZXRlZCBhdCBnZW5lcmFs IEludGVybmV0LXdpZGUgdXNlLg0KDQo+IFRoZSBiZXN0IGNvdXJzZSBvZiBhY3Rpb24gaXMgdG8g cHV0IGEgU0hPVUxEIGluIHJlZ2FyZGluZyBjaGVja3N1bXMNCj4gYW5kIHB1dCBhIFNIT1VMRCBp biByZWdhcmRpbmcgY29uZ2VzdGlvbiBhdm9pZGFuY2UuICBFdmVuIHRoZSBCQ1AgZG9lcw0KPiBu b3QgZ28gYW55IGZ1cnRoZXIgdGhhbiB0byBzYXkgYSB0dW5uZWxpbmcgcHJvdG9jb2wgU0hPVUxE IHVzZQ0KPiBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIHRoZXJlIHdlcmUgcmVhc29ucyB0aGF0IHRo ZSB3b3JkIE1VU1Qgd2FzIG5vdA0KPiBhY2NlcHRhYmxlIGluIHRoZSBCQ1AuDQoNClRoZSBTSE9V TEQgZm9yIGNvbmdlc3Rpb24gY29udHJvbCBuZWVkcyB0byBhY3R1YWxseSBkZXNjcmliZSBhIG1l Y2hhbmlzbSB0aGF0IGNhbiBiZSB1c2VkIHdoZW4gbmVlZGVkLiBJdCBjYW4ndCBiZSBhIGJsYW5r ZXQgInlvdSBTSE9VTEQgdXNlIHNvbWV0aGluZyBidXQgd2UgZG9uJ3QgdGVsbCB5b3Ugd2hhdCBp dCBpcyItc3RhdGVtZW50Lg0KDQo+IElmIHdlIGFyZSBzdGlsbCBhcmd1aW5nIG92ZXIgdHdvIGlu c3RhbmNlcyBvZiBTSE9VTEQgdnMgTVVTVCB3ZSBoYXZlDQo+IHdhc3RlZCBhIGxvdCBvZiBiYW5k d2lkdGggb24gdGhvc2UgdHdvIHdvcmRzLg0KDQpJdCdzIG5vdCBTSE9VTEQgdnMuIE1VU1QuIEl0 J3MgdHdvIFNIT1VMRHMsIGJ1dCBpbiBib3RoIGNhc2VzIGl0IG5lZWRzIHRvIGJlIHNwZWNpZmll ZCB3aGF0IGlzIHRvIGJlIGRvbmUuIEluIHRoZSBjYXNlIG9mIGNoZWNrc3VtcywgdGhhdCdzIG9i dmlvdXMgKGNhbGN1bGF0ZSBpdCBhbmQgY2hlY2sgaXQpOyBpbiB0aGUgY2FzZSBvZiBjb25nZXN0 aW9uIGNvbnRyb2wsIHNvbWUgYWN0dWFsIG1lY2hhbmlzbSBuZWVkcyB0byBiZSBkZXNjcmliZWQg KGUuZy4sIGEgY2lyY3VpdCBicmVha2VyKS4NCg0KPiBJTUhPIFRoZSBvbmx5IHJlbWFpbmluZyBx dWVzdGlvbiBpcyB3aGV0aGVyIHRoZSBkb2N1bWVudCBjYW4gZ28gZm9yd2FyZA0KPiB3aXRoIHRo ZSBkZWZpbml0aW9uIG9mIGNvbmdlc3Rpb24gY29udHJvbCBmb3IgTVBMUyBvdmVyIFVEUCBsZWZ0 IG91dA0KPiBvZiBzY29wZSBhbmQgZm9yIGFub3RoZXIgZG9jdW1lbnQgaWYgYSBuZWVkIGFyaXNl cy4NCg0KSW4gbXkgb3BpbmlvbiwgaXQgY2Fubm90Lg0KDQo+IElmIHRoaXMgaXMgbm90IGFjY2Vw dGFibGUgdG8geW91IChJIGRvdWJ0IGl0IGlzKSBwbGVhc2UgaW5kaWNhdGUgd2hhdA0KPiB5b3Ug d291bGQgbGlrZSB0byBzZWUgaW4gdGhlIGRvY3VtZW50IGFuZCBzaW5jZSB0aGlzIGlzIElFVEYg bGFzdCBjYWxsDQo+IHdoZXJlIGNvbnNlbnN1cyBtYXR0ZXJzIGFuZCBubyBvbmUgaW5kaXZpZHVh bCBoYXMgdmV0byBwb3dlciwgd2UnbGwNCj4gaGF2ZSB0byBzZWUgaWYgdGhlcmUgaXMgY29uc2Vu c3VzIGJlaGluZCB5b3VyIHByb3Bvc2VkIGNoYW5nZXMuDQoNCkkgd291bGQgbGlrZSB0aGUgZG9j dW1lbnQgdG8gc3BlY2lmeSBhdCB0aGUgdmVyeSBsZWFzdCBhIGNpcmN1aXQgYnJlYWtlciBtZWNo YW5pc20sIHRoYXQgc3RvcHMgdGhlIHR1bm5lbGVkIHRyYWZmaWMgaWYgc2V2ZXJlIHBhY2tldCBs b3NzIGlzIGRldGVjdGVkIGFsb25nIHRoZSBwYXRoLg0KDQpBbmQgdGhpcyBpc24ndCBhYm91dCBh biAiaW5kaXZpZHVhbCB2ZXRvIi4gVGhpcyBpcyBhYm91dCBhIGRvY3VtZW50IHRoYXQgaXMgYXQg dGhlIG1vbWVudCBpbiB2aW9sYXRpb24gb2YgSUVURiBjb25zZW5zdXMgYXQgbGVhc3QgYXMgZmFy IGJhY2sgYXMgUkZDMjkxNC4NCg0KTGFycw0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246B7DNKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Alia,

 = ;

Your sugge= stion sounds reasonable to me.

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: mpls [m= ailto:mpls-bounces@ietf.org] =B4=FA= =B1=ED Alia Atlas
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C222=C8=D5 4:20
=CA=D5=BC=FE=C8=CB: Eggert, Lars
=B3=AD=CB=CD: mpls@ietf.org; IETF discussion list
=D6=F7=CC=E2: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulatin= g MPLS in UDP) to Proposed Standard

 

Apologies for top-posting, but = what struck me as very useful that Lars said is:

 

"There are always special deployment scenarios where these principle= s do not apply, and we typically explain in applicability statements when out specifications can only be safely used under certain conditions. = I don't see any such statement in draft-ietf-mpls-in-udp, which to me means= it's targeted at general Internet-wide use."

 

Why don't we add an applic= ability statement?  That seems easier than trying to define the approp= riate congestion control mechanism which is highly likely to interact badly with the congestion control applied to the encapsulated traffic?

 

Alia

 

Alia

=  

On Tue, Jan 21, 2014 at 8:22 AM= , Eggert, Lars <lar= s@netapp.com> wrote:

Hi,

On 2014-1-17, at 18:19, Curtis Villamizar <curtis@ipv6.occnc.com> wrote:
> You have made your assertions about your desire to uphold the purity > of any new UDP applications and adhere to the BCP you wrote.
>
> You appear to be very nearly alone in this argument and certainly no > one that works with MPLS is siding with you.

the reason we wrote the RFC when I was TSV AD was that we were seeing a who= le bunch of questionable uses of UDP over the eyars and we were having the = same arguments over and over. That's why we decided to write down the pract= ices we expect users of UDP to follow. This is yet another such questionable use.

(Also, I don't appreciate you turning this into a personal argument.)

> In the end we can put anything we want in the RFC *but* IETF has never=
> truly had the final word on what vendors and operators do in provider<= br> > networks.

Aka the "take my toys and go home" argument. Heard it many times.=

> In this case, regardless of what changes are made to the draft,
> implementations will offer at least the option for non-RFC behavior by=
> using zero checksums and not using any congestion control.  And > providers will make use of it, perhaps exclusively.

And there's nothing wrong with that - the BCP even says that one SHOULD NOT= use congestion control for some deployment cases.

But for others, one SHOULD. For those, a mechanism needs to be available, i= .e., it needs to be specified and implemented.

> The document might as well reflect reality, despite reality not
> conforming to your notions of architectural purity.

I'm sorry, but we have certain architectural principles in the Internet tha= t we have IETF consensus on. At least since RFC2914, that includes the need= to have congestion control in place.

There are always special deployment scenarios where these principles do not= apply, and we typically explain in applicability statements when out speci= fications can only be safely used under certain conditions. I don't see any= such statement in draft-ietf-mpls-in-udp, which to me means it's targeted at general Internet-wide use.

> The best course of action is to put a SHOULD in regarding checksums > and put a SHOULD in regarding congestion avoidance.  Even the BCP= does
> not go any further than to say a tunneling protocol SHOULD use
> congestion control and there were reasons that the word MUST was not > acceptable in the BCP.

The SHOULD for congestion control needs to actually describe a mechanism th= at can be used when needed. It can't be a blanket "you SHOULD use some= thing but we don't tell you what it is"-statement.

> If we are still arguing over two instances of SHOULD vs MUST we have > wasted a lot of bandwidth on those two words.

It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it needs to b= e specified what is to be done. In the case of checksums, that's obvious (c= alculate it and check it); in the case of congestion control, some actual m= echanism needs to be described (e.g., a circuit breaker).

> IMHO The only remaining question is whether the document can go forwar= d
> with the definition of congestion control for MPLS over UDP left out > of scope and for another document if a need arises.

In my opinion, it cannot.

> If this is not acceptable to you (I doubt it is) please indicate what<= br> > you would like to see in the document and since this is IETF last call=
> where consensus matters and no one individual has veto power, we'll > have to see if there is consensus behind your proposed changes.

I would like the document to specify at the very least a circuit breaker me= chanism, that stops the tunneled traffic if severe packet loss is detected = along the path.

And this isn't about an "individual veto". This is about a docume= nt that is at the moment in violation of IETF consensus at least as far bac= k as RFC2914.

Lars

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246B7DNKGEML512MBSchi_-- From l.wood@surrey.ac.uk Tue Jan 21 17:04:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1771A024F for ; Tue, 21 Jan 2014 17:04:33 -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, 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 LqbeCk1WCj-M for ; Tue, 21 Jan 2014 17:04:30 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) by ietfa.amsl.com (Postfix) with ESMTP id 363A71A0229 for ; Tue, 21 Jan 2014 17:04:29 -0800 (PST) Received: from [85.158.137.99:57949] by server-16.bemta-3.messagelabs.com id C6/9C-26128-C191FD25; Wed, 22 Jan 2014 01:04:28 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-217.messagelabs.com!1390352668!19000025!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32338 invoked from network); 22 Jan 2014 01:04:28 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-12.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 22 Jan 2014 01:04:28 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 22 Jan 2014 01:04:27 +0000 From: To: Date: Wed, 22 Jan 2014 01:04:27 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8XCVTW9xrgAbzRRfKawk9InrrOtAAA8K+k Message-ID: <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk> References: Your message of "Tue, 21 Jan 2014 21:28:30 +0000." <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk>, <201401220024.s0M0OwGW068768@maildrop2.v6ds.occnc.com> In-Reply-To: <201401220024.s0M0OwGW068768@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:04:33 -0000 Curtis, the 'intended for use within a service provider' and not for mass use sound= s reasonable, and scoping in this way may also alleviate some congestion control concerns= . But outgoing packet filtering, when you're trying to catch a corrupted port= , and the port is not what you think it is? That's going to do a partial job of corrupted addresses in IPv6 at best. (v4 has header checksums, ports in v4 and v6 are open to corruption sans UDP pseudo-header check.) Not convinced by providers already blocking inbound traffic on a new port -= =20 particularly given discussion of handling entropy with varying ports in another thread. So, I don't think filtering is a useful solution here to the problem posed by zero UDP checksums. (An actual UDP checksum solves it, of course.) regards Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 22 January 2014 00:24 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com; lars@netapp.com; stbryant@cisco.com; joelja@bogu= s.com; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Lloyd, Since MPLS over UDP is intended to be used within a provider, how about if we recommend the following: If no MPLS over UDP is intended to go outside a service provider, then packet filters should be added to block traffic with the UDP port number for MPLS over UDP to prevent misconfiguation or packet error to cause MPLS over UDP packets to escape, If either the IP destination address or the UDP destination port were corrupted, then the packet would not leave. The former because the intended destination within the provider would get the packet. The latter because with the UDP port intact the provider's filter would block it. This would also prevent ordinary users from making use of MPLS over UDP, which with its absense of congestion control is causing some objections. Providers would already be blocking traffic coming into their net with this UDP port, particularly to their own infrastructure. The filters might cover only their own addresses allowing users to make use of MPLS over UDP, or could block it entirely. This is in line with Alia's suggestion that we define a profile of intended use being for service providers internal use. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > checksum can still be filled in so the IP destination is checked > > IPv6 doesn't have an IP header checksum. So with an error in the > header the packet can go anywhere. > > > > Lack of UDP checksum should at worst mean that the destination gets a > > packet with a munged payload, pulls off the IP and UDP headers and > > continues to forward > > ... or a munged header, and forwards to a different application on a diff= erent port. > > See RFC 6936 section 3, which goes through the scenarios - but plays lig= ht > on the side-effects. My beef is with: > > A protocol or application that uses the zero UDP checksum method must > ensure that the lack of checksum does not affect the protocol > operation. This includes being robust to receiving an unintended > packet from another protocol or context following corruption of a > destination or source address and/or port value. It also includes > considering the need for additional implicit protection mechanisms > required when using the payload of a UDP packet received with a zero > checksum. > > Lack of a UDP checksum in one protocol can affect the operation of other > protocols minding their own business, until they receive and try to handl= e > a corrupted packet from the first protocol because port or address is > corrupted. There are a lot of applications that presume that the data the= y > are given is error-free, and they presume that rogue data is not injected= into > their conversation. > > I mean, if you're going to use a zero UDP checksum, and your application > messes up and gives itself corrupt data, fine. More fool you. By analogy > as a risk, it's like speeding while talking on a cellphone and crashing i= nto a tree. > But if your lack of checksum means you affect other applications who have > to now protect themselves against your data, you're effectively now crash= ing > into and harming other people. They weren't in armoured cars to protect > against this? They had no right to be on the road! > > Zero UDP checksums are hit-and-run accidents waiting to happen. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 21 January 2014 20:14 > To: Eggert, Lars > Cc: Stewart Bryant; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com; J= oel Jaeggli; mpls@ietf.org > Subject: Re: [mpls] Last Call: (Encapsula= ting MPLS in UDP) to Proposed Standard > > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> > "Eggert, Lars" writes: > > > Hi, > > > > On 2014-1-21, at 12:50, Stewart Bryant wrote: > > > In terms of congestion and misdelivery it is interesting looking > > > at the number of horses that are already bounding around > > > in the paddock outside the stable: > > > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > > > there is a big difference between encapsulation in IP and > > encapsulation in UDP. Everything encapsulated with "obscure" IP > > protocol numbers will get dropped by default at NATs and firewalls, > > whereas UDO traffic happily traverses them. The reach of UDP traffic > > is much broader. > > > > Lars > > > Stray UDP packets carrying MPLS getting to grandma's firewall is > really stretching the argument but ... > > When encapsulating in UDP, the UDP checksum might be zero but the IP > checksum can still be filled in so the IP destination is checked and > grandma need not worry about these packets. But ... > > Grandma's firewall would block since there is no state established on > the firewall with the opposite port pair pattern. But ... > > Even if it went through when the packet reached grandma's subnet the > payload is junk bound to an unused port. Maybe it hits grandma's DNS > server and is interpreted as a badly malformed DNS request. > > So grandma seems safe from these bad packets. > > Lack of UDP checksum should at worst mean that the destination gets a > packet with a munged payload, pulls off the IP and UDP headers and > continues to forward. At worst has the wrong MPLS label and gets > blackholed in the provider network somewhere. If it ends up at the > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > UDP payload carried in that IP got munged the packet could end up at > the destination with a bad TCP or UDP checksum and get dropped. > > Curtis From touch@isi.edu Tue Jan 21 17:05:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7021A0266; Tue, 21 Jan 2014 17:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 yFUgIdWtgmu1; Tue, 21 Jan 2014 17:05:25 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id ECEDA1A024F; Tue, 21 Jan 2014 17:05:24 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0M14Inb000306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jan 2014 17:04:18 -0800 (PST) Message-ID: <52DF1911.8040806@isi.edu> Date: Tue, 21 Jan 2014 17:04:17 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Eggert, Lars" , Scott Brim References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <52D05C75.3050505@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:05:26 -0000 +1 Edward Crabbe is right - the encapsulated protocols ought to take care of congestion control when using UDP. When they do NOT - e.g., when using MPLS to transfer traffic that either isn't IP or is IP but isn't congestion controlled, then some other mechanism needs to be employed. It's not enough to assume "someone else, somewhere else" will handle this. I agree with Lars - this needs to be part of the encapsulation protocol, because it's not enforced by MPLS, and not provided by UDP. Joe On 1/10/2014 10:23 PM, Eggert, Lars wrote: > Hi, > > On 2014-1-10, at 22:32, Scott Brim wrote: >> OK good point - so we invoke the end-to-end argument on MPLS's behalf. > > look at it the other way. From the viewpoint of the rest of the net, you are an application using UDP. Such applications need to follow a set of principles we have IETF consensus on (RFC5405). > > By encapsulating MPLS in UDP, you are changing the game. That traffic can now appear on any Internet path, and not just inside provisioned networks. Because of that, you need a mechanism to detect if you are causing congestion, and a mechanism to react to it. > > And it *is* a requirement on the encapsulator, because from the perspective of the rest of the net, that is the application that generates the UDP traffic. > > Lars > From touch@isi.edu Tue Jan 21 17:08:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2061B1A02DE; Tue, 21 Jan 2014 17:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 ycx--PJrQ9dC; Tue, 21 Jan 2014 17:08:37 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2FA1A0266; Tue, 21 Jan 2014 17:08:33 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0M17vXb001507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jan 2014 17:07:57 -0800 (PST) Message-ID: <52DF19ED.8010200@isi.edu> Date: Tue, 21 Jan 2014 17:07:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Joel M. Halpern" , "Eggert, Lars" , Stewart Bryant References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> In-Reply-To: <52D5568F.2070600@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:08:44 -0000 On 1/14/2014 7:23 AM, Joel M. Halpern wrote: > Isn't that basically the problem of the inner traffic sender, not the > problem of the tunnel that is carrying the traffic? > Asking tunnel's to solve the problem of applications with undesirable > behavior seems backwards. By that argument, apps using TCP shouldn't expect the transport to control congestion. They ought to control it at the app layer. Tunneled MPLS, when encapsulated inside UDP, *is* the "application". UDP expects the app to deal with congestion, so it's entirely reasonable for UDP to expect the tunneling system to do this. Joe > > Yours, > Joel > > On 1/14/14 10:20 AM, Eggert, Lars wrote: >> On 2014-1-14, at 15:20, Stewart Bryant wrote: >>> Yes, the inner (real) transport header is the only meaningful place >>> to apply congestion avoidance. >> >> But what if the inner traffic isn't congestion controlled? >> >> Lars >> From touch@isi.edu Tue Jan 21 17:11:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C911A033F; Tue, 21 Jan 2014 17:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 WN6-MZQ7ovip; Tue, 21 Jan 2014 17:11:44 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BFF271A01BC; Tue, 21 Jan 2014 17:11:44 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0M1BW8I002184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jan 2014 17:11:32 -0800 (PST) Message-ID: <52DF1AC4.7080007@isi.edu> Date: Tue, 21 Jan 2014 17:11:32 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ross Callon , "Eggert, Lars" References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:11:51 -0000 On 1/16/2014 2:32 PM, Ross Callon wrote: >>> These tunnels are stateless >> >> yep. (But they don't have to be.) > > The tunnels strictly speaking do not have to be stateless. However, if you want routers to actually implement them, and you want to scale in both forwarding speed and number of tunnels, then yes they do have to be stateless. There's clearly a problem though: - tunnels must be stateless to be efficiently implemented - transport layer tunnels must have congestion control Saying that the only way we can make tunnels cheap is to make them break the Internet isn't a good solution. Maybe it's time to expect something that's inherently costly to end up being expensive? Joe From touch@isi.edu Tue Jan 21 17:13:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA3E1A0381; Tue, 21 Jan 2014 17:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 8E3I-ViLnAaJ; Tue, 21 Jan 2014 17:13:48 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 35C781A037F; Tue, 21 Jan 2014 17:13:48 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0M1Cace002661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jan 2014 17:12:36 -0800 (PST) Message-ID: <52DF1B04.70802@isi.edu> Date: Tue, 21 Jan 2014 17:12:36 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Eggert, Lars" , Xuxiaohu References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082443DD@NKGEML512-MBS.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:13:50 -0000 +1 I don't even care if the safety breaker is a little late, e.g., a few hundreds of packets (as might be needed for efficient implementation). Joe On 1/13/2014 1:42 AM, Eggert, Lars wrote: > Hi, > > On 2014-1-13, at 10:16, Xuxiaohu wrote: >> No conflict at all. What I meant is: for those clients of MPLS which are not TCP-friendly (case 2&3 as described in Section 3.1.3 of RFC5405), they should never be transported over the unprovisioned path (e.g., the Internet). Insteads, they should only be transported over a provisioned path in a restricted networking environment. As a result, there is no need for the congestion control mechanism for them. > > I agree, but I think we need a safety mechanism when such traffic does end up on the general Internet (because operators may not read the RFC, or there may be configuration errors, etc.) > > Even when running inside a provisioned domain, you probably want some sort of safety net, like a circuit breaker that detects if your tunnel is experiencing/causing severe congestion, and shut it down. > > Lars > From touch@isi.edu Tue Jan 21 17:15:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F611A0284; Tue, 21 Jan 2014 17:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.235 X-Spam-Level: X-Spam-Status: No, score=-4.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 QVcYqZn5PMbU; Tue, 21 Jan 2014 17:15:18 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9161A0285; Tue, 21 Jan 2014 17:15:18 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0M1EjNh003052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jan 2014 17:14:45 -0800 (PST) Message-ID: <52DF1B85.4020302@isi.edu> Date: Tue, 21 Jan 2014 17:14:45 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Eggert, Lars" , "curtis@ipv6.occnc.com" References: <201401171719.s0HHJqHY062965@maildrop2.v6ds.occnc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:15:23 -0000 +1 on all points. I suspect if more people in transport had the time to track this protracted discussion, you'd get the same from them too. Joe On 1/21/2014 5:22 AM, Eggert, Lars wrote: > Hi, > > On 2014-1-17, at 18:19, Curtis Villamizar wrote: >> You have made your assertions about your desire to uphold the purity >> of any new UDP applications and adhere to the BCP you wrote. >> >> You appear to be very nearly alone in this argument and certainly no >> one that works with MPLS is siding with you. > > the reason we wrote the RFC when I was TSV AD was that we were seeing a whole bunch of questionable uses of UDP over the eyars and we were having the same arguments over and over. That's why we decided to write down the practices we expect users of UDP to follow. This is yet another such questionable use. > > (Also, I don't appreciate you turning this into a personal argument.) > >> In the end we can put anything we want in the RFC *but* IETF has never >> truly had the final word on what vendors and operators do in provider >> networks. > > Aka the "take my toys and go home" argument. Heard it many times. > >> In this case, regardless of what changes are made to the draft, >> implementations will offer at least the option for non-RFC behavior by >> using zero checksums and not using any congestion control. And >> providers will make use of it, perhaps exclusively. > > And there's nothing wrong with that - the BCP even says that one SHOULD NOT use congestion control for some deployment cases. > > But for others, one SHOULD. For those, a mechanism needs to be available, i.e., it needs to be specified and implemented. > >> The document might as well reflect reality, despite reality not >> conforming to your notions of architectural purity. > > I'm sorry, but we have certain architectural principles in the Internet that we have IETF consensus on. At least since RFC2914, that includes the need to have congestion control in place. > > There are always special deployment scenarios where these principles do not apply, and we typically explain in applicability statements when out specifications can only be safely used under certain conditions. I don't see any such statement in draft-ietf-mpls-in-udp, which to me means it's targeted at general Internet-wide use. > >> The best course of action is to put a SHOULD in regarding checksums >> and put a SHOULD in regarding congestion avoidance. Even the BCP does >> not go any further than to say a tunneling protocol SHOULD use >> congestion control and there were reasons that the word MUST was not >> acceptable in the BCP. > > The SHOULD for congestion control needs to actually describe a mechanism that can be used when needed. It can't be a blanket "you SHOULD use something but we don't tell you what it is"-statement. > >> If we are still arguing over two instances of SHOULD vs MUST we have >> wasted a lot of bandwidth on those two words. > > It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it needs to be specified what is to be done. In the case of checksums, that's obvious (calculate it and check it); in the case of congestion control, some actual mechanism needs to be described (e.g., a circuit breaker). > >> IMHO The only remaining question is whether the document can go forward >> with the definition of congestion control for MPLS over UDP left out >> of scope and for another document if a need arises. > > In my opinion, it cannot. > >> If this is not acceptable to you (I doubt it is) please indicate what >> you would like to see in the document and since this is IETF last call >> where consensus matters and no one individual has veto power, we'll >> have to see if there is consensus behind your proposed changes. > > I would like the document to specify at the very least a circuit breaker mechanism, that stops the tunneled traffic if severe packet loss is detected along the path. > > And this isn't about an "individual veto". This is about a document that is at the moment in violation of IETF consensus at least as far back as RFC2914. > > Lars > From akatlas@gmail.com Tue Jan 21 18:34:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167D11A0152 for ; Tue, 21 Jan 2014 18:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWD0WVpQIXtY for ; Tue, 21 Jan 2014 18:34:47 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id C8ADB1A0125 for ; Tue, 21 Jan 2014 18:34:46 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id at1so7943295iec.22 for ; Tue, 21 Jan 2014 18:34:46 -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=MHIB4QoQD5POM/YGlFDGNRG9+A19iRq51m4Mo04wXa8=; b=QgtUsxlOKPbuKXIPSEc5NwvtUSx+jBwGf5chlo2VQqCTis1tGx6Vgpok46J3AKDt0a CSsDjyVlGvko67RmQYFXtXkKZPz+iX3+YDlU2df77wVz74EPqmPljpgMLyTdogcJdOuP TJwhxdAeu1FNsppbhRY2Q1KgHneRiLtw9k7obJYK6xhP7M/mSmV2uPG4xHeX0xfBZiTV kzefbOIKjE/38PUer4zA/aPcGbKp/anwZFH7fDpaXRA0z609Z/W5IlJ5NZJCuBYq1Dr0 i2yU4sdNeADlJNYEypjOLQt2knX+QDgfMNC/E6d5SQy13Bdr8hxZzG2dKhL9UwNg7nRL /t4w== MIME-Version: 1.0 X-Received: by 10.50.25.129 with SMTP id c1mr21074906igg.23.1390358086276; Tue, 21 Jan 2014 18:34:46 -0800 (PST) Received: by 10.64.72.132 with HTTP; Tue, 21 Jan 2014 18:34:46 -0800 (PST) In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> <201401220024.s0M0OwGW068768@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk> Date: Tue, 21 Jan 2014 21:34:46 -0500 Message-ID: From: Alia Atlas To: l.wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=047d7bdc10ecd7e0c704f085f7ae Cc: joelja@bogus.com, "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 02:34:52 -0000 --047d7bdc10ecd7e0c704f085f7ae Content-Type: text/plain; charset=ISO-8859-1 Lloyd, On Tue, Jan 21, 2014 at 8:04 PM, wrote: > Curtis, > > the 'intended for use within a service provider' and not for mass use > sounds reasonable, > and scoping in this way may also alleviate some congestion control > concerns. > [Alia] Excellent - so if we can describe filtering on the correct fields to enforce this constrained scope, then the concerns about congestion control may be alleviated. > > But outgoing packet filtering, when you're trying to catch a corrupted > port, > and the port is not what you think it is? That's going to do a partial job > of corrupted addresses in IPv6 at best. (v4 has header checksums, > ports in v4 and v6 are open to corruption sans UDP pseudo-header > check.) > [Alia] Are you actually suggesting that it is highly likely for both the destination IP and UDP port to be simultaneously corrupted on a significant flow of packets where each link already has a FCS covering the entire packet? [Alia] We have vast existence proof that MPLS label stacks, also covered only by link FCS, that this is not the case. Naturally the top label is manipulated but the rest of the label stack is just passed through and not looked at. Not convinced by providers already blocking inbound traffic on a new port - > particularly given discussion of handling entropy with varying ports > in another thread. > [Alia] For defense, isn't it a case of block ports by default and only open the destination ports that are explicitly needed? That's how firewalls that I've seen work; perhaps others have a common counterexample? The entropy is put into the source port, which isn't relevant here. > So, I don't think filtering is a useful solution here to the problem posed > by zero UDP checksums. (An actual UDP checksum solves it, of course.) > [Alia] Can you clearly articulate what you see as the threat scenario and the necessary scale and probability to be meaningful here? Regards, Alia > > regards > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 22 January 2014 00:24 > To: Wood L Dr (Electronic Eng) > Cc: curtis@ipv6.occnc.com; lars@netapp.com; stbryant@cisco.com; > joelja@bogus.com; mpls@ietf.org > Subject: Re: [mpls] Last Call: > (Encapsulating MPLS in UDP) to Proposed Standard > > Lloyd, > > Since MPLS over UDP is intended to be used within a provider, how > about if we recommend the following: > > If no MPLS over UDP is intended to go outside a service provider, > then packet filters should be added to block traffic with the UDP > port number for MPLS over UDP to prevent misconfiguation or packet > error to cause MPLS over UDP packets to escape, > > If either the IP destination address or the UDP destination port were > corrupted, then the packet would not leave. The former because the > intended destination within the provider would get the packet. The > latter because with the UDP port intact the provider's filter would > block it. > > This would also prevent ordinary users from making use of MPLS over > UDP, which with its absense of congestion control is causing some > objections. > > Providers would already be blocking traffic coming into their net with > this UDP port, particularly to their own infrastructure. The filters > might cover only their own addresses allowing users to make use of > MPLS over UDP, or could block it entirely. > > This is in line with Alia's suggestion that we define a profile of > intended use being for service providers internal use. > > Curtis > > > In message < > 290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > > checksum can still be filled in so the IP destination is checked > > > > IPv6 doesn't have an IP header checksum. So with an error in the > > header the packet can go anywhere. > > > > > > > Lack of UDP checksum should at worst mean that the destination gets a > > > packet with a munged payload, pulls off the IP and UDP headers and > > > continues to forward > > > > ... or a munged header, and forwards to a different application on a > different port. > > > > See RFC 6936 section 3, which goes through the scenarios - but plays > light > > on the side-effects. My beef is with: > > > > A protocol or application that uses the zero UDP checksum method must > > ensure that the lack of checksum does not affect the protocol > > operation. This includes being robust to receiving an unintended > > packet from another protocol or context following corruption of a > > destination or source address and/or port value. It also includes > > considering the need for additional implicit protection mechanisms > > required when using the payload of a UDP packet received with a zero > > checksum. > > > > Lack of a UDP checksum in one protocol can affect the operation of other > > protocols minding their own business, until they receive and try to > handle > > a corrupted packet from the first protocol because port or address is > > corrupted. There are a lot of applications that presume that the data > they > > are given is error-free, and they presume that rogue data is not > injected into > > their conversation. > > > > I mean, if you're going to use a zero UDP checksum, and your application > > messes up and gives itself corrupt data, fine. More fool you. By analogy > > as a risk, it's like speeding while talking on a cellphone and crashing > into a tree. > > But if your lack of checksum means you affect other applications who have > > to now protect themselves against your data, you're effectively now > crashing > > into and harming other people. They weren't in armoured cars to protect > > against this? They had no right to be on the road! > > > > Zero UDP checksums are hit-and-run accidents waiting to happen. > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Curtis Villamizar [curtis@ipv6.occnc.com] > > Sent: 21 January 2014 20:14 > > To: Eggert, Lars > > Cc: Stewart Bryant; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com; > Joel Jaeggli; mpls@ietf.org > > Subject: Re: [mpls] Last Call: > (Encapsulating MPLS in UDP) to Proposed Standard > > > > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> > > "Eggert, Lars" writes: > > > > > Hi, > > > > > > On 2014-1-21, at 12:50, Stewart Bryant wrote: > > > > In terms of congestion and misdelivery it is interesting looking > > > > at the number of horses that are already bounding around > > > > in the paddock outside the stable: > > > > > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > > > > > there is a big difference between encapsulation in IP and > > > encapsulation in UDP. Everything encapsulated with "obscure" IP > > > protocol numbers will get dropped by default at NATs and firewalls, > > > whereas UDO traffic happily traverses them. The reach of UDP traffic > > > is much broader. > > > > > > Lars > > > > > > Stray UDP packets carrying MPLS getting to grandma's firewall is > > really stretching the argument but ... > > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > checksum can still be filled in so the IP destination is checked and > > grandma need not worry about these packets. But ... > > > > Grandma's firewall would block since there is no state established on > > the firewall with the opposite port pair pattern. But ... > > > > Even if it went through when the packet reached grandma's subnet the > > payload is junk bound to an unused port. Maybe it hits grandma's DNS > > server and is interpreted as a badly malformed DNS request. > > > > So grandma seems safe from these bad packets. > > > > Lack of UDP checksum should at worst mean that the destination gets a > > packet with a munged payload, pulls off the IP and UDP headers and > > continues to forward. At worst has the wrong MPLS label and gets > > blackholed in the provider network somewhere. If it ends up at the > > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > > UDP payload carried in that IP got munged the packet could end up at > > the destination with a bad TCP or UDP checksum and get dropped. > > > > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7bdc10ecd7e0c704f085f7ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Lloyd,

On Tue, Jan 21, 2014 at 8:04 PM, <l.wood@surrey.ac.uk> wrote:
Curtis,

the 'intended for use within a service provider' and not for mass u= se sounds reasonable,
and scoping in this way may also alleviate some congestion control concerns= .

[Alia] Excellent - so if we can descr= ibe filtering on the correct fields to enforce this constrained scope, then= the concerns about congestion control may be alleviated.=A0

But outgoing packet filtering, when you're trying to catch a corrupted = port,
and the port is not what you think it is? That's going to do a partial = job
of corrupted addresses in IPv6 at best. (v4 has header checksums,
ports in v4 and v6 are open to corruption sans UDP pseudo-header
check.)

[Alia] Are you actually suggest= ing that it is highly likely for both the destination IP and UDP port to be= simultaneously corrupted on a significant flow of packets where each link = already has a FCS covering the entire packet?

[Alia] We have vast existence proof that MPLS label sta= cks, also covered only by link FCS, that this is not the case. =A0Naturally= the top label is manipulated but the rest of the label stack is just passe= d through and not looked at.=A0

Not convinced by providers already blocking inbound traffic on a new port -=
particularly given discussion of handling entropy with varying ports
in another thread.

[Alia] For defense, = isn't it a case of block ports by default and only open the destination= ports that are explicitly needed? =A0That's how firewalls that I'v= e seen work; perhaps others have a common counterexample? =A0The entropy is= put into the source port, which isn't relevant here.
=A0
So, I don't think filtering is a useful solution here to the problem po= sed
by zero UDP checksums. (An actual UDP checksum solves it, of course.)

[Alia] Can you clearly articulate what you s= ee as the threat scenario and the necessary scale and probability to be mea= ningful here?

Regards,
Alia
=A0

regards

Lloyd Wood
http://about.me/llo= ydwood
________________________________________
From: Curtis Villamizar [curtis@ip= v6.occnc.com]
Sent: 22 January 2014 00:24
To: Wood L =A0Dr (Electronic Eng)
Cc: curtis@ipv6.occnc.com; lars@netapp.com; stbryant@cisco.com; joelja@bogus.com; mpls@ietf.org Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encap= sulating MPLS in UDP) to Proposed Standard

Lloyd,

Since MPLS over UDP is intended to be used within a provider, how
about if we recommend the following:

=A0 If no MPLS over UDP is intended to go outside a service provider,
=A0 then packet filters should be added to block traffic with the UDP
=A0 port number for MPLS over UDP to prevent misconfiguation or packet
=A0 error to cause MPLS over UDP packets to escape,

If either the IP destination address or the UDP destination port were
corrupted, then the packet would not leave. =A0The former because the
intended destination within the provider would get the packet. =A0The
latter because with the UDP port intact the provider's filter would
block it.

This would also prevent ordinary users from making use of MPLS over
UDP, which with its absense of congestion control is causing some
objections.

Providers would already be blocking traffic coming into their net with
this UDP port, particularly to their own infrastructure. =A0The filters
might cover only their own addresses allowing users to make use of
MPLS over UDP, or could block it entirely.

This is in line with Alia's suggestion that we define a profile of
intended use being for service providers internal use.

Curtis


In message <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01C= MS.surrey.ac.uk>
l.wood@surrey.ac.uk writes:
>
> > When encapsulating in UDP, the UDP checksum might be zero but the= IP
> > checksum can still be filled in so the IP destination is checked<= br> >
> IPv6 doesn't have an IP header checksum. So with an error in the > header the packet can go anywhere.
>
>
> > Lack of UDP checksum should at worst mean that the destination ge= ts a
> > packet with a munged payload, pulls off the IP and UDP headers an= d
> > continues to forward
>
> ... or a munged header, and forwards to a different application on a d= ifferent port.
>
> See RFC 6936 section 3, which goes through the scenarios - =A0but play= s light
> on the side-effects. My beef is with:
>
> =A0 =A0A protocol or application that uses the zero UDP checksum metho= d must
> =A0 =A0ensure that the lack of checksum does not affect the protocol > =A0 =A0operation. =A0This includes being robust to receiving an uninte= nded
> =A0 =A0packet from another protocol or context following corruption of= a
> =A0 =A0destination or source address and/or port value. =A0It also inc= ludes
> =A0 =A0considering the need for additional implicit protection mechani= sms
> =A0 =A0required when using the payload of a UDP packet received with a= zero
> =A0 =A0checksum.
>
> Lack of a UDP checksum in one protocol can affect the operation of oth= er
> protocols minding their own business, until they receive and try to ha= ndle
> a corrupted packet from the first protocol because port or address is<= br> > corrupted. There are a lot of applications that presume that the data = they
> are given is error-free, and they presume that rogue data is not injec= ted into
> their conversation.
>
> I mean, if you're going to use a zero UDP checksum, and your appli= cation
> messes up and gives itself corrupt data, fine. More fool you. By analo= gy
> as a risk, it's like speeding while talking on a cellphone and cra= shing into a tree.
> But if your lack of checksum means you affect other applications who h= ave
> to now protect themselves against your data, you're effectively no= w crashing
> into and harming other people. They weren't in armoured cars to pr= otect
> against this? They had no right to be on the road!
>
> Zero UDP checksums are hit-and-run accidents waiting to happen.
>
> Lloyd Wood
> http://about.m= e/lloydwood
> ________________________________________
> From: Curtis Villamizar [curt= is@ipv6.occnc.com]
> Sent: 21 January 2014 20:14
> To: Eggert, Lars
> Cc: Stewart Bryant; Wood L =A0Dr (Electronic Eng); curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (= Encapsulating MPLS in UDP) to Proposed Standard
>
> In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com>
> "Eggert, Lars" writes:
>
> > Hi,
> >
> > On 2014-1-21, at 12:50, Stewart Bryant <stbryant@cisco.com> wrote:
> > > In terms of congestion and misdelivery it is interesting loo= king
> > > at the number of horses that are already bounding around
> > > in the paddock outside the stable:
> > >
> > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example.
> >
> > there is a big difference between encapsulation in IP and
> > encapsulation in UDP. Everything encapsulated with "obscure&= quot; IP
> > protocol numbers will get dropped by default at NATs and firewall= s,
> > whereas UDO traffic happily traverses them. The reach of UDP traf= fic
> > is much broader.
> >
> > Lars
>
>
> Stray UDP packets carrying MPLS getting to grandma's firewall is > really stretching the argument but ...
>
> When encapsulating in UDP, the UDP checksum might be zero but the IP > checksum can still be filled in so the IP destination is checked and > grandma need not worry about these packets. =A0But ...
>
> Grandma's firewall would block since there is no state established= on
> the firewall with the opposite port pair pattern. =A0But ...
>
> Even if it went through when the packet reached grandma's subnet t= he
> payload is junk bound to an unused port. =A0Maybe it hits grandma'= s DNS
> server and is interpreted as a badly malformed DNS request.
>
> So grandma seems safe from these bad packets.
>
> Lack of UDP checksum should at worst mean that the destination gets a<= br> > packet with a munged payload, pulls off the IP and UDP headers and
> continues to forward. =A0At worst has the wrong MPLS label and gets > blackholed in the provider network somewhere. =A0If it ends up at the<= br> > correct MPLS egress, if IP, the IP checksum is checked. =A0If a TCP or=
> UDP payload carried in that IP got munged the packet could end up at > the destination with a bad TCP or UDP checksum and get dropped.
>
> Curtis
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7bdc10ecd7e0c704f085f7ae-- From rcallon@juniper.net Tue Jan 21 18:40:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2859A1A025F; Tue, 21 Jan 2014 18:40:12 -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 n8sAdxCtsrrY; Tue, 21 Jan 2014 18:40:09 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3746A1A0152; Tue, 21 Jan 2014 18:40:09 -0800 (PST) Received: from mail52-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 22 Jan 2014 02:40:08 +0000 Received: from mail52-am1 (localhost [127.0.0.1]) by mail52-am1-R.bigfish.com (Postfix) with ESMTP id 3774AE0144; Wed, 22 Jan 2014 02:40:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(z579ehzbb2dI98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h1033IL1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach9a9j1155h) Received-SPF: pass (mail52-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(13464003)(24454002)(377454003)(51704005)(479174003)(19580405001)(86362001)(83322001)(51856001)(50986001)(33646001)(74876001)(66066001)(2656002)(74706001)(4396001)(80022001)(47736001)(47976001)(83072002)(65816001)(49866001)(46102001)(54356001)(53806001)(19580395003)(74316001)(81686001)(92566001)(93136001)(90146001)(2171001)(93516002)(74366001)(80976001)(76482001)(87936001)(74662001)(56816005)(85852003)(74502001)(85306002)(47446002)(81342001)(81542001)(81816001)(79102001)(63696002)(87266001)(31966008)(76576001)(59766001)(77982001)(54316002)(56776001)(76796001)(76786001)(69226001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail52-am1 (localhost.localdomain [127.0.0.1]) by mail52-am1 (MessageSwitch) id 139035840584948_19187; Wed, 22 Jan 2014 02:40:05 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.248]) by mail52-am1.bigfish.com (Postfix) with ESMTP id 106AA46004C; Wed, 22 Jan 2014 02:40:05 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 22 Jan 2014 02:40:04 +0000 Received: from CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Wed, 22 Jan 2014 02:40:02 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) with Microsoft SMTP Server (TLS) id 15.0.851.11; Wed, 22 Jan 2014 02:40:00 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0851.011; Wed, 22 Jan 2014 02:40:00 +0000 From: Ross Callon To: Joe Touch , "Eggert, Lars" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPB81jtn8uxkZO2EiBZeT7DEf4ppp6pziAgAK2KYCAAFQ7gIAAckaAgAAJRICAAAZDAIAD31WAgABWkACAAHXPgIAAN0wAgAEJtoCAACSWAIAAC2+AgAAH1ACAABCvgIAAAQmAgAABlACAAz/IAIAAA6wAgABUpZCACArNAIAAFXLw Date: Wed, 22 Jan 2014 02:40:00 +0000 Message-ID: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> <52DF1AC4.7080007@isi.edu> In-Reply-To: <52DF1AC4.7080007@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-forefront-prvs: 00997889E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 02:40:12 -0000 If the upper layers (the thing that runs over the tunnel) involves applicat= ions over TCP over IP, or if it is otherwise responding to congestion in th= e same way that we expect anything running over IP to respond to congestion= , then we don't want the tunnel to also independently try to respond to con= gestion (two independent cooks cooking the same meal does not necessarily l= ead to success).=20 If the upper layer does not respond to congestion, then perhaps it shouldn'= t be running over the open Internet (with or without a tunnel), unless the = *total* bandwidth that could be used is inherently quite low. On the other = hand, it might want to run within a data center or internally to a service = provider network with appropriate provisioning.=20 Ross -----Original Message----- From: Joe Touch [mailto:touch@isi.edu]=20 Sent: Tuesday, January 21, 2014 8:12 PM To: Ross Callon; Eggert, Lars Cc: mpls@ietf.org; IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard On 1/16/2014 2:32 PM, Ross Callon wrote: >>> These tunnels are stateless >> >> yep. (But they don't have to be.) > > The tunnels strictly speaking do not have to be stateless. However, if yo= u want routers to actually implement them, and you want to scale in both fo= rwarding speed and number of tunnels, then yes they do have to be stateless= . There's clearly a problem though: - tunnels must be stateless to be efficiently implemented - transport layer tunnels must have congestion control Saying that the only way we can make tunnels cheap is to make them break=20 the Internet isn't a good solution. Maybe it's time to expect something that's inherently costly to end up=20 being expensive? Joe From l.wood@surrey.ac.uk Tue Jan 21 19:38:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4AF1A0183 for ; Tue, 21 Jan 2014 19:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vS5-y76lz4J7 for ; Tue, 21 Jan 2014 19:38:22 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id 02C021A0125 for ; Tue, 21 Jan 2014 19:38:21 -0800 (PST) Received: from [85.158.136.51:33199] by server-1.bemta-5.messagelabs.com id 1F/1D-21065-C2D3FD25; Wed, 22 Jan 2014 03:38:20 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-5.tower-49.messagelabs.com!1390361900!25525584!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3915 invoked from network); 22 Jan 2014 03:38:20 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-5.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 22 Jan 2014 03:38:20 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Wed, 22 Jan 2014 03:38:19 +0000 From: To: Date: Wed, 22 Jan 2014 03:38:19 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8XGosA4PjLvdhfQ/6Py6AaoQfeIwAB+zAk Message-ID: <290E20B455C66743BE178C5C84F1240847E63346E0@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> <201401220024.s0M0OwGW068768@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 03:38:25 -0000 > [Alia] Excellent - so if we can describe filtering on the correct fields = to enforce this constrained scope, then the concerns about congestion contr= ol may be alleviated. For intended private use within a network, I think you'd be fine;as with co= ngestion, crossing the public Internet poses more of a problem. I don't see= how filtering comes in to enforce this. > [Alia] Are you actually suggesting that it is highly likely for both the = destination IP and UDP port to be simultaneously corrupted on a significant= flow of packets where each link already has a FCS covering the entire pack= et? It is possible. The FCS only covers the link, and the zero UDP checksum rem= oves any check across the entire path. > [Alia] We have vast existence proof that MPLS label stacks, also covered = only by link FCS, that this is not the case. MPLS is scoped within the link between MPLS-aware devices. This tunnelling = use is along the entire path. The scope is different. How are MPLS discards= or missent packets measured? > [Alia] Can you clearly articulate what you see as the threat scenario and= the necessary scale and probability to be meaningful here? 'Threat scenario' is language about mitigating a threat to your traffic. He= re, your traffic with a zero UDP checksum poses the threat - to everything = else. Probability of threat is non-zero, but unknown, because networks are not in= strumented for it. We have discussed Stone's results and other anecdotal ev= idence in this thread. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Alia Atlas [akatlas@gmail.com] Sent: 22 January 2014 02:34 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com; joelja@bogus.com; mpls@ietf.org; Eggert, Lars Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Lloyd, On Tue, Jan 21, 2014 at 8:04 PM, > wrote: Curtis, the 'intended for use within a service provider' and not for mass use sound= s reasonable, and scoping in this way may also alleviate some congestion control concerns= . [Alia] Excellent - so if we can describe filtering on the correct fields to= enforce this constrained scope, then the concerns about congestion control= may be alleviated. But outgoing packet filtering, when you're trying to catch a corrupted port= , and the port is not what you think it is? That's going to do a partial job of corrupted addresses in IPv6 at best. (v4 has header checksums, ports in v4 and v6 are open to corruption sans UDP pseudo-header check.) [Alia] Are you actually suggesting that it is highly likely for both the de= stination IP and UDP port to be simultaneously corrupted on a significant f= low of packets where each link already has a FCS covering the entire packet= ? [Alia] We have vast existence proof that MPLS label stacks, also covered on= ly by link FCS, that this is not the case. Naturally the top label is mani= pulated but the rest of the label stack is just passed through and not look= ed at. Not convinced by providers already blocking inbound traffic on a new port - particularly given discussion of handling entropy with varying ports in another thread. [Alia] For defense, isn't it a case of block ports by default and only open= the destination ports that are explicitly needed? That's how firewalls th= at I've seen work; perhaps others have a common counterexample? The entrop= y is put into the source port, which isn't relevant here. So, I don't think filtering is a useful solution here to the problem posed by zero UDP checksums. (An actual UDP checksum solves it, of course.) [Alia] Can you clearly articulate what you see as the threat scenario and t= he necessary scale and probability to be meaningful here? Regards, Alia regards Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 22 January 2014 00:24 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com; lars@netapp.com; stbryant@cisco.com; joelj= a@bogus.com; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Lloyd, Since MPLS over UDP is intended to be used within a provider, how about if we recommend the following: If no MPLS over UDP is intended to go outside a service provider, then packet filters should be added to block traffic with the UDP port number for MPLS over UDP to prevent misconfiguation or packet error to cause MPLS over UDP packets to escape, If either the IP destination address or the UDP destination port were corrupted, then the packet would not leave. The former because the intended destination within the provider would get the packet. The latter because with the UDP port intact the provider's filter would block it. This would also prevent ordinary users from making use of MPLS over UDP, which with its absense of congestion control is causing some objections. Providers would already be blocking traffic coming into their net with this UDP port, particularly to their own infrastructure. The filters might cover only their own addresses allowing users to make use of MPLS over UDP, or could block it entirely. This is in line with Alia's suggestion that we define a profile of intended use being for service providers internal use. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > checksum can still be filled in so the IP destination is checked > > IPv6 doesn't have an IP header checksum. So with an error in the > header the packet can go anywhere. > > > > Lack of UDP checksum should at worst mean that the destination gets a > > packet with a munged payload, pulls off the IP and UDP headers and > > continues to forward > > ... or a munged header, and forwards to a different application on a diff= erent port. > > See RFC 6936 section 3, which goes through the scenarios - but plays lig= ht > on the side-effects. My beef is with: > > A protocol or application that uses the zero UDP checksum method must > ensure that the lack of checksum does not affect the protocol > operation. This includes being robust to receiving an unintended > packet from another protocol or context following corruption of a > destination or source address and/or port value. It also includes > considering the need for additional implicit protection mechanisms > required when using the payload of a UDP packet received with a zero > checksum. > > Lack of a UDP checksum in one protocol can affect the operation of other > protocols minding their own business, until they receive and try to handl= e > a corrupted packet from the first protocol because port or address is > corrupted. There are a lot of applications that presume that the data the= y > are given is error-free, and they presume that rogue data is not injected= into > their conversation. > > I mean, if you're going to use a zero UDP checksum, and your application > messes up and gives itself corrupt data, fine. More fool you. By analogy > as a risk, it's like speeding while talking on a cellphone and crashing i= nto a tree. > But if your lack of checksum means you affect other applications who have > to now protect themselves against your data, you're effectively now crash= ing > into and harming other people. They weren't in armoured cars to protect > against this? They had no right to be on the road! > > Zero UDP checksums are hit-and-run accidents waiting to happen. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 21 January 2014 20:14 > To: Eggert, Lars > Cc: Stewart Bryant; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org > Subject: Re: [mpls] Last Call: (Encapsula= ting MPLS in UDP) to Proposed Standard > > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> > "Eggert, Lars" writes: > > > Hi, > > > > On 2014-1-21, at 12:50, Stewart Bryant > wrote: > > > In terms of congestion and misdelivery it is interesting looking > > > at the number of horses that are already bounding around > > > in the paddock outside the stable: > > > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > > > there is a big difference between encapsulation in IP and > > encapsulation in UDP. Everything encapsulated with "obscure" IP > > protocol numbers will get dropped by default at NATs and firewalls, > > whereas UDO traffic happily traverses them. The reach of UDP traffic > > is much broader. > > > > Lars > > > Stray UDP packets carrying MPLS getting to grandma's firewall is > really stretching the argument but ... > > When encapsulating in UDP, the UDP checksum might be zero but the IP > checksum can still be filled in so the IP destination is checked and > grandma need not worry about these packets. But ... > > Grandma's firewall would block since there is no state established on > the firewall with the opposite port pair pattern. But ... > > Even if it went through when the packet reached grandma's subnet the > payload is junk bound to an unused port. Maybe it hits grandma's DNS > server and is interpreted as a badly malformed DNS request. > > So grandma seems safe from these bad packets. > > Lack of UDP checksum should at worst mean that the destination gets a > packet with a munged payload, pulls off the IP and UDP headers and > continues to forward. At worst has the wrong MPLS label and gets > blackholed in the provider network somewhere. If it ends up at the > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > UDP payload carried in that IP got munged the packet could end up at > the destination with a bad TCP or UDP checksum and get dropped. > > Curtis _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From scott.brim@gmail.com Tue Jan 21 19:51:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520501A01C8; Tue, 21 Jan 2014 19:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6alxzttj4Fru; Tue, 21 Jan 2014 19:51:01 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id C10EE1A018E; Tue, 21 Jan 2014 19:51:01 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id j17so4325404oag.14 for ; Tue, 21 Jan 2014 19:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1Y157LQ/7jrE6Mfvy16cUTetDh9KfSGvX1/rbqvqyAg=; b=hFtvXo3fWctR2MrIx3VFkGfPrhpwNH0lrE71ZdKt7EfvhV1vwHz37hx3Owq+UsDMrZ 60+zSoPwIm3K0AZ+ESY6taDN0T0R/FRAgVzmKLGuPQH8GgwAShOA5cGVowS+lvT+eKTJ KSKfQMLZX3LOZliJlaVLjzEU+4PEbg0mWV0rrz7rcB/SF7ajLSggQjhaSgKvCUDw/7GA Xkciy3df25XaL2ciVBz5MdMu8jhODoTOrZ9hAP+MvRu9cUGBnDqUf+FofWDluXrOlmBO HyyqmgAOdyULIXHzw+NVkHlKV5rr44yF+EDJUMPvGwLoNo29HExMYMBnQNpD4T7dGSfJ i0FA== X-Received: by 10.60.98.40 with SMTP id ef8mr24179552oeb.13.1390362661415; Tue, 21 Jan 2014 19:51:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Tue, 21 Jan 2014 19:50:40 -0800 (PST) In-Reply-To: <52DF19ED.8010200@isi.edu> References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <52DF19ED.8010200@isi.edu> From: Scott Brim Date: Tue, 21 Jan 2014 22:50:40 -0500 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 03:51:03 -0000 On Tue, Jan 21, 2014 at 8:07 PM, Joe Touch wrote: > > > On 1/14/2014 7:23 AM, Joel M. Halpern wrote: >> >> Isn't that basically the problem of the inner traffic sender, not the >> problem of the tunnel that is carrying the traffic? >> Asking tunnel's to solve the problem of applications with undesirable >> behavior seems backwards. > > > By that argument, apps using TCP shouldn't expect the transport to control > congestion. They ought to control it at the app layer. > > Tunneled MPLS, when encapsulated inside UDP, *is* the "application". UDP > expects the app to deal with congestion, so it's entirely reasonable for UDP > to expect the tunneling system to do this. Joe, I believe you are confusing a protocol with an architectural function. It's a UDP encapsulation, but that encapsulation has nothing to do with transport, and what runs over it is not an "application". It may be a client layer (with the encapsulation a service layer), but that's a relative relationship, not an absolution one about stack position. This instance of UDP is way below transport, is just in fact a bit of lubrication for the packet, and considered _functionally_ has nothing to do with congestion control. The only reason for using UDP encapsulation is to get through middleboxes. If something else worked better for that, they would use it. From scott.brim@gmail.com Tue Jan 21 20:03:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8099E1A028A; Tue, 21 Jan 2014 20:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cxa1YYN7yUEU; Tue, 21 Jan 2014 20:03:42 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D09771A0270; Tue, 21 Jan 2014 20:03:41 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id vb8so9930383obc.3 for ; Tue, 21 Jan 2014 20:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=YX9WgGK60iZ/lSVVH8SYOGDDc9XjbDqHnWBilhfrS08=; b=K2GTIot584G79iLero+oE3MBKjnAwYwtWiFEKDFIY8xza16Wyccs72pEoJj/tjzLDD pznh52HZKn+yU9PGk27SDoYAVyW89s7QuLWi/8OsqBdS6dFMeE2G6l7ykK3HId3B3VRe Np7bKE8EE7FVOrDJtpyflvbRVPnVZT4lxSOq4unzw/1uC/Q5hlXFjYjdf0gpgHonqlBz dj9gW0HC2hIOY/YQIxY7xHb4vEX1hpwc9Cp012ZKTxTDs+wq7WAmrNbOe+ZMn//xPfd0 ucOwGcyNZXEjZRV+NIoRhrR20Lyd1hnkdvrwL+DROYsEWxHkf3fyFEkDvDqd3r/bYtUj svAw== X-Received: by 10.60.51.6 with SMTP id g6mr24290928oeo.5.1390363421476; Tue, 21 Jan 2014 20:03:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Tue, 21 Jan 2014 20:03:21 -0800 (PST) In-Reply-To: References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> <52DF1AC4.7080007@isi.edu> From: Scott Brim Date: Tue, 21 Jan 2014 23:03:21 -0500 Message-ID: To: Ross Callon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list , Joe Touch Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 04:03:43 -0000 On Tue, Jan 21, 2014 at 9:40 PM, Ross Callon wrote: > If the upper layers (the thing that runs over the tunnel) involves applic= ations over TCP over IP, or if it is otherwise responding to congestion in = the same way that we expect anything running over IP to respond to congesti= on, then we don't want the tunnel to also independently try to respond to c= ongestion (two independent cooks cooking the same meal does not necessarily= lead to success). > > If the upper layer does not respond to congestion, then perhaps it should= n't be running over the open Internet (with or without a tunnel), unless th= e *total* bandwidth that could be used is inherently quite low. On the othe= r hand, it might want to run within a data center or internally to a servic= e provider network with appropriate provisioning. To paraphrase: if this problem exists in the new encapsulation, then it exists already. Lars is right, this does allow traffic that was formerly run over provisioned paths in well-managed networks to possibly be part of general Internet traffic. It would be good if there were a way to be _sure_ there was e2e congestion control. But there is no signaling between this low-layer UDP encapsulation and anything above it that might already be reacting to congestion. There is no reasonably easy way for it to know what it is carrying. Yes there is a way to do congestion control at the bottom layer, but doing so could destroy performance if one (or more) layer(s) is already doing it up above. We have experience with that. I can't remember who said it, but an applicability statement might satisfy everyone, especially since it's been said (Curtis?) that this just isn't going to be used in situations where congestion will be a problem. Alternatively, a paragraph laying out the problem and saying if this is used in a way that could impact ordinary traffic, a mechanism must be defined. Scott From akatlas@gmail.com Tue Jan 21 20:04:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BF61A0351 for ; Tue, 21 Jan 2014 20:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_42=0.6, 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 yeJPbrZu1bsE for ; Tue, 21 Jan 2014 20:04:10 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 537031A034E for ; Tue, 21 Jan 2014 20:04:10 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id ar20so6109424iec.24 for ; Tue, 21 Jan 2014 20:04:09 -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=RY6/whdCHeSNeUMzztnNYHEOX9aeWr8PFAe7RbdPL5k=; b=TSofDnZjB0udJ5ETUZnFtgGwbELCggqtnx0QSOIMNTuCUKMumeCUYcT1WTHhbltuS2 o2c4NQN8fbXqr/H6WY/5Wrkaumx6BcrBvWysSkCZg3nh/rmCBTxRkE1UMMfhNvGxRJl1 sYDBvnW+uzvDDIrEUSiI6LbQN3pF8omU4agnWRZU3xckzG0NJndgygQAqe/mizMjSFg9 BjE6LrfWL0VZWzJ9AJECBaNpRsmOVc07d/5+COXgRCUjZI51mCXTjB6A+YBcoXm7QFkH u2ee1FZ/9LuL4SdbZkI/nFU2AtTJ0dan6YofAzHKX02o5nna3kicwhwIftT8bMokPF9n /ncw== MIME-Version: 1.0 X-Received: by 10.50.20.67 with SMTP id l3mr1031850ige.16.1390363449884; Tue, 21 Jan 2014 20:04:09 -0800 (PST) Received: by 10.64.72.132 with HTTP; Tue, 21 Jan 2014 20:04:09 -0800 (PST) In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346E0@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> <201401220024.s0M0OwGW068768@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F1240847E63346E0@EXMB01CMS.surrey.ac.uk> Date: Tue, 21 Jan 2014 23:04:09 -0500 Message-ID: From: Alia Atlas To: l.wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=047d7bb03ed68a080204f08737f1 Cc: joelja@bogus.com, "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 04:04:14 -0000 --047d7bb03ed68a080204f08737f1 Content-Type: text/plain; charset=ISO-8859-1 Lloyd, On Tue, Jan 21, 2014 at 10:38 PM, wrote: > > > [Alia] Excellent - so if we can describe filtering on the correct fields > to enforce this constrained scope, then the concerns about congestion > control may be alleviated. > > For intended private use within a network, I think you'd be fine;as with > congestion, crossing the public Internet poses more of a problem. I don't > see how filtering comes in to enforce this. > > > [Alia] Are you actually suggesting that it is highly likely for both the > destination IP and UDP port to be simultaneously corrupted on a significant > flow of packets where each link already has a FCS covering the entire > packet? > > It is possible. The FCS only covers the link, and the zero UDP checksum > removes any check across the entire path. > > > [Alia] We have vast existence proof that MPLS label stacks, also covered > only by link FCS, that this is not the case. > > MPLS is scoped within the link between MPLS-aware devices. This tunnelling > use is along the entire path. The scope is different. How are MPLS discards > or missent packets measured? > [Alia] I believe that you have not fully thought through how MPLS works. The top label certainly only has local significance between two adjacent routers - but there is not merely one but many labels possible in an MPLS label stack. The other labels in the label stack are passed transparently along. Perhaps this misunderstanding is part of why your insistence that the link-layer FCS is ok for MPLS but not for UDP between routers is not coming through as a coherent argument. [Alia] For example, in a typical L3VPN deployment, the ingress PE places an MPLS label indicating the VPN or even outgoing prefix. Then the ingress PE adds a second MPLS label that indicates to its next-hop that the packet is destined to the egress PE. The inner label is not seen until the egress PE - and its value is not protected by anything but the link-layer FCS. [Alia] MPLS packets with an unknown label can be counted and discarded. The number of packets sent into an RSVP-TE LSP can be compared to the number received by the egress. A number of years ago, there was actually a problem with hardware missending MPLS packets; as a result the MPLS working group defined an LSR self-test mechanism ( RFC 4379) which allows checking of the LFIB. > [Alia] Can you clearly articulate what you see as the threat scenario and > the necessary scale and probability to be meaningful here? > > 'Threat scenario' is language about mitigating a threat to your traffic. > Here, your traffic with a zero UDP checksum poses the threat - to > everything else. > [Alia] If, to inject a bit of levity and culture, you are playing the Lorax who speaks for the trees, you are speaking for all the other traffic, please explain how the MPLS in UDP as a tunnel (not transport) poses a threat. That is what I would like you to explain. [Alia] In the applicability suggested by Curtis, traffic with the port MPLS-in-UDP would be filtered. If that isn't good enough, then that is because of the error rate you are concerned about. Adding in the destination address or source address would increase the number of errors hitting the same packet that would be of concern. Granted, if one error occurs, I am willing to believe that multiple may happen. But now you are assuming that the error rate is high enough to cause problems. What is that rate and what is the corresponding rate of traffic? [Alia] Next, for this to happen, the errors must not be detected by either the link-layer FCS or memory chip checksums/validation. If this were going to happen to UDP packets, it would also and already be happening to MPLS label stacks. [Alia] I certainly heard some willingness for a SHOULD on the UDP checksum - but that won't be possible on all hardware. IF there were convincing numbers and examples, instead of significant counter-examples for the level of corruption you are suggesting, that might get greater support. Certainly the LFIB problem I mentioned that led to RFC 4379 got a lot of attention at the time! Regards, Alia Probability of threat is non-zero, but unknown, because networks are not > instrumented for it. We have discussed Stone's results and other anecdotal > evidence in this thread. > > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Alia Atlas [akatlas@gmail.com] > Sent: 22 January 2014 02:34 > To: Wood L Dr (Electronic Eng) > Cc: curtis@ipv6.occnc.com; joelja@bogus.com; mpls@ietf.org; Eggert, Lars > Subject: Re: [mpls] Last Call: > (Encapsulating MPLS in UDP) to Proposed Standard > > Lloyd, > > On Tue, Jan 21, 2014 at 8:04 PM, l.wood@surrey.ac.uk>> wrote: > Curtis, > > the 'intended for use within a service provider' and not for mass use > sounds reasonable, > and scoping in this way may also alleviate some congestion control > concerns. > > [Alia] Excellent - so if we can describe filtering on the correct fields > to enforce this constrained scope, then the concerns about congestion > control may be alleviated. > > But outgoing packet filtering, when you're trying to catch a corrupted > port, > and the port is not what you think it is? That's going to do a partial job > of corrupted addresses in IPv6 at best. (v4 has header checksums, > ports in v4 and v6 are open to corruption sans UDP pseudo-header > check.) > > [Alia] Are you actually suggesting that it is highly likely for both the > destination IP and UDP port to be simultaneously corrupted on a significant > flow of packets where each link already has a FCS covering the entire > packet? > > [Alia] We have vast existence proof that MPLS label stacks, also covered > only by link FCS, that this is not the case. Naturally the top label is > manipulated but the rest of the label stack is just passed through and not > looked at. > > Not convinced by providers already blocking inbound traffic on a new port - > particularly given discussion of handling entropy with varying ports > in another thread. > > [Alia] For defense, isn't it a case of block ports by default and only > open the destination ports that are explicitly needed? That's how > firewalls that I've seen work; perhaps others have a common counterexample? > The entropy is put into the source port, which isn't relevant here. > > So, I don't think filtering is a useful solution here to the problem posed > by zero UDP checksums. (An actual UDP checksum solves it, of course.) > > [Alia] Can you clearly articulate what you see as the threat scenario and > the necessary scale and probability to be meaningful here? > > Regards, > Alia > > > regards > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com curtis@ipv6.occnc.com>] > Sent: 22 January 2014 00:24 > To: Wood L Dr (Electronic Eng) > Cc: curtis@ipv6.occnc.com; lars@netapp.com > ; stbryant@cisco.com; > joelja@bogus.com; mpls@ietf.org mpls@ietf.org> > Subject: Re: [mpls] Last Call: > (Encapsulating MPLS in UDP) to Proposed Standard > > Lloyd, > > Since MPLS over UDP is intended to be used within a provider, how > about if we recommend the following: > > If no MPLS over UDP is intended to go outside a service provider, > then packet filters should be added to block traffic with the UDP > port number for MPLS over UDP to prevent misconfiguation or packet > error to cause MPLS over UDP packets to escape, > > If either the IP destination address or the UDP destination port were > corrupted, then the packet would not leave. The former because the > intended destination within the provider would get the packet. The > latter because with the UDP port intact the provider's filter would > block it. > > This would also prevent ordinary users from making use of MPLS over > UDP, which with its absense of congestion control is causing some > objections. > > Providers would already be blocking traffic coming into their net with > this UDP port, particularly to their own infrastructure. The filters > might cover only their own addresses allowing users to make use of > MPLS over UDP, or could block it entirely. > > This is in line with Alia's suggestion that we define a profile of > intended use being for service providers internal use. > > Curtis > > > In message < > 290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk 290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk>> > l.wood@surrey.ac.uk writes: > > > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > > checksum can still be filled in so the IP destination is checked > > > > IPv6 doesn't have an IP header checksum. So with an error in the > > header the packet can go anywhere. > > > > > > > Lack of UDP checksum should at worst mean that the destination gets a > > > packet with a munged payload, pulls off the IP and UDP headers and > > > continues to forward > > > > ... or a munged header, and forwards to a different application on a > different port. > > > > See RFC 6936 section 3, which goes through the scenarios - but plays > light > > on the side-effects. My beef is with: > > > > A protocol or application that uses the zero UDP checksum method must > > ensure that the lack of checksum does not affect the protocol > > operation. This includes being robust to receiving an unintended > > packet from another protocol or context following corruption of a > > destination or source address and/or port value. It also includes > > considering the need for additional implicit protection mechanisms > > required when using the payload of a UDP packet received with a zero > > checksum. > > > > Lack of a UDP checksum in one protocol can affect the operation of other > > protocols minding their own business, until they receive and try to > handle > > a corrupted packet from the first protocol because port or address is > > corrupted. There are a lot of applications that presume that the data > they > > are given is error-free, and they presume that rogue data is not > injected into > > their conversation. > > > > I mean, if you're going to use a zero UDP checksum, and your application > > messes up and gives itself corrupt data, fine. More fool you. By analogy > > as a risk, it's like speeding while talking on a cellphone and crashing > into a tree. > > But if your lack of checksum means you affect other applications who have > > to now protect themselves against your data, you're effectively now > crashing > > into and harming other people. They weren't in armoured cars to protect > > against this? They had no right to be on the road! > > > > Zero UDP checksums are hit-and-run accidents waiting to happen. > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Curtis Villamizar [curtis@ipv6.occnc.com curtis@ipv6.occnc.com>] > > Sent: 21 January 2014 20:14 > > To: Eggert, Lars > > Cc: Stewart Bryant; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com > ; Joel Jaeggli; mpls@ietf.org mpls@ietf.org> > > Subject: Re: [mpls] Last Call: > (Encapsulating MPLS in UDP) to Proposed Standard > > > > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com 558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com>> > > "Eggert, Lars" writes: > > > > > Hi, > > > > > > On 2014-1-21, at 12:50, Stewart Bryant stbryant@cisco.com>> wrote: > > > > In terms of congestion and misdelivery it is interesting looking > > > > at the number of horses that are already bounding around > > > > in the paddock outside the stable: > > > > > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > > > > > there is a big difference between encapsulation in IP and > > > encapsulation in UDP. Everything encapsulated with "obscure" IP > > > protocol numbers will get dropped by default at NATs and firewalls, > > > whereas UDO traffic happily traverses them. The reach of UDP traffic > > > is much broader. > > > > > > Lars > > > > > > Stray UDP packets carrying MPLS getting to grandma's firewall is > > really stretching the argument but ... > > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > checksum can still be filled in so the IP destination is checked and > > grandma need not worry about these packets. But ... > > > > Grandma's firewall would block since there is no state established on > > the firewall with the opposite port pair pattern. But ... > > > > Even if it went through when the packet reached grandma's subnet the > > payload is junk bound to an unused port. Maybe it hits grandma's DNS > > server and is interpreted as a badly malformed DNS request. > > > > So grandma seems safe from these bad packets. > > > > Lack of UDP checksum should at worst mean that the destination gets a > > packet with a munged payload, pulls off the IP and UDP headers and > > continues to forward. At worst has the wrong MPLS label and gets > > blackholed in the provider network somewhere. If it ends up at the > > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > > UDP payload carried in that IP got munged the packet could end up at > > the destination with a bad TCP or UDP checksum and get dropped. > > > > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --047d7bb03ed68a080204f08737f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Lloyd,
On Tue, Jan 21, 2014 at 10:38 PM, <l.wood@surrey.ac.uk> wrote:

> [Alia] Excellent - so if we can describe filtering on the correct fiel= ds to enforce this constrained scope, then the concerns about congestion co= ntrol may be alleviated.

For intended private use within a network, I think you'd be fine;= as with congestion, crossing the public Internet poses more of a problem. I= don't see how filtering comes in to enforce this.

> [Alia] Are you actually suggesting that it is highly likely for both t= he destination IP and UDP port to be simultaneously corrupted on a signific= ant flow of packets where each link already has a FCS covering the entire p= acket?

It is possible. The FCS only covers the link, and the zero UDP checks= um removes any check across the entire path.

> [Alia] We have vast existence proof that MPLS label stacks, also cover= ed only by link FCS, that this is not the case.

MPLS is scoped within the link between MPLS-aware devices. This tunne= lling use is along the entire path. The scope is different. How are MPLS di= scards or missent packets measured?

[Alia] I believe that you have not fully thought through how MPLS works. = =A0The top label certainly only has local significance between two adjacent= routers - but there is not merely one but many labels possible in an MPLS = label stack. =A0The other labels in the label stack are passed transparentl= y along. =A0 Perhaps this misunderstanding is part of why your insistence t= hat the link-layer FCS is ok for MPLS but not for UDP between routers is no= t coming through as a coherent argument.

[Alia] For example, in a typical L3VPN deployment, the = ingress PE places an MPLS label indicating the VPN or even outgoing prefix.= =A0Then the ingress PE adds a second MPLS label that indicates to its next= -hop that the packet is destined to the egress PE. =A0 The inner label is n= ot seen until the egress PE - and its value is not protected by anything bu= t the link-layer FCS.
=A0
[Alia] MPLS packets with an unknown label can be counted= and discarded. =A0 The number of packets sent into an RSVP-TE LSP can be c= ompared to the number received by the egress. =A0A number of years ago, the= re was actually a problem with hardware missending MPLS packets; as a resul= t the MPLS working group defined an LSR self-test mechanism ( RFC 4379) whi= ch allows checking of the LFIB.

> [Alia] Can you clearly articulate what you see as th= e threat scenario and the necessary scale and probability to be meaningful = here?

'Threat scenario' is language about mitigating a threat to yo= ur traffic. Here, your traffic with a zero UDP checksum poses the threat - = to everything else.

[Alia] If, to injec= t a bit of levity and culture, you are playing the Lorax who speaks for the= trees, you are speaking for all the other traffic, please explain how the = MPLS in UDP as a =A0tunnel (not transport) poses a threat. =A0 That is what= I would like you to explain.

[Alia] In the applicability suggested by Curtis, traffi= c with the port MPLS-in-UDP would be filtered. =A0If that isn't good en= ough, then that is because of the error rate you are concerned about. =A0Ad= ding in the destination address or source address would increase the number= of errors hitting the same packet that would be of concern. =A0Granted, if= one error occurs, I am willing to believe that multiple may happen. =A0But= now you are assuming that the error rate is high enough to cause problems.= =A0 What is that rate and what is the corresponding rate of traffic? =A0

[Alia] Next, for this to happen, the errors must not be= detected by either the link-layer FCS or memory chip checksums/validation.= =A0 If this were going to happen to UDP packets, it would also and already= be happening to MPLS label stacks. =A0

[Alia] I certainly heard some willingness for a SHOULD = on the UDP checksum - but that won't be possible on all hardware. =A0IF= there were convincing numbers and examples, instead of significant counter= -examples for the level of corruption you are suggesting, that might get gr= eater support. =A0Certainly the LFIB problem I mentioned that led to RFC 43= 79 got a lot of attention at the time!

Regards,
Alia

Probability of threat is non-zero, but unknown, because= networks are not instrumented for it. We have discussed Stone's result= s and other anecdotal evidence in this thread.

=A0

Lloyd Wood
http://about.me/llo= ydwood
________________________________________
From: Alia Atlas [akatlas@gmail.= com]
Sent: 22 January 2014 02:34
To: Wood L =A0Dr (Electronic Eng)
Cc: curtis@ipv6.occnc.com; joelja@bogus.com; mpls@ietf.org; Eggert, Lars
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp= -04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Lloyd,

On Tue, Jan 21, 2014 at 8:04 PM, <l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>> wrote:
Curtis,

the 'intended for use within a service provider' and not for mass u= se sounds reasonable,
and scoping in this way may also alleviate some congestion control concerns= .

[Alia] Excellent - so if we can describe filtering on the correct fields to= enforce this constrained scope, then the concerns about congestion control= may be alleviated.

But outgoing packet filtering, when you're trying to catch a corrupted = port,
and the port is not what you think it is? That's going to do a partial = job
of corrupted addresses in IPv6 at best. (v4 has header checksums,
ports in v4 and v6 are open to corruption sans UDP pseudo-header
check.)

[Alia] Are you actually suggesting that it is highly likely for both the de= stination IP and UDP port to be simultaneously corrupted on a significant f= low of packets where each link already has a FCS covering the entire packet= ?

[Alia] We have vast existence proof that MPLS label stacks, also covered on= ly by link FCS, that this is not the case. =A0Naturally the top label is ma= nipulated but the rest of the label stack is just passed through and not lo= oked at.

Not convinced by providers already blocking inbound traffic on a new port -=
particularly given discussion of handling entropy with varying ports
in another thread.

[Alia] For defense, isn't it a case of block ports by default and only = open the destination ports that are explicitly needed? =A0That's how fi= rewalls that I've seen work; perhaps others have a common counterexampl= e? =A0The entropy is put into the source port, which isn't relevant her= e.

So, I don't think filtering is a useful solution here to the problem po= sed
by zero UDP checksums. (An actual UDP checksum solves it, of course.)

[Alia] Can you clearly articulate what you see as the threat scenario and t= he necessary scale and probability to be meaningful here?

Regards,
Alia


regards

Lloyd Wood
http://about.me/llo= ydwood
________________________________________
From: Curtis Villamizar [curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com>]
Sent: 22 January 2014 00:24
To: Wood L =A0Dr (Electronic Eng)
Cc: curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com<= /a>>; lars@netapp.com<mailto:<= a href=3D"mailto:lars@netapp.com">lars@netapp.com>; stbryant@cisco.com<mailto:stbryant@cisco.com>; joelja@bogus.com<mailto:j= oelja@bogus.com>; mpls@ietf.org= <mailto:mpls@ietf.org>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp= -04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Lloyd,

Since MPLS over UDP is intended to be used within a provider, how
about if we recommend the following:

=A0 If no MPLS over UDP is intended to go outside a service provider,
=A0 then packet filters should be added to block traffic with the UDP
=A0 port number for MPLS over UDP to prevent misconfiguation or packet
=A0 error to cause MPLS over UDP packets to escape,

If either the IP destination address or the UDP destination port were
corrupted, then the packet would not leave. =A0The former because the
intended destination within the provider would get the packet. =A0The
latter because with the UDP port intact the provider's filter would
block it.

This would also prevent ordinary users from making use of MPLS over
UDP, which with its absense of congestion control is causing some
objections.

Providers would already be blocking traffic coming into their net with
this UDP port, particularly to their own infrastructure. =A0The filters
might cover only their own addresses allowing users to make use of
MPLS over UDP, or could block it entirely.

This is in line with Alia's suggestion that we define a profile of
intended use being for service providers internal use.

Curtis


In message <290E20B455C66743BE178C5C84F1240847E63346DE@E= XMB01CMS.surrey.ac.uk<mailto:290E20B455C66743BE178C5C84F12= 40847E63346DE@EXMB01CMS.surrey.ac.uk>>
l.wood@surrey= .ac.uk<mailto:l.wood@surrey.a= c.uk> writes:
>
> > When encapsulating in UDP, the UDP checksum might be zero but the= IP
> > checksum can still be filled in so the IP destination is checked<= br> >
> IPv6 doesn't have an IP header checksum. So with an error in the > header the packet can go anywhere.
>
>
> > Lack of UDP checksum should at worst mean that the destination ge= ts a
> > packet with a munged payload, pulls off the IP and UDP headers an= d
> > continues to forward
>
> ... or a munged header, and forwards to a different application on a d= ifferent port.
>
> See RFC 6936 section 3, which goes through the scenarios - =A0but play= s light
> on the side-effects. My beef is with:
>
> =A0 =A0A protocol or application that uses the zero UDP checksum metho= d must
> =A0 =A0ensure that the lack of checksum does not affect the protocol > =A0 =A0operation. =A0This includes being robust to receiving an uninte= nded
> =A0 =A0packet from another protocol or context following corruption of= a
> =A0 =A0destination or source address and/or port value. =A0It also inc= ludes
> =A0 =A0considering the need for additional implicit protection mechani= sms
> =A0 =A0required when using the payload of a UDP packet received with a= zero
> =A0 =A0checksum.
>
> Lack of a UDP checksum in one protocol can affect the operation of oth= er
> protocols minding their own business, until they receive and try to ha= ndle
> a corrupted packet from the first protocol because port or address is<= br> > corrupted. There are a lot of applications that presume that the data = they
> are given is error-free, and they presume that rogue data is not injec= ted into
> their conversation.
>
> I mean, if you're going to use a zero UDP checksum, and your appli= cation
> messes up and gives itself corrupt data, fine. More fool you. By analo= gy
> as a risk, it's like speeding while talking on a cellphone and cra= shing into a tree.
> But if your lack of checksum means you affect other applications who h= ave
> to now protect themselves against your data, you're effectively no= w crashing
> into and harming other people. They weren't in armoured cars to pr= otect
> against this? They had no right to be on the road!
>
> Zero UDP checksums are hit-and-run accidents waiting to happen.
>
> Lloyd Wood
> http://about.m= e/lloydwood
> ________________________________________
> From: Curtis Villamizar [curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com>]
> Sent: 21 January 2014 20:14
> To: Eggert, Lars
> Cc: Stewart Bryant; Wood L =A0Dr (Electronic Eng); curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com>; Joel Jaeggli; = mpls@ietf.org<mailto:mpls@ietf.org>
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-i= n-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
>
> In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com<ma= ilto:558= A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com>>
> "Eggert, Lars" writes:
>
> > Hi,
> >
> > On 2014-1-21, at 12:50, Stewart Bryant <stbryant@cisco.com<mailto:stbryant@cisco.com>> wrote:
> > > In terms of congestion and misdelivery it is interesting loo= king
> > > at the number of horses that are already bounding around
> > > in the paddock outside the stable:
> > >
> > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example.
> >
> > there is a big difference between encapsulation in IP and
> > encapsulation in UDP. Everything encapsulated with "obscure&= quot; IP
> > protocol numbers will get dropped by default at NATs and firewall= s,
> > whereas UDO traffic happily traverses them. The reach of UDP traf= fic
> > is much broader.
> >
> > Lars
>
>
> Stray UDP packets carrying MPLS getting to grandma's firewall is > really stretching the argument but ...
>
> When encapsulating in UDP, the UDP checksum might be zero but the IP > checksum can still be filled in so the IP destination is checked and > grandma need not worry about these packets. =A0But ...
>
> Grandma's firewall would block since there is no state established= on
> the firewall with the opposite port pair pattern. =A0But ...
>
> Even if it went through when the packet reached grandma's subnet t= he
> payload is junk bound to an unused port. =A0Maybe it hits grandma'= s DNS
> server and is interpreted as a badly malformed DNS request.
>
> So grandma seems safe from these bad packets.
>
> Lack of UDP checksum should at worst mean that the destination gets a<= br> > packet with a munged payload, pulls off the IP and UDP headers and
> continues to forward. =A0At worst has the wrong MPLS label and gets > blackholed in the provider network somewhere. =A0If it ends up at the<= br> > correct MPLS egress, if IP, the IP checksum is checked. =A0If a TCP or=
> UDP payload carried in that IP got munged the packet could end up at > the destination with a bad TCP or UDP checksum and get dropped.
>
> Curtis
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
ht= tps://www.ietf.org/mailman/listinfo/mpls


--047d7bb03ed68a080204f08737f1-- From l.wood@surrey.ac.uk Tue Jan 21 21:19:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A541A0229 for ; Tue, 21 Jan 2014 21:19:50 -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_42=0.6, 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 44o1rA30K7f3 for ; Tue, 21 Jan 2014 21:19:46 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.174]) by ietfa.amsl.com (Postfix) with ESMTP id BD1361A0030 for ; Tue, 21 Jan 2014 21:19:45 -0800 (PST) Received: from [195.245.230.131:50589] by server-14.bemta-3.messagelabs.com id 3B/B3-06105-0F45FD25; Wed, 22 Jan 2014 05:19:44 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-13.tower-78.messagelabs.com!1390367983!31112089!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23711 invoked from network); 22 Jan 2014 05:19:43 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-13.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 22 Jan 2014 05:19:43 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 22 Jan 2014 05:19:43 +0000 From: To: Date: Wed, 22 Jan 2014 05:19:41 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8XJwfui6H39/u1QaK+ZOXYu/XW8gABvhBw Message-ID: <290E20B455C66743BE178C5C84F1240847E63346E1@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> <201401220024.s0M0OwGW068768@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F1240847E63346E0@EXMB01CMS.surrey.ac.uk>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 05:19:50 -0000 > [Alia] I believe that you have not fully thought through how MPLS works. = The top label certainly only has local significance between two adjacent > routers - but there is not merely one but many labels possible in an MPLS= label stack. The other labels in the label stack are passed transparently= along. > Perhaps this misunderstanding is part of why your insistence that the lin= k-layer FCS is ok for MPLS but not for UDP between routers is not coming > through as a coherent argument. Where did I say FCS is ok for MPLS? The assumption in MPLS is that it is processed in a switch where the stack = is modified, or protected across the link. I personally don't view that as = particularly okay for MPLS - MPLS headers are not self-checking, if e.g. th= e end of stack bit gets corrupted, it's toast. But I'm not overly concerned= about MPLS networks trashing themselves. with MPLS-in-UDP, it is not processed in the routers, just carried. And wit= hout an end-to-end UDP checksum, there is no check for the UDP packet OR IT= S HEADERS across the entire scope of carriage. The problem is larger than f= or MPLS. The desire for fast processing with turning off the UDP checksum = makes this an IP problem, not an MPLS problem. To look at it another way, link layer FCS checks MPLS across the link. the = UDP checksum checks MPLS across the MPLS-in-UDP path. The proposal is that = UDP checksums are not needed across the scope of the path. So, surely by an= alogy we can run without link-layer checksums across the link! Let's turn o= ff Ethernet CRCs! IF you wouldn't turn off Ethernet CRCs, why would you tur= n off UDP checksums? > A number of years ago, there was actually a problem with hardware missend= ing MPLS packets; as a result the MPLS working group defined an LSR self-te= st mechanism ( RFC 4379) which allows checking of the LFIB. Yes, problems happen, and they have to be detected. First the problem is introduced, then it is measured. (MPLS ping is arguabl= y much the same. And wasn't MPLS fun before TTL?) Will we see measurements = for MPLS-in-UDP misdeliveries, or no measurements thanks to corruption not= being picked up zero UDP checksums? > please explain how the MPLS in UDP as a tunnel (not transport) poses a t= hreat. The desire to use a zero UDP checksum poses a threat to other ports and des= tinations as explained in RFC 6936 section 3. MPLS is UDP in itself is no threat, if a UDP checksum is used. That it's MP= LS being carried only matters to MPLS. It's that it's a zero UDP checksum, = which is desired for tunnelling efficiency. (I think this might have been m= entioned before.) > In the applicability suggested by Curtis, traffic with the port MPLS-in-= UDP would be filtered with a zero UDP checksum, the port could be corrupted to a different port, = as described in RFC 6936 section 3. How do you filter on the changed port? The error rate is debatable - no instrumentation, no measurements, even if = 0.00000001% or less, at high tunnel rates it adds up. But I can guarantee i= t's nonzero. > [Alia] Next, for this to happen, the errors must not be detected by eithe= r the link-layer FCS or memory chip checksums/validation. Which is why we have the end-to-end principle and end-to-end checks. A good way to not detect errors is to turn off error detection with e.g. tu= rning off the UDP checksum. > If this were going to happen to UDP packets, it would also and already b= e happening to MPLS label stacks. And it has happened to UDP packets, as described in Jonathan Stone's papers= and elsewhere. My bet is that it is already happening to MPLS label stacks, but is simply = not monitored or detected. > [Alia] I certainly heard some willingness for a SHOULD on the UDP checksu= m - but that won't be possible on all hardware. SHOULD implement congestion control and SHOULD implement the UDP checksum i= f crossing the public internet is likely the best we can hope for at this = point. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Alia Atlas [akatlas@gmail.com] Sent: 22 January 2014 04:04 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com; joelja@bogus.com; mpls@ietf.org; Eggert, Lars Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Lloyd, On Tue, Jan 21, 2014 at 10:38 PM, > wrote: > [Alia] Excellent - so if we can describe filtering on the correct fields = to enforce this constrained scope, then the concerns about congestion contr= ol may be alleviated. For intended private use within a network, I think you'd be fine;as with co= ngestion, crossing the public Internet poses more of a problem. I don't see= how filtering comes in to enforce this. > [Alia] Are you actually suggesting that it is highly likely for both the = destination IP and UDP port to be simultaneously corrupted on a significant= flow of packets where each link already has a FCS covering the entire pack= et? It is possible. The FCS only covers the link, and the zero UDP checksum rem= oves any check across the entire path. > [Alia] We have vast existence proof that MPLS label stacks, also covered = only by link FCS, that this is not the case. MPLS is scoped within the link between MPLS-aware devices. This tunnelling = use is along the entire path. The scope is different. How are MPLS discards= or missent packets measured? [Alia] I believe that you have not fully thought through how MPLS works. T= he top label certainly only has local significance between two adjacent rou= ters - but there is not merely one but many labels possible in an MPLS labe= l stack. The other labels in the label stack are passed transparently alon= g. Perhaps this misunderstanding is part of why your insistence that the = link-layer FCS is ok for MPLS but not for UDP between routers is not coming= through as a coherent argument. [Alia] For example, in a typical L3VPN deployment, the ingress PE places an= MPLS label indicating the VPN or even outgoing prefix. Then the ingress P= E adds a second MPLS label that indicates to its next-hop that the packet i= s destined to the egress PE. The inner label is not seen until the egress= PE - and its value is not protected by anything but the link-layer FCS. [Alia] MPLS packets with an unknown label can be counted and discarded. T= he number of packets sent into an RSVP-TE LSP can be compared to the number= received by the egress. A number of years ago, there was actually a probl= em with hardware missending MPLS packets; as a result the MPLS working grou= p defined an LSR self-test mechanism ( RFC 4379) which allows checking of t= he LFIB. > [Alia] Can you clearly articulate what you see as the threat scenario and= the necessary scale and probability to be meaningful here? 'Threat scenario' is language about mitigating a threat to your traffic. He= re, your traffic with a zero UDP checksum poses the threat - to everything = else. [Alia] If, to inject a bit of levity and culture, you are playing the Lorax= who speaks for the trees, you are speaking for all the other traffic, plea= se explain how the MPLS in UDP as a tunnel (not transport) poses a threat.= That is what I would like you to explain. [Alia] In the applicability suggested by Curtis, traffic with the port MPLS= -in-UDP would be filtered. If that isn't good enough, then that is because= of the error rate you are concerned about. Adding in the destination addr= ess or source address would increase the number of errors hitting the same = packet that would be of concern. Granted, if one error occurs, I am willin= g to believe that multiple may happen. But now you are assuming that the e= rror rate is high enough to cause problems. What is that rate and what is= the corresponding rate of traffic? [Alia] Next, for this to happen, the errors must not be detected by either = the link-layer FCS or memory chip checksums/validation. If this were goin= g to happen to UDP packets, it would also and already be happening to MPLS = label stacks. [Alia] I certainly heard some willingness for a SHOULD on the UDP checksum = - but that won't be possible on all hardware. IF there were convincing num= bers and examples, instead of significant counter-examples for the level of= corruption you are suggesting, that might get greater support. Certainly = the LFIB problem I mentioned that led to RFC 4379 got a lot of attention at= the time! Regards, Alia Probability of threat is non-zero, but unknown, because networks are not in= strumented for it. We have discussed Stone's results and other anecdotal ev= idence in this thread. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Alia Atlas [akatlas@gmail.com] Sent: 22 January 2014 02:34 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com; joelja@bogus.com; mpls@ietf.org; Eggert, Lars Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Lloyd, On Tue, Jan 21, 2014 at 8:04 PM, >> wrote: Curtis, the 'intended for use within a service provider' and not for mass use sound= s reasonable, and scoping in this way may also alleviate some congestion control concerns= . [Alia] Excellent - so if we can describe filtering on the correct fields to= enforce this constrained scope, then the concerns about congestion control= may be alleviated. But outgoing packet filtering, when you're trying to catch a corrupted port= , and the port is not what you think it is? That's going to do a partial job of corrupted addresses in IPv6 at best. (v4 has header checksums, ports in v4 and v6 are open to corruption sans UDP pseudo-header check.) [Alia] Are you actually suggesting that it is highly likely for both the de= stination IP and UDP port to be simultaneously corrupted on a significant f= low of packets where each link already has a FCS covering the entire packet= ? [Alia] We have vast existence proof that MPLS label stacks, also covered on= ly by link FCS, that this is not the case. Naturally the top label is mani= pulated but the rest of the label stack is just passed through and not look= ed at. Not convinced by providers already blocking inbound traffic on a new port - particularly given discussion of handling entropy with varying ports in another thread. [Alia] For defense, isn't it a case of block ports by default and only open= the destination ports that are explicitly needed? That's how firewalls th= at I've seen work; perhaps others have a common counterexample? The entrop= y is put into the source port, which isn't relevant here. So, I don't think filtering is a useful solution here to the problem posed by zero UDP checksums. (An actual UDP checksum solves it, of course.) [Alia] Can you clearly articulate what you see as the threat scenario and t= he necessary scale and probability to be meaningful here? Regards, Alia regards Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com>] Sent: 22 January 2014 00:24 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com>; lars@netapp.com>; stbryant@cisco.com<= mailto:stbryant@cisco.com>>; joelja@bogus.com>; mpls@ietf.org> Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Lloyd, Since MPLS over UDP is intended to be used within a provider, how about if we recommend the following: If no MPLS over UDP is intended to go outside a service provider, then packet filters should be added to block traffic with the UDP port number for MPLS over UDP to prevent misconfiguation or packet error to cause MPLS over UDP packets to escape, If either the IP destination address or the UDP destination port were corrupted, then the packet would not leave. The former because the intended destination within the provider would get the packet. The latter because with the UDP port intact the provider's filter would block it. This would also prevent ordinary users from making use of MPLS over UDP, which with its absense of congestion control is causing some objections. Providers would already be blocking traffic coming into their net with this UDP port, particularly to their own infrastructure. The filters might cover only their own addresses allowing users to make use of MPLS over UDP, or could block it entirely. This is in line with Alia's suggestion that we define a profile of intended use being for service providers internal use. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.= uk>> l.wood@surrey.ac.uk> writes: > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > checksum can still be filled in so the IP destination is checked > > IPv6 doesn't have an IP header checksum. So with an error in the > header the packet can go anywhere. > > > > Lack of UDP checksum should at worst mean that the destination gets a > > packet with a munged payload, pulls off the IP and UDP headers and > > continues to forward > > ... or a munged header, and forwards to a different application on a diff= erent port. > > See RFC 6936 section 3, which goes through the scenarios - but plays lig= ht > on the side-effects. My beef is with: > > A protocol or application that uses the zero UDP checksum method must > ensure that the lack of checksum does not affect the protocol > operation. This includes being robust to receiving an unintended > packet from another protocol or context following corruption of a > destination or source address and/or port value. It also includes > considering the need for additional implicit protection mechanisms > required when using the payload of a UDP packet received with a zero > checksum. > > Lack of a UDP checksum in one protocol can affect the operation of other > protocols minding their own business, until they receive and try to handl= e > a corrupted packet from the first protocol because port or address is > corrupted. There are a lot of applications that presume that the data the= y > are given is error-free, and they presume that rogue data is not injected= into > their conversation. > > I mean, if you're going to use a zero UDP checksum, and your application > messes up and gives itself corrupt data, fine. More fool you. By analogy > as a risk, it's like speeding while talking on a cellphone and crashing i= nto a tree. > But if your lack of checksum means you affect other applications who have > to now protect themselves against your data, you're effectively now crash= ing > into and harming other people. They weren't in armoured cars to protect > against this? They had no right to be on the road! > > Zero UDP checksums are hit-and-run accidents waiting to happen. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com>] > Sent: 21 January 2014 20:14 > To: Eggert, Lars > Cc: Stewart Bryant; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com>; Joel Jaeggli; mpls@ietf.org> > Subject: Re: [mpls] Last Call: (Encapsula= ting MPLS in UDP) to Proposed Standard > > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com>> > "Eggert, Lars" writes: > > > Hi, > > > > On 2014-1-21, at 12:50, Stewart Bryant >> wrote= : > > > In terms of congestion and misdelivery it is interesting looking > > > at the number of horses that are already bounding around > > > in the paddock outside the stable: > > > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > > > there is a big difference between encapsulation in IP and > > encapsulation in UDP. Everything encapsulated with "obscure" IP > > protocol numbers will get dropped by default at NATs and firewalls, > > whereas UDO traffic happily traverses them. The reach of UDP traffic > > is much broader. > > > > Lars > > > Stray UDP packets carrying MPLS getting to grandma's firewall is > really stretching the argument but ... > > When encapsulating in UDP, the UDP checksum might be zero but the IP > checksum can still be filled in so the IP destination is checked and > grandma need not worry about these packets. But ... > > Grandma's firewall would block since there is no state established on > the firewall with the opposite port pair pattern. But ... > > Even if it went through when the packet reached grandma's subnet the > payload is junk bound to an unused port. Maybe it hits grandma's DNS > server and is interpreted as a badly malformed DNS request. > > So grandma seems safe from these bad packets. > > Lack of UDP checksum should at worst mean that the destination gets a > packet with a munged payload, pulls off the IP and UDP headers and > continues to forward. At worst has the wrong MPLS label and gets > blackholed in the provider network somewhere. If it ends up at the > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > UDP payload carried in that IP got munged the packet could end up at > the destination with a bad TCP or UDP checksum and get dropped. > > Curtis _______________________________________________ mpls mailing list mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls From agmalis@gmail.com Tue Jan 21 22:44:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6779B1A0296 for ; Tue, 21 Jan 2014 22:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iMlTMXZmS32 for ; Tue, 21 Jan 2014 22:44:07 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD241A028A for ; Tue, 21 Jan 2014 22:44:07 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id c9so8391076qcz.27 for ; Tue, 21 Jan 2014 22:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A2K1jGaT30dB+LjV/G0SPv+yC8YiImwKzOntbLO+y2o=; b=t8ITYL+aSDzWDv3VNdqLZEh+Czk4v8XGp6IG+674/cQA5oIXbWSTCl+tlWIh7pxkHh HbG+YAKbSIL7tZ2xhksXHJgZg6In/LsienRbTtZLZgp2E2F+r+0MFTAT6dwWTsi2XKRf lcYaUYOuVpIfRpPTPzwwrfk8Q1TzeYCMUSlTGlFntSVt/G35tjfQS3WqQQe3wg8ua8Le CrV9oYBAfUFkTqtXWXy0WiOQGJ599SsfVQcST7p0iIyHa+4/nE7B9t+6GjRNB8SclBWJ 6UrPhEQIlqYI6NH7LCMTT7tOUrPMLbo6addFfQ66hTHbcsGKF86TT/5aP2kduFZQ43Td /jOA== X-Received: by 10.140.102.69 with SMTP id v63mr41543942qge.5.1390373046563; Tue, 21 Jan 2014 22:44:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.120.130 with HTTP; Tue, 21 Jan 2014 22:43:46 -0800 (PST) In-Reply-To: References: <52DE4BB7.80408@pi.nu> From: "Andrew G. Malis" Date: Tue, 21 Jan 2014 22:43:46 -0800 Message-ID: To: "Kamran Raza (skraza)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org" Subject: Re: [mpls] Short working group last call on draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 06:44:11 -0000 The changes are an improvement. Please publish. Cheers, Andy On Tue, Jan 21, 2014 at 6:22 AM, Kamran Raza (skraza) wrote: > > FYR, the main changes in this rev are: > > - This document now covers all the currently defined FECs and states their > label adv mode; > - The doc title is renamed to "Label Advertisement Discipline for LDP > FECs"; > - Cleanup/removal of introductory text > - Update to RFC 5036 > - Specification of mode for all standardized FEC types and updates to > their respective RFCs > - IANA considerations: Add a new column "Label Advertisement Discipline" > in LDP FEC Type namespace > > > Thanks for your review, > -- > Kamran > (On behalf of I.D. authors) > > On 2014-01-21 5:28 AM, "Loa Andersson" wrote: > >>Working Group, >> >>We did a working group last call on draft-ietf-mpls-ldp-applicability- >>label-adv in March 2013. The draft was updated according to the wglc >>comments and Publication Requested. >> >>The AD evaluation and the discussion with the authors resultetd in >>changes that makes it reasonable to verify that the working group are >>comfortable with the changes that has been doen. >> >>Please send your comments to the working group mailing list >>(mpls@ietf.org). In this case silence will be interpreted as >>agreement. >> >>This working group last call ends January 28th, 2014. >> >>/Loa >>mpls wg co-chair >> >> >>-- >> >> >>Loa Andersson email: loa@mail01.huawei.com >>Senior MPLS Expert loa@pi.nu >>Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lars@netapp.com Tue Jan 21 23:51:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793F21A0355 for ; Tue, 21 Jan 2014 23:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 OqEg-nJkEFxW for ; Tue, 21 Jan 2014 23:51:38 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 12F481A01C8 for ; Tue, 21 Jan 2014 23:51:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,698,1384329600"; d="asc'?scan'208";a="97424697" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 21 Jan 2014 23:51:37 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 23:51:37 -0800 From: "Eggert, Lars" To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPFuVZZzPPQlRcgk6ua2U45NfiYJqQ5eGA Date: Wed, 22 Jan 2014 07:51:37 +0000 Message-ID: <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> In-Reply-To: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_A0A4435E-B289-48A2-BBFC-F40094C16E2F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 07:51:40 -0000 --Apple-Mail=_A0A4435E-B289-48A2-BBFC-F40094C16E2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is not at all the argument I am making. My emails have not touched = at all on the issue of zero checksums. My point is that UDP encapsulation changes the potential *reach* of = congestion-uncontrolled traffic that was otherwise limited to L2 = networks. Lars On 2014-1-21, at 21:14, Curtis Villamizar wrote: >=20 > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> > "Eggert, Lars" writes: >=20 >> Hi, >>=20 >> On 2014-1-21, at 12:50, Stewart Bryant wrote: >>> In terms of congestion and misdelivery it is interesting looking >>> at the number of horses that are already bounding around >>> in the paddock outside the stable: >>>=20 >>> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. >>=20 >> there is a big difference between encapsulation in IP and >> encapsulation in UDP. Everything encapsulated with "obscure" IP >> protocol numbers will get dropped by default at NATs and firewalls, >> whereas UDO traffic happily traverses them. The reach of UDP traffic >> is much broader. >>=20 >> Lars >=20 >=20 > Stray UDP packets carrying MPLS getting to grandma's firewall is > really stretching the argument but ... >=20 > When encapsulating in UDP, the UDP checksum might be zero but the IP > checksum can still be filled in so the IP destination is checked and > grandma need not worry about these packets. But ... >=20 > Grandma's firewall would block since there is no state established on > the firewall with the opposite port pair pattern. But ... >=20 > Even if it went through when the packet reached grandma's subnet the > payload is junk bound to an unused port. Maybe it hits grandma's DNS > server and is interpreted as a badly malformed DNS request. >=20 > So grandma seems safe from these bad packets. >=20 > Lack of UDP checksum should at worst mean that the destination gets a > packet with a munged payload, pulls off the IP and UDP headers and > continues to forward. At worst has the wrong MPLS label and gets > blackholed in the provider network somewhere. If it ends up at the > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > UDP payload carried in that IP got munged the packet could end up at > the destination with a bad TCP or UDP checksum and get dropped. >=20 > Curtis --Apple-Mail=_A0A4435E-B289-48A2-BBFC-F40094C16E2F 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----- iQCVAwUBUt94i9ZcnpRveo1xAQIOHwP/V4t9XykL1Ni9djlW/s5jxgpzPLFvA1Xb 7oseLZHZ79rxILcVP5Bp8AaEWj9Zi5ufGJQ6YQ3bWxWkiOjNiCC3WypAhUoPUAz+ CXT4Z0N/YkHmaXcGNDovC0M1NEEhSDDCO8NoF7vLSjppLJftfbDP6YmUx5dPtvcz WqFHkjQM89c= =Mg+V -----END PGP SIGNATURE----- --Apple-Mail=_A0A4435E-B289-48A2-BBFC-F40094C16E2F-- From stbryant@cisco.com Wed Jan 22 02:01:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6663B1A02C2 for ; Wed, 22 Jan 2014 02:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 93_t1c86EQ7c for ; Wed, 22 Jan 2014 02:01:43 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id E99D21A0099 for ; Wed, 22 Jan 2014 02:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=190; q=dns/txt; s=iport; t=1390384903; x=1391594503; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b2p1RjYs7dpPlh/pcBjpOGlRpn+ELzHPTYKNC5a5lzA=; b=LDhbKGdtNwPuwdHsrIM0L9cmKt8axbkGt5SfpsDnSNnMXWpgoP8ArmiN Zu9UBTIaZn+dH2+nk7MYMUA04Uy38LT5QILVB1txLZhAhTokDVacMSPi0 D2Lg04akB+I5teGl6PlSPdBneObBdNrKSi9aYc6dHKbLcUGWh6TwpcDxh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAKuW31KQ/khL/2dsb2JhbABbDoJ9jVKvF4ERFnSCJQEBAQQ4QAEQCxgJFgQLCQMCAQIBRQcMAQUCAQGIAcFCF458B4Q4AQOYIpIYgW9/Pw X-IronPort-AV: E=Sophos;i="4.95,698,1384300800"; d="scan'208";a="3331871" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 22 Jan 2014 10:01:40 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0MA1eEc019881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 10:01:40 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0MA1aZ3019004; Wed, 22 Jan 2014 10:01:36 GMT Message-ID: <52DF9700.7040707@cisco.com> Date: Wed, 22 Jan 2014 10:01:36 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, curtis@ipv6.occnc.com References: Your message of "Tue, 21 Jan 2014 21:28:30 +0000." <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk>, <201401220024.s0M0OwGW068768@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:01:44 -0000 On 22/01/2014 01:04, l.wood@surrey.ac.uk wrote: > Curtis, > > the 'intended for use within a service provider' Presumable within an SP or an adjacent set of co-operating SPs Stewart From stbryant@cisco.com Wed Jan 22 02:09:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF341A02D0 for ; Wed, 22 Jan 2014 02:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 iOkqm9Q_RxCu for ; Wed, 22 Jan 2014 02:09:03 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 02C0D1A02C2 for ; Wed, 22 Jan 2014 02:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=881; q=dns/txt; s=iport; t=1390385340; x=1391594940; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DKh1cOu4uImSRT/VJVgHNSTXmN3ucltgnCh+zO8JDy4=; b=eoPblhno8uUB21E+KWJWdB6qyvSGyUYYbtZr8bT5HeQ/yz3hL5Awn+Ou SUJau3E+4SLNKoXnH8dWAT/+Ansenot+8YADtcF951WYJJS7NNa0v8irs FdyI3kXsd+S5/CCBwLMXk42EWO3uZgax19uVLgEmgr6O7wasIYbjzT2FM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAKCX31KQ/khN/2dsb2JhbABbgwu5ZIMFgREWdIIlAQEBBDhAARALGAkWBAsJAwIBAgFFBgEMAQcBAYgBwUgXjiRYB4Q4AQOYIpIYgW+BPoFo X-IronPort-AV: E=Sophos;i="4.95,698,1384300800"; d="scan'208";a="3332408" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 22 Jan 2014 10:08:58 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0MA8wmZ004158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 10:08:58 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0MA8u22019306; Wed, 22 Jan 2014 10:08:56 GMT Message-ID: <52DF98B8.3050208@cisco.com> Date: Wed, 22 Jan 2014 10:08:56 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Eggert, Lars" , "curtis@ipv6.occnc.com" References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> In-Reply-To: <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:09:05 -0000 On 22/01/2014 07:51, Eggert, Lars wrote: > This is not at all the argument I am making. My emails have not touched at all on the issue of zero checksums. > > My point is that UDP encapsulation changes the potential *reach* of congestion-uncontrolled traffic that was otherwise limited to L2 networks. > > Lars How about if text is introduced recommending the use of an OAM between tunnel endpoints that monitors packet loss. The tunnel endpoints need to know if the tunnel is broken anyway and on hitting a loss threshold they can alarm, redirect the traffic, or shutdown, depending on configuration, topology and the needs of the operator. You probably also need pro-active CV to make the whole system work. This many not necessarily be fast or elegant, but if there is significant misdelivery or congestion loss, traffic will eventually cease. Stewart From lars@netapp.com Wed Jan 22 02:12:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A6E1A02C2 for ; Wed, 22 Jan 2014 02:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.437 X-Spam-Level: X-Spam-Status: No, score=-7.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 9NsNMrForf5A for ; Wed, 22 Jan 2014 02:12:24 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4E61D1A0099 for ; Wed, 22 Jan 2014 02:12:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,698,1384329600"; d="asc'?scan'208";a="67200987" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx2-out.netapp.com with ESMTP; 22 Jan 2014 02:12:24 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 02:12:24 -0800 From: "Eggert, Lars" To: Stewart Bryant Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPFuVZZzPPQlRcgk6ua2U45NfiYJqQ5eGAgAAmXACAAAD1AA== Date: Wed, 22 Jan 2014 10:12:23 +0000 Message-ID: <84EEC1E1-88D0-4B12-B01C-598FC3DE465C@netapp.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <52DF98B8.3050208@cisco.com> In-Reply-To: <52DF98B8.3050208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_D48C063F-ECA7-4189-847B-B9B13D520B6E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:12:26 -0000 --Apple-Mail=_D48C063F-ECA7-4189-847B-B9B13D520B6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2014-1-22, at 11:08, Stewart Bryant wrote: > How about if text is introduced recommending the use of an > OAM between tunnel endpoints that monitors packet loss. >=20 > The tunnel endpoints need to know if the tunnel is broken > anyway and on hitting a loss threshold they can alarm, > redirect the traffic, or shutdown, depending on configuration, > topology and the needs of the operator. >=20 > You probably also need pro-active CV to make the whole > system work. >=20 > This many not necessarily be fast or elegant, but if there > is significant misdelivery or congestion loss, traffic will > eventually cease. That seems like a viable approach, coupled with some applicability = statement (Alia made some good suggestions). Some more details would be = good to see, however. Lars --Apple-Mail=_D48C063F-ECA7-4189-847B-B9B13D520B6E 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----- iQCVAwUBUt+ZhtZcnpRveo1xAQJF+gP+NsiRG1FyCMVtOc0bxFOnpuU/xRWSzx9v ZiiLbKjZHNgUHAos+d4v9c3Bj4pToEbdEN3dJgVoplP2E/80IgrR3wIcb568l3g8 OHfLkLYUp4LlZ4U0aK78uNDALz7/TNEFuKlclz4E2vMT1+ibRxrPcMlWNjLdIpQC ipehZb5OiPw= =bKjK -----END PGP SIGNATURE----- --Apple-Mail=_D48C063F-ECA7-4189-847B-B9B13D520B6E-- From xuxiaohu@huawei.com Wed Jan 22 02:12:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D6F1A0422 for ; Wed, 22 Jan 2014 02:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 9TpFUUkR1gz4 for ; Wed, 22 Jan 2014 02:12:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 171B01A041E for ; Wed, 22 Jan 2014 02:12:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAH39278; Wed, 22 Jan 2014 10:12:32 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 10:12:15 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 10:12:27 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 18:12:23 +0800 From: Xuxiaohu To: "Eggert, Lars" , "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g Date: Wed, 22 Jan 2014 10:12:22 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> In-Reply-To: <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Joel Jaeggli , "mpls@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg?= =?gb2312?b?dG8gUHJvcG9zZWQgU3RhbmRhcmQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:12:39 -0000 SGkgYWxsLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMuDQoNCkkgd29uZGVyIHdo ZXRoZXIgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIE9LIHRvIHlvdToNCg0KU2luY2UgdGhlIE1QTFMt aW4tVURQIGVuY2Fwc3VsYXRpb24gY2F1c2VzIE1QTFMgcGFja2V0cyB0byBiZSBmb3J3YXJkZWQg dGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGd1aWRlbGluZXMg Zm9yIFVEUCB0dW5uZWxzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuMyBvZiBbUkZDNTQwNV0g U0hPVUxEIGJlIGZvbGxvd2VkLiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5IGEgbnVtYmVy IG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMgcGF5bG9hZHMuIFdoZW4gYW4gVURQIHR1bm5lbCBp cyB1c2VkIGZvciBNUExTIHBheWxvYWQgdHJhZmZpYyB0aGF0IGlzIGtub3duIGF0IGNvbmZpZ3Vy YXRpb24gdGltZSB0byBiZSBJUC1iYXNlZCBhbmQgY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUg VURQIHR1bm5lbCBTSE9VTEQgTk9UIGVtcGxveSBpdHMgb3duIGNvbmdlc3Rpb24gY29udHJvbCBt ZWNoYW5pc20sIGJlY2F1c2UgY29uZ2VzdGlvbiBsb3NzZXMgb2YgdHVubmVsZWQgdHJhZmZpYyB3 aWxsIHRyaWdnZXIgYW4gY29uZ2VzdGlvbiByZXNwb25zZSBhdCB0aGUgb3JpZ2luYWwgc2VuZGVy cyBvZiB0aGUgdHVubmVsZWQgdHJhZmZpYy4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9y IE1QTFMgcGF5bG9hZCB0cmFmZmljIHRoYXQgaXMga25vd24gYXQgY29uZmlndXJhdGlvbiB0aW1l IG5vdCB0byBiZSBJUC1iYXNlZCBhbmQgY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUgVURQIHR1 bm5lbCBTSE9VTEQgZW1wbG95IGFuIGFwcHJvcHJpYXRlIGNvbmdlc3Rpb24gY29udHJvbCBtZWNo YW5pc20gYXMgZGVzY3JpYmVkIGluIFtSRkMzOTg1XS4gTm90ZSB0aGF0IGl0IFNUUk9OR0xZIFJF Q09NTUVOREVEIHRvIGRlcGxveSBzdWNoIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9neSBvbmx5IHdp dGhpbiBhIFNQIG5ldHdvcmsgb3IgbmV0d29ya3Mgb2YgYW4gYWRqYWNlbnQgc2V0IG9mIGNvLW9w ZXJhdGluZyBTUHMsIHJhdGhlciB0aGFuIG92ZXIgdGhlIEludGVybmV0LiBGdXJ0aGVybW9yZSwg cGFja2V0IGZpbHRlcnMgc2hvdWxkIGJlIGFkZGVkIHRvIGJsb2NrIHRyYWZmaWMgd2l0aCB0aGUg VURQIHBvcnQgbnVtYmVyIGZvciBNUExTIG92ZXIgVURQIHRvIHByZXZlbnQgTVBMUyBvdmVyIFVE UCBwYWNrZXRzIHRvIGVzY2FwZSBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmtzIGR1 ZSB0byBtaXNjb25maWd1YXRpb24gb3IgcGFja2V0IGVycm9ycy4NCg0KQmVzdCByZWdhcmRzLA0K WGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBscyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBFZ2dlcnQsIExhcnMNCj4gt6LLzcqxvOQ6IDIwMTTE 6jHUwjIyyNUgMTU6NTINCj4gytW8/sjLOiBjdXJ0aXNAaXB2Ni5vY2NuYy5jb20NCj4gs63LzTog Sm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+INb3zOI6IFJlOiBbbXBsc10gTGFzdCBDYWxs OiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMNCj4g aW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gVGhpcyBpcyBub3QgYXQgYWxsIHRo ZSBhcmd1bWVudCBJIGFtIG1ha2luZy4gTXkgZW1haWxzIGhhdmUgbm90IHRvdWNoZWQgYXQgYWxs DQo+IG9uIHRoZSBpc3N1ZSBvZiB6ZXJvIGNoZWNrc3Vtcy4NCj4gDQo+IE15IHBvaW50IGlzIHRo YXQgVURQIGVuY2Fwc3VsYXRpb24gY2hhbmdlcyB0aGUgcG90ZW50aWFsICpyZWFjaCogb2YNCj4g Y29uZ2VzdGlvbi11bmNvbnRyb2xsZWQgdHJhZmZpYyB0aGF0IHdhcyBvdGhlcndpc2UgbGltaXRl ZCB0byBMMiBuZXR3b3Jrcy4NCj4gDQo+IExhcnMNCj4gDQo+IE9uIDIwMTQtMS0yMSwgYXQgMjE6 MTQsIEN1cnRpcyBWaWxsYW1pemFyIDxjdXJ0aXNAaXB2Ni5vY2NuYy5jb20+IHdyb3RlOg0KPiAN Cj4gPg0KPiA+IEluIG1lc3NhZ2UgPDU1OEExNUE5LTIwNEEtNDQ0Ny05MjNDLTU4REMyQTNDRUQ4 QUBuZXRhcHAuY29tPg0KPiA+ICJFZ2dlcnQsIExhcnMiIHdyaXRlczoNCj4gPg0KPiA+PiBIaSwN Cj4gPj4NCj4gPj4gT24gMjAxNC0xLTIxLCBhdCAxMjo1MCwgU3Rld2FydCBCcnlhbnQgPHN0YnJ5 YW50QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+PiBJbiB0ZXJtcyBvZiBjb25nZXN0aW9uIGFuZCBt aXNkZWxpdmVyeSBpdCBpcyBpbnRlcmVzdGluZyBsb29raW5nIGF0DQo+ID4+PiB0aGUgbnVtYmVy IG9mIGhvcnNlcyB0aGF0IGFyZSBhbHJlYWR5IGJvdW5kaW5nIGFyb3VuZCBpbiB0aGUgcGFkZG9j aw0KPiA+Pj4gb3V0c2lkZSB0aGUgc3RhYmxlOg0KPiA+Pj4NCj4gPj4+IElQIHR5cGVzOiA0NyAo R1JFKSBhbmQgMTM3IChNUExTLWluLUlQKSBmb3IgZXhhbXBsZS4NCj4gPj4NCj4gPj4gdGhlcmUg aXMgYSBiaWcgZGlmZmVyZW5jZSBiZXR3ZWVuIGVuY2Fwc3VsYXRpb24gaW4gSVAgYW5kDQo+ID4+ IGVuY2Fwc3VsYXRpb24gaW4gVURQLiBFdmVyeXRoaW5nIGVuY2Fwc3VsYXRlZCB3aXRoICJvYnNj dXJlIiBJUA0KPiA+PiBwcm90b2NvbCBudW1iZXJzIHdpbGwgZ2V0IGRyb3BwZWQgYnkgZGVmYXVs dCBhdCBOQVRzIGFuZCBmaXJld2FsbHMsDQo+ID4+IHdoZXJlYXMgVURPIHRyYWZmaWMgaGFwcGls eSB0cmF2ZXJzZXMgdGhlbS4gVGhlIHJlYWNoIG9mIFVEUCB0cmFmZmljDQo+ID4+IGlzIG11Y2gg YnJvYWRlci4NCj4gPj4NCj4gPj4gTGFycw0KPiA+DQo+ID4NCj4gPiBTdHJheSBVRFAgcGFja2V0 cyBjYXJyeWluZyBNUExTIGdldHRpbmcgdG8gZ3JhbmRtYSdzIGZpcmV3YWxsIGlzDQo+ID4gcmVh bGx5IHN0cmV0Y2hpbmcgdGhlIGFyZ3VtZW50IGJ1dCAuLi4NCj4gPg0KPiA+IFdoZW4gZW5jYXBz dWxhdGluZyBpbiBVRFAsIHRoZSBVRFAgY2hlY2tzdW0gbWlnaHQgYmUgemVybyBidXQgdGhlIElQ DQo+ID4gY2hlY2tzdW0gY2FuIHN0aWxsIGJlIGZpbGxlZCBpbiBzbyB0aGUgSVAgZGVzdGluYXRp b24gaXMgY2hlY2tlZCBhbmQNCj4gPiBncmFuZG1hIG5lZWQgbm90IHdvcnJ5IGFib3V0IHRoZXNl IHBhY2tldHMuICBCdXQgLi4uDQo+ID4NCj4gPiBHcmFuZG1hJ3MgZmlyZXdhbGwgd291bGQgYmxv Y2sgc2luY2UgdGhlcmUgaXMgbm8gc3RhdGUgZXN0YWJsaXNoZWQgb24NCj4gPiB0aGUgZmlyZXdh bGwgd2l0aCB0aGUgb3Bwb3NpdGUgcG9ydCBwYWlyIHBhdHRlcm4uICBCdXQgLi4uDQo+ID4NCj4g PiBFdmVuIGlmIGl0IHdlbnQgdGhyb3VnaCB3aGVuIHRoZSBwYWNrZXQgcmVhY2hlZCBncmFuZG1h J3Mgc3VibmV0IHRoZQ0KPiA+IHBheWxvYWQgaXMganVuayBib3VuZCB0byBhbiB1bnVzZWQgcG9y dC4gIE1heWJlIGl0IGhpdHMgZ3JhbmRtYSdzIEROUw0KPiA+IHNlcnZlciBhbmQgaXMgaW50ZXJw cmV0ZWQgYXMgYSBiYWRseSBtYWxmb3JtZWQgRE5TIHJlcXVlc3QuDQo+ID4NCj4gPiBTbyBncmFu ZG1hIHNlZW1zIHNhZmUgZnJvbSB0aGVzZSBiYWQgcGFja2V0cy4NCj4gPg0KPiA+IExhY2sgb2Yg VURQIGNoZWNrc3VtIHNob3VsZCBhdCB3b3JzdCBtZWFuIHRoYXQgdGhlIGRlc3RpbmF0aW9uIGdl dHMgYQ0KPiA+IHBhY2tldCB3aXRoIGEgbXVuZ2VkIHBheWxvYWQsIHB1bGxzIG9mZiB0aGUgSVAg YW5kIFVEUCBoZWFkZXJzIGFuZA0KPiA+IGNvbnRpbnVlcyB0byBmb3J3YXJkLiAgQXQgd29yc3Qg aGFzIHRoZSB3cm9uZyBNUExTIGxhYmVsIGFuZCBnZXRzDQo+ID4gYmxhY2tob2xlZCBpbiB0aGUg cHJvdmlkZXIgbmV0d29yayBzb21ld2hlcmUuICBJZiBpdCBlbmRzIHVwIGF0IHRoZQ0KPiA+IGNv cnJlY3QgTVBMUyBlZ3Jlc3MsIGlmIElQLCB0aGUgSVAgY2hlY2tzdW0gaXMgY2hlY2tlZC4gIElm IGEgVENQIG9yDQo+ID4gVURQIHBheWxvYWQgY2FycmllZCBpbiB0aGF0IElQIGdvdCBtdW5nZWQg dGhlIHBhY2tldCBjb3VsZCBlbmQgdXAgYXQNCj4gPiB0aGUgZGVzdGluYXRpb24gd2l0aCBhIGJh ZCBUQ1Agb3IgVURQIGNoZWNrc3VtIGFuZCBnZXQgZHJvcHBlZC4NCj4gPg0KPiA+IEN1cnRpcw0K DQo= From lars@netapp.com Wed Jan 22 02:22:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6541A041E for ; Wed, 22 Jan 2014 02:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.437 X-Spam-Level: X-Spam-Status: No, score=-7.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 cKa0Nph7-2MU for ; Wed, 22 Jan 2014 02:22:37 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C76A51A02C2 for ; Wed, 22 Jan 2014 02:22:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,698,1384329600"; d="asc'?scan'208";a="138376234" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 22 Jan 2014 02:22:37 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 02:22:37 -0800 From: "Eggert, Lars" To: Xuxiaohu Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPFuVZZzPPQlRcgk6ua2U45NfiYJqQ5eGAgAAnUQCAAALZgA== Date: Wed, 22 Jan 2014 10:22:36 +0000 Message-ID: References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_284C6D2D-E30E-41B4-B7BA-E4CB74F1B323"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:22:39 -0000 --Apple-Mail=_284C6D2D-E30E-41B4-B7BA-E4CB74F1B323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi, On 2014-1-22, at 11:12, Xuxiaohu wrote: > I wonder whether the following text is OK to you: >=20 > Since the MPLS-in-UDP encapsulation causes MPLS packets to be = forwarded through "UDP tunnels", the congestion control guidelines for = UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. = Specifically, MPLS can carry a number of different protocols as = payloads. When an UDP tunnel is used for MPLS payload traffic that is = known at configuration time to be IP-based and congestion-controlled, = the UDP tunnel SHOULD NOT employ its own congestion control mechanism, = because congestion losses of tunneled traffic will trigger an congestion = response at the original senders of the tunneled traffic. When an UDP = tunnel is used for MPLS payload traffic that is known at configuration = time not to be IP-based and congestion-controlled, the UDP tunnel SHOULD = employ an appropriate congestion control mechanism as described in = [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such = encapsulation technology only within a SP network or networks of an = adjacent set of co-operating SPs, rather than over the Internet. = Furthermore, packet filters should be added to block traffic with the = UDP port number for MPLS over UDP to prevent MPLS over UDP packets to = escape from the service provider networks due to misconfiguation or = packet errors. I think it would be better to describe the OAM control loop in (some) = more detail, rather than pointing to RFC3985, which doesn't have a whole = lot of detail either. Also because the adding of firewall rules requires = an OAM hook. Since STRONGLY RECOMMENDED is not an RFC2119 term and RECOMMENDED is too = weak, I'd suggest to change this to MUST. Finally, the applicability statement should be prominently made in the = abstract, introduction, etc. Lars --Apple-Mail=_284C6D2D-E30E-41B4-B7BA-E4CB74F1B323 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----- iQCVAwUBUt+b6dZcnpRveo1xAQLkKQQAhc+emA26F89+q5G6IaoweMLZmVAwDKhM Ho2jImsrh7Wxbez8DlKpGXarvLiWvVKvEMFTTm4hr5NpUQfGxhdtQqy9JKk+PlJL SCmg/gM3ntpfRARKFHrDqwZoT0xxqgw10oI7eurSKAWQ8C5UhOVi8Wwk5I+0tT5w dXXm1tFJ/jA= =TPMR -----END PGP SIGNATURE----- --Apple-Mail=_284C6D2D-E30E-41B4-B7BA-E4CB74F1B323-- From Alexander.Vainshtein@ecitele.com Wed Jan 22 03:05:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2E31A041F for ; Wed, 22 Jan 2014 03:05: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 WpQrwruwg0bg for ; Wed, 22 Jan 2014 03:05:01 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) by ietfa.amsl.com (Postfix) with ESMTP id 136841A02DE for ; Wed, 22 Jan 2014 03:05:00 -0800 (PST) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) with Microsoft SMTP Server (TLS) id 15.0.851.11; Wed, 22 Jan 2014 11:04:58 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0851.011; Wed, 22 Jan 2014 11:04:58 +0000 From: Alexander Vainshtein To: "Eggert, Lars" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF1wLMahemEzeV02cmtD3UBbhc5qQkZpA Date: Wed, 22 Jan 2014 11:04:57 +0000 Message-ID: References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.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: [147.234.56.21] x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(24454002)(189002)(377454003)(252514010)(51704005)(13464003)(377424004)(85852003)(2656002)(46102001)(93136001)(49866001)(53806001)(81816001)(54356001)(51856001)(90146001)(56816005)(85306002)(87936001)(83072002)(4396001)(81542001)(47736001)(19580395003)(50986001)(54316002)(74706001)(19580405001)(81342001)(80976001)(31966008)(33646001)(83322001)(47976001)(74366001)(76482001)(76576001)(76786001)(59766001)(81686001)(77982001)(92566001)(74876001)(65816001)(80022001)(74662001)(66066001)(74502001)(56776001)(79102001)(69226001)(76796001)(63696002)(87266001)(93516002)(47446002)(74316001)(86362001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB532; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:147.234.56.21; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 11:05:04 -0000 Lars and all, Last time I've counted the IETF LC thread on this draft has more than 150 m= essages in it, and it seems that on some issues (congestion control and UDP= checksums) we are going round the mulberry bush. IMHO and FWIW: - UDP checksums (or lack thereof) is a non-issue because native MPLS does n= ot have anything like that. And yes, there are cases where packets are corr= upted within the routers), but so far it did not prevent MPLS deployment. T= here is, e.g., RFC 4720 for FCS retention in PWs, but I doubt it is widely = implemented and deployed (would be nice to know). - E2E congestion control (regardless of its implications) simply cannot be = added to this protocol without some major changes. A short applicability st= atement explaining that should suffice IMO. My 2c, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars > Sent: Wednesday, January 22, 2014 12:23 PM > To: Xuxiaohu > Cc: Joel Jaeggli; mpls@ietf.org > Subject: Re: [mpls] Last Call: (Encapsula= ting > MPLS in UDP) to Proposed Standard >=20 > Hi, >=20 > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > I wonder whether the following text is OK to you: > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > forwarded through "UDP tunnels", the congestion control guidelines for UD= P > tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. > Specifically, MPLS can carry a number of different protocols as payloads. > When an UDP tunnel is used for MPLS payload traffic that is known at > configuration time to be IP-based and congestion-controlled, the UDP tunn= el > SHOULD NOT employ its own congestion control mechanism, because > congestion losses of tunneled traffic will trigger an congestion response= at > the original senders of the tunneled traffic. When an UDP tunnel is used = for > MPLS payload traffic that is known at configuration time not to be IP-bas= ed > and congestion-controlled, the UDP tunnel SHOULD employ an appropriate > congestion control mechanism as described in [RFC3985]. Note that it > STRONGLY RECOMMENDED to deploy such encapsulation technology only > within a SP network or networks of an adjacent set of co-operating SPs, > rather than over the Internet. Furthermore, packet filters should be adde= d > to block traffic with the UDP port number for MPLS over UDP to prevent > MPLS over UDP packets to escape from the service provider networks due to > misconfiguation or packet errors. >=20 > I think it would be better to describe the OAM control loop in (some) mor= e > detail, rather than pointing to RFC3985, which doesn't have a whole lot o= f > detail either. Also because the adding of firewall rules requires an OAM > hook. >=20 > Since STRONGLY RECOMMENDED is not an RFC2119 term and > RECOMMENDED is too weak, I'd suggest to change this to MUST. >=20 > Finally, the applicability statement should be prominently made in the > abstract, introduction, etc. >=20 > Lars From touch@isi.edu Wed Jan 22 07:20:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21761A010C; Wed, 22 Jan 2014 07:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 Pynengn7gPRw; Wed, 22 Jan 2014 07:20:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id EDC1D1A0111; Wed, 22 Jan 2014 07:20:11 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0MFIXkP025761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 07:18:42 -0800 (PST) Message-ID: <52DFE14C.5010802@isi.edu> Date: Wed, 22 Jan 2014 07:18:36 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ross Callon , "Eggert, Lars" References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> <52DF1AC4.7080007@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 15:20:27 -0000 On 1/21/2014 6:40 PM, Ross Callon wrote: > If the upper layers (the thing that runs over the tunnel) involves > applications over TCP over IP, or if it is otherwise responding to > congestion in the same way that we expect anything running over IP to > respond to congestion, then we don't want the tunnel to also > independently try to respond to congestion (two independent cooks > cooking the same meal does not necessarily lead to success). That's true, but is an issue only if the tunnel congestion control is dynamic over the same or shorter timescales than the congestion-controlled traffic being tunneled. > If the upper layer does not respond to congestion, then perhaps it > shouldn't be running over the open Internet (with or without a tunnel), > unless the *total* bandwidth that could be used is inherently quite low. Sure, but who would enforce that? If you're using MPLS, the only entity in a position to know (whether the traffic is congestion controlled or not) is the tunnel encapsulator. > On the other hand, it might want to run within a data center or > internally to a service provider network with appropriate provisioning. All bets are always off for private networks; they need not comply with any Internet standards or expectations, even when they leverage Internet header formats and protocols. But that's not a strict constraint of the proposed approach here. Joe > Ross > > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, January 21, 2014 8:12 PM > To: Ross Callon; Eggert, Lars > Cc: mpls@ietf.org; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > > > On 1/16/2014 2:32 PM, Ross Callon wrote: >>>> These tunnels are stateless >>> >>> yep. (But they don't have to be.) >> >> The tunnels strictly speaking do not have to be stateless. However, if you want routers to actually implement them, and you want to scale in both forwarding speed and number of tunnels, then yes they do have to be stateless. > > There's clearly a problem though: > > - tunnels must be stateless to be efficiently implemented > > - transport layer tunnels must have congestion control > > Saying that the only way we can make tunnels cheap is to make them break > the Internet isn't a good solution. > > Maybe it's time to expect something that's inherently costly to end up > being expensive? > > Joe > > > From touch@isi.edu Wed Jan 22 07:34:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBDD1A0102; Wed, 22 Jan 2014 07:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 Uo7-mb0gFZvx; Wed, 22 Jan 2014 07:34:38 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 278241A00E4; Wed, 22 Jan 2014 07:34:38 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0MFXQj1028544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 07:33:35 -0800 (PST) Message-ID: <52DFE4C9.8080403@isi.edu> Date: Wed, 22 Jan 2014 07:33:29 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Scott Brim References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <52DF19ED.8010200@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 15:34:39 -0000 On 1/21/2014 7:50 PM, Scott Brim wrote: > On Tue, Jan 21, 2014 at 8:07 PM, Joe Touch wrote: >> >> On 1/14/2014 7:23 AM, Joel M. Halpern wrote: >>> >>> Isn't that basically the problem of the inner traffic sender, not the >>> problem of the tunnel that is carrying the traffic? >>> Asking tunnel's to solve the problem of applications with undesirable >>> behavior seems backwards. >> >> By that argument, apps using TCP shouldn't expect the transport to control >> congestion. They ought to control it at the app layer. >> >> Tunneled MPLS, when encapsulated inside UDP, *is* the "application". UDP >> expects the app to deal with congestion, so it's entirely reasonable for UDP >> to expect the tunneling system to do this. > > Joe, I believe you are confusing a protocol with an architectural > function. http://www.isi.edu/rna ought to clear that misconception up. > It's a UDP encapsulation, but that encapsulation has nothing > to do with transport, and what runs over it is not an "application". That would be correct if the 8-byte UDP header were interpreted anywhere *except* the current Internet as the demuxing layer above IP. But that semantics is exactly what this document seeks - to use that UDP information for load balancing, e.g. Consider this from the Internet's viewpoint; UDP traffic is traversing it, sourced by the tunnel ingress, and travels through the Internet with the congestion control expectations outlined in RFC5405. To the Internet, this UDP header is a transport layer, and the tunnel ingress is the application. Yes, if you were just using these bytes somewhere else, interpreted by some other mechanism (or not), they'd be just bytes of encapsulation. But in the Internet, the roles are determined by RFC768, RFC1122, and RFC5405. > It may be a client layer (with the encapsulation a service layer), but > that's a relative relationship, not an absolution one about stack > position. In an arbitrary environment, without knowledge of any of the other protocol layers, yes (that's the principle behind RNA, above). When instantiated inside the Internet, when you take a physical signal, interpret it as a link layer packet, examine the next 20-40 bytes as the IP header, and the next 8 as UDP, then that UDP header *is* the transport layer for that network (the Internet), and the application layer *is* whatever generated the contents of that packet (the encapsulator). > This instance of UDP is way below transport, is just in > fact a bit of lubrication for the packet, and considered That's true from the perspective of the MPLS packet and its origin network, but not from the perspective of the network the UDP encapsulated result traverses. > _functionally_ has nothing to do with congestion control. Oh, sure - UDP has nothing to do with congestion control. But that's exactly why the transport area generated RFC5405's section 3.1.3 - requiring that the application (the party that generates the UDP packets) includes congestion control (directly, or by transitive closure of the source of the source of the source... that generated the original highest layer of packet, which eventually became encapsulated in UDP). > The only > reason for using UDP encapsulation is to get through middleboxes. If > something else worked better for that, they would use it. According to the doc, this is also for load distribution. That aside, however, it'd be nice if there were a layer that just "got through middleboxes" and had no other properties. UDP isn't that layer. Nor is TCP. TCP comes with its own baggage (including reactive congestion control) of a heavyweight mechanism that isn't desired for most high-speed tunnels. UDP comes with RFC5405. That requires some sort of congestion reaction. No need to be on the same timescale as TCP - it could be much slower, or could simply be (as Lars suggested) a throttle-limit (circuit breaker). Joe From touch@isi.edu Wed Jan 22 07:37:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6A71A00E4; Wed, 22 Jan 2014 07:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 hwx41X7SzANq; Wed, 22 Jan 2014 07:37:52 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 672BE1A00CF; Wed, 22 Jan 2014 07:37:52 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0MFbGJJ029275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 07:37:25 -0800 (PST) Message-ID: <52DFE5AC.9020008@isi.edu> Date: Wed, 22 Jan 2014 07:37:16 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Scott Brim , Ross Callon References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> <52DF1AC4.7080007@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 15:37:54 -0000 On 1/21/2014 8:03 PM, Scott Brim wrote: > Lars is right, this does allow traffic that was formerly run over > provisioned paths in well-managed networks to possibly be part of > general Internet traffic. It would be good if there were a way to be > _sure_ there was e2e congestion control. But there is no signaling > between this low-layer UDP encapsulation and anything above it that > might already be reacting to congestion. There is no reasonably easy > way for it to know what it is carrying. Yes there is a way to do > congestion control at the bottom layer, but doing so could destroy > performance if one (or more) layer(s) is already doing it up above. We > have experience with that. Lars isn't suggesting congestion control on the same timescale as TCP, which is where the problem would be. Long-timescale control OR something as simple as a throttle-cap would be sufficient. > I can't remember who said it, but an applicability statement might > satisfy everyone, especially since it's been said (Curtis?) that this > just isn't going to be used in situations where congestion will be a > problem. If we accepted that premise, we wouldn't need any congestion control. Nobody openly claims to want to generate congestion. Congestion control is required to protect the rest of us from cases where that claim turns out to be false (typically because the protocol designers/use case authors turned out to be wrong). > Alternatively, a paragraph laying out the problem and saying if this > is used in a way that could impact ordinary traffic, a mechanism must > be defined. The problem is very clearly already stated in RFC5405. I can't see how this mechanism would ever be used if not for ordinary traffic. So yes, a mechanism must be defined IMO too. Joe From touch@isi.edu Wed Jan 22 07:47:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3F91A0159; Wed, 22 Jan 2014 07:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.235 X-Spam-Level: X-Spam-Status: No, score=-4.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 alGmuZx7SSph; Wed, 22 Jan 2014 07:47:15 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E75B11A0154; Wed, 22 Jan 2014 07:47:15 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0MFkUn6001040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 07:46:39 -0800 (PST) Message-ID: <52DFE7D8.9090400@isi.edu> Date: Wed, 22 Jan 2014 07:46:32 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com, "Eggert, Lars" References: <201401171719.s0HHJqHY062965@maildrop2.v6ds.occnc.com> In-Reply-To: <201401171719.s0HHJqHY062965@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 15:47:17 -0000 On 1/17/2014 9:19 AM, Curtis Villamizar wrote: > Lars, > > We seem to be in an endless loop here. > > You have made your assertions about your desire to uphold the purity > of any new UDP applications and adhere to the BCP you wrote. The BCP that the transport area as a whole recommends, in conjunction with the IETF as a whole. > You appear to be very nearly alone in this argument... The IETF is a very large DDOS attack on people's time. It's very easy for faulty ideas to pop up and not be challenged - easy because there are a lot of people (companies) with vested (financial) interest in promoting their particular approaches, and only a few people who care to spend the time playing "whack a mole" to defend the Internet against these approaches (by either pulling them back into compliance with agreed principles, such as BCPs, or shooting down ideas altogether). So if your room is full of your own choir singing so loud for your own sake that you can't hear the objections of the few who are providing feedback from outside the room, that shouldn't be surprising. But that neither means the choir is in tune nor that there aren't many outside the room (or who don't attend meetings) who aren't trying to tell you otherwise. FWIW. :-) Joe From touch@isi.edu Wed Jan 22 07:51:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490141A0167; Wed, 22 Jan 2014 07:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 ky4hNptpXHK1; Wed, 22 Jan 2014 07:51:54 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3112C1A0160; Wed, 22 Jan 2014 07:51:54 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0MFpAXI001943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 07:51:19 -0800 (PST) Message-ID: <52DFE8F1.7070304@isi.edu> Date: Wed, 22 Jan 2014 07:51:13 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com, "Eggert, Lars" References: <201401150040.s0F0eZXj005169@maildrop2.v6ds.occnc.com> In-Reply-To: <201401150040.s0F0eZXj005169@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 15:51:55 -0000 On 1/14/2014 4:40 PM, Curtis Villamizar wrote: > In message > "Eggert, Lars" writes: > >> On 2014-1-14, at 15:20, Stewart Bryant wrote: >>> Yes, the inner (real) transport header is the only meaningful place >>> to apply congestion avoidance. >> >> But what if the inner traffic isn't congestion controlled? >> >> Lars > > > Lars, > > The exact same thing will happen in all of the following cases: > > NON-congestion controlled application --over-- > UDP --over-- IP --over-- L2 > > NON-congestion controlled application --over-- > UDP --over-- IP --over-- MPLS --over-- L2 > > NON-congestion controlled application --over-- > UDP --over-- IP --over-- MPLS --over-- UDP --over-- IP --over-- L2 > > The non-congestion controlled application is what needs fixing. In all three cases, RFC5405 expects that traffic inside UDP is congestion controlled. That can happen when the source application does so, but when that isn't known, it needs to happen at whatever layer puts the packet inside the UDP header that the Internet ends up seeing. > It would be wrong to try to put congestion control at every layer > underneath the non-congestion controlled application Yes, but it's not wrong to require some sort of congestion control at any layer that generates a UDP packet inside the Internet or any other Internet-protocol-based network that has the same RFC5405 expectations. Joe From gregory.mirsky@ericsson.com Wed Jan 22 07:52:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6CC1A0144 for ; Wed, 22 Jan 2014 07:52: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, 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 Wyh5laHpS02x for ; Wed, 22 Jan 2014 07:52:18 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7F73E1A029C for ; Wed, 22 Jan 2014 07:52:18 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-5e-52dfe931275a Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 70.0D.11484.139EFD25; Wed, 22 Jan 2014 16:52:17 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Wed, 22 Jan 2014 10:52:16 -0500 From: Gregory Mirsky To: "stbryant@cisco.com" , "Eggert, Lars" , "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bPPvfN+AdnsEmIwhiSR8n5OpqQ2S8AgAAH4oA= Date: Wed, 22 Jan 2014 15:52:16 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B749A17@eusaamb103.ericsson.se> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <52DF98B8.3050208@cisco.com> In-Reply-To: <52DF98B8.3050208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPgq7hy/tBBktuaVtMnnWGzeLVqTWM Fi9e97BY3Fq6ktXi3NM5jA6sHmePLGD0mPJ7I6vHkiU/mTyW3b/I5jHj0xe2ANYoLpuU1JzM stQifbsErozFb78wFqznq1gx5SRzA+Mr7i5GDg4JAROJR8fquhg5gUwxiQv31rN1MXJxCAkc YZS4dKqDGSQhJLCcUeLyhGwQm03ASOLFxh52kCIRgSZGiWldbewgCWYBF4lJX+czgdjCAoUS p2d9YASxRQSKJN72tLOBLBMRsJI4cMUGJMwioCrx4eUzsBJeAV+Jpx2NLBCLpzJKrNqxgwmk nlNAU2LzC12QGkag476fWsMEsUpc4tYTiFUSAgISS/acZ4awRSVePv7HCmErScx5fY0Zol5H YsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcx AuPrmASb4w7GBZ8sDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRL7qs vq5EtCItYQ7rxu7S2cb7P31SeKjn/NNM7E7cyi8KjuJVK+u+yz7c5L+4+4KqfWJ8G/NhjrUb HdJ351Yv7vWOmGt73q6rjO34u6X3Kt4/OS4ceeYyF7/4ueLvMUFOLGan560wTz3gKHSnPpkv v9xWl6MhPPJd5omoJL3fkYyG+9V3mSmxFGckGmoxFxUnAgAxUH5UfQIAAA== Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 15:52:20 -0000 Hi Stewart, et. al, I think that the method to detect degradation of a tunnel service can use a= ny of performance measurement metrics, e.g. packet loss, delay or delay var= iation. An operator may have controls to define what constitutes entering a= nd exiting Severe Service Degradation error state, e.g. threshold, number o= f consecutive down threshold and up threshold measurements, etc. And associ= ate actions with entering and exiting error state. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, January 22, 2014 2:09 AM To: Eggert, Lars; curtis@ipv6.occnc.com Cc: Joel Jaeggli; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard On 22/01/2014 07:51, Eggert, Lars wrote: > This is not at all the argument I am making. My emails have not touched a= t all on the issue of zero checksums. > > My point is that UDP encapsulation changes the potential *reach* of conge= stion-uncontrolled traffic that was otherwise limited to L2 networks. > > Lars How about if text is introduced recommending the use of an OAM between tunn= el endpoints that monitors packet loss. The tunnel endpoints need to know if the tunnel is broken anyway and on hit= ting a loss threshold they can alarm, redirect the traffic, or shutdown, d= epending on configuration, topology and the needs of the operator. You probably also need pro-active CV to make the whole system work. This many not necessarily be fast or elegant, but if there is significant m= isdelivery or congestion loss, traffic will eventually cease. Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lars@netapp.com Wed Jan 22 09:55:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8031A0188; Wed, 22 Jan 2014 09:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 7BtcWX0YP8-6; Wed, 22 Jan 2014 09:55:31 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id A8D2E1A0199; Wed, 22 Jan 2014 09:55:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,701,1384329600"; d="asc'?scan'208";a="97521704" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 22 Jan 2014 09:55:24 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 09:55:24 -0800 From: "Eggert, Lars" To: Noel Chiappa Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF5eBFyKjVtdEy02x6qUpK40JLJqRjSoA Date: Wed, 22 Jan 2014 17:55:23 +0000 Message-ID: <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> In-Reply-To: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: multipart/signed; boundary="Apple-Mail=_8A1F21FB-58D7-4707-982F-B65299EABE49"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 17:55:32 -0000 --Apple-Mail=_8A1F21FB-58D7-4707-982F-B65299EABE49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-1-22, at 18:29, Noel Chiappa wrote: > Envision the following 4 (or more) scenarios for one Border Tunneling = Routing > (BTR), BTR A, to send packets to another BTR, BTR B, on the path from = ultimate > source S (somewhere before BTR A) to destination D (somewhere after = BTR B). >=20 > - Plain IP > - Some existing encapsulation like GRE > - A new, custom encapsulation > - Encapsulation using UDP >=20 > What you seem to be claiming is that in case 4 we need to have = congestion > detection and response at the intermediate forwarding node BTR A - but = it > would not be required in cases 1-3? This makes no sense. I'm not saying that. I'm saying that for every tunnel that can extend = the reach of not-congestion-controlled traffic, e.g., some L2 traffic, = over the wider Internet, we have a potential problem. For plain IP as well as encapsulations that use IP protocol numbers that = are different than UDP, TCP and I guess ICMP, that danger is somewhat = mitigated, because such traffic typically dies at the next NAT or = firewall (unless that has been specifically provisioned, which is then = also OK). So there can be harm, but it will be limited to some segment = of the network, hopefully the segment that the entity who performed the = encapsulation manages. UDP and TCP traverse most NATs and firewalls, if the directionality of = the flow establishment is as expected by the middlebox ("inside" to = "outside"). That means that UDP-encapsulated L2 traffic has a much wider = reach - an Internet-wide reach. That's the fundamental difference to the = other cases. > Even better, suppose that BTR A implements _both_ one of the first = three, > _and_ UDP encapsulation. If its response to UDP congestion on the path = to BTR > B is to.... switch to a _different_ encapsulation for traffic to that > intermediate forwarding node, one for which it's not required to = detect and > respond to congestion, did that really help? It won't solve the problem, but these other encapsulations have more = limited reach, and as such the potential for damage is lessened. > Similarly, if people doing tunnels ditched UDP in favor of some other > encapsulation (assuming they could find something that would get = through as > many filters as UDP does, would have the same load-spreading = properties that > UDP does, etc, etc - or maybe not, if that's the price they have to = pay for > being free of the grief they are getting because they are using UDP) - = would > that do anything at all for any potential congestion from their = traffic? No, > it would still be there, obviously. Depends on the reach of that encapsulation. If it requires manual = configuration of middleboxes to make it traverse (like GRE would), that = danger is lessened. If it traversed such middleboxes by default, as UDP = does, it has the same issues. > Look, the current architectural model of the Internet for dealing with > congestion is that the _application endpoints_ have to notice it, and = slow > down. Intermediate forwarding nodes don't have any particular = responsibility > other than to drop packets if they have too many. Right. =46rom the viewpoint of the Internet, the *encapsulator* is that = application endpoint. That's what the whole concept of a tunnel is = about. > You are quite right that if we take some application that doesn't = detect and > respond to congestion (perhaps because it was written for a local = environment, > and some bright spark is tunnelling that L2 protocol over the = Internet), that > can cause problems - but that's because we are violating the = Internet's > architectural assumption on how/who/where congestion control is done. Exactly.=20 > I don't have any particularly brilliant suggestions on how to respond = to > situations in which applications don't detect and respond to = congestion. > Architecturally, if we are to keep to the existing congestion control = scheme > (endpoints are responsible), the responsibilty has to go back to the = ultimate > source of the traffic somehow... No, it doesn't. That responsibility lies with the entity that injects = that packet into the Internet, which is the encapsulator. For the rest = of the Internet, the encapsulator is the sending application of the UDP = traffic. Without the encapsulator, that traffic would not exist on the = Internet. > But saying that _intermediate forwarding nodes_ have to detect = down-stream > congestion, and respond, represents a fundamental change to the = Internet's > architecture for congestion control. And here's the fallacy: UDP encapsulators are forwarding nodes *only* = from the viewpoint of the final endpoints. =46rom the viewpoint of the = rest of the Internet, they are traffic *sources*, not *forwarders*.=20 Lars --Apple-Mail=_8A1F21FB-58D7-4707-982F-B65299EABE49 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----- iQCVAwUBUuAGCtZcnpRveo1xAQKpqQQAsy2+qTUBiH1uxeE2Z5H2CcqVCmKNEMxf snsKO+JwL36uQE+GpMUk59FWmQwI8qpOwx5cONDddNfGWcKVdIVRt4IxwNs5XA4/ 67oPhuPTMMAHysRw5YgK0wTWitMZQ0iuuogcL2u2x/S3i1VxLIHj5dtP/4+gvedt QbCu9sKKu6Y= =EvAi -----END PGP SIGNATURE----- --Apple-Mail=_8A1F21FB-58D7-4707-982F-B65299EABE49-- From curtis@ipv6.occnc.com Wed Jan 22 11:35:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33EB1A0151 for ; Wed, 22 Jan 2014 11:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 8I9vb7ptdCRu for ; Wed, 22 Jan 2014 11:35:29 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 302341A014E for ; Wed, 22 Jan 2014 11:35:29 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0MJZON3087092; Wed, 22 Jan 2014 14:35:24 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401221935.s0MJZON3087092@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Wed, 22 Jan 2014 01:04:27 +0000." <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk> Date: Wed, 22 Jan 2014 14:35:24 -0500 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 19:35:32 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > Curtis, > > the 'intended for use within a service provider' and not for mass use > sounds reasonable, and scoping in this way may also alleviate some > congestion control concerns. Partial agreement. That's progress. > But outgoing packet filtering, when you're trying to catch a corrupted > port, and the port is not what you think it is? That's going to do a > partial job of corrupted addresses in IPv6 at best. (v4 has header > checksums, ports in v4 and v6 are open to corruption sans UDP > pseudo-header check.) Both the port and the IPv6 address would have to be corrupt for the filter to fail. > Not convinced by providers already blocking inbound traffic on a new > port - particularly given discussion of handling entropy with varying > ports in another thread. Providers already block port 179 and quite a few others and have for 20 years. If the provider wants the service to simply not affect their infrastructure, the filter is dest port number plus IP address prefix covering their infrastructure. > So, I don't think filtering is a useful solution here to the problem > posed by zero UDP checksums. (An actual UDP checksum solves it, of > course.) So if I understand, you like the recommendation that MPLS over UDP be recommended for service provider use only and you don't like recommending that the providers filter to protect against IPv6 destination address corruption related to this service. Curtis > regards > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 22 January 2014 00:24 > To: Wood L Dr (Electronic Eng) > Cc: curtis@ipv6.occnc.com; lars@netapp.com; stbryant@cisco.com; joelja@bogus.com; mpls@ietf.org > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > Lloyd, > > Since MPLS over UDP is intended to be used within a provider, how > about if we recommend the following: > > If no MPLS over UDP is intended to go outside a service provider, > then packet filters should be added to block traffic with the UDP > port number for MPLS over UDP to prevent misconfiguation or packet > error to cause MPLS over UDP packets to escape, > > If either the IP destination address or the UDP destination port were > corrupted, then the packet would not leave. The former because the > intended destination within the provider would get the packet. The > latter because with the UDP port intact the provider's filter would > block it. > > This would also prevent ordinary users from making use of MPLS over > UDP, which with its absense of congestion control is causing some > objections. > > Providers would already be blocking traffic coming into their net with > this UDP port, particularly to their own infrastructure. The filters > might cover only their own addresses allowing users to make use of > MPLS over UDP, or could block it entirely. > > This is in line with Alia's suggestion that we define a profile of > intended use being for service providers internal use. > > Curtis > > > In message <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > > checksum can still be filled in so the IP destination is checked > > > > IPv6 doesn't have an IP header checksum. So with an error in the > > header the packet can go anywhere. > > > > > > > Lack of UDP checksum should at worst mean that the destination gets a > > > packet with a munged payload, pulls off the IP and UDP headers and > > > continues to forward > > > > ... or a munged header, and forwards to a different application on a different port. > > > > See RFC 6936 section 3, which goes through the scenarios - but plays light > > on the side-effects. My beef is with: > > > > A protocol or application that uses the zero UDP checksum method must > > ensure that the lack of checksum does not affect the protocol > > operation. This includes being robust to receiving an unintended > > packet from another protocol or context following corruption of a > > destination or source address and/or port value. It also includes > > considering the need for additional implicit protection mechanisms > > required when using the payload of a UDP packet received with a zero > > checksum. > > > > Lack of a UDP checksum in one protocol can affect the operation of other > > protocols minding their own business, until they receive and try to handle > > a corrupted packet from the first protocol because port or address is > > corrupted. There are a lot of applications that presume that the data they > > are given is error-free, and they presume that rogue data is not injected into > > their conversation. > > > > I mean, if you're going to use a zero UDP checksum, and your application > > messes up and gives itself corrupt data, fine. More fool you. By analogy > > as a risk, it's like speeding while talking on a cellphone and crashing into a tree. > > But if your lack of checksum means you affect other applications who have > > to now protect themselves against your data, you're effectively now crashing > > into and harming other people. They weren't in armoured cars to protect > > against this? They had no right to be on the road! > > > > Zero UDP checksums are hit-and-run accidents waiting to happen. > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Curtis Villamizar [curtis@ipv6.occnc.com] > > Sent: 21 January 2014 20:14 > > To: Eggert, Lars > > Cc: Stewart Bryant; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org > > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > > > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> > > "Eggert, Lars" writes: > > > > > Hi, > > > > > > On 2014-1-21, at 12:50, Stewart Bryant wrote: > > > > In terms of congestion and misdelivery it is interesting looking > > > > at the number of horses that are already bounding around > > > > in the paddock outside the stable: > > > > > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > > > > > there is a big difference between encapsulation in IP and > > > encapsulation in UDP. Everything encapsulated with "obscure" IP > > > protocol numbers will get dropped by default at NATs and firewalls, > > > whereas UDO traffic happily traverses them. The reach of UDP traffic > > > is much broader. > > > > > > Lars > > > > > > Stray UDP packets carrying MPLS getting to grandma's firewall is > > really stretching the argument but ... > > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > checksum can still be filled in so the IP destination is checked and > > grandma need not worry about these packets. But ... > > > > Grandma's firewall would block since there is no state established on > > the firewall with the opposite port pair pattern. But ... > > > > Even if it went through when the packet reached grandma's subnet the > > payload is junk bound to an unused port. Maybe it hits grandma's DNS > > server and is interpreted as a badly malformed DNS request. > > > > So grandma seems safe from these bad packets. > > > > Lack of UDP checksum should at worst mean that the destination gets a > > packet with a munged payload, pulls off the IP and UDP headers and > > continues to forward. At worst has the wrong MPLS label and gets > > blackholed in the provider network somewhere. If it ends up at the > > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > > UDP payload carried in that IP got munged the packet could end up at > > the destination with a bad TCP or UDP checksum and get dropped. > > > > Curtis From curtis@ipv6.occnc.com Wed Jan 22 11:59:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447EE1A01C0 for ; Wed, 22 Jan 2014 11:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.535, 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 Hmk0ZJeROsZv for ; Wed, 22 Jan 2014 11:59:20 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id EB1F81A037F for ; Wed, 22 Jan 2014 11:59:19 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0MJx5qw087329; Wed, 22 Jan 2014 14:59:05 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401221959.s0MJx5qw087329@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Wed, 22 Jan 2014 03:38:19 +0000." <290E20B455C66743BE178C5C84F1240847E63346E0@EXMB01CMS.surrey.ac.uk> Date: Wed, 22 Jan 2014 14:59:05 -0500 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 19:59:23 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346E0@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > > [Alia] Excellent - so if we can describe filtering on the correct > fields to enforce this constrained scope, then the concerns about > congestion control may be alleviated. > > For intended private use within a network, I think you'd be fine;as > with congestion, crossing the public Internet poses more of a > problem. I don't see how filtering comes in to enforce this. Minor clarification here: The filtering is intended to reduce the possibility of an MPLS in UDP in IPv6 packet from going out a provider LSR with a bad IPv6 address and creating a high traffic accidental DoS attack on a random IPv6 address. Blocking all traffic from the provider infrastructure prefix with MPLS over UDP port number would accomplish this as long as the IPv6 source address was not corrupted and outside the prefix or the destination UDP port number was not corrupted. So for example, all packets with a single bit error that would otherwise exit the provider's infrastructure would be blocked by the filter. This is not intended to block a malicious user. A malicious user would not bother adding the MPLS encapsulation in the first place as it does nothing to improve their throughput. Additional suggestions: We can also recommend that hosts and routers that are not primarily intended to be used in a provider infrastructure not implement this protocol. Other than that the SHOULD implement congestion control and SHOULD use the UDP checksum seems to me to be sufficient. It is only the high end routers that don't have the whole packet in memory to run a UDP checksum where making it zero is needed. Infeasibility certainly qualifies as a circumstance that meets going against a SHOULD. If MPLS over UDP starts showing up on lower end routers that could end up on enterprise networks or worse yet consumer routers or hosts, then a congestion control for UDP draft would have to be written and advanced. If so, it might be best to cover any form of tunneling over UDP rather than just MPLS over UDP. > > [Alia] Are you actually suggesting that it is highly likely for both > the destination IP and UDP port to be simultaneously corrupted on a > significant flow of packets where each link already has a FCS > covering the entire packet? > > It is possible. The FCS only covers the link, and the zero UDP > checksum removes any check across the entire path. > > > [Alia] We have vast existence proof that MPLS label stacks, also > covered only by link FCS, that this is not the case. > > MPLS is scoped within the link between MPLS-aware devices. This > tunnelling use is along the entire path. The scope is different. How > are MPLS discards or missent packets measured? > > > [Alia] Can you clearly articulate what you see as the threat > scenario and the necessary scale and probability to be meaningful > here? > > 'Threat scenario' is language about mitigating a threat to your > traffic. Here, your traffic with a zero UDP checksum poses the threat > - to everything else. > > Probability of threat is non-zero, but unknown, because networks are > not instrumented for it. We have discussed Stone's results and other > anecdotal evidence in this thread. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Alia Atlas [akatlas@gmail.com] > Sent: 22 January 2014 02:34 > To: Wood L Dr (Electronic Eng) > Cc: curtis@ipv6.occnc.com; joelja@bogus.com; mpls@ietf.org; Eggert, Lars > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > Lloyd, > > On Tue, Jan 21, 2014 at 8:04 PM, > wrote: > Curtis, > > the 'intended for use within a service provider' and not for mass use sounds reasonable, > and scoping in this way may also alleviate some congestion control concerns. > > [Alia] Excellent - so if we can describe filtering on the correct fields to enforce this constrained scope, then the concerns about congestion control may be alleviated. > > But outgoing packet filtering, when you're trying to catch a corrupted port, > and the port is not what you think it is? That's going to do a partial job > of corrupted addresses in IPv6 at best. (v4 has header checksums, > ports in v4 and v6 are open to corruption sans UDP pseudo-header > check.) > > [Alia] Are you actually suggesting that it is highly likely for both the destination IP and UDP port to be simultaneously corrupted on a significant flow of packets where each link already has a FCS covering the entire packet? > > [Alia] We have vast existence proof that MPLS label stacks, also covered only by link FCS, that this is not the case. Naturally the top label is manipulated but the rest of the label stack is just passed through and not looked at. > > Not convinced by providers already blocking inbound traffic on a new port - > particularly given discussion of handling entropy with varying ports > in another thread. > > [Alia] For defense, isn't it a case of block ports by default and only open the destination ports that are explicitly needed? That's how firewalls that I've seen work; perhaps others have a common counterexample? The entropy is put into the source port, which isn't relevant here. > > So, I don't think filtering is a useful solution here to the problem posed > by zero UDP checksums. (An actual UDP checksum solves it, of course.) > > [Alia] Can you clearly articulate what you see as the threat scenario and the necessary scale and probability to be meaningful here? > > Regards, > Alia > > > regards > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 22 January 2014 00:24 > To: Wood L Dr (Electronic Eng) > Cc: curtis@ipv6.occnc.com; lars@netapp.com; stbryant@cisco.com; joelja@bogus.com; mpls@ietf.org > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > Lloyd, > > Since MPLS over UDP is intended to be used within a provider, how > about if we recommend the following: > > If no MPLS over UDP is intended to go outside a service provider, > then packet filters should be added to block traffic with the UDP > port number for MPLS over UDP to prevent misconfiguation or packet > error to cause MPLS over UDP packets to escape, > > If either the IP destination address or the UDP destination port were > corrupted, then the packet would not leave. The former because the > intended destination within the provider would get the packet. The > latter because with the UDP port intact the provider's filter would > block it. > > This would also prevent ordinary users from making use of MPLS over > UDP, which with its absense of congestion control is causing some > objections. > > Providers would already be blocking traffic coming into their net with > this UDP port, particularly to their own infrastructure. The filters > might cover only their own addresses allowing users to make use of > MPLS over UDP, or could block it entirely. > > This is in line with Alia's suggestion that we define a profile of > intended use being for service providers internal use. > > Curtis > > > In message <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > > checksum can still be filled in so the IP destination is checked > > > > IPv6 doesn't have an IP header checksum. So with an error in the > > header the packet can go anywhere. > > > > > > > Lack of UDP checksum should at worst mean that the destination gets a > > > packet with a munged payload, pulls off the IP and UDP headers and > > > continues to forward > > > > ... or a munged header, and forwards to a different application on a different port. > > > > See RFC 6936 section 3, which goes through the scenarios - but plays light > > on the side-effects. My beef is with: > > > > A protocol or application that uses the zero UDP checksum method must > > ensure that the lack of checksum does not affect the protocol > > operation. This includes being robust to receiving an unintended > > packet from another protocol or context following corruption of a > > destination or source address and/or port value. It also includes > > considering the need for additional implicit protection mechanisms > > required when using the payload of a UDP packet received with a zero > > checksum. > > > > Lack of a UDP checksum in one protocol can affect the operation of other > > protocols minding their own business, until they receive and try to handle > > a corrupted packet from the first protocol because port or address is > > corrupted. There are a lot of applications that presume that the data they > > are given is error-free, and they presume that rogue data is not injected into > > their conversation. > > > > I mean, if you're going to use a zero UDP checksum, and your application > > messes up and gives itself corrupt data, fine. More fool you. By analogy > > as a risk, it's like speeding while talking on a cellphone and crashing into a tree. > > But if your lack of checksum means you affect other applications who have > > to now protect themselves against your data, you're effectively now crashing > > into and harming other people. They weren't in armoured cars to protect > > against this? They had no right to be on the road! > > > > Zero UDP checksums are hit-and-run accidents waiting to happen. > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Curtis Villamizar [curtis@ipv6.occnc.com] > > Sent: 21 January 2014 20:14 > > To: Eggert, Lars > > Cc: Stewart Bryant; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org > > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > > > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> > > "Eggert, Lars" writes: > > > > > Hi, > > > > > > On 2014-1-21, at 12:50, Stewart Bryant > wrote: > > > > In terms of congestion and misdelivery it is interesting looking > > > > at the number of horses that are already bounding around > > > > in the paddock outside the stable: > > > > > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > > > > > there is a big difference between encapsulation in IP and > > > encapsulation in UDP. Everything encapsulated with "obscure" IP > > > protocol numbers will get dropped by default at NATs and firewalls, > > > whereas UDO traffic happily traverses them. The reach of UDP traffic > > > is much broader. > > > > > > Lars > > > > > > Stray UDP packets carrying MPLS getting to grandma's firewall is > > really stretching the argument but ... > > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > checksum can still be filled in so the IP destination is checked and > > grandma need not worry about these packets. But ... > > > > Grandma's firewall would block since there is no state established on > > the firewall with the opposite port pair pattern. But ... > > > > Even if it went through when the packet reached grandma's subnet the > > payload is junk bound to an unused port. Maybe it hits grandma's DNS > > server and is interpreted as a badly malformed DNS request. > > > > So grandma seems safe from these bad packets. > > > > Lack of UDP checksum should at worst mean that the destination gets a > > packet with a munged payload, pulls off the IP and UDP headers and > > continues to forward. At worst has the wrong MPLS label and gets > > blackholed in the provider network somewhere. If it ends up at the > > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > > UDP payload carried in that IP got munged the packet could end up at > > the destination with a bad TCP or UDP checksum and get dropped. > > > > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Wed Jan 22 12:12:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517541A019A for ; Wed, 22 Jan 2014 12:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 XyUaK7r57sZA for ; Wed, 22 Jan 2014 12:12:24 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6402F1A044C for ; Wed, 22 Jan 2014 12:12:16 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0MKC92Z087567; Wed, 22 Jan 2014 15:12:09 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401222012.s0MKC92Z087567@maildrop2.v6ds.occnc.com> To: stbryant@cisco.com From: Curtis Villamizar In-reply-to: Your message of "Wed, 22 Jan 2014 10:01:36 +0000." <52DF9700.7040707@cisco.com> Date: Wed, 22 Jan 2014 15:12:09 -0500 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:12:25 -0000 In message <52DF9700.7040707@cisco.com> Stewart Bryant writes: > On 22/01/2014 01:04, l.wood@surrey.ac.uk wrote: > > Curtis, > > > > the 'intended for use within a service provider' > Presumable within an SP or an adjacent set of co-operating SPs > > Stewart Yakov used to say "among consenting adults" but that was regarding certain BGP practices. The same would apply here. Curtis From curtis@ipv6.occnc.com Wed Jan 22 12:43:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507671A02C8 for ; Wed, 22 Jan 2014 12:43:05 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char B4 hex): Subject: Re: \264\360\270\264: [mpls] Las[...] X-Spam-Flag: NO X-Spam-Score: -0.231 X-Spam-Level: X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJECT_NEEDS_ENCODING=0.049, SUBJ_ILLEGAL_CHARS=1.518] 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 lMa8pJkNifSv for ; Wed, 22 Jan 2014 12:43:04 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCFF1A0158 for ; Wed, 22 Jan 2014 12:42:58 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0MKgoTZ087832; Wed, 22 Jan 2014 15:42:50 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401222042.s0MKgoTZ087832@maildrop2.v6ds.occnc.com> To: Xuxiaohu From: Curtis Villamizar Subject: Re: ´ð¸´: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard In-reply-to: Your message of "Wed, 22 Jan 2014 10:12:22 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> Date: Wed, 22 Jan 2014 15:42:50 -0500 Cc: Joel Jaeggli , "mpls@ietf.org" , "Eggert, Lars" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:43:05 -0000 In message <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> Xuxiaohu writes: > Hi all, > > Thanks a lot for your comments. > > I wonder whether the following text is OK to you: > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > forwarded through "UDP tunnels", the congestion control guidelines > for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be > followed. Specifically, MPLS can carry a number of different > protocols as payloads. When an UDP tunnel is used for MPLS payload > traffic that is known at configuration time to be IP-based and > congestion-controlled, the UDP tunnel SHOULD NOT employ its own > congestion control mechanism, because congestion losses of tunneled > traffic will trigger an congestion response at the original senders > of the tunneled traffic. When an UDP tunnel is used for MPLS > payload traffic that is known at configuration time not to be > IP-based and congestion-controlled, the UDP tunnel SHOULD employ an > appropriate congestion control mechanism as described in > [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such > encapsulation technology only within a SP network or networks of an > adjacent set of co-operating SPs, rather than over the > Internet. Furthermore, packet filters should be added to block > traffic with the UDP port number for MPLS over UDP to prevent MPLS > over UDP packets to escape from the service provider networks due > to misconfiguation or packet errors. > > Best regards, > Xiaohu Xiaohu, Looks good. A few nits: s/an congestion response/a congestion response/ s/Note that it STRONGLY RECOMMENDED/Note that it is STRONGLY RECOMMENDED/ s/to deploy such encapsulation technology /that such encapsulation technology be deployed/ s/UDP packets to escape from/UDP packets from escaping/ I suggest that you also add a paragraph saying that UDP checksums SHOULD be used in all cases where it is feasible to do so. Try to capture the reasoning behind the tsvwg recommendations that UDP checksums be used whenever it is possible to do so. You can optionally add wording from past email outlining the known cases where adding UDP checksums are infeasible (such as cut-through routing). thanks. Curtis > > -----ÓʼþÔ­¼þ----- > > ·¢¼þÈË: mpls [mailto:mpls-bounces@ietf.org] ´ú±í Eggert, Lars > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ22ÈÕ 15:52 > > ÊÕ¼þÈË: curtis@ipv6.occnc.com > > ³­ËÍ: Joel Jaeggli; mpls@ietf.org > > Ö÷Ìâ: Re: [mpls] Last Call: (Encapsulating MPLS > > in UDP) to Proposed Standard > > > > This is not at all the argument I am making. My emails have not touched at all > > on the issue of zero checksums. > > > > My point is that UDP encapsulation changes the potential *reach* of > > congestion-uncontrolled traffic that was otherwise limited to L2 networks. > > > > Lars > > > > On 2014-1-21, at 21:14, Curtis Villamizar wrote: > > > > > > > > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com> > > > "Eggert, Lars" writes: > > > > > >> Hi, > > >> > > >> On 2014-1-21, at 12:50, Stewart Bryant wrote: > > >>> In terms of congestion and misdelivery it is interesting looking at > > >>> the number of horses that are already bounding around in the paddock > > >>> outside the stable: > > >>> > > >>> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > >> > > >> there is a big difference between encapsulation in IP and > > >> encapsulation in UDP. Everything encapsulated with "obscure" IP > > >> protocol numbers will get dropped by default at NATs and firewalls, > > >> whereas UDO traffic happily traverses them. The reach of UDP traffic > > >> is much broader. > > >> > > >> Lars > > > > > > > > > Stray UDP packets carrying MPLS getting to grandma's firewall is > > > really stretching the argument but ... > > > > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > > checksum can still be filled in so the IP destination is checked and > > > grandma need not worry about these packets. But ... > > > > > > Grandma's firewall would block since there is no state established on > > > the firewall with the opposite port pair pattern. But ... > > > > > > Even if it went through when the packet reached grandma's subnet the > > > payload is junk bound to an unused port. Maybe it hits grandma's DNS > > > server and is interpreted as a badly malformed DNS request. > > > > > > So grandma seems safe from these bad packets. > > > > > > Lack of UDP checksum should at worst mean that the destination gets a > > > packet with a munged payload, pulls off the IP and UDP headers and > > > continues to forward. At worst has the wrong MPLS label and gets > > > blackholed in the provider network somewhere. If it ends up at the > > > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > > > UDP payload carried in that IP got munged the packet could end up at > > > the destination with a bad TCP or UDP checksum and get dropped. > > > > > > Curtis From curtis@ipv6.occnc.com Wed Jan 22 12:47:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECDE1A0158 for ; Wed, 22 Jan 2014 12:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 UdGexcmfUH7P for ; Wed, 22 Jan 2014 12:47:22 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id BAF481A0140 for ; Wed, 22 Jan 2014 12:47:21 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0MKlEFD087939; Wed, 22 Jan 2014 15:47:14 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401222047.s0MKlEFD087939@maildrop2.v6ds.occnc.com> To: "Eggert, Lars" From: Curtis Villamizar In-reply-to: Your message of "Wed, 22 Jan 2014 10:22:36 +0000." Date: Wed, 22 Jan 2014 15:47:14 -0500 Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:47:23 -0000 I personally don't think that Lars' suggestion of putting a MUST in the "only in service providers" wording is a problem. Others OK with this? Curtis In message "Eggert, Lars" writes: --Apple-Mail=_284C6D2D-E30E-41B4-B7BA-E4CB74F1B323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi, On 2014-1-22, at 11:12, Xuxiaohu wrote: > I wonder whether the following text is OK to you: >=20 > Since the MPLS-in-UDP encapsulation causes MPLS packets to be = forwarded through "UDP tunnels", the congestion control guidelines for = UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. = Specifically, MPLS can carry a number of different protocols as = payloads. When an UDP tunnel is used for MPLS payload traffic that is = known at configuration time to be IP-based and congestion-controlled, = the UDP tunnel SHOULD NOT employ its own congestion control mechanism, = because congestion losses of tunneled traffic will trigger an congestion = response at the original senders of the tunneled traffic. When an UDP = tunnel is used for MPLS payload traffic that is known at configuration = time not to be IP-based and congestion-controlled, the UDP tunnel SHOULD = employ an appropriate congestion control mechanism as described in = [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such = encapsulation technology only within a SP network or networks of an = adjacent set of co-operating SPs, rather than over the Internet. = Furthermore, packet filters should be added to block traffic with the = UDP port number for MPLS over UDP to prevent MPLS over UDP packets to = escape from the service provider networks due to misconfiguation or = packet errors. I think it would be better to describe the OAM control loop in (some) = more detail, rather than pointing to RFC3985, which doesn't have a whole = lot of detail either. Also because the adding of firewall rules requires = an OAM hook. Since STRONGLY RECOMMENDED is not an RFC2119 term and RECOMMENDED is too = weak, I'd suggest to change this to MUST. Finally, the applicability statement should be prominently made in the = abstract, introduction, etc. Lars --Apple-Mail=_284C6D2D-E30E-41B4-B7BA-E4CB74F1B323 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----- iQCVAwUBUt+b6dZcnpRveo1xAQLkKQQAhc+emA26F89+q5G6IaoweMLZmVAwDKhM Ho2jImsrh7Wxbez8DlKpGXarvLiWvVKvEMFTTm4hr5NpUQfGxhdtQqy9JKk+PlJL SCmg/gM3ntpfRARKFHrDqwZoT0xxqgw10oI7eurSKAWQ8C5UhOVi8Wwk5I+0tT5w dXXm1tFJ/jA= =TPMR -----END PGP SIGNATURE----- --Apple-Mail=_284C6D2D-E30E-41B4-B7BA-E4CB74F1B323-- From nobo@cisco.com Wed Jan 22 14:00:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE8D1A037B for ; Wed, 22 Jan 2014 14:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 Tlp4DTiXYaEX for ; Wed, 22 Jan 2014 14:00:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 771CF1A038D for ; Wed, 22 Jan 2014 14:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19300; q=dns/txt; s=iport; t=1390428017; x=1391637617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fSkmDFG32AVEhIQDNA+mzTzAJXAo7VSWLbDaKmAR05c=; b=LOxwVvLrOX2xrya/otldtTJ97L1Sc6ueximp1QiIS7cFGRqwKG7R0lpn 5Qha/urmIhyvYo3MLKQAAE8sXuai66mBF2iwK4w88BrThufNX+7hKZ99+ t5HBx/KLA/A/OgZRjraHOE8BV9OD9toVkRay/njkXNOKXVhj4g6dtagmt w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FANk+4FKtJXG8/2dsb2JhbABbgmshOFa7XoETFnSCJQEBAQQOLCsCBwsMBAIBCBEEAQELFAUEBzIUCQgCBA4FCId9AcQRF44kJwYrBwIEgx6BFASqOoFvgT6BaEI X-IronPort-AV: E=Sophos;i="4.95,702,1384300800"; d="scan'208";a="299081379" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 22 Jan 2014 22:00:16 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0MM0GU2026626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 22:00:16 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 16:00:15 -0600 From: "Nobo Akiya (nobo)" To: "curtis@ipv6.occnc.com" Thread-Topic: Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping Thread-Index: AQHPFnVQqNAJ0+0KI0u/55coQMgJMJqRSc0w Date: Wed, 22 Jan 2014 22:00:15 +0000 Message-ID: References: Your message of "Sun, 19 Jan 2014 17:02:49 +0000." <201401210652.s0L6qDAc053024@maildrop2.v6ds.occnc.com> In-Reply-To: <201401210652.s0L6qDAc053024@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org" , Curtis Villamizar , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 22:00:23 -0000 Hi Curtis, Thanks again for detailed comments! Point is well taken for additional cases. For the load balancing cases you've listed, there are two cases of each whe= n considering stitched/hierarchical LSP. 1. LSRs which load balances on the cases you mentioned and forwards the pac= ket. 2. LSRs which load balances on the cases you mentioned, pushes EL and forwa= rds the packet. MPLS echo reply will need to differentiate both cases, mapping carried in c= ase of (2). Today, despite large number of cases already existing, LSP ping/trace multi= path capability remains to be functional and used by many operators. Introd= uction of EL will break these "working cases", and my current focus on this= draft will continue to be addressing the "working cases" when EL is in the= picture. With that said, having tools (whether LSP ping/trace multipath or otherwise= ) to deterministically discover and exercise MPLS ECMP for all cases of MPL= S load balancing is a goal which I highly support. I'd like to suggest taki= ng this up as a separate effort outside of this draft. If WG consensus is t= o use this draft as a vehicle to do so, then I'm willing to contribute. As result of your comments (thank you for them!), I plan to make following = change in the next revision. 1. Add a section describing the cases which LSP ping/trace multipath worked= , got broken with EL and being addressed by this draft. 2. Add terminology section. 3. Mention RFC6424 in introduction when RFC4379 is mentioned. 4. Fix the paragraph describing EL-FEC/NIL-FEC. 5. Replace "transport layer" to text you suggested. 6. s/indicate and entropy/indicate an entropy/ 7. Sec 5.2 third bullet, split into sub-bullets. Same treatment to similar. -Nobo > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > Sent: Tuesday, January 21, 2014 1:52 AM > To: Nobo Akiya (nobo) > Cc: curtis@ipv6.occnc.com; Loa Andersson; Sriganesh Kini; Xuxiaohu; Curti= s > Villamizar; Daniel King; mpls-chairs@tools.ietf.org; draft-akiya-mpls- > entropy-lsp-ping@tools.ietf.org; mpls@ietf.org > Subject: Re: Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp- > ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping >=20 >=20 > In message x01.cisco.com> > "Nobo Akiya (nobo)" writes: > > > > Hi Curtis, > > > > Thanks for detailed comments. > > > > > Overall a good draft and should become a WG doc as it is an > > > improvement to a fairly badly designed feature of MPLS Ping that > > > remains fairly badly designed but now a little less broken for ELI/EL= . > > > > > > I'm not sure the procedures that are defined work correctly if an > > > LSR does load split on the label stack (or part of it) up to and > > > then including the EL, but nothing after the EL. There seems to be > > > an assumption that only the EL is used if present. The way the RFC > > > 6790 reads the search for entropy stops at the EL (a SHOULD that woul= d > have been better made a MUST). > > > > Assumption here is that label stack up to ELI/EL is constant for LSP > > tracing purpose, thus defined procedure will work whether transit LSR > > load balances on just (EL) or (label stack up to EL + EL). This > > assumption is most probably worth being mentioned in the document, > and > > we will plan to do so. >=20 > What I meant was you don't know what an LSR will do with the label entrie= s > below ELI/EL since RFC 6790 makes stopping the search for further entropy > a SHOULD. An LSP carrying MPLS traffic will have other things under the > ELI/EL. >=20 > > The other tricky aspect depends on the outcome of > > draft-ravisingh-mpls-el-for-seamless-mpls. If multiple ELI/ELs are > > allowed in the label stack, and there are no clear defined forwarding > > rule on load balancing in that case, then defined procedures will not > > work, since we now have 2 (or more) non-constant values. I spoke to R. > > Singh and Y. Shen at Vancouver and communicated this concern on from > > OAM perspective. >=20 > As I understand it, the load balancing SHOULD be based on the top EL > according to RFC 6790. OTOH it is only SHOULD. >=20 > > > Some (big) issues: > > > > > > {L=3D0, E=3D0} LSR load balances based on IP and does not push ELI/= EL. > > > {L=3D0, E=3D1} LSR load balances based on IP and pushes ELI/EL. > > > {L=3D1, E=3D0} LSR load balances based on label and does not push E= LI/EL. > > > {L=3D1, E=3D1} LSR load balances based on label and pushes ELI/EL. > > > > > > What about the case where the LSR load balances on both labels and on > IP? > > > If the payload is IP, the entropy from the IP header is used *in > > > addition to* the entropy from the label stack. > > > > You are right, that is still allowed by RFC6790. >=20 > And load balance on labels plus IP was always allowed before RFC 6790. >=20 > > [snip] > > Some transit LSRs look beyond the label stack for better load- > > balancing information. This is a simple, backward-compatible > > approach in networks where some ingress LSRs impose ELs and others > > don't. However, this is of limited incremental value if an EL is > > indeed present and requires more packet processing from the LSR. A > > transit LSR MAY choose to parse the label stack for the presence of > > the ELI and look beyond the label stack only if it does not find it, > > thus retaining the old behavior when needed, yet avoiding unnecessar= y > > work if not needed. > > [snip] > > > > Adding LSP traceroute support for such will require [even more] > > complexities in the tools, which I personally would prefer to avoid if > > possible. I'd like to hear from WG on this, particularly those > > implementing ELI/EL. If there are any vendors looking at EL + IP for > > load balancing when EL is present, and if we want this scenario to > > also be supported by LSP traceroute, then we need to address this. >=20 > Do you want tools that work for some networks and not others? If you > want tools that work for all allowed behavior then you will need some > complexity given the way the RFCs are defined. >=20 > > > There should also be a flag to indicate that the LSR will terminate > > > the search for entropy at the EL as it SHOULD according to RFC 6790. > > > > Wouldn't such flag potentially cause load balancing deviation between > > traffic vs. MPLS echo request? >=20 > The flag would be set in the Echo Reply and indicate which of these > behaviors the LSR will be using on the traffic. >=20 > > > The flags points to an issue with RFC 4379 even without ELI/EL that > > > is still not addressed here. What if the typical payload contains > > > both additional labels (payload is MPLS) and IP under the labels and > > > some LSR look at only the IP and some look at only the labels and > > > some look at both and some that look at labels can only look at the t= op > N or the bottom N labels. > > > > Prior to this draft, supported scenarios were: > > 1. LSP which all LSR load balances just on IP as entropy. > > 2. LSP which all LSR load balances just on label stack as entropy. >=20 > Which is why I've mentioned a number of times on MPLS WG mailing list > and at meetings that the support for multipath in LSP Ping was broken. > There are LSR that use both. >=20 > > With this draft, we intend to add support for following scenario. > > 3. LSP which all LSR load balances on IP as entropy OR label stack as > > entropy (assuming constant label stack + one EL). > > 4. Stitched/Hierarchical LSPs with ELI/EL push/pop operations by transi= t > nodes. > > > > Which both scenario a very likely realistic scenario. >=20 > And if that is all you cover, then LSP Ping remains broken. >=20 > > Agree that there are many load balance implementations possibilities. > > I wish there was a clear load balance rules defined from the > > beginning. I also wish there _is_ a clear load balance rules defined > > today ... is there one? Without clear defined rules, OAM is placed in > > a very difficult position: i.e. solving all theoretically possible > > scenarios will significantly complicate the tools to the point where > > desire to implement will likely significantly diminish. > > > > All this to say, your comment raises a great point that perhaps we > > should take a step back and find out the realistic combinations which > > WG plans to solve from OAM perspective. >=20 > LSP Ping should cover all of the cases that are legal: >=20 > IP only > labels only > both IP and labels >=20 > No EL support >=20 > EL support also using labels above ELI/EL > EL support throwing out anything above ELI/EL, using EL only >=20 > EL support terminating at EL > EL support but also using labels below EL >=20 > There are quite a few combinations. Add to this: >=20 > only the top N labels > up to M bottom labels for label stack of up to N labels (M < N) >=20 > can only find IP stack if label stack <=3D depth of N >=20 > hash on special labels > special labels are skipped > skip special labels but count toward limits >=20 > This is why some flags are needed so that the LSR can in the Echo Reply > indicate how it behaves. >=20 > Any change to RFC 4379 should document how to deal with each of the > cases as best as possible. >=20 > > > Also the max depth in RFC 4379 is inadequate since some LSR can look > > > at labels up to some depth D1 and can find an IP header if it > > > appears at up to some depth D2 and D1 !=3D D2. These two depths are > > > not independent in RFC 4379. > > > > Noted. > > > > > > > > A few additional flags and values need to be carried if these cases > > > are all to be covered. OTOH, RFC 4379 works fine for a single > > > vendor network if all their products behave in the same way. > > > > > > This draft acknowledges that there are some issues (including with > > > E=3D0 that existing in RFC 4379 prior to ELI/EL) but doesn't fix them > > > even though they are fixable: > > > > > > In following conditions, initiating LSR may have lost the ability > > > to exercise specific ECMP paths. Initiating LSR MAY continue with > > > "best effort". > > > > > > o Received echo reply contains empty multipath information. > > > > > > o Received echo reply contains {L=3D0, E=3D} DS flags, but d= oes > > > not contain IP multipath information. > > > > > > o Received echo reply contains {L=3D1, E=3D} DS flags, but d= oes > > > not contain label multipath information. > > > > > > o Received echo reply contains {L=3D, E=3D1} DS flags, but d= oes > > > not contain associated label multipath information. > > > > > > o IP multipath information types {2, 4, 8} sent, and received ech= o > > > reply with {L=3D1, E=3D0} in DS flags. > > > > > > o Multipath information type {10} sent, and received echo reply > > > with multipath information type other than {10}. > > > > Correct, we acknowledge the scenarios which we do not support. This > > goes back to the point [above] of what scenarios we want to fix. We > > can use some help from WG to define this space. >=20 > The problem here is that if one LSR uses labels only and another uses IP > only and the LSP is carrying MPLS traffic (traffic payload already has la= bels) > with IP under it, then the traffic exercises all paths but the OAM just g= ives > up. >=20 > > > On the topic of flags, the N bit was always problematic. When TTL > > > is incremented the LSR will behave as if the packet is IP, because it= is. > > > > Interesting point, didn't think about this one, but yes I agree, it's > > troublesome. >=20 > So the N bit does nothing useful. >=20 > > > The flags and defined behavior for this failure is an improvement > > > over RFC > > > 4379 where the behavior was undefined both in terms of what to put > > > in the reply and how the initiator should interpret it. > > > > > > Througout the document it is not clear what an IP load balancer is. > > > For example:` > > > > > > o When initiating LSR is IP based load balancer (not pushing ELI/ > > > EL), initialize EL_LSP=3DFalse. > > > > > > The initiating LSR may be a carrying MPLS traffic (ie: a PSC LSP). > > > Therefore is may get traffic that already has an ELI/EL in the stack. > > > > > > This is not worded clearly for the case where the LSR is capable of > > > IP based load balance but is not pushing an ELI/EL but it has > > > already seen an ELI/EL on the stack. Need to clarify whether the LSR= is > an "IP based load balancer" > > > if it is capable of IP based load balance or if it would have done > > > IP based load balance on this stack. > > > > To trace the LSP starting from such LSR, I don't believe *stitching > > behavior* of the LSR is not relevant. Yes such LSR can be egress of > > ELC LSP, but [some] packets MAY or MAY NOT come in with ELI/EL, when > > ELI/EL is pushed is up to ingress to decide. If we want to diagnose > > the *stitching behavior* of the LSR, we will have to initiate the LSP > > traceroute from prior LSP. >=20 > I'm thinking of hierarchy, not stitching. The existing ELI/EL in the tra= ffic is > on the stack after the client LSP label. >=20 > > > The term "IP Based Load Balancer" is never defined. > > > > > > The term "Label Based Load Balancer" is never defined. > > > > Good point. We will add a terminology for those. >=20 > Thanks. >=20 > > > It is not clear which to pick if an LSR can use both types of > > > information as would be the case for many routers when no ELI/EL is > found in the stack. > > > > This one, again, goes back to the problem-space point above. >=20 > If that is the behavior of an LSR then LSP Ping doesn't work. Leaving a = big > hole in LSP Ping is not a good thing. >=20 > > > In "9. Unsupported Cases" you might as well admit "won't ever work > > > for some vendor's equipment that uses the whole label stack to load > > > balance plus can use IP stack". > > > > ACK. Until problem-space is defined, we will clarify these assumption > > which proposal is intended work. > > > > > The two unsupported cases are: > > > > > > o When one or more LSP transit node(s) performs label based load > > > balancing on a label that is not bottom-of-stack label when > > > Entropy Label Indicator is not included. > > > > > > A lot of equipment uses all of the labels. Did you means does not > > > use the bottom label? > > > > Good point. We will rephrase above. > > > > > > > > o When one or more LSP transit node(s) performs label based load > > > balancing on a label other than Entropy Label when Entropy Labe= l > > > Indicator and Entropy Label pair is included. > > > > > > It is also legal (and I think preferred) to use all of the labels up > > > to and including the first EL (but not the ELI and any other > > > reserved label). Did you means a label after the EL? > > > > It would be a good idea to rephrase above as well, thank you for > > pointing this out. > > > > > > > > Either these unsupported cases are worded wrong or something is very > > > seriously wrong with LSP Ping. > > > > > > Some minor points: > > > > > > RFC 6424 should be mentioned as soon as RFC 4379 is mentioned in the > > > intro since RFC 6424 changes RFC 4379 behavior and depricated a RFC > > > 4379 TLV and replaces it. > > > > ACK. > > > > > > > > When an MPLS echo request message is received containing a > > > FEC-Stack with an EL-FEC at the bottom of the FEC stack and is not > > > preceded by an entropy label, the responder must behave (for load > > > balancing purposes) as if the first word of the message were a > > > Pseudowire Control Word. > > > > > > This is asking for the DD-MAP or DS-MAP response to be constructed > > > as if CW was at bottom, but doesn't read that way. It reads as if > > > forwarding was changed. > > > > I will check with George on this, but I believe what he meant was: > > > > When an MPLS echo request message is received containing a > > FEC-Stack with an EL-FEC at the bottom of the FEC stack and is not > > preceded by an Nil-FEC indicating ELI, the responder must behave > > (for load balancing purposes) as if the first word of the message > > were a Pseudowire Control Word. >=20 > For LSR that look past the EL when TTL is incremented the data plane will > not behave that way. The Echo Reply should indicate that this is going t= o > happen. >=20 > > > Note that this procedure only traces to the end of the MPLS LSP at > > > transport layer (e.g. LDP and/or RSVP). > > > > > > That is not what "transport layer" means to a lot of people. Very > > > bad wording. > > > > Sorry for newbie mistake. Any wording you can suggest? >=20 > I think what you were trying to say here was: >=20 > Note that this procedure only traces to the end of the MPLS LSP that > is under test and will not verify the PW FEC. >=20 > Also: >=20 > To actually verify the PW-FEC or in the case of a MS-PW, to > determine the next pseudowire label value, the initiator MUST > repeat that step of the trace, (i.e., repeating the TTL value used) > but with the FEC- Stack modified to contain the appropriate PW-FEC. >=20 > I don't think this (the whole procedure in this paragraph actually works = for > LSR that use the whole label stack up to the EL (or fat PW label). For f= at PW > the PW and flow label will both be used. You need to put the PW label in > the stack. That is where the VCCV CW comes in handy, allowing the OAM IP > payload to be carried but not treated as IP. This CW usage (or GAL) can = be > carried into LSP Ping. >=20 > > > * Else initiating LSR MUST use multipath information type {2, > > > 4, 8, 9}. > > > > > > Exactly what should it do if load balance is affected by *either* > > > another label on the stack or a different IP under the stack? What > > > if both peices of information are used in creating load balance > > > entropy > > > (ie: what if the IP map depends on any additional labels)? > > > > Yes, let's get consensus on problem-space first. >=20 > In the past I've advocated either fixing or depricating LSP Ping multipat= h > support. >=20 > > > Nits: > > > > > > s/indicate and entropy/indicate and entropy/ > > > > Thanks & ACK on s/indicate and entropy/indicate an entropy/ >=20 > oops >=20 > > > In "5.2. IP Based Load Balancer & Pushes ELI/EL" third bullet is a > > > massive run-on paragraph. Split into sub-bullets for the multiple ca= se > within it. > > > Probably good for other bullets containing more than one sentence > > > starting with "If". > > > > Ok, will do. > > > > And again, thank you for providing detailed comments!! > > > > -Nobo >=20 > Thanks, >=20 > Curtis >=20 > > > probably plenty more nits that I missed. > > > > > > Curtis From nobo@cisco.com Wed Jan 22 14:26:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C21B1A01DA for ; Wed, 22 Jan 2014 14:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 HHii2THCptFO for ; Wed, 22 Jan 2014 14:26:42 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id D44641A04CB for ; Wed, 22 Jan 2014 14:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6187; q=dns/txt; s=iport; t=1390429601; x=1391639201; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FxBsaNfJCDwt5FTlYaneg0/CdXSTjotPs6baFbgH20I=; b=ddU1evg7WbqXFjLi9ik4/LXusBCuUDka3p0MjvWH3URaOa3YLwuIDSvZ pkqTC6KDwn1tKG7zAl57jzRFfbWFUUe5oJCFzSNwJ5IWWhqWaBFRXfl8C kQXBxPs0JIRbVTgSYxiYSOH6er3mpzOR7hXOIM5VZ8uYUPKGTH8GPDpnk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAEpF4FKtJXG9/2dsb2JhbABbgmshOFa7XoETFnSCJQEBAQMBAQEBNysCBwsFBwQCAQgRBAEBAQoUCQcnCxQJCAEBBAENBQiHdQgBDMQJEwSOGhEBHzEHBoMegRQEqjqDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,702,1384300800"; d="scan'208";a="14808744" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 22 Jan 2014 22:26:41 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0MMQf8p011681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 22:26:41 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 16:26:40 -0600 From: "Nobo Akiya (nobo)" To: Daniel King , "mpls-chairs@tools.ietf.org" , "'Martin Vigoureux'" , "draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org" Thread-Topic: [mpls] mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Thread-Index: Ac8WK1t1++A1SQXVRGCzuMh7DOHDzgBkhFLg Date: Wed, 22 Jan 2014 22:26:40 +0000 Message-ID: References: <000f01cf162b$7cee4ab0$76cae010$@olddog.co.uk> In-Reply-To: <000f01cf162b$7cee4ab0$76cae010$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] mpls-rt review for draft-akiya-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 22:26:45 -0000 Hi Dan, > Hi All, >=20 > As requested (MPLS RT), please find my brief review of draft-akiya-mpls- > entropy-lsp-ping. >=20 > The I-D updates LSP verification mechanism and Entropy Label LSPs. The I-= D > is well written with a clear intention and should be polled for WG adopti= on. >=20 >=20 > A few suggested comments/updates/NITs: >=20 > - Abstract mentions RFC4379, but this I-D is updated by RFC6424? Good question. Correct, portion of RFC4379 was updated by RFC6424. 1. RFC4379 is still the RFC which describes LSP ping/trace. 2. RFC4379 describes DSMAP. 3. RFC6424 updates RFC4379, introduced DDMAP which deprecated DSMAP. 4. DS Flags is a common field of DSMAP and DDMAP. 5. Multipath Information is a common field of DSMAP and DDMAP. 6. DSMAP is still widely used by many vendors. 7. This draft extends DS Flags, Multipath Information and procedures around= them. 8. This draft introduces EL-FEC So, (7) is technically an update to RFC6424 and (8) is an update to RFC4379= . And because of (6), this document still refers to downstream as DSMAP/DDM= AP. >=20 > - Although you expand acronyms in the "Abstract", you may want to > expand them again in the Introduction, and other parts of the document > (ECMP, EL, ELI, FAT, FEC, MS-PW, etc.). Good point, will make this change. >=20 > - The last two sentences of the final paragraph from the "Introduction" i= s > slightly truncated. I would suggest the following updated text: >=20 > >> > Section 3 of this document updates the procedures for multipath > information type {9} described in [RFC4379]. The rest of this document > describes extensions required to restore ECMP discovery and tracing > capabilities for the scenarios described. > << Oops, you are right, thanks. >=20 > - "Overview " section, second paragraph needs some minor grammar > updates and acronyms expanded. Suggest updating the text to: >=20 > >> > LSP Ping initiating LSR sends MPLS echo request with multipath informatio= n. > This multipath information is described in Downstream Mapping TLV and > Downstream Detailed Mapping TLV (DSMAP/DMAP) echo request, and may > contain a set of IP addresses or set of labels. Multipath information ty= pes > {2, 4, 8} carry a set of IP addresses and multipath information type {9} > carries a set of labels. Responder LSR (receiver of MPLS echo request) wi= ll > determine the subset of initiator specified multipath information which > load balances to each downstream (outgoing interface). Responder LSR > sends MPLS echo reply with resulting multipath information per > downstream (outgoing interface) back to the initiating LSR. Initiating L= SR is > then able to use specific IP destination address or specific label to exe= rcise > specific ECMP path on the responder LSR. > << ACK, thanks. >=20 > - "Overview" section, third bullet. Suggest updating text to: >=20 > >> > Initiating LSR sends existing multipath information to LSR which pushes > ELI/EL in label stack, but the initiating LSR can only continue to discov= er and > exercise specific path of ECMP, if the LSR which pushes ELI/EL responds w= ith > both IP addresses and associated EL corresponding to each IP address. > << Ok. >=20 > - "Multipath Type 9" section, uses "non-FAT pseudowire" terminology, then > later expands acronym to "Flow-Aware Transport Pseudowire", suggest > expanding acronym on first use. ACK. >=20 > - "Multipath Type 9" section, fourth paragraph, the use of "must" looks l= ike > it should "MUST". ACK. >=20 > - "Initiating LSR Procedures" section, not really sure what a " IP based = load > balancer" is? This was pointed out by Curtis V. as well. I will add a terminology section= . >=20 > - "FAT MS-PW Stitching LSR" section, suggest updating "xconnects" to > "cross-connects". ACK. >=20 > - General observation for your figures, I would suggest you provide figur= e > numbers/titles. ACK. Thanks for details review! -Nobo >=20 > Br, Dan. >=20 > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > Sent: 17 January 2014 05:08 > To: Loa Andersson > Cc: Sriganesh Kini; Xuxiaohu; Curtis Villamizar; Daniel King; mpls- > chairs@tools.ietf.org; draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org; > draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org > Subject: Re: Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp- > ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping >=20 > In message <52C67349.4020701@pi.nu> > Loa Andersson writes: >=20 > > Folks, > > > > This was the wrong document - I intended to have the review done for > > draft-akiya-mpls-entropy-lsp-ping sorry for the confusion. > > > > All other cordinates correct! > > > > On 2014-01-03 14:44, Loa Andersson wrote: > > > Sri, Xiaohu, Curtis and Dan, > > > > > > You have been selected as MPLS Review team reviewers for > > > draft-akiya-mpls-entropy-lsp-ping-01. > > > > > > Note to authors: You have been CC'd on this email so that you can > > > know that this review is going on. However, please do not review > > > your own document. > > > > > > Reviews should comment on whether the document is coherent, is it > > > useful (ie, is it likely to be actually useful in operational > > > networks), and is the document technically sound? We are interested > > > in knowing whether the document is ready to be considered for WG > > > adoption (ie, it doesn't have to be perfect at this point, but > > > should be a good start). > > > > > > Reviews should be sent to the document authors, WG co-chairs and WG > > > secretary, and CC'd to the MPLS WG email list. If necessary, > > > comments may be sent privately to only the WG chairs. > > > > > > Are you able to review this draft by January 20, 2014? > > > > > > Thanks, Loa > > > (as MPLS WG chair) > > > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From xuxiaohu@huawei.com Wed Jan 22 17:25:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ADB1A024F for ; Wed, 22 Jan 2014 17:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 1M3WkvxBmFKh for ; Wed, 22 Jan 2014 17:25:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 54B0D1A0147 for ; Wed, 22 Jan 2014 17:24:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCV18197; Thu, 23 Jan 2014 01:24:58 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 01:24:41 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 01:24:56 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 23 Jan 2014 09:24:52 +0800 From: Xuxiaohu To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF9npYjmekYulOkuMeDluALM0qw== Date: Thu, 23 Jan 2014 01:24:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082471F3@NKGEML512-MBS.china.huawei.com> References: Your message of "Wed, 22 Jan 2014 10:12:22 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> <201401222042.s0MKgoTZ087832@maildrop2.v6ds.occnc.com> In-Reply-To: <201401222042.s0MKgoTZ087832@maildrop2.v6ds.occnc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Joel Jaeggli , "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 01:25:03 -0000 SGkgQ3VydGlzLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgc3VnZ2VzdGlvbnMuIEkgd291bGQg aW5jb3Jwb3JhdGUgdGhlbSBpbnRvIHRoZSBuZXh0IHZlcnNpb24uDQoNCkJlc3QgcmVnYXJkcywN ClhpYW9odQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IEN1cnRpcyBWaWxsYW1p emFyIFttYWlsdG86Y3VydGlzQGlwdjYub2NjbmMuY29tXQ0KPiC3osvNyrG85DogMjAxNMTqMdTC MjPI1SA0OjQzDQo+IMrVvP7IyzogWHV4aWFvaHUNCj4gs63LzTogRWdnZXJ0LCBMYXJzOyBjdXJ0 aXNAaXB2Ni5vY2NuYy5jb207IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBS ZTogtPC4tDogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0 PiAoRW5jYXBzdWxhdGluZw0KPiBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4g DQo+IA0KPiBJbiBtZXNzYWdlDQo+IDwxRkVFM0Y4RjVDQ0RFNjRDOUE4RThGNEFEMjdDMTlFRTA4 MjQ2Q0EzQE5LR0VNTDUxMi1NQlMuY2hpbmEuDQo+IGh1YXdlaS5jb20+DQo+IFh1eGlhb2h1IHdy aXRlczoNCj4gDQo+ID4gSGkgYWxsLA0KPiA+DQo+ID4gVGhhbmtzIGEgbG90IGZvciB5b3VyIGNv bW1lbnRzLg0KPiA+DQo+ID4gSSB3b25kZXIgd2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMg T0sgdG8geW91Og0KPiA+DQo+ID4gICAgU2luY2UgdGhlIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRp b24gY2F1c2VzIE1QTFMgcGFja2V0cyB0byBiZQ0KPiA+ICAgIGZvcndhcmRlZCB0aHJvdWdoICJV RFAgdHVubmVscyIsIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgZ3VpZGVsaW5lcw0KPiA+ICAgIGZv ciBVRFAgdHVubmVscyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjMgb2YgW1JGQzU0MDVdIFNI T1VMRCBiZQ0KPiA+ICAgIGZvbGxvd2VkLiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5IGEg bnVtYmVyIG9mIGRpZmZlcmVudA0KPiA+ICAgIHByb3RvY29scyBhcyBwYXlsb2Fkcy4gV2hlbiBh biBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZA0KPiA+ICAgIHRyYWZmaWMgdGhh dCBpcyBrbm93biBhdCBjb25maWd1cmF0aW9uIHRpbWUgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4g ICAgY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUgVURQIHR1bm5lbCBTSE9VTEQgTk9UIGVtcGxv eSBpdHMgb3duDQo+ID4gICAgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSwgYmVjYXVzZSBj b25nZXN0aW9uIGxvc3NlcyBvZiB0dW5uZWxlZA0KPiA+ICAgIHRyYWZmaWMgd2lsbCB0cmlnZ2Vy IGFuIGNvbmdlc3Rpb24gcmVzcG9uc2UgYXQgdGhlIG9yaWdpbmFsIHNlbmRlcnMNCj4gPiAgICBv ZiB0aGUgdHVubmVsZWQgdHJhZmZpYy4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1Q TFMNCj4gPiAgICBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcyBrbm93biBhdCBjb25maWd1cmF0aW9u IHRpbWUgbm90IHRvIGJlDQo+ID4gICAgSVAtYmFzZWQgYW5kIGNvbmdlc3Rpb24tY29udHJvbGxl ZCwgdGhlIFVEUCB0dW5uZWwgU0hPVUxEIGVtcGxveSBhbg0KPiA+ICAgIGFwcHJvcHJpYXRlIGNv bmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluDQo+ID4gICAgW1JGQzM5 ODVdLiBOb3RlIHRoYXQgaXQgU1RST05HTFkgUkVDT01NRU5ERUQgdG8gZGVwbG95IHN1Y2gNCj4g PiAgICBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kgb25seSB3aXRoaW4gYSBTUCBuZXR3b3JrIG9y IG5ldHdvcmtzIG9mIGFuDQo+ID4gICAgYWRqYWNlbnQgc2V0IG9mIGNvLW9wZXJhdGluZyBTUHMs IHJhdGhlciB0aGFuIG92ZXIgdGhlDQo+ID4gICAgSW50ZXJuZXQuIEZ1cnRoZXJtb3JlLCBwYWNr ZXQgZmlsdGVycyBzaG91bGQgYmUgYWRkZWQgdG8gYmxvY2sNCj4gPiAgICB0cmFmZmljIHdpdGgg dGhlIFVEUCBwb3J0IG51bWJlciBmb3IgTVBMUyBvdmVyIFVEUCB0byBwcmV2ZW50IE1QTFMNCj4g PiAgICBvdmVyIFVEUCBwYWNrZXRzIHRvIGVzY2FwZSBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVy IG5ldHdvcmtzIGR1ZQ0KPiA+ICAgIHRvIG1pc2NvbmZpZ3VhdGlvbiBvciBwYWNrZXQgZXJyb3Jz Lg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiANCj4gWGlhb2h1LA0KPiAN Cj4gTG9va3MgZ29vZC4NCj4gDQo+IEEgZmV3IG5pdHM6DQo+IA0KPiBzL2FuIGNvbmdlc3Rpb24g cmVzcG9uc2UvYSBjb25nZXN0aW9uIHJlc3BvbnNlLw0KPiANCj4gcy9Ob3RlIHRoYXQgaXQgU1RS T05HTFkgUkVDT01NRU5ERUQvTm90ZSB0aGF0IGl0IGlzIFNUUk9OR0xZDQo+IFJFQ09NTUVOREVE Lw0KPiANCj4gcy90byBkZXBsb3kgc3VjaCBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kgIC90aGF0 IHN1Y2ggZW5jYXBzdWxhdGlvbg0KPiB0ZWNobm9sb2d5IGJlIGRlcGxveWVkLw0KPiANCj4gcy9V RFAgcGFja2V0cyB0byBlc2NhcGUgZnJvbS9VRFAgcGFja2V0cyBmcm9tIGVzY2FwaW5nLw0KPiAN Cj4gSSBzdWdnZXN0IHRoYXQgeW91IGFsc28gYWRkIGEgcGFyYWdyYXBoIHNheWluZyB0aGF0IFVE UCBjaGVja3N1bXMgU0hPVUxEIGJlDQo+IHVzZWQgaW4gYWxsIGNhc2VzIHdoZXJlIGl0IGlzIGZl YXNpYmxlIHRvIGRvIHNvLiAgVHJ5IHRvIGNhcHR1cmUgdGhlIHJlYXNvbmluZw0KPiBiZWhpbmQg dGhlIHRzdndnIHJlY29tbWVuZGF0aW9ucyB0aGF0IFVEUCBjaGVja3N1bXMgYmUgdXNlZCB3aGVu ZXZlciBpdCBpcw0KPiBwb3NzaWJsZSB0byBkbyBzby4gIFlvdSBjYW4gb3B0aW9uYWxseSBhZGQg d29yZGluZyBmcm9tIHBhc3QgZW1haWwgb3V0bGluaW5nDQo+IHRoZSBrbm93biBjYXNlcyB3aGVy ZSBhZGRpbmcgVURQIGNoZWNrc3VtcyBhcmUgaW5mZWFzaWJsZSAoc3VjaCBhcw0KPiBjdXQtdGhy b3VnaCByb3V0aW5nKS4NCj4gDQo+IHRoYW5rcy4NCj4gDQo+IEN1cnRpcw0KPiANCj4gDQo+ID4g PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ILeivP7IyzogbXBscyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBFZ2dlcnQsIExhcnMNCj4gPiA+ILeiy83KsbzkOiAyMDE0xOox 1MIyMsjVIDE1OjUyDQo+ID4gPiDK1bz+yMs6IGN1cnRpc0BpcHY2Lm9jY25jLmNvbQ0KPiA+ID4g s63LzTogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiDW98ziOiBSZTogW21wbHNd IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gKEVuY2Fw c3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPg0KPiA+ID4g VGhpcyBpcyBub3QgYXQgYWxsIHRoZSBhcmd1bWVudCBJIGFtIG1ha2luZy4gTXkgZW1haWxzIGhh dmUgbm90DQo+ID4gPiB0b3VjaGVkIGF0IGFsbCBvbiB0aGUgaXNzdWUgb2YgemVybyBjaGVja3N1 bXMuDQo+ID4gPg0KPiA+ID4gTXkgcG9pbnQgaXMgdGhhdCBVRFAgZW5jYXBzdWxhdGlvbiBjaGFu Z2VzIHRoZSBwb3RlbnRpYWwgKnJlYWNoKiBvZg0KPiA+ID4gY29uZ2VzdGlvbi11bmNvbnRyb2xs ZWQgdHJhZmZpYyB0aGF0IHdhcyBvdGhlcndpc2UgbGltaXRlZCB0byBMMiBuZXR3b3Jrcy4NCj4g PiA+DQo+ID4gPiBMYXJzDQo+ID4gPg0KPiA+ID4gT24gMjAxNC0xLTIxLCBhdCAyMToxNCwgQ3Vy dGlzIFZpbGxhbWl6YXIgPGN1cnRpc0BpcHY2Lm9jY25jLmNvbT4gd3JvdGU6DQo+ID4gPg0KPiA+ ID4gPg0KPiA+ID4gPiBJbiBtZXNzYWdlIDw1NThBMTVBOS0yMDRBLTQ0NDctOTIzQy01OERDMkEz Q0VEOEFAbmV0YXBwLmNvbT4NCj4gPiA+ID4gIkVnZ2VydCwgTGFycyIgd3JpdGVzOg0KPiA+ID4g Pg0KPiA+ID4gPj4gSGksDQo+ID4gPiA+Pg0KPiA+ID4gPj4gT24gMjAxNC0xLTIxLCBhdCAxMjo1 MCwgU3Rld2FydCBCcnlhbnQgPHN0YnJ5YW50QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gPiA+Pj4g SW4gdGVybXMgb2YgY29uZ2VzdGlvbiBhbmQgbWlzZGVsaXZlcnkgaXQgaXMgaW50ZXJlc3Rpbmcg bG9va2luZw0KPiA+ID4gPj4+IGF0IHRoZSBudW1iZXIgb2YgaG9yc2VzIHRoYXQgYXJlIGFscmVh ZHkgYm91bmRpbmcgYXJvdW5kIGluIHRoZQ0KPiA+ID4gPj4+IHBhZGRvY2sgb3V0c2lkZSB0aGUg c3RhYmxlOg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gSVAgdHlwZXM6IDQ3IChHUkUpIGFuZCAxMzcg KE1QTFMtaW4tSVApIGZvciBleGFtcGxlLg0KPiA+ID4gPj4NCj4gPiA+ID4+IHRoZXJlIGlzIGEg YmlnIGRpZmZlcmVuY2UgYmV0d2VlbiBlbmNhcHN1bGF0aW9uIGluIElQIGFuZA0KPiA+ID4gPj4g ZW5jYXBzdWxhdGlvbiBpbiBVRFAuIEV2ZXJ5dGhpbmcgZW5jYXBzdWxhdGVkIHdpdGggIm9ic2N1 cmUiIElQDQo+ID4gPiA+PiBwcm90b2NvbCBudW1iZXJzIHdpbGwgZ2V0IGRyb3BwZWQgYnkgZGVm YXVsdCBhdCBOQVRzIGFuZA0KPiA+ID4gPj4gZmlyZXdhbGxzLCB3aGVyZWFzIFVETyB0cmFmZmlj IGhhcHBpbHkgdHJhdmVyc2VzIHRoZW0uIFRoZSByZWFjaA0KPiA+ID4gPj4gb2YgVURQIHRyYWZm aWMgaXMgbXVjaCBicm9hZGVyLg0KPiA+ID4gPj4NCj4gPiA+ID4+IExhcnMNCj4gPiA+ID4NCj4g PiA+ID4NCj4gPiA+ID4gU3RyYXkgVURQIHBhY2tldHMgY2FycnlpbmcgTVBMUyBnZXR0aW5nIHRv IGdyYW5kbWEncyBmaXJld2FsbCBpcw0KPiA+ID4gPiByZWFsbHkgc3RyZXRjaGluZyB0aGUgYXJn dW1lbnQgYnV0IC4uLg0KPiA+ID4gPg0KPiA+ID4gPiBXaGVuIGVuY2Fwc3VsYXRpbmcgaW4gVURQ LCB0aGUgVURQIGNoZWNrc3VtIG1pZ2h0IGJlIHplcm8gYnV0IHRoZQ0KPiA+ID4gPiBJUCBjaGVj a3N1bSBjYW4gc3RpbGwgYmUgZmlsbGVkIGluIHNvIHRoZSBJUCBkZXN0aW5hdGlvbiBpcw0KPiA+ ID4gPiBjaGVja2VkIGFuZCBncmFuZG1hIG5lZWQgbm90IHdvcnJ5IGFib3V0IHRoZXNlIHBhY2tl dHMuICBCdXQgLi4uDQo+ID4gPiA+DQo+ID4gPiA+IEdyYW5kbWEncyBmaXJld2FsbCB3b3VsZCBi bG9jayBzaW5jZSB0aGVyZSBpcyBubyBzdGF0ZSBlc3RhYmxpc2hlZA0KPiA+ID4gPiBvbiB0aGUg ZmlyZXdhbGwgd2l0aCB0aGUgb3Bwb3NpdGUgcG9ydCBwYWlyIHBhdHRlcm4uICBCdXQgLi4uDQo+ ID4gPiA+DQo+ID4gPiA+IEV2ZW4gaWYgaXQgd2VudCB0aHJvdWdoIHdoZW4gdGhlIHBhY2tldCBy ZWFjaGVkIGdyYW5kbWEncyBzdWJuZXQNCj4gPiA+ID4gdGhlIHBheWxvYWQgaXMganVuayBib3Vu ZCB0byBhbiB1bnVzZWQgcG9ydC4gIE1heWJlIGl0IGhpdHMNCj4gPiA+ID4gZ3JhbmRtYSdzIERO UyBzZXJ2ZXIgYW5kIGlzIGludGVycHJldGVkIGFzIGEgYmFkbHkgbWFsZm9ybWVkIEROUw0KPiBy ZXF1ZXN0Lg0KPiA+ID4gPg0KPiA+ID4gPiBTbyBncmFuZG1hIHNlZW1zIHNhZmUgZnJvbSB0aGVz ZSBiYWQgcGFja2V0cy4NCj4gPiA+ID4NCj4gPiA+ID4gTGFjayBvZiBVRFAgY2hlY2tzdW0gc2hv dWxkIGF0IHdvcnN0IG1lYW4gdGhhdCB0aGUgZGVzdGluYXRpb24NCj4gPiA+ID4gZ2V0cyBhIHBh Y2tldCB3aXRoIGEgbXVuZ2VkIHBheWxvYWQsIHB1bGxzIG9mZiB0aGUgSVAgYW5kIFVEUA0KPiA+ ID4gPiBoZWFkZXJzIGFuZCBjb250aW51ZXMgdG8gZm9yd2FyZC4gIEF0IHdvcnN0IGhhcyB0aGUg d3JvbmcgTVBMUw0KPiA+ID4gPiBsYWJlbCBhbmQgZ2V0cyBibGFja2hvbGVkIGluIHRoZSBwcm92 aWRlciBuZXR3b3JrIHNvbWV3aGVyZS4gIElmDQo+ID4gPiA+IGl0IGVuZHMgdXAgYXQgdGhlIGNv cnJlY3QgTVBMUyBlZ3Jlc3MsIGlmIElQLCB0aGUgSVAgY2hlY2tzdW0gaXMNCj4gPiA+ID4gY2hl Y2tlZC4gIElmIGEgVENQIG9yIFVEUCBwYXlsb2FkIGNhcnJpZWQgaW4gdGhhdCBJUCBnb3QgbXVu Z2VkDQo+ID4gPiA+IHRoZSBwYWNrZXQgY291bGQgZW5kIHVwIGF0IHRoZSBkZXN0aW5hdGlvbiB3 aXRoIGEgYmFkIFRDUCBvciBVRFANCj4gY2hlY2tzdW0gYW5kIGdldCBkcm9wcGVkLg0KPiA+ID4g Pg0KPiA+ID4gPiBDdXJ0aXMNCg0K From xuxiaohu@huawei.com Wed Jan 22 19:00:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8181A0249 for ; Wed, 22 Jan 2014 19:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 pveDbfHBjId3 for ; Wed, 22 Jan 2014 19:00:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE471A00DD for ; Wed, 22 Jan 2014 19:00:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAI21780; Thu, 23 Jan 2014 03:00:49 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 03:00:33 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 03:00:47 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 23 Jan 2014 11:00:42 +0800 From: Xuxiaohu To: "Eggert, Lars" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAZGOsA== Date: Thu, 23 Jan 2014 03:00:41 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472A1@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> 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.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 03:00:54 -0000 SGkgTGFycywNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBFZ2dlcnQsIExhcnMg W21haWx0bzpsYXJzQG5ldGFwcC5jb21dDQo+ILeiy83KsbzkOiAyMDE0xOox1MIyMsjVIDE4OjIz DQo+IMrVvP7IyzogWHV4aWFvaHUNCj4gs63LzTogY3VydGlzQGlwdjYub2NjbmMuY29tOyBKb2Vs IEphZWdnbGk7IG1wbHNAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxk cmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUw0KPiBpbiBV RFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiBIaSwNCj4gDQo+IE9uIDIwMTQtMS0yMiwg YXQgMTE6MTIsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiBJIHdv bmRlciB3aGV0aGVyIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBPSyB0byB5b3U6DQo+ID4NCj4gPiBT aW5jZSB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiBjYXVzZXMgTVBMUyBwYWNrZXRzIHRv IGJlIGZvcndhcmRlZA0KPiB0aHJvdWdoICJVRFAgdHVubmVscyIsIHRoZSBjb25nZXN0aW9uIGNv bnRyb2wgZ3VpZGVsaW5lcyBmb3IgVURQIHR1bm5lbHMgYXMNCj4gZGVmaW5lZCBpbiBTZWN0aW9u IDMuMS4zIG9mIFtSRkM1NDA1XSBTSE9VTEQgYmUgZm9sbG93ZWQuIFNwZWNpZmljYWxseSwgTVBM Uw0KPiBjYW4gY2FycnkgYSBudW1iZXIgb2YgZGlmZmVyZW50IHByb3RvY29scyBhcyBwYXlsb2Fk cy4gV2hlbiBhbiBVRFAgdHVubmVsIGlzDQo+IHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFmZmlj IHRoYXQgaXMga25vd24gYXQgY29uZmlndXJhdGlvbiB0aW1lIHRvIGJlIElQLWJhc2VkDQo+IGFu ZCBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFAgdHVubmVsIFNIT1VMRCBOT1QgZW1wbG95 IGl0cyBvd24NCj4gY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSwgYmVjYXVzZSBjb25nZXN0 aW9uIGxvc3NlcyBvZiB0dW5uZWxlZCB0cmFmZmljDQo+IHdpbGwgdHJpZ2dlciBhbiBjb25nZXN0 aW9uIHJlc3BvbnNlIGF0IHRoZSBvcmlnaW5hbCBzZW5kZXJzIG9mIHRoZSB0dW5uZWxlZCB0cmFm ZmljLg0KPiBXaGVuIGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZm aWMgdGhhdCBpcyBrbm93biBhdA0KPiBjb25maWd1cmF0aW9uIHRpbWUgbm90IHRvIGJlIElQLWJh c2VkIGFuZCBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFANCj4gdHVubmVsIFNIT1VMRCBl bXBsb3kgYW4gYXBwcm9wcmlhdGUgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSBhcw0KPiBk ZXNjcmliZWQgaW4gW1JGQzM5ODVdLiBOb3RlIHRoYXQgaXQgU1RST05HTFkgUkVDT01NRU5ERUQg dG8gZGVwbG95IHN1Y2gNCj4gZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IG9ubHkgd2l0aGluIGEg U1AgbmV0d29yayBvciBuZXR3b3JrcyBvZiBhbiBhZGphY2VudA0KPiBzZXQgb2YgY28tb3BlcmF0 aW5nIFNQcywgcmF0aGVyIHRoYW4gb3ZlciB0aGUgSW50ZXJuZXQuIEZ1cnRoZXJtb3JlLCBwYWNr ZXQNCj4gZmlsdGVycyBzaG91bGQgYmUgYWRkZWQgdG8gYmxvY2sgdHJhZmZpYyB3aXRoIHRoZSBV RFAgcG9ydCBudW1iZXIgZm9yIE1QTFMgb3Zlcg0KPiBVRFAgdG8gcHJldmVudCBNUExTIG92ZXIg VURQIHBhY2tldHMgdG8gZXNjYXBlIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXINCj4gbmV0d29y a3MgZHVlIHRvIG1pc2NvbmZpZ3VhdGlvbiBvciBwYWNrZXQgZXJyb3JzLg0KPiANCj4gSSB0aGlu ayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVzY3JpYmUgdGhlIE9BTSBjb250cm9sIGxvb3AgaW4g KHNvbWUpIG1vcmUNCj4gZGV0YWlsLCByYXRoZXIgdGhhbiBwb2ludGluZyB0byBSRkMzOTg1LCB3 aGljaCBkb2Vzbid0IGhhdmUgYSB3aG9sZSBsb3Qgb2YgZGV0YWlsDQo+IGVpdGhlci4gQWxzbyBi ZWNhdXNlIHRoZSBhZGRpbmcgb2YgZmlyZXdhbGwgcnVsZXMgcmVxdWlyZXMgYW4gT0FNIGhvb2su DQo+IA0KPiBTaW5jZSBTVFJPTkdMWSBSRUNPTU1FTkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJt IGFuZCBSRUNPTU1FTkRFRA0KPiBpcyB0b28gd2VhaywgSSdkIHN1Z2dlc3QgdG8gY2hhbmdlIHRo aXMgdG8gTVVTVC4NCg0KSXQncyBmaW5lIHRvIG1ha2UgdGhhdCBjaGFuZ2UuDQoNCj4gRmluYWxs eSwgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHNob3VsZCBiZSBwcm9taW5lbnRseSBtYWRl IGluIHRoZSBhYnN0cmFjdCwNCj4gaW50cm9kdWN0aW9uLCBldGMuDQoNClRoZSBhcHBsaWNhdGlv biBzdGF0ZW1lbnQgaXMgcHJvbWluZW50bHkgZGVzY3JpYmVkIGluIGEgZGVkaWNhdGVkIHN1Yi1z ZWN0aW9uIG9mIHRoZSBJbnRyb2R1Y3Rpb24gU2VjdGlvbiBhcyBmb2xsb3dzOg0KDQoxLjMuIEFw cGxpY2F0aW9uIFN0YXRlbWVudHMNCg0KVGhlIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24gdGVj aG5vbG9neSBNVVNUIG9ubHkgYmUgZGVwbG95ZWQgd2l0aGluIGEgU1AgbmV0d29yayBvciBuZXR3 b3JrcyBvZiBhbiBhZGphY2VudCBzZXQgb2YgY28tb3BlcmF0aW5nIFNQcyB3aGVyZSB0aGUgY29u Z2VzdGlvbiBjb250cm9sIGlzIG5vdCBhIGNvbmNlcm4sIHJhdGhlciB0aGFuIG92ZXIgdGhlIElu dGVybmV0IHdoZXJlIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgaXMgYSBtdXN0LiBGdXJ0aGVybW9y ZSwgcGFja2V0IGZpbHRlcnMgc2hvdWxkIGJlIGFkZGVkIHRvIHByZXZlbnQgTVBMUyBvdmVyIFVE UCBwYWNrZXRzIGZyb20gZXNjYXBpbmcgZnJvbSB0aGUgc2VydmljZSBwcm92aWRlciBuZXR3b3Jr cyBkdWUgdG8gbWlzY29uZmlndWF0aW9uIG9yIHBhY2tldCBlcnJvcnMuIE5vdGUgdGhhdCB0aGUg cHJvdmVuIE1QTFMtaW4tR1JFIGFuZCBNUExTLWluLUlQIFtSRkM0MDIzXSBlbmNhcHN1bGF0aW9u IHRlY2hub2xvZ2llcyB3aGljaCBoYXZlIGFscmVhZHkgYmVlbiBkZXBsb3llZCB3aXRoaW4gU1Ag bmV0d29ya3MgZG9uJ3QgcmVxdWlyZSBhbnkgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbS4N Cg0KSW4gYWRkaXRpb24sIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBhZGRlZCB0byB0aGUgYWJzdHJh Y3Qgc2VjdGlvbjoiIE5vdGUgdGhhdCB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiB0ZWNo bm9sb2d5IE1VU1Qgb25seSBiZSBkZXBsb3llZCB3aXRoaW4gYSBTUCBuZXR3b3JrIG9yIG5ldHdv cmtzIG9mIGFuIGFkamFjZW50IHNldCBvZiBjby1vcGVyYXRpbmcgU1BzIHdoZXJlIHRoZSBjb25n ZXN0aW9uIGNvbnRyb2wgaXMgbm90IGEgY29uY2Vybi4iDQoNCkR1ZSB0byB0aGUgYWJvdmUgZXhw bGljaXQgYXBwbGljYXRpb24gc3RhdGVtZW50LCBJIHdvbmRlciB3aGV0aGVyIGl0J3Mgc3RpbGwg bmVjZXNzYXJ5IHRvIGRlc2NyaWJlIHRoZSBPQU0gY29udHJvbCBsb29wIGluIChzb21lKSBtb3Jl IGRldGFpbCwgcmF0aGVyIHRoYW4gc2ltcGx5IHBvaW50aW5nIHRvIFJGQzM5ODUuIEkgZXZlbiB3 b25kZXIgd2hldGhlciBpdCdzIHN0aWxsIG5lY2Vzc2FyeSB0byByZW1haW4gdGhlIGNvbmdlc3Rp b24gY29uc2lkZXJhdGlvbiBzZWN0aW9uLiANCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4g TGFycw0K From xuxiaohu@huawei.com Wed Jan 22 19:17:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18CB1A00BF for ; Wed, 22 Jan 2014 19:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 Q_bgrkvHq28N for ; Wed, 22 Jan 2014 19:17:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6E51A0179 for ; Wed, 22 Jan 2014 19:17:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAI23059; Thu, 23 Jan 2014 03:17:00 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 03:16:44 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 03:16:58 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 23 Jan 2014 11:16:52 +0800 From: Xuxiaohu To: Alexander Vainshtein , "Eggert, Lars" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXw Date: Thu, 23 Jan 2014 03:16:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> 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.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 03:17:05 -0000 SGkgDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogQWxleGFuZGVyIFZhaW5zaHRl aW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4gt6LLzcqxvOQ6 IDIwMTTE6jHUwjIyyNUgMTk6MDUNCj4gytW8/sjLOiBFZ2dlcnQsIExhcnMNCj4gs63LzTogSm9l bCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnOyBYdXhpYW9odQ0KPiDW98ziOiBSRTogW21wbHNdIExh c3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBN UExTDQo+IGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+IExhcnMgYW5kIGFsbCwN Cj4gTGFzdCB0aW1lIEkndmUgY291bnRlZCB0aGUgSUVURiBMQyB0aHJlYWQgb24gdGhpcyBkcmFm dCBoYXMgbW9yZSB0aGFuIDE1MA0KPiBtZXNzYWdlcyBpbiBpdCwgYW5kIGl0IHNlZW1zIHRoYXQg b24gc29tZSBpc3N1ZXMgKGNvbmdlc3Rpb24gY29udHJvbCBhbmQgVURQDQo+IGNoZWNrc3Vtcykg d2UgYXJlIGdvaW5nIHJvdW5kIHRoZSBtdWxiZXJyeSBidXNoLg0KPiANCj4gSU1ITyBhbmQgRldJ VzoNCj4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJl Y2F1c2UgbmF0aXZlIE1QTFMgZG9lcyBub3QNCj4gaGF2ZSBhbnl0aGluZyBsaWtlIHRoYXQuIEFu ZCB5ZXMsIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSBwYWNrZXRzIGFyZSBjb3JydXB0ZWQNCj4gd2l0 aGluIHRoZSByb3V0ZXJzKSwgYnV0IHNvIGZhciBpdCBkaWQgbm90IHByZXZlbnQgTVBMUyBkZXBs b3ltZW50LiBUaGVyZSBpcywgZS5nLiwNCj4gUkZDIDQ3MjAgZm9yIEZDUyByZXRlbnRpb24gaW4g UFdzLCBidXQgSSBkb3VidCBpdCBpcyB3aWRlbHkgaW1wbGVtZW50ZWQgYW5kDQo+IGRlcGxveWVk ICh3b3VsZCBiZSBuaWNlIHRvIGtub3cpLg0KPiAtIEUyRSBjb25nZXN0aW9uIGNvbnRyb2wgKHJl Z2FyZGxlc3Mgb2YgaXRzIGltcGxpY2F0aW9ucykgc2ltcGx5IGNhbm5vdCBiZSBhZGRlZA0KPiB0 byB0aGlzIHByb3RvY29sIHdpdGhvdXQgc29tZSBtYWpvciBjaGFuZ2VzLiBBIHNob3J0IGFwcGxp Y2FiaWxpdHkgc3RhdGVtZW50DQo+IGV4cGxhaW5pbmcgdGhhdCBzaG91bGQgc3VmZmljZSBJTU8u DQoNCkhpIFNhc2hhLA0KDQpJIGZ1bGx5IGFncmVlIHdpdGggeW91ciBwb2ludHMuDQoNCkJlc3Qg cmVnYXJkcywNClhpYW9odQ0KDQo+IE15IDJjLA0KPiAgICAgICAgU2FzaGENCj4gRW1haWw6IEFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4g DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBtcGxzIFttYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRWdnZXJ0LCBMYXJzDQo+ID4gU2Vu dDogV2VkbmVzZGF5LCBKYW51YXJ5IDIyLCAyMDE0IDEyOjIzIFBNDQo+ID4gVG86IFh1eGlhb2h1 DQo+ID4gQ2M6IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBb bXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gKEVu Y2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4NCj4gPiBI aSwNCj4gPg0KPiA+IE9uIDIwMTQtMS0yMiwgYXQgMTE6MTIsIFh1eGlhb2h1IDx4dXhpYW9odUBo dWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+IEkgd29uZGVyIHdoZXRoZXIgdGhlIGZvbGxvd2luZyB0 ZXh0IGlzIE9LIHRvIHlvdToNCj4gPiA+DQo+ID4gPiBTaW5jZSB0aGUgTVBMUy1pbi1VRFAgZW5j YXBzdWxhdGlvbiBjYXVzZXMgTVBMUyBwYWNrZXRzIHRvIGJlDQo+ID4gZm9yd2FyZGVkIHRocm91 Z2ggIlVEUCB0dW5uZWxzIiwgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBndWlkZWxpbmVzIGZvcg0K PiA+IFVEUCB0dW5uZWxzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuMyBvZiBbUkZDNTQwNV0g U0hPVUxEIGJlIGZvbGxvd2VkLg0KPiA+IFNwZWNpZmljYWxseSwgTVBMUyBjYW4gY2FycnkgYSBu dW1iZXIgb2YgZGlmZmVyZW50IHByb3RvY29scyBhcyBwYXlsb2Fkcy4NCj4gPiBXaGVuIGFuIFVE UCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcyBrbm93biBh dA0KPiA+IGNvbmZpZ3VyYXRpb24gdGltZSB0byBiZSBJUC1iYXNlZCBhbmQgY29uZ2VzdGlvbi1j b250cm9sbGVkLCB0aGUgVURQDQo+ID4gdHVubmVsIFNIT1VMRCBOT1QgZW1wbG95IGl0cyBvd24g Y29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSwgYmVjYXVzZQ0KPiA+IGNvbmdlc3Rpb24gbG9z c2VzIG9mIHR1bm5lbGVkIHRyYWZmaWMgd2lsbCB0cmlnZ2VyIGFuIGNvbmdlc3Rpb24NCj4gPiBy ZXNwb25zZSBhdCB0aGUgb3JpZ2luYWwgc2VuZGVycyBvZiB0aGUgdHVubmVsZWQgdHJhZmZpYy4g V2hlbiBhbiBVRFANCj4gPiB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMg dGhhdCBpcyBrbm93biBhdCBjb25maWd1cmF0aW9uDQo+ID4gdGltZSBub3QgdG8gYmUgSVAtYmFz ZWQgYW5kIGNvbmdlc3Rpb24tY29udHJvbGxlZCwgdGhlIFVEUCB0dW5uZWwNCj4gPiBTSE9VTEQg ZW1wbG95IGFuIGFwcHJvcHJpYXRlIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gYXMgZGVz Y3JpYmVkDQo+ID4gaW4gW1JGQzM5ODVdLiBOb3RlIHRoYXQgaXQgU1RST05HTFkgUkVDT01NRU5E RUQgdG8gZGVwbG95IHN1Y2gNCj4gPiBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kgb25seSB3aXRo aW4gYSBTUCBuZXR3b3JrIG9yIG5ldHdvcmtzIG9mIGFuDQo+ID4gYWRqYWNlbnQgc2V0IG9mIGNv LW9wZXJhdGluZyBTUHMsIHJhdGhlciB0aGFuIG92ZXIgdGhlIEludGVybmV0Lg0KPiA+IEZ1cnRo ZXJtb3JlLCBwYWNrZXQgZmlsdGVycyBzaG91bGQgYmUgYWRkZWQgdG8gYmxvY2sgdHJhZmZpYyB3 aXRoIHRoZQ0KPiA+IFVEUCBwb3J0IG51bWJlciBmb3IgTVBMUyBvdmVyIFVEUCB0byBwcmV2ZW50 IE1QTFMgb3ZlciBVRFAgcGFja2V0cyB0bw0KPiA+IGVzY2FwZSBmcm9tIHRoZSBzZXJ2aWNlIHBy b3ZpZGVyIG5ldHdvcmtzIGR1ZSB0byBtaXNjb25maWd1YXRpb24gb3IgcGFja2V0DQo+IGVycm9y cy4NCj4gPg0KPiA+IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGRlc2NyaWJlIHRoZSBP QU0gY29udHJvbCBsb29wIGluIChzb21lKQ0KPiA+IG1vcmUgZGV0YWlsLCByYXRoZXIgdGhhbiBw b2ludGluZyB0byBSRkMzOTg1LCB3aGljaCBkb2Vzbid0IGhhdmUgYQ0KPiA+IHdob2xlIGxvdCBv ZiBkZXRhaWwgZWl0aGVyLiBBbHNvIGJlY2F1c2UgdGhlIGFkZGluZyBvZiBmaXJld2FsbCBydWxl cw0KPiA+IHJlcXVpcmVzIGFuIE9BTSBob29rLg0KPiA+DQo+ID4gU2luY2UgU1RST05HTFkgUkVD T01NRU5ERUQgaXMgbm90IGFuIFJGQzIxMTkgdGVybSBhbmQNCj4gUkVDT01NRU5ERUQgaXMNCj4g PiB0b28gd2VhaywgSSdkIHN1Z2dlc3QgdG8gY2hhbmdlIHRoaXMgdG8gTVVTVC4NCj4gPg0KPiA+ IEZpbmFsbHksIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBzaG91bGQgYmUgcHJvbWluZW50 bHkgbWFkZSBpbiB0aGUNCj4gPiBhYnN0cmFjdCwgaW50cm9kdWN0aW9uLCBldGMuDQo+ID4NCj4g PiBMYXJzDQo= From l.wood@surrey.ac.uk Wed Jan 22 20:46:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337EC1A0176 for ; Wed, 22 Jan 2014 20:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 j9vqRjzkdxSO for ; Wed, 22 Jan 2014 20:46:48 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.162]) by ietfa.amsl.com (Postfix) with ESMTP id F3B711A014B for ; Wed, 22 Jan 2014 20:46:47 -0800 (PST) Received: from [195.245.230.131:27959] by server-2.bemta-3.messagelabs.com id DB/56-17329-5BE90E25; Thu, 23 Jan 2014 04:46:45 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-13.tower-78.messagelabs.com!1390452405!31220847!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19048 invoked from network); 23 Jan 2014 04:46:45 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-13.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 23 Jan 2014 04:46:45 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Thu, 23 Jan 2014 04:46:44 +0000 From: To: , , Date: Thu, 23 Jan 2014 04:44:01 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiM= Message-ID: <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 04:46:52 -0000 U2FzaGENCg0KPiAtIFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhlcmVvZikgaXMgYSBub24taXNz dWUgYmVjYXVzZSBuYXRpdmUgTVBMUyBkb2VzIG5vdA0KPiBoYXZlIGFueXRoaW5nIGxpa2UgdGhh dC4gQW5kIHllcywgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHBhY2tldHMgYXJlIGNvcnJ1cHRlZA0K PiB3aXRoaW4gdGhlIHJvdXRlcnMpDQoNClNvIHlvdSBhZG1pdCB0aGF0IHBhY2tldHMgY2FuIGJl IGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMgLSBhIGNoZWNrIHRoYXQgY2FuDQpvbmx5IGJl IGNhdWdodCBieSBhbiBlbmQtdG8tZW5kIGNoZWNrLCBhIGNvcnJ1cHRpb24gdGhhdCBjYW4gbGVh ZCB0byB0aGUgcHJvYmxlbXMNCmRldGFpbGVkIGluIFJGQyA2OTM2IHNlY3Rpb24gMyAtIGFuZCB0 aGVuIHlvdSBzYXkgaXQncyBhIG5vbi1pc3N1ZSBiZWNhdXNlIHRoaXMNCmRvZXNuJ3QgYWZmZWN0 IG5hdGl2ZSBNUExTLiBCdXQgd2UncmUgbm90IGRvaW5nIG5hdGl2ZSBNUExTIGhlcmUuIFdlJ3Jl IGRvaW5nDQpNUExTIG92ZXIgVURQLg0KDQpkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dCBp cyBhYm91dCB0dW5uZWxsaW5nIE1QTFMgaW4gVURQLiBJdCdzIGFuIGlzc3VlLg0KUGxlYXNlIHJl YWQgdGhlIG90aGVyIDE1MCBtZXNzYWdlcyB0aGF0IHlvdSByZWZlciB0by4NCg0KTGxveWQgV29v ZA0KaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRnJvbTogbXBscyBbbXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgWHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5jb21dDQpTZW50OiAyMyBKYW51YXJ5IDIw MTQgMDM6MTYNClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgRWdnZXJ0LCBMYXJzDQpDYzogSm9l bCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDog PGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVE UCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KSGkNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4g t6K8/sjLOiBBbGV4YW5kZXIgVmFpbnNodGVpbiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tXQ0KPiC3osvNyrG85DogMjAxNMTqMdTCMjLI1SAxOTowNQ0KPiDK1bz+yMs6 IEVnZ2VydCwgTGFycw0KPiCzrcvNOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmc7IFh1eGlh b2h1DQo+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVk cC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMNCj4gaW4gVURQKSB0byBQcm9wb3NlZCBTdGFu ZGFyZA0KPg0KPiBMYXJzIGFuZCBhbGwsDQo+IExhc3QgdGltZSBJJ3ZlIGNvdW50ZWQgdGhlIElF VEYgTEMgdGhyZWFkIG9uIHRoaXMgZHJhZnQgaGFzIG1vcmUgdGhhbiAxNTANCj4gbWVzc2FnZXMg aW4gaXQsIGFuZCBpdCBzZWVtcyB0aGF0IG9uIHNvbWUgaXNzdWVzIChjb25nZXN0aW9uIGNvbnRy b2wgYW5kIFVEUA0KPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyByb3VuZCB0aGUgbXVsYmVycnkg YnVzaC4NCj4NCj4gSU1ITyBhbmQgRldJVzoNCj4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRo ZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJlY2F1c2UgbmF0aXZlIE1QTFMgZG9lcyBub3QNCj4gaGF2 ZSBhbnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSBwYWNr ZXRzIGFyZSBjb3JydXB0ZWQNCj4gd2l0aGluIHRoZSByb3V0ZXJzKSwgYnV0IHNvIGZhciBpdCBk aWQgbm90IHByZXZlbnQgTVBMUyBkZXBsb3ltZW50LiBUaGVyZSBpcywgZS5nLiwNCj4gUkZDIDQ3 MjAgZm9yIEZDUyByZXRlbnRpb24gaW4gUFdzLCBidXQgSSBkb3VidCBpdCBpcyB3aWRlbHkgaW1w bGVtZW50ZWQgYW5kDQo+IGRlcGxveWVkICh3b3VsZCBiZSBuaWNlIHRvIGtub3cpLg0KPiAtIEUy RSBjb25nZXN0aW9uIGNvbnRyb2wgKHJlZ2FyZGxlc3Mgb2YgaXRzIGltcGxpY2F0aW9ucykgc2lt cGx5IGNhbm5vdCBiZSBhZGRlZA0KPiB0byB0aGlzIHByb3RvY29sIHdpdGhvdXQgc29tZSBtYWpv ciBjaGFuZ2VzLiBBIHNob3J0IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50DQo+IGV4cGxhaW5pbmcg dGhhdCBzaG91bGQgc3VmZmljZSBJTU8uDQoNCkhpIFNhc2hhLA0KDQpJIGZ1bGx5IGFncmVlIHdp dGggeW91ciBwb2ludHMuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IE15IDJjLA0KPiAg ICAgICAgU2FzaGENCj4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+ IE1vYmlsZTogMDU0LTkyNjYzMDINCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+IEZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBFZ2dlcnQsIExhcnMNCj4gPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjIsIDIwMTQgMTI6 MjMgUE0NCj4gPiBUbzogWHV4aWFvaHUNCj4gPiBDYzogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYu b3JnDQo+ID4gU3ViamVjdDogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMt aW4tdWRwLTA0LnR4dD4NCj4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9z ZWQgU3RhbmRhcmQNCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gT24gMjAxNC0xLTIyLCBhdCAxMTox MiwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ID4gSSB3b25kZXIg d2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0sgdG8geW91Og0KPiA+ID4NCj4gPiA+IFNp bmNlIHRoZSBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uIGNhdXNlcyBNUExTIHBhY2tldHMgdG8g YmUNCj4gPiBmb3J3YXJkZWQgdGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBj b250cm9sIGd1aWRlbGluZXMgZm9yDQo+ID4gVURQIHR1bm5lbHMgYXMgZGVmaW5lZCBpbiBTZWN0 aW9uIDMuMS4zIG9mIFtSRkM1NDA1XSBTSE9VTEQgYmUgZm9sbG93ZWQuDQo+ID4gU3BlY2lmaWNh bGx5LCBNUExTIGNhbiBjYXJyeSBhIG51bWJlciBvZiBkaWZmZXJlbnQgcHJvdG9jb2xzIGFzIHBh eWxvYWRzLg0KPiA+IFdoZW4gYW4gVURQIHR1bm5lbCBpcyB1c2VkIGZvciBNUExTIHBheWxvYWQg dHJhZmZpYyB0aGF0IGlzIGtub3duIGF0DQo+ID4gY29uZmlndXJhdGlvbiB0aW1lIHRvIGJlIElQ LWJhc2VkIGFuZCBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFANCj4gPiB0dW5uZWwgU0hP VUxEIE5PVCBlbXBsb3kgaXRzIG93biBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLCBiZWNh dXNlDQo+ID4gY29uZ2VzdGlvbiBsb3NzZXMgb2YgdHVubmVsZWQgdHJhZmZpYyB3aWxsIHRyaWdn ZXIgYW4gY29uZ2VzdGlvbg0KPiA+IHJlc3BvbnNlIGF0IHRoZSBvcmlnaW5hbCBzZW5kZXJzIG9m IHRoZSB0dW5uZWxlZCB0cmFmZmljLiBXaGVuIGFuIFVEUA0KPiA+IHR1bm5lbCBpcyB1c2VkIGZv ciBNUExTIHBheWxvYWQgdHJhZmZpYyB0aGF0IGlzIGtub3duIGF0IGNvbmZpZ3VyYXRpb24NCj4g PiB0aW1lIG5vdCB0byBiZSBJUC1iYXNlZCBhbmQgY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUg VURQIHR1bm5lbA0KPiA+IFNIT1VMRCBlbXBsb3kgYW4gYXBwcm9wcmlhdGUgY29uZ2VzdGlvbiBj b250cm9sIG1lY2hhbmlzbSBhcyBkZXNjcmliZWQNCj4gPiBpbiBbUkZDMzk4NV0uIE5vdGUgdGhh dCBpdCBTVFJPTkdMWSBSRUNPTU1FTkRFRCB0byBkZXBsb3kgc3VjaA0KPiA+IGVuY2Fwc3VsYXRp b24gdGVjaG5vbG9neSBvbmx5IHdpdGhpbiBhIFNQIG5ldHdvcmsgb3IgbmV0d29ya3Mgb2YgYW4N Cj4gPiBhZGphY2VudCBzZXQgb2YgY28tb3BlcmF0aW5nIFNQcywgcmF0aGVyIHRoYW4gb3ZlciB0 aGUgSW50ZXJuZXQuDQo+ID4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3VsZCBiZSBh ZGRlZCB0byBibG9jayB0cmFmZmljIHdpdGggdGhlDQo+ID4gVURQIHBvcnQgbnVtYmVyIGZvciBN UExTIG92ZXIgVURQIHRvIHByZXZlbnQgTVBMUyBvdmVyIFVEUCBwYWNrZXRzIHRvDQo+ID4gZXNj YXBlIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29ya3MgZHVlIHRvIG1pc2NvbmZpZ3Vh dGlvbiBvciBwYWNrZXQNCj4gZXJyb3JzLg0KPiA+DQo+ID4gSSB0aGluayBpdCB3b3VsZCBiZSBi ZXR0ZXIgdG8gZGVzY3JpYmUgdGhlIE9BTSBjb250cm9sIGxvb3AgaW4gKHNvbWUpDQo+ID4gbW9y ZSBkZXRhaWwsIHJhdGhlciB0aGFuIHBvaW50aW5nIHRvIFJGQzM5ODUsIHdoaWNoIGRvZXNuJ3Qg aGF2ZSBhDQo+ID4gd2hvbGUgbG90IG9mIGRldGFpbCBlaXRoZXIuIEFsc28gYmVjYXVzZSB0aGUg YWRkaW5nIG9mIGZpcmV3YWxsIHJ1bGVzDQo+ID4gcmVxdWlyZXMgYW4gT0FNIGhvb2suDQo+ID4N Cj4gPiBTaW5jZSBTVFJPTkdMWSBSRUNPTU1FTkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJtIGFu ZA0KPiBSRUNPTU1FTkRFRCBpcw0KPiA+IHRvbyB3ZWFrLCBJJ2Qgc3VnZ2VzdCB0byBjaGFuZ2Ug dGhpcyB0byBNVVNULg0KPiA+DQo+ID4gRmluYWxseSwgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVt ZW50IHNob3VsZCBiZSBwcm9taW5lbnRseSBtYWRlIGluIHRoZQ0KPiA+IGFic3RyYWN0LCBpbnRy b2R1Y3Rpb24sIGV0Yy4NCj4gPg0KPiA+IExhcnMNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From lars@netapp.com Thu Jan 23 02:37:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD0F1A03A9; Thu, 23 Jan 2014 02:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 cPsch87rsW8E; Thu, 23 Jan 2014 02:37:07 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id D803D1A03D5; Thu, 23 Jan 2014 02:37:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,705,1384329600"; d="asc'?scan'208";a="97660183" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 23 Jan 2014 02:37:07 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 02:37:07 -0800 From: "Eggert, Lars" To: Noel Chiappa Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF6BSFyKjVtdEy02x6qUpK40JLJqSpPgA Date: Thu, 23 Jan 2014 10:37:06 +0000 Message-ID: <0DCB269E-D53D-4BF5-8D1A-42445ABBBB1E@netapp.com> References: <20140122183237.0FE0918C144@mercury.lcs.mit.edu> In-Reply-To: <20140122183237.0FE0918C144@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_D267C342-22A5-4375-B74A-7185400A74A7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 10:37:11 -0000 --Apple-Mail=_D267C342-22A5-4375-B74A-7185400A74A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-1-22, at 19:32, Noel Chiappa wrote: >> From: "Eggert, Lars" >=20 >> Depends on the reach of that encapsulation. .. If it traversed such >> middleboxes by default, as UDP does, it has the same issues. >=20 > Exactly. The problem is not specific to UDP. So why is the discussion > (seemingly) trying to solve it in a UDP-specific way? you conveniently cut the part of my original message where I tried to = explain that the difference is in *reach* of the traffic. > I repeat: even if people were _not_ using UDP encapsulations, the = exact same > problem (of potential congestion caused by non-congestion-compliant > applications) would still exist. Switching to a different = encapsulation method > is not going to get rid of _any_ potential congestion - not one = packet's > worth. The severity of the problem depends on the reach of the traffic. = Encapsulating something inside some "obscure" IP protocol number limits = the reach. Encapsulating in UDP does not. > So can we just drop all mention of UDP, since it's irrelevant to the = _real_ > problem? But it isn't. >>> But saying that _intermediate forwarding nodes_ have to detect >>> down-stream congestion, and respond, represents a fundamental change >>> to the Internet's architecture for congestion control. >=20 >> And here's the fallacy: UDP encapsulators are forwarding nodes *only* >> from the viewpoint of the final endpoints. =46rom the viewpoint of = the >> rest of the Internet, they are traffic *sources*, not *forwarders*. >=20 > I present two boxes. In one, a packet comes in, and after some = manipulation of > headers, the packet goes out. In the other, a packet comes in, and = after some > header changes, the packet goes out. You're trying to tell me that, > architecturally, one _is_ an intermediate forwarding node (which = doesn't have > to detect downsteam congestion, and respond), and the other is not = (and so > does have to)? You have oversimplified the scenario.=20 In one case, an L2 packet comes in, and goes out as an L2 packet that is = limited in reach to the L2 topology, or as an L3 packet with an obscure = IP protocol number that will make it die at the next middlebox (in the = case of MPLS in IP). In the other case, an L2 packet comes in and it comes out as an L4 UDP = packet that can now go anywhere on the Internet. Surely you see the difference? > And I repeat: mandating that nodes which are forwarding nodes have to = detect, > and respond to, downsteam congestion caused by = non-congestion-compliant > traffic flowing _through_ them is a fundamental change to the = Internet's > existing framework for congestion control. Since we're repeating ourselves, I'll again say that encapsulators are = not forwarding nodes from the viewpoint of the network they tunnel over. = They are traffic sources. > Not that I'm opposed to such a change (it might make sense, I'd have = to go > away and think about it), but if we're going to make such an = architectural > change, i) we should do so explicitly, and ii) such a requirement = should fall > on _all_ packet forwarding nodes - including regular routers, since = they could > equally possibly be given non-congestion-compliant traffic to forward. Lars --Apple-Mail=_D267C342-22A5-4375-B74A-7185400A74A7 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----- iQCVAwUBUuDw0dZcnpRveo1xAQJbVgP8D3cTNl5SZRKcD5Xlny3NJbVsqgataqkI GfQt0OyysOwHZQrLbkzSRYAzedQldpa6IwamTC2bAnukEnuVv1BX7CFZSfTEwahy vdfDw0fi4iac2TeOZpDfm6KJ235a4Bw82ZBew2iFEHn4heI7m+oZdyoZBzhgZ5l8 8bMCste8GnQ= =Ggw/ -----END PGP SIGNATURE----- --Apple-Mail=_D267C342-22A5-4375-B74A-7185400A74A7-- From xuxiaohu@huawei.com Thu Jan 23 04:36:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4410D1A03E6 for ; Thu, 23 Jan 2014 04:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 9o4JojtgLRfb for ; Thu, 23 Jan 2014 04:36:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 443521A042D for ; Thu, 23 Jan 2014 04:36:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAI69959; Thu, 23 Jan 2014 12:35:59 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 12:35:53 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 12:35:56 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 23 Jan 2014 20:35:51 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "Alexander.Vainshtein@ecitele.com" , "lars@netapp.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiOAAIGV4A== Date: Thu, 23 Jan 2014 12:35:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 12:36:06 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBb bWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ILeiy83KsbzkOiAyMDE0xOox1MIyM8jVIDEy OjQ0DQo+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t OyBsYXJzQG5ldGFwcC5jb20NCj4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9y Zw0KPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAt MDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTDQo+IGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRh cmQNCj4gDQo+IFNhc2hhDQo+IA0KPiA+IC0gVURQIGNoZWNrc3VtcyAob3IgbGFjayB0aGVyZW9m KSBpcyBhIG5vbi1pc3N1ZSBiZWNhdXNlIG5hdGl2ZSBNUExTDQo+ID4gZG9lcyBub3QgaGF2ZSBh bnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFyZSBjYXNlcyB3aGVyZQ0KPiA+IHBh Y2tldHMgYXJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMpDQo+IA0KPiBTbyB5b3UgYWRt aXQgdGhhdCBwYWNrZXRzIGNhbiBiZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzIC0gYSBj aGVjayB0aGF0IGNhbg0KPiBvbmx5IGJlIGNhdWdodCBieSBhbiBlbmQtdG8tZW5kIGNoZWNrLCBh IGNvcnJ1cHRpb24gdGhhdCBjYW4gbGVhZCB0byB0aGUNCj4gcHJvYmxlbXMgZGV0YWlsZWQgaW4g UkZDIDY5MzYgc2VjdGlvbiAzIC0gYW5kIHRoZW4geW91IHNheSBpdCdzIGEgbm9uLWlzc3VlDQo+ IGJlY2F1c2UgdGhpcyBkb2Vzbid0IGFmZmVjdCBuYXRpdmUgTVBMUy4gQnV0IHdlJ3JlIG5vdCBk b2luZyBuYXRpdmUgTVBMUyBoZXJlLg0KPiBXZSdyZSBkb2luZyBNUExTIG92ZXIgVURQLg0KPiAN Cj4gZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQgaXMgYWJvdXQgdHVubmVsbGluZyBNUExT IGluIFVEUC4gSXQncyBhbiBpc3N1ZS4NCj4gUGxlYXNlIHJlYWQgdGhlIG90aGVyIDE1MCBtZXNz YWdlcyB0aGF0IHlvdSByZWZlciB0by4NCg0KSGkgTGxveWQsDQoNClRoZSBkcmFmdCBkb2Vzbid0 IHJlcXVpcmUgdGhlIElQdjYgVURQIGNoZWNrc3VtIHRvIGJlIHNldCB0byB6ZXJvIHJlZ2FyZGxl c3MuIFNlZSB0aGUgZm9sbG93aW5nIHRleHQgcXVvdGVkIGZyb20gdGhhdCBkcmFmdDoNCg0KVURQ IENoZWNrc3VtIA0KDQpUaGUgdXNhZ2Ugb2YgdGhpcyBmaWVsZCBpcyBpbiBhY2NvcmRhbmNlIHdp dGggdGhlIGN1cnJlbnQgVURQIHNwZWNpZmljYXRpb24gW1JGQzc2OF0uIFRvIHNpbXBsaWZ5IHRo ZSBvcGVyYXRpb24gb24gdGhlIGRlY2Fwc3VsYXRvciwgdGhpcyBmaWVsZCBpcyBSRUNPTU1FTkRF RCB0byBiZSBzZXQgdG8gemVybyBpbiBJUHY0IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2UuIEluIHRo ZSBJUHY2IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2UsIGlmIGFwcHJvcHJpYXRlIGFjY29yZGluZyB0 byB0aGUgcmVxdWlyZW1lbnRzIGRlZmluZWQgaW4gW1JGQzY5MzVdIFtSRkM2OTM2XSwgdGhpcyBm aWVsZCBpcyBhbHNvIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvLiBTcGVjaWZpY2FsbHks IGlmIHRoZSBNUExTIHBheWxvYWQgaXMgSW50ZXJuZXQgUHJvdG9jb2wgKElQdjQgb3IgSVB2Nikg cGFja2V0cywgaXQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gd2hlbiB0aGUgaW5u ZXIgcGFja2V0IGludGVncml0eSBjaGVja3MgaXMgYXZhaWxhYmxlLiBJbiBhZGRpdGlvbiwgaWYg dGhlIE1QTFMgcGF5bG9hZCBpcyBub24tSVAgcGFja2V0IHdoaWNoIGlzIHNwZWNpZmljYWxseSBk ZXNpZ25lZCBmb3IgdHJhbnNtaXNzaW9uIG92ZXIgYSBsb3dlciBsYXllciB0aGF0IGRvZXMgbm90 IHByb3ZpZGUgYSBwYWNrZXQgaW50ZWdyaXR5IGd1YXJhbnRlZSwgaXQgaXMgUkVDT01NRU5ERUQg dG8gYmUgc2V0IHRvIHplcm8gYXMgd2VsbC4gT3RoZXJ3aXNlLCB1c2luZyB6ZXJvIGNoZWNrc3Vt IGlzIE5PVCBSRUNPTU1FTkRFRC4gTm90ZSB0aGF0IG90aGVyIElQIGVuY2Fwc3VsYXRpb25zIGZv ciBNUExTIGRvIG5vdCBoYXZlIGEgY2hlY2tzdW0gaW4gdGhlIHR1bm5lbCBoZWFkZXIuDQoNCklm IHlvdSBzdGlsbCBiZWxpZXZlIHRoZSBhYm92ZSB0ZXh0IGlzIG5vdCBzYXRpc2ZhY3RvcnksIHBs ZWFzZSBwcm92aWRlIHlvdXIgdGV4dC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gTGxv eWQgV29vZA0KPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogbXBscyBbbXBscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNCj4gW3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+IFNl bnQ6IDIzIEphbnVhcnkgMjAxNCAwMzoxNg0KPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IEVn Z2VydCwgTGFycw0KPiBDYzogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChF bmNhcHN1bGF0aW5nDQo+IE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4g SGkNCj4gDQo+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiBBbGV4YW5kZXIgVmFp bnNodGVpbiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ILei y83KsbzkOiAyMDE0xOox1MIyMsjVIDE5OjA1DQo+ID4gytW8/sjLOiBFZ2dlcnQsIExhcnMNCj4g PiCzrcvNOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1DQo+ID4g1vfM4jog UkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4g PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPg0K PiA+IExhcnMgYW5kIGFsbCwNCj4gPiBMYXN0IHRpbWUgSSd2ZSBjb3VudGVkIHRoZSBJRVRGIExD IHRocmVhZCBvbiB0aGlzIGRyYWZ0IGhhcyBtb3JlIHRoYW4NCj4gPiAxNTAgbWVzc2FnZXMgaW4g aXQsIGFuZCBpdCBzZWVtcyB0aGF0IG9uIHNvbWUgaXNzdWVzIChjb25nZXN0aW9uDQo+ID4gY29u dHJvbCBhbmQgVURQDQo+ID4gY2hlY2tzdW1zKSB3ZSBhcmUgZ29pbmcgcm91bmQgdGhlIG11bGJl cnJ5IGJ1c2guDQo+ID4NCj4gPiBJTUhPIGFuZCBGV0lXOg0KPiA+IC0gVURQIGNoZWNrc3VtcyAo b3IgbGFjayB0aGVyZW9mKSBpcyBhIG5vbi1pc3N1ZSBiZWNhdXNlIG5hdGl2ZSBNUExTDQo+ID4g ZG9lcyBub3QgaGF2ZSBhbnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFyZSBjYXNl cyB3aGVyZQ0KPiA+IHBhY2tldHMgYXJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMpLCBi dXQgc28gZmFyIGl0IGRpZCBub3QNCj4gPiBwcmV2ZW50IE1QTFMgZGVwbG95bWVudC4gVGhlcmUg aXMsIGUuZy4sIFJGQyA0NzIwIGZvciBGQ1MgcmV0ZW50aW9uIGluDQo+ID4gUFdzLCBidXQgSSBk b3VidCBpdCBpcyB3aWRlbHkgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkICh3b3VsZCBiZSBuaWNl IHRvDQo+IGtub3cpLg0KPiA+IC0gRTJFIGNvbmdlc3Rpb24gY29udHJvbCAocmVnYXJkbGVzcyBv ZiBpdHMgaW1wbGljYXRpb25zKSBzaW1wbHkNCj4gPiBjYW5ub3QgYmUgYWRkZWQgdG8gdGhpcyBw cm90b2NvbCB3aXRob3V0IHNvbWUgbWFqb3IgY2hhbmdlcy4gQSBzaG9ydA0KPiA+IGFwcGxpY2Fi aWxpdHkgc3RhdGVtZW50IGV4cGxhaW5pbmcgdGhhdCBzaG91bGQgc3VmZmljZSBJTU8uDQo+IA0K PiBIaSBTYXNoYSwNCj4gDQo+IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHBvaW50cy4NCj4gDQo+ IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IA0KPiA+IE15IDJjLA0KPiA+ICAgICAgICBTYXNo YQ0KPiA+IEVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPiA+IE1vYmls ZTogMDU0LTkyNjYzMDINCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+IEZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBFZ2dlcnQsIExhcnMNCj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMiwgMjAxNCAx MjoyMyBQTQ0KPiA+ID4gVG86IFh1eGlhb2h1DQo+ID4gPiBDYzogSm9lbCBKYWVnZ2xpOyBtcGxz QGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWll dGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFAp IHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ID4gT24g MjAxNC0xLTIyLCBhdCAxMToxMiwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3Rl Og0KPiA+ID4gPiBJIHdvbmRlciB3aGV0aGVyIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBPSyB0byB5 b3U6DQo+ID4gPiA+DQo+ID4gPiA+IFNpbmNlIHRoZSBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9u IGNhdXNlcyBNUExTIHBhY2tldHMgdG8gYmUNCj4gPiA+IGZvcndhcmRlZCB0aHJvdWdoICJVRFAg dHVubmVscyIsIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgZ3VpZGVsaW5lcw0KPiA+ID4gZm9yIFVE UCB0dW5uZWxzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuMyBvZiBbUkZDNTQwNV0gU0hPVUxE IGJlDQo+IGZvbGxvd2VkLg0KPiA+ID4gU3BlY2lmaWNhbGx5LCBNUExTIGNhbiBjYXJyeSBhIG51 bWJlciBvZiBkaWZmZXJlbnQgcHJvdG9jb2xzIGFzIHBheWxvYWRzLg0KPiA+ID4gV2hlbiBhbiBV RFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFmZmljIHRoYXQgaXMga25vd24g YXQNCj4gPiA+IGNvbmZpZ3VyYXRpb24gdGltZSB0byBiZSBJUC1iYXNlZCBhbmQgY29uZ2VzdGlv bi1jb250cm9sbGVkLCB0aGUgVURQDQo+ID4gPiB0dW5uZWwgU0hPVUxEIE5PVCBlbXBsb3kgaXRz IG93biBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLA0KPiA+ID4gYmVjYXVzZSBjb25nZXN0 aW9uIGxvc3NlcyBvZiB0dW5uZWxlZCB0cmFmZmljIHdpbGwgdHJpZ2dlciBhbg0KPiA+ID4gY29u Z2VzdGlvbiByZXNwb25zZSBhdCB0aGUgb3JpZ2luYWwgc2VuZGVycyBvZiB0aGUgdHVubmVsZWQg dHJhZmZpYy4NCj4gPiA+IFdoZW4gYW4gVURQIHR1bm5lbCBpcyB1c2VkIGZvciBNUExTIHBheWxv YWQgdHJhZmZpYyB0aGF0IGlzIGtub3duIGF0DQo+ID4gPiBjb25maWd1cmF0aW9uIHRpbWUgbm90 IHRvIGJlIElQLWJhc2VkIGFuZCBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZQ0KPiA+ID4gVURQ IHR1bm5lbCBTSE9VTEQgZW1wbG95IGFuIGFwcHJvcHJpYXRlIGNvbmdlc3Rpb24gY29udHJvbCBt ZWNoYW5pc20NCj4gPiA+IGFzIGRlc2NyaWJlZCBpbiBbUkZDMzk4NV0uIE5vdGUgdGhhdCBpdCBT VFJPTkdMWSBSRUNPTU1FTkRFRCB0bw0KPiA+ID4gZGVwbG95IHN1Y2ggZW5jYXBzdWxhdGlvbiB0 ZWNobm9sb2d5IG9ubHkgd2l0aGluIGEgU1AgbmV0d29yayBvcg0KPiA+ID4gbmV0d29ya3Mgb2Yg YW4gYWRqYWNlbnQgc2V0IG9mIGNvLW9wZXJhdGluZyBTUHMsIHJhdGhlciB0aGFuIG92ZXIgdGhl DQo+IEludGVybmV0Lg0KPiA+ID4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3VsZCBi ZSBhZGRlZCB0byBibG9jayB0cmFmZmljIHdpdGgNCj4gPiA+IHRoZSBVRFAgcG9ydCBudW1iZXIg Zm9yIE1QTFMgb3ZlciBVRFAgdG8gcHJldmVudCBNUExTIG92ZXIgVURQDQo+ID4gPiBwYWNrZXRz IHRvIGVzY2FwZSBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmtzIGR1ZSB0bw0KPiA+ ID4gbWlzY29uZmlndWF0aW9uIG9yIHBhY2tldA0KPiA+IGVycm9ycy4NCj4gPiA+DQo+ID4gPiBJ IHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBkZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wgbG9v cCBpbg0KPiA+ID4gKHNvbWUpIG1vcmUgZGV0YWlsLCByYXRoZXIgdGhhbiBwb2ludGluZyB0byBS RkMzOTg1LCB3aGljaCBkb2Vzbid0DQo+ID4gPiBoYXZlIGEgd2hvbGUgbG90IG9mIGRldGFpbCBl aXRoZXIuIEFsc28gYmVjYXVzZSB0aGUgYWRkaW5nIG9mDQo+ID4gPiBmaXJld2FsbCBydWxlcyBy ZXF1aXJlcyBhbiBPQU0gaG9vay4NCj4gPiA+DQo+ID4gPiBTaW5jZSBTVFJPTkdMWSBSRUNPTU1F TkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJtIGFuZA0KPiA+IFJFQ09NTUVOREVEIGlzDQo+ID4g PiB0b28gd2VhaywgSSdkIHN1Z2dlc3QgdG8gY2hhbmdlIHRoaXMgdG8gTVVTVC4NCj4gPiA+DQo+ ID4gPiBGaW5hbGx5LCB0aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgc2hvdWxkIGJlIHByb21p bmVudGx5IG1hZGUgaW4NCj4gPiA+IHRoZSBhYnN0cmFjdCwgaW50cm9kdWN0aW9uLCBldGMuDQo+ ID4gPg0KPiA+ID4gTGFycw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From l.wood@surrey.ac.uk Thu Jan 23 09:18:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5CE1A0100 for ; Thu, 23 Jan 2014 09:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 n2h8HJQbpKAX for ; Thu, 23 Jan 2014 09:18:27 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.167]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF51A00FF for ; Thu, 23 Jan 2014 09:18:26 -0800 (PST) Received: from [85.158.137.99:33258] by server-7.bemta-3.messagelabs.com id 75/00-27599-FDE41E25; Thu, 23 Jan 2014 17:18:23 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-217.messagelabs.com!1390497502!19187129!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32241 invoked from network); 23 Jan 2014 17:18:23 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-12.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 23 Jan 2014 17:18:23 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Thu, 23 Jan 2014 17:18:22 +0000 From: To: , , Date: Thu, 23 Jan 2014 17:18:22 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiOAAIGV4IAASynF Message-ID: <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 17:18:31 -0000 dGhlIHRleHQgaXMgbm90IHNhdGlzZmFjdG9yeS4gbmV2ZXIgcmVjb21tZW5kIHNldHRpbmcgdG8g emVybywNCmFzIHRoYXQgcG9zZXMgYSByaXNrIHRvIHlvdXIgYW5kIHRvIG90aGVyIHRyYWZmaWMu IFN1Z2dlc3RlZCB0ZXh0Og0KKioqDQpUaGUgVURQIGNoZWNrc3VtIFNIT1VMRCBiZSB1c2VkIHRv IHByb3RlY3QgdGhlIHBheWxvYWQgYW5kDQplbnN1cmUgY29ycmVjdCBkZW11bHRpcGxleGluZyBh bmQgZGVsaXZlcnkgdG8gdGhlIHR1bm5lbCwgYW5kIG5vdCB0bw0Kb3RoZXIgVURQIGRlc3RpbmF0 aW9ucywgYnkgcHJvdGVjdGluZyB0aGUgVURQIHBzZXVkb2hlYWRlci4NClVzZSBvZiBhIHplcm8g VURQIGNoZWNrc3VtIGlzIE5PVCBSRUNPTU1FTkRFRCwgZXZlbiB3aGVuDQpkZXNpcmVkIGZvciBw ZXJmb3JtYW5jZSBvciBuZWNlc3NpdGF0ZWQgYnkgaW1wbGVtZW50YXRpb24NCnJlYXNvbnMsIGZv ciB0aGUgcmVhc29ucyBvdXRsaW5lZCBpbiBbUkZDNjkzNl0gc2VjdGlvbiAzLg0KDQpVRFAtTGl0 ZSBbUkZDMzgyOF0gY2FuIHByb3ZpZGUgYSBkZW11bHRpcGxleGluZyBjaGVjayBhbmQgTVBMUw0K c3RhY2sgaW50ZWdyaXR5IGNoZWNrIHdoaWxlIGF2b2lkaW5nIHRoZSBvdmVyaGVhZCBvZiBjb21w dXRpbmcgYW4NCmludGVncml0eSBjaGVjayBvdmVyIGEgdHVubmVsbGVkIGZyYW1lIHRoYXQgaGFz IGl0cyBvd24gaW50ZWdyaXR5IGNoZWNrLg0KKioqDQoNCkxsb3lkIFdvb2QNCmh0dHA6Ly9hYm91 dC5tZS9sbG95ZHdvb2QNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KU2VudDogMjMgSmFudWFyeSAy MDE0IDEyOjM1DQpUbzogV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpOyBBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQpDYzogam9lbGphQGJvZ3VzLmNv bTsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1p ZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFBy b3Bvc2VkIFN0YW5kYXJkDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbC53b29k QHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ILeiy83KsbzkOiAy MDE0xOox1MIyM8jVIDEyOjQ0DQo+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5ldGFwcC5jb20NCj4gs63LzTogam9lbGphQGJvZ3VzLmNv bTsgbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWll dGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTDQo+IGluIFVEUCkgdG8g UHJvcG9zZWQgU3RhbmRhcmQNCj4NCj4gU2FzaGENCj4NCj4gPiAtIFVEUCBjaGVja3N1bXMgKG9y IGxhY2sgdGhlcmVvZikgaXMgYSBub24taXNzdWUgYmVjYXVzZSBuYXRpdmUgTVBMUw0KPiA+IGRv ZXMgbm90IGhhdmUgYW55dGhpbmcgbGlrZSB0aGF0LiBBbmQgeWVzLCB0aGVyZSBhcmUgY2FzZXMg d2hlcmUNCj4gPiBwYWNrZXRzIGFyZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKQ0KPg0K PiBTbyB5b3UgYWRtaXQgdGhhdCBwYWNrZXRzIGNhbiBiZSBjb3JydXB0ZWQgd2l0aGluIHRoZSBy b3V0ZXJzIC0gYSBjaGVjayB0aGF0IGNhbg0KPiBvbmx5IGJlIGNhdWdodCBieSBhbiBlbmQtdG8t ZW5kIGNoZWNrLCBhIGNvcnJ1cHRpb24gdGhhdCBjYW4gbGVhZCB0byB0aGUNCj4gcHJvYmxlbXMg ZGV0YWlsZWQgaW4gUkZDIDY5MzYgc2VjdGlvbiAzIC0gYW5kIHRoZW4geW91IHNheSBpdCdzIGEg bm9uLWlzc3VlDQo+IGJlY2F1c2UgdGhpcyBkb2Vzbid0IGFmZmVjdCBuYXRpdmUgTVBMUy4gQnV0 IHdlJ3JlIG5vdCBkb2luZyBuYXRpdmUgTVBMUyBoZXJlLg0KPiBXZSdyZSBkb2luZyBNUExTIG92 ZXIgVURQLg0KPg0KPiBkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dCBpcyBhYm91dCB0dW5u ZWxsaW5nIE1QTFMgaW4gVURQLiBJdCdzIGFuIGlzc3VlLg0KPiBQbGVhc2UgcmVhZCB0aGUgb3Ro ZXIgMTUwIG1lc3NhZ2VzIHRoYXQgeW91IHJlZmVyIHRvLg0KDQpIaSBMbG95ZCwNCg0KVGhlIGRy YWZ0IGRvZXNuJ3QgcmVxdWlyZSB0aGUgSVB2NiBVRFAgY2hlY2tzdW0gdG8gYmUgc2V0IHRvIHpl cm8gcmVnYXJkbGVzcy4gU2VlIHRoZSBmb2xsb3dpbmcgdGV4dCBxdW90ZWQgZnJvbSB0aGF0IGRy YWZ0Og0KDQpVRFAgQ2hlY2tzdW0NCg0KVGhlIHVzYWdlIG9mIHRoaXMgZmllbGQgaXMgaW4gYWNj b3JkYW5jZSB3aXRoIHRoZSBjdXJyZW50IFVEUCBzcGVjaWZpY2F0aW9uIFtSRkM3NjhdLiBUbyBz aW1wbGlmeSB0aGUgb3BlcmF0aW9uIG9uIHRoZSBkZWNhcHN1bGF0b3IsIHRoaXMgZmllbGQgaXMg UkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gaW4gSVB2NCBVRFAgZW5jYXBzdWxhdGlvbiBj YXNlLiBJbiB0aGUgSVB2NiBVRFAgZW5jYXBzdWxhdGlvbiBjYXNlLCBpZiBhcHByb3ByaWF0ZSBh Y2NvcmRpbmcgdG8gdGhlIHJlcXVpcmVtZW50cyBkZWZpbmVkIGluIFtSRkM2OTM1XSBbUkZDNjkz Nl0sIHRoaXMgZmllbGQgaXMgYWxzbyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVyby4gU3Bl Y2lmaWNhbGx5LCBpZiB0aGUgTVBMUyBwYXlsb2FkIGlzIEludGVybmV0IFByb3RvY29sIChJUHY0 IG9yIElQdjYpIHBhY2tldHMsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIHdo ZW4gdGhlIGlubmVyIHBhY2tldCBpbnRlZ3JpdHkgY2hlY2tzIGlzIGF2YWlsYWJsZS4gSW4gYWRk aXRpb24sIGlmIHRoZSBNUExTIHBheWxvYWQgaXMgbm9uLUlQIHBhY2tldCB3aGljaCBpcyBzcGVj aWZpY2FsbHkgZGVzaWduZWQgZm9yIHRyYW5zbWlzc2lvbiBvdmVyIGEgbG93ZXIgbGF5ZXIgdGhh dCBkb2VzIG5vdCBwcm92aWRlIGEgcGFja2V0IGludGVncml0eSBndWFyYW50ZWUsIGl0IGlzIFJF Q09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGFzIHdlbGwuIE90aGVyd2lzZSwgdXNpbmcgemVy byBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQuIE5vdGUgdGhhdCBvdGhlciBJUCBlbmNhcHN1 bGF0aW9ucyBmb3IgTVBMUyBkbyBub3QgaGF2ZSBhIGNoZWNrc3VtIGluIHRoZSB0dW5uZWwgaGVh ZGVyLg0KDQpJZiB5b3Ugc3RpbGwgYmVsaWV2ZSB0aGUgYWJvdmUgdGV4dCBpcyBub3Qgc2F0aXNm YWN0b3J5LCBwbGVhc2UgcHJvdmlkZSB5b3VyIHRleHQuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9o dQ0KDQo+IExsb3lkIFdvb2QNCj4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IG1wbHMgW21wbHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQo+IFt4dXhpYW9odUBodWF3ZWku Y29tXQ0KPiBTZW50OiAyMyBKYW51YXJ5IDIwMTQgMDM6MTYNCj4gVG86IEFsZXhhbmRlciBWYWlu c2h0ZWluOyBFZ2dlcnQsIExhcnMNCj4gQ2M6IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAt MDQudHh0PiAoRW5jYXBzdWxhdGluZw0KPiBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRh cmQNCj4NCj4gSGkNCj4NCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiC3orz+yMs6IEFsZXhh bmRlciBWYWluc2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21d DQo+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjIyyNUgMTk6MDUNCj4gPiDK1bz+yMs6IEVnZ2VydCwg TGFycw0KPiA+ILOty806IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZzsgWHV4aWFvaHUNCj4g PiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQu dHh0Pg0KPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFy ZA0KPiA+DQo+ID4gTGFycyBhbmQgYWxsLA0KPiA+IExhc3QgdGltZSBJJ3ZlIGNvdW50ZWQgdGhl IElFVEYgTEMgdGhyZWFkIG9uIHRoaXMgZHJhZnQgaGFzIG1vcmUgdGhhbg0KPiA+IDE1MCBtZXNz YWdlcyBpbiBpdCwgYW5kIGl0IHNlZW1zIHRoYXQgb24gc29tZSBpc3N1ZXMgKGNvbmdlc3Rpb24N Cj4gPiBjb250cm9sIGFuZCBVRFANCj4gPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyByb3VuZCB0 aGUgbXVsYmVycnkgYnVzaC4NCj4gPg0KPiA+IElNSE8gYW5kIEZXSVc6DQo+ID4gLSBVRFAgY2hl Y2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJlY2F1c2UgbmF0aXZlIE1Q TFMNCj4gPiBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIGxpa2UgdGhhdC4gQW5kIHllcywgdGhlcmUg YXJlIGNhc2VzIHdoZXJlDQo+ID4gcGFja2V0cyBhcmUgY29ycnVwdGVkIHdpdGhpbiB0aGUgcm91 dGVycyksIGJ1dCBzbyBmYXIgaXQgZGlkIG5vdA0KPiA+IHByZXZlbnQgTVBMUyBkZXBsb3ltZW50 LiBUaGVyZSBpcywgZS5nLiwgUkZDIDQ3MjAgZm9yIEZDUyByZXRlbnRpb24gaW4NCj4gPiBQV3Ms IGJ1dCBJIGRvdWJ0IGl0IGlzIHdpZGVseSBpbXBsZW1lbnRlZCBhbmQgZGVwbG95ZWQgKHdvdWxk IGJlIG5pY2UgdG8NCj4ga25vdykuDQo+ID4gLSBFMkUgY29uZ2VzdGlvbiBjb250cm9sIChyZWdh cmRsZXNzIG9mIGl0cyBpbXBsaWNhdGlvbnMpIHNpbXBseQ0KPiA+IGNhbm5vdCBiZSBhZGRlZCB0 byB0aGlzIHByb3RvY29sIHdpdGhvdXQgc29tZSBtYWpvciBjaGFuZ2VzLiBBIHNob3J0DQo+ID4g YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZXhwbGFpbmluZyB0aGF0IHNob3VsZCBzdWZmaWNlIElN Ty4NCj4NCj4gSGkgU2FzaGEsDQo+DQo+IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHBvaW50cy4N Cj4NCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFvaHUNCj4NCj4gPiBNeSAyYywNCj4gPiAgICAgICAg U2FzaGENCj4gPiBFbWFpbDogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gPiBN b2JpbGU6IDA1NC05MjY2MzAyDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gPiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgRWdnZXJ0LCBMYXJzDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjIsIDIw MTQgMTI6MjMgUE0NCj4gPiA+IFRvOiBYdXhpYW9odQ0KPiA+ID4gQ2M6IEpvZWwgSmFlZ2dsaTsg bXBsc0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFm dC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4g VURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+ IE9uIDIwMTQtMS0yMiwgYXQgMTE6MTIsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3 cm90ZToNCj4gPiA+ID4gSSB3b25kZXIgd2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0sg dG8geW91Og0KPiA+ID4gPg0KPiA+ID4gPiBTaW5jZSB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxh dGlvbiBjYXVzZXMgTVBMUyBwYWNrZXRzIHRvIGJlDQo+ID4gPiBmb3J3YXJkZWQgdGhyb3VnaCAi VURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGd1aWRlbGluZXMNCj4gPiA+IGZv ciBVRFAgdHVubmVscyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjMgb2YgW1JGQzU0MDVdIFNI T1VMRCBiZQ0KPiBmb2xsb3dlZC4NCj4gPiA+IFNwZWNpZmljYWxseSwgTVBMUyBjYW4gY2Fycnkg YSBudW1iZXIgb2YgZGlmZmVyZW50IHByb3RvY29scyBhcyBwYXlsb2Fkcy4NCj4gPiA+IFdoZW4g YW4gVURQIHR1bm5lbCBpcyB1c2VkIGZvciBNUExTIHBheWxvYWQgdHJhZmZpYyB0aGF0IGlzIGtu b3duIGF0DQo+ID4gPiBjb25maWd1cmF0aW9uIHRpbWUgdG8gYmUgSVAtYmFzZWQgYW5kIGNvbmdl c3Rpb24tY29udHJvbGxlZCwgdGhlIFVEUA0KPiA+ID4gdHVubmVsIFNIT1VMRCBOT1QgZW1wbG95 IGl0cyBvd24gY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSwNCj4gPiA+IGJlY2F1c2UgY29u Z2VzdGlvbiBsb3NzZXMgb2YgdHVubmVsZWQgdHJhZmZpYyB3aWxsIHRyaWdnZXIgYW4NCj4gPiA+ IGNvbmdlc3Rpb24gcmVzcG9uc2UgYXQgdGhlIG9yaWdpbmFsIHNlbmRlcnMgb2YgdGhlIHR1bm5l bGVkIHRyYWZmaWMuDQo+ID4gPiBXaGVuIGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBw YXlsb2FkIHRyYWZmaWMgdGhhdCBpcyBrbm93biBhdA0KPiA+ID4gY29uZmlndXJhdGlvbiB0aW1l IG5vdCB0byBiZSBJUC1iYXNlZCBhbmQgY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUNCj4gPiA+ IFVEUCB0dW5uZWwgU0hPVUxEIGVtcGxveSBhbiBhcHByb3ByaWF0ZSBjb25nZXN0aW9uIGNvbnRy b2wgbWVjaGFuaXNtDQo+ID4gPiBhcyBkZXNjcmliZWQgaW4gW1JGQzM5ODVdLiBOb3RlIHRoYXQg aXQgU1RST05HTFkgUkVDT01NRU5ERUQgdG8NCj4gPiA+IGRlcGxveSBzdWNoIGVuY2Fwc3VsYXRp b24gdGVjaG5vbG9neSBvbmx5IHdpdGhpbiBhIFNQIG5ldHdvcmsgb3INCj4gPiA+IG5ldHdvcmtz IG9mIGFuIGFkamFjZW50IHNldCBvZiBjby1vcGVyYXRpbmcgU1BzLCByYXRoZXIgdGhhbiBvdmVy IHRoZQ0KPiBJbnRlcm5ldC4NCj4gPiA+IEZ1cnRoZXJtb3JlLCBwYWNrZXQgZmlsdGVycyBzaG91 bGQgYmUgYWRkZWQgdG8gYmxvY2sgdHJhZmZpYyB3aXRoDQo+ID4gPiB0aGUgVURQIHBvcnQgbnVt YmVyIGZvciBNUExTIG92ZXIgVURQIHRvIHByZXZlbnQgTVBMUyBvdmVyIFVEUA0KPiA+ID4gcGFj a2V0cyB0byBlc2NhcGUgZnJvbSB0aGUgc2VydmljZSBwcm92aWRlciBuZXR3b3JrcyBkdWUgdG8N Cj4gPiA+IG1pc2NvbmZpZ3VhdGlvbiBvciBwYWNrZXQNCj4gPiBlcnJvcnMuDQo+ID4gPg0KPiA+ ID4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVzY3JpYmUgdGhlIE9BTSBjb250cm9s IGxvb3AgaW4NCj4gPiA+IChzb21lKSBtb3JlIGRldGFpbCwgcmF0aGVyIHRoYW4gcG9pbnRpbmcg dG8gUkZDMzk4NSwgd2hpY2ggZG9lc24ndA0KPiA+ID4gaGF2ZSBhIHdob2xlIGxvdCBvZiBkZXRh aWwgZWl0aGVyLiBBbHNvIGJlY2F1c2UgdGhlIGFkZGluZyBvZg0KPiA+ID4gZmlyZXdhbGwgcnVs ZXMgcmVxdWlyZXMgYW4gT0FNIGhvb2suDQo+ID4gPg0KPiA+ID4gU2luY2UgU1RST05HTFkgUkVD T01NRU5ERUQgaXMgbm90IGFuIFJGQzIxMTkgdGVybSBhbmQNCj4gPiBSRUNPTU1FTkRFRCBpcw0K PiA+ID4gdG9vIHdlYWssIEknZCBzdWdnZXN0IHRvIGNoYW5nZSB0aGlzIHRvIE1VU1QuDQo+ID4g Pg0KPiA+ID4gRmluYWxseSwgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHNob3VsZCBiZSBw cm9taW5lbnRseSBtYWRlIGluDQo+ID4gPiB0aGUgYWJzdHJhY3QsIGludHJvZHVjdGlvbiwgZXRj Lg0KPiA+ID4NCj4gPiA+IExhcnMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From spencerdawkins.ietf@gmail.com Wed Jan 22 06:48:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDE71A0113; Wed, 22 Jan 2014 06:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57E7xIgE6j7u; Wed, 22 Jan 2014 06:48:11 -0800 (PST) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A94ED1A014B; Wed, 22 Jan 2014 06:48:10 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id h16so529625oag.30 for ; Wed, 22 Jan 2014 06:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cSOPjB8N1Xa9jg5gO0+Pl1i9QqB3QlrEXfOCpxkD8q4=; b=iUAoblElrl8dMmEVwYfMu9/FZs2tzddvvfdns1uCvURIFZdOKA+4uD0ptXqocl3rDl iNuRDekWYe9MiJRKXOAJ/9mpwlYiPY+rHJBA6KVcSg/aqYi+HAvIOqwEo7drIOtVaElc dcP0ISNMnq3ooSkzBBh0uAkRUIuNuyScTOGzuBmBdNm5dzxLyFd9bPO1Ztc9Rc+UF3BW C32zN4PfrEjOkXpBK4MR8lv6veLVU9BcJzso9zMlpeKnO9MGF3m5yNncmCtvJsvPUFOR jxVKHpPWxBFZYg0ALKOkDTUNGYB9uUY2sm3Bs/qe77c2Dd5fYKLwlGK32sC5NKdPnM69 9KVw== X-Received: by 10.182.22.33 with SMTP id a1mr1620189obf.60.1390402090123; Wed, 22 Jan 2014 06:48:10 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id oo13sm39900310oeb.0.2014.01.22.06.48.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 06:48:09 -0800 (PST) Message-ID: <52DFDA26.2070103@gmail.com> Date: Wed, 22 Jan 2014 08:48:06 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Scott Brim , Ross Callon References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <52D40B91.8040101@joelhalpern.com> <52D518D9.7010703@cisco.com> <52D547B2.1060302@cisco.com> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> <52DF1AC4.7080007@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 23 Jan 2014 10:57:52 -0800 Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 14:48:13 -0000 For what it's worth ... On 01/21/2014 10:03 PM, Scott Brim wrote: > On Tue, Jan 21, 2014 at 9:40 PM, Ross Callon wrote: >> If the upper layers (the thing that runs over the tunnel) involves applications over TCP over IP, or if it is otherwise responding to congestion in the same way that we expect anything running over IP to respond to congestion, then we don't want the tunnel to also independently try to respond to congestion (two independent cooks cooking the same meal does not necessarily lead to success). >> >> If the upper layer does not respond to congestion, then perhaps it shouldn't be running over the open Internet (with or without a tunnel), unless the *total* bandwidth that could be used is inherently quite low. On the other hand, it might want to run within a data center or internally to a service provider network with appropriate provisioning. > To paraphrase: if this problem exists in the new encapsulation, then > it exists already. > > Lars is right, this does allow traffic that was formerly run over > provisioned paths in well-managed networks to possibly be part of > general Internet traffic. It would be good if there were a way to be > _sure_ there was e2e congestion control. But there is no signaling > between this low-layer UDP encapsulation and anything above it that > might already be reacting to congestion. There is no reasonably easy > way for it to know what it is carrying. Yes there is a way to do > congestion control at the bottom layer, but doing so could destroy > performance if one (or more) layer(s) is already doing it up above. We > have experience with that. > > I can't remember who said it, but an applicability statement might > satisfy everyone, especially since it's been said (Curtis?) that this > just isn't going to be used in situations where congestion will be a > problem. Alia Atlas made this suggestion. Speaking as an AD who has been following this conversation with some interest ... that's gotta help. > Alternatively, a paragraph laying out the problem and saying if this > is used in a way that could impact ordinary traffic, a mechanism must > be defined. I would read such a paragraph with some interest ... Spencer From mls.ietf@gmail.com Wed Jan 22 07:57:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849181A02D9; Wed, 22 Jan 2014 07:57:01 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, 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 SKGeZ9jXTq0I; Wed, 22 Jan 2014 07:56:57 -0800 (PST) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 007501A02D5; Wed, 22 Jan 2014 07:56:56 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id m10so4761860eaj.12 for ; Wed, 22 Jan 2014 07:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dIghn2bh5Hftkq+R9GKQ8MqqfVq/aLsaUGxIeJ1ZJNU=; b=bE2sqOcCYq50JjzCEkFz8sCUcozWZobu52d2VzL1YucMiwU6+sE0Q3upts8al57aYw a+6Bc2AFRE7nqKC9jVW7ztYd4QplJoAwKzo35h3Q5HdtzP5E1QF46AgcDqxkUsLK8UtT 3H3lG9lQvnMgYE/xaIG9YILSDCq2JarrpsjsR/ZwGyMbsJEewUReBx3SDZJduCJJOywL ihbvUCEXBQU1q4XNT+LnVBK/D9oh6DzNTwG3Z4UUWy/8VrGA/XtXK2KaEct8a0X6lU+T f5HfN/h/1pcTj1fbG0ODgIZyJ6vBAFpk5A0ReK3bgNUgVRH8EPkz9Sle4PVFx/fMxqag KrMg== X-Received: by 10.15.36.65 with SMTP id h41mr2306940eev.0.1390406215900; Wed, 22 Jan 2014 07:56:55 -0800 (PST) Received: from [192.168.178.53] (port-92-202-18-73.dynamic.qsc.de. [92.202.18.73]) by mx.google.com with ESMTPSA id d43sm28517526eeo.12.2014.01.22.07.56.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 07:56:54 -0800 (PST) Message-ID: <52DFEA45.6040701@gmail.com> Date: Wed, 22 Jan 2014 16:56:53 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com, "Eggert, Lars" References: <201401171719.s0HHJqHY062965@maildrop2.v6ds.occnc.com> In-Reply-To: <201401171719.s0HHJqHY062965@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 23 Jan 2014 10:57:52 -0800 Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 15:57:01 -0000 Hi Curtis, I want to make an important observation below: On 01/17/2014 06:19 PM, Curtis Villamizar wrote: > Lars, > > We seem to be in an endless loop here. > > You have made your assertions about your desire to uphold the purity > of any new UDP applications and adhere to the BCP you wrote. > > You appear to be very nearly alone in this argument and certainly no > one that works with MPLS is siding with you. Lars is not alone but took the time and energy to comment on the draft. Lars' arguments are just right and need to be addressed. Regards, Martin Transport Area Director From jnc@mercury.lcs.mit.edu Wed Jan 22 09:29:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93B61A011B; Wed, 22 Jan 2014 09:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 ctB-qpFkctrB; Wed, 22 Jan 2014 09:29:31 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 17D701A0119; Wed, 22 Jan 2014 09:29:30 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3D31A18C13B; Wed, 22 Jan 2014 12:29:30 -0500 (EST) To: ietf@ietf.org, mpls@ietf.org Message-Id: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> Date: Wed, 22 Jan 2014 12:29:30 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailman-Approved-At: Thu, 23 Jan 2014 10:57:52 -0800 Cc: jnc@mercury.lcs.mit.edu Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 17:29:33 -0000 > From: "Eggert, Lars" > I would like the document to specify at the very least a circuit > breaker mechanism, that stops the tunneled traffic if severe packet > loss is detected along the path. I think people are looking at this from the wrong perspective, focusing in on UDP and what its specs say, and not on the larger engineering picture. Envision the following 4 (or more) scenarios for one Border Tunneling Routing (BTR), BTR A, to send packets to another BTR, BTR B, on the path from ultimate source S (somewhere before BTR A) to destination D (somewhere after BTR B). - Plain IP - Some existing encapsulation like GRE - A new, custom encapsulation - Encapsulation using UDP What you seem to be claiming is that in case 4 we need to have congestion detection and response at the intermediate forwarding node BTR A - but it would not be required in cases 1-3? This makes no sense. Even better, suppose that BTR A implements _both_ one of the first three, _and_ UDP encapsulation. If its response to UDP congestion on the path to BTR B is to.... switch to a _different_ encapsulation for traffic to that intermediate forwarding node, one for which it's not required to detect and respond to congestion, did that really help? Similarly, if people doing tunnels ditched UDP in favor of some other encapsulation (assuming they could find something that would get through as many filters as UDP does, would have the same load-spreading properties that UDP does, etc, etc - or maybe not, if that's the price they have to pay for being free of the grief they are getting because they are using UDP) - would that do anything at all for any potential congestion from their traffic? No, it would still be there, obviously. Look, the current architectural model of the Internet for dealing with congestion is that the _application endpoints_ have to notice it, and slow down. Intermediate forwarding nodes don't have any particular responsibility other than to drop packets if they have too many. You are quite right that if we take some application that doesn't detect and respond to congestion (perhaps because it was written for a local environment, and some bright spark is tunnelling that L2 protocol over the Internet), that can cause problems - but that's because we are violating the Internet's architectural assumption on how/who/where congestion control is done. I don't have any particularly brilliant suggestions on how to respond to situations in which applications don't detect and respond to congestion. Architecturally, if we are to keep to the existing congestion control scheme (endpoints are responsible), the responsibilty has to go back to the ultimate source of the traffic somehow... But saying that _intermediate forwarding nodes_ have to detect down-stream congestion, and respond, represents a fundamental change to the Internet's architecture for congestion control. Noel From jnc@mercury.lcs.mit.edu Wed Jan 22 10:33:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208111A0174; Wed, 22 Jan 2014 10:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 en5IS1-ZKUOD; Wed, 22 Jan 2014 10:33:17 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 139781A018B; Wed, 22 Jan 2014 10:32:37 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0FE0918C144; Wed, 22 Jan 2014 13:32:37 -0500 (EST) To: ietf@ietf.org, mpls@ietf.org Message-Id: <20140122183237.0FE0918C144@mercury.lcs.mit.edu> Date: Wed, 22 Jan 2014 13:32:37 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailman-Approved-At: Thu, 23 Jan 2014 10:57:52 -0800 Cc: jnc@mercury.lcs.mit.edu Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 18:33:20 -0000 > From: "Eggert, Lars" > that danger is somewhat mitigated, because such traffic typically dies > at the next NAT or firewall (unless that has been specifically > provisioned, which is then also OK). But such packets/protocols are usually not "provisioned" (i.e. specific resources set aside to carry them). Generally, they are merely "allowed" - and one then still has the potential of congestion at that device. > Depends on the reach of that encapsulation. .. If it traversed such > middleboxes by default, as UDP does, it has the same issues. Exactly. The problem is not specific to UDP. So why is the discussion (seemingly) trying to solve it in a UDP-specific way? I repeat: even if people were _not_ using UDP encapsulations, the exact same problem (of potential congestion caused by non-congestion-compliant applications) would still exist. Switching to a different encapsulation method is not going to get rid of _any_ potential congestion - not one packet's worth. So can we just drop all mention of UDP, since it's irrelevant to the _real_ problem? >> But saying that _intermediate forwarding nodes_ have to detect >> down-stream congestion, and respond, represents a fundamental change >> to the Internet's architecture for congestion control. > And here's the fallacy: UDP encapsulators are forwarding nodes *only* > from the viewpoint of the final endpoints. From the viewpoint of the > rest of the Internet, they are traffic *sources*, not *forwarders*. I present two boxes. In one, a packet comes in, and after some manipulation of headers, the packet goes out. In the other, a packet comes in, and after some header changes, the packet goes out. You're trying to tell me that, architecturally, one _is_ an intermediate forwarding node (which doesn't have to detect downsteam congestion, and respond), and the other is not (and so does have to)? And I repeat: mandating that nodes which are forwarding nodes have to detect, and respond to, downsteam congestion caused by non-congestion-compliant traffic flowing _through_ them is a fundamental change to the Internet's existing framework for congestion control. Not that I'm opposed to such a change (it might make sense, I'd have to go away and think about it), but if we're going to make such an architectural change, i) we should do so explicitly, and ii) such a requirement should fall on _all_ packet forwarding nodes - including regular routers, since they could equally possibly be given non-congestion-compliant traffic to forward. Noel From jnc@mercury.lcs.mit.edu Thu Jan 23 06:49:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BFA1A00FC; Thu, 23 Jan 2014 06:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 Qsawzw_UJ7lF; Thu, 23 Jan 2014 06:49:18 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id E316E1A00E2; Thu, 23 Jan 2014 06:49:17 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AF62D18C151; Thu, 23 Jan 2014 09:49:16 -0500 (EST) To: ietf@ietf.org, mpls@ietf.org Message-Id: <20140123144916.AF62D18C151@mercury.lcs.mit.edu> Date: Thu, 23 Jan 2014 09:49:16 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailman-Approved-At: Thu, 23 Jan 2014 10:57:52 -0800 Cc: jnc@mercury.lcs.mit.edu Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 14:49:20 -0000 > From: "Eggert, Lars" >>> Depends on the reach of that encapsulation. .. If it traversed such >>> middleboxes by default, as UDP does, it has the same issues. >> Exactly. The problem is not specific to UDP. > you conveniently cut the part of my original message where I tried to > explain that the difference is in *reach* of the traffic. Say what? Does not "Depends on the reach of that encapsulation. .. If it traversed such middleboxes by default" (which I did include) make exactly that point? But that's not important. Moving on... > encapsulators are not forwarding nodes from the viewpoint of the > network they tunnel over. They are traffic sources. You might just as well say that 'from the viewpoint of the rest of the Internet, a NAT box is a traffic source'. I mean, as far as the rest of the Internet can tell, it just sits there, and emits packets, right? After all, i) the packets it emits are quite different from the packets it receives, and ii) (to make your pet point) the original packets (which usually have RFC-1918 source addresses) would not make it far through the Internet without the header changes the NAT box makes. But I don't hear you clamouring to have NAT boxes detect, and respond to, down-stream congestion. Look at it from the point of view of the box. Something(s) is sending it packets, which it is supposed to forward. Basically, it can do one of three (really, two) things with the packet: - Forward it - Drop it - Queue it (but this eventually has to turn into 1 or 2, above) How is that any different between i) a plain old router, and ii) one of these boxes that you insist is a "traffic *source[]*, not [a] *forwarder[]*"? You want to separate out a very specific class of intermediate forwarding nodes, selected on a fairly arbitrary basis (the particular kind of header they emit), and impose requirements on them that are not imposed on any other intermediate forwarding nodes - and change the Internet's basic schemea of congestion control in the process. Why restrict that change to this particular kind of intermediate forwarding device? Noel From touch@isi.edu Thu Jan 23 13:16:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288431A00C9; Thu, 23 Jan 2014 13:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 ygOVmu-YtQFw; Thu, 23 Jan 2014 13:16:12 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC0C1A00B6; Thu, 23 Jan 2014 13:16:12 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0NLFD9m002532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jan 2014 13:15:14 -0800 (PST) Message-ID: <52E18661.4060000@isi.edu> Date: Thu, 23 Jan 2014 13:15:13 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Eggert, Lars" , Noel Chiappa References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> In-Reply-To: <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:16:16 -0000 On 1/22/2014 9:55 AM, Eggert, Lars wrote: > Hi, > > On 2014-1-22, at 18:29, Noel Chiappa wrote: >> Envision the following 4 (or more) scenarios for one Border Tunneling Routing >> (BTR), BTR A, to send packets to another BTR, BTR B, on the path from ultimate >> source S (somewhere before BTR A) to destination D (somewhere after BTR B). >> >> - Plain IP >> - Some existing encapsulation like GRE >> - A new, custom encapsulation >> - Encapsulation using UDP >> >> What you seem to be claiming is that in case 4 we need to have congestion >> detection and response at the intermediate forwarding node BTR A - but it >> would not be required in cases 1-3? This makes no sense. FWIW, the whole point of using UDP is to leverage the Internet's ability to interpret the tunneled traffic as application data - to manage it according to port-based flow interpretation. There's a cost associated with that privilege - the cost of needing to react to congestion. That doesn't require 1-RTT, TCP-friendly dynamic congestion control; it does mean *reacting* to congestion in some way, over some timescale more than just ignoring things. This should be expected of any tunneling system that encapsulates non-reactive flows - regardless of technology. Joe From touch@isi.edu Thu Jan 23 13:20:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6866D1A0140; Thu, 23 Jan 2014 13:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 a2FiViWBbdTb; Thu, 23 Jan 2014 13:20:48 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 054481A013B; Thu, 23 Jan 2014 13:20:48 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0NLK3mm003430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jan 2014 13:20:04 -0800 (PST) Message-ID: <52E18783.4020905@isi.edu> Date: Thu, 23 Jan 2014 13:20:03 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Eggert, Lars" , Noel Chiappa References: <20140122183237.0FE0918C144@mercury.lcs.mit.edu> <0DCB269E-D53D-4BF5-8D1A-42445ABBBB1E@netapp.com> In-Reply-To: <0DCB269E-D53D-4BF5-8D1A-42445ABBBB1E@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:20:49 -0000 On 1/23/2014 2:37 AM, Eggert, Lars wrote: > Since we're repeating ourselves, I'll again say that encapsulators are not forwarding nodes from the viewpoint of the network they tunnel over. They are traffic sources. +1 Just as NATs act like sources to the networks they traverse (NATs being a kind of tunnel that replaces encapsulation with translation). In both cases, they ought to behave just like any other source on that network. Joe From touch@isi.edu Thu Jan 23 13:22:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD3A1A01FD; Thu, 23 Jan 2014 13:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.235 X-Spam-Level: X-Spam-Status: No, score=-4.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 NjEYka13vFQA; Thu, 23 Jan 2014 13:22:45 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0F1A007C; Thu, 23 Jan 2014 13:22:45 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0NLMOTR003983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jan 2014 13:22:24 -0800 (PST) Message-ID: <52E18810.1010701@isi.edu> Date: Thu, 23 Jan 2014 13:22:24 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com, "Eggert, Lars" References: <201401212058.s0LKwcu2066223@maildrop2.v6ds.occnc.com> In-Reply-To: <201401212058.s0LKwcu2066223@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:22:47 -0000 Curtis, If you're going with this argument (SHOULD vs MUST), then you need to explain exactly *why* you're not doing what's recommended. "SHOULD" isn't carte blanche to claim an exception. And the need to avoid layered congestion control is a good justification for not layering TCP-friendly on top of TCP-friendly, but not for avoiding circuit breaker-style congestion controls/limits. Joe On 1/21/2014 12:58 PM, Curtis Villamizar wrote: > Lars, > > The IETF consensus in RFC5405 was to put a SHOULD in regarding use of > congestion control in tunneling protocols. > > RFC2119 states: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > We have discussed the reasons why congestion control is in general a > good thing. We have also discussed why there may be valid reasons to > not include congestion control in MPLS over UDP. > > The question is not whether there is already IETF consensus on > congestion control in UDP in general. There is consensus and that > consensus was to use the word "SHOULD". > > The question we now face is whether MPLS in UDP needs to up the prior > consensus to a MUST or can keep it as SHOULD. I see one or maybe two > people vigorously arguing to upgrade this to a MUST and otherwise > consensus to keep this as SHOULD. Further I see no objection except > the same one or maybe two people to making the congestion control the > topic of a later work if a need for it arises. Consensus does not > require unanimous agreeement. > > If we are trying to gauge consensus, maybe both you and I should sit > back and let other people weigh in. > > Curtis > > > In message > "Eggert, Lars" writes: >> >> Hi, >> >> On 2014-1-17, at 18:19, Curtis Villamizar wrote: >>> You have made your assertions about your desire to uphold the purity >>> of any new UDP applications and adhere to the BCP you wrote. >>> =20 >>> You appear to be very nearly alone in this argument and certainly no >>> one that works with MPLS is siding with you. >> >> the reason we wrote the RFC when I was TSV AD was that we were seeing a = >> whole bunch of questionable uses of UDP over the eyars and we were = >> having the same arguments over and over. That's why we decided to write = >> down the practices we expect users of UDP to follow. This is yet another = >> such questionable use. >> >> (Also, I don't appreciate you turning this into a personal argument.) > > Nothing personal intended. > > The important point is the sentence "You appear to be very nearly > alone in this argument and certainly no one that works with MPLS is > siding with you." was intended to point out that there is no consensus > behind your argument regardless of how vigorously you make that > argument. > >>> In the end we can put anything we want in the RFC *but* IETF has never >>> truly had the final word on what vendors and operators do in provider >>> networks. >> >> Aka the "take my toys and go home" argument. Heard it many times. > > It has been successful many times in the past. It turns into the "its > deployed so get over it" argument after a few years. > >>> In this case, regardless of what changes are made to the draft, >>> implementations will offer at least the option for non-RFC behavior by >>> using zero checksums and not using any congestion control. And >>> providers will make use of it, perhaps exclusively. >> >> And there's nothing wrong with that - the BCP even says that one SHOULD = >> NOT use congestion control for some deployment cases. >> >> But for others, one SHOULD. For those, a mechanism needs to be = >> available, i.e., it needs to be specified and implemented. >> >>> The document might as well reflect reality, despite reality not >>> conforming to your notions of architectural purity. >> >> I'm sorry, but we have certain architectural principles in the Internet = >> that we have IETF consensus on. At least since RFC2914, that includes = >> the need to have congestion control in place. >> >> There are always special deployment scenarios where these principles do = >> not apply, and we typically explain in applicability statements when out = >> specifications can only be safely used under certain conditions. I don't = >> see any such statement in draft-ietf-mpls-in-udp, which to me means it's = >> targeted at general Internet-wide use. >> >>> The best course of action is to put a SHOULD in regarding checksums >>> and put a SHOULD in regarding congestion avoidance. Even the BCP does >>> not go any further than to say a tunneling protocol SHOULD use >>> congestion control and there were reasons that the word MUST was not >>> acceptable in the BCP. >> >> The SHOULD for congestion control needs to actually describe a mechanism = >> that can be used when needed. It can't be a blanket "you SHOULD use = >> something but we don't tell you what it is"-statement. >> >>> If we are still arguing over two instances of SHOULD vs MUST we have >>> wasted a lot of bandwidth on those two words. >> >> It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it needs = >> to be specified what is to be done. In the case of checksums, that's = >> obvious (calculate it and check it); in the case of congestion control, = >> some actual mechanism needs to be described (e.g., a circuit breaker). >> >>> IMHO The only remaining question is whether the document can go = >> forward >>> with the definition of congestion control for MPLS over UDP left out >>> of scope and for another document if a need arises. >> >> In my opinion, it cannot. >> >>> If this is not acceptable to you (I doubt it is) please indicate what >>> you would like to see in the document and since this is IETF last call >>> where consensus matters and no one individual has veto power, we'll >>> have to see if there is consensus behind your proposed changes. >> >> I would like the document to specify at the very least a circuit breaker = >> mechanism, that stops the tunneled traffic if severe packet loss is = >> detected along the path. >> >> And this isn't about an "individual veto". This is about a document that = >> is at the moment in violation of IETF consensus at least as far back as = >> RFC2914. >> >> Lars From edc@google.com Thu Jan 23 13:28:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687521A02D2 for ; Thu, 23 Jan 2014 13:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, 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 xiUmVTCZyGSc for ; Thu, 23 Jan 2014 13:27:58 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8781A02D0 for ; Thu, 23 Jan 2014 13:27:58 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id w62so1828435wes.38 for ; Thu, 23 Jan 2014 13:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ySeAoBVOKxEcgFiTTL0qa++Og2YCAQ8uttU9Q+IcfdM=; b=J1b2cLlQjYq8fwTDYZrqGp/CcvKir+doLGZvqvP9pkIBDmtIWkk1CQxexuMNMx894H w3KYraGbHrlRAcnvpdFxp9ZqMRXVqhfbSVH6W+5wK7aiNvXPKqdI/Iyh4OdYlQWZTfsW ZiAOXbdiA6poWXDB4vBfP72t/msjq40m7kZzlQo/wlLp867My8zUrVsGFLbjMm6LJ5f6 mOHUa10xpLIQlCPQ2JlyH0pfvAvyL12PinBD0zldsu3+t36eQI+l/VBIA54wpFHUSO09 5Q6ytVeOqZj8K/qucCmgVvRN7kImiGIWeDObxfauR5Dj2V8tFprO09Otj9iUnQP8KEnD tvEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ySeAoBVOKxEcgFiTTL0qa++Og2YCAQ8uttU9Q+IcfdM=; b=Fx99sK7W+nXAbIYAyviSgIz+wwApNyjGvxmnj0phrSZ966kTYSSiPjZtmUrAxTtNYO BLIoGslBnm5CL0XfZLaMwSx8WRP9fbrQPDLl3o86eazEiROIVMnH17qx1NUvrV8tnyBx ybOeN4TSd7uE3K6KLyE3bTJ5PiYxz0H7AbgXEwAibo3gw9q4nJIJAuNjej5toHjYlXDo YGczqI7gWle6daxnRWrnWkmJKivhXlf5ipOeZa4RRM8bQIzcrU1yC0cqEq71WsRC+aUp XlQuFxldOpV/zrRLkfsd7xS4UcOAt59Rif3q2R4bG37gga6giRYKsLc+8uFg7/lgD5J1 2K1w== X-Gm-Message-State: ALoCoQn20F5es2nWkrNBtF8vHlQ2nM2dpvtZQsK2bwqPPCX/YxVmt3HD84TdcC8ffPcmFdYLkCMxH62NGg7nhoe7QDEvsNngHTyaSJtcYUmYkLSOZT4P8J1a7HjFtYZFBi0fecXO5S1fQz2dN5orQDxVWg6Xaoey8J85ZcsvbPqNbZlExAzlTR2Sbgux0OcWQLYBZI4+Y7Bb X-Received: by 10.180.9.74 with SMTP id x10mr567884wia.52.1390512476895; Thu, 23 Jan 2014 13:27:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Thu, 23 Jan 2014 13:27:16 -0800 (PST) In-Reply-To: <52E18661.4060000@isi.edu> References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> From: Edward Crabbe Date: Thu, 23 Jan 2014 13:27:16 -0800 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c245fa3de08904f0a9eac1 Cc: "mpls@ietf.org" , "Eggert, Lars" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:28:01 -0000 --001a11c245fa3de08904f0a9eac1 Content-Type: text/plain; charset=ISO-8859-1 Part of the point of using UDP is to make use of lowest common denominator forwarding hardware in introducing entropy to protocols that lack it ( this is particularly true of the GRE in UDP use case also under discussion elsewhere). The tunnel is not the source of the traffic. The _source of the traffic_ is the source of the traffic. The originating application who's traffic is being tunneled should be responsible for congestion control, or lack there of. Are we advocating a return to intermediate congestion control (I like X.25 as much as the next guy, but...). This is a very stark change of direction. I think mandating congestion control is not technically sound from either a theoretical (violation of end to end principle, stacking of congestion control algorithms leading to complex and potentially suboptimal results) or economic perspective (as a very large backbone, we've been doing just fine without intermediate congestion management thank you very much, and I have 0 desire to pay for a cost prohibitive, unnecessary feature in silicon.) I get Lars comments regarding reach, to some limited extent. Ultimately, the implication seems to be that the protocols riding the L2 network will have no form of congestion control and are fundamentally different than protocols that would reside on a typical wan. I have some serious doubts about this, although I'm sure this is the case in some specialized environments. At any rate, it seems to me that a stern warning regarding edge filtering on interdomain boundaries will be sufficient. On Thu, Jan 23, 2014 at 1:15 PM, Joe Touch wrote: > > > On 1/22/2014 9:55 AM, Eggert, Lars wrote: > >> Hi, >> >> On 2014-1-22, at 18:29, Noel Chiappa wrote: >> >>> Envision the following 4 (or more) scenarios for one Border Tunneling >>> Routing >>> (BTR), BTR A, to send packets to another BTR, BTR B, on the path from >>> ultimate >>> source S (somewhere before BTR A) to destination D (somewhere after BTR >>> B). >>> >>> - Plain IP >>> - Some existing encapsulation like GRE >>> - A new, custom encapsulation >>> - Encapsulation using UDP >>> >>> What you seem to be claiming is that in case 4 we need to have congestion >>> detection and response at the intermediate forwarding node BTR A - but it >>> would not be required in cases 1-3? This makes no sense. >>> >> > FWIW, the whole point of using UDP is to leverage the Internet's ability > to interpret the tunneled traffic as application data - to manage it > according to port-based flow interpretation. > > There's a cost associated with that privilege - the cost of needing to > react to congestion. That doesn't require 1-RTT, TCP-friendly dynamic > congestion control; it does mean *reacting* to congestion in some way, over > some timescale more than just ignoring things. > > This should be expected of any tunneling system that encapsulates > non-reactive flows - regardless of technology. > > Joe > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11c245fa3de08904f0a9eac1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Part of the point of using UDP is to make use of lowest co= mmon denominator forwarding hardware in introducing entropy to protocols th= at lack it ( this is particularly true of the GRE in UDP use case also unde= r discussion elsewhere).=A0

The tunnel is not the source of the traffic. =A0The _source = of the traffic_ is the source of the traffic. =A0The originating applicatio= n who's traffic is being tunneled should be responsible for congestion = control, or lack there of. =A0Are we advocating a return to intermediate co= ngestion control (I like X.25 as much as the next guy, but...). =A0This is = a very stark change of direction. =A0

I think mandating congestion control =A0is not technica= lly sound from either a theoretical (violation of end to end principle, sta= cking of congestion control algorithms leading to complex and potentially s= uboptimal results) or economic perspective (as a very large backbone, we= 9;ve been doing just fine without intermediate congestion management thank = you very much, and I have 0 desire to pay for a cost prohibitive, unnecessa= ry feature in silicon.)

I get Lars comments regarding reach, to some limited ex= tent. =A0Ultimately, the implication seems to be that the protocols riding = the L2 network will have no form of congestion control and are fundamentall= y different than protocols that would reside on a typical wan. =A0I have so= me serious doubts about this, although I'm sure this is the case in som= e specialized environments. =A0At any rate, it seems to me that a stern war= ning regarding edge filtering on interdomain boundaries will be sufficient.= =A0


On Thu,= Jan 23, 2014 at 1:15 PM, Joe Touch <touch@isi.edu> wrote:


On 1/22/2014 9:55 AM, Eggert, Lars wrote:
Hi,

On 2014-1-22, at 18:29, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
Envision the following 4 (or more) scenarios for one Border Tunneling Routi= ng
(BTR), BTR A, to send packets to another BTR, BTR B, on the path from ultim= ate
source S (somewhere before BTR A) to destination D (somewhere after BTR B).=

- Plain IP
- Some existing encapsulation like GRE
- A new, custom encapsulation
- Encapsulation using UDP

What you seem to be claiming is that in case 4 we need to have congestion detection and response at the intermediate forwarding node BTR A - but it would not be required in cases 1-3? This makes no sense.

FWIW, the whole point of using UDP is to leverage the Internet's abilit= y to interpret the tunneled traffic as application data - to manage it acco= rding to port-based flow interpretation.

There's a cost associated with that privilege - the cost of needing to = react to congestion. That doesn't require 1-RTT, TCP-friendly dynamic c= ongestion control; it does mean *reacting* to congestion in some way, over = some timescale more than just ignoring things.

This should be expected of any tunneling system that encapsulates non-react= ive flows - regardless of technology.

Joe

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--001a11c245fa3de08904f0a9eac1-- From touch@isi.edu Thu Jan 23 13:39:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF421A0140; Thu, 23 Jan 2014 13:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 mzEqwJrABF4R; Thu, 23 Jan 2014 13:39:23 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E57821A00C9; Thu, 23 Jan 2014 13:39:23 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0NLcwbP007223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jan 2014 13:38:58 -0800 (PST) Message-ID: <52E18BF1.1040004@isi.edu> Date: Thu, 23 Jan 2014 13:38:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Edward Crabbe References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , "Eggert, Lars" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:39:26 -0000 On 1/23/2014 1:27 PM, Edward Crabbe wrote: > Part of the point of using UDP is to make use of lowest common > denominator forwarding hardware in introducing entropy to protocols that > lack it ( this is particularly true of the GRE in UDP use case also > under discussion elsewhere). > > The tunnel is not the source of the traffic. The _source of the > traffic_ is the source of the traffic. To the Internet, the tunnel encapusulator is the source of traffic. Tracing the data back further than that is a mirage at best - and irrelevant. The tunnel head-end is responsible for the tunnel walking, talking, and quaking like a duck (host). When the tunnel head-end knows something about the ultimate origin of the traffic - whether real, imagined, or from Asgard - then it has done it's duty (e.g., that it's already congestion controlled). But that head end is responsible, regardless of what it knows or doesn't. And when it doesn't know, the only way to be responsible is to put in its own reactivity. > The originating application > who's traffic is being tunneled should be responsible for congestion > control, or lack there of. Perhaps it should be, but that's an agreement between whomever implements/deploys the tunnel headend and whomever provides the originating traffic to them. The problem is that this isn't true for the typical use case for this kind of encapsulation. I.e., if we were talking about MPLS traffic that already was reactive, we wouldn't be claiming the need for additional encapsulator mechanism. It's precisely because nothing is known about the MPLS traffic that the encapsulator needs to act. > Are we advocating a return to intermediate > congestion control (I like X.25 as much as the next guy, but...). This > is a very stark change of direction. > > I think mandating congestion control is not technically sound from > either a theoretical (violation of end to end principle, stacking of > congestion control algorithms leading to complex and potentially > suboptimal results) or economic perspective (as a very large backbone, > we've been doing just fine without intermediate congestion management > thank you very much, and I have 0 desire to pay for a cost prohibitive, > unnecessary feature in silicon.) Write that up, and we'll see how it turns out in the IETF. However, right now, the IETF BCPs do require reactive congestion management of transport streams. If you don't want/like that, then either don't use transport encapsulation, or change the BCPs. > I get Lars comments regarding reach, to some limited extent. > Ultimately, the implication seems to be that the protocols riding the > L2 network will have no form of congestion control and are fundamentally > different than protocols that would reside on a typical wan. I have > some serious doubts about this, although I'm sure this is the case in > some specialized environments. At any rate, it seems to me that a stern > warning regarding edge filtering on interdomain boundaries will be > sufficient. My concern may be slightly different that his. My concern is that you want the benefits of a UDP header, but don't like the responsibilities that come along with it. Joe From ietf-ipr@ietf.org Thu Jan 23 15:04:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BDB1A035C; Thu, 23 Jan 2014 15:04:52 -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 rsrC6-jnwzWm; Thu, 23 Jan 2014 15:04:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDB41A00C9; Thu, 23 Jan 2014 15:04:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: nobo@cisco.com,swallow@cisco.com,cpignata@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123230451.11634.89567.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 15:04:51 -0800 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Cisco's Statement of IPR Related to draft-akiya-mpls-entropy-lsp-ping-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 23:04:52 -0000 Dear Nobo Akiya, George Swallow, Carlos Pignataro: An IPR disclosure that pertains to your Internet-Draft entitled "Label Swi= tched Path (LSP) Ping/Trace over MPLS Network using Entropy Labels (EL)" (draft-a= kiya- mpls-entropy-lsp-ping) was submitted to the IETF Secretariat on 2014-01-23 = and has been posted on the "IETF Page of Intellectual Property Rights Disclosur= es" (https://datatracker.ietf.org/ipr/2305/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-akiya-mpls-entropy-lsp-ping-01."= "); The IETF Secretariat From curtis@ipv6.occnc.com Thu Jan 23 15:12:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E261A035C for ; Thu, 23 Jan 2014 15:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RP_MATCHES_RCVD=-0.535, 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 UsWAENONM3L2 for ; Thu, 23 Jan 2014 15:12:08 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9D50E1A02DC for ; Thu, 23 Jan 2014 15:12:07 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0NNC08b010650; Thu, 23 Jan 2014 18:12:00 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401232312.s0NNC08b010650@maildrop2.v6ds.occnc.com> To: "maciek@cisco.com" From: Curtis Villamizar In-reply-to: Your message of "Mon, 13 Jan 2014 20:28:16 +0000." Date: Thu, 23 Jan 2014 18:12:00 -0500 Cc: "mpls@ietf.org" , "draft-ietf-mpls-seamless-mpls.all@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Still open: working group lst call on draft-ietf-mpls-seamless-mpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 23:12:12 -0000 In message "Maciek Konstantynowicz (mkonstan)" writes: > Curtis, > > Pls see our comments inline, and let us know your thoughts. > We have also posted updated ID. There was very little change between the 04 version and the 05 version. > On 15 Oct 2013, at 18:09, Curtis Villamizar wrote: > > > > > Loa, > > > > No details are given in IPR #686 (applicable to RFC 5283) for the > > "Reasonable and Non-Discriminatory License to All Implementers with > > Possible Royalty/Fee." At the very least, some terms should be given. > > Update from Bruno in addition to the email he sent on > Date: 16 October 2013 08:43:46 GMT+01:00 > > <...> > Tried for more than 6 months, to have my IPR team to update the IPR 853 > to make it clear that it _replaces/supersede _ 686. > But they are not moving. It's all the more incredible that they have > dropped the patent. So no, it's not even "No licence Required" it's even > no IPR at all... > > That being said, the above IPR was on RFC 5283, not on seamless MPLS > draft. I had a discussion with Loa & Adrian on this, and there opinion > is that no IPR declaration would be required for draft seamless mpls. So > there is no real problem in the first place. > <...> > > > > > IPR #1920 and #2212 do provide details. > > > > An alternate to the use of a prefix based LDP LSP is to use a prefix > > based RSVP-TE LSP and carry the individual end-to-end LSP within it. > > This is not mentioned in the draft. See below for details. > > The use cases, proposed design and protocol choices have been driven by > the actual SP deployments. > > Design based on the hierarchy of RSVP-TE LSPs may address the listed use > cases. However the labeled BGP design with LDP DoD has been chosen due > to the higher degree of out-of-the-box automation and operational > simplicity as well as compatibility with the existing backbone and > backhaul designs & deployments which use LDP and not RSVP-TE. > > It also assumes relatively simple MPLS implementations on access nodes - > RFC 7032 goes into much more detail there. Could you please simply mention that RSVP-TE might be an alternative and then state the assumptions above in the document as reasons for using this approach. > > Scaling numbers are given as: > > > > Number of Aggregation Domains: 100 > > Number of Backbone Nodes: 1.000 > > Number of Aggregation Nodes: 10.000 > > Number of Access Nodes: 100.000 > > > > This section should state that very sparse connectivity among the set > > of access nodes is expected. For exampls, you would not expect each > > access node to have an LSP to every other access node. Is so, more > > than 10 such access nodes aggregated prior to a prefix based LSP would > > exceed the limits of the MPLS 20 bit label space. > > The requirement was to cater for service connectivity over transport > LSPs per scaling numbers provided for listed deployment use cases. The > required design was not to restrict the LSP based connectivity between > the access, aggregation and backbone nodes, catering equally well for > sparse and dense connectivity, but not the full-mesh. Full-mesh > connectivity between between all ANs will require each AN maintaining > LSP that they initiate and terminate, complicating the AN > implementation. > Luckily this is not the case in the listed use cases and the actual > access deployments. > > The result is the seamless MPLS design specified in this draft. And it > does work for dense transport LSP connectivity between the access nodes > without exhausting the MPLS 20-bit label space on any of the nodes by > relying on LSP hierarchy provided by labeled BGP for inter-domain > connectivity. > > See section 5.2 for scalability analysis, and numerical examples for > access node connectivity in section 5.2.1.5. > > > > > On the other hand it would not be unreasonable to expect each of the > > 10,000 aggregation nodes to be fully meshed or at least very densely > > meshed. This can also create problems without some form of > > aggregation as a worst case graph cut set with 5000 nodes on each side > > would have 25,000,000 LSP. A cutset of 2-5 nodes (typical core) could > > not support this (exceeds the 20 bit label space) without aggregation. > > We read your comment "without some form of aggregation" as meaning > "without some form of hierarchy". > If so, indeed this is why specified design used LSP hierarchy per > earlier comment. OK. I reread parts of your draft and I understand how you are using recursive LDP LFIB lookup to create a hierarchical label stack at the ABR. > > Some indication of how dense or sparse the connectivity would be > > useful in this section (2.1. Why Seamless MPLS). > > Indicative access node level connectivity has been described in section > 5.2 Scalability Analysis, but we agree that it makes sense to give an > indication in section 2.1 Access node connectivity is not mentioned in 5.2 as far as I can tell. What you do have in "5.2.1.4. Summary" is mention that "The main limitation is the MPLS connectivity requirements on the AN, i.e. mainly the number of LSP needed on the AN." At no point in this section is there mention that this limit is less than #AN because in the typical deployment there is a sparse mesh of connectivity among access nodes. You would really solve this if in "5.2.1.1. Introduction" you added a variable which is the number of access nodes that any one access node is connected to. Perhaps call it #AMD for access mesh density and explain what it is. You have a magical 1k and 100 under assumptions that comes out of thin air. You can replace it with #AMD (or whatever name you pick). Then when you do the worked examples in "5.2.1.5. Numerical application for use case #1" and "5.2.1.6. Numerical application for use case #2" you can include values for #AMD. I do think that right now the 1k and 100 numbers are reasonable values but I think in the future these may increase. The reason that the 1k number looks to be out of thin air is because sections 2.2.2 and 2.3.2 contain nothing but a table and no explanation and there is desription of the assumption or connection to the 1k number later on in section 5.2. See below on 2.2.2 and 2.3.2. [OT and IMO - the access node connectivity due to legacy circuits is expected to continue to drop even though actual TDM infrastructure is disappearing and being replaced with IP and PW for remaining TDM, FR, and ATM. OTOH - l3vpn connectivity is growing. Many potential l3vpn customers know they can use plain old Internet and tunnel traffic themselves and encrypt it. The value to them of l3vpn is mostly preferred treatment of traffic. As cost of l3vpn service drops, that value will out weigh the cost of the service until penetration increases (in which case cost may drop more).] btw- Are case #1 and case #2 the numbers that specific customers asked you to use? A simple "yes/no" question - no need to name them. > Following text added in section 2.1: > > Multiple Service Providers plan to deploy networks with 10k to 100k MPLS > nodes, with varying levels of MPLS LSP connectivity between those nodes > - sparse-mesh in access, partial-mesh in aggregation and full-mesh in > core. This is typically at least one order of magnitude higher than > typical deployments and may require a new architecture. OK. > > It may be worth > > creating a new subsection (2.2 Scaling Goals) and going into a little > > more detail. > > We believe this comment is addressed by above addition in section 2.1 > and section 5.2. Scalability Analysis. Let us know if this does address > your comment. Please consider the comments I've made above. I'm also not sure what "IGP Control Plane = 2" and "IP FIB = 2" mean in table 1 and table 2. You also have "LDP Control Plane = 200" (or 1000) and "LDP FIB = 200" (or 1000). It is not clear to me what it means for an access node to have 200 control planes. If the access node has only default routes I can see where "IP FIB = 2" would come about but that assumption is not stated. It is unclear what "IGP Control Plane = 2" means. Please explain in the document. It is also more common AFAIK to state how many VFRs the access node needs and also how many routes per VRF on average. Since the access nodes have a high fanout to CPE nodes, the number of IP fib entries would be the two conditional default routes plus at least one route per CPE attachment, plus VRF routes which should be counted separately. If it is assumed that the aggregation nodes hold the VRF, that should be stated. If you are just counting core facing IP routes, then say so in the document. BTW- the correct MPLS term is ILM. IFIB is a vendor term and so far does not appear in any RFCs. s/IFIB/ILM/g please. > > Then there is the question as to whether this draft should even go > > forward at all. > > Can you pls be more specific why you don't see this draft proceeding ? > > There are production implementation by both vendors and providers of > Seamless MPLS design as specified in this draft. Now that I see how you are doing the core hierarchy I see how this works. > > It is worth noting that a full mesh of 10.000 RSVP-TE LSP is feasible > > using hierarch. Within the core of 100 nodes, PSC-4 can be used. > > Each of the 1,000 backbone nodes can create a PSC-3 LSP to each other > > backbone node (using above terminology, "edge" nodes in more common > > core-edge-access or core-edge-aggregation-access terminology). If on > > average there are 10 backbone nodes per core node pair, then each core > > node has on the order of 10,000 ILM entries (about 20,000 if you > > consider 50 pairs of core nodes, each serving 20 nodes). There are > > only 100 LSP from each core node facing the core side, so FRR can be > > very effectively deployed. The same holds for a full mesh of the > > 10.000 aggregation nodes. If each of the 1,000 backbone nodes are > > deployed in pairs serving on average 20 nodes per pair, then an ILM > > siz on the order of 200,000 is needed. The PSC-3 LSP used to reach > > the far side backbone node can be used, yielding only 1,000 LSP facing > > the core per backbone node. Again, FRR can be used, with the protect > > path using the alternate core node of the designated pair. > > > > In this scenarion the access nodes may or may not be full meshed. If > > they are full meshed, then they need to be able to support 100,000 DoD > > mode LSP. If the are more sparsely meshed, they can support a lower > > number of DoD mode LSP. > > We do not disagree that alternative design approach based on RFC 4206 > and related h-LSP RFCs may be applied to address the LSP connectivity in > this environment. > > However we believe the design specified in the Seamless MPLS draft > better meets described requirements including better deployment > flexibility, better scaling and easier troubleshooting. As I said before, the draft would be greatly improved if you mentioned that you have considered this alternative and why you took the approach that you took. > > If RSVP-TE is used in this way, there is no need for aggregating LDP > > LSP. The LDP LSP are aggregated into RSVP-TE LSP and further > > aggregated in PSC-3 LSP and PSC-4 LSP in tiers closer to the core. > > The draft does not propose aggregating LDP LSPs. In fact the design > enables the operator to choose the transport LSP signalling protocol, > LDP or RSVP-TE, per domain, per section 4.4. Intra-Domain Routing. OK. I missed that mention of RSVP. We may have been arguing for similar solutions but your solution adding the recursive LDP route lookup when only a prefix route is present and resulting in a label stack. This is a very key aspect of your proposal and it is not well highlighted in section 4.5 where there is only the one word mention of hierarchy. Perhaps you could add a forward reference from that point such as a sentence saying "The mechanism for this hierarchy is defined in Section 5.1.3" and then change the title of 5.1.3 from hierarchy to "Hierarchy based on recursive LDP route lookup". This is AFAIK the first RFC mention of this technique and it is quite well buried. Also in this section please mention that router "I" could be an RSVP LSP or LDP LSP that reaches a prefix at the other ABR. > > There are ultimate scaling limits to either approach, imposed by the > > 20 bit label space. If a full mesh is needed at a given tier T with N > > nodes, then the nodes in tier T-1 aggregating tier T needs an ILM size > > of N times the number of T nodes the T-1 node serves. So for example, > > with a full mesh of 100,000 tier T nodes if each tier T-1 node could > > aggregate 8 tier T nodes without exceeding the 20 bit label space size > > (ILM=800,000 in this case), but could not aggregate 20 tier T nodes > > (ILM=2,000,000). If using RSVP-TE in the core, the core is limited by > > the worst case cut set, but core sizes of on the order of hundreds are > > OK (but smaller is better). > > In line with your comments the scaling limits are imposed not only by > MPLS 20-bit label space, but also by the number of supported LFIB > entries on specific MPLS node. > > Design in this draft relies on labeled BGP control plane to scale the > MPLS label distribution and to optimize the MPLS data plane on ABR nodes > by installing only the local labelled routes in its LFIB, as described > in section 5.1.7. Now that I see your LDP based hierarchy works I see how the scaling works out. > > Using either RSVP-TE or LDP for aggregation the outermost T-max tier > > could have a million nodes or more as long as they were sufficiently > > sparsely connected. This limit is independent of whether aggregation > > is via LDP or RSVP-TE. > > Similarly, the scale of the design in this draft is restricted by the > scale of AN at the outskirts of the MPLS network and their connectivity > needs driving the scale of neighbouring AGNs. We are in agreement. Your text was simply not clear to me. I'm not usually known to be more clueless than the average reader (maybe depends on who you ask, but OT) so it seems that some improvements in document clarity wouldn't hurt. I suspect that few people actually thoroughly read your document and thought about where your numbers came from and that may have more to do with lack of anyone else questioning your numbers (or maybe I *am* just really dense - I hope not). > > With RSVP-TE used for aggregation, T-LDP is used among the sparse mesh > > in the outermost T-max tier. A T-LDP session is only needed if FEC > > information needs to be exchanged via LDP to support an underlying > > service, otherwise RSVP-TE alone could be used. Using T-LDP the > > number of T-LDP TCP sessions could be a limiting factor for very > > highly connected tier T-max nodes. Either TCB state or the 16 bit TCP > > port limit could be the limit depending on how much RAM the T-max node > > has. OTOH if a tier T-max node out on the fringes is supporting on > > the order of 50K T-LDP sessions, it can use multiple IP addresses to > > get around the 16 bit TCP port number issue. > > In the draft, labeled BGP is used for labeled routes, providing excellent > scaling properties in the control plane. Yes. I agree. It was not clear to me at first how your hierarchy was working in the core with the labeled BGP routes exchanged but not installed in the core. At some point in the document you should mention that the labeled BGP routes are not installed in the core. I searched the document for the word BGP (the word BGP is in a lot of places) and there does not seem to be any mention that the BGP labeled routes are installed at the ABR and carried across the core but are not installed in the core. Again, this is a key aspect of the proposal and it has gone unstated. > > LDP could be extended to avoid the need for T-LDP sessions using LDP > > distribution of labels that will make use of RSVP-TE LSP. A DoD > > request would normally create a series of label bindings and swaps. > > If a full mesh of RSVP-TE LSP is know to exist within a prefix (ie: > > tier T), then the LSR can return a mapping of FEC,label,addr with its > > address. This mapping can be passed back and at each hop that > > actually does have a direct path to that address the mapping can be > > installed and the RSVP-TE LSP used as an outer label, even if there is > > no T-LDP session to that address. (btw- AFAIK no such extension > > exists, I'd be happy to be wrong about that). > > > > IMHO using RSPV-TE is a viable and IMHO better solution for the > > problem posed in this draft. > > It is opinion of the authors of this draft and WG members supporting > this draft that the design described in the draft is more optimal for > scaling MPLS into large access and aggregation deployments compared to > RSVP-TE with hierarchical LSPs. The draft also efficiently accommodates > capabilities of access device and the operational aspects. OK. Now I see how your approach works and I can see the benefits. Prior to this discussion it was not clear from reading the draft. > > It is also not encumbered by IPR AFAIK. > > IPRs are provided on non-discriminatory terms, per IETF standard. Yes. I've seen that. > > I don't think the draft provides a good solution. > > Per earlier note, the design specified by this draft has been accepted > by number of operators for production deployments. Now that I better understand how your proposal works, I withdraw my "not a good solution" comment and replace it with "your draft is not a clear description of your solution, but that can be easily fixed". Please consider making the changes that I have suggested to improve the document clarity. > /maciek Regards, Curtis > > Curtis > > > > > > > > In message <525CD992.2020800@pi.nu> > > Loa Andersson writes: > > > > Working Group, > > > > I'll will keep this wglc open until October 21st, there are several > > reasons. > > > > - the subject line did not explicitly say that this was a working group > > last call > > - we had a very late IPR disclosure, and we are still looking into that. > > We should like to draw the attention to the expectation that IPRs > > need to be disclosed in a timely fashion after your name appears on > > on a document, we are talking days or weeks, rather than months; and > > certainly not years > > - we have not seen any comments on the list, we are therefore now also > > asking if there is support to progress the draft. > > > > /Loa > > > > > > > > On 2013-09-26 13:37, Loa Andersson wrote: > >> Working Group, > >> > >> this is to start a two week+ working group last call on > >> draft-ietf-mpls-seamless-mpls-05. > >> > >> Please send your comment to working group mailing lists (mpls@ietf.org). > >> > >> We did an IPR poll on this document prior to starting the wglc. > >> All the authors responded to the IPR poll that they are not aware of > >> any IPR's relating to this document other than the one already > >> disclosed. > >> > >> There are no IPRs disclosed directly against this document, disclosure > >> #1920 was disclosed against an earlier individual version of the > >> document. > >> > >> It has also been pointed out that one of the components in the Seamless > >> MPLS architecture is derived from RFC 5283 and that IPR disclosures > >> # 686 and # 853 are applicable. > >> > >> The working group last call will end Friday October 11, 2913. > >> > >> /Loa > > > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 From edc@google.com Thu Jan 23 15:32:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55231A0250 for ; Thu, 23 Jan 2014 15:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lESP20tuKAR5 for ; Thu, 23 Jan 2014 15:32:45 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C21C71A01FD for ; Thu, 23 Jan 2014 15:32:44 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id l18so1243415wgh.5 for ; Thu, 23 Jan 2014 15:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7iEPFVrQDwc4acl4MKrckex2YxOTgnXyGxXhsmkODEQ=; b=pa4QVk5Pp8ZlhFoWQXHGnwqGLthIavXIhgaje1DZP6CfrvptzWZ0FBOObDcw2CSvYh 42X5wDsMF/g+DgouVPFQjo+cgiGOPXdblQW2u3T0tWBROs9iu/gwjNeO4lNKW8uSk7R4 v3d3P/1P2JqGpub17yNupT8ZI8ACteDPh1qd6c5BdgBFey2o4qckPEQ/ZbtqaO+8hT45 wfPhZDae7rmGUJJAPvzoNV/RFL874ozDwgwOjB8/AHQoShTWaBgmZvrQy0ViPupp05u+ dVUZwrxZ6F1WVNvWq+YjHpbFW+Ge7YmVikO9qZMgWLm1Yop12FnrcdLC0Qv5QrGqrADX 94MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7iEPFVrQDwc4acl4MKrckex2YxOTgnXyGxXhsmkODEQ=; b=OrtrB83ttIaD6hM9jft4PTn1khq0gqFg3nnwG3M85qVojF8SJXYSvuGv8T29c3zBJL mLWrUEI+SovyA65rHUjoT39x6CHQlD5OgRlTc3FcRNQZzwpGxV7vzp8ImrZn+QyFRTSB ILv6EMEk0lJpG1Yl2gK/DxsFgwWWMs1+0XuYHZUoUyIYvcFukqQp6+eTcbe7Bi8DS4M4 Ei06PZzBuX4/Hda/S9q4OmDWRrDhS8QVbM2YoDWBsrCNa6t0E4Mxajc++bDltHbJO5Pn 5qAuYV0YoSwUmO9bG/LUZ/C9bYLm9faY57ew3JxXxxMMTlvJLFv3T8sgZukwrPDT40gN micw== X-Gm-Message-State: ALoCoQkXZIj0Gq48B1Ziwn7zSRDp81dG5PO74Zd0E+mpb+GjLVQiY2EuCAzAxjmNBxXLH+wdbfI2y7Ljj7NXYKkOEDpU9fXI8lMNAp4IobtGDf3YJyQYeacSITYIlsLg3mKF2wcRvuNeCIsKUCcpLfJCOtdS3jWazx6O3yLuvfAMsW7Jv8O1UgLNeRB5Fm4cVoWPLUGuaVGe X-Received: by 10.195.13.17 with SMTP id eu17mr8614706wjd.24.1390519963327; Thu, 23 Jan 2014 15:32:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Thu, 23 Jan 2014 15:32:03 -0800 (PST) In-Reply-To: <52E18BF1.1040004@isi.edu> References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> From: Edward Crabbe Date: Thu, 23 Jan 2014 15:32:03 -0800 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=047d7bd91a7a77b4c304f0aba8c7 Cc: "mpls@ietf.org" , "Eggert, Lars" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 23:32:47 -0000 --047d7bd91a7a77b4c304f0aba8c7 Content-Type: text/plain; charset=ISO-8859-1 Joe, thanks for your response. Comments inline: > On 1/23/2014 1:27 PM, Edward Crabbe wrote: > >> Part of the point of using UDP is to make use of lowest common >> denominator forwarding hardware in introducing entropy to protocols that >> lack it ( this is particularly true of the GRE in UDP use case also >> under discussion elsewhere). >> >> The tunnel is not the source of the traffic. The _source of the >> traffic_ is the source of the traffic. >> > > To the Internet, the tunnel encapusulator is the source of traffic. > Tracing the data back further than that is a mirage at best - and > irrelevant. > The 'internet' cares about characteristics of reactivity to congestion. This is guaranteed by the /source of the traffic/ independent of any intermediate node. > > The tunnel head-end is responsible for the tunnel walking, talking, and > quaking like a duck (host). When the tunnel head-end knows something about > the ultimate origin of the traffic - whether real, imagined, or from Asgard > - then it has done it's duty (e.g., that it's already congestion > controlled). > > But that head end is responsible, regardless of what it knows or doesn't. > And when it doesn't know, the only way to be responsible is to put in its > own reactivity. This is not fact; it's actually precisely the principle we're currently arguing about. ;) I would posit: The tunnel doesn't have to know anything about congestion or performance characteristics because the originating application must. See GRE, MPLS, many other tunnel types, including several existing within the IETF that make use of an outer UDP header. > > > The originating application >> who's traffic is being tunneled should be responsible for congestion >> control, or lack there of. >> > > Perhaps it should be, but that's an agreement between whomever > implements/deploys the tunnel headend and whomever provides the originating > traffic to them. The problem is that this isn't true for the typical use > case for this kind of encapsulation. > How so? As mentioned before, this is the same case as standard GRE/MPLS etc. > > I.e., if we were talking about MPLS traffic that already was reactive, we > wouldn't be claiming the need for additional encapsulator mechanism. It's > precisely because nothing is known about the MPLS traffic that the > encapsulator needs to act. The MPLS traffic doesn't have to be reactive, it's the applications being encapsulated / traversing a particular tunnel that are responsible for and aware of path and congestion charateristics. Because the MPLS head end knows nothing about the /end to end application 'session'/ characteristics it /shouldn't/ have anything to do with congestion management. > > > Are we advocating a return to intermediate > >> congestion control (I like X.25 as much as the next guy, but...). This >> is a very stark change of direction. >> >> I think mandating congestion control is not technically sound from >> either a theoretical (violation of end to end principle, stacking of >> congestion control algorithms leading to complex and potentially >> suboptimal results) or economic perspective (as a very large backbone, >> we've been doing just fine without intermediate congestion management >> thank you very much, and I have 0 desire to pay for a cost prohibitive, >> unnecessary feature in silicon.) >> > > Write that up, and we'll see how it turns out in the IETF. However, right > now, the IETF BCPs do require reactive congestion management of transport > streams. > Which part? The end-to-end principle, or the aversion to congestion control stacking? These have been implicit in all tunneling protocols produced by the IETF for the modern internet. > If you don't want/like that, then either don't use transport > encapsulation, or change the BCPs. These BCPs are defined for an originating /application/. In this case the UDP header is simply a shim header applied to existing application traffic. The tunnel head does not introduce traffic independent of the originating application. > > > I get Lars comments regarding reach, to some limited extent. >> Ultimately, the implication seems to be that the protocols riding the >> L2 network will have no form of congestion control and are fundamentally >> different than protocols that would reside on a typical wan. I have >> some serious doubts about this, although I'm sure this is the case in >> some specialized environments. At any rate, it seems to me that a stern >> warning regarding edge filtering on interdomain boundaries will be >> sufficient. >> > > My concern may be slightly different that his. My concern is that you want > the benefits of a UDP header, but don't like the responsibilities that come > along with it. > > Joe > > --047d7bd91a7a77b4c304f0aba8c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joe, thanks for your response. Comments inline:


On 1/23/2014 1:27 PM, Edward Crabbe wrote:
Part of the point of using UDP is to make use of lowest common
denominator forwarding hardware in introducing entropy to protocols that lack it ( this is particularly true of the GRE in UDP use case also
under discussion elsewhere).

The tunnel is not the source of the traffic. =A0The _source of the
traffic_ is the source of the traffic.

To the Internet, the tunnel encapusulator is the source of traffic. Tracing= the data back further than that is a mirage at best - and irrelevant.
<= /blockquote>

The 'internet' cares about characte= ristics of reactivity to congestion. =A0This is guaranteed by the /source o= f the traffic/ independent of any intermediate node.=A0
=A0

The tunnel head-end is responsible for the tunnel walking, talking, and qua= king like a duck (host). When the tunnel head-end knows something about the= ultimate origin of the traffic - whether real, imagined, or from Asgard - = then it has done it's duty (e.g., that it's already congestion cont= rolled).

But that head end is responsible, regardless of what it knows or doesn'= t. And when it doesn't know, the only way to be responsible is to put i= n its own reactivity.

This is not fact; it&= #39;s actually precisely the principle =A0we're currently arguing about= . =A0;)

I would posit:

The tunnel does= n't have to know anything about congestion or performance characteristi= cs because the originating application must. =A0See GRE, MPLS, many other t= unnel types, including several existing within the IETF that make use of an= outer UDP header.
=A0


The originating application
who's traffic is being tunneled should be responsible for congestion control, or lack there of.

Perhaps it should be, but that's an agreement between whomever implemen= ts/deploys the tunnel headend and whomever provides the originating traffic= to them. The problem is that this isn't true for the typical use case = for this kind of encapsulation.

How so? =A0As mentioned before, this is th= e same case as standard GRE/MPLS etc. =A0
=A0

I.e., if we were talking about MPLS traffic that already was reactive, we w= ouldn't be claiming the need for additional encapsulator mechanism. It&= #39;s precisely because nothing is known about the MPLS traffic that the en= capsulator needs to act.

The MPLS traffic doesn't have to be reactive, it= 9;s the applications being encapsulated / traversing a particular tunnel th= at are responsible for and aware of path and congestion charateristics. =A0= Because the MPLS head end knows nothing about the /end to end application &= #39;session'/ characteristics it /shouldn't/ have anything to do wi= th congestion management. =A0
=A0

> Are we advocating a return to intermediate
congestion control (I like X.25 as much as the next guy, but...). =A0This is a very stark change of direction.

I think mandating congestion control =A0is not technically sound from
either a theoretical (violation of end to end principle, stacking of
congestion control algorithms leading to complex and potentially
suboptimal results) or economic perspective (as a very large backbone,
we've been doing just fine without intermediate congestion management thank you very much, and I have 0 desire to pay for a cost prohibitive,
unnecessary feature in silicon.)

Write that up, and we'll see how it turns out in the IETF. However, rig= ht now, the IETF BCPs do require reactive congestion management of transpor= t streams.

Which part? =A0The end-to-en= d principle, or the aversion to congestion control stacking? =A0These have = been implicit in all tunneling protocols produced by the IETF for the moder= n internet.=A0
=A0
If you don't want/like that, then either don't use transport encaps= ulation, or change the BCPs.


These BCPs are defined for an originating /application/. =A0In this case t= he UDP header is simply a shim header applied to existing application traff= ic. =A0The tunnel head does not introduce traffic independent of the origin= ating application. =A0
=A0


I get Lars comments regarding reach, to some limited extent.
=A0 Ultimately, the implication seems to be that the protocols riding the L2 network will have no form of congestion control and are fundamentally different than protocols that would reside on a typical wan. =A0I have
some serious doubts about this, although I'm sure this is the case in some specialized environments. =A0At any rate, it seems to me that a stern<= br> warning regarding edge filtering on interdomain boundaries will be
sufficient.

My concern may be slightly different that his. My concern is that you want = the benefits of a UDP header, but don't like the responsibilities that = come along with it.

Joe


--047d7bd91a7a77b4c304f0aba8c7-- From touch@isi.edu Thu Jan 23 15:57:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BF71A03E6; Thu, 23 Jan 2014 15:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 dUbHBaI_hRIN; Thu, 23 Jan 2014 15:57:23 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A34F41A01D3; Thu, 23 Jan 2014 15:57:23 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0NNukiX004611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jan 2014 15:56:46 -0800 (PST) Message-ID: <52E1AC3E.2040204@isi.edu> Date: Thu, 23 Jan 2014 15:56:46 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Edward Crabbe References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , "Eggert, Lars" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 23:57:26 -0000 On 1/23/2014 3:32 PM, Edward Crabbe wrote: > Joe, thanks for your response. Comments inline: > > > On 1/23/2014 1:27 PM, Edward Crabbe wrote: > > Part of the point of using UDP is to make use of lowest common > denominator forwarding hardware in introducing entropy to > protocols that > lack it ( this is particularly true of the GRE in UDP use case also > under discussion elsewhere). > > The tunnel is not the source of the traffic. The _source of the > traffic_ is the source of the traffic. > > > To the Internet, the tunnel encapusulator is the source of traffic. > Tracing the data back further than that is a mirage at best - and > irrelevant. > > > The 'internet' cares about characteristics of reactivity to congestion. > This is guaranteed by the /source of the traffic/ independent of any > intermediate node. Are you prepared to make that a requirement of this document, i.e., that the only MPLS traffic that can be UDP encapsulated is known to react to congestion? How exactly can you know that? > The tunnel head-end is responsible for the tunnel walking, talking, > and quaking like a duck (host). When the tunnel head-end knows > something about the ultimate origin of the traffic - whether real, > imagined, or from Asgard - then it has done it's duty (e.g., that > it's already congestion controlled). > > But that head end is responsible, regardless of what it knows or > doesn't. And when it doesn't know, the only way to be responsible is > to put in its own reactivity. > > This is not fact; it's actually precisely the principle we're currently > arguing about. ;) Actually, it's a paraphrasing of Section 3.1.3 of RFC5405. We can continue to debate it, but until it's been *changed* by a revision, it remains BCP. > I would posit: > > The tunnel doesn't have to know anything about congestion or performance > characteristics because the originating application must. That works only if you know that fact about the originating application. However, there are plenty of applications whose traffic goes over MPLS that isn't congestion reactive or bandwidth-limited. > See GRE, > MPLS, many other tunnel types, This isn't an issue for all tunnels until they enter the Internet... > including several existing within the > IETF that make use of an outer UDP header. Which are all already supposed to follow the recommendations of RFC5405. To the extent that they don't, they don't agree with that BCP. I'm not saying such things never can or will exist, but I don't think the IETF should be self-contradictory. We already agreed as a group on such BCPs and other standards, and new standards-track docs need to follow them. > The originating application > who's traffic is being tunneled should be responsible for congestion > control, or lack there of. > > Perhaps it should be, but that's an agreement between whomever > implements/deploys the tunnel headend and whomever provides the > originating traffic to them. The problem is that this isn't true for > the typical use case for this kind of encapsulation. > > How so? As mentioned before, this is the same case as standard GRE/MPLS > etc. It's putting MPLS inside UDP. That's a different case, and the reason RFC5405 applies. > I.e., if we were talking about MPLS traffic that already was > reactive, we wouldn't be claiming the need for additional > encapsulator mechanism. It's precisely because nothing is known > about the MPLS traffic that the encapsulator needs to act. > > The MPLS traffic doesn't have to be reactive, it's the applications > being encapsulated / traversing a particular tunnel that are responsible > for and aware of path and congestion charateristics. Because the MPLS > head end knows nothing about the /end to end application 'session'/ > characteristics it /shouldn't/ have anything to do with congestion > management. OK, so what you're saying is that "traffic using this encapsulation MUST be known to be congestion reactive". Put that in the doc and we'll debate whether we believe it. But right now you're basically saying that because you think it's someone else's problem (the originating application), it isn't yours. The difficulty with that logic is that you (the tunnel headend) is responsible to ensure that this is true - either by *knowing* that the originating traffic is congestion reactive, or by putting in its own mechanism to ensure that this happens if the originating application isn't. > > Are we advocating a return to intermediate > > congestion control (I like X.25 as much as the next guy, > but...). This > is a very stark change of direction. > > I think mandating congestion control is not technically sound from > either a theoretical (violation of end to end principle, stacking of > congestion control algorithms leading to complex and potentially > suboptimal results) or economic perspective (as a very large > backbone, > we've been doing just fine without intermediate congestion > management > thank you very much, and I have 0 desire to pay for a cost > prohibitive, > unnecessary feature in silicon.) > > Write that up, and we'll see how it turns out in the IETF. However, > right now, the IETF BCPs do require reactive congestion management > of transport streams. > > Which part? The end-to-end principle, or the aversion to congestion > control stacking? These have been implicit in all tunneling protocols > produced by the IETF for the modern internet. Sure, and that's reflected in RFC5405 already. However, please, PLEASE appreciate that NOBODY here is asking you to put in "congestion control stacking"; that happens when you run two dynamic, reactive control algorithms using the same timescale on top of each other. Equally well-known in CC circles is that you CAN - and often *should* - stack different kinds of mechanisms at different layers with different timescales. E.g., that's why we have an AQM WG - because even when all the traffic is TCP, that's not quite enough inside the network. That's also why Lars was suggesting something coarse on a longer timescale - a circuit breaker - rather than AIMD on a RTT basis. Keep in mind as well that the E2E argument says that you can't get an E2E service by composing the equivalent HBH one; it also says that HBH mechanisms can be required for efficiency. That's what we're talking about here - the efficiency impact of congestion, not the overall correctness of E2E control. > If you don't want/like that, then either don't use transport > encapsulation, or change the BCPs. > > These BCPs are defined for an originating /application/. Yes, and I don't understand why you (and others) keep thinking it matters that there are layers of things behind the tunnel head end. It doesn't - unless you KNOW what those layers are, and can ensure that they behave as you expect. > In this case > the UDP header is simply a shim header applied to existing application > traffic. It's not "simply a shim" - if that's the case, use IP and we're done. No need for congestion control. The reason congestion issues arise is because you're inserting a header ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO REACT TO****. If you put in a UDP-like header that nobody in the Internet would interpret, this wouldn't be an issue. But you simply cannot expect the Internet to treat you like "application" traffic if you won't enforce acting like that traffic too. > The tunnel head does not introduce traffic independent of the > originating application. The Internet ****neither knows nor cares****. To the Internet, the head-end is the source. Whatever data the head end puts inside the UDP packets *is application data* to the rest of the Internet. Again, if you are saying that you know so much about the originating source that you know you don't need additional mechanism at the headend, say so - but then live by that requirement. If *any* MPLS traffic could show up at the headend, then it becomes the headend's responsibility to do something. --- Consider the following case: - video shows up inside the OS, destined for the network - software X bundles that video and sends it to go out - software Y puts that data into UDP packets to go to the Internet So what's the "application" here? To the Internet, it's software Y -- the thing that puts the 'application' data into UDP packets. The previous steps are irrelevant - just as irrelevant as the singer your video camera is filming, as irrelevant as the sun that created the light that is reflected off the singer to your camera. If software Y knows so much about the steps that lead to its input data that it knows it's congestion reactive, nothing more need be done. If NOT (and that's the relevant corollary here), then it becomes software Y's responsibility to put in some reactivity. Joe From akatlas@gmail.com Thu Jan 23 16:07:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046B21A0493; Thu, 23 Jan 2014 16:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yysSrxnD2GRb; Thu, 23 Jan 2014 16:07:26 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 96C7E1A0491; Thu, 23 Jan 2014 16:07:26 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tp5so2007145ieb.7 for ; Thu, 23 Jan 2014 16:07:25 -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=VwcuizKnEIN/7aOhj2d1R6wjOLeSik0tNx9fgGVzRUY=; b=s4kWvHuNFb4/27LtN1RwsV9VR8tGernHUVYEcff9+Z+usUElLw2hkv7KK02ycbQhW/ mH1qB4Zd5HdHY4J9jI3Zr9uh7+2XAATtM/Cf3/+Y/NwpPMRJOv8inBjbQWv1TQRQvM1L GBkj6efPOg27UY2OvaOWhFdVZCijWNEG5n2cQA8vBiS8S6XvWGgcKLeY+iXzvKyyL70d kwFt6D99mDu+qkxGiDA8hmXm4liJKTU+6IwGSoegogEfZJcuTZqZRqPGk7okiwNn4NJf pbf6s3t1+hZK5+4u8BSAyxqK5H0XiLG1mfm45A5kQfhIj6wjTQqrTtcnuiC59WcHvfzc hVvQ== MIME-Version: 1.0 X-Received: by 10.43.163.3 with SMTP id mm3mr11845icc.63.1390522045559; Thu, 23 Jan 2014 16:07:25 -0800 (PST) Received: by 10.64.72.132 with HTTP; Thu, 23 Jan 2014 16:07:25 -0800 (PST) In-Reply-To: <52E1AC3E.2040204@isi.edu> References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> <52E1AC3E.2040204@isi.edu> Date: Thu, 23 Jan 2014 19:07:25 -0500 Message-ID: From: Alia Atlas To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c2fafe93fadf04f0ac2478 Cc: "mpls@ietf.org" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:07:31 -0000 --001a11c2fafe93fadf04f0ac2478 Content-Type: text/plain; charset=ISO-8859-1 I don't want to get in the way of vehement discussion, but I thought we were on the verge of finding an actual solution... IMHO, that was a combination of an applicability statement, using SHOULD for congestion control and checksum, and defining a longer-term OAM-based approach (as Stewart Bryant suggested) to be able to verify that packet corruption or excessive drops aren't happening. Does that sound like an acceptable set? Alia On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch wrote: > > > On 1/23/2014 3:32 PM, Edward Crabbe wrote: > >> Joe, thanks for your response. Comments inline: >> >> >> On 1/23/2014 1:27 PM, Edward Crabbe wrote: >> >> Part of the point of using UDP is to make use of lowest common >> denominator forwarding hardware in introducing entropy to >> protocols that >> lack it ( this is particularly true of the GRE in UDP use case >> also >> under discussion elsewhere). >> >> The tunnel is not the source of the traffic. The _source of the >> traffic_ is the source of the traffic. >> >> >> To the Internet, the tunnel encapusulator is the source of traffic. >> Tracing the data back further than that is a mirage at best - and >> irrelevant. >> >> >> The 'internet' cares about characteristics of reactivity to congestion. >> This is guaranteed by the /source of the traffic/ independent of any >> intermediate node. >> > > Are you prepared to make that a requirement of this document, i.e., that > the only MPLS traffic that can be UDP encapsulated is known to react to > congestion? > > How exactly can you know that? > > > The tunnel head-end is responsible for the tunnel walking, talking, >> and quaking like a duck (host). When the tunnel head-end knows >> something about the ultimate origin of the traffic - whether real, >> imagined, or from Asgard - then it has done it's duty (e.g., that >> it's already congestion controlled). >> >> But that head end is responsible, regardless of what it knows or >> doesn't. And when it doesn't know, the only way to be responsible is >> to put in its own reactivity. >> >> This is not fact; it's actually precisely the principle we're currently >> arguing about. ;) >> > > Actually, it's a paraphrasing of Section 3.1.3 of RFC5405. > > We can continue to debate it, but until it's been *changed* by a revision, > it remains BCP. > > > I would posit: >> >> The tunnel doesn't have to know anything about congestion or performance >> characteristics because the originating application must. >> > > That works only if you know that fact about the originating application. > However, there are plenty of applications whose traffic goes over MPLS that > isn't congestion reactive or bandwidth-limited. > > > > See GRE, > >> MPLS, many other tunnel types, >> > > This isn't an issue for all tunnels until they enter the Internet... > > > including several existing within the >> IETF that make use of an outer UDP header. >> > > Which are all already supposed to follow the recommendations of RFC5405. > To the extent that they don't, they don't agree with that BCP. > > I'm not saying such things never can or will exist, but I don't think the > IETF should be self-contradictory. We already agreed as a group on such > BCPs and other standards, and new standards-track docs need to follow them. > > > The originating application >> who's traffic is being tunneled should be responsible for >> congestion >> control, or lack there of. >> >> Perhaps it should be, but that's an agreement between whomever >> implements/deploys the tunnel headend and whomever provides the >> originating traffic to them. The problem is that this isn't true for >> the typical use case for this kind of encapsulation. >> >> How so? As mentioned before, this is the same case as standard GRE/MPLS >> etc. >> > > It's putting MPLS inside UDP. That's a different case, and the reason > RFC5405 applies. > > > I.e., if we were talking about MPLS traffic that already was >> reactive, we wouldn't be claiming the need for additional >> encapsulator mechanism. It's precisely because nothing is known >> about the MPLS traffic that the encapsulator needs to act. >> >> The MPLS traffic doesn't have to be reactive, it's the applications >> being encapsulated / traversing a particular tunnel that are responsible >> for and aware of path and congestion charateristics. Because the MPLS >> head end knows nothing about the /end to end application 'session'/ >> characteristics it /shouldn't/ have anything to do with congestion >> management. >> > > OK, so what you're saying is that "traffic using this encapsulation MUST > be known to be congestion reactive". Put that in the doc and we'll debate > whether we believe it. > > But right now you're basically saying that because you think it's someone > else's problem (the originating application), it isn't yours. The > difficulty with that logic is that you (the tunnel headend) is responsible > to ensure that this is true - either by *knowing* that the originating > traffic is congestion reactive, or by putting in its own mechanism to > ensure that this happens if the originating application isn't. > > > > Are we advocating a return to intermediate >> >> congestion control (I like X.25 as much as the next guy, >> but...). This >> is a very stark change of direction. >> >> I think mandating congestion control is not technically sound >> from >> either a theoretical (violation of end to end principle, stacking >> of >> congestion control algorithms leading to complex and potentially >> suboptimal results) or economic perspective (as a very large >> backbone, >> we've been doing just fine without intermediate congestion >> management >> thank you very much, and I have 0 desire to pay for a cost >> prohibitive, >> unnecessary feature in silicon.) >> >> Write that up, and we'll see how it turns out in the IETF. However, >> right now, the IETF BCPs do require reactive congestion management >> of transport streams. >> >> Which part? The end-to-end principle, or the aversion to congestion >> control stacking? These have been implicit in all tunneling protocols >> produced by the IETF for the modern internet. >> > > Sure, and that's reflected in RFC5405 already. However, please, PLEASE > appreciate that NOBODY here is asking you to put in "congestion control > stacking"; that happens when you run two dynamic, reactive control > algorithms using the same timescale on top of each other. > > Equally well-known in CC circles is that you CAN - and often *should* - > stack different kinds of mechanisms at different layers with different > timescales. E.g., that's why we have an AQM WG - because even when all the > traffic is TCP, that's not quite enough inside the network. That's also why > Lars was suggesting something coarse on a longer timescale - a circuit > breaker - rather than AIMD on a RTT basis. > > Keep in mind as well that the E2E argument says that you can't get an E2E > service by composing the equivalent HBH one; it also says that HBH > mechanisms can be required for efficiency. That's what we're talking about > here - the efficiency impact of congestion, not the overall correctness of > E2E control. > > > If you don't want/like that, then either don't use transport >> encapsulation, or change the BCPs. >> >> These BCPs are defined for an originating /application/. >> > > Yes, and I don't understand why you (and others) keep thinking it matters > that there are layers of things behind the tunnel head end. It doesn't - > unless you KNOW what those layers are, and can ensure that they behave as > you expect. > > > In this case >> the UDP header is simply a shim header applied to existing application >> traffic. >> > > It's not "simply a shim" - if that's the case, use IP and we're done. No > need for congestion control. > > The reason congestion issues arise is because you're inserting a header > ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO REACT TO****. > > If you put in a UDP-like header that nobody in the Internet would > interpret, this wouldn't be an issue. > > But you simply cannot expect the Internet to treat you like "application" > traffic if you won't enforce acting like that traffic too. > > > The tunnel head does not introduce traffic independent of the >> originating application. >> > > The Internet ****neither knows nor cares****. > > To the Internet, the head-end is the source. Whatever data the head end > puts inside the UDP packets *is application data* to the rest of the > Internet. > > Again, if you are saying that you know so much about the originating > source that you know you don't need additional mechanism at the headend, > say so - but then live by that requirement. > > If *any* MPLS traffic could show up at the headend, then it becomes the > headend's responsibility to do something. > > --- > > Consider the following case: > > - video shows up inside the OS, destined for the network > > - software X bundles that video and sends it to go out > > - software Y puts that data into UDP packets to go > to the Internet > > So what's the "application" here? To the Internet, it's software Y -- the > thing that puts the 'application' data into UDP packets. The previous steps > are irrelevant - just as irrelevant as the singer your video camera is > filming, as irrelevant as the sun that created the light that is reflected > off the singer to your camera. > > If software Y knows so much about the steps that lead to its input data > that it knows it's congestion reactive, nothing more need be done. > > If NOT (and that's the relevant corollary here), then it becomes software > Y's responsibility to put in some reactivity. > > Joe > --001a11c2fafe93fadf04f0ac2478 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't want to get in the way of vehement discussion,= but I thought we were on the verge of finding an actual solution...
IMHO, that was a combination of an applicability statement, us= ing SHOULD for congestion control and checksum, and defining a longer-term = OAM-based approach (as Stewart Bryant suggested) to be able to verify that = packet corruption or excessive drops aren't happening.

Does that sound like an acceptable set?

<= /div>
Alia


On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch &= lt;touch@isi.edu>= wrote:


On 1/23/2014 3:32 PM, Edward Crabbe wrote:
Joe, thanks for your response. Comments inline:


=A0 =A0 On 1/23/2014 1:27 PM, Edward Crabbe wrote:

=A0 =A0 =A0 =A0 Part of the point of using UDP is to make use of lowest com= mon
=A0 =A0 =A0 =A0 denominator forwarding hardware in introducing entropy to =A0 =A0 =A0 =A0 protocols that
=A0 =A0 =A0 =A0 lack it ( this is particularly true of the GRE in UDP use c= ase also
=A0 =A0 =A0 =A0 under discussion elsewhere).

=A0 =A0 =A0 =A0 The tunnel is not the source of the traffic. =A0The _source= of the
=A0 =A0 =A0 =A0 traffic_ is the source of the traffic.


=A0 =A0 To the Internet, the tunnel encapusulator is the source of traffic.=
=A0 =A0 Tracing the data back further than that is a mirage at best - and =A0 =A0 irrelevant.


The 'internet' cares about characteristics of reactivity to congest= ion.
=A0 This is guaranteed by the /source of the traffic/ independent of any intermediate node.

Are you prepared to make that a requirement of this document, i.e., that th= e only MPLS traffic that can be UDP encapsulated is known to react to conge= stion?

How exactly can you know that?


=A0 =A0 The tunnel head-end is responsible for the tunnel walking, talking,=
=A0 =A0 and quaking like a duck (host). When the tunnel head-end knows
=A0 =A0 something about the ultimate origin of the traffic - whether real,<= br> =A0 =A0 imagined, or from Asgard - then it has done it's duty (e.g., th= at
=A0 =A0 it's already congestion controlled).

=A0 =A0 But that head end is responsible, regardless of what it knows or =A0 =A0 doesn't. And when it doesn't know, the only way to be respo= nsible is
=A0 =A0 to put in its own reactivity.

This is not fact; it's actually precisely the principle =A0we're cu= rrently
arguing about. =A0;)

Actually, it's a paraphrasing of Section 3.1.3 of RFC5405.

We can continue to debate it, but until it's been *changed* by a revisi= on, it remains BCP.


I would posit:

The tunnel doesn't have to know anything about congestion or performanc= e
characteristics because the originating application must.

That works only if you know that fact about the originating application. Ho= wever, there are plenty of applications whose traffic goes over MPLS that i= sn't congestion reactive or bandwidth-limited.


> See GRE,
MPLS, many other tunnel types,

This isn't an issue for all tunnels until they enter the Internet...

including several existing within the
IETF that make use of an outer UDP header.

Which are all already supposed to follow the recommendations of RFC5405. To= the extent that they don't, they don't agree with that BCP.

I'm not saying such things never can or will exist, but I don't thi= nk the IETF should be self-contradictory. We already agreed as a group on s= uch BCPs and other standards, and new standards-track docs need to follow t= hem.


=A0 =A0 =A0 =A0 The originating application
=A0 =A0 =A0 =A0 who's traffic is being tunneled should be responsible f= or congestion
=A0 =A0 =A0 =A0 control, or lack there of.

=A0 =A0 Perhaps it should be, but that's an agreement between whomever<= br> =A0 =A0 implements/deploys the tunnel headend and whomever provides the
=A0 =A0 originating traffic to them. The problem is that this isn't tru= e for
=A0 =A0 the typical use case for this kind of encapsulation.

How so? =A0As mentioned before, this is the same case as standard GRE/MPLS<= br> etc.

It's putting MPLS inside UDP. That's a different case, and the reas= on RFC5405 applies.


=A0 =A0 I.e., if we were talking about MPLS traffic that already was
=A0 =A0 reactive, we wouldn't be claiming the need for additional
=A0 =A0 encapsulator mechanism. It's precisely because nothing is known=
=A0 =A0 about the MPLS traffic that the encapsulator needs to act.

The MPLS traffic doesn't have to be reactive, it's the applications=
being encapsulated / traversing a particular tunnel that are responsible for and aware of path and congestion charateristics. =A0Because the MPLS head end knows nothing about the /end to end application 'session'/=
characteristics it /shouldn't/ have anything to do with congestion
management.

OK, so what you're saying is that "traffic using this encapsulatio= n MUST be known to be congestion reactive". Put that in the doc and we= 'll debate whether we believe it.

But right now you're basically saying that because you think it's s= omeone else's problem (the originating application), it isn't yours= . The difficulty with that logic is that you (the tunnel headend) is respon= sible to ensure that this is true - either by *knowing* that the originatin= g traffic is congestion reactive, or by putting in its own mechanism to ens= ure that this happens if the originating application isn't.


=A0 =A0 =A0> Are we advocating a return to intermediate

=A0 =A0 =A0 =A0 congestion control (I like X.25 as much as the next guy, =A0 =A0 =A0 =A0 but...). =A0This
=A0 =A0 =A0 =A0 is a very stark change of direction.

=A0 =A0 =A0 =A0 I think mandating congestion control =A0is not technically = sound from
=A0 =A0 =A0 =A0 either a theoretical (violation of end to end principle, st= acking of
=A0 =A0 =A0 =A0 congestion control algorithms leading to complex and potent= ially
=A0 =A0 =A0 =A0 suboptimal results) or economic perspective (as a very larg= e
=A0 =A0 =A0 =A0 backbone,
=A0 =A0 =A0 =A0 we've been doing just fine without intermediate congest= ion
=A0 =A0 =A0 =A0 management
=A0 =A0 =A0 =A0 thank you very much, and I have 0 desire to pay for a cost<= br> =A0 =A0 =A0 =A0 prohibitive,
=A0 =A0 =A0 =A0 unnecessary feature in silicon.)

=A0 =A0 Write that up, and we'll see how it turns out in the IETF. Howe= ver,
=A0 =A0 right now, the IETF BCPs do require reactive congestion management<= br> =A0 =A0 of transport streams.

Which part? =A0The end-to-end principle, or the aversion to congestion
control stacking? =A0These have been implicit in all tunneling protocols produced by the IETF for the modern internet.

Sure, and that's reflected in RFC5405 already. However, please, PLEASE = appreciate that NOBODY here is asking you to put in "congestion contro= l stacking"; that happens when you run two dynamic, reactive control a= lgorithms using the same timescale on top of each other.

Equally well-known in CC circles is that you CAN - and often *should* - sta= ck different kinds of mechanisms at different layers with different timesca= les. E.g., that's why we have an AQM WG - because even when all the tra= ffic is TCP, that's not quite enough inside the network. That's als= o why Lars was suggesting something coarse on a longer timescale - a circui= t breaker - rather than AIMD on a RTT basis.

Keep in mind as well that the E2E argument says that you can't get an E= 2E service by composing the equivalent HBH one; it also says that HBH mecha= nisms can be required for efficiency. That's what we're talking abo= ut here - the efficiency impact of congestion, not the overall correctness = of E2E control.


=A0 =A0 If you don't want/like that, then either don't use transpor= t
=A0 =A0 encapsulation, or change the BCPs.

These BCPs are defined for an originating /application/.

Yes, and I don't understand why you (and others) keep thinking it matte= rs that there are layers of things behind the tunnel head end. It doesn'= ;t - unless you KNOW what those layers are, and can ensure that they behave= as you expect.


In this case
the UDP header is simply a shim header applied to existing application
traffic.

It's not "simply a shim" - if that's the case, use IP and= we're done. No need for congestion control.

The reason congestion issues arise is because you're inserting a header= ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO REACT TO****.
If you put in a UDP-like header that nobody in the Internet would interpret= , this wouldn't be an issue.

But you simply cannot expect the Internet to treat you like "applicati= on" traffic if you won't enforce acting like that traffic too.

The tunnel head does not introduce traffic independent of the
originating application.

The Internet ****neither knows nor cares****.

To the Internet, the head-end is the source. Whatever data the head end put= s inside the UDP packets *is application data* to the rest of the Internet.=

Again, if you are saying that you know so much about the originating source= that you know you don't need additional mechanism at the headend, say = so - but then live by that requirement.

If *any* MPLS traffic could show up at the headend, then it becomes the hea= dend's responsibility to do something.

---

Consider the following case:

=A0 =A0 =A0 =A0 - video shows up inside the OS, destined for the network
=A0 =A0 =A0 =A0 - software X bundles that video and sends it to go out

=A0 =A0 =A0 =A0 - software Y puts that data into UDP packets to go
=A0 =A0 =A0 =A0 to the Internet

So what's the "application" here? To the Internet, it's s= oftware Y -- the thing that puts the 'application' data into UDP pa= ckets. The previous steps are irrelevant - just as irrelevant as the singer= your video camera is filming, as irrelevant as the sun that created the li= ght that is reflected off the singer to your camera.

If software Y knows so much about the steps that lead to its input data tha= t it knows it's congestion reactive, nothing more need be done.

If NOT (and that's the relevant corollary here), then it becomes softwa= re Y's responsibility to put in some reactivity.=

Joe

--001a11c2fafe93fadf04f0ac2478-- From edc@google.com Thu Jan 23 16:09:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80F31A049D for ; Thu, 23 Jan 2014 16:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhkrOblxPJlE for ; Thu, 23 Jan 2014 16:09:06 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E78FE1A0499 for ; Thu, 23 Jan 2014 16:09:05 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id y10so2259121wgg.34 for ; Thu, 23 Jan 2014 16:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jI6V2xlZ2oaxIW6hKnc+9sUSJ1S3GLJ13RLK+iDfNV8=; b=SmZm1kJL16ST0la54OuW/vEj1c2y15+A/letuk2MUsAUXEFJqwsBG/8KvAZk6mMkbw pbbR7MvNIwImZ8ZOt7OjKMvxzcMWq9VTOLk8mEVJ0AqJsrux+l/7nlMaAUSSOvAuZnPx RcCSGfuOIIl/O35xQXTC79ZRvbEeJtSG0VYGRleqSn1V7zvfghGp1uSbpubmEVOFTf8j fYSfLKtXjJTU2+RfgXI4cDu8cQqf0WHDdBlc8+uEsrLWA9UxyKr81/yuFCyDVUApCbgy 4MSp/MCHjkwDd5H6K5hyNT8YI/BdMjHG2oghNSkSPPW6wzi5eysGmk5wrYzdKHhHDHEW sR+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jI6V2xlZ2oaxIW6hKnc+9sUSJ1S3GLJ13RLK+iDfNV8=; b=iMsrdsCvUTeNYrFzZXsO4AhRXyPGqDd230mf47TEo9c+q7JlLIpr1PKQ2u194DQOdg x6dlzWWvSL+Es4NxLrUl07G/oP/wP8FPGuYt2m7jVEWsGm3oFHoiveSwWCm3z6WnwINc +N4/6wXxwBs0QL387mzSJ0nW24lzyS+cCLmJvLHboQrMnDxf4aDwov6KDsONWA7XCqME XJiuIGdZyeWGkieGDbxDh4ivAtNseDYsQeNI+bPp58gyMXS06t8KDK/zdf/1d8j1N5H6 WwvdGS0q84Bgu2t0q08Et5lEmhr/S9kyI8Z6H/mI0i+W21r/Qso25kp587RraCW2T+X4 hETA== X-Gm-Message-State: ALoCoQlDorA5MpZkF77do51tbIXQM5/zuJR6FVomlAFlVYWkdvXuZq+ZeF2KDx2FnqwCtvNLSTCBJEkqBlVYRGZX7ka0NEDOjKKPSYc/dwKFN7ERdLm0cE0RDsPST3f651KWBf45pRq1iguecgB7K+uP0VEUVTZ73bC9lX8jThQxH9M04kA9ZirY1bba6ojAUG93pAIz/xM8 X-Received: by 10.180.93.169 with SMTP id cv9mr1093140wib.3.1390522144277; Thu, 23 Jan 2014 16:09:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Thu, 23 Jan 2014 16:08:24 -0800 (PST) In-Reply-To: References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> <52E1AC3E.2040204@isi.edu> From: Edward Crabbe Date: Thu, 23 Jan 2014 16:08:24 -0800 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=f46d043c7fc0769e9404f0ac2aea Cc: "mpls@ietf.org" , IETF discussion list , Noel Chiappa , Joe Touch Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:09:09 -0000 --f46d043c7fc0769e9404f0ac2aea Content-Type: text/plain; charset=ISO-8859-1 I think there also needs to be a network boundary statement with recommendations for filtering and usage in terms of intra vs interdomain protocol usage. On Thu, Jan 23, 2014 at 4:07 PM, Alia Atlas wrote: > I don't want to get in the way of vehement discussion, but I thought we > were on the verge of finding an actual solution... > > IMHO, that was a combination of an applicability statement, using SHOULD > for congestion control and checksum, and defining a longer-term OAM-based > approach (as Stewart Bryant suggested) to be able to verify that packet > corruption or excessive drops aren't happening. > > Does that sound like an acceptable set? > > Alia > > > On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch wrote: > >> >> >> On 1/23/2014 3:32 PM, Edward Crabbe wrote: >> >>> Joe, thanks for your response. Comments inline: >>> >>> >>> On 1/23/2014 1:27 PM, Edward Crabbe wrote: >>> >>> Part of the point of using UDP is to make use of lowest common >>> denominator forwarding hardware in introducing entropy to >>> protocols that >>> lack it ( this is particularly true of the GRE in UDP use case >>> also >>> under discussion elsewhere). >>> >>> The tunnel is not the source of the traffic. The _source of the >>> traffic_ is the source of the traffic. >>> >>> >>> To the Internet, the tunnel encapusulator is the source of traffic. >>> Tracing the data back further than that is a mirage at best - and >>> irrelevant. >>> >>> >>> The 'internet' cares about characteristics of reactivity to congestion. >>> This is guaranteed by the /source of the traffic/ independent of any >>> intermediate node. >>> >> >> Are you prepared to make that a requirement of this document, i.e., that >> the only MPLS traffic that can be UDP encapsulated is known to react to >> congestion? >> >> How exactly can you know that? >> >> >> The tunnel head-end is responsible for the tunnel walking, talking, >>> and quaking like a duck (host). When the tunnel head-end knows >>> something about the ultimate origin of the traffic - whether real, >>> imagined, or from Asgard - then it has done it's duty (e.g., that >>> it's already congestion controlled). >>> >>> But that head end is responsible, regardless of what it knows or >>> doesn't. And when it doesn't know, the only way to be responsible is >>> to put in its own reactivity. >>> >>> This is not fact; it's actually precisely the principle we're currently >>> arguing about. ;) >>> >> >> Actually, it's a paraphrasing of Section 3.1.3 of RFC5405. >> >> We can continue to debate it, but until it's been *changed* by a >> revision, it remains BCP. >> >> >> I would posit: >>> >>> The tunnel doesn't have to know anything about congestion or performance >>> characteristics because the originating application must. >>> >> >> That works only if you know that fact about the originating application. >> However, there are plenty of applications whose traffic goes over MPLS that >> isn't congestion reactive or bandwidth-limited. >> >> >> > See GRE, >> >>> MPLS, many other tunnel types, >>> >> >> This isn't an issue for all tunnels until they enter the Internet... >> >> >> including several existing within the >>> IETF that make use of an outer UDP header. >>> >> >> Which are all already supposed to follow the recommendations of RFC5405. >> To the extent that they don't, they don't agree with that BCP. >> >> I'm not saying such things never can or will exist, but I don't think the >> IETF should be self-contradictory. We already agreed as a group on such >> BCPs and other standards, and new standards-track docs need to follow them. >> >> >> The originating application >>> who's traffic is being tunneled should be responsible for >>> congestion >>> control, or lack there of. >>> >>> Perhaps it should be, but that's an agreement between whomever >>> implements/deploys the tunnel headend and whomever provides the >>> originating traffic to them. The problem is that this isn't true for >>> the typical use case for this kind of encapsulation. >>> >>> How so? As mentioned before, this is the same case as standard GRE/MPLS >>> etc. >>> >> >> It's putting MPLS inside UDP. That's a different case, and the reason >> RFC5405 applies. >> >> >> I.e., if we were talking about MPLS traffic that already was >>> reactive, we wouldn't be claiming the need for additional >>> encapsulator mechanism. It's precisely because nothing is known >>> about the MPLS traffic that the encapsulator needs to act. >>> >>> The MPLS traffic doesn't have to be reactive, it's the applications >>> being encapsulated / traversing a particular tunnel that are responsible >>> for and aware of path and congestion charateristics. Because the MPLS >>> head end knows nothing about the /end to end application 'session'/ >>> characteristics it /shouldn't/ have anything to do with congestion >>> management. >>> >> >> OK, so what you're saying is that "traffic using this encapsulation MUST >> be known to be congestion reactive". Put that in the doc and we'll debate >> whether we believe it. >> >> But right now you're basically saying that because you think it's someone >> else's problem (the originating application), it isn't yours. The >> difficulty with that logic is that you (the tunnel headend) is responsible >> to ensure that this is true - either by *knowing* that the originating >> traffic is congestion reactive, or by putting in its own mechanism to >> ensure that this happens if the originating application isn't. >> >> >> > Are we advocating a return to intermediate >>> >>> congestion control (I like X.25 as much as the next guy, >>> but...). This >>> is a very stark change of direction. >>> >>> I think mandating congestion control is not technically sound >>> from >>> either a theoretical (violation of end to end principle, >>> stacking of >>> congestion control algorithms leading to complex and potentially >>> suboptimal results) or economic perspective (as a very large >>> backbone, >>> we've been doing just fine without intermediate congestion >>> management >>> thank you very much, and I have 0 desire to pay for a cost >>> prohibitive, >>> unnecessary feature in silicon.) >>> >>> Write that up, and we'll see how it turns out in the IETF. However, >>> right now, the IETF BCPs do require reactive congestion management >>> of transport streams. >>> >>> Which part? The end-to-end principle, or the aversion to congestion >>> control stacking? These have been implicit in all tunneling protocols >>> produced by the IETF for the modern internet. >>> >> >> Sure, and that's reflected in RFC5405 already. However, please, PLEASE >> appreciate that NOBODY here is asking you to put in "congestion control >> stacking"; that happens when you run two dynamic, reactive control >> algorithms using the same timescale on top of each other. >> >> Equally well-known in CC circles is that you CAN - and often *should* - >> stack different kinds of mechanisms at different layers with different >> timescales. E.g., that's why we have an AQM WG - because even when all the >> traffic is TCP, that's not quite enough inside the network. That's also why >> Lars was suggesting something coarse on a longer timescale - a circuit >> breaker - rather than AIMD on a RTT basis. >> >> Keep in mind as well that the E2E argument says that you can't get an E2E >> service by composing the equivalent HBH one; it also says that HBH >> mechanisms can be required for efficiency. That's what we're talking about >> here - the efficiency impact of congestion, not the overall correctness of >> E2E control. >> >> >> If you don't want/like that, then either don't use transport >>> encapsulation, or change the BCPs. >>> >>> These BCPs are defined for an originating /application/. >>> >> >> Yes, and I don't understand why you (and others) keep thinking it matters >> that there are layers of things behind the tunnel head end. It doesn't - >> unless you KNOW what those layers are, and can ensure that they behave as >> you expect. >> >> >> In this case >>> the UDP header is simply a shim header applied to existing application >>> traffic. >>> >> >> It's not "simply a shim" - if that's the case, use IP and we're done. No >> need for congestion control. >> >> The reason congestion issues arise is because you're inserting a header >> ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO REACT TO****. >> >> If you put in a UDP-like header that nobody in the Internet would >> interpret, this wouldn't be an issue. >> >> But you simply cannot expect the Internet to treat you like "application" >> traffic if you won't enforce acting like that traffic too. >> >> >> The tunnel head does not introduce traffic independent of the >>> originating application. >>> >> >> The Internet ****neither knows nor cares****. >> >> To the Internet, the head-end is the source. Whatever data the head end >> puts inside the UDP packets *is application data* to the rest of the >> Internet. >> >> Again, if you are saying that you know so much about the originating >> source that you know you don't need additional mechanism at the headend, >> say so - but then live by that requirement. >> >> If *any* MPLS traffic could show up at the headend, then it becomes the >> headend's responsibility to do something. >> >> --- >> >> Consider the following case: >> >> - video shows up inside the OS, destined for the network >> >> - software X bundles that video and sends it to go out >> >> - software Y puts that data into UDP packets to go >> to the Internet >> >> So what's the "application" here? To the Internet, it's software Y -- the >> thing that puts the 'application' data into UDP packets. The previous steps >> are irrelevant - just as irrelevant as the singer your video camera is >> filming, as irrelevant as the sun that created the light that is reflected >> off the singer to your camera. >> >> If software Y knows so much about the steps that lead to its input data >> that it knows it's congestion reactive, nothing more need be done. >> >> If NOT (and that's the relevant corollary here), then it becomes software >> Y's responsibility to put in some reactivity. >> >> Joe >> > > --f46d043c7fc0769e9404f0ac2aea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think there also needs to be a network boundary statemen= t with recommendations for filtering and usage in terms of intra vs interdo= main protocol usage.=A0


On Thu, Jan 23, 2014 at 4:07 PM, Alia Atlas <akatlas@gmail.com> wrote:
I don't want to get in the way of vehement discussion,= but I thought we were on the verge of finding an actual solution...
IMHO, that was a combination of an applicability statement, us= ing SHOULD for congestion control and checksum, and defining a longer-term = OAM-based approach (as Stewart Bryant suggested) to be able to verify that = packet corruption or excessive drops aren't happening.

Does that sound like an acceptable set?

Alia
<= /span>


On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch <= span dir=3D"ltr"><tou= ch@isi.edu> wrote:


On 1/23/2014 3:32 PM, Edward Crabbe wrote:
Joe, thanks for your response. Comments inline:


=A0 =A0 On 1/23/2014 1:27 PM, Edward Crabbe wrote:

=A0 =A0 =A0 =A0 Part of the point of using UDP is to make use of lowest com= mon
=A0 =A0 =A0 =A0 denominator forwarding hardware in introducing entropy to =A0 =A0 =A0 =A0 protocols that
=A0 =A0 =A0 =A0 lack it ( this is particularly true of the GRE in UDP use c= ase also
=A0 =A0 =A0 =A0 under discussion elsewhere).

=A0 =A0 =A0 =A0 The tunnel is not the source of the traffic. =A0The _source= of the
=A0 =A0 =A0 =A0 traffic_ is the source of the traffic.


=A0 =A0 To the Internet, the tunnel encapusulator is the source of traffic.=
=A0 =A0 Tracing the data back further than that is a mirage at best - and =A0 =A0 irrelevant.


The 'internet' cares about characteristics of reactivity to congest= ion.
=A0 This is guaranteed by the /source of the traffic/ independent of any intermediate node.

Are you prepared to make that a requirement of this document, i.e., that th= e only MPLS traffic that can be UDP encapsulated is known to react to conge= stion?

How exactly can you know that?


=A0 =A0 The tunnel head-end is responsible for the tunnel walking, talking,=
=A0 =A0 and quaking like a duck (host). When the tunnel head-end knows
=A0 =A0 something about the ultimate origin of the traffic - whether real,<= br> =A0 =A0 imagined, or from Asgard - then it has done it's duty (e.g., th= at
=A0 =A0 it's already congestion controlled).

=A0 =A0 But that head end is responsible, regardless of what it knows or =A0 =A0 doesn't. And when it doesn't know, the only way to be respo= nsible is
=A0 =A0 to put in its own reactivity.

This is not fact; it's actually precisely the principle =A0we're cu= rrently
arguing about. =A0;)

Actually, it's a paraphrasing of Section 3.1.3 of RFC5405.

We can continue to debate it, but until it's been *changed* by a revisi= on, it remains BCP.


I would posit:

The tunnel doesn't have to know anything about congestion or performanc= e
characteristics because the originating application must.

That works only if you know that fact about the originating application. Ho= wever, there are plenty of applications whose traffic goes over MPLS that i= sn't congestion reactive or bandwidth-limited.


> See GRE,
MPLS, many other tunnel types,

This isn't an issue for all tunnels until they enter the Internet...

including several existing within the
IETF that make use of an outer UDP header.

Which are all already supposed to follow the recommendations of RFC5405. To= the extent that they don't, they don't agree with that BCP.

I'm not saying such things never can or will exist, but I don't thi= nk the IETF should be self-contradictory. We already agreed as a group on s= uch BCPs and other standards, and new standards-track docs need to follow t= hem.


=A0 =A0 =A0 =A0 The originating application
=A0 =A0 =A0 =A0 who's traffic is being tunneled should be responsible f= or congestion
=A0 =A0 =A0 =A0 control, or lack there of.

=A0 =A0 Perhaps it should be, but that's an agreement between whomever<= br> =A0 =A0 implements/deploys the tunnel headend and whomever provides the
=A0 =A0 originating traffic to them. The problem is that this isn't tru= e for
=A0 =A0 the typical use case for this kind of encapsulation.

How so? =A0As mentioned before, this is the same case as standard GRE/MPLS<= br> etc.

It's putting MPLS inside UDP. That's a different case, and the reas= on RFC5405 applies.


=A0 =A0 I.e., if we were talking about MPLS traffic that already was
=A0 =A0 reactive, we wouldn't be claiming the need for additional
=A0 =A0 encapsulator mechanism. It's precisely because nothing is known=
=A0 =A0 about the MPLS traffic that the encapsulator needs to act.

The MPLS traffic doesn't have to be reactive, it's the applications=
being encapsulated / traversing a particular tunnel that are responsible for and aware of path and congestion charateristics. =A0Because the MPLS head end knows nothing about the /end to end application 'session'/=
characteristics it /shouldn't/ have anything to do with congestion
management.

OK, so what you're saying is that "traffic using this encapsulatio= n MUST be known to be congestion reactive". Put that in the doc and we= 'll debate whether we believe it.

But right now you're basically saying that because you think it's s= omeone else's problem (the originating application), it isn't yours= . The difficulty with that logic is that you (the tunnel headend) is respon= sible to ensure that this is true - either by *knowing* that the originatin= g traffic is congestion reactive, or by putting in its own mechanism to ens= ure that this happens if the originating application isn't.


=A0 =A0 =A0> Are we advocating a return to intermediate

=A0 =A0 =A0 =A0 congestion control (I like X.25 as much as the next guy, =A0 =A0 =A0 =A0 but...). =A0This
=A0 =A0 =A0 =A0 is a very stark change of direction.

=A0 =A0 =A0 =A0 I think mandating congestion control =A0is not technically = sound from
=A0 =A0 =A0 =A0 either a theoretical (violation of end to end principle, st= acking of
=A0 =A0 =A0 =A0 congestion control algorithms leading to complex and potent= ially
=A0 =A0 =A0 =A0 suboptimal results) or economic perspective (as a very larg= e
=A0 =A0 =A0 =A0 backbone,
=A0 =A0 =A0 =A0 we've been doing just fine without intermediate congest= ion
=A0 =A0 =A0 =A0 management
=A0 =A0 =A0 =A0 thank you very much, and I have 0 desire to pay for a cost<= br> =A0 =A0 =A0 =A0 prohibitive,
=A0 =A0 =A0 =A0 unnecessary feature in silicon.)

=A0 =A0 Write that up, and we'll see how it turns out in the IETF. Howe= ver,
=A0 =A0 right now, the IETF BCPs do require reactive congestion management<= br> =A0 =A0 of transport streams.

Which part? =A0The end-to-end principle, or the aversion to congestion
control stacking? =A0These have been implicit in all tunneling protocols produced by the IETF for the modern internet.

Sure, and that's reflected in RFC5405 already. However, please, PLEASE = appreciate that NOBODY here is asking you to put in "congestion contro= l stacking"; that happens when you run two dynamic, reactive control a= lgorithms using the same timescale on top of each other.

Equally well-known in CC circles is that you CAN - and often *should* - sta= ck different kinds of mechanisms at different layers with different timesca= les. E.g., that's why we have an AQM WG - because even when all the tra= ffic is TCP, that's not quite enough inside the network. That's als= o why Lars was suggesting something coarse on a longer timescale - a circui= t breaker - rather than AIMD on a RTT basis.

Keep in mind as well that the E2E argument says that you can't get an E= 2E service by composing the equivalent HBH one; it also says that HBH mecha= nisms can be required for efficiency. That's what we're talking abo= ut here - the efficiency impact of congestion, not the overall correctness = of E2E control.


=A0 =A0 If you don't want/like that, then either don't use transpor= t
=A0 =A0 encapsulation, or change the BCPs.

These BCPs are defined for an originating /application/.

Yes, and I don't understand why you (and others) keep thinking it matte= rs that there are layers of things behind the tunnel head end. It doesn'= ;t - unless you KNOW what those layers are, and can ensure that they behave= as you expect.


In this case
the UDP header is simply a shim header applied to existing application
traffic.

It's not "simply a shim" - if that's the case, use IP and= we're done. No need for congestion control.

The reason congestion issues arise is because you're inserting a header= ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO REACT TO****.
If you put in a UDP-like header that nobody in the Internet would interpret= , this wouldn't be an issue.

But you simply cannot expect the Internet to treat you like "applicati= on" traffic if you won't enforce acting like that traffic too.

The tunnel head does not introduce traffic independent of the
originating application.

The Internet ****neither knows nor cares****.

To the Internet, the head-end is the source. Whatever data the head end put= s inside the UDP packets *is application data* to the rest of the Internet.=

Again, if you are saying that you know so much about the originating source= that you know you don't need additional mechanism at the headend, say = so - but then live by that requirement.

If *any* MPLS traffic could show up at the headend, then it becomes the hea= dend's responsibility to do something.

---

Consider the following case:

=A0 =A0 =A0 =A0 - video shows up inside the OS, destined for the network
=A0 =A0 =A0 =A0 - software X bundles that video and sends it to go out

=A0 =A0 =A0 =A0 - software Y puts that data into UDP packets to go
=A0 =A0 =A0 =A0 to the Internet

So what's the "application" here? To the Internet, it's s= oftware Y -- the thing that puts the 'application' data into UDP pa= ckets. The previous steps are irrelevant - just as irrelevant as the singer= your video camera is filming, as irrelevant as the sun that created the li= ght that is reflected off the singer to your camera.

If software Y knows so much about the steps that lead to its input data tha= t it knows it's congestion reactive, nothing more need be done.

If NOT (and that's the relevant corollary here), then it becomes softwa= re Y's responsibility to put in some reactivity.

Joe


--f46d043c7fc0769e9404f0ac2aea-- From touch@isi.edu Thu Jan 23 16:11:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E686F1A01A0; Thu, 23 Jan 2014 16:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 JBHE9UvscKsG; Thu, 23 Jan 2014 16:11:08 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 550791A00AA; Thu, 23 Jan 2014 16:11:08 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0O0AM3o006909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jan 2014 16:10:22 -0800 (PST) Message-ID: <52E1AF6E.1000108@isi.edu> Date: Thu, 23 Jan 2014 16:10:22 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alia Atlas References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> <52E1AC3E.2040204@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:11:13 -0000 Hi, Alia, On 1/23/2014 4:07 PM, Alia Atlas wrote: > I don't want to get in the way of vehement discussion, but I thought we > were on the verge of finding an actual solution... > > IMHO, that was a combination of an applicability statement, using SHOULD > for congestion control and checksum, and defining a longer-term > OAM-based approach (as Stewart Bryant suggested) to be able to verify > that packet corruption or excessive drops aren't happening. > > Does that sound like an acceptable set? It answers my concerns (I was concerned about the checksum issue too, though it seems to have petered out). I wasn't tracking whether there were other issues that this doesn't address that were raised, though. Joe > Alia > > > On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch > wrote: > > > > On 1/23/2014 3:32 PM, Edward Crabbe wrote: > > Joe, thanks for your response. Comments inline: > > > On 1/23/2014 1:27 PM, Edward Crabbe wrote: > > Part of the point of using UDP is to make use of lowest > common > denominator forwarding hardware in introducing entropy to > protocols that > lack it ( this is particularly true of the GRE in UDP > use case also > under discussion elsewhere). > > The tunnel is not the source of the traffic. The > _source of the > traffic_ is the source of the traffic. > > > To the Internet, the tunnel encapusulator is the source of > traffic. > Tracing the data back further than that is a mirage at best > - and > irrelevant. > > > The 'internet' cares about characteristics of reactivity to > congestion. > This is guaranteed by the /source of the traffic/ independent > of any > intermediate node. > > > Are you prepared to make that a requirement of this document, i.e., > that the only MPLS traffic that can be UDP encapsulated is known to > react to congestion? > > How exactly can you know that? > > > The tunnel head-end is responsible for the tunnel walking, > talking, > and quaking like a duck (host). When the tunnel head-end knows > something about the ultimate origin of the traffic - > whether real, > imagined, or from Asgard - then it has done it's duty > (e.g., that > it's already congestion controlled). > > But that head end is responsible, regardless of what it > knows or > doesn't. And when it doesn't know, the only way to be > responsible is > to put in its own reactivity. > > This is not fact; it's actually precisely the principle we're > currently > arguing about. ;) > > > Actually, it's a paraphrasing of Section 3.1.3 of RFC5405. > > We can continue to debate it, but until it's been *changed* by a > revision, it remains BCP. > > > I would posit: > > The tunnel doesn't have to know anything about congestion or > performance > characteristics because the originating application must. > > > That works only if you know that fact about the originating > application. However, there are plenty of applications whose traffic > goes over MPLS that isn't congestion reactive or bandwidth-limited. > > > > See GRE, > > MPLS, many other tunnel types, > > > This isn't an issue for all tunnels until they enter the Internet... > > > including several existing within the > IETF that make use of an outer UDP header. > > > Which are all already supposed to follow the recommendations of > RFC5405. To the extent that they don't, they don't agree with that BCP. > > I'm not saying such things never can or will exist, but I don't > think the IETF should be self-contradictory. We already agreed as a > group on such BCPs and other standards, and new standards-track docs > need to follow them. > > > The originating application > who's traffic is being tunneled should be responsible > for congestion > control, or lack there of. > > Perhaps it should be, but that's an agreement between whomever > implements/deploys the tunnel headend and whomever provides the > originating traffic to them. The problem is that this isn't > true for > the typical use case for this kind of encapsulation. > > How so? As mentioned before, this is the same case as standard > GRE/MPLS > etc. > > > It's putting MPLS inside UDP. That's a different case, and the > reason RFC5405 applies. > > > I.e., if we were talking about MPLS traffic that already was > reactive, we wouldn't be claiming the need for additional > encapsulator mechanism. It's precisely because nothing is known > about the MPLS traffic that the encapsulator needs to act. > > The MPLS traffic doesn't have to be reactive, it's the applications > being encapsulated / traversing a particular tunnel that are > responsible > for and aware of path and congestion charateristics. Because > the MPLS > head end knows nothing about the /end to end application 'session'/ > characteristics it /shouldn't/ have anything to do with congestion > management. > > > OK, so what you're saying is that "traffic using this encapsulation > MUST be known to be congestion reactive". Put that in the doc and > we'll debate whether we believe it. > > But right now you're basically saying that because you think it's > someone else's problem (the originating application), it isn't > yours. The difficulty with that logic is that you (the tunnel > headend) is responsible to ensure that this is true - either by > *knowing* that the originating traffic is congestion reactive, or by > putting in its own mechanism to ensure that this happens if the > originating application isn't. > > > > Are we advocating a return to intermediate > > congestion control (I like X.25 as much as the next guy, > but...). This > is a very stark change of direction. > > I think mandating congestion control is not > technically sound from > either a theoretical (violation of end to end > principle, stacking of > congestion control algorithms leading to complex and > potentially > suboptimal results) or economic perspective (as a very > large > backbone, > we've been doing just fine without intermediate congestion > management > thank you very much, and I have 0 desire to pay for a cost > prohibitive, > unnecessary feature in silicon.) > > Write that up, and we'll see how it turns out in the IETF. > However, > right now, the IETF BCPs do require reactive congestion > management > of transport streams. > > Which part? The end-to-end principle, or the aversion to congestion > control stacking? These have been implicit in all tunneling > protocols > produced by the IETF for the modern internet. > > > Sure, and that's reflected in RFC5405 already. However, please, > PLEASE appreciate that NOBODY here is asking you to put in > "congestion control stacking"; that happens when you run two > dynamic, reactive control algorithms using the same timescale on top > of each other. > > Equally well-known in CC circles is that you CAN - and often > *should* - stack different kinds of mechanisms at different layers > with different timescales. E.g., that's why we have an AQM WG - > because even when all the traffic is TCP, that's not quite enough > inside the network. That's also why Lars was suggesting something > coarse on a longer timescale - a circuit breaker - rather than AIMD > on a RTT basis. > > Keep in mind as well that the E2E argument says that you can't get > an E2E service by composing the equivalent HBH one; it also says > that HBH mechanisms can be required for efficiency. That's what > we're talking about here - the efficiency impact of congestion, not > the overall correctness of E2E control. > > > If you don't want/like that, then either don't use transport > encapsulation, or change the BCPs. > > These BCPs are defined for an originating /application/. > > > Yes, and I don't understand why you (and others) keep thinking it > matters that there are layers of things behind the tunnel head end. > It doesn't - unless you KNOW what those layers are, and can ensure > that they behave as you expect. > > > In this case > the UDP header is simply a shim header applied to existing > application > traffic. > > > It's not "simply a shim" - if that's the case, use IP and we're > done. No need for congestion control. > > The reason congestion issues arise is because you're inserting a > header ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO > REACT TO****. > > If you put in a UDP-like header that nobody in the Internet would > interpret, this wouldn't be an issue. > > But you simply cannot expect the Internet to treat you like > "application" traffic if you won't enforce acting like that traffic too. > > > The tunnel head does not introduce traffic independent of the > originating application. > > > The Internet ****neither knows nor cares****. > > To the Internet, the head-end is the source. Whatever data the head > end puts inside the UDP packets *is application data* to the rest of > the Internet. > > Again, if you are saying that you know so much about the originating > source that you know you don't need additional mechanism at the > headend, say so - but then live by that requirement. > > If *any* MPLS traffic could show up at the headend, then it becomes > the headend's responsibility to do something. > > --- > > Consider the following case: > > - video shows up inside the OS, destined for the network > > - software X bundles that video and sends it to go out > > - software Y puts that data into UDP packets to go > to the Internet > > So what's the "application" here? To the Internet, it's software Y > -- the thing that puts the 'application' data into UDP packets. The > previous steps are irrelevant - just as irrelevant as the singer > your video camera is filming, as irrelevant as the sun that created > the light that is reflected off the singer to your camera. > > If software Y knows so much about the steps that lead to its input > data that it knows it's congestion reactive, nothing more need be done. > > If NOT (and that's the relevant corollary here), then it becomes > software Y's responsibility to put in some reactivity. > > Joe > > From akatlas@gmail.com Thu Jan 23 16:22:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F4B1A01D3; Thu, 23 Jan 2014 16:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7ro5TIPVu4m; Thu, 23 Jan 2014 16:22:15 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2725A1A034B; Thu, 23 Jan 2014 16:22:15 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tp5so2090609ieb.35 for ; Thu, 23 Jan 2014 16:22:14 -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=rvOrBZR4e7WAEY2PHiW87cbKpP9iWrgkYKW6V4SEptU=; b=ziLIscQNwneUbehpL2DqVfP+jLhgsiCAhjTE+TzXDJCO29NZhhQe+apfGvseMcx7h8 98iSSO1yEew3BZ3MmM7dZsAPb7FSncEoLafJxsE40F6368x7e4UtB/xKpWk8hIhHkTCv nDRdlbHABLC/EbooIrT6w3Pg9dt5Du7MKPF40JKQqbRGqYR4eUpzBtEgjcm1Aqxgw8fF n4viAlQs6aBBEOZDzE+qv+9C9KarrDgVssUd8IyaCVi7+MEbEmG+juXWNTzGa8n2DVjP NY1JKgENEGMOD/cfZLutvtUNl/YMF6TYldsEkUse6u8QDsxNQVAs5vdS1QPz3VRfecFZ gm9g== MIME-Version: 1.0 X-Received: by 10.50.43.134 with SMTP id w6mr2063144igl.20.1390522934092; Thu, 23 Jan 2014 16:22:14 -0800 (PST) Received: by 10.64.72.132 with HTTP; Thu, 23 Jan 2014 16:22:13 -0800 (PST) In-Reply-To: References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> <52E1AC3E.2040204@isi.edu> Date: Thu, 23 Jan 2014 19:22:13 -0500 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: multipart/alternative; boundary=089e01184b0c89e95004f0ac59ce Cc: "mpls@ietf.org" , IETF discussion list , Noel Chiappa , Joe Touch Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:22:18 -0000 --089e01184b0c89e95004f0ac59ce Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 23, 2014 at 7:08 PM, Edward Crabbe wrote: > I think there also needs to be a network boundary statement with > recommendations for filtering and usage in terms of intra vs interdomain > protocol usage. > Agreed - I think that's part of describing how the applicability statement can be enforced by a service provider. Alia > > > On Thu, Jan 23, 2014 at 4:07 PM, Alia Atlas wrote: > >> I don't want to get in the way of vehement discussion, but I thought we >> were on the verge of finding an actual solution... >> >> IMHO, that was a combination of an applicability statement, using SHOULD >> for congestion control and checksum, and defining a longer-term OAM-based >> approach (as Stewart Bryant suggested) to be able to verify that packet >> corruption or excessive drops aren't happening. >> >> Does that sound like an acceptable set? >> >> Alia >> >> >> On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch wrote: >> >>> >>> >>> On 1/23/2014 3:32 PM, Edward Crabbe wrote: >>> >>>> Joe, thanks for your response. Comments inline: >>>> >>>> >>>> On 1/23/2014 1:27 PM, Edward Crabbe wrote: >>>> >>>> Part of the point of using UDP is to make use of lowest common >>>> denominator forwarding hardware in introducing entropy to >>>> protocols that >>>> lack it ( this is particularly true of the GRE in UDP use case >>>> also >>>> under discussion elsewhere). >>>> >>>> The tunnel is not the source of the traffic. The _source of the >>>> traffic_ is the source of the traffic. >>>> >>>> >>>> To the Internet, the tunnel encapusulator is the source of traffic. >>>> Tracing the data back further than that is a mirage at best - and >>>> irrelevant. >>>> >>>> >>>> The 'internet' cares about characteristics of reactivity to congestion. >>>> This is guaranteed by the /source of the traffic/ independent of any >>>> intermediate node. >>>> >>> >>> Are you prepared to make that a requirement of this document, i.e., that >>> the only MPLS traffic that can be UDP encapsulated is known to react to >>> congestion? >>> >>> How exactly can you know that? >>> >>> >>> The tunnel head-end is responsible for the tunnel walking, talking, >>>> and quaking like a duck (host). When the tunnel head-end knows >>>> something about the ultimate origin of the traffic - whether real, >>>> imagined, or from Asgard - then it has done it's duty (e.g., that >>>> it's already congestion controlled). >>>> >>>> But that head end is responsible, regardless of what it knows or >>>> doesn't. And when it doesn't know, the only way to be responsible is >>>> to put in its own reactivity. >>>> >>>> This is not fact; it's actually precisely the principle we're currently >>>> arguing about. ;) >>>> >>> >>> Actually, it's a paraphrasing of Section 3.1.3 of RFC5405. >>> >>> We can continue to debate it, but until it's been *changed* by a >>> revision, it remains BCP. >>> >>> >>> I would posit: >>>> >>>> The tunnel doesn't have to know anything about congestion or performance >>>> characteristics because the originating application must. >>>> >>> >>> That works only if you know that fact about the originating application. >>> However, there are plenty of applications whose traffic goes over MPLS that >>> isn't congestion reactive or bandwidth-limited. >>> >>> >>> > See GRE, >>> >>>> MPLS, many other tunnel types, >>>> >>> >>> This isn't an issue for all tunnels until they enter the Internet... >>> >>> >>> including several existing within the >>>> IETF that make use of an outer UDP header. >>>> >>> >>> Which are all already supposed to follow the recommendations of RFC5405. >>> To the extent that they don't, they don't agree with that BCP. >>> >>> I'm not saying such things never can or will exist, but I don't think >>> the IETF should be self-contradictory. We already agreed as a group on such >>> BCPs and other standards, and new standards-track docs need to follow them. >>> >>> >>> The originating application >>>> who's traffic is being tunneled should be responsible for >>>> congestion >>>> control, or lack there of. >>>> >>>> Perhaps it should be, but that's an agreement between whomever >>>> implements/deploys the tunnel headend and whomever provides the >>>> originating traffic to them. The problem is that this isn't true for >>>> the typical use case for this kind of encapsulation. >>>> >>>> How so? As mentioned before, this is the same case as standard GRE/MPLS >>>> etc. >>>> >>> >>> It's putting MPLS inside UDP. That's a different case, and the reason >>> RFC5405 applies. >>> >>> >>> I.e., if we were talking about MPLS traffic that already was >>>> reactive, we wouldn't be claiming the need for additional >>>> encapsulator mechanism. It's precisely because nothing is known >>>> about the MPLS traffic that the encapsulator needs to act. >>>> >>>> The MPLS traffic doesn't have to be reactive, it's the applications >>>> being encapsulated / traversing a particular tunnel that are responsible >>>> for and aware of path and congestion charateristics. Because the MPLS >>>> head end knows nothing about the /end to end application 'session'/ >>>> characteristics it /shouldn't/ have anything to do with congestion >>>> management. >>>> >>> >>> OK, so what you're saying is that "traffic using this encapsulation MUST >>> be known to be congestion reactive". Put that in the doc and we'll debate >>> whether we believe it. >>> >>> But right now you're basically saying that because you think it's >>> someone else's problem (the originating application), it isn't yours. The >>> difficulty with that logic is that you (the tunnel headend) is responsible >>> to ensure that this is true - either by *knowing* that the originating >>> traffic is congestion reactive, or by putting in its own mechanism to >>> ensure that this happens if the originating application isn't. >>> >>> >>> > Are we advocating a return to intermediate >>>> >>>> congestion control (I like X.25 as much as the next guy, >>>> but...). This >>>> is a very stark change of direction. >>>> >>>> I think mandating congestion control is not technically sound >>>> from >>>> either a theoretical (violation of end to end principle, >>>> stacking of >>>> congestion control algorithms leading to complex and potentially >>>> suboptimal results) or economic perspective (as a very large >>>> backbone, >>>> we've been doing just fine without intermediate congestion >>>> management >>>> thank you very much, and I have 0 desire to pay for a cost >>>> prohibitive, >>>> unnecessary feature in silicon.) >>>> >>>> Write that up, and we'll see how it turns out in the IETF. However, >>>> right now, the IETF BCPs do require reactive congestion management >>>> of transport streams. >>>> >>>> Which part? The end-to-end principle, or the aversion to congestion >>>> control stacking? These have been implicit in all tunneling protocols >>>> produced by the IETF for the modern internet. >>>> >>> >>> Sure, and that's reflected in RFC5405 already. However, please, PLEASE >>> appreciate that NOBODY here is asking you to put in "congestion control >>> stacking"; that happens when you run two dynamic, reactive control >>> algorithms using the same timescale on top of each other. >>> >>> Equally well-known in CC circles is that you CAN - and often *should* - >>> stack different kinds of mechanisms at different layers with different >>> timescales. E.g., that's why we have an AQM WG - because even when all the >>> traffic is TCP, that's not quite enough inside the network. That's also why >>> Lars was suggesting something coarse on a longer timescale - a circuit >>> breaker - rather than AIMD on a RTT basis. >>> >>> Keep in mind as well that the E2E argument says that you can't get an >>> E2E service by composing the equivalent HBH one; it also says that HBH >>> mechanisms can be required for efficiency. That's what we're talking about >>> here - the efficiency impact of congestion, not the overall correctness of >>> E2E control. >>> >>> >>> If you don't want/like that, then either don't use transport >>>> encapsulation, or change the BCPs. >>>> >>>> These BCPs are defined for an originating /application/. >>>> >>> >>> Yes, and I don't understand why you (and others) keep thinking it >>> matters that there are layers of things behind the tunnel head end. It >>> doesn't - unless you KNOW what those layers are, and can ensure that they >>> behave as you expect. >>> >>> >>> In this case >>>> the UDP header is simply a shim header applied to existing application >>>> traffic. >>>> >>> >>> It's not "simply a shim" - if that's the case, use IP and we're done. No >>> need for congestion control. >>> >>> The reason congestion issues arise is because you're inserting a header >>> ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO REACT TO****. >>> >>> If you put in a UDP-like header that nobody in the Internet would >>> interpret, this wouldn't be an issue. >>> >>> But you simply cannot expect the Internet to treat you like >>> "application" traffic if you won't enforce acting like that traffic too. >>> >>> >>> The tunnel head does not introduce traffic independent of the >>>> originating application. >>>> >>> >>> The Internet ****neither knows nor cares****. >>> >>> To the Internet, the head-end is the source. Whatever data the head end >>> puts inside the UDP packets *is application data* to the rest of the >>> Internet. >>> >>> Again, if you are saying that you know so much about the originating >>> source that you know you don't need additional mechanism at the headend, >>> say so - but then live by that requirement. >>> >>> If *any* MPLS traffic could show up at the headend, then it becomes the >>> headend's responsibility to do something. >>> >>> --- >>> >>> Consider the following case: >>> >>> - video shows up inside the OS, destined for the network >>> >>> - software X bundles that video and sends it to go out >>> >>> - software Y puts that data into UDP packets to go >>> to the Internet >>> >>> So what's the "application" here? To the Internet, it's software Y -- >>> the thing that puts the 'application' data into UDP packets. The previous >>> steps are irrelevant - just as irrelevant as the singer your video camera >>> is filming, as irrelevant as the sun that created the light that is >>> reflected off the singer to your camera. >>> >>> If software Y knows so much about the steps that lead to its input data >>> that it knows it's congestion reactive, nothing more need be done. >>> >>> If NOT (and that's the relevant corollary here), then it becomes >>> software Y's responsibility to put in some reactivity. >>> >>> Joe >>> >> >> > --089e01184b0c89e95004f0ac59ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Jan 23, 2014 at 7:08 PM, Edward Crabbe <edc@google.com>= wrote:
I think there also needs to= be a network boundary statement with recommendations for filtering and usa= ge in terms of intra vs interdomain protocol usage.=A0

Agreed - I think that's part of descri= bing how the applicability statement can be enforced by a service provider.=

Alia
=A0


=
On Thu, Jan 23, 2014 at 4:07 PM, Alia Atlas <akatlas@gmail.com> wrote:
I don't want to get in the way of vehement discussion,= but I thought we were on the verge of finding an actual solution...
IMHO, that was a combination of an applicability statement, us= ing SHOULD for congestion control and checksum, and defining a longer-term = OAM-based approach (as Stewart Bryant suggested) to be able to verify that = packet corruption or excessive drops aren't happening.

Does that sound like an acceptable set?

Alia
=


On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch <= span dir=3D"ltr"><tou= ch@isi.edu> wrote:


On 1/23/2014 3:32 PM, Edward Crabbe wrote:
Joe, thanks for your response. Comments inline:


=A0 =A0 On 1/23/2014 1:27 PM, Edward Crabbe wrote:

=A0 =A0 =A0 =A0 Part of the point of using UDP is to make use of lowest com= mon
=A0 =A0 =A0 =A0 denominator forwarding hardware in introducing entropy to =A0 =A0 =A0 =A0 protocols that
=A0 =A0 =A0 =A0 lack it ( this is particularly true of the GRE in UDP use c= ase also
=A0 =A0 =A0 =A0 under discussion elsewhere).

=A0 =A0 =A0 =A0 The tunnel is not the source of the traffic. =A0The _source= of the
=A0 =A0 =A0 =A0 traffic_ is the source of the traffic.


=A0 =A0 To the Internet, the tunnel encapusulator is the source of traffic.=
=A0 =A0 Tracing the data back further than that is a mirage at best - and =A0 =A0 irrelevant.


The 'internet' cares about characteristics of reactivity to congest= ion.
=A0 This is guaranteed by the /source of the traffic/ independent of any intermediate node.

Are you prepared to make that a requirement of this document, i.e., that th= e only MPLS traffic that can be UDP encapsulated is known to react to conge= stion?

How exactly can you know that?


=A0 =A0 The tunnel head-end is responsible for the tunnel walking, talking,=
=A0 =A0 and quaking like a duck (host). When the tunnel head-end knows
=A0 =A0 something about the ultimate origin of the traffic - whether real,<= br> =A0 =A0 imagined, or from Asgard - then it has done it's duty (e.g., th= at
=A0 =A0 it's already congestion controlled).

=A0 =A0 But that head end is responsible, regardless of what it knows or =A0 =A0 doesn't. And when it doesn't know, the only way to be respo= nsible is
=A0 =A0 to put in its own reactivity.

This is not fact; it's actually precisely the principle =A0we're cu= rrently
arguing about. =A0;)

Actually, it's a paraphrasing of Section 3.1.3 of RFC5405.

We can continue to debate it, but until it's been *changed* by a revisi= on, it remains BCP.


I would posit:

The tunnel doesn't have to know anything about congestion or performanc= e
characteristics because the originating application must.

That works only if you know that fact about the originating application. Ho= wever, there are plenty of applications whose traffic goes over MPLS that i= sn't congestion reactive or bandwidth-limited.


> See GRE,
MPLS, many other tunnel types,

This isn't an issue for all tunnels until they enter the Internet...

including several existing within the
IETF that make use of an outer UDP header.

Which are all already supposed to follow the recommendations of RFC5405. To= the extent that they don't, they don't agree with that BCP.

I'm not saying such things never can or will exist, but I don't thi= nk the IETF should be self-contradictory. We already agreed as a group on s= uch BCPs and other standards, and new standards-track docs need to follow t= hem.


=A0 =A0 =A0 =A0 The originating application
=A0 =A0 =A0 =A0 who's traffic is being tunneled should be responsible f= or congestion
=A0 =A0 =A0 =A0 control, or lack there of.

=A0 =A0 Perhaps it should be, but that's an agreement between whomever<= br> =A0 =A0 implements/deploys the tunnel headend and whomever provides the
=A0 =A0 originating traffic to them. The problem is that this isn't tru= e for
=A0 =A0 the typical use case for this kind of encapsulation.

How so? =A0As mentioned before, this is the same case as standard GRE/MPLS<= br> etc.

It's putting MPLS inside UDP. That's a different case, and the reas= on RFC5405 applies.


=A0 =A0 I.e., if we were talking about MPLS traffic that already was
=A0 =A0 reactive, we wouldn't be claiming the need for additional
=A0 =A0 encapsulator mechanism. It's precisely because nothing is known=
=A0 =A0 about the MPLS traffic that the encapsulator needs to act.

The MPLS traffic doesn't have to be reactive, it's the applications=
being encapsulated / traversing a particular tunnel that are responsible for and aware of path and congestion charateristics. =A0Because the MPLS head end knows nothing about the /end to end application 'session'/=
characteristics it /shouldn't/ have anything to do with congestion
management.

OK, so what you're saying is that "traffic using this encapsulatio= n MUST be known to be congestion reactive". Put that in the doc and we= 'll debate whether we believe it.

But right now you're basically saying that because you think it's s= omeone else's problem (the originating application), it isn't yours= . The difficulty with that logic is that you (the tunnel headend) is respon= sible to ensure that this is true - either by *knowing* that the originatin= g traffic is congestion reactive, or by putting in its own mechanism to ens= ure that this happens if the originating application isn't.


=A0 =A0 =A0> Are we advocating a return to intermediate

=A0 =A0 =A0 =A0 congestion control (I like X.25 as much as the next guy, =A0 =A0 =A0 =A0 but...). =A0This
=A0 =A0 =A0 =A0 is a very stark change of direction.

=A0 =A0 =A0 =A0 I think mandating congestion control =A0is not technically = sound from
=A0 =A0 =A0 =A0 either a theoretical (violation of end to end principle, st= acking of
=A0 =A0 =A0 =A0 congestion control algorithms leading to complex and potent= ially
=A0 =A0 =A0 =A0 suboptimal results) or economic perspective (as a very larg= e
=A0 =A0 =A0 =A0 backbone,
=A0 =A0 =A0 =A0 we've been doing just fine without intermediate congest= ion
=A0 =A0 =A0 =A0 management
=A0 =A0 =A0 =A0 thank you very much, and I have 0 desire to pay for a cost<= br> =A0 =A0 =A0 =A0 prohibitive,
=A0 =A0 =A0 =A0 unnecessary feature in silicon.)

=A0 =A0 Write that up, and we'll see how it turns out in the IETF. Howe= ver,
=A0 =A0 right now, the IETF BCPs do require reactive congestion management<= br> =A0 =A0 of transport streams.

Which part? =A0The end-to-end principle, or the aversion to congestion
control stacking? =A0These have been implicit in all tunneling protocols produced by the IETF for the modern internet.

Sure, and that's reflected in RFC5405 already. However, please, PLEASE = appreciate that NOBODY here is asking you to put in "congestion contro= l stacking"; that happens when you run two dynamic, reactive control a= lgorithms using the same timescale on top of each other.

Equally well-known in CC circles is that you CAN - and often *should* - sta= ck different kinds of mechanisms at different layers with different timesca= les. E.g., that's why we have an AQM WG - because even when all the tra= ffic is TCP, that's not quite enough inside the network. That's als= o why Lars was suggesting something coarse on a longer timescale - a circui= t breaker - rather than AIMD on a RTT basis.

Keep in mind as well that the E2E argument says that you can't get an E= 2E service by composing the equivalent HBH one; it also says that HBH mecha= nisms can be required for efficiency. That's what we're talking abo= ut here - the efficiency impact of congestion, not the overall correctness = of E2E control.


=A0 =A0 If you don't want/like that, then either don't use transpor= t
=A0 =A0 encapsulation, or change the BCPs.

These BCPs are defined for an originating /application/.

Yes, and I don't understand why you (and others) keep thinking it matte= rs that there are layers of things behind the tunnel head end. It doesn'= ;t - unless you KNOW what those layers are, and can ensure that they behave= as you expect.


In this case
the UDP header is simply a shim header applied to existing application
traffic.

It's not "simply a shim" - if that's the case, use IP and= we're done. No need for congestion control.

The reason congestion issues arise is because you're inserting a header= ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO REACT TO****.
If you put in a UDP-like header that nobody in the Internet would interpret= , this wouldn't be an issue.

But you simply cannot expect the Internet to treat you like "applicati= on" traffic if you won't enforce acting like that traffic too.

The tunnel head does not introduce traffic independent of the
originating application.

The Internet ****neither knows nor cares****.

To the Internet, the head-end is the source. Whatever data the head end put= s inside the UDP packets *is application data* to the rest of the Internet.=

Again, if you are saying that you know so much about the originating source= that you know you don't need additional mechanism at the headend, say = so - but then live by that requirement.

If *any* MPLS traffic could show up at the headend, then it becomes the hea= dend's responsibility to do something.

---

Consider the following case:

=A0 =A0 =A0 =A0 - video shows up inside the OS, destined for the network
=A0 =A0 =A0 =A0 - software X bundles that video and sends it to go out

=A0 =A0 =A0 =A0 - software Y puts that data into UDP packets to go
=A0 =A0 =A0 =A0 to the Internet

So what's the "application" here? To the Internet, it's s= oftware Y -- the thing that puts the 'application' data into UDP pa= ckets. The previous steps are irrelevant - just as irrelevant as the singer= your video camera is filming, as irrelevant as the sun that created the li= ght that is reflected off the singer to your camera.

If software Y knows so much about the steps that lead to its input data tha= t it knows it's congestion reactive, nothing more need be done.

If NOT (and that's the relevant corollary here), then it becomes softwa= re Y's responsibility to put in some reactivity.

Joe



--089e01184b0c89e95004f0ac59ce-- From xuxiaohu@huawei.com Thu Jan 23 16:35:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35121A0491 for ; Thu, 23 Jan 2014 16:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 GOaInJXRun7h for ; Thu, 23 Jan 2014 16:35:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D3E361A0232 for ; Thu, 23 Jan 2014 16:35:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCW15088; Fri, 24 Jan 2014 00:35:00 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 00:34:54 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 00:34:59 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 08:34:53 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "Alexander.Vainshtein@ecitele.com" , "lars@netapp.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiOAAIGV4IAASynFgAB+v4A= Date: Fri, 24 Jan 2014 00:34:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082477E6@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg?= =?gb2312?b?dG8gUHJvcG9zZWQgU3RhbmRhcmQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:35:10 -0000 SXQgc2VlbXMgdGhhdCB5b3UgYXJlIGFnYWluc3QgUkZDNjkzNSBhbmQgUkZDNjkzNiwgcmlnaHQ/ DQoNClhpYW9odQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGwud29vZEBzdXJy ZXkuYWMudWsgW21haWx0bzpsLndvb2RAc3VycmV5LmFjLnVrXQ0KPiC3osvNyrG85DogMjAxNMTq MdTCMjTI1SAxOjE4DQo+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tOyBsYXJzQG5ldGFwcC5jb20NCj4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBs c0BpZXRmLm9yZw0KPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBs cy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTDQo+IGluIFVEUCkgdG8gUHJvcG9z ZWQgU3RhbmRhcmQNCj4gDQo+IHRoZSB0ZXh0IGlzIG5vdCBzYXRpc2ZhY3RvcnkuIG5ldmVyIHJl Y29tbWVuZCBzZXR0aW5nIHRvIHplcm8sIGFzIHRoYXQgcG9zZXMgYSByaXNrDQo+IHRvIHlvdXIg YW5kIHRvIG90aGVyIHRyYWZmaWMuIFN1Z2dlc3RlZCB0ZXh0Og0KPiAqKioNCj4gVGhlIFVEUCBj aGVja3N1bSBTSE9VTEQgYmUgdXNlZCB0byBwcm90ZWN0IHRoZSBwYXlsb2FkIGFuZCBlbnN1cmUg Y29ycmVjdA0KPiBkZW11bHRpcGxleGluZyBhbmQgZGVsaXZlcnkgdG8gdGhlIHR1bm5lbCwgYW5k IG5vdCB0byBvdGhlciBVRFAgZGVzdGluYXRpb25zLCBieQ0KPiBwcm90ZWN0aW5nIHRoZSBVRFAg cHNldWRvaGVhZGVyLg0KPiBVc2Ugb2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBpcyBOT1QgUkVDT01N RU5ERUQsIGV2ZW4gd2hlbiBkZXNpcmVkIGZvcg0KPiBwZXJmb3JtYW5jZSBvciBuZWNlc3NpdGF0 ZWQgYnkgaW1wbGVtZW50YXRpb24gcmVhc29ucywgZm9yIHRoZSByZWFzb25zDQo+IG91dGxpbmVk IGluIFtSRkM2OTM2XSBzZWN0aW9uIDMuDQo+IA0KPiBVRFAtTGl0ZSBbUkZDMzgyOF0gY2FuIHBy b3ZpZGUgYSBkZW11bHRpcGxleGluZyBjaGVjayBhbmQgTVBMUyBzdGFjaw0KPiBpbnRlZ3JpdHkg Y2hlY2sgd2hpbGUgYXZvaWRpbmcgdGhlIG92ZXJoZWFkIG9mIGNvbXB1dGluZyBhbiBpbnRlZ3Jp dHkgY2hlY2sNCj4gb3ZlciBhIHR1bm5lbGxlZCBmcmFtZSB0aGF0IGhhcyBpdHMgb3duIGludGVn cml0eSBjaGVjay4NCj4gKioqDQo+IA0KPiBMbG95ZCBXb29kDQo+IGh0dHA6Ly9hYm91dC5tZS9s bG95ZHdvb2QNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBG cm9tOiBYdXhpYW9odSBbeHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gU2VudDogMjMgSmFudWFyeSAy MDE0IDEyOjM1DQo+IFRvOiBXb29kIEwgIERyIChFbGVjdHJvbmljIEVuZyk7IEFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tOw0KPiBsYXJzQG5ldGFwcC5jb20NCj4gQ2M6IGpvZWxqYUBi b2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6 IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUw0KPiBp biBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXkuYWMu dWtdDQo+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjIzyNUgMTI6NDQNCj4gPiDK1bz+yMs6IFh1eGlh b2h1OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQo+ ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+INb3zOI6IFJFOiBb bXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gKEVu Y2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4NCj4gPiBT YXNoYQ0KPiA+DQo+ID4gPiAtIFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhlcmVvZikgaXMgYSBu b24taXNzdWUgYmVjYXVzZSBuYXRpdmUgTVBMUw0KPiA+ID4gZG9lcyBub3QgaGF2ZSBhbnl0aGlu ZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFyZSBjYXNlcyB3aGVyZQ0KPiA+ID4gcGFja2V0 cyBhcmUgY29ycnVwdGVkIHdpdGhpbiB0aGUgcm91dGVycykNCj4gPg0KPiA+IFNvIHlvdSBhZG1p dCB0aGF0IHBhY2tldHMgY2FuIGJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMgLSBhDQo+ ID4gY2hlY2sgdGhhdCBjYW4gb25seSBiZSBjYXVnaHQgYnkgYW4gZW5kLXRvLWVuZCBjaGVjaywg YSBjb3JydXB0aW9uDQo+ID4gdGhhdCBjYW4gbGVhZCB0byB0aGUgcHJvYmxlbXMgZGV0YWlsZWQg aW4gUkZDIDY5MzYgc2VjdGlvbiAzIC0gYW5kDQo+ID4gdGhlbiB5b3Ugc2F5IGl0J3MgYSBub24t aXNzdWUgYmVjYXVzZSB0aGlzIGRvZXNuJ3QgYWZmZWN0IG5hdGl2ZSBNUExTLiBCdXQgd2UncmUN Cj4gbm90IGRvaW5nIG5hdGl2ZSBNUExTIGhlcmUuDQo+ID4gV2UncmUgZG9pbmcgTVBMUyBvdmVy IFVEUC4NCj4gPg0KPiA+IGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0IGlzIGFib3V0IHR1 bm5lbGxpbmcgTVBMUyBpbiBVRFAuIEl0J3MgYW4gaXNzdWUuDQo+ID4gUGxlYXNlIHJlYWQgdGhl IG90aGVyIDE1MCBtZXNzYWdlcyB0aGF0IHlvdSByZWZlciB0by4NCj4gDQo+IEhpIExsb3lkLA0K PiANCj4gVGhlIGRyYWZ0IGRvZXNuJ3QgcmVxdWlyZSB0aGUgSVB2NiBVRFAgY2hlY2tzdW0gdG8g YmUgc2V0IHRvIHplcm8gcmVnYXJkbGVzcy4NCj4gU2VlIHRoZSBmb2xsb3dpbmcgdGV4dCBxdW90 ZWQgZnJvbSB0aGF0IGRyYWZ0Og0KPiANCj4gVURQIENoZWNrc3VtDQo+IA0KPiBUaGUgdXNhZ2Ug b2YgdGhpcyBmaWVsZCBpcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGN1cnJlbnQgVURQIHNwZWNp ZmljYXRpb24NCj4gW1JGQzc2OF0uIFRvIHNpbXBsaWZ5IHRoZSBvcGVyYXRpb24gb24gdGhlIGRl Y2Fwc3VsYXRvciwgdGhpcyBmaWVsZCBpcw0KPiBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVy byBpbiBJUHY0IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2UuIEluIHRoZSBJUHY2DQo+IFVEUCBlbmNh cHN1bGF0aW9uIGNhc2UsIGlmIGFwcHJvcHJpYXRlIGFjY29yZGluZyB0byB0aGUgcmVxdWlyZW1l bnRzIGRlZmluZWQgaW4NCj4gW1JGQzY5MzVdIFtSRkM2OTM2XSwgdGhpcyBmaWVsZCBpcyBhbHNv IFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvLg0KPiBTcGVjaWZpY2FsbHksIGlmIHRoZSBN UExTIHBheWxvYWQgaXMgSW50ZXJuZXQgUHJvdG9jb2wgKElQdjQgb3IgSVB2NikgcGFja2V0cywg aXQgaXMNCj4gUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gd2hlbiB0aGUgaW5uZXIgcGFj a2V0IGludGVncml0eSBjaGVja3MgaXMNCj4gYXZhaWxhYmxlLiBJbiBhZGRpdGlvbiwgaWYgdGhl IE1QTFMgcGF5bG9hZCBpcyBub24tSVAgcGFja2V0IHdoaWNoIGlzIHNwZWNpZmljYWxseQ0KPiBk ZXNpZ25lZCBmb3IgdHJhbnNtaXNzaW9uIG92ZXIgYSBsb3dlciBsYXllciB0aGF0IGRvZXMgbm90 IHByb3ZpZGUgYSBwYWNrZXQNCj4gaW50ZWdyaXR5IGd1YXJhbnRlZSwgaXQgaXMgUkVDT01NRU5E RUQgdG8gYmUgc2V0IHRvIHplcm8gYXMgd2VsbC4gT3RoZXJ3aXNlLA0KPiB1c2luZyB6ZXJvIGNo ZWNrc3VtIGlzIE5PVCBSRUNPTU1FTkRFRC4gTm90ZSB0aGF0IG90aGVyIElQIGVuY2Fwc3VsYXRp b25zDQo+IGZvciBNUExTIGRvIG5vdCBoYXZlIGEgY2hlY2tzdW0gaW4gdGhlIHR1bm5lbCBoZWFk ZXIuDQo+IA0KPiBJZiB5b3Ugc3RpbGwgYmVsaWV2ZSB0aGUgYWJvdmUgdGV4dCBpcyBub3Qgc2F0 aXNmYWN0b3J5LCBwbGVhc2UgcHJvdmlkZSB5b3VyIHRleHQuDQo+IA0KPiBCZXN0IHJlZ2FyZHMs DQo+IFhpYW9odQ0KPiANCj4gPiBMbG95ZCBXb29kDQo+ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lk d29vZA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBG cm9tOiBtcGxzIFttcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBYdXhpYW9odQ0K PiA+IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IDIzIEphbnVhcnkgMjAxNCAwMzox Ng0KPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgRWdnZXJ0LCBMYXJzDQo+ID4gQ2M6IEpv ZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gTGFzdCBD YWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gKEVuY2Fwc3VsYXRpbmcg TVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4NCj4gPiBIaQ0KPiA+DQo+ID4g PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ILeivP7IyzogQWxleGFuZGVyIFZhaW5zaHRlaW4g W21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4gPiA+ILeiy83Ksbzk OiAyMDE0xOox1MIyMsjVIDE5OjA1DQo+ID4gPiDK1bz+yMs6IEVnZ2VydCwgTGFycw0KPiA+ID4g s63LzTogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnOyBYdXhpYW9odQ0KPiA+ID4g1vfM4jog UkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4g PiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ ID4NCj4gPiA+IExhcnMgYW5kIGFsbCwNCj4gPiA+IExhc3QgdGltZSBJJ3ZlIGNvdW50ZWQgdGhl IElFVEYgTEMgdGhyZWFkIG9uIHRoaXMgZHJhZnQgaGFzIG1vcmUNCj4gPiA+IHRoYW4NCj4gPiA+ IDE1MCBtZXNzYWdlcyBpbiBpdCwgYW5kIGl0IHNlZW1zIHRoYXQgb24gc29tZSBpc3N1ZXMgKGNv bmdlc3Rpb24NCj4gPiA+IGNvbnRyb2wgYW5kIFVEUA0KPiA+ID4gY2hlY2tzdW1zKSB3ZSBhcmUg Z29pbmcgcm91bmQgdGhlIG11bGJlcnJ5IGJ1c2guDQo+ID4gPg0KPiA+ID4gSU1ITyBhbmQgRldJ VzoNCj4gPiA+IC0gVURQIGNoZWNrc3VtcyAob3IgbGFjayB0aGVyZW9mKSBpcyBhIG5vbi1pc3N1 ZSBiZWNhdXNlIG5hdGl2ZSBNUExTDQo+ID4gPiBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIGxpa2Ug dGhhdC4gQW5kIHllcywgdGhlcmUgYXJlIGNhc2VzIHdoZXJlDQo+ID4gPiBwYWNrZXRzIGFyZSBj b3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKSwgYnV0IHNvIGZhciBpdCBkaWQgbm90DQo+ID4g PiBwcmV2ZW50IE1QTFMgZGVwbG95bWVudC4gVGhlcmUgaXMsIGUuZy4sIFJGQyA0NzIwIGZvciBG Q1MgcmV0ZW50aW9uDQo+ID4gPiBpbiBQV3MsIGJ1dCBJIGRvdWJ0IGl0IGlzIHdpZGVseSBpbXBs ZW1lbnRlZCBhbmQgZGVwbG95ZWQgKHdvdWxkIGJlDQo+ID4gPiBuaWNlIHRvDQo+ID4ga25vdyku DQo+ID4gPiAtIEUyRSBjb25nZXN0aW9uIGNvbnRyb2wgKHJlZ2FyZGxlc3Mgb2YgaXRzIGltcGxp Y2F0aW9ucykgc2ltcGx5DQo+ID4gPiBjYW5ub3QgYmUgYWRkZWQgdG8gdGhpcyBwcm90b2NvbCB3 aXRob3V0IHNvbWUgbWFqb3IgY2hhbmdlcy4gQSBzaG9ydA0KPiA+ID4gYXBwbGljYWJpbGl0eSBz dGF0ZW1lbnQgZXhwbGFpbmluZyB0aGF0IHNob3VsZCBzdWZmaWNlIElNTy4NCj4gPg0KPiA+IEhp IFNhc2hhLA0KPiA+DQo+ID4gSSBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnRzLg0KPiA+DQo+ ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4gPiBNeSAyYywNCj4gPiA+ICAg ICAgICBTYXNoYQ0KPiA+ID4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t DQo+ID4gPiBNb2JpbGU6IDA1NC05MjY2MzAyDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRWdnZXJ0LA0KPiA+ID4gPiBMYXJzDQo+ID4gPiA+IFNlbnQ6 IFdlZG5lc2RheSwgSmFudWFyeSAyMiwgMjAxNCAxMjoyMyBQTQ0KPiA+ID4gPiBUbzogWHV4aWFv aHUNCj4gPiA+ID4gQ2M6IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiBTdWJq ZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0 Pg0KPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRh cmQNCj4gPiA+ID4NCj4gPiA+ID4gSGksDQo+ID4gPiA+DQo+ID4gPiA+IE9uIDIwMTQtMS0yMiwg YXQgMTE6MTIsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+ID4g PiBJIHdvbmRlciB3aGV0aGVyIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBPSyB0byB5b3U6DQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBTaW5jZSB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiBjYXVz ZXMgTVBMUyBwYWNrZXRzIHRvIGJlDQo+ID4gPiA+IGZvcndhcmRlZCB0aHJvdWdoICJVRFAgdHVu bmVscyIsIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgZ3VpZGVsaW5lcw0KPiA+ID4gPiBmb3IgVURQ IHR1bm5lbHMgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMS4zIG9mIFtSRkM1NDA1XSBTSE9VTEQg YmUNCj4gPiBmb2xsb3dlZC4NCj4gPiA+ID4gU3BlY2lmaWNhbGx5LCBNUExTIGNhbiBjYXJyeSBh IG51bWJlciBvZiBkaWZmZXJlbnQgcHJvdG9jb2xzIGFzIHBheWxvYWRzLg0KPiA+ID4gPiBXaGVu IGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcyBr bm93bg0KPiA+ID4gPiBhdCBjb25maWd1cmF0aW9uIHRpbWUgdG8gYmUgSVAtYmFzZWQgYW5kIGNv bmdlc3Rpb24tY29udHJvbGxlZCwNCj4gPiA+ID4gdGhlIFVEUCB0dW5uZWwgU0hPVUxEIE5PVCBl bXBsb3kgaXRzIG93biBjb25nZXN0aW9uIGNvbnRyb2wNCj4gPiA+ID4gbWVjaGFuaXNtLCBiZWNh dXNlIGNvbmdlc3Rpb24gbG9zc2VzIG9mIHR1bm5lbGVkIHRyYWZmaWMgd2lsbA0KPiA+ID4gPiB0 cmlnZ2VyIGFuIGNvbmdlc3Rpb24gcmVzcG9uc2UgYXQgdGhlIG9yaWdpbmFsIHNlbmRlcnMgb2Yg dGhlIHR1bm5lbGVkDQo+IHRyYWZmaWMuDQo+ID4gPiA+IFdoZW4gYW4gVURQIHR1bm5lbCBpcyB1 c2VkIGZvciBNUExTIHBheWxvYWQgdHJhZmZpYyB0aGF0IGlzIGtub3duDQo+ID4gPiA+IGF0IGNv bmZpZ3VyYXRpb24gdGltZSBub3QgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+IGNvbmdlc3Rp b24tY29udHJvbGxlZCwgdGhlIFVEUCB0dW5uZWwgU0hPVUxEIGVtcGxveSBhbiBhcHByb3ByaWF0 ZQ0KPiA+ID4gPiBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIGFzIGRlc2NyaWJlZCBpbiBb UkZDMzk4NV0uIE5vdGUgdGhhdA0KPiA+ID4gPiBpdCBTVFJPTkdMWSBSRUNPTU1FTkRFRCB0byBk ZXBsb3kgc3VjaCBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kNCj4gPiA+ID4gb25seSB3aXRoaW4g YSBTUCBuZXR3b3JrIG9yIG5ldHdvcmtzIG9mIGFuIGFkamFjZW50IHNldCBvZg0KPiA+ID4gPiBj by1vcGVyYXRpbmcgU1BzLCByYXRoZXIgdGhhbiBvdmVyIHRoZQ0KPiA+IEludGVybmV0Lg0KPiA+ ID4gPiBGdXJ0aGVybW9yZSwgcGFja2V0IGZpbHRlcnMgc2hvdWxkIGJlIGFkZGVkIHRvIGJsb2Nr IHRyYWZmaWMgd2l0aA0KPiA+ID4gPiB0aGUgVURQIHBvcnQgbnVtYmVyIGZvciBNUExTIG92ZXIg VURQIHRvIHByZXZlbnQgTVBMUyBvdmVyIFVEUA0KPiA+ID4gPiBwYWNrZXRzIHRvIGVzY2FwZSBm cm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmtzIGR1ZSB0bw0KPiA+ID4gPiBtaXNjb25m aWd1YXRpb24gb3IgcGFja2V0DQo+ID4gPiBlcnJvcnMuDQo+ID4gPiA+DQo+ID4gPiA+IEkgdGhp bmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGRlc2NyaWJlIHRoZSBPQU0gY29udHJvbCBsb29wIGlu DQo+ID4gPiA+IChzb21lKSBtb3JlIGRldGFpbCwgcmF0aGVyIHRoYW4gcG9pbnRpbmcgdG8gUkZD Mzk4NSwgd2hpY2ggZG9lc24ndA0KPiA+ID4gPiBoYXZlIGEgd2hvbGUgbG90IG9mIGRldGFpbCBl aXRoZXIuIEFsc28gYmVjYXVzZSB0aGUgYWRkaW5nIG9mDQo+ID4gPiA+IGZpcmV3YWxsIHJ1bGVz IHJlcXVpcmVzIGFuIE9BTSBob29rLg0KPiA+ID4gPg0KPiA+ID4gPiBTaW5jZSBTVFJPTkdMWSBS RUNPTU1FTkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJtIGFuZA0KPiA+ID4gUkVDT01NRU5ERUQg aXMNCj4gPiA+ID4gdG9vIHdlYWssIEknZCBzdWdnZXN0IHRvIGNoYW5nZSB0aGlzIHRvIE1VU1Qu DQo+ID4gPiA+DQo+ID4gPiA+IEZpbmFsbHksIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBz aG91bGQgYmUgcHJvbWluZW50bHkgbWFkZSBpbg0KPiA+ID4gPiB0aGUgYWJzdHJhY3QsIGludHJv ZHVjdGlvbiwgZXRjLg0KPiA+ID4gPg0KPiA+ID4gPiBMYXJzDQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtcGxzIG1haWxpbmcgbGlzdA0K PiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCg== From l.wood@surrey.ac.uk Thu Jan 23 16:35:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CF81A04B1; Thu, 23 Jan 2014 16:35:41 -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, 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 WoskbpwVuOtF; Thu, 23 Jan 2014 16:35:36 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id D3F221A04AD; Thu, 23 Jan 2014 16:35:35 -0800 (PST) Received: from [85.158.136.51:13375] by server-17.bemta-5.messagelabs.com id 87/38-19152-655B1E25; Fri, 24 Jan 2014 00:35:34 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-16.tower-49.messagelabs.com!1390523733!18630929!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5644 invoked from network); 24 Jan 2014 00:35:33 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-16.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jan 2014 00:35:33 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 24 Jan 2014 00:35:32 +0000 From: To: , Date: Fri, 24 Jan 2014 00:33:49 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8YmNyQleJV1FEDSgabe3hbCgDd0wAAxaYP Message-ID: <290E20B455C66743BE178C5C84F1240847E63346E6@EXMB01CMS.surrey.ac.uk> References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> <52E1AC3E.2040204@isi.edu> , <52E1AF6E.1000108@isi.edu> In-Reply-To: <52E1AF6E.1000108@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, jnc@mercury.lcs.mit.edu, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:35:41 -0000 I wouldn't say the checksum issue has petered out - I've provided replaceme= nt paragraphs of text to Xiaohu which will hopefully resolve it. Lloyd Wood http://about.me/lloydwood ________________________________________ From: ietf [ietf-bounces@ietf.org] On Behalf Of Joe Touch [touch@isi.edu] Sent: 24 January 2014 00:10 To: Alia Atlas Cc: mpls@ietf.org; Edward Crabbe; Noel Chiappa; IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Hi, Alia, On 1/23/2014 4:07 PM, Alia Atlas wrote: > I don't want to get in the way of vehement discussion, but I thought we > were on the verge of finding an actual solution... > > IMHO, that was a combination of an applicability statement, using SHOULD > for congestion control and checksum, and defining a longer-term > OAM-based approach (as Stewart Bryant suggested) to be able to verify > that packet corruption or excessive drops aren't happening. > > Does that sound like an acceptable set? It answers my concerns (I was concerned about the checksum issue too, though it seems to have petered out). I wasn't tracking whether there were other issues that this doesn't address that were raised, though. Joe > Alia > > > On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch > wrote: > > > > On 1/23/2014 3:32 PM, Edward Crabbe wrote: > > Joe, thanks for your response. Comments inline: > > > On 1/23/2014 1:27 PM, Edward Crabbe wrote: > > Part of the point of using UDP is to make use of lowest > common > denominator forwarding hardware in introducing entropy t= o > protocols that > lack it ( this is particularly true of the GRE in UDP > use case also > under discussion elsewhere). > > The tunnel is not the source of the traffic. The > _source of the > traffic_ is the source of the traffic. > > > To the Internet, the tunnel encapusulator is the source of > traffic. > Tracing the data back further than that is a mirage at best > - and > irrelevant. > > > The 'internet' cares about characteristics of reactivity to > congestion. > This is guaranteed by the /source of the traffic/ independent > of any > intermediate node. > > > Are you prepared to make that a requirement of this document, i.e., > that the only MPLS traffic that can be UDP encapsulated is known to > react to congestion? > > How exactly can you know that? > > > The tunnel head-end is responsible for the tunnel walking, > talking, > and quaking like a duck (host). When the tunnel head-end kno= ws > something about the ultimate origin of the traffic - > whether real, > imagined, or from Asgard - then it has done it's duty > (e.g., that > it's already congestion controlled). > > But that head end is responsible, regardless of what it > knows or > doesn't. And when it doesn't know, the only way to be > responsible is > to put in its own reactivity. > > This is not fact; it's actually precisely the principle we're > currently > arguing about. ;) > > > Actually, it's a paraphrasing of Section 3.1.3 of RFC5405. > > We can continue to debate it, but until it's been *changed* by a > revision, it remains BCP. > > > I would posit: > > The tunnel doesn't have to know anything about congestion or > performance > characteristics because the originating application must. > > > That works only if you know that fact about the originating > application. However, there are plenty of applications whose traffic > goes over MPLS that isn't congestion reactive or bandwidth-limited. > > > > See GRE, > > MPLS, many other tunnel types, > > > This isn't an issue for all tunnels until they enter the Internet... > > > including several existing within the > IETF that make use of an outer UDP header. > > > Which are all already supposed to follow the recommendations of > RFC5405. To the extent that they don't, they don't agree with that BC= P. > > I'm not saying such things never can or will exist, but I don't > think the IETF should be self-contradictory. We already agreed as a > group on such BCPs and other standards, and new standards-track docs > need to follow them. > > > The originating application > who's traffic is being tunneled should be responsible > for congestion > control, or lack there of. > > Perhaps it should be, but that's an agreement between whomev= er > implements/deploys the tunnel headend and whomever provides = the > originating traffic to them. The problem is that this isn't > true for > the typical use case for this kind of encapsulation. > > How so? As mentioned before, this is the same case as standard > GRE/MPLS > etc. > > > It's putting MPLS inside UDP. That's a different case, and the > reason RFC5405 applies. > > > I.e., if we were talking about MPLS traffic that already was > reactive, we wouldn't be claiming the need for additional > encapsulator mechanism. It's precisely because nothing is kn= own > about the MPLS traffic that the encapsulator needs to act. > > The MPLS traffic doesn't have to be reactive, it's the applicatio= ns > being encapsulated / traversing a particular tunnel that are > responsible > for and aware of path and congestion charateristics. Because > the MPLS > head end knows nothing about the /end to end application 'session= '/ > characteristics it /shouldn't/ have anything to do with congestio= n > management. > > > OK, so what you're saying is that "traffic using this encapsulation > MUST be known to be congestion reactive". Put that in the doc and > we'll debate whether we believe it. > > But right now you're basically saying that because you think it's > someone else's problem (the originating application), it isn't > yours. The difficulty with that logic is that you (the tunnel > headend) is responsible to ensure that this is true - either by > *knowing* that the originating traffic is congestion reactive, or by > putting in its own mechanism to ensure that this happens if the > originating application isn't. > > > > Are we advocating a return to intermediate > > congestion control (I like X.25 as much as the next guy, > but...). This > is a very stark change of direction. > > I think mandating congestion control is not > technically sound from > either a theoretical (violation of end to end > principle, stacking of > congestion control algorithms leading to complex and > potentially > suboptimal results) or economic perspective (as a very > large > backbone, > we've been doing just fine without intermediate congesti= on > management > thank you very much, and I have 0 desire to pay for a co= st > prohibitive, > unnecessary feature in silicon.) > > Write that up, and we'll see how it turns out in the IETF. > However, > right now, the IETF BCPs do require reactive congestion > management > of transport streams. > > Which part? The end-to-end principle, or the aversion to congest= ion > control stacking? These have been implicit in all tunneling > protocols > produced by the IETF for the modern internet. > > > Sure, and that's reflected in RFC5405 already. However, please, > PLEASE appreciate that NOBODY here is asking you to put in > "congestion control stacking"; that happens when you run two > dynamic, reactive control algorithms using the same timescale on top > of each other. > > Equally well-known in CC circles is that you CAN - and often > *should* - stack different kinds of mechanisms at different layers > with different timescales. E.g., that's why we have an AQM WG - > because even when all the traffic is TCP, that's not quite enough > inside the network. That's also why Lars was suggesting something > coarse on a longer timescale - a circuit breaker - rather than AIMD > on a RTT basis. > > Keep in mind as well that the E2E argument says that you can't get > an E2E service by composing the equivalent HBH one; it also says > that HBH mechanisms can be required for efficiency. That's what > we're talking about here - the efficiency impact of congestion, not > the overall correctness of E2E control. > > > If you don't want/like that, then either don't use transport > encapsulation, or change the BCPs. > > These BCPs are defined for an originating /application/. > > > Yes, and I don't understand why you (and others) keep thinking it > matters that there are layers of things behind the tunnel head end. > It doesn't - unless you KNOW what those layers are, and can ensure > that they behave as you expect. > > > In this case > the UDP header is simply a shim header applied to existing > application > traffic. > > > It's not "simply a shim" - if that's the case, use IP and we're > done. No need for congestion control. > > The reason congestion issues arise is because you're inserting a > header ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO > REACT TO****. > > If you put in a UDP-like header that nobody in the Internet would > interpret, this wouldn't be an issue. > > But you simply cannot expect the Internet to treat you like > "application" traffic if you won't enforce acting like that traffic t= oo. > > > The tunnel head does not introduce traffic independent of the > originating application. > > > The Internet ****neither knows nor cares****. > > To the Internet, the head-end is the source. Whatever data the head > end puts inside the UDP packets *is application data* to the rest of > the Internet. > > Again, if you are saying that you know so much about the originating > source that you know you don't need additional mechanism at the > headend, say so - but then live by that requirement. > > If *any* MPLS traffic could show up at the headend, then it becomes > the headend's responsibility to do something. > > --- > > Consider the following case: > > - video shows up inside the OS, destined for the network > > - software X bundles that video and sends it to go out > > - software Y puts that data into UDP packets to go > to the Internet > > So what's the "application" here? To the Internet, it's software Y > -- the thing that puts the 'application' data into UDP packets. The > previous steps are irrelevant - just as irrelevant as the singer > your video camera is filming, as irrelevant as the sun that created > the light that is reflected off the singer to your camera. > > If software Y knows so much about the steps that lead to its input > data that it knows it's congestion reactive, nothing more need be don= e. > > If NOT (and that's the relevant corollary here), then it becomes > software Y's responsibility to put in some reactivity. > > Joe > > From l.wood@surrey.ac.uk Thu Jan 23 16:53:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD921A015F for ; Thu, 23 Jan 2014 16:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.889 X-Spam-Level: X-Spam-Status: No, score=0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5PzQBoD9ViaD for ; Thu, 23 Jan 2014 16:53:14 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.144]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA7F1A0253 for ; Thu, 23 Jan 2014 16:53:13 -0800 (PST) Received: from [195.245.231.67:53659] by server-8.bemta-5.messagelabs.com id 8A/0B-29838-779B1E25; Fri, 24 Jan 2014 00:53:11 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-16.tower-82.messagelabs.com!1390524791!34589369!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2452 invoked from network); 24 Jan 2014 00:53:11 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-16.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jan 2014 00:53:11 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 24 Jan 2014 00:53:10 +0000 From: To: , , Date: Fri, 24 Jan 2014 00:48:23 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiOAAIGV4IAASynFgAB+v4CAAAUDQQ== Message-ID: <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082477E6@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082477E6@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:53:17 -0000 UkZDNjkzNSB3YXMgd3JpdHRlbiBmcm9tIGEgdHVubmVsbGluZyBwZXJzcGVjdGl2ZSwgdG8gYWxs b3cgdHVubmVsbGluZyB0byB1c2UgemVybyBjaGVja3N1bXMNCmZvciBwZXJmb3JtYW5jZSwgYW5k IGFuYWx5c2VkIHJpc2tzIHRvIHRoZSB0dW5uZWwgdHJhZmZpYyAtIGJ1dCBub3QgdG8gb3RoZXIg dXNlcnMuDQoNCiAgICJXaGlsZSB0aGUgbWV0aG9kcyBkbw0KICAgbm90IGd1YXJhbnRlZSBjb3Jy ZWN0bmVzcywgdGhleSBjYW4gcmVkdWNlIHRoZSByaXNrcyBvZiByZWxheGluZyB0aGUNCiAgIFVE UCBjaGVja3N1bSByZXF1aXJlbWVudCBmb3IgYSB0dW5uZWwgYXBwbGljYXRpb24gdXNpbmcgSVB2 Ni4iDQoNClJpc2tzIHRvIG90aGVyIGFwcGxpY2F0aW9ucyBhcmUgbm90IGFzc2Vzc2VkLCBhbmQg bm90IHN0YXRlZC4NCg0KDQpMbG95ZCBXb29kDQpodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBYdXhpYW9odSBb eHV4aWFvaHVAaHVhd2VpLmNvbV0NClNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwMDozNA0KVG86IFdv b2QgTCAgRHIgKEVsZWN0cm9uaWMgRW5nKTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b207IGxhcnNAbmV0YXBwLmNvbQ0KQ2M6IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcN ClN1YmplY3Q6ILTwuLQ6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRw LTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJk DQoNCkl0IHNlZW1zIHRoYXQgeW91IGFyZSBhZ2FpbnN0IFJGQzY5MzUgYW5kIFJGQzY5MzYsIHJp Z2h0Pw0KDQpYaWFvaHUNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBsLndvb2RA c3VycmV5LmFjLnVrIFttYWlsdG86bC53b29kQHN1cnJleS5hYy51a10NCj4gt6LLzcqxvOQ6IDIw MTTE6jHUwjI0yNUgMToxOA0KPiDK1bz+yMs6IFh1eGlhb2h1OyBBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQo+ILOty806IGpvZWxqYUBib2d1cy5jb207 IG1wbHNAaWV0Zi5vcmcNCj4g1vfM4jogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRm LW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUw0KPiBpbiBVRFApIHRvIFBy b3Bvc2VkIFN0YW5kYXJkDQo+DQo+IHRoZSB0ZXh0IGlzIG5vdCBzYXRpc2ZhY3RvcnkuIG5ldmVy IHJlY29tbWVuZCBzZXR0aW5nIHRvIHplcm8sIGFzIHRoYXQgcG9zZXMgYSByaXNrDQo+IHRvIHlv dXIgYW5kIHRvIG90aGVyIHRyYWZmaWMuIFN1Z2dlc3RlZCB0ZXh0Og0KPiAqKioNCj4gVGhlIFVE UCBjaGVja3N1bSBTSE9VTEQgYmUgdXNlZCB0byBwcm90ZWN0IHRoZSBwYXlsb2FkIGFuZCBlbnN1 cmUgY29ycmVjdA0KPiBkZW11bHRpcGxleGluZyBhbmQgZGVsaXZlcnkgdG8gdGhlIHR1bm5lbCwg YW5kIG5vdCB0byBvdGhlciBVRFAgZGVzdGluYXRpb25zLCBieQ0KPiBwcm90ZWN0aW5nIHRoZSBV RFAgcHNldWRvaGVhZGVyLg0KPiBVc2Ugb2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBpcyBOT1QgUkVD T01NRU5ERUQsIGV2ZW4gd2hlbiBkZXNpcmVkIGZvcg0KPiBwZXJmb3JtYW5jZSBvciBuZWNlc3Np dGF0ZWQgYnkgaW1wbGVtZW50YXRpb24gcmVhc29ucywgZm9yIHRoZSByZWFzb25zDQo+IG91dGxp bmVkIGluIFtSRkM2OTM2XSBzZWN0aW9uIDMuDQo+DQo+IFVEUC1MaXRlIFtSRkMzODI4XSBjYW4g cHJvdmlkZSBhIGRlbXVsdGlwbGV4aW5nIGNoZWNrIGFuZCBNUExTIHN0YWNrDQo+IGludGVncml0 eSBjaGVjayB3aGlsZSBhdm9pZGluZyB0aGUgb3ZlcmhlYWQgb2YgY29tcHV0aW5nIGFuIGludGVn cml0eSBjaGVjaw0KPiBvdmVyIGEgdHVubmVsbGVkIGZyYW1lIHRoYXQgaGFzIGl0cyBvd24gaW50 ZWdyaXR5IGNoZWNrLg0KPiAqKioNCj4NCj4gTGxveWQgV29vZA0KPiBodHRwOi8vYWJvdXQubWUv bGxveWR3b29kDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g RnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+IFNlbnQ6IDIzIEphbnVhcnkg MjAxNCAxMjozNQ0KPiBUbzogV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpOyBBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsNCj4gbGFyc0BuZXRhcHAuY29tDQo+IENjOiBqb2VsamFA Ym9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IHJlOiBbbXBsc10gTGFzdCBDYWxs OiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMNCj4g aW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPg0KPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXkuYWMu dWtdDQo+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjIzyNUgMTI6NDQNCj4gPiDK1bz+yMs6IFh1eGlh b2h1OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQo+ ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+INb3zOI6IFJFOiBb bXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gKEVu Y2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4NCj4gPiBT YXNoYQ0KPiA+DQo+ID4gPiAtIFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhlcmVvZikgaXMgYSBu b24taXNzdWUgYmVjYXVzZSBuYXRpdmUgTVBMUw0KPiA+ID4gZG9lcyBub3QgaGF2ZSBhbnl0aGlu ZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFyZSBjYXNlcyB3aGVyZQ0KPiA+ID4gcGFja2V0 cyBhcmUgY29ycnVwdGVkIHdpdGhpbiB0aGUgcm91dGVycykNCj4gPg0KPiA+IFNvIHlvdSBhZG1p dCB0aGF0IHBhY2tldHMgY2FuIGJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMgLSBhDQo+ ID4gY2hlY2sgdGhhdCBjYW4gb25seSBiZSBjYXVnaHQgYnkgYW4gZW5kLXRvLWVuZCBjaGVjaywg YSBjb3JydXB0aW9uDQo+ID4gdGhhdCBjYW4gbGVhZCB0byB0aGUgcHJvYmxlbXMgZGV0YWlsZWQg aW4gUkZDIDY5MzYgc2VjdGlvbiAzIC0gYW5kDQo+ID4gdGhlbiB5b3Ugc2F5IGl0J3MgYSBub24t aXNzdWUgYmVjYXVzZSB0aGlzIGRvZXNuJ3QgYWZmZWN0IG5hdGl2ZSBNUExTLiBCdXQgd2UncmUN Cj4gbm90IGRvaW5nIG5hdGl2ZSBNUExTIGhlcmUuDQo+ID4gV2UncmUgZG9pbmcgTVBMUyBvdmVy IFVEUC4NCj4gPg0KPiA+IGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0IGlzIGFib3V0IHR1 bm5lbGxpbmcgTVBMUyBpbiBVRFAuIEl0J3MgYW4gaXNzdWUuDQo+ID4gUGxlYXNlIHJlYWQgdGhl IG90aGVyIDE1MCBtZXNzYWdlcyB0aGF0IHlvdSByZWZlciB0by4NCj4NCj4gSGkgTGxveWQsDQo+ DQo+IFRoZSBkcmFmdCBkb2Vzbid0IHJlcXVpcmUgdGhlIElQdjYgVURQIGNoZWNrc3VtIHRvIGJl IHNldCB0byB6ZXJvIHJlZ2FyZGxlc3MuDQo+IFNlZSB0aGUgZm9sbG93aW5nIHRleHQgcXVvdGVk IGZyb20gdGhhdCBkcmFmdDoNCj4NCj4gVURQIENoZWNrc3VtDQo+DQo+IFRoZSB1c2FnZSBvZiB0 aGlzIGZpZWxkIGlzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgY3VycmVudCBVRFAgc3BlY2lmaWNh dGlvbg0KPiBbUkZDNzY4XS4gVG8gc2ltcGxpZnkgdGhlIG9wZXJhdGlvbiBvbiB0aGUgZGVjYXBz dWxhdG9yLCB0aGlzIGZpZWxkIGlzDQo+IFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGlu IElQdjQgVURQIGVuY2Fwc3VsYXRpb24gY2FzZS4gSW4gdGhlIElQdjYNCj4gVURQIGVuY2Fwc3Vs YXRpb24gY2FzZSwgaWYgYXBwcm9wcmlhdGUgYWNjb3JkaW5nIHRvIHRoZSByZXF1aXJlbWVudHMg ZGVmaW5lZCBpbg0KPiBbUkZDNjkzNV0gW1JGQzY5MzZdLCB0aGlzIGZpZWxkIGlzIGFsc28gUkVD T01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8uDQo+IFNwZWNpZmljYWxseSwgaWYgdGhlIE1QTFMg cGF5bG9hZCBpcyBJbnRlcm5ldCBQcm90b2NvbCAoSVB2NCBvciBJUHY2KSBwYWNrZXRzLCBpdCBp cw0KPiBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyB3aGVuIHRoZSBpbm5lciBwYWNrZXQg aW50ZWdyaXR5IGNoZWNrcyBpcw0KPiBhdmFpbGFibGUuIEluIGFkZGl0aW9uLCBpZiB0aGUgTVBM UyBwYXlsb2FkIGlzIG5vbi1JUCBwYWNrZXQgd2hpY2ggaXMgc3BlY2lmaWNhbGx5DQo+IGRlc2ln bmVkIGZvciB0cmFuc21pc3Npb24gb3ZlciBhIGxvd2VyIGxheWVyIHRoYXQgZG9lcyBub3QgcHJv dmlkZSBhIHBhY2tldA0KPiBpbnRlZ3JpdHkgZ3VhcmFudGVlLCBpdCBpcyBSRUNPTU1FTkRFRCB0 byBiZSBzZXQgdG8gemVybyBhcyB3ZWxsLiBPdGhlcndpc2UsDQo+IHVzaW5nIHplcm8gY2hlY2tz dW0gaXMgTk9UIFJFQ09NTUVOREVELiBOb3RlIHRoYXQgb3RoZXIgSVAgZW5jYXBzdWxhdGlvbnMN Cj4gZm9yIE1QTFMgZG8gbm90IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4N Cj4NCj4gSWYgeW91IHN0aWxsIGJlbGlldmUgdGhlIGFib3ZlIHRleHQgaXMgbm90IHNhdGlzZmFj dG9yeSwgcGxlYXNlIHByb3ZpZGUgeW91ciB0ZXh0Lg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhp YW9odQ0KPg0KPiA+IExsb3lkIFdvb2QNCj4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206IG1w bHMgW21wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQo+ID4gW3h1 eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gU2VudDogMjMgSmFudWFyeSAyMDE0IDAzOjE2DQo+ID4g VG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBFZ2dlcnQsIExhcnMNCj4gPiBDYzogSm9lbCBKYWVn Z2xpOyBtcGxzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxk cmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGlu IFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPg0KPiA+IEhpDQo+ID4NCj4gPiA+IC0tLS0t 08q8/tStvP4tLS0tLQ0KPiA+ID4gt6K8/sjLOiBBbGV4YW5kZXIgVmFpbnNodGVpbiBbbWFpbHRv OkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ID4gt6LLzcqxvOQ6IDIwMTTE 6jHUwjIyyNUgMTk6MDUNCj4gPiA+IMrVvP7IyzogRWdnZXJ0LCBMYXJzDQo+ID4gPiCzrcvNOiBK b2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1DQo+ID4gPiDW98ziOiBSRTogW21w bHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gKEVu Y2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPg0KPiA+ ID4gTGFycyBhbmQgYWxsLA0KPiA+ID4gTGFzdCB0aW1lIEkndmUgY291bnRlZCB0aGUgSUVURiBM QyB0aHJlYWQgb24gdGhpcyBkcmFmdCBoYXMgbW9yZQ0KPiA+ID4gdGhhbg0KPiA+ID4gMTUwIG1l c3NhZ2VzIGluIGl0LCBhbmQgaXQgc2VlbXMgdGhhdCBvbiBzb21lIGlzc3VlcyAoY29uZ2VzdGlv bg0KPiA+ID4gY29udHJvbCBhbmQgVURQDQo+ID4gPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyBy b3VuZCB0aGUgbXVsYmVycnkgYnVzaC4NCj4gPiA+DQo+ID4gPiBJTUhPIGFuZCBGV0lXOg0KPiA+ ID4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJlY2F1 c2UgbmF0aXZlIE1QTFMNCj4gPiA+IGRvZXMgbm90IGhhdmUgYW55dGhpbmcgbGlrZSB0aGF0LiBB bmQgeWVzLCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUNCj4gPiA+IHBhY2tldHMgYXJlIGNvcnJ1cHRl ZCB3aXRoaW4gdGhlIHJvdXRlcnMpLCBidXQgc28gZmFyIGl0IGRpZCBub3QNCj4gPiA+IHByZXZl bnQgTVBMUyBkZXBsb3ltZW50LiBUaGVyZSBpcywgZS5nLiwgUkZDIDQ3MjAgZm9yIEZDUyByZXRl bnRpb24NCj4gPiA+IGluIFBXcywgYnV0IEkgZG91YnQgaXQgaXMgd2lkZWx5IGltcGxlbWVudGVk IGFuZCBkZXBsb3llZCAod291bGQgYmUNCj4gPiA+IG5pY2UgdG8NCj4gPiBrbm93KS4NCj4gPiA+ IC0gRTJFIGNvbmdlc3Rpb24gY29udHJvbCAocmVnYXJkbGVzcyBvZiBpdHMgaW1wbGljYXRpb25z KSBzaW1wbHkNCj4gPiA+IGNhbm5vdCBiZSBhZGRlZCB0byB0aGlzIHByb3RvY29sIHdpdGhvdXQg c29tZSBtYWpvciBjaGFuZ2VzLiBBIHNob3J0DQo+ID4gPiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVu dCBleHBsYWluaW5nIHRoYXQgc2hvdWxkIHN1ZmZpY2UgSU1PLg0KPiA+DQo+ID4gSGkgU2FzaGEs DQo+ID4NCj4gPiBJIGZ1bGx5IGFncmVlIHdpdGggeW91ciBwb2ludHMuDQo+ID4NCj4gPiBCZXN0 IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPiA+IE15IDJjLA0KPiA+ID4gICAgICAgIFNh c2hhDQo+ID4gPiBFbWFpbDogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gPiA+ IE1vYmlsZTogMDU0LTkyNjYzMDINCj4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPiA+IEZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBFZ2dlcnQsDQo+ID4gPiA+IExhcnMNCj4gPiA+ID4gU2VudDogV2VkbmVz ZGF5LCBKYW51YXJ5IDIyLCAyMDE0IDEyOjIzIFBNDQo+ID4gPiA+IFRvOiBYdXhpYW9odQ0KPiA+ ID4gPiBDYzogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJl OiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4g PiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ ID4gPg0KPiA+ID4gPiBIaSwNCj4gPiA+ID4NCj4gPiA+ID4gT24gMjAxNC0xLTIyLCBhdCAxMTox MiwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ID4gPiA+IEkgd29u ZGVyIHdoZXRoZXIgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIE9LIHRvIHlvdToNCj4gPiA+ID4gPg0K PiA+ID4gPiA+IFNpbmNlIHRoZSBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uIGNhdXNlcyBNUExT IHBhY2tldHMgdG8gYmUNCj4gPiA+ID4gZm9yd2FyZGVkIHRocm91Z2ggIlVEUCB0dW5uZWxzIiwg dGhlIGNvbmdlc3Rpb24gY29udHJvbCBndWlkZWxpbmVzDQo+ID4gPiA+IGZvciBVRFAgdHVubmVs cyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjMgb2YgW1JGQzU0MDVdIFNIT1VMRCBiZQ0KPiA+ IGZvbGxvd2VkLg0KPiA+ID4gPiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5IGEgbnVtYmVy IG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMgcGF5bG9hZHMuDQo+ID4gPiA+IFdoZW4gYW4gVURQ IHR1bm5lbCBpcyB1c2VkIGZvciBNUExTIHBheWxvYWQgdHJhZmZpYyB0aGF0IGlzIGtub3duDQo+ ID4gPiA+IGF0IGNvbmZpZ3VyYXRpb24gdGltZSB0byBiZSBJUC1iYXNlZCBhbmQgY29uZ2VzdGlv bi1jb250cm9sbGVkLA0KPiA+ID4gPiB0aGUgVURQIHR1bm5lbCBTSE9VTEQgTk9UIGVtcGxveSBp dHMgb3duIGNvbmdlc3Rpb24gY29udHJvbA0KPiA+ID4gPiBtZWNoYW5pc20sIGJlY2F1c2UgY29u Z2VzdGlvbiBsb3NzZXMgb2YgdHVubmVsZWQgdHJhZmZpYyB3aWxsDQo+ID4gPiA+IHRyaWdnZXIg YW4gY29uZ2VzdGlvbiByZXNwb25zZSBhdCB0aGUgb3JpZ2luYWwgc2VuZGVycyBvZiB0aGUgdHVu bmVsZWQNCj4gdHJhZmZpYy4NCj4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9y IE1QTFMgcGF5bG9hZCB0cmFmZmljIHRoYXQgaXMga25vd24NCj4gPiA+ID4gYXQgY29uZmlndXJh dGlvbiB0aW1lIG5vdCB0byBiZSBJUC1iYXNlZCBhbmQNCj4gPiA+ID4gY29uZ2VzdGlvbi1jb250 cm9sbGVkLCB0aGUgVURQIHR1bm5lbCBTSE9VTEQgZW1wbG95IGFuIGFwcHJvcHJpYXRlDQo+ID4g PiA+IGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluIFtSRkMzOTg1 XS4gTm90ZSB0aGF0DQo+ID4gPiA+IGl0IFNUUk9OR0xZIFJFQ09NTUVOREVEIHRvIGRlcGxveSBz dWNoIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9neQ0KPiA+ID4gPiBvbmx5IHdpdGhpbiBhIFNQIG5l dHdvcmsgb3IgbmV0d29ya3Mgb2YgYW4gYWRqYWNlbnQgc2V0IG9mDQo+ID4gPiA+IGNvLW9wZXJh dGluZyBTUHMsIHJhdGhlciB0aGFuIG92ZXIgdGhlDQo+ID4gSW50ZXJuZXQuDQo+ID4gPiA+IEZ1 cnRoZXJtb3JlLCBwYWNrZXQgZmlsdGVycyBzaG91bGQgYmUgYWRkZWQgdG8gYmxvY2sgdHJhZmZp YyB3aXRoDQo+ID4gPiA+IHRoZSBVRFAgcG9ydCBudW1iZXIgZm9yIE1QTFMgb3ZlciBVRFAgdG8g cHJldmVudCBNUExTIG92ZXIgVURQDQo+ID4gPiA+IHBhY2tldHMgdG8gZXNjYXBlIGZyb20gdGhl IHNlcnZpY2UgcHJvdmlkZXIgbmV0d29ya3MgZHVlIHRvDQo+ID4gPiA+IG1pc2NvbmZpZ3VhdGlv biBvciBwYWNrZXQNCj4gPiA+IGVycm9ycy4NCj4gPiA+ID4NCj4gPiA+ID4gSSB0aGluayBpdCB3 b3VsZCBiZSBiZXR0ZXIgdG8gZGVzY3JpYmUgdGhlIE9BTSBjb250cm9sIGxvb3AgaW4NCj4gPiA+ ID4gKHNvbWUpIG1vcmUgZGV0YWlsLCByYXRoZXIgdGhhbiBwb2ludGluZyB0byBSRkMzOTg1LCB3 aGljaCBkb2Vzbid0DQo+ID4gPiA+IGhhdmUgYSB3aG9sZSBsb3Qgb2YgZGV0YWlsIGVpdGhlci4g QWxzbyBiZWNhdXNlIHRoZSBhZGRpbmcgb2YNCj4gPiA+ID4gZmlyZXdhbGwgcnVsZXMgcmVxdWly ZXMgYW4gT0FNIGhvb2suDQo+ID4gPiA+DQo+ID4gPiA+IFNpbmNlIFNUUk9OR0xZIFJFQ09NTUVO REVEIGlzIG5vdCBhbiBSRkMyMTE5IHRlcm0gYW5kDQo+ID4gPiBSRUNPTU1FTkRFRCBpcw0KPiA+ ID4gPiB0b28gd2VhaywgSSdkIHN1Z2dlc3QgdG8gY2hhbmdlIHRoaXMgdG8gTVVTVC4NCj4gPiA+ ID4NCj4gPiA+ID4gRmluYWxseSwgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHNob3VsZCBi ZSBwcm9taW5lbnRseSBtYWRlIGluDQo+ID4gPiA+IHRoZSBhYnN0cmFjdCwgaW50cm9kdWN0aW9u LCBldGMuDQo+ID4gPiA+DQo+ID4gPiA+IExhcnMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBs c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0K From xuxiaohu@huawei.com Thu Jan 23 17:01:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25121A046F for ; Thu, 23 Jan 2014 17:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 keXBUYvO0N46 for ; Thu, 23 Jan 2014 17:00:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 740641A025A for ; Thu, 23 Jan 2014 17:00:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAJ12934; Fri, 24 Jan 2014 01:00:54 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 01:00:47 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 01:00:52 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 09:00:45 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "Alexander.Vainshtein@ecitele.com" , "lars@netapp.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiOAAIGV4IAASynFgAB+v4CAAAUDQYAAAhRg Date: Fri, 24 Jan 2014 01:00:45 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824784D@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082477E6@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg?= =?gb2312?b?dG8gUHJvcG9zZWQgU3RhbmRhcmQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 01:01:00 -0000 V2UgYXJlIHRhbGtpbmcgYWJvdXQgdXNpbmcgVURQIGFzIGEgdHVubmVsIGZvciBNUExTIHRyYWZm aWMuIFNvIHdoeSBjYW4ndCBhbGxvdyB0aGUgVURQIHR1bm5lbCB0byB1c2UgemVybyBjaGVja3N1 bXMgZm9yIHBlcmZvcm1hbmNlLCB3aGljaCBpcyB0aGUgcmVjb21tZW5kYXRpb24gZnJvbSBSRkM2 OTM1Lg0KDQpYaWFvaHUNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBsLndvb2RA c3VycmV5LmFjLnVrIFttYWlsdG86bC53b29kQHN1cnJleS5hYy51a10NCj4gt6LLzcqxvOQ6IDIw MTTE6jHUwjI0yNUgODo0OA0KPiDK1bz+yMs6IFh1eGlhb2h1OyBBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQo+ILOty806IGpvZWxqYUBib2d1cy5jb207 IG1wbHNAaWV0Zi5vcmcNCj4g1vfM4jogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRm LW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUw0KPiBpbiBVRFApIHRvIFBy b3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiBSRkM2OTM1IHdhcyB3cml0dGVuIGZyb20gYSB0dW5uZWxs aW5nIHBlcnNwZWN0aXZlLCB0byBhbGxvdyB0dW5uZWxsaW5nIHRvIHVzZQ0KPiB6ZXJvIGNoZWNr c3VtcyBmb3IgcGVyZm9ybWFuY2UsIGFuZCBhbmFseXNlZCByaXNrcyB0byB0aGUgdHVubmVsIHRy YWZmaWMgLSBidXQNCj4gbm90IHRvIG90aGVyIHVzZXJzLg0KPiANCj4gICAgIldoaWxlIHRoZSBt ZXRob2RzIGRvDQo+ICAgIG5vdCBndWFyYW50ZWUgY29ycmVjdG5lc3MsIHRoZXkgY2FuIHJlZHVj ZSB0aGUgcmlza3Mgb2YgcmVsYXhpbmcgdGhlDQo+ICAgIFVEUCBjaGVja3N1bSByZXF1aXJlbWVu dCBmb3IgYSB0dW5uZWwgYXBwbGljYXRpb24gdXNpbmcgSVB2Ni4iDQo+IA0KPiBSaXNrcyB0byBv dGhlciBhcHBsaWNhdGlvbnMgYXJlIG5vdCBhc3Nlc3NlZCwgYW5kIG5vdCBzdGF0ZWQuDQo+IA0K PiANCj4gTGxveWQgV29vZA0KPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogWHV4aWFvaHUgW3h1eGlh b2h1QGh1YXdlaS5jb21dDQo+IFNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwMDozNA0KPiBUbzogV29v ZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTsNCj4gbGFyc0BuZXRhcHAuY29tDQo+IENjOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYu b3JnDQo+IFN1YmplY3Q6ILTwuLQ6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMt aW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcNCj4gTVBMUyBpbiBVRFApIHRvIFByb3Bvc2Vk IFN0YW5kYXJkDQo+IA0KPiBJdCBzZWVtcyB0aGF0IHlvdSBhcmUgYWdhaW5zdCBSRkM2OTM1IGFu ZCBSRkM2OTM2LCByaWdodD8NCj4gDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLdPKvP7Urbz+LS0t LS0NCj4gPiC3orz+yMs6IGwud29vZEBzdXJyZXkuYWMudWsgW21haWx0bzpsLndvb2RAc3VycmV5 LmFjLnVrXQ0KPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyNMjVIDE6MTgNCj4gPiDK1bz+yMs6IFh1 eGlhb2h1OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29t DQo+ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+INb3zOI6IFJF OiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4g KEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4NCj4g PiB0aGUgdGV4dCBpcyBub3Qgc2F0aXNmYWN0b3J5LiBuZXZlciByZWNvbW1lbmQgc2V0dGluZyB0 byB6ZXJvLCBhcyB0aGF0DQo+ID4gcG9zZXMgYSByaXNrIHRvIHlvdXIgYW5kIHRvIG90aGVyIHRy YWZmaWMuIFN1Z2dlc3RlZCB0ZXh0Og0KPiA+ICoqKg0KPiA+IFRoZSBVRFAgY2hlY2tzdW0gU0hP VUxEIGJlIHVzZWQgdG8gcHJvdGVjdCB0aGUgcGF5bG9hZCBhbmQgZW5zdXJlDQo+ID4gY29ycmVj dCBkZW11bHRpcGxleGluZyBhbmQgZGVsaXZlcnkgdG8gdGhlIHR1bm5lbCwgYW5kIG5vdCB0byBv dGhlcg0KPiA+IFVEUCBkZXN0aW5hdGlvbnMsIGJ5IHByb3RlY3RpbmcgdGhlIFVEUCBwc2V1ZG9o ZWFkZXIuDQo+ID4gVXNlIG9mIGEgemVybyBVRFAgY2hlY2tzdW0gaXMgTk9UIFJFQ09NTUVOREVE LCBldmVuIHdoZW4gZGVzaXJlZCBmb3INCj4gPiBwZXJmb3JtYW5jZSBvciBuZWNlc3NpdGF0ZWQg YnkgaW1wbGVtZW50YXRpb24gcmVhc29ucywgZm9yIHRoZSByZWFzb25zDQo+ID4gb3V0bGluZWQg aW4gW1JGQzY5MzZdIHNlY3Rpb24gMy4NCj4gPg0KPiA+IFVEUC1MaXRlIFtSRkMzODI4XSBjYW4g cHJvdmlkZSBhIGRlbXVsdGlwbGV4aW5nIGNoZWNrIGFuZCBNUExTIHN0YWNrDQo+ID4gaW50ZWdy aXR5IGNoZWNrIHdoaWxlIGF2b2lkaW5nIHRoZSBvdmVyaGVhZCBvZiBjb21wdXRpbmcgYW4gaW50 ZWdyaXR5DQo+ID4gY2hlY2sgb3ZlciBhIHR1bm5lbGxlZCBmcmFtZSB0aGF0IGhhcyBpdHMgb3du IGludGVncml0eSBjaGVjay4NCj4gPiAqKioNCj4gPg0KPiA+IExsb3lkIFdvb2QNCj4gPiBodHRw Oi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+IEZyb206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiA+ IFNlbnQ6IDIzIEphbnVhcnkgMjAxNCAxMjozNQ0KPiA+IFRvOiBXb29kIEwgIERyIChFbGVjdHJv bmljIEVuZyk7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0KPiA+IGxhcnNAbmV0 YXBwLmNvbQ0KPiA+IENjOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4gU3Vi amVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4 dD4NCj4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQN Cj4gPg0KPiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gPiC3orz+yMs6IGwud29vZEBzdXJy ZXkuYWMudWsgW21haWx0bzpsLndvb2RAc3VycmV5LmFjLnVrXQ0KPiA+ID4gt6LLzcqxvOQ6IDIw MTTE6jHUwjIzyNUgMTI6NDQNCj4gPiA+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5ldGFwcC5jb20NCj4gPiA+ILOty806IGpvZWxqYUBi b2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxs OiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiAoRW5jYXBzdWxhdGluZyBN UExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+DQo+ID4gPiBTYXNoYQ0KPiA+ ID4NCj4gPiA+ID4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlz c3VlIGJlY2F1c2UgbmF0aXZlDQo+ID4gPiA+IE1QTFMgZG9lcyBub3QgaGF2ZSBhbnl0aGluZyBs aWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFyZSBjYXNlcw0KPiA+ID4gPiB3aGVyZSBwYWNrZXRz IGFyZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKQ0KPiA+ID4NCj4gPiA+IFNvIHlvdSBh ZG1pdCB0aGF0IHBhY2tldHMgY2FuIGJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMgLSBh DQo+ID4gPiBjaGVjayB0aGF0IGNhbiBvbmx5IGJlIGNhdWdodCBieSBhbiBlbmQtdG8tZW5kIGNo ZWNrLCBhIGNvcnJ1cHRpb24NCj4gPiA+IHRoYXQgY2FuIGxlYWQgdG8gdGhlIHByb2JsZW1zIGRl dGFpbGVkIGluIFJGQyA2OTM2IHNlY3Rpb24gMyAtIGFuZA0KPiA+ID4gdGhlbiB5b3Ugc2F5IGl0 J3MgYSBub24taXNzdWUgYmVjYXVzZSB0aGlzIGRvZXNuJ3QgYWZmZWN0IG5hdGl2ZQ0KPiA+ID4g TVBMUy4gQnV0IHdlJ3JlDQo+ID4gbm90IGRvaW5nIG5hdGl2ZSBNUExTIGhlcmUuDQo+ID4gPiBX ZSdyZSBkb2luZyBNUExTIG92ZXIgVURQLg0KPiA+ID4NCj4gPiA+IGRyYWZ0LWlldGYtbXBscy1p bi11ZHAtMDQudHh0IGlzIGFib3V0IHR1bm5lbGxpbmcgTVBMUyBpbiBVRFAuIEl0J3MgYW4gaXNz dWUuDQo+ID4gPiBQbGVhc2UgcmVhZCB0aGUgb3RoZXIgMTUwIG1lc3NhZ2VzIHRoYXQgeW91IHJl ZmVyIHRvLg0KPiA+DQo+ID4gSGkgTGxveWQsDQo+ID4NCj4gPiBUaGUgZHJhZnQgZG9lc24ndCBy ZXF1aXJlIHRoZSBJUHY2IFVEUCBjaGVja3N1bSB0byBiZSBzZXQgdG8gemVybyByZWdhcmRsZXNz Lg0KPiA+IFNlZSB0aGUgZm9sbG93aW5nIHRleHQgcXVvdGVkIGZyb20gdGhhdCBkcmFmdDoNCj4g Pg0KPiA+IFVEUCBDaGVja3N1bQ0KPiA+DQo+ID4gVGhlIHVzYWdlIG9mIHRoaXMgZmllbGQgaXMg aW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBjdXJyZW50IFVEUA0KPiA+IHNwZWNpZmljYXRpb24gW1JG Qzc2OF0uIFRvIHNpbXBsaWZ5IHRoZSBvcGVyYXRpb24gb24gdGhlIGRlY2Fwc3VsYXRvciwNCj4g PiB0aGlzIGZpZWxkIGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGluIElQdjQgVURQ IGVuY2Fwc3VsYXRpb24NCj4gPiBjYXNlLiBJbiB0aGUgSVB2NiBVRFAgZW5jYXBzdWxhdGlvbiBj YXNlLCBpZiBhcHByb3ByaWF0ZSBhY2NvcmRpbmcgdG8NCj4gPiB0aGUgcmVxdWlyZW1lbnRzIGRl ZmluZWQgaW4gW1JGQzY5MzVdIFtSRkM2OTM2XSwgdGhpcyBmaWVsZCBpcyBhbHNvDQo+IFJFQ09N TUVOREVEIHRvIGJlIHNldCB0byB6ZXJvLg0KPiA+IFNwZWNpZmljYWxseSwgaWYgdGhlIE1QTFMg cGF5bG9hZCBpcyBJbnRlcm5ldCBQcm90b2NvbCAoSVB2NCBvciBJUHY2KQ0KPiA+IHBhY2tldHMs IGl0IGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIHdoZW4gdGhlIGlubmVyIHBhY2tl dA0KPiA+IGludGVncml0eSBjaGVja3MgaXMgYXZhaWxhYmxlLiBJbiBhZGRpdGlvbiwgaWYgdGhl IE1QTFMgcGF5bG9hZCBpcw0KPiA+IG5vbi1JUCBwYWNrZXQgd2hpY2ggaXMgc3BlY2lmaWNhbGx5 IGRlc2lnbmVkIGZvciB0cmFuc21pc3Npb24gb3ZlciBhDQo+ID4gbG93ZXIgbGF5ZXIgdGhhdCBk b2VzIG5vdCBwcm92aWRlIGEgcGFja2V0IGludGVncml0eSBndWFyYW50ZWUsIGl0IGlzDQo+ID4g UkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gYXMgd2VsbC4gT3RoZXJ3aXNlLCB1c2luZyB6 ZXJvIGNoZWNrc3VtDQo+ID4gaXMgTk9UIFJFQ09NTUVOREVELiBOb3RlIHRoYXQgb3RoZXIgSVAg ZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMgZG8gbm90DQo+IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUg dHVubmVsIGhlYWRlci4NCj4gPg0KPiA+IElmIHlvdSBzdGlsbCBiZWxpZXZlIHRoZSBhYm92ZSB0 ZXh0IGlzIG5vdCBzYXRpc2ZhY3RvcnksIHBsZWFzZSBwcm92aWRlIHlvdXIgdGV4dC4NCj4gPg0K PiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+ID4gTGxveWQgV29vZA0KPiA+ ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRnJvbTogbXBscyBbbXBscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNCj4gPiA+IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0K PiA+ID4gU2VudDogMjMgSmFudWFyeSAyMDE0IDAzOjE2DQo+ID4gPiBUbzogQWxleGFuZGVyIFZh aW5zaHRlaW47IEVnZ2VydCwgTGFycw0KPiA+ID4gQ2M6IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRm Lm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1w bHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQ cm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+IEhpDQo+ID4gPg0KPiA+ID4gPiAtLS0tLdPK vP7Urbz+LS0tLS0NCj4gPiA+ID4gt6K8/sjLOiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPiA+ID4g PiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ID4gPiC3osvN yrG85DogMjAxNMTqMdTCMjLI1SAxOTowNQ0KPiA+ID4gPiDK1bz+yMs6IEVnZ2VydCwgTGFycw0K PiA+ID4gPiCzrcvNOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1DQo+ID4g PiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0w NC50eHQ+DQo+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBT dGFuZGFyZA0KPiA+ID4gPg0KPiA+ID4gPiBMYXJzIGFuZCBhbGwsDQo+ID4gPiA+IExhc3QgdGlt ZSBJJ3ZlIGNvdW50ZWQgdGhlIElFVEYgTEMgdGhyZWFkIG9uIHRoaXMgZHJhZnQgaGFzIG1vcmUN Cj4gPiA+ID4gdGhhbg0KPiA+ID4gPiAxNTAgbWVzc2FnZXMgaW4gaXQsIGFuZCBpdCBzZWVtcyB0 aGF0IG9uIHNvbWUgaXNzdWVzIChjb25nZXN0aW9uDQo+ID4gPiA+IGNvbnRyb2wgYW5kIFVEUA0K PiA+ID4gPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyByb3VuZCB0aGUgbXVsYmVycnkgYnVzaC4N Cj4gPiA+ID4NCj4gPiA+ID4gSU1ITyBhbmQgRldJVzoNCj4gPiA+ID4gLSBVRFAgY2hlY2tzdW1z IChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJlY2F1c2UgbmF0aXZlDQo+ID4gPiA+ IE1QTFMgZG9lcyBub3QgaGF2ZSBhbnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFy ZSBjYXNlcw0KPiA+ID4gPiB3aGVyZSBwYWNrZXRzIGFyZSBjb3JydXB0ZWQgd2l0aGluIHRoZSBy b3V0ZXJzKSwgYnV0IHNvIGZhciBpdCBkaWQNCj4gPiA+ID4gbm90IHByZXZlbnQgTVBMUyBkZXBs b3ltZW50LiBUaGVyZSBpcywgZS5nLiwgUkZDIDQ3MjAgZm9yIEZDUw0KPiA+ID4gPiByZXRlbnRp b24gaW4gUFdzLCBidXQgSSBkb3VidCBpdCBpcyB3aWRlbHkgaW1wbGVtZW50ZWQgYW5kDQo+ID4g PiA+IGRlcGxveWVkICh3b3VsZCBiZSBuaWNlIHRvDQo+ID4gPiBrbm93KS4NCj4gPiA+ID4gLSBF MkUgY29uZ2VzdGlvbiBjb250cm9sIChyZWdhcmRsZXNzIG9mIGl0cyBpbXBsaWNhdGlvbnMpIHNp bXBseQ0KPiA+ID4gPiBjYW5ub3QgYmUgYWRkZWQgdG8gdGhpcyBwcm90b2NvbCB3aXRob3V0IHNv bWUgbWFqb3IgY2hhbmdlcy4gQQ0KPiA+ID4gPiBzaG9ydCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVu dCBleHBsYWluaW5nIHRoYXQgc2hvdWxkIHN1ZmZpY2UgSU1PLg0KPiA+ID4NCj4gPiA+IEhpIFNh c2hhLA0KPiA+ID4NCj4gPiA+IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHBvaW50cy4NCj4gPiA+ DQo+ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiBYaWFvaHUNCj4gPiA+DQo+ID4gPiA+IE15IDJj LA0KPiA+ID4gPiAgICAgICAgU2FzaGENCj4gPiA+ID4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tDQo+ID4gPiA+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4gPiA+ID4NCj4g PiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IG1wbHMg W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFZ2dlcnQsDQo+ID4g PiA+ID4gTGFycw0KPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMiwgMjAxNCAx MjoyMyBQTQ0KPiA+ID4gPiA+IFRvOiBYdXhpYW9odQ0KPiA+ID4gPiA+IENjOiBKb2VsIEphZWdn bGk7IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2Fs bDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiA+IChFbmNhcHN1bGF0 aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gSGksDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPbiAyMDE0LTEtMjIsIGF0IDExOjEyLCBYdXhp YW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4gPiBJIHdvbmRlciB3 aGV0aGVyIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBPSyB0byB5b3U6DQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gU2luY2UgdGhlIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24gY2F1c2VzIE1QTFMg cGFja2V0cyB0byBiZQ0KPiA+ID4gPiA+IGZvcndhcmRlZCB0aHJvdWdoICJVRFAgdHVubmVscyIs IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wNCj4gPiA+ID4gPiBndWlkZWxpbmVzIGZvciBVRFAgdHVu bmVscyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjMgb2YNCj4gPiA+ID4gPiBbUkZDNTQwNV0g U0hPVUxEIGJlDQo+ID4gPiBmb2xsb3dlZC4NCj4gPiA+ID4gPiBTcGVjaWZpY2FsbHksIE1QTFMg Y2FuIGNhcnJ5IGEgbnVtYmVyIG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMgcGF5bG9hZHMuDQo+ ID4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFm ZmljIHRoYXQgaXMNCj4gPiA+ID4gPiBrbm93biBhdCBjb25maWd1cmF0aW9uIHRpbWUgdG8gYmUg SVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUgVURQIHR1 bm5lbCBTSE9VTEQgTk9UIGVtcGxveSBpdHMgb3duDQo+ID4gPiA+ID4gY29uZ2VzdGlvbiBjb250 cm9sIG1lY2hhbmlzbSwgYmVjYXVzZSBjb25nZXN0aW9uIGxvc3NlcyBvZg0KPiA+ID4gPiA+IHR1 bm5lbGVkIHRyYWZmaWMgd2lsbCB0cmlnZ2VyIGFuIGNvbmdlc3Rpb24gcmVzcG9uc2UgYXQgdGhl DQo+ID4gPiA+ID4gb3JpZ2luYWwgc2VuZGVycyBvZiB0aGUgdHVubmVsZWQNCj4gPiB0cmFmZmlj Lg0KPiA+ID4gPiA+IFdoZW4gYW4gVURQIHR1bm5lbCBpcyB1c2VkIGZvciBNUExTIHBheWxvYWQg dHJhZmZpYyB0aGF0IGlzDQo+ID4gPiA+ID4ga25vd24gYXQgY29uZmlndXJhdGlvbiB0aW1lIG5v dCB0byBiZSBJUC1iYXNlZCBhbmQNCj4gPiA+ID4gPiBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRo ZSBVRFAgdHVubmVsIFNIT1VMRCBlbXBsb3kgYW4NCj4gPiA+ID4gPiBhcHByb3ByaWF0ZSBjb25n ZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIGFzIGRlc2NyaWJlZCBpbg0KPiA+ID4gPiA+IFtSRkMz OTg1XS4gTm90ZSB0aGF0IGl0IFNUUk9OR0xZIFJFQ09NTUVOREVEIHRvIGRlcGxveSBzdWNoDQo+ ID4gPiA+ID4gZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IG9ubHkgd2l0aGluIGEgU1AgbmV0d29y ayBvciBuZXR3b3JrcyBvZg0KPiA+ID4gPiA+IGFuIGFkamFjZW50IHNldCBvZiBjby1vcGVyYXRp bmcgU1BzLCByYXRoZXIgdGhhbiBvdmVyIHRoZQ0KPiA+ID4gSW50ZXJuZXQuDQo+ID4gPiA+ID4g RnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3VsZCBiZSBhZGRlZCB0byBibG9jayB0cmFm ZmljDQo+ID4gPiA+ID4gd2l0aCB0aGUgVURQIHBvcnQgbnVtYmVyIGZvciBNUExTIG92ZXIgVURQ IHRvIHByZXZlbnQgTVBMUyBvdmVyDQo+ID4gPiA+ID4gVURQIHBhY2tldHMgdG8gZXNjYXBlIGZy b20gdGhlIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29ya3MgZHVlIHRvDQo+ID4gPiA+ID4gbWlzY29u ZmlndWF0aW9uIG9yIHBhY2tldA0KPiA+ID4gPiBlcnJvcnMuDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBkZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wg bG9vcCBpbg0KPiA+ID4gPiA+IChzb21lKSBtb3JlIGRldGFpbCwgcmF0aGVyIHRoYW4gcG9pbnRp bmcgdG8gUkZDMzk4NSwgd2hpY2gNCj4gPiA+ID4gPiBkb2Vzbid0IGhhdmUgYSB3aG9sZSBsb3Qg b2YgZGV0YWlsIGVpdGhlci4gQWxzbyBiZWNhdXNlIHRoZQ0KPiA+ID4gPiA+IGFkZGluZyBvZiBm aXJld2FsbCBydWxlcyByZXF1aXJlcyBhbiBPQU0gaG9vay4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IFNpbmNlIFNUUk9OR0xZIFJFQ09NTUVOREVEIGlzIG5vdCBhbiBSRkMyMTE5IHRlcm0gYW5kDQo+ ID4gPiA+IFJFQ09NTUVOREVEIGlzDQo+ID4gPiA+ID4gdG9vIHdlYWssIEknZCBzdWdnZXN0IHRv IGNoYW5nZSB0aGlzIHRvIE1VU1QuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBGaW5hbGx5LCB0aGUg YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgc2hvdWxkIGJlIHByb21pbmVudGx5IG1hZGUNCj4gPiA+ ID4gPiBpbiB0aGUgYWJzdHJhY3QsIGludHJvZHVjdGlvbiwgZXRjLg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gTGFycw0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gPiBtcGxzQGlldGYub3JnDQo+ ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From l.wood@surrey.ac.uk Thu Jan 23 17:29:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BBB1A015F for ; Thu, 23 Jan 2014 17:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.889 X-Spam-Level: X-Spam-Status: No, score=0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 DL_bTz37jGd7 for ; Thu, 23 Jan 2014 17:29:32 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) by ietfa.amsl.com (Postfix) with ESMTP id 9259C1A017D for ; Thu, 23 Jan 2014 17:29:31 -0800 (PST) Received: from [195.245.231.67:21164] by server-16.bemta-5.messagelabs.com id D8/D7-11843-AF1C1E25; Fri, 24 Jan 2014 01:29:30 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-6.tower-82.messagelabs.com!1390526969!34264082!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15239 invoked from network); 24 Jan 2014 01:29:29 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-6.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jan 2014 01:29:29 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Fri, 24 Jan 2014 01:29:28 +0000 From: To: , , Date: Fri, 24 Jan 2014 01:26:13 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiOAAIGV4IAASynFgAB+v4CAAAUDQYAAAhRggAAIfvs= Message-ID: <290E20B455C66743BE178C5C84F1240847E63346E8@EXMB01CMS.surrey.ac.uk> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082477E6@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824784D@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824784D@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 01:29:35 -0000 Rm9yIHRoZSByZWFzb25zIG91dGxpbmVkIGluIFJGQzY5MzYgc2VjdGlvbiAzLCB3aGljaCBJIGNp dGVkLCBhbmQgZm9yIHRoZSBkYW5nZXIgdG8gb3RoZXIgdHJhZmZpYywgd2hpY2ggd2UgaGF2ZSBk aXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQuDQoNCkkgcXVvdGUgUkZDMzkzNjoNCg0KIEN1cnJlbnRs eSwgZm9yIHRoZSBnZW5lcmFsIEludGVybmV0LCB0aGVyZSBpcyBubyBldmlkZW5jZSB0aGF0DQog Y29ycnVwdGlvbiBpcyByYXJlLCBub3IgaXMgdGhlcmUgZXZpZGVuY2UgdGhhdCBjb3JydXB0aW9u IGluIElQdjYgaXMNCiByYXJlLiBUaGVyZWZvcmUsIGl0IHNlZW1zIHBydWRlbnQgbm90IHRvIHJl bGF4IGNoZWNrcyBvbg0KIG1pc2RlbGl2ZXJ5Lg0KDQoNCkxsb3lkIFdvb2QNCmh0dHA6Ly9hYm91 dC5tZS9sbG95ZHdvb2QNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KU2VudDogMjQgSmFudWFyeSAy MDE0IDAxOjAwDQpUbzogV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpOyBBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQpDYzogam9lbGphQGJvZ3VzLmNv bTsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8g UHJvcG9zZWQgU3RhbmRhcmQNCg0KV2UgYXJlIHRhbGtpbmcgYWJvdXQgdXNpbmcgVURQIGFzIGEg dHVubmVsIGZvciBNUExTIHRyYWZmaWMuIFNvIHdoeSBjYW4ndCBhbGxvdyB0aGUgVURQIHR1bm5l bCB0byB1c2UgemVybyBjaGVja3N1bXMgZm9yIHBlcmZvcm1hbmNlLCB3aGljaCBpcyB0aGUgcmVj b21tZW5kYXRpb24gZnJvbSBSRkM2OTM1Lg0KDQpYaWFvaHUNCg0KPiAtLS0tLdPKvP7Urbz+LS0t LS0NCj4gt6K8/sjLOiBsLndvb2RAc3VycmV5LmFjLnVrIFttYWlsdG86bC53b29kQHN1cnJleS5h Yy51a10NCj4gt6LLzcqxvOQ6IDIwMTTE6jHUwjI0yNUgODo0OA0KPiDK1bz+yMs6IFh1eGlhb2h1 OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQo+ILOt y806IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4g1vfM4jogUkU6IFttcGxzXSBM YXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcg TVBMUw0KPiBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+DQo+IFJGQzY5MzUgd2FzIHdy aXR0ZW4gZnJvbSBhIHR1bm5lbGxpbmcgcGVyc3BlY3RpdmUsIHRvIGFsbG93IHR1bm5lbGxpbmcg dG8gdXNlDQo+IHplcm8gY2hlY2tzdW1zIGZvciBwZXJmb3JtYW5jZSwgYW5kIGFuYWx5c2VkIHJp c2tzIHRvIHRoZSB0dW5uZWwgdHJhZmZpYyAtIGJ1dA0KPiBub3QgdG8gb3RoZXIgdXNlcnMuDQo+ DQo+ICAgICJXaGlsZSB0aGUgbWV0aG9kcyBkbw0KPiAgICBub3QgZ3VhcmFudGVlIGNvcnJlY3Ru ZXNzLCB0aGV5IGNhbiByZWR1Y2UgdGhlIHJpc2tzIG9mIHJlbGF4aW5nIHRoZQ0KPiAgICBVRFAg Y2hlY2tzdW0gcmVxdWlyZW1lbnQgZm9yIGEgdHVubmVsIGFwcGxpY2F0aW9uIHVzaW5nIElQdjYu Ig0KPg0KPiBSaXNrcyB0byBvdGhlciBhcHBsaWNhdGlvbnMgYXJlIG5vdCBhc3Nlc3NlZCwgYW5k IG5vdCBzdGF0ZWQuDQo+DQo+DQo+IExsb3lkIFdvb2QNCj4gaHR0cDovL2Fib3V0Lm1lL2xsb3lk d29vZA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206 IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiBTZW50OiAyNCBKYW51YXJ5IDIwMTQg MDA6MzQNCj4gVG86IFdvb2QgTCAgRHIgKEVsZWN0cm9uaWMgRW5nKTsgQWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb207DQo+IGxhcnNAbmV0YXBwLmNvbQ0KPiBDYzogam9lbGphQGJvZ3Vz LmNvbTsgbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiC08Li0OiBbbXBsc10gTGFzdCBDYWxsOiA8 ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nDQo+IE1QTFMgaW4g VURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPg0KPiBJdCBzZWVtcyB0aGF0IHlvdSBhcmUgYWdh aW5zdCBSRkM2OTM1IGFuZCBSRkM2OTM2LCByaWdodD8NCj4NCj4gWGlhb2h1DQo+DQo+ID4gLS0t LS3Tyrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiBsLndvb2RAc3VycmV5LmFjLnVrIFttYWlsdG86 bC53b29kQHN1cnJleS5hYy51a10NCj4gPiC3osvNyrG85DogMjAxNMTqMdTCMjTI1SAxOjE4DQo+ ID4gytW8/sjLOiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxh cnNAbmV0YXBwLmNvbQ0KPiA+ILOty806IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcN Cj4gPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAt MDQudHh0Pg0KPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFu ZGFyZA0KPiA+DQo+ID4gdGhlIHRleHQgaXMgbm90IHNhdGlzZmFjdG9yeS4gbmV2ZXIgcmVjb21t ZW5kIHNldHRpbmcgdG8gemVybywgYXMgdGhhdA0KPiA+IHBvc2VzIGEgcmlzayB0byB5b3VyIGFu ZCB0byBvdGhlciB0cmFmZmljLiBTdWdnZXN0ZWQgdGV4dDoNCj4gPiAqKioNCj4gPiBUaGUgVURQ IGNoZWNrc3VtIFNIT1VMRCBiZSB1c2VkIHRvIHByb3RlY3QgdGhlIHBheWxvYWQgYW5kIGVuc3Vy ZQ0KPiA+IGNvcnJlY3QgZGVtdWx0aXBsZXhpbmcgYW5kIGRlbGl2ZXJ5IHRvIHRoZSB0dW5uZWws IGFuZCBub3QgdG8gb3RoZXINCj4gPiBVRFAgZGVzdGluYXRpb25zLCBieSBwcm90ZWN0aW5nIHRo ZSBVRFAgcHNldWRvaGVhZGVyLg0KPiA+IFVzZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzIE5P VCBSRUNPTU1FTkRFRCwgZXZlbiB3aGVuIGRlc2lyZWQgZm9yDQo+ID4gcGVyZm9ybWFuY2Ugb3Ig bmVjZXNzaXRhdGVkIGJ5IGltcGxlbWVudGF0aW9uIHJlYXNvbnMsIGZvciB0aGUgcmVhc29ucw0K PiA+IG91dGxpbmVkIGluIFtSRkM2OTM2XSBzZWN0aW9uIDMuDQo+ID4NCj4gPiBVRFAtTGl0ZSBb UkZDMzgyOF0gY2FuIHByb3ZpZGUgYSBkZW11bHRpcGxleGluZyBjaGVjayBhbmQgTVBMUyBzdGFj aw0KPiA+IGludGVncml0eSBjaGVjayB3aGlsZSBhdm9pZGluZyB0aGUgb3ZlcmhlYWQgb2YgY29t cHV0aW5nIGFuIGludGVncml0eQ0KPiA+IGNoZWNrIG92ZXIgYSB0dW5uZWxsZWQgZnJhbWUgdGhh dCBoYXMgaXRzIG93biBpbnRlZ3JpdHkgY2hlY2suDQo+ID4gKioqDQo+ID4NCj4gPiBMbG95ZCBX b29kDQo+ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBGcm9tOiBYdXhpYW9odSBbeHV4aWFvaHVAaHVh d2VpLmNvbV0NCj4gPiBTZW50OiAyMyBKYW51YXJ5IDIwMTQgMTI6MzUNCj4gPiBUbzogV29vZCBM ICBEciAoRWxlY3Ryb25pYyBFbmcpOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsN Cj4gPiBsYXJzQG5ldGFwcC5jb20NCj4gPiBDYzogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRm Lm9yZw0KPiA+IFN1YmplY3Q6IHJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxz LWluLXVkcC0wNC50eHQ+DQo+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bv c2VkIFN0YW5kYXJkDQo+ID4NCj4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ID4gt6K8/sjL OiBsLndvb2RAc3VycmV5LmFjLnVrIFttYWlsdG86bC53b29kQHN1cnJleS5hYy51a10NCj4gPiA+ ILeiy83KsbzkOiAyMDE0xOox1MIyM8jVIDEyOjQ0DQo+ID4gPiDK1bz+yMs6IFh1eGlhb2h1OyBB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQo+ID4gPiCz rcvNOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4gPiDW98ziOiBSRTogW21w bHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gKEVu Y2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPg0KPiA+ ID4gU2FzaGENCj4gPiA+DQo+ID4gPiA+IC0gVURQIGNoZWNrc3VtcyAob3IgbGFjayB0aGVyZW9m KSBpcyBhIG5vbi1pc3N1ZSBiZWNhdXNlIG5hdGl2ZQ0KPiA+ID4gPiBNUExTIGRvZXMgbm90IGhh dmUgYW55dGhpbmcgbGlrZSB0aGF0LiBBbmQgeWVzLCB0aGVyZSBhcmUgY2FzZXMNCj4gPiA+ID4g d2hlcmUgcGFja2V0cyBhcmUgY29ycnVwdGVkIHdpdGhpbiB0aGUgcm91dGVycykNCj4gPiA+DQo+ ID4gPiBTbyB5b3UgYWRtaXQgdGhhdCBwYWNrZXRzIGNhbiBiZSBjb3JydXB0ZWQgd2l0aGluIHRo ZSByb3V0ZXJzIC0gYQ0KPiA+ID4gY2hlY2sgdGhhdCBjYW4gb25seSBiZSBjYXVnaHQgYnkgYW4g ZW5kLXRvLWVuZCBjaGVjaywgYSBjb3JydXB0aW9uDQo+ID4gPiB0aGF0IGNhbiBsZWFkIHRvIHRo ZSBwcm9ibGVtcyBkZXRhaWxlZCBpbiBSRkMgNjkzNiBzZWN0aW9uIDMgLSBhbmQNCj4gPiA+IHRo ZW4geW91IHNheSBpdCdzIGEgbm9uLWlzc3VlIGJlY2F1c2UgdGhpcyBkb2Vzbid0IGFmZmVjdCBu YXRpdmUNCj4gPiA+IE1QTFMuIEJ1dCB3ZSdyZQ0KPiA+IG5vdCBkb2luZyBuYXRpdmUgTVBMUyBo ZXJlLg0KPiA+ID4gV2UncmUgZG9pbmcgTVBMUyBvdmVyIFVEUC4NCj4gPiA+DQo+ID4gPiBkcmFm dC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dCBpcyBhYm91dCB0dW5uZWxsaW5nIE1QTFMgaW4gVURQ LiBJdCdzIGFuIGlzc3VlLg0KPiA+ID4gUGxlYXNlIHJlYWQgdGhlIG90aGVyIDE1MCBtZXNzYWdl cyB0aGF0IHlvdSByZWZlciB0by4NCj4gPg0KPiA+IEhpIExsb3lkLA0KPiA+DQo+ID4gVGhlIGRy YWZ0IGRvZXNuJ3QgcmVxdWlyZSB0aGUgSVB2NiBVRFAgY2hlY2tzdW0gdG8gYmUgc2V0IHRvIHpl cm8gcmVnYXJkbGVzcy4NCj4gPiBTZWUgdGhlIGZvbGxvd2luZyB0ZXh0IHF1b3RlZCBmcm9tIHRo YXQgZHJhZnQ6DQo+ID4NCj4gPiBVRFAgQ2hlY2tzdW0NCj4gPg0KPiA+IFRoZSB1c2FnZSBvZiB0 aGlzIGZpZWxkIGlzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgY3VycmVudCBVRFANCj4gPiBzcGVj aWZpY2F0aW9uIFtSRkM3NjhdLiBUbyBzaW1wbGlmeSB0aGUgb3BlcmF0aW9uIG9uIHRoZSBkZWNh cHN1bGF0b3IsDQo+ID4gdGhpcyBmaWVsZCBpcyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVy byBpbiBJUHY0IFVEUCBlbmNhcHN1bGF0aW9uDQo+ID4gY2FzZS4gSW4gdGhlIElQdjYgVURQIGVu Y2Fwc3VsYXRpb24gY2FzZSwgaWYgYXBwcm9wcmlhdGUgYWNjb3JkaW5nIHRvDQo+ID4gdGhlIHJl cXVpcmVtZW50cyBkZWZpbmVkIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0sIHRoaXMgZmllbGQgaXMg YWxzbw0KPiBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVyby4NCj4gPiBTcGVjaWZpY2FsbHks IGlmIHRoZSBNUExTIHBheWxvYWQgaXMgSW50ZXJuZXQgUHJvdG9jb2wgKElQdjQgb3IgSVB2NikN Cj4gPiBwYWNrZXRzLCBpdCBpcyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyB3aGVuIHRo ZSBpbm5lciBwYWNrZXQNCj4gPiBpbnRlZ3JpdHkgY2hlY2tzIGlzIGF2YWlsYWJsZS4gSW4gYWRk aXRpb24sIGlmIHRoZSBNUExTIHBheWxvYWQgaXMNCj4gPiBub24tSVAgcGFja2V0IHdoaWNoIGlz IHNwZWNpZmljYWxseSBkZXNpZ25lZCBmb3IgdHJhbnNtaXNzaW9uIG92ZXIgYQ0KPiA+IGxvd2Vy IGxheWVyIHRoYXQgZG9lcyBub3QgcHJvdmlkZSBhIHBhY2tldCBpbnRlZ3JpdHkgZ3VhcmFudGVl LCBpdCBpcw0KPiA+IFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGFzIHdlbGwuIE90aGVy d2lzZSwgdXNpbmcgemVybyBjaGVja3N1bQ0KPiA+IGlzIE5PVCBSRUNPTU1FTkRFRC4gTm90ZSB0 aGF0IG90aGVyIElQIGVuY2Fwc3VsYXRpb25zIGZvciBNUExTIGRvIG5vdA0KPiBoYXZlIGEgY2hl Y2tzdW0gaW4gdGhlIHR1bm5lbCBoZWFkZXIuDQo+ID4NCj4gPiBJZiB5b3Ugc3RpbGwgYmVsaWV2 ZSB0aGUgYWJvdmUgdGV4dCBpcyBub3Qgc2F0aXNmYWN0b3J5LCBwbGVhc2UgcHJvdmlkZSB5b3Vy IHRleHQuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPiA+IExs b3lkIFdvb2QNCj4gPiA+IGh0dHA6Ly9hYm91dC5tZS9sbG95ZHdvb2QNCj4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IEZyb206IG1wbHMgW21wbHMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQo+ID4gPiBbeHV4aWFvaHVA aHVhd2VpLmNvbV0NCj4gPiA+IFNlbnQ6IDIzIEphbnVhcnkgMjAxNCAwMzoxNg0KPiA+ID4gVG86 IEFsZXhhbmRlciBWYWluc2h0ZWluOyBFZ2dlcnQsIExhcnMNCj4gPiA+IENjOiBKb2VsIEphZWdn bGk7IG1wbHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8 ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExT IGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+DQo+ID4gPiBIaQ0KPiA+ID4NCj4g PiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gPiA+ILeivP7IyzogQWxleGFuZGVyIFZhaW5z aHRlaW4NCj4gPiA+ID4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0N Cj4gPiA+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjIyyNUgMTk6MDUNCj4gPiA+ID4gytW8/sjLOiBF Z2dlcnQsIExhcnMNCj4gPiA+ID4gs63LzTogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnOyBY dXhpYW9odQ0KPiA+ID4gPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYt bXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg dG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4NCj4gPiA+ID4gTGFycyBhbmQgYWxsLA0KPiA+ ID4gPiBMYXN0IHRpbWUgSSd2ZSBjb3VudGVkIHRoZSBJRVRGIExDIHRocmVhZCBvbiB0aGlzIGRy YWZ0IGhhcyBtb3JlDQo+ID4gPiA+IHRoYW4NCj4gPiA+ID4gMTUwIG1lc3NhZ2VzIGluIGl0LCBh bmQgaXQgc2VlbXMgdGhhdCBvbiBzb21lIGlzc3VlcyAoY29uZ2VzdGlvbg0KPiA+ID4gPiBjb250 cm9sIGFuZCBVRFANCj4gPiA+ID4gY2hlY2tzdW1zKSB3ZSBhcmUgZ29pbmcgcm91bmQgdGhlIG11 bGJlcnJ5IGJ1c2guDQo+ID4gPiA+DQo+ID4gPiA+IElNSE8gYW5kIEZXSVc6DQo+ID4gPiA+IC0g VURQIGNoZWNrc3VtcyAob3IgbGFjayB0aGVyZW9mKSBpcyBhIG5vbi1pc3N1ZSBiZWNhdXNlIG5h dGl2ZQ0KPiA+ID4gPiBNUExTIGRvZXMgbm90IGhhdmUgYW55dGhpbmcgbGlrZSB0aGF0LiBBbmQg eWVzLCB0aGVyZSBhcmUgY2FzZXMNCj4gPiA+ID4gd2hlcmUgcGFja2V0cyBhcmUgY29ycnVwdGVk IHdpdGhpbiB0aGUgcm91dGVycyksIGJ1dCBzbyBmYXIgaXQgZGlkDQo+ID4gPiA+IG5vdCBwcmV2 ZW50IE1QTFMgZGVwbG95bWVudC4gVGhlcmUgaXMsIGUuZy4sIFJGQyA0NzIwIGZvciBGQ1MNCj4g PiA+ID4gcmV0ZW50aW9uIGluIFBXcywgYnV0IEkgZG91YnQgaXQgaXMgd2lkZWx5IGltcGxlbWVu dGVkIGFuZA0KPiA+ID4gPiBkZXBsb3llZCAod291bGQgYmUgbmljZSB0bw0KPiA+ID4ga25vdyku DQo+ID4gPiA+IC0gRTJFIGNvbmdlc3Rpb24gY29udHJvbCAocmVnYXJkbGVzcyBvZiBpdHMgaW1w bGljYXRpb25zKSBzaW1wbHkNCj4gPiA+ID4gY2Fubm90IGJlIGFkZGVkIHRvIHRoaXMgcHJvdG9j b2wgd2l0aG91dCBzb21lIG1ham9yIGNoYW5nZXMuIEENCj4gPiA+ID4gc2hvcnQgYXBwbGljYWJp bGl0eSBzdGF0ZW1lbnQgZXhwbGFpbmluZyB0aGF0IHNob3VsZCBzdWZmaWNlIElNTy4NCj4gPiA+ DQo+ID4gPiBIaSBTYXNoYSwNCj4gPiA+DQo+ID4gPiBJIGZ1bGx5IGFncmVlIHdpdGggeW91ciBw b2ludHMuDQo+ID4gPg0KPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gWGlhb2h1DQo+ID4gPg0K PiA+ID4gPiBNeSAyYywNCj4gPiA+ID4gICAgICAgIFNhc2hhDQo+ID4gPiA+IEVtYWlsOiBBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPiA+ID4gPiBNb2JpbGU6IDA1NC05MjY2MzAy DQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g PiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RWdnZXJ0LA0KPiA+ID4gPiA+IExhcnMNCj4gPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIEphbnVh cnkgMjIsIDIwMTQgMTI6MjMgUE0NCj4gPiA+ID4gPiBUbzogWHV4aWFvaHUNCj4gPiA+ID4gPiBD YzogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gU3ViamVjdDogUmU6IFtt cGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4g PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IEhpLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gMjAxNC0xLTIyLCBh dCAxMToxMiwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ID4gPiA+ ID4gSSB3b25kZXIgd2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0sgdG8geW91Og0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFNpbmNlIHRoZSBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9u IGNhdXNlcyBNUExTIHBhY2tldHMgdG8gYmUNCj4gPiA+ID4gPiBmb3J3YXJkZWQgdGhyb3VnaCAi VURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250cm9sDQo+ID4gPiA+ID4gZ3VpZGVsaW5l cyBmb3IgVURQIHR1bm5lbHMgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMS4zIG9mDQo+ID4gPiA+ ID4gW1JGQzU0MDVdIFNIT1VMRCBiZQ0KPiA+ID4gZm9sbG93ZWQuDQo+ID4gPiA+ID4gU3BlY2lm aWNhbGx5LCBNUExTIGNhbiBjYXJyeSBhIG51bWJlciBvZiBkaWZmZXJlbnQgcHJvdG9jb2xzIGFz IHBheWxvYWRzLg0KPiA+ID4gPiA+IFdoZW4gYW4gVURQIHR1bm5lbCBpcyB1c2VkIGZvciBNUExT IHBheWxvYWQgdHJhZmZpYyB0aGF0IGlzDQo+ID4gPiA+ID4ga25vd24gYXQgY29uZmlndXJhdGlv biB0aW1lIHRvIGJlIElQLWJhc2VkIGFuZA0KPiA+ID4gPiA+IGNvbmdlc3Rpb24tY29udHJvbGxl ZCwgdGhlIFVEUCB0dW5uZWwgU0hPVUxEIE5PVCBlbXBsb3kgaXRzIG93bg0KPiA+ID4gPiA+IGNv bmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20sIGJlY2F1c2UgY29uZ2VzdGlvbiBsb3NzZXMgb2YN Cj4gPiA+ID4gPiB0dW5uZWxlZCB0cmFmZmljIHdpbGwgdHJpZ2dlciBhbiBjb25nZXN0aW9uIHJl c3BvbnNlIGF0IHRoZQ0KPiA+ID4gPiA+IG9yaWdpbmFsIHNlbmRlcnMgb2YgdGhlIHR1bm5lbGVk DQo+ID4gdHJhZmZpYy4NCj4gPiA+ID4gPiBXaGVuIGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3Ig TVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcw0KPiA+ID4gPiA+IGtub3duIGF0IGNvbmZpZ3Vy YXRpb24gdGltZSBub3QgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gY29uZ2VzdGlvbi1j b250cm9sbGVkLCB0aGUgVURQIHR1bm5lbCBTSE9VTEQgZW1wbG95IGFuDQo+ID4gPiA+ID4gYXBw cm9wcmlhdGUgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSBhcyBkZXNjcmliZWQgaW4NCj4g PiA+ID4gPiBbUkZDMzk4NV0uIE5vdGUgdGhhdCBpdCBTVFJPTkdMWSBSRUNPTU1FTkRFRCB0byBk ZXBsb3kgc3VjaA0KPiA+ID4gPiA+IGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9neSBvbmx5IHdpdGhp biBhIFNQIG5ldHdvcmsgb3IgbmV0d29ya3Mgb2YNCj4gPiA+ID4gPiBhbiBhZGphY2VudCBzZXQg b2YgY28tb3BlcmF0aW5nIFNQcywgcmF0aGVyIHRoYW4gb3ZlciB0aGUNCj4gPiA+IEludGVybmV0 Lg0KPiA+ID4gPiA+IEZ1cnRoZXJtb3JlLCBwYWNrZXQgZmlsdGVycyBzaG91bGQgYmUgYWRkZWQg dG8gYmxvY2sgdHJhZmZpYw0KPiA+ID4gPiA+IHdpdGggdGhlIFVEUCBwb3J0IG51bWJlciBmb3Ig TVBMUyBvdmVyIFVEUCB0byBwcmV2ZW50IE1QTFMgb3Zlcg0KPiA+ID4gPiA+IFVEUCBwYWNrZXRz IHRvIGVzY2FwZSBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmtzIGR1ZSB0bw0KPiA+ ID4gPiA+IG1pc2NvbmZpZ3VhdGlvbiBvciBwYWNrZXQNCj4gPiA+ID4gZXJyb3JzLg0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVzY3JpYmUgdGhl IE9BTSBjb250cm9sIGxvb3AgaW4NCj4gPiA+ID4gPiAoc29tZSkgbW9yZSBkZXRhaWwsIHJhdGhl ciB0aGFuIHBvaW50aW5nIHRvIFJGQzM5ODUsIHdoaWNoDQo+ID4gPiA+ID4gZG9lc24ndCBoYXZl IGEgd2hvbGUgbG90IG9mIGRldGFpbCBlaXRoZXIuIEFsc28gYmVjYXVzZSB0aGUNCj4gPiA+ID4g PiBhZGRpbmcgb2YgZmlyZXdhbGwgcnVsZXMgcmVxdWlyZXMgYW4gT0FNIGhvb2suDQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBTaW5jZSBTVFJPTkdMWSBSRUNPTU1FTkRFRCBpcyBub3QgYW4gUkZDMjEx OSB0ZXJtIGFuZA0KPiA+ID4gPiBSRUNPTU1FTkRFRCBpcw0KPiA+ID4gPiA+IHRvbyB3ZWFrLCBJ J2Qgc3VnZ2VzdCB0byBjaGFuZ2UgdGhpcyB0byBNVVNULg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g RmluYWxseSwgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHNob3VsZCBiZSBwcm9taW5lbnRs eSBtYWRlDQo+ID4gPiA+ID4gaW4gdGhlIGFic3RyYWN0LCBpbnRyb2R1Y3Rpb24sIGV0Yy4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IExhcnMNCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+ID4gbXBs c0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQo= From xuxiaohu@huawei.com Thu Jan 23 17:36:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F931A017D for ; Thu, 23 Jan 2014 17:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 BOQzSbNAIKud for ; Thu, 23 Jan 2014 17:36:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A51A0111 for ; Thu, 23 Jan 2014 17:36:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAJ14523; Fri, 24 Jan 2014 01:36:31 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 01:36:25 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 01:36:30 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 09:36:25 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "Alexander.Vainshtein@ecitele.com" , "lars@netapp.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiOAAIGV4IAASynFgAB+v4CAAAUDQYAAAhRggAAIfvuAAAIPgA== Date: Fri, 24 Jan 2014 01:36:24 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824789C@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082477E6@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824784D@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E8@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346E8@EXMB01CMS.surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg?= =?gb2312?b?dG8gUHJvcG9zZWQgU3RhbmRhcmQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 01:36:37 -0000 SGksDQoNClNpbmNlIHlvdSBhcmUgbm90IGFnYWluc3QgUkZDNjkzNiBhbmQgUkZDNjkzNSwgaG93 IGFib3V0IG1ha2luZyB0aGUgZm9sbG93aW5nIGNoYW5nZToNCg0KT0xEOg0KDQpJbiB0aGUgSVB2 NiBVRFAgZW5jYXBzdWxhdGlvbiBjYXNlLCBpZiBhcHByb3ByaWF0ZSBhY2NvcmRpbmcgdG8gdGhl IHJlcXVpcmVtZW50cyBkZWZpbmVkIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0sIHRoaXMgZmllbGQg aXMgYWxzbyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVyby4gU3BlY2lmaWNhbGx5LCBpZiB0 aGUgTVBMUyBwYXlsb2FkIGlzIEludGVybmV0IFByb3RvY29sIChJUHY0IG9yIElQdjYpIHBhY2tl dHMsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIHdoZW4gdGhlIGlubmVyIHBh Y2tldCBpbnRlZ3JpdHkgY2hlY2tzIGlzIGF2YWlsYWJsZS4gSW4gYWRkaXRpb24sIGlmIHRoZSBN UExTIHBheWxvYWQgaXMgbm9uLUlQIHBhY2tldCB3aGljaCBpcyBzcGVjaWZpY2FsbHkgZGVzaWdu ZWQgZm9yIHRyYW5zbWlzc2lvbiBvdmVyIGEgbG93ZXIgbGF5ZXIgdGhhdCBkb2VzIG5vdCBwcm92 aWRlIGEgcGFja2V0IGludGVncml0eSBndWFyYW50ZWUsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGJl IHNldCB0byB6ZXJvIGFzIHdlbGwuIE90aGVyd2lzZSwgdXNpbmcgemVybyBjaGVja3N1bSBpcyBO T1QgUkVDT01NRU5ERUQuIE5vdGUgdGhhdCBvdGhlciBJUCBlbmNhcHN1bGF0aW9ucyBmb3IgTVBM UyBkbyBub3QgaGF2ZSBhIGNoZWNrc3VtIGluIHRoZSB0dW5uZWwgaGVhZGVyLg0KDQpORVc6DQoN CkluIHRoZSBJUHY2IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2UsIGFzIGZvciB3aGV0aGVyIG9yIG5v dCBpdCBpcyBzdWl0YWJsZSB0byB1c2UgdGhlIHplcm8tY2hlY2tzdW0gbm9kZSwgdGhlIHJlcXVp cmVtZW50cyBkZWZpbmVkIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0gU0hPVUxEIGJlIHN0cmljdGx5 IGZvbGxvd2VkLiBOb3RlIHRoYXQgb3RoZXIgSVAgZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMgZG8g bm90IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCg0KWGlhb2h1DQoNCj4g LS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRv Omwud29vZEBzdXJyZXkuYWMudWtdDQo+ILeiy83KsbzkOiAyMDE0xOox1MIyNMjVIDk6MjYNCj4g ytW8/sjLOiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNA bmV0YXBwLmNvbQ0KPiCzrcvNOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+INb3 zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+ IChFbmNhcHN1bGF0aW5nIE1QTFMNCj4gaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiAN Cj4gRm9yIHRoZSByZWFzb25zIG91dGxpbmVkIGluIFJGQzY5MzYgc2VjdGlvbiAzLCB3aGljaCBJ IGNpdGVkLCBhbmQgZm9yIHRoZSBkYW5nZXINCj4gdG8gb3RoZXIgdHJhZmZpYywgd2hpY2ggd2Ug aGF2ZSBkaXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQuDQo+IA0KPiBJIHF1b3RlIFJGQzM5MzY6DQo+ IA0KPiAgQ3VycmVudGx5LCBmb3IgdGhlIGdlbmVyYWwgSW50ZXJuZXQsIHRoZXJlIGlzIG5vIGV2 aWRlbmNlIHRoYXQgIGNvcnJ1cHRpb24gaXMNCj4gcmFyZSwgbm9yIGlzIHRoZXJlIGV2aWRlbmNl IHRoYXQgY29ycnVwdGlvbiBpbiBJUHY2IGlzICByYXJlLiBUaGVyZWZvcmUsIGl0IHNlZW1zDQo+ IHBydWRlbnQgbm90IHRvIHJlbGF4IGNoZWNrcyBvbiAgbWlzZGVsaXZlcnkuDQo+IA0KPiANCj4g TGxveWQgV29vZA0KPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1QGh1 YXdlaS5jb21dDQo+IFNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwMTowMA0KPiBUbzogV29vZCBMICBE ciAoRWxlY3Ryb25pYyBFbmcpOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsNCj4g bGFyc0BuZXRhcHAuY29tDQo+IENjOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ IFN1YmplY3Q6ILTwuLQ6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRw LTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcNCj4gTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5k YXJkDQo+IA0KPiBXZSBhcmUgdGFsa2luZyBhYm91dCB1c2luZyBVRFAgYXMgYSB0dW5uZWwgZm9y IE1QTFMgdHJhZmZpYy4gU28gd2h5IGNhbid0IGFsbG93DQo+IHRoZSBVRFAgdHVubmVsIHRvIHVz ZSB6ZXJvIGNoZWNrc3VtcyBmb3IgcGVyZm9ybWFuY2UsIHdoaWNoIGlzIHRoZQ0KPiByZWNvbW1l bmRhdGlvbiBmcm9tIFJGQzY5MzUuDQo+IA0KPiBYaWFvaHUNCj4gDQo+ID4gLS0tLS3Tyrz+1K28 /i0tLS0tDQo+ID4gt6K8/sjLOiBsLndvb2RAc3VycmV5LmFjLnVrIFttYWlsdG86bC53b29kQHN1 cnJleS5hYy51a10NCj4gPiC3osvNyrG85DogMjAxNMTqMdTCMjTI1SA4OjQ4DQo+ID4gytW8/sjL OiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBw LmNvbQ0KPiA+ILOty806IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiDW98zi OiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0K PiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ DQo+ID4gUkZDNjkzNSB3YXMgd3JpdHRlbiBmcm9tIGEgdHVubmVsbGluZyBwZXJzcGVjdGl2ZSwg dG8gYWxsb3cgdHVubmVsbGluZw0KPiA+IHRvIHVzZSB6ZXJvIGNoZWNrc3VtcyBmb3IgcGVyZm9y bWFuY2UsIGFuZCBhbmFseXNlZCByaXNrcyB0byB0aGUNCj4gPiB0dW5uZWwgdHJhZmZpYyAtIGJ1 dCBub3QgdG8gb3RoZXIgdXNlcnMuDQo+ID4NCj4gPiAgICAiV2hpbGUgdGhlIG1ldGhvZHMgZG8N Cj4gPiAgICBub3QgZ3VhcmFudGVlIGNvcnJlY3RuZXNzLCB0aGV5IGNhbiByZWR1Y2UgdGhlIHJp c2tzIG9mIHJlbGF4aW5nIHRoZQ0KPiA+ICAgIFVEUCBjaGVja3N1bSByZXF1aXJlbWVudCBmb3Ig YSB0dW5uZWwgYXBwbGljYXRpb24gdXNpbmcgSVB2Ni4iDQo+ID4NCj4gPiBSaXNrcyB0byBvdGhl ciBhcHBsaWNhdGlvbnMgYXJlIG5vdCBhc3Nlc3NlZCwgYW5kIG5vdCBzdGF0ZWQuDQo+ID4NCj4g Pg0KPiA+IExsb3lkIFdvb2QNCj4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206IFh1eGlhb2h1 IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwMDozNA0K PiA+IFRvOiBXb29kIEwgIERyIChFbGVjdHJvbmljIEVuZyk7IEFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tOw0KPiA+IGxhcnNAbmV0YXBwLmNvbQ0KPiA+IENjOiBqb2VsamFAYm9ndXMu Y29tOyBtcGxzQGlldGYub3JnDQo+ID4gU3ViamVjdDogtPC4tDogW21wbHNdIExhc3QgQ2FsbDog PGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMg aW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+DQo+ID4gSXQgc2VlbXMgdGhhdCB5b3Ug YXJlIGFnYWluc3QgUkZDNjkzNSBhbmQgUkZDNjkzNiwgcmlnaHQ/DQo+ID4NCj4gPiBYaWFvaHUN Cj4gPg0KPiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gPiC3orz+yMs6IGwud29vZEBzdXJy ZXkuYWMudWsgW21haWx0bzpsLndvb2RAc3VycmV5LmFjLnVrXQ0KPiA+ID4gt6LLzcqxvOQ6IDIw MTTE6jHUwjI0yNUgMToxOA0KPiA+ID4gytW8/sjLOiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBwLmNvbQ0KPiA+ID4gs63LzTogam9lbGphQGJv Z3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4g1vfM4jogUkU6IFttcGxzXSBMYXN0IENhbGw6 IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChFbmNhcHN1bGF0aW5nIE1Q TFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+IHRoZSB0ZXh0IGlz IG5vdCBzYXRpc2ZhY3RvcnkuIG5ldmVyIHJlY29tbWVuZCBzZXR0aW5nIHRvIHplcm8sIGFzDQo+ ID4gPiB0aGF0IHBvc2VzIGEgcmlzayB0byB5b3VyIGFuZCB0byBvdGhlciB0cmFmZmljLiBTdWdn ZXN0ZWQgdGV4dDoNCj4gPiA+ICoqKg0KPiA+ID4gVGhlIFVEUCBjaGVja3N1bSBTSE9VTEQgYmUg dXNlZCB0byBwcm90ZWN0IHRoZSBwYXlsb2FkIGFuZCBlbnN1cmUNCj4gPiA+IGNvcnJlY3QgZGVt dWx0aXBsZXhpbmcgYW5kIGRlbGl2ZXJ5IHRvIHRoZSB0dW5uZWwsIGFuZCBub3QgdG8gb3RoZXIN Cj4gPiA+IFVEUCBkZXN0aW5hdGlvbnMsIGJ5IHByb3RlY3RpbmcgdGhlIFVEUCBwc2V1ZG9oZWFk ZXIuDQo+ID4gPiBVc2Ugb2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQs IGV2ZW4gd2hlbiBkZXNpcmVkIGZvcg0KPiA+ID4gcGVyZm9ybWFuY2Ugb3IgbmVjZXNzaXRhdGVk IGJ5IGltcGxlbWVudGF0aW9uIHJlYXNvbnMsIGZvciB0aGUNCj4gPiA+IHJlYXNvbnMgb3V0bGlu ZWQgaW4gW1JGQzY5MzZdIHNlY3Rpb24gMy4NCj4gPiA+DQo+ID4gPiBVRFAtTGl0ZSBbUkZDMzgy OF0gY2FuIHByb3ZpZGUgYSBkZW11bHRpcGxleGluZyBjaGVjayBhbmQgTVBMUyBzdGFjaw0KPiA+ ID4gaW50ZWdyaXR5IGNoZWNrIHdoaWxlIGF2b2lkaW5nIHRoZSBvdmVyaGVhZCBvZiBjb21wdXRp bmcgYW4NCj4gPiA+IGludGVncml0eSBjaGVjayBvdmVyIGEgdHVubmVsbGVkIGZyYW1lIHRoYXQg aGFzIGl0cyBvd24gaW50ZWdyaXR5IGNoZWNrLg0KPiA+ID4gKioqDQo+ID4gPg0KPiA+ID4gTGxv eWQgV29vZA0KPiA+ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiA+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRnJvbTogWHV4aWFvaHUgW3h1 eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiBTZW50OiAyMyBKYW51YXJ5IDIwMTQgMTI6MzUNCj4g PiA+IFRvOiBXb29kIEwgIERyIChFbGVjdHJvbmljIEVuZyk7IEFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tOw0KPiA+ID4gbGFyc0BuZXRhcHAuY29tDQo+ID4gPiBDYzogam9lbGphQGJv Z3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENh bGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChFbmNhcHN1bGF0aW5n IE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+ID4gLS0tLS3T yrz+1K28/i0tLS0tDQo+ID4gPiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRv Omwud29vZEBzdXJyZXkuYWMudWtdDQo+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyM8jVIDEy OjQ0DQo+ID4gPiA+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tOyBsYXJzQG5ldGFwcC5jb20NCj4gPiA+ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsg bXBsc0BpZXRmLm9yZw0KPiA+ID4gPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGlu IFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4NCj4gPiA+ID4gU2FzaGENCj4gPiA+ ID4NCj4gPiA+ID4gPiAtIFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhlcmVvZikgaXMgYSBub24t aXNzdWUgYmVjYXVzZSBuYXRpdmUNCj4gPiA+ID4gPiBNUExTIGRvZXMgbm90IGhhdmUgYW55dGhp bmcgbGlrZSB0aGF0LiBBbmQgeWVzLCB0aGVyZSBhcmUgY2FzZXMNCj4gPiA+ID4gPiB3aGVyZSBw YWNrZXRzIGFyZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKQ0KPiA+ID4gPg0KPiA+ID4g PiBTbyB5b3UgYWRtaXQgdGhhdCBwYWNrZXRzIGNhbiBiZSBjb3JydXB0ZWQgd2l0aGluIHRoZSBy b3V0ZXJzIC0gYQ0KPiA+ID4gPiBjaGVjayB0aGF0IGNhbiBvbmx5IGJlIGNhdWdodCBieSBhbiBl bmQtdG8tZW5kIGNoZWNrLCBhIGNvcnJ1cHRpb24NCj4gPiA+ID4gdGhhdCBjYW4gbGVhZCB0byB0 aGUgcHJvYmxlbXMgZGV0YWlsZWQgaW4gUkZDIDY5MzYgc2VjdGlvbiAzIC0gYW5kDQo+ID4gPiA+ IHRoZW4geW91IHNheSBpdCdzIGEgbm9uLWlzc3VlIGJlY2F1c2UgdGhpcyBkb2Vzbid0IGFmZmVj dCBuYXRpdmUNCj4gPiA+ID4gTVBMUy4gQnV0IHdlJ3JlDQo+ID4gPiBub3QgZG9pbmcgbmF0aXZl IE1QTFMgaGVyZS4NCj4gPiA+ID4gV2UncmUgZG9pbmcgTVBMUyBvdmVyIFVEUC4NCj4gPiA+ID4N Cj4gPiA+ID4gZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQgaXMgYWJvdXQgdHVubmVsbGlu ZyBNUExTIGluIFVEUC4gSXQncyBhbiBpc3N1ZS4NCj4gPiA+ID4gUGxlYXNlIHJlYWQgdGhlIG90 aGVyIDE1MCBtZXNzYWdlcyB0aGF0IHlvdSByZWZlciB0by4NCj4gPiA+DQo+ID4gPiBIaSBMbG95 ZCwNCj4gPiA+DQo+ID4gPiBUaGUgZHJhZnQgZG9lc24ndCByZXF1aXJlIHRoZSBJUHY2IFVEUCBj aGVja3N1bSB0byBiZSBzZXQgdG8gemVybw0KPiByZWdhcmRsZXNzLg0KPiA+ID4gU2VlIHRoZSBm b2xsb3dpbmcgdGV4dCBxdW90ZWQgZnJvbSB0aGF0IGRyYWZ0Og0KPiA+ID4NCj4gPiA+IFVEUCBD aGVja3N1bQ0KPiA+ID4NCj4gPiA+IFRoZSB1c2FnZSBvZiB0aGlzIGZpZWxkIGlzIGluIGFjY29y ZGFuY2Ugd2l0aCB0aGUgY3VycmVudCBVRFANCj4gPiA+IHNwZWNpZmljYXRpb24gW1JGQzc2OF0u IFRvIHNpbXBsaWZ5IHRoZSBvcGVyYXRpb24gb24gdGhlDQo+ID4gPiBkZWNhcHN1bGF0b3IsIHRo aXMgZmllbGQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gaW4gSVB2NA0KPiA+ID4g VURQIGVuY2Fwc3VsYXRpb24gY2FzZS4gSW4gdGhlIElQdjYgVURQIGVuY2Fwc3VsYXRpb24gY2Fz ZSwgaWYNCj4gPiA+IGFwcHJvcHJpYXRlIGFjY29yZGluZyB0byB0aGUgcmVxdWlyZW1lbnRzIGRl ZmluZWQgaW4gW1JGQzY5MzVdDQo+ID4gPiBbUkZDNjkzNl0sIHRoaXMgZmllbGQgaXMgYWxzbw0K PiA+IFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvLg0KPiA+ID4gU3BlY2lmaWNhbGx5LCBp ZiB0aGUgTVBMUyBwYXlsb2FkIGlzIEludGVybmV0IFByb3RvY29sIChJUHY0IG9yDQo+ID4gPiBJ UHY2KSBwYWNrZXRzLCBpdCBpcyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyB3aGVuIHRo ZSBpbm5lcg0KPiA+ID4gcGFja2V0IGludGVncml0eSBjaGVja3MgaXMgYXZhaWxhYmxlLiBJbiBh ZGRpdGlvbiwgaWYgdGhlIE1QTFMNCj4gPiA+IHBheWxvYWQgaXMgbm9uLUlQIHBhY2tldCB3aGlj aCBpcyBzcGVjaWZpY2FsbHkgZGVzaWduZWQgZm9yDQo+ID4gPiB0cmFuc21pc3Npb24gb3ZlciBh IGxvd2VyIGxheWVyIHRoYXQgZG9lcyBub3QgcHJvdmlkZSBhIHBhY2tldA0KPiA+ID4gaW50ZWdy aXR5IGd1YXJhbnRlZSwgaXQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gYXMgd2Vs bC4NCj4gPiA+IE90aGVyd2lzZSwgdXNpbmcgemVybyBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5E RUQuIE5vdGUgdGhhdCBvdGhlcg0KPiA+ID4gSVAgZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMgZG8g bm90DQo+ID4gaGF2ZSBhIGNoZWNrc3VtIGluIHRoZSB0dW5uZWwgaGVhZGVyLg0KPiA+ID4NCj4g PiA+IElmIHlvdSBzdGlsbCBiZWxpZXZlIHRoZSBhYm92ZSB0ZXh0IGlzIG5vdCBzYXRpc2ZhY3Rv cnksIHBsZWFzZSBwcm92aWRlIHlvdXIgdGV4dC4NCj4gPiA+DQo+ID4gPiBCZXN0IHJlZ2FyZHMs DQo+ID4gPiBYaWFvaHUNCj4gPiA+DQo+ID4gPiA+IExsb3lkIFdvb2QNCj4gPiA+ID4gaHR0cDov L2Fib3V0Lm1lL2xsb3lkd29vZA0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPiA+IEZyb206IG1wbHMgW21wbHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFh1eGlhb2h1DQo+ID4gPiA+IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiA+ ID4gPiBTZW50OiAyMyBKYW51YXJ5IDIwMTQgMDM6MTYNCj4gPiA+ID4gVG86IEFsZXhhbmRlciBW YWluc2h0ZWluOyBFZ2dlcnQsIExhcnMNCj4gPiA+ID4gQ2M6IEpvZWwgSmFlZ2dsaTsgbXBsc0Bp ZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWll dGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVE UCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4NCj4gPiA+ID4gSGkNCj4gPiA+ID4NCj4g PiA+ID4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ID4gPiC3orz+yMs6IEFsZXhhbmRlciBW YWluc2h0ZWluDQo+ID4gPiA+ID4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbV0NCj4gPiA+ID4gPiC3osvNyrG85DogMjAxNMTqMdTCMjLI1SAxOTowNQ0KPiA+ID4gPiA+ IMrVvP7IyzogRWdnZXJ0LCBMYXJzDQo+ID4gPiA+ID4gs63LzTogSm9lbCBKYWVnZ2xpOyBtcGxz QGlldGYub3JnOyBYdXhpYW9odQ0KPiA+ID4gPiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxs OiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiA+ID4gKEVuY2Fwc3VsYXRp bmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBMYXJzIGFuZCBhbGwsDQo+ID4gPiA+ID4gTGFzdCB0aW1lIEkndmUgY291bnRlZCB0aGUgSUVU RiBMQyB0aHJlYWQgb24gdGhpcyBkcmFmdCBoYXMgbW9yZQ0KPiA+ID4gPiA+IHRoYW4NCj4gPiA+ ID4gPiAxNTAgbWVzc2FnZXMgaW4gaXQsIGFuZCBpdCBzZWVtcyB0aGF0IG9uIHNvbWUgaXNzdWVz IChjb25nZXN0aW9uDQo+ID4gPiA+ID4gY29udHJvbCBhbmQgVURQDQo+ID4gPiA+ID4gY2hlY2tz dW1zKSB3ZSBhcmUgZ29pbmcgcm91bmQgdGhlIG11bGJlcnJ5IGJ1c2guDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBJTUhPIGFuZCBGV0lXOg0KPiA+ID4gPiA+IC0gVURQIGNoZWNrc3VtcyAob3IgbGFj ayB0aGVyZW9mKSBpcyBhIG5vbi1pc3N1ZSBiZWNhdXNlIG5hdGl2ZQ0KPiA+ID4gPiA+IE1QTFMg ZG9lcyBub3QgaGF2ZSBhbnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFyZSBjYXNl cw0KPiA+ID4gPiA+IHdoZXJlIHBhY2tldHMgYXJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRl cnMpLCBidXQgc28gZmFyIGl0DQo+ID4gPiA+ID4gZGlkIG5vdCBwcmV2ZW50IE1QTFMgZGVwbG95 bWVudC4gVGhlcmUgaXMsIGUuZy4sIFJGQyA0NzIwIGZvcg0KPiA+ID4gPiA+IEZDUyByZXRlbnRp b24gaW4gUFdzLCBidXQgSSBkb3VidCBpdCBpcyB3aWRlbHkgaW1wbGVtZW50ZWQgYW5kDQo+ID4g PiA+ID4gZGVwbG95ZWQgKHdvdWxkIGJlIG5pY2UgdG8NCj4gPiA+ID4ga25vdykuDQo+ID4gPiA+ ID4gLSBFMkUgY29uZ2VzdGlvbiBjb250cm9sIChyZWdhcmRsZXNzIG9mIGl0cyBpbXBsaWNhdGlv bnMpIHNpbXBseQ0KPiA+ID4gPiA+IGNhbm5vdCBiZSBhZGRlZCB0byB0aGlzIHByb3RvY29sIHdp dGhvdXQgc29tZSBtYWpvciBjaGFuZ2VzLiBBDQo+ID4gPiA+ID4gc2hvcnQgYXBwbGljYWJpbGl0 eSBzdGF0ZW1lbnQgZXhwbGFpbmluZyB0aGF0IHNob3VsZCBzdWZmaWNlIElNTy4NCj4gPiA+ID4N Cj4gPiA+ID4gSGkgU2FzaGEsDQo+ID4gPiA+DQo+ID4gPiA+IEkgZnVsbHkgYWdyZWUgd2l0aCB5 b3VyIHBvaW50cy4NCj4gPiA+ID4NCj4gPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPiBYaWFv aHUNCj4gPiA+ID4NCj4gPiA+ID4gPiBNeSAyYywNCj4gPiA+ID4gPiAgICAgICAgU2FzaGENCj4g PiA+ID4gPiBFbWFpbDogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gPiA+ID4g PiBNb2JpbGU6IDA1NC05MjY2MzAyDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRWdnZXJ0LA0KPiA+ID4gPiA+ID4gTGFycw0KPiA+ ID4gPiA+ID4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIyLCAyMDE0IDEyOjIzIFBNDQo+ID4g PiA+ID4gPiBUbzogWHV4aWFvaHUNCj4gPiA+ID4gPiA+IENjOiBKb2VsIEphZWdnbGk7IG1wbHNA aWV0Zi5vcmcNCj4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJh ZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBN UExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiBIaSwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBPbiAyMDE0LTEtMjIsIGF0IDExOjEyLCBY dXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4gPiA+IEkgd29u ZGVyIHdoZXRoZXIgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIE9LIHRvIHlvdToNCj4gPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ID4gU2luY2UgdGhlIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24gY2F1 c2VzIE1QTFMgcGFja2V0cyB0bw0KPiA+ID4gPiA+ID4gPiBiZQ0KPiA+ID4gPiA+ID4gZm9yd2Fy ZGVkIHRocm91Z2ggIlVEUCB0dW5uZWxzIiwgdGhlIGNvbmdlc3Rpb24gY29udHJvbA0KPiA+ID4g PiA+ID4gZ3VpZGVsaW5lcyBmb3IgVURQIHR1bm5lbHMgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMu MS4zIG9mDQo+ID4gPiA+ID4gPiBbUkZDNTQwNV0gU0hPVUxEIGJlDQo+ID4gPiA+IGZvbGxvd2Vk Lg0KPiA+ID4gPiA+ID4gU3BlY2lmaWNhbGx5LCBNUExTIGNhbiBjYXJyeSBhIG51bWJlciBvZiBk aWZmZXJlbnQgcHJvdG9jb2xzIGFzDQo+IHBheWxvYWRzLg0KPiA+ID4gPiA+ID4gV2hlbiBhbiBV RFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFmZmljIHRoYXQgaXMNCj4gPiA+ ID4gPiA+IGtub3duIGF0IGNvbmZpZ3VyYXRpb24gdGltZSB0byBiZSBJUC1iYXNlZCBhbmQNCj4g PiA+ID4gPiA+IGNvbmdlc3Rpb24tY29udHJvbGxlZCwgdGhlIFVEUCB0dW5uZWwgU0hPVUxEIE5P VCBlbXBsb3kgaXRzDQo+ID4gPiA+ID4gPiBvd24gY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlz bSwgYmVjYXVzZSBjb25nZXN0aW9uIGxvc3NlcyBvZg0KPiA+ID4gPiA+ID4gdHVubmVsZWQgdHJh ZmZpYyB3aWxsIHRyaWdnZXIgYW4gY29uZ2VzdGlvbiByZXNwb25zZSBhdCB0aGUNCj4gPiA+ID4g PiA+IG9yaWdpbmFsIHNlbmRlcnMgb2YgdGhlIHR1bm5lbGVkDQo+ID4gPiB0cmFmZmljLg0KPiA+ ID4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFm ZmljIHRoYXQgaXMNCj4gPiA+ID4gPiA+IGtub3duIGF0IGNvbmZpZ3VyYXRpb24gdGltZSBub3Qg dG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gPiBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRo ZSBVRFAgdHVubmVsIFNIT1VMRCBlbXBsb3kgYW4NCj4gPiA+ID4gPiA+IGFwcHJvcHJpYXRlIGNv bmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluDQo+ID4gPiA+ID4gPiBb UkZDMzk4NV0uIE5vdGUgdGhhdCBpdCBTVFJPTkdMWSBSRUNPTU1FTkRFRCB0byBkZXBsb3kgc3Vj aA0KPiA+ID4gPiA+ID4gZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IG9ubHkgd2l0aGluIGEgU1Ag bmV0d29yayBvciBuZXR3b3Jrcw0KPiA+ID4gPiA+ID4gb2YgYW4gYWRqYWNlbnQgc2V0IG9mIGNv LW9wZXJhdGluZyBTUHMsIHJhdGhlciB0aGFuIG92ZXIgdGhlDQo+ID4gPiA+IEludGVybmV0Lg0K PiA+ID4gPiA+ID4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3VsZCBiZSBhZGRlZCB0 byBibG9jayB0cmFmZmljDQo+ID4gPiA+ID4gPiB3aXRoIHRoZSBVRFAgcG9ydCBudW1iZXIgZm9y IE1QTFMgb3ZlciBVRFAgdG8gcHJldmVudCBNUExTDQo+ID4gPiA+ID4gPiBvdmVyIFVEUCBwYWNr ZXRzIHRvIGVzY2FwZSBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmtzDQo+ID4gPiA+ ID4gPiBkdWUgdG8gbWlzY29uZmlndWF0aW9uIG9yIHBhY2tldA0KPiA+ID4gPiA+IGVycm9ycy4N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBk ZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wgbG9vcCBpbg0KPiA+ID4gPiA+ID4gKHNvbWUpIG1vcmUg ZGV0YWlsLCByYXRoZXIgdGhhbiBwb2ludGluZyB0byBSRkMzOTg1LCB3aGljaA0KPiA+ID4gPiA+ ID4gZG9lc24ndCBoYXZlIGEgd2hvbGUgbG90IG9mIGRldGFpbCBlaXRoZXIuIEFsc28gYmVjYXVz ZSB0aGUNCj4gPiA+ID4gPiA+IGFkZGluZyBvZiBmaXJld2FsbCBydWxlcyByZXF1aXJlcyBhbiBP QU0gaG9vay4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTaW5jZSBTVFJPTkdMWSBSRUNPTU1F TkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJtIGFuZA0KPiA+ID4gPiA+IFJFQ09NTUVOREVEIGlz DQo+ID4gPiA+ID4gPiB0b28gd2VhaywgSSdkIHN1Z2dlc3QgdG8gY2hhbmdlIHRoaXMgdG8gTVVT VC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBGaW5hbGx5LCB0aGUgYXBwbGljYWJpbGl0eSBz dGF0ZW1lbnQgc2hvdWxkIGJlIHByb21pbmVudGx5DQo+ID4gPiA+ID4gPiBtYWRlIGluIHRoZSBh YnN0cmFjdCwgaW50cm9kdWN0aW9uLCBldGMuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gTGFy cw0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+ID4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBtcGxzQGlldGYub3JnDQo+ID4g PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From xuxiaohu@huawei.com Thu Jan 23 17:38:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8FB1A02C8 for ; Thu, 23 Jan 2014 17:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 pv6Bg_ZE-jRu for ; Thu, 23 Jan 2014 17:38:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB0E1A017D for ; Thu, 23 Jan 2014 17:38:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAJ14637; Fri, 24 Jan 2014 01:38:29 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 01:38:23 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 01:38:27 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 09:38:16 +0800 From: Xuxiaohu To: Xuxiaohu , "l.wood@surrey.ac.uk" , "Alexander.Vainshtein@ecitele.com" , "lars@netapp.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiOAAIGV4IAASynFgAB+v4CAAAUDQYAAAhRggAAIfvuAAAIPgIAAASaA Date: Fri, 24 Jan 2014 01:38:15 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478AB@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082477E6@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824784D@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E8@EXMB01CMS.surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 01:38:34 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogWHV4aWFvaHUNCj4gt6LLzcqxvOQ6 IDIwMTTE6jHUwjI0yNUgOTozNg0KPiDK1bz+yMs6ICdsLndvb2RAc3VycmV5LmFjLnVrJzsgQWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207DQo+IGxhcnNAbmV0YXBwLmNvbQ0KPiCzrcvN OiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+INb3zOI6ILTwuLQ6IFttcGxzXSBM YXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcN Cj4gTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiBIaSwNCj4gDQo+IFNp bmNlIHlvdSBhcmUgbm90IGFnYWluc3QgUkZDNjkzNiBhbmQgUkZDNjkzNSwgaG93IGFib3V0IG1h a2luZyB0aGUNCj4gZm9sbG93aW5nIGNoYW5nZToNCj4gDQo+IE9MRDoNCj4gDQo+IEluIHRoZSBJ UHY2IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2UsIGlmIGFwcHJvcHJpYXRlIGFjY29yZGluZyB0byB0 aGUNCj4gcmVxdWlyZW1lbnRzIGRlZmluZWQgaW4gW1JGQzY5MzVdIFtSRkM2OTM2XSwgdGhpcyBm aWVsZCBpcyBhbHNvIFJFQ09NTUVOREVEDQo+IHRvIGJlIHNldCB0byB6ZXJvLiBTcGVjaWZpY2Fs bHksIGlmIHRoZSBNUExTIHBheWxvYWQgaXMgSW50ZXJuZXQgUHJvdG9jb2wgKElQdjQgb3INCj4g SVB2NikgcGFja2V0cywgaXQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gd2hlbiB0 aGUgaW5uZXIgcGFja2V0DQo+IGludGVncml0eSBjaGVja3MgaXMgYXZhaWxhYmxlLiBJbiBhZGRp dGlvbiwgaWYgdGhlIE1QTFMgcGF5bG9hZCBpcyBub24tSVAgcGFja2V0DQo+IHdoaWNoIGlzIHNw ZWNpZmljYWxseSBkZXNpZ25lZCBmb3IgdHJhbnNtaXNzaW9uIG92ZXIgYSBsb3dlciBsYXllciB0 aGF0IGRvZXMgbm90DQo+IHByb3ZpZGUgYSBwYWNrZXQgaW50ZWdyaXR5IGd1YXJhbnRlZSwgaXQg aXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gYXMNCj4gd2VsbC4gT3RoZXJ3aXNlLCB1 c2luZyB6ZXJvIGNoZWNrc3VtIGlzIE5PVCBSRUNPTU1FTkRFRC4gTm90ZSB0aGF0IG90aGVyDQo+ IElQIGVuY2Fwc3VsYXRpb25zIGZvciBNUExTIGRvIG5vdCBoYXZlIGEgY2hlY2tzdW0gaW4gdGhl IHR1bm5lbCBoZWFkZXIuDQo+IA0KPiBORVc6DQo+IA0KPiBJbiB0aGUgSVB2NiBVRFAgZW5jYXBz dWxhdGlvbiBjYXNlLCBhcyBmb3Igd2hldGhlciBvciBub3QgaXQgaXMgc3VpdGFibGUgdG8gdXNl IHRoZQ0KPiB6ZXJvLWNoZWNrc3VtIG5vZGUsIHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbiBb UkZDNjkzNV0gW1JGQzY5MzZdDQoNCnMvbm9kZS9tb2RlDQoNCj4gU0hPVUxEIGJlIHN0cmljdGx5 IGZvbGxvd2VkLiBOb3RlIHRoYXQgb3RoZXIgSVAgZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMgZG8g bm90DQo+IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCj4gDQo+IFhpYW9o dQ0KPiANCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiC3orz+yMs6IGwud29vZEBzdXJyZXku YWMudWsgW21haWx0bzpsLndvb2RAc3VycmV5LmFjLnVrXQ0KPiA+ILeiy83KsbzkOiAyMDE0xOox 1MIyNMjVIDk6MjYNCj4gPiDK1bz+yMs6IFh1eGlhb2h1OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQo+ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsg bXBsc0BpZXRmLm9yZw0KPiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0 Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRv IFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4NCj4gPiBGb3IgdGhlIHJlYXNvbnMgb3V0bGluZWQgaW4g UkZDNjkzNiBzZWN0aW9uIDMsIHdoaWNoIEkgY2l0ZWQsIGFuZCBmb3INCj4gPiB0aGUgZGFuZ2Vy IHRvIG90aGVyIHRyYWZmaWMsIHdoaWNoIHdlIGhhdmUgZGlzY3Vzc2VkIGluIHRoaXMgdGhyZWFk Lg0KPiA+DQo+ID4gSSBxdW90ZSBSRkMzOTM2Og0KPiA+DQo+ID4gIEN1cnJlbnRseSwgZm9yIHRo ZSBnZW5lcmFsIEludGVybmV0LCB0aGVyZSBpcyBubyBldmlkZW5jZSB0aGF0DQo+ID4gY29ycnVw dGlvbiBpcyByYXJlLCBub3IgaXMgdGhlcmUgZXZpZGVuY2UgdGhhdCBjb3JydXB0aW9uIGluIElQ djYgaXMNCj4gPiByYXJlLiBUaGVyZWZvcmUsIGl0IHNlZW1zIHBydWRlbnQgbm90IHRvIHJlbGF4 IGNoZWNrcyBvbiAgbWlzZGVsaXZlcnkuDQo+ID4NCj4gPg0KPiA+IExsb3lkIFdvb2QNCj4gPiBo dHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IEZyb206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0K PiA+IFNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwMTowMA0KPiA+IFRvOiBXb29kIEwgIERyIChFbGVj dHJvbmljIEVuZyk7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0KPiA+IGxhcnNA bmV0YXBwLmNvbQ0KPiA+IENjOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4g U3ViamVjdDogtPC4tDogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAt MDQudHh0Pg0KPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFu ZGFyZA0KPiA+DQo+ID4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgdXNpbmcgVURQIGFzIGEgdHVubmVs IGZvciBNUExTIHRyYWZmaWMuIFNvIHdoeQ0KPiA+IGNhbid0IGFsbG93IHRoZSBVRFAgdHVubmVs IHRvIHVzZSB6ZXJvIGNoZWNrc3VtcyBmb3IgcGVyZm9ybWFuY2UsDQo+ID4gd2hpY2ggaXMgdGhl IHJlY29tbWVuZGF0aW9uIGZyb20gUkZDNjkzNS4NCj4gPg0KPiA+IFhpYW9odQ0KPiA+DQo+ID4g PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBb bWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ID4gPiC3osvNyrG85DogMjAxNMTqMdTCMjTI 1SA4OjQ4DQo+ID4gPiDK1bz+yMs6IFh1eGlhb2h1OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQo+ID4gPiCzrcvNOiBqb2VsamFAYm9ndXMuY29tOyBt cGxzQGlldGYub3JnDQo+ID4gPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWll dGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFAp IHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPg0KPiA+ID4gUkZDNjkzNSB3YXMgd3JpdHRlbiBm cm9tIGEgdHVubmVsbGluZyBwZXJzcGVjdGl2ZSwgdG8gYWxsb3cNCj4gPiA+IHR1bm5lbGxpbmcg dG8gdXNlIHplcm8gY2hlY2tzdW1zIGZvciBwZXJmb3JtYW5jZSwgYW5kIGFuYWx5c2VkIHJpc2tz DQo+ID4gPiB0byB0aGUgdHVubmVsIHRyYWZmaWMgLSBidXQgbm90IHRvIG90aGVyIHVzZXJzLg0K PiA+ID4NCj4gPiA+ICAgICJXaGlsZSB0aGUgbWV0aG9kcyBkbw0KPiA+ID4gICAgbm90IGd1YXJh bnRlZSBjb3JyZWN0bmVzcywgdGhleSBjYW4gcmVkdWNlIHRoZSByaXNrcyBvZiByZWxheGluZyB0 aGUNCj4gPiA+ICAgIFVEUCBjaGVja3N1bSByZXF1aXJlbWVudCBmb3IgYSB0dW5uZWwgYXBwbGlj YXRpb24gdXNpbmcgSVB2Ni4iDQo+ID4gPg0KPiA+ID4gUmlza3MgdG8gb3RoZXIgYXBwbGljYXRp b25zIGFyZSBub3QgYXNzZXNzZWQsIGFuZCBub3Qgc3RhdGVkLg0KPiA+ID4NCj4gPiA+DQo+ID4g PiBMbG95ZCBXb29kDQo+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBGcm9tOiBYdXhpYW9o dSBbeHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPiA+IFNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwMDoz NA0KPiA+ID4gVG86IFdvb2QgTCAgRHIgKEVsZWN0cm9uaWMgRW5nKTsgQWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb207DQo+ID4gPiBsYXJzQG5ldGFwcC5jb20NCj4gPiA+IENjOiBqb2Vs amFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiC08Li0OiBbbXBsc10g TGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiAoRW5jYXBz dWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+DQo+ID4gPiBJ dCBzZWVtcyB0aGF0IHlvdSBhcmUgYWdhaW5zdCBSRkM2OTM1IGFuZCBSRkM2OTM2LCByaWdodD8N Cj4gPiA+DQo+ID4gPiBYaWFvaHUNCj4gPiA+DQo+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiA+ID4gPiC3orz+yMs6IGwud29vZEBzdXJyZXkuYWMudWsgW21haWx0bzpsLndvb2RAc3VycmV5 LmFjLnVrXQ0KPiA+ID4gPiC3osvNyrG85DogMjAxNMTqMdTCMjTI1SAxOjE4DQo+ID4gPiA+IMrV vP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5l dGFwcC5jb20NCj4gPiA+ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0K PiA+ID4gPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11 ZHAtMDQudHh0Pg0KPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9z ZWQgU3RhbmRhcmQNCj4gPiA+ID4NCj4gPiA+ID4gdGhlIHRleHQgaXMgbm90IHNhdGlzZmFjdG9y eS4gbmV2ZXIgcmVjb21tZW5kIHNldHRpbmcgdG8gemVybywgYXMNCj4gPiA+ID4gdGhhdCBwb3Nl cyBhIHJpc2sgdG8geW91ciBhbmQgdG8gb3RoZXIgdHJhZmZpYy4gU3VnZ2VzdGVkIHRleHQ6DQo+ ID4gPiA+ICoqKg0KPiA+ID4gPiBUaGUgVURQIGNoZWNrc3VtIFNIT1VMRCBiZSB1c2VkIHRvIHBy b3RlY3QgdGhlIHBheWxvYWQgYW5kIGVuc3VyZQ0KPiA+ID4gPiBjb3JyZWN0IGRlbXVsdGlwbGV4 aW5nIGFuZCBkZWxpdmVyeSB0byB0aGUgdHVubmVsLCBhbmQgbm90IHRvDQo+ID4gPiA+IG90aGVy IFVEUCBkZXN0aW5hdGlvbnMsIGJ5IHByb3RlY3RpbmcgdGhlIFVEUCBwc2V1ZG9oZWFkZXIuDQo+ ID4gPiA+IFVzZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzIE5PVCBSRUNPTU1FTkRFRCwgZXZl biB3aGVuIGRlc2lyZWQNCj4gPiA+ID4gZm9yIHBlcmZvcm1hbmNlIG9yIG5lY2Vzc2l0YXRlZCBi eSBpbXBsZW1lbnRhdGlvbiByZWFzb25zLCBmb3IgdGhlDQo+ID4gPiA+IHJlYXNvbnMgb3V0bGlu ZWQgaW4gW1JGQzY5MzZdIHNlY3Rpb24gMy4NCj4gPiA+ID4NCj4gPiA+ID4gVURQLUxpdGUgW1JG QzM4MjhdIGNhbiBwcm92aWRlIGEgZGVtdWx0aXBsZXhpbmcgY2hlY2sgYW5kIE1QTFMNCj4gPiA+ ID4gc3RhY2sgaW50ZWdyaXR5IGNoZWNrIHdoaWxlIGF2b2lkaW5nIHRoZSBvdmVyaGVhZCBvZiBj b21wdXRpbmcgYW4NCj4gPiA+ID4gaW50ZWdyaXR5IGNoZWNrIG92ZXIgYSB0dW5uZWxsZWQgZnJh bWUgdGhhdCBoYXMgaXRzIG93biBpbnRlZ3JpdHkgY2hlY2suDQo+ID4gPiA+ICoqKg0KPiA+ID4g Pg0KPiA+ID4gPiBMbG95ZCBXb29kDQo+ID4gPiA+IGh0dHA6Ly9hYm91dC5tZS9sbG95ZHdvb2QN Cj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4g PiBGcm9tOiBYdXhpYW9odSBbeHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPiA+ID4gU2VudDogMjMg SmFudWFyeSAyMDE0IDEyOjM1DQo+ID4gPiA+IFRvOiBXb29kIEwgIERyIChFbGVjdHJvbmljIEVu Zyk7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0KPiA+ID4gPiBsYXJzQG5ldGFw cC5jb20NCj4gPiA+ID4gQ2M6IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ ID4gU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRw LTA0LnR4dD4NCj4gPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2Vk IFN0YW5kYXJkDQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gPiA+ ID4gt6K8/sjLOiBsLndvb2RAc3VycmV5LmFjLnVrIFttYWlsdG86bC53b29kQHN1cnJleS5hYy51 a10NCj4gPiA+ID4gPiC3osvNyrG85DogMjAxNMTqMdTCMjPI1SAxMjo0NA0KPiA+ID4gPiA+IMrV vP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0KPiBsYXJz QG5ldGFwcC5jb20NCj4gPiA+ID4gPiCzrcvNOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYu b3JnDQo+ID4gPiA+ID4g1vfM4jogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1w bHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg dG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFNhc2hhDQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IC0gVURQIGNoZWNrc3VtcyAob3IgbGFjayB0aGVyZW9mKSBpcyBhIG5v bi1pc3N1ZSBiZWNhdXNlDQo+ID4gPiA+ID4gPiBuYXRpdmUgTVBMUyBkb2VzIG5vdCBoYXZlIGFu eXRoaW5nIGxpa2UgdGhhdC4gQW5kIHllcywgdGhlcmUNCj4gPiA+ID4gPiA+IGFyZSBjYXNlcyB3 aGVyZSBwYWNrZXRzIGFyZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKQ0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gU28geW91IGFkbWl0IHRoYXQgcGFja2V0cyBjYW4gYmUgY29ycnVwdGVkIHdp dGhpbiB0aGUgcm91dGVycyAtDQo+ID4gPiA+ID4gYSBjaGVjayB0aGF0IGNhbiBvbmx5IGJlIGNh dWdodCBieSBhbiBlbmQtdG8tZW5kIGNoZWNrLCBhDQo+ID4gPiA+ID4gY29ycnVwdGlvbiB0aGF0 IGNhbiBsZWFkIHRvIHRoZSBwcm9ibGVtcyBkZXRhaWxlZCBpbiBSRkMgNjkzNg0KPiA+ID4gPiA+ IHNlY3Rpb24gMyAtIGFuZCB0aGVuIHlvdSBzYXkgaXQncyBhIG5vbi1pc3N1ZSBiZWNhdXNlIHRo aXMNCj4gPiA+ID4gPiBkb2Vzbid0IGFmZmVjdCBuYXRpdmUgTVBMUy4gQnV0IHdlJ3JlDQo+ID4g PiA+IG5vdCBkb2luZyBuYXRpdmUgTVBMUyBoZXJlLg0KPiA+ID4gPiA+IFdlJ3JlIGRvaW5nIE1Q TFMgb3ZlciBVRFAuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBkcmFmdC1pZXRmLW1wbHMtaW4tdWRw LTA0LnR4dCBpcyBhYm91dCB0dW5uZWxsaW5nIE1QTFMgaW4gVURQLiBJdCdzIGFuDQo+IGlzc3Vl Lg0KPiA+ID4gPiA+IFBsZWFzZSByZWFkIHRoZSBvdGhlciAxNTAgbWVzc2FnZXMgdGhhdCB5b3Ug cmVmZXIgdG8uDQo+ID4gPiA+DQo+ID4gPiA+IEhpIExsb3lkLA0KPiA+ID4gPg0KPiA+ID4gPiBU aGUgZHJhZnQgZG9lc24ndCByZXF1aXJlIHRoZSBJUHY2IFVEUCBjaGVja3N1bSB0byBiZSBzZXQg dG8gemVybw0KPiA+IHJlZ2FyZGxlc3MuDQo+ID4gPiA+IFNlZSB0aGUgZm9sbG93aW5nIHRleHQg cXVvdGVkIGZyb20gdGhhdCBkcmFmdDoNCj4gPiA+ID4NCj4gPiA+ID4gVURQIENoZWNrc3VtDQo+ ID4gPiA+DQo+ID4gPiA+IFRoZSB1c2FnZSBvZiB0aGlzIGZpZWxkIGlzIGluIGFjY29yZGFuY2Ug d2l0aCB0aGUgY3VycmVudCBVRFANCj4gPiA+ID4gc3BlY2lmaWNhdGlvbiBbUkZDNzY4XS4gVG8g c2ltcGxpZnkgdGhlIG9wZXJhdGlvbiBvbiB0aGUNCj4gPiA+ID4gZGVjYXBzdWxhdG9yLCB0aGlz IGZpZWxkIGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGluIElQdjQNCj4gPiA+ID4g VURQIGVuY2Fwc3VsYXRpb24gY2FzZS4gSW4gdGhlIElQdjYgVURQIGVuY2Fwc3VsYXRpb24gY2Fz ZSwgaWYNCj4gPiA+ID4gYXBwcm9wcmlhdGUgYWNjb3JkaW5nIHRvIHRoZSByZXF1aXJlbWVudHMg ZGVmaW5lZCBpbiBbUkZDNjkzNV0NCj4gPiA+ID4gW1JGQzY5MzZdLCB0aGlzIGZpZWxkIGlzIGFs c28NCj4gPiA+IFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvLg0KPiA+ID4gPiBTcGVjaWZp Y2FsbHksIGlmIHRoZSBNUExTIHBheWxvYWQgaXMgSW50ZXJuZXQgUHJvdG9jb2wgKElQdjQgb3IN Cj4gPiA+ID4gSVB2NikgcGFja2V0cywgaXQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHpl cm8gd2hlbiB0aGUgaW5uZXINCj4gPiA+ID4gcGFja2V0IGludGVncml0eSBjaGVja3MgaXMgYXZh aWxhYmxlLiBJbiBhZGRpdGlvbiwgaWYgdGhlIE1QTFMNCj4gPiA+ID4gcGF5bG9hZCBpcyBub24t SVAgcGFja2V0IHdoaWNoIGlzIHNwZWNpZmljYWxseSBkZXNpZ25lZCBmb3INCj4gPiA+ID4gdHJh bnNtaXNzaW9uIG92ZXIgYSBsb3dlciBsYXllciB0aGF0IGRvZXMgbm90IHByb3ZpZGUgYSBwYWNr ZXQNCj4gPiA+ID4gaW50ZWdyaXR5IGd1YXJhbnRlZSwgaXQgaXMgUkVDT01NRU5ERUQgdG8gYmUg c2V0IHRvIHplcm8gYXMgd2VsbC4NCj4gPiA+ID4gT3RoZXJ3aXNlLCB1c2luZyB6ZXJvIGNoZWNr c3VtIGlzIE5PVCBSRUNPTU1FTkRFRC4gTm90ZSB0aGF0IG90aGVyDQo+ID4gPiA+IElQIGVuY2Fw c3VsYXRpb25zIGZvciBNUExTIGRvIG5vdA0KPiA+ID4gaGF2ZSBhIGNoZWNrc3VtIGluIHRoZSB0 dW5uZWwgaGVhZGVyLg0KPiA+ID4gPg0KPiA+ID4gPiBJZiB5b3Ugc3RpbGwgYmVsaWV2ZSB0aGUg YWJvdmUgdGV4dCBpcyBub3Qgc2F0aXNmYWN0b3J5LCBwbGVhc2UgcHJvdmlkZSB5b3VyDQo+IHRl eHQuDQo+ID4gPiA+DQo+ID4gPiA+IEJlc3QgcmVnYXJkcywNCj4gPiA+ID4gWGlhb2h1DQo+ID4g PiA+DQo+ID4gPiA+ID4gTGxveWQgV29vZA0KPiA+ID4gPiA+IGh0dHA6Ly9hYm91dC5tZS9sbG95 ZHdvb2QNCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gPiA+ID4gRnJvbTogbXBscyBbbXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgWHV4aWFvaHUNCj4gPiA+ID4gPiBbeHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPiA+ID4gPiBT ZW50OiAyMyBKYW51YXJ5IDIwMTQgMDM6MTYNCj4gPiA+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5z aHRlaW47IEVnZ2VydCwgTGFycw0KPiA+ID4gPiA+IENjOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0 Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWll dGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4g VURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSGkNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gPiA+ID4gPiC3orz+yMs6 IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+ID4gPiA+ID4gPiBbbWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ID4gPiA+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjIyyNUg MTk6MDUNCj4gPiA+ID4gPiA+IMrVvP7IyzogRWdnZXJ0LCBMYXJzDQo+ID4gPiA+ID4gPiCzrcvN OiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1DQo+ID4gPiA+ID4gPiDW98zi OiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0K PiA+ID4gPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5k YXJkDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gTGFycyBhbmQgYWxsLA0KPiA+ID4gPiA+ID4g TGFzdCB0aW1lIEkndmUgY291bnRlZCB0aGUgSUVURiBMQyB0aHJlYWQgb24gdGhpcyBkcmFmdCBo YXMNCj4gPiA+ID4gPiA+IG1vcmUgdGhhbg0KPiA+ID4gPiA+ID4gMTUwIG1lc3NhZ2VzIGluIGl0 LCBhbmQgaXQgc2VlbXMgdGhhdCBvbiBzb21lIGlzc3Vlcw0KPiA+ID4gPiA+ID4gKGNvbmdlc3Rp b24gY29udHJvbCBhbmQgVURQDQo+ID4gPiA+ID4gPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyBy b3VuZCB0aGUgbXVsYmVycnkgYnVzaC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJTUhPIGFu ZCBGV0lXOg0KPiA+ID4gPiA+ID4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlz IGEgbm9uLWlzc3VlIGJlY2F1c2UNCj4gPiA+ID4gPiA+IG5hdGl2ZSBNUExTIGRvZXMgbm90IGhh dmUgYW55dGhpbmcgbGlrZSB0aGF0LiBBbmQgeWVzLCB0aGVyZQ0KPiA+ID4gPiA+ID4gYXJlIGNh c2VzIHdoZXJlIHBhY2tldHMgYXJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMpLCBidXQN Cj4gPiA+ID4gPiA+IHNvIGZhciBpdCBkaWQgbm90IHByZXZlbnQgTVBMUyBkZXBsb3ltZW50LiBU aGVyZSBpcywgZS5nLiwgUkZDDQo+ID4gPiA+ID4gPiA0NzIwIGZvciBGQ1MgcmV0ZW50aW9uIGlu IFBXcywgYnV0IEkgZG91YnQgaXQgaXMgd2lkZWx5DQo+ID4gPiA+ID4gPiBpbXBsZW1lbnRlZCBh bmQgZGVwbG95ZWQgKHdvdWxkIGJlIG5pY2UgdG8NCj4gPiA+ID4gPiBrbm93KS4NCj4gPiA+ID4g PiA+IC0gRTJFIGNvbmdlc3Rpb24gY29udHJvbCAocmVnYXJkbGVzcyBvZiBpdHMgaW1wbGljYXRp b25zKQ0KPiA+ID4gPiA+ID4gc2ltcGx5IGNhbm5vdCBiZSBhZGRlZCB0byB0aGlzIHByb3RvY29s IHdpdGhvdXQgc29tZSBtYWpvcg0KPiA+ID4gPiA+ID4gY2hhbmdlcy4gQSBzaG9ydCBhcHBsaWNh YmlsaXR5IHN0YXRlbWVudCBleHBsYWluaW5nIHRoYXQgc2hvdWxkIHN1ZmZpY2UNCj4gSU1PLg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gSGkgU2FzaGEsDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGZ1 bGx5IGFncmVlIHdpdGggeW91ciBwb2ludHMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBCZXN0IHJl Z2FyZHMsDQo+ID4gPiA+ID4gWGlhb2h1DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE15IDJjLA0K PiA+ID4gPiA+ID4gICAgICAgIFNhc2hhDQo+ID4gPiA+ID4gPiBFbWFpbDogQWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gPiA+ID4gPiA+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g PiA+ID4gPiA+IEZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZg0KPiA+ID4gPiA+ID4gPiBFZ2dlcnQsIExhcnMNCj4gPiA+ID4gPiA+ID4gU2VudDog V2VkbmVzZGF5LCBKYW51YXJ5IDIyLCAyMDE0IDEyOjIzIFBNDQo+ID4gPiA+ID4gPiA+IFRvOiBY dXhpYW9odQ0KPiA+ID4gPiA+ID4gPiBDYzogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gTGFzdCBDYWxsOg0KPiA+ID4gPiA+ID4g PiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4g VURQKQ0KPiA+ID4gPiA+ID4gPiB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiBIaSwNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gT24gMjAxNC0x LTIyLCBhdCAxMToxMiwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ ID4gPiA+ID4gPiA+IEkgd29uZGVyIHdoZXRoZXIgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIE9LIHRv IHlvdToNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IFNpbmNlIHRoZSBNUExTLWlu LVVEUCBlbmNhcHN1bGF0aW9uIGNhdXNlcyBNUExTIHBhY2tldHMgdG8NCj4gPiA+ID4gPiA+ID4g PiBiZQ0KPiA+ID4gPiA+ID4gPiBmb3J3YXJkZWQgdGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUg Y29uZ2VzdGlvbiBjb250cm9sDQo+ID4gPiA+ID4gPiA+IGd1aWRlbGluZXMgZm9yIFVEUCB0dW5u ZWxzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuMyBvZg0KPiA+ID4gPiA+ID4gPiBbUkZDNTQw NV0gU0hPVUxEIGJlDQo+ID4gPiA+ID4gZm9sbG93ZWQuDQo+ID4gPiA+ID4gPiA+IFNwZWNpZmlj YWxseSwgTVBMUyBjYW4gY2FycnkgYSBudW1iZXIgb2YgZGlmZmVyZW50IHByb3RvY29scw0KPiA+ ID4gPiA+ID4gPiBhcw0KPiA+IHBheWxvYWRzLg0KPiA+ID4gPiA+ID4gPiBXaGVuIGFuIFVEUCB0 dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcw0KPiA+ID4gPiA+ ID4gPiBrbm93biBhdCBjb25maWd1cmF0aW9uIHRpbWUgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4g PiA+ID4gPiA+IGNvbmdlc3Rpb24tY29udHJvbGxlZCwgdGhlIFVEUCB0dW5uZWwgU0hPVUxEIE5P VCBlbXBsb3kgaXRzDQo+ID4gPiA+ID4gPiA+IG93biBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFu aXNtLCBiZWNhdXNlIGNvbmdlc3Rpb24gbG9zc2VzDQo+ID4gPiA+ID4gPiA+IG9mIHR1bm5lbGVk IHRyYWZmaWMgd2lsbCB0cmlnZ2VyIGFuIGNvbmdlc3Rpb24gcmVzcG9uc2UgYXQNCj4gPiA+ID4g PiA+ID4gdGhlIG9yaWdpbmFsIHNlbmRlcnMgb2YgdGhlIHR1bm5lbGVkDQo+ID4gPiA+IHRyYWZm aWMuDQo+ID4gPiA+ID4gPiA+IFdoZW4gYW4gVURQIHR1bm5lbCBpcyB1c2VkIGZvciBNUExTIHBh eWxvYWQgdHJhZmZpYyB0aGF0IGlzDQo+ID4gPiA+ID4gPiA+IGtub3duIGF0IGNvbmZpZ3VyYXRp b24gdGltZSBub3QgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gPiA+IGNvbmdlc3Rpb24t Y29udHJvbGxlZCwgdGhlIFVEUCB0dW5uZWwgU0hPVUxEIGVtcGxveSBhbg0KPiA+ID4gPiA+ID4g PiBhcHByb3ByaWF0ZSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIGFzIGRlc2NyaWJlZCBp bg0KPiA+ID4gPiA+ID4gPiBbUkZDMzk4NV0uIE5vdGUgdGhhdCBpdCBTVFJPTkdMWSBSRUNPTU1F TkRFRCB0byBkZXBsb3kgc3VjaA0KPiA+ID4gPiA+ID4gPiBlbmNhcHN1bGF0aW9uIHRlY2hub2xv Z3kgb25seSB3aXRoaW4gYSBTUCBuZXR3b3JrIG9yDQo+ID4gPiA+ID4gPiA+IG5ldHdvcmtzIG9m IGFuIGFkamFjZW50IHNldCBvZiBjby1vcGVyYXRpbmcgU1BzLCByYXRoZXIgdGhhbg0KPiA+ID4g PiA+ID4gPiBvdmVyIHRoZQ0KPiA+ID4gPiA+IEludGVybmV0Lg0KPiA+ID4gPiA+ID4gPiBGdXJ0 aGVybW9yZSwgcGFja2V0IGZpbHRlcnMgc2hvdWxkIGJlIGFkZGVkIHRvIGJsb2NrIHRyYWZmaWMN Cj4gPiA+ID4gPiA+ID4gd2l0aCB0aGUgVURQIHBvcnQgbnVtYmVyIGZvciBNUExTIG92ZXIgVURQ IHRvIHByZXZlbnQgTVBMUw0KPiA+ID4gPiA+ID4gPiBvdmVyIFVEUCBwYWNrZXRzIHRvIGVzY2Fw ZSBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyDQo+ID4gPiA+ID4gPiA+IG5ldHdvcmtzIGR1ZSB0 byBtaXNjb25maWd1YXRpb24gb3IgcGFja2V0DQo+ID4gPiA+ID4gPiBlcnJvcnMuDQo+ID4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGRlc2Ny aWJlIHRoZSBPQU0gY29udHJvbCBsb29wDQo+ID4gPiA+ID4gPiA+IGluDQo+ID4gPiA+ID4gPiA+ IChzb21lKSBtb3JlIGRldGFpbCwgcmF0aGVyIHRoYW4gcG9pbnRpbmcgdG8gUkZDMzk4NSwgd2hp Y2gNCj4gPiA+ID4gPiA+ID4gZG9lc24ndCBoYXZlIGEgd2hvbGUgbG90IG9mIGRldGFpbCBlaXRo ZXIuIEFsc28gYmVjYXVzZSB0aGUNCj4gPiA+ID4gPiA+ID4gYWRkaW5nIG9mIGZpcmV3YWxsIHJ1 bGVzIHJlcXVpcmVzIGFuIE9BTSBob29rLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBT aW5jZSBTVFJPTkdMWSBSRUNPTU1FTkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJtIGFuZA0KPiA+ ID4gPiA+ID4gUkVDT01NRU5ERUQgaXMNCj4gPiA+ID4gPiA+ID4gdG9vIHdlYWssIEknZCBzdWdn ZXN0IHRvIGNoYW5nZSB0aGlzIHRvIE1VU1QuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ IEZpbmFsbHksIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBzaG91bGQgYmUgcHJvbWluZW50 bHkNCj4gPiA+ID4gPiA+ID4gbWFkZSBpbiB0aGUgYWJzdHJhY3QsIGludHJvZHVjdGlvbiwgZXRj Lg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBMYXJzDQo+ID4gPiA+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiBtcGxzIG1h aWxpbmcgbGlzdA0KPiA+ID4gPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From sriganesh.kini@ericsson.com Thu Jan 23 18:15:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB451A01BE for ; Thu, 23 Jan 2014 18:15: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, 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 PIANoonh8zRs for ; Thu, 23 Jan 2014 18:15:17 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C08351A0111 for ; Thu, 23 Jan 2014 18:15:17 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-05-52e1ccb44535 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DF.C8.11484.4BCC1E25; Fri, 24 Jan 2014 03:15:16 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Thu, 23 Jan 2014 21:15:14 -0500 From: Sriganesh Kini To: Loa Andersson , Xuxiaohu , "Curtis Villamizar" , Daniel King Thread-Topic: Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping Thread-Index: AQHPCE9A+TcumlifSk2qGEM5Kxzrv5py/RmAgCAUOQA= Date: Fri, 24 Jan 2014 02:15:14 +0000 Message-ID: In-Reply-To: <52C67349.4020701@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-ID: <0BDA48F98D09B344B09BB38E044E02A2@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyuXRPuO6WMw+DDM7+k7A4fGA6u0XT270s FhtPn2KzWHJnB6vFv7lzmC2+X1rCYnFr6UpWi63nVzE6cHi0HHnL6rFkyU8mj8Vf/DxWbF7J 6DFrehubx5fLn9kC2KK4bFJSczLLUov07RK4MibvmclY8EKiYvHk5SwNjIuEuxg5OSQETCT2 7VzFAmGLSVy4t56ti5GLQ0jgCKPE02nn2SGc5YwSz5+2s4JUsQkYSVy4O58FJCEi0MUoMfvw SVYQh1lgA5PE3t5nYC3CAj2MElMXfmaGKOtllNh/fzMbSL+IgJXEn72NYBtZBFQlPs+dxAhi 8wpYSHze9oIdxOYEiu/9N4cZxGYEuur7qTVMIDazgLjErSfzmSCuFZBYsuc8M4QtKvHy8T+w +0QF9CQO73nNChFXlNjXP50doldHYsHuT0A3cADZ1hKnD2hChLUlli18zQxxgqDEyZlPWCYw is9Csm0Wku5ZCN2zkHTPQtK9gJF1FSNHaXFqWW66keEmRmD0HpNgc9zBuOCT5SFGaQ4WJXHe L2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwGn9l85BMt1WqaDt1/tVB5XcyGh7XNjwI mh8jK7ftjqzWv6mtMyJXrLYoKRQO3JbNz50wa27QtQcPllqp3pz3PlvsoW/0F0uX/MKfVw5x GezJvmu8fP2POOY7Wy/Oulb+tE5AZtZztzV1Hx1uZRhw1KjyRSyJrjjubfXe68WKsl2cAqe1 DmhVKbEUZyQaajEXFScCAFQsoYasAgAA Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" , "draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:15:20 -0000 Hello authors, The draft is reasonably coherent. It addresses a useful problem. Technically it is a start. The document is ready to be considered for WG adoption. A few comments - 1. sec 8. DSMAP is deprecated. Should be removed. Even though "Multipath Info" field was in DSMAP too, since a more recent RFC has deprecated it, it should no longer be used. Some implementations referring to DSMAP is not a reason to continue using if the intention is to get to a proposed standard.=20 2. The notation {x, y, z} is introduced in section 2, without mentioning what it means. I am assuming it means one-of. Should be stated clearly. 3. sec 9 bullet 1 - If the transit node encounters a deep label stack, it may not be able to access labels till the bottom of stack to compute the hash. If this is the case, "Depth Limit" should take care of this. It is not clear what this unsupported-case is and why it should occur. 4. sec 9. bullet 2 - Is this case when the transit node is using other labels in the label stack "in addition to the EL" OR is it when the transit node is using a non-EL label in the stack even if EL is included ? The former case is typical. The latter case I would imagine can occur if the transit LSR cannot access the entire label stack depth. Again not clear what the unsupported case is. 5. Does the draft make a distinction between the two cases allowed by RFC6790, namely - a. Load balance solely on the EL b. Use as-much of the label-stack as feasible 6. The "Associated Label Multipath Information" field should be better explained. I would suggest a separate section to improve the coherency. Thanks Sri On 1/3/14 12:22 AM, "Loa Andersson" wrote: >Folks, > >This was the wrong document - I intended to have the review >done for draft-akiya-mpls-entropy-lsp-ping sorry for the confusion. > >All other cordinates correct! > >On 2014-01-03 14:44, Loa Andersson wrote: >> Sri, Xiaohu, Curtis and Dan, >> >> You have been selected as MPLS Review team reviewers for >> draft-akiya-mpls-entropy-lsp-ping-01. >> >> Note to authors: You have been CC'd on this email so that you can know >> that this review is going on. However, please do not review your own >> document. >> >> Reviews should comment on whether the document is coherent, is it >> useful (ie, is it likely to be actually useful in operational >> networks), and is the document technically sound? We are interested >> in knowing whether the document is ready to be considered for WG >> adoption (ie, it doesn't have to be perfect at this point, but should be >> a good start). >> >> Reviews should be sent to the document authors, WG co-chairs and >> WG secretary, and CC'd to the MPLS WG email list. If necessary, comments >> may be sent privately to only the WG chairs. >> >> Are you able to review this draft by January 20, 2014? >> >> Thanks, Loa >> (as MPLS WG chair) > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From xuxiaohu@huawei.com Thu Jan 23 18:22:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E621A010E for ; Thu, 23 Jan 2014 18:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 sDDQiGEdTBfy for ; Thu, 23 Jan 2014 18:22:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BA7371A0098 for ; Thu, 23 Jan 2014 18:22:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCW20130; Fri, 24 Jan 2014 02:22:50 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 02:22:43 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 02:22:48 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 10:22:43 +0800 From: Xuxiaohu To: "Eggert, Lars" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAZGOsIABjYUA Date: Fri, 24 Jan 2014 02:22:42 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478D0@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:22:54 -0000 SGkgTGFycyBhbmQgYWxsLA0KDQpJIHRoaW5rIGEgY29uZ2VzdGlvbiBjb25zaWRlcmF0aW9uIHNl Y3Rpb24gY29udGFpbmluZyB0aGUgZm9sbG93aW5nIHRleHQgY291bGQgYmUgcmVtYWluZWQgZm9y IHBlb3BsZSB0byBrbm93IHRoZSBiYWNrZ3JvdW5kIGZvciB0aGUgYXBwbGljYXRpb24gc3RhdGVt ZW50cy4NCg0KNS4gQ29uZ2VzdGlvbiBDb25zaWRlcmF0aW9ucw0KDQpTaW5jZSB0aGUgTVBMUy1p bi1VRFAgZW5jYXBzdWxhdGlvbiBjYXVzZXMgTVBMUyBwYWNrZXRzIHRvIGJlIGZvcndhcmRlZCB0 aHJvdWdoICJVRFAgdHVubmVscyIsIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgZ3VpZGVsaW5lcyBm b3IgVURQIHR1bm5lbHMgYXMgZGVmaW5lZCBpbiBbUkZDNTQwNV0gU0hPVUxEIGJlIGZvbGxvd2Vk LiBTcGVjaWZpY2FsbHksIGFzIHN0YXRlZCBpbiBTZWN0aW9uIDMuMS4zIG9mIFtSRkM1NDA1XSAi Li4uRmluYWxseSwgc29tZSBidWxrIHRyYW5zZmVyIGFwcGxpY2F0aW9ucyBtYXkgY2hvb3NlIG5v dCB0byBpbXBsZW1lbnQgYW55IGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gYW5kIGluc3Rl YWQgcmVseSBvbiB0cmFuc21pdHRpbmcgYWNyb3NzIHJlc2VydmVkIHBhdGggY2FwYWNpdHkuIFRo aXMgbWlnaHQgYmUgYW4gYWNjZXB0YWJsZSBjaG9pY2UgZm9yIGEgc3Vic2V0IG9mIHJlc3RyaWN0 ZWQgbmV0d29ya2luZyBlbnZpcm9ubWVudHMsIGJ1dCBpcyBieSBubyBtZWFucyBhIHNhZmUgcHJh Y3RpY2UgZm9yIG9wZXJhdGlvbiBpbiB0aGUgSW50ZXJuZXQuICIgRHVlIHRvIHRoZSBmYWN0IHRo YXQgdGhlIHByb3ZlbiBNUExTLWluLUdSRSBhbmQgTVBMUy1pbi1JUCBbUkZDNDAyM10gZW5jYXBz dWxhdGlvbiB0ZWNobm9sb2dpZXMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSBkZXBsb3llZCB3aXRo aW4gU1AgbmV0d29ya3Mgd2l0aG91dCBhbnkgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSBh bmQgdGhlIGZhY3QgdGhhdCB0aGUgY3VycmVudCBNUExTIHRlY2hub2xvZ3kgY291bGRuJ3QgcHJv dmlkZSBjb25nZXN0aW9uIGNvbnRyb2wgd2l0aG91dCBtYWpvciBjaGFuZ2VzLCB0aGUgTVBMUy1p bi1VRFAgZW5jYXBzdWxhdGlvbiBNVVNUIG9ubHkgYmUgZGVwbG95ZWQgaW4gU1AgbmV0d29ya3Mg d2hpY2ggaXMgYSByZXN0cmljdGVkIG5ldHdvcmsgZW52aXJvbm1lbnQuDQoNCkJlc3QgcmVnYXJk cywNClhpYW9odQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IFh1eGlhb2h1DQo+ ILeiy83KsbzkOiAyMDE0xOox1MIyM8jVIDExOjAxDQo+IMrVvP7IyzogJ0VnZ2VydCwgTGFycycN Cj4gs63LzTogY3VydGlzQGlwdjYub2NjbmMuY29tOyBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5v cmcNCj4g1vfM4jogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRw LTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbg0KPiBVRFApIHRvIFByb3Bvc2VkIFN0YW5k YXJkDQo+IA0KPiBIaSBMYXJzLA0KPiANCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiC3orz+ yMs6IEVnZ2VydCwgTGFycyBbbWFpbHRvOmxhcnNAbmV0YXBwLmNvbV0NCj4gPiC3osvNyrG85Dog MjAxNMTqMdTCMjLI1SAxODoyMw0KPiA+IMrVvP7IyzogWHV4aWFvaHUNCj4gPiCzrcvNOiBjdXJ0 aXNAaXB2Ni5vY2NuYy5jb207IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+INb3zOI6 IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4N Cj4gPiBIaSwNCj4gPg0KPiA+IE9uIDIwMTQtMS0yMiwgYXQgMTE6MTIsIFh1eGlhb2h1IDx4dXhp YW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+IEkgd29uZGVyIHdoZXRoZXIgdGhlIGZvbGxv d2luZyB0ZXh0IGlzIE9LIHRvIHlvdToNCj4gPiA+DQo+ID4gPiBTaW5jZSB0aGUgTVBMUy1pbi1V RFAgZW5jYXBzdWxhdGlvbiBjYXVzZXMgTVBMUyBwYWNrZXRzIHRvIGJlDQo+ID4gPiBmb3J3YXJk ZWQNCj4gPiB0aHJvdWdoICJVRFAgdHVubmVscyIsIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgZ3Vp ZGVsaW5lcyBmb3IgVURQDQo+ID4gdHVubmVscyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjMg b2YgW1JGQzU0MDVdIFNIT1VMRCBiZSBmb2xsb3dlZC4NCj4gPiBTcGVjaWZpY2FsbHksIE1QTFMg Y2FuIGNhcnJ5IGEgbnVtYmVyIG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMNCj4gPiBwYXlsb2Fk cy4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFmZmljIHRo YXQgaXMNCj4gPiBrbm93biBhdCBjb25maWd1cmF0aW9uIHRpbWUgdG8gYmUgSVAtYmFzZWQgYW5k IGNvbmdlc3Rpb24tY29udHJvbGxlZCwNCj4gPiB0aGUgVURQIHR1bm5lbCBTSE9VTEQgTk9UIGVt cGxveSBpdHMgb3duIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20sDQo+ID4gYmVjYXVzZSBj b25nZXN0aW9uIGxvc3NlcyBvZiB0dW5uZWxlZCB0cmFmZmljIHdpbGwgdHJpZ2dlciBhbiBjb25n ZXN0aW9uDQo+IHJlc3BvbnNlIGF0IHRoZSBvcmlnaW5hbCBzZW5kZXJzIG9mIHRoZSB0dW5uZWxl ZCB0cmFmZmljLg0KPiA+IFdoZW4gYW4gVURQIHR1bm5lbCBpcyB1c2VkIGZvciBNUExTIHBheWxv YWQgdHJhZmZpYyB0aGF0IGlzIGtub3duIGF0DQo+ID4gY29uZmlndXJhdGlvbiB0aW1lIG5vdCB0 byBiZSBJUC1iYXNlZCBhbmQgY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUNCj4gPiBVRFAgdHVu bmVsIFNIT1VMRCBlbXBsb3kgYW4gYXBwcm9wcmlhdGUgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hh bmlzbQ0KPiA+IGFzIGRlc2NyaWJlZCBpbiBbUkZDMzk4NV0uIE5vdGUgdGhhdCBpdCBTVFJPTkdM WSBSRUNPTU1FTkRFRCB0byBkZXBsb3kNCj4gPiBzdWNoIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9n eSBvbmx5IHdpdGhpbiBhIFNQIG5ldHdvcmsgb3IgbmV0d29ya3Mgb2YNCj4gPiBhbiBhZGphY2Vu dCBzZXQgb2YgY28tb3BlcmF0aW5nIFNQcywgcmF0aGVyIHRoYW4gb3ZlciB0aGUgSW50ZXJuZXQu DQo+ID4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3VsZCBiZSBhZGRlZCB0byBibG9j ayB0cmFmZmljIHdpdGggdGhlDQo+ID4gVURQIHBvcnQgbnVtYmVyIGZvciBNUExTIG92ZXIgVURQ IHRvIHByZXZlbnQgTVBMUyBvdmVyIFVEUCBwYWNrZXRzIHRvDQo+ID4gZXNjYXBlIGZyb20gdGhl IHNlcnZpY2UgcHJvdmlkZXIgbmV0d29ya3MgZHVlIHRvIG1pc2NvbmZpZ3VhdGlvbiBvciBwYWNr ZXQNCj4gZXJyb3JzLg0KPiA+DQo+ID4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVz Y3JpYmUgdGhlIE9BTSBjb250cm9sIGxvb3AgaW4gKHNvbWUpDQo+ID4gbW9yZSBkZXRhaWwsIHJh dGhlciB0aGFuIHBvaW50aW5nIHRvIFJGQzM5ODUsIHdoaWNoIGRvZXNuJ3QgaGF2ZSBhDQo+ID4g d2hvbGUgbG90IG9mIGRldGFpbCBlaXRoZXIuIEFsc28gYmVjYXVzZSB0aGUgYWRkaW5nIG9mIGZp cmV3YWxsIHJ1bGVzIHJlcXVpcmVzIGFuDQo+IE9BTSBob29rLg0KPiA+DQo+ID4gU2luY2UgU1RS T05HTFkgUkVDT01NRU5ERUQgaXMgbm90IGFuIFJGQzIxMTkgdGVybSBhbmQNCj4gUkVDT01NRU5E RUQgaXMNCj4gPiB0b28gd2VhaywgSSdkIHN1Z2dlc3QgdG8gY2hhbmdlIHRoaXMgdG8gTVVTVC4N Cj4gDQo+IEl0J3MgZmluZSB0byBtYWtlIHRoYXQgY2hhbmdlLg0KPiANCj4gPiBGaW5hbGx5LCB0 aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgc2hvdWxkIGJlIHByb21pbmVudGx5IG1hZGUgaW4g dGhlDQo+ID4gYWJzdHJhY3QsIGludHJvZHVjdGlvbiwgZXRjLg0KPiANCj4gVGhlIGFwcGxpY2F0 aW9uIHN0YXRlbWVudCBpcyBwcm9taW5lbnRseSBkZXNjcmliZWQgaW4gYSBkZWRpY2F0ZWQgc3Vi LXNlY3Rpb24gb2YNCj4gdGhlIEludHJvZHVjdGlvbiBTZWN0aW9uIGFzIGZvbGxvd3M6DQo+IA0K PiAxLjMuIEFwcGxpY2F0aW9uIFN0YXRlbWVudHMNCj4gDQo+IFRoZSBNUExTLWluLVVEUCBlbmNh cHN1bGF0aW9uIHRlY2hub2xvZ3kgTVVTVCBvbmx5IGJlIGRlcGxveWVkIHdpdGhpbiBhIFNQDQo+ IG5ldHdvcmsgb3IgbmV0d29ya3Mgb2YgYW4gYWRqYWNlbnQgc2V0IG9mIGNvLW9wZXJhdGluZyBT UHMgd2hlcmUgdGhlDQo+IGNvbmdlc3Rpb24gY29udHJvbCBpcyBub3QgYSBjb25jZXJuLCByYXRo ZXIgdGhhbiBvdmVyIHRoZSBJbnRlcm5ldCB3aGVyZSB0aGUNCj4gY29uZ2VzdGlvbiBjb250cm9s IGlzIGEgbXVzdC4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3VsZCBiZSBhZGRlZCB0 bw0KPiBwcmV2ZW50IE1QTFMgb3ZlciBVRFAgcGFja2V0cyBmcm9tIGVzY2FwaW5nIGZyb20gdGhl IHNlcnZpY2UgcHJvdmlkZXINCj4gbmV0d29ya3MgZHVlIHRvIG1pc2NvbmZpZ3VhdGlvbiBvciBw YWNrZXQgZXJyb3JzLiBOb3RlIHRoYXQgdGhlIHByb3Zlbg0KPiBNUExTLWluLUdSRSBhbmQgTVBM Uy1pbi1JUCBbUkZDNDAyM10gZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2dpZXMgd2hpY2ggaGF2ZQ0K PiBhbHJlYWR5IGJlZW4gZGVwbG95ZWQgd2l0aGluIFNQIG5ldHdvcmtzIGRvbid0IHJlcXVpcmUg YW55IGNvbmdlc3Rpb24gY29udHJvbA0KPiBtZWNoYW5pc20uDQo+IA0KPiBJbiBhZGRpdGlvbiwg dGhlIGZvbGxvd2luZyB0ZXh0IGlzIGFkZGVkIHRvIHRoZSBhYnN0cmFjdCBzZWN0aW9uOiIgTm90 ZSB0aGF0IHRoZQ0KPiBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kgTVVTVCBv bmx5IGJlIGRlcGxveWVkIHdpdGhpbiBhIFNQDQo+IG5ldHdvcmsgb3IgbmV0d29ya3Mgb2YgYW4g YWRqYWNlbnQgc2V0IG9mIGNvLW9wZXJhdGluZyBTUHMgd2hlcmUgdGhlDQo+IGNvbmdlc3Rpb24g Y29udHJvbCBpcyBub3QgYSBjb25jZXJuLiINCj4gDQo+IER1ZSB0byB0aGUgYWJvdmUgZXhwbGlj aXQgYXBwbGljYXRpb24gc3RhdGVtZW50LCBJIHdvbmRlciB3aGV0aGVyIGl0J3Mgc3RpbGwNCj4g bmVjZXNzYXJ5IHRvIGRlc2NyaWJlIHRoZSBPQU0gY29udHJvbCBsb29wIGluIChzb21lKSBtb3Jl IGRldGFpbCwgcmF0aGVyIHRoYW4NCj4gc2ltcGx5IHBvaW50aW5nIHRvIFJGQzM5ODUuIEkgZXZl biB3b25kZXIgd2hldGhlciBpdCdzIHN0aWxsIG5lY2Vzc2FyeSB0byByZW1haW4NCj4gdGhlIGNv bmdlc3Rpb24gY29uc2lkZXJhdGlvbiBzZWN0aW9uLg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBY aWFvaHUNCj4gDQo+ID4gTGFycw0K From edc@google.com Thu Jan 23 18:29:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E981A0111 for ; Thu, 23 Jan 2014 18:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.876 X-Spam-Level: X-Spam-Status: No, score=0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.535, 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 hxrkyHAPWYO4 for ; Thu, 23 Jan 2014 18:29:02 -0800 (PST) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE261A0098 for ; Thu, 23 Jan 2014 18:29:01 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j5so3190531qaq.6 for ; Thu, 23 Jan 2014 18:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=P1Y5fUY544SWrfMUdBv+fLEx9a5UGoIYBMNgc/tm1kM=; b=JNH73IzJu0yDJECRMdoHUQBv771HOSqPL5K8P+X8A8to8v9V3Ml4RXEZna8xlZhIbL ftrsBL6ZDzKelqY7Ua15yHzko2fB+0AwmLIR7DtD09b5fMVbhn5n/qvfCvWKNdC8vqpV GOnxgBRrhDxdZpUt+tYMHkS8ag9D3fITioPH06LvdVATkAM+YfwMVSMLbH8BJ7VMCvru Om/gThfDMBfUhrWVKvifrUd9kpU3K2fjwPlnmgUELhjdOpATBlOfLVC/s2+zOqz8feeX X1xTE5ywe39g7lXdie7EVqE5+D+FzKkvPcvEUTX4m3bjX3SFTH/AGEkxOpa7xAhzmXnf qLEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=P1Y5fUY544SWrfMUdBv+fLEx9a5UGoIYBMNgc/tm1kM=; b=N8R+CC0p8Bu8mYd2kaTu3IpzB0tuD3fQtE1R2T6J8Ik1I8tsNzJRjXR3Dtw2DslDr/ mKnhjT9SACqbFoypyslXgOwBY/jnMXhsBDsFXfEO/jeuvPkHgQfr6KmTdjn3PWSs+Qd2 58V/kRLQyPawL7G+YwviJLPCiPwJySura9KzWZ0c/YDPFRQidYbalY6DZkShG/GEZuGt 20Dw1qnx6K/koDJkHAHltSDddSQR7y6FwrzpmMCirGp8yy51lDZV3p3MbQ75R/Dlyfhl hCGGPAs4qivHw+y6kKijVgu0FAHhSr7rep9YGR95bcpX7EuINlNPEfC1z7ZDvDxa7ZKt Wf/A== X-Gm-Message-State: ALoCoQkmbrAuJCafmKw77bYLla7tIsWbjtNcAuGXureHagF30P9Q44gsYXaYCUrAPpwbQtxQXlBkGX8SYwJVajrj4eVdGhlbeTx5WhmULl3qyydVKfB7MvJWnWXw5dfNMHocXlUxim4lEQ9o6NlrT1DLfwv/7s1sZdYjpDPGzRhDAvALFDpV0MJn1OcUBs1yRa0Cz8Q7JyAC X-Received: by 10.224.115.78 with SMTP id h14mr16854383qaq.94.1390530540580; Thu, 23 Jan 2014 18:29:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.86.130 with HTTP; Thu, 23 Jan 2014 18:28:20 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478D0@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478D0@NKGEML512-MBS.china.huawei.com> From: Edward Crabbe Date: Thu, 23 Jan 2014 18:28:20 -0800 Message-ID: To: Xuxiaohu Content-Type: multipart/alternative; boundary=047d7bdc78d0ebccae04f0ae1ef5 Cc: Joel Jaeggli , "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:29:04 -0000 --047d7bdc78d0ebccae04f0ae1ef5 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable "the MPLS-in-UDP encapsulation SHOULD only be deployed on an intradomain basis, and SHOULD not generally traverse interdomain boundaries" On Thu, Jan 23, 2014 at 6:22 PM, Xuxiaohu wrote: > Hi Lars and all, > > I think a congestion consideration section containing the following text > could be remained for people to know the background for the application > statements. > > 5. Congestion Considerations > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded > through "UDP tunnels", the congestion control guidelines for UDP tunnels = as > defined in [RFC5405] SHOULD be followed. Specifically, as stated in Secti= on > 3.1.3 of [RFC5405] "...Finally, some bulk transfer applications may choos= e > not to implement any congestion control mechanism and instead rely on > transmitting across reserved path capacity. This might be an acceptable > choice for a subset of restricted networking environments, but is by no > means a safe practice for operation in the Internet. " Due to the fact th= at > the proven MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation technologie= s > have been successfully deployed within SP networks without any congestion > control mechanism and the fact that the current MPLS technology couldn't > provide congestion control without major changes, the MPLS-in-UDP > encapsulation MUST only be deployed in SP networks which is a restricted > network environment. > > Best regards, > Xiaohu > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Xuxiaohu > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C223=C8=D5 11:01 > > =CA=D5=BC=FE=C8=CB: 'Eggert, Lars' > > =B3=AD=CB=CD: curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org > > =D6=F7=CC=E2: re: [mpls] Last Call: (En= capsulating > MPLS in > > UDP) to Proposed Standard > > > > Hi Lars, > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: Eggert, Lars [mailto:lars@netapp.com] > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C222=C8=D5 18:23 > > > =CA=D5=BC=FE=C8=CB: Xuxiaohu > > > =B3=AD=CB=CD: curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org > > > =D6=F7=CC=E2: Re: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > Hi, > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > I wonder whether the following text is OK to you: > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > > > forwarded > > > through "UDP tunnels", the congestion control guidelines for UDP > > > tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. > > > Specifically, MPLS can carry a number of different protocols as > > > payloads. When an UDP tunnel is used for MPLS payload traffic that is > > > known at configuration time to be IP-based and congestion-controlled, > > > the UDP tunnel SHOULD NOT employ its own congestion control mechanism= , > > > because congestion losses of tunneled traffic will trigger an > congestion > > response at the original senders of the tunneled traffic. > > > When an UDP tunnel is used for MPLS payload traffic that is known at > > > configuration time not to be IP-based and congestion-controlled, the > > > UDP tunnel SHOULD employ an appropriate congestion control mechanism > > > as described in [RFC3985]. Note that it STRONGLY RECOMMENDED to deplo= y > > > such encapsulation technology only within a SP network or networks of > > > an adjacent set of co-operating SPs, rather than over the Internet. > > > Furthermore, packet filters should be added to block traffic with the > > > UDP port number for MPLS over UDP to prevent MPLS over UDP packets to > > > escape from the service provider networks due to misconfiguation or > packet > > errors. > > > > > > I think it would be better to describe the OAM control loop in (some) > > > more detail, rather than pointing to RFC3985, which doesn't have a > > > whole lot of detail either. Also because the adding of firewall rules > requires an > > OAM hook. > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > RECOMMENDED is > > > too weak, I'd suggest to change this to MUST. > > > > It's fine to make that change. > > > > > Finally, the applicability statement should be prominently made in th= e > > > abstract, introduction, etc. > > > > The application statement is prominently described in a dedicated > sub-section of > > the Introduction Section as follows: > > > > 1.3. Application Statements > > > > The MPLS-in-UDP encapsulation technology MUST only be deployed within a > SP > > network or networks of an adjacent set of co-operating SPs where the > > congestion control is not a concern, rather than over the Internet wher= e > the > > congestion control is a must. Furthermore, packet filters should be > added to > > prevent MPLS over UDP packets from escaping from the service provider > > networks due to misconfiguation or packet errors. Note that the proven > > MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation technologies which > have > > already been deployed within SP networks don't require any congestion > control > > mechanism. > > > > In addition, the following text is added to the abstract section:" Note > that the > > MPLS-in-UDP encapsulation technology MUST only be deployed within a SP > > network or networks of an adjacent set of co-operating SPs where the > > congestion control is not a concern." > > > > Due to the above explicit application statement, I wonder whether it's > still > > necessary to describe the OAM control loop in (some) more detail, rathe= r > than > > simply pointing to RFC3985. I even wonder whether it's still necessary > to remain > > the congestion consideration section. > > > > Best regards, > > Xiaohu > > > > > Lars > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7bdc78d0ebccae04f0ae1ef5 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
"the MPLS-in-UDP encapsulation SHOULD only be deployed on an intrado= main basis, and SHOULD not generally traverse interdomain boundaries"<= /span>


On Thu,= Jan 23, 2014 at 6:22 PM, Xuxiaohu <xuxiaohu@huawei.com> w= rote:
Hi Lars and all,

I think a congestion consideration section containing the following text co= uld be remained for people to know the background for the application state= ments.

5. Congestion Considerations

Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded thr= ough "UDP tunnels", the congestion control guidelines for UDP tun= nels as defined in [RFC5405] SHOULD be followed. Specifically, as stated in= Section 3.1.3 of [RFC5405] "...Finally, some bulk transfer applicatio= ns may choose not to implement any congestion control mechanism and instead= rely on transmitting across reserved path capacity. This might be an accep= table choice for a subset of restricted networking environments, but is by = no means a safe practice for operation in the Internet. " Due to the f= act that the proven MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation tech= nologies have been successfully deployed within SP networks without any con= gestion control mechanism and the fact that the current MPLS technology cou= ldn't provide congestion control without major changes, the MPLS-in-UDP= encapsulation MUST only be deployed in SP networks which is a restricted n= etwork environment.

Best regards,
Xiaohu

> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Xuxiaohu
> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C223=C8=D5 11:01
> =CA=D5=BC=FE=C8=CB: 'Eggert, Lars'
> =B3=AD=CB=CD: curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org
> =D6=F7=CC=E2: re: [mpls] Last Call: <draft-= ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in
> UDP) to Proposed Standard
>
> Hi Lars,
>
> > -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> > =B7=A2=BC=FE=C8=CB: Eggert, Lars [mailto:lars@netapp.com]
> > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C222=C8=D5 18:23
> > =CA=D5=BC=FE=C8=CB: Xuxiaohu
> > =B3=AD=CB=CD: curt= is@ipv6.occnc.com; Joel Jaeggli; mpls@= ietf.org
> > =D6=F7=CC=E2: Re: [mpls] Last Call: <draft-i= etf-mpls-in-udp-04.txt>
> > (Encapsulating MPLS in UDP) to Proposed Standard
> >
> > Hi,
> >
> > On 2014-1-22, at 11:12, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> > > I wonder whether the following text is OK to you:
> > >
> > > Since the MPLS-in-UDP encapsulation causes MPLS packets to b= e
> > > forwarded
> > through "UDP tunnels", the congestion control guideline= s for UDP
> > tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be follow= ed.
> > Specifically, MPLS can carry a number of different protocols as > > payloads. When an UDP tunnel is used for MPLS payload traffic tha= t is
> > known at configuration time to be IP-based and congestion-control= led,
> > the UDP tunnel SHOULD NOT employ its own congestion control mecha= nism,
> > because congestion losses of tunneled traffic will trigger an con= gestion
> response at the original senders of the tunneled traffic.
> > When an UDP tunnel is used for MPLS payload traffic that is known= at
> > configuration time not to be IP-based and congestion-controlled, = the
> > UDP tunnel SHOULD employ an appropriate congestion control mechan= ism
> > as described in [RFC3985]. Note that it STRONGLY RECOMMENDED to d= eploy
> > such encapsulation technology only within a SP network or network= s of
> > an adjacent set of co-operating SPs, rather than over the Interne= t.
> > Furthermore, packet filters should be added to block traffic with= the
> > UDP port number for MPLS over UDP to prevent MPLS over UDP packet= s to
> > escape from the service provider networks due to misconfiguation = or packet
> errors.
> >
> > I think it would be better to describe the OAM control loop in (s= ome)
> > more detail, rather than pointing to RFC3985, which doesn't h= ave a
> > whole lot of detail either. Also because the adding of firewall r= ules requires an
> OAM hook.
> >
> > Since STRONGLY RECOMMENDED is not an RFC2119 term and
> RECOMMENDED is
> > too weak, I'd suggest to change this to MUST.
>
> It's fine to make that change.
>
> > Finally, the applicability statement shou= ld be prominently made in the
> > abstract, introduction, etc.
>
> The application statement is prominently descr= ibed in a dedicated sub-section of
> the Introduction Section as follows:
>
> 1.3. Application Statements
>
> The MPLS-in-UDP encapsulation technology MUST only be deployed w= ithin a SP
> network or networks of an adjacent set of co-operati= ng SPs where the
> congestion control is not a concern, rather than over the Internet whe= re the
> congestion control is a must. Furthermore, packet filters should= be added to
> prevent MPLS over UDP packets from escaping from the service provider<= br>
> networks due to misconfiguation or packet errors. No= te that the proven
> MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation technologies which = have
> already been deployed within SP networks don't require any congest= ion control
> mechanism.
>
> In addition, the following text is added to the abstract section:"= ; Note that the
> MPLS-in-UDP encapsulation technology MUST only be deployed withi= n a SP
> network or networks of an adjacent set of co-operati= ng SPs where the
> congestion control is not a concern."
>
> Due to the above explicit application statement, I wonder whether it&#= 39;s still
> necessary to describe the OAM control loop in (some) more detail= , rather than
> simply pointing to RFC3985. I even wonder whe= ther it's still necessary to remain
> the congestion consideration section.
>
> Best regards,
> Xiaohu
>
> > Lars
_____________________________= __________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7bdc78d0ebccae04f0ae1ef5-- From l.wood@surrey.ac.uk Thu Jan 23 18:30:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6DE1A0195 for ; Thu, 23 Jan 2014 18:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 SiCDbQz8x-kq for ; Thu, 23 Jan 2014 18:30:15 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.167]) by ietfa.amsl.com (Postfix) with ESMTP id B501E1A0189 for ; Thu, 23 Jan 2014 18:30:14 -0800 (PST) Received: from [195.245.230.131:2969] by server-7.bemta-3.messagelabs.com id 1C/8F-27599-430D1E25; Fri, 24 Jan 2014 02:30:12 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-2.tower-78.messagelabs.com!1390530612!23646957!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19012 invoked from network); 24 Jan 2014 02:30:12 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-2.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jan 2014 02:30:12 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 24 Jan 2014 02:30:11 +0000 From: To: , , Date: Fri, 24 Jan 2014 02:30:10 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiOAAIGV4IAASynFgAB+v4CAAAUDQYAAAhRggAAIfvuAAAIPgIAAASaAgAALJEA= Message-ID: <290E20B455C66743BE178C5C84F1240847E63346E9@EXMB01CMS.surrey.ac.uk> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082477E6@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824784D@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E8@EXMB01CMS.surrey.ac.uk> ,<1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478AB@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478AB@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:30:19 -0000 SSBhbSBub3QgYWdhaW5zdCB0aGUgYnVsayBvZiBSRkM2OTM2LiBCdXQgdW5saWtlICczNiwNClJG QzY5MzUgaXMgdmVyeSBtdWNoIHdyaXR0ZW4gZm9yIHRoZSBiZW5lZml0IG9mIHR1bm5lbGVycy4N Cg0KUkZDNjkzNSBhbmQgMzYgY2FuIGJlIHJlYWQgdG8gZ2l2ZSBjb25mbGljdGluZyBhZHZpY2Ug KDM1IC0gemVybyENCjM2IC0gdW0sIHRoYXQgbGVhZHMgdG8gdGhlc2Ugc3VidGxlIGFuZCBudWFu Y2VkIHBycm9ibGVtcywgc28gbWF5YmUgbm90KSwNCnNvIGp1c3QgcmVmZXJyaW5nIHRvIHRoZW0g YW5kIGxlYXZpbmcgdGhlIGltcGxlbWVudGVyIHdpdGhvdXQgY2xlYXINCmRpcmVjdGlvbiBpcyBu b3Qgc3VmZmljaWVudCBpbW8uDQoNClJGQzY5MzUgaXMgY29uc2lkZXJpbmcgIHR1bm5lbGxlZCB0 cmFmZmljLCBub3QgdGhlIGVmZmVjdCBvbiBvdGhlciB0cmFmZmljLA0KcG9ydHMgYW5kIGRlc3Rp bmF0aW9ucywgd2hpY2ggUkZDNjkzNiB3YXJucyBhZ2FpbnN0LkJ1dCBldmVuIFJGQzY5MzUsDQp3 aGljaCBwcmltYXJpbHkgY29uc2lkZXJzIHRoZSBjb3N0cy9iZW5lZml0cyB0byB0dW5uZWxzLCBu b3QgdG8gdHJhZmZpYyBzaGFyaW5nDQp0aGUgbmV0d29yayB3aXRoIHR1bm5lbHMgZG9lcyBzYXk6 DQoNCiAgT25lIHVuZm9ydHVuYXRlIHNpZGUgZWZmZWN0IG9mIGluY3JlYXNlZCB1c2Ugb2YgYSB6 ZXJvIGNoZWNrc3VtIGlzDQogICB0aGF0IGl0IGFsc28gaW5jcmVhc2VzIHRoZSBsaWtlbGlob29k IG9mIGFjY2VwdGFuY2Ugd2hlbiBhIGRhdGFncmFtDQogICB3aXRoIGEgemVybyBVRFAgY2hlY2tz dW0gaXMgbWlzZGVsaXZlcmVkLg0KDQpVbmZvcnR1bmF0ZSwgYnV0IG5vdCBmb3IgdGhlIHR1bm5l bCwgd2hpY2gganVzdCBzZWVzIGEgZHJvcC4NCg0KLi53aGljaCBpcyB3aHkgdGhlIHRleHQgSSBw cm9wb3NlIHNheXMgJ1NIT1VMRCcgdXNlIGEgY2hlY2tzdW0sIHdoaWxlDQphY2tub3dsZWRnaW5n IHRoYXQgcGVyZm9ybWFuY2UgYW5kIGltcGxlbWVudGF0aW9uIHJlYXNvbnMgbWF5IGRpY3RhdGUN Cm90aGVyd2lzZS4NCg0KPiBOb3RlIHRoYXQgb3RoZXIgSVAgZW5jYXBzdWxhdGlvbnMgZm9yIE1Q TFMgZG8gbm90DQo+IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCg0KT3Ro ZXIgZW5jYXBzdWxhdGlvbnMgZG9uJ3QgaGF2ZSBVRFAgcG9ydHMgdGhhdCBjYW4gYmUgY29ycnVw dGVkLA0Kc28gZXZlbiBpZiB0aGUgYWRkcmVzcyBpcyBjb3JydXB0ZWQsIGRlY2Fwc3VsYXRpb24g YXQgYW5vdGhlciB0dW5uZWwNCmVuZHBvaW50IGlzIGZhciBsZXNzIGxpa2VseS4gQnV0IGhvc3Rz IHN1cHBvcnRpbmcgVURQIHNlcnZpY2VzIGFyZQ0KdmVyeSB2ZXJ5IGNvbW1vbi4NCg0KTGxveWQg V29vZA0KaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5jb21dDQpT ZW50OiAyNCBKYW51YXJ5IDIwMTQgMDE6MzgNClRvOiBYdXhpYW9odTsgV29vZCBMICBEciAoRWxl Y3Ryb25pYyBFbmcpOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRh cHAuY29tDQpDYzogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogcmU6 IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fw c3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCj4gLS0tLS3Tyrz+ 1K28/i0tLS0tDQo+ILeivP7IyzogWHV4aWFvaHUNCj4gt6LLzcqxvOQ6IDIwMTTE6jHUwjI0yNUg OTozNg0KPiDK1bz+yMs6ICdsLndvb2RAc3VycmV5LmFjLnVrJzsgQWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb207DQo+IGxhcnNAbmV0YXBwLmNvbQ0KPiCzrcvNOiBqb2VsamFAYm9ndXMu Y29tOyBtcGxzQGlldGYub3JnDQo+INb3zOI6ILTwuLQ6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFm dC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcNCj4gTVBMUyBpbiBVRFAp IHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+DQo+IEhpLA0KPg0KPiBTaW5jZSB5b3UgYXJlIG5vdCBh Z2FpbnN0IFJGQzY5MzYgYW5kIFJGQzY5MzUsIGhvdyBhYm91dCBtYWtpbmcgdGhlDQo+IGZvbGxv d2luZyBjaGFuZ2U6DQo+DQo+IE9MRDoNCj4NCj4gSW4gdGhlIElQdjYgVURQIGVuY2Fwc3VsYXRp b24gY2FzZSwgaWYgYXBwcm9wcmlhdGUgYWNjb3JkaW5nIHRvIHRoZQ0KPiByZXF1aXJlbWVudHMg ZGVmaW5lZCBpbiBbUkZDNjkzNV0gW1JGQzY5MzZdLCB0aGlzIGZpZWxkIGlzIGFsc28gUkVDT01N RU5ERUQNCj4gdG8gYmUgc2V0IHRvIHplcm8uIFNwZWNpZmljYWxseSwgaWYgdGhlIE1QTFMgcGF5 bG9hZCBpcyBJbnRlcm5ldCBQcm90b2NvbCAoSVB2NCBvcg0KPiBJUHY2KSBwYWNrZXRzLCBpdCBp cyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyB3aGVuIHRoZSBpbm5lciBwYWNrZXQNCj4g aW50ZWdyaXR5IGNoZWNrcyBpcyBhdmFpbGFibGUuIEluIGFkZGl0aW9uLCBpZiB0aGUgTVBMUyBw YXlsb2FkIGlzIG5vbi1JUCBwYWNrZXQNCj4gd2hpY2ggaXMgc3BlY2lmaWNhbGx5IGRlc2lnbmVk IGZvciB0cmFuc21pc3Npb24gb3ZlciBhIGxvd2VyIGxheWVyIHRoYXQgZG9lcyBub3QNCj4gcHJv dmlkZSBhIHBhY2tldCBpbnRlZ3JpdHkgZ3VhcmFudGVlLCBpdCBpcyBSRUNPTU1FTkRFRCB0byBi ZSBzZXQgdG8gemVybyBhcw0KPiB3ZWxsLiBPdGhlcndpc2UsIHVzaW5nIHplcm8gY2hlY2tzdW0g aXMgTk9UIFJFQ09NTUVOREVELiBOb3RlIHRoYXQgb3RoZXINCj4gSVAgZW5jYXBzdWxhdGlvbnMg Zm9yIE1QTFMgZG8gbm90IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCj4N Cj4gTkVXOg0KPg0KPiBJbiB0aGUgSVB2NiBVRFAgZW5jYXBzdWxhdGlvbiBjYXNlLCBhcyBmb3Ig d2hldGhlciBvciBub3QgaXQgaXMgc3VpdGFibGUgdG8gdXNlIHRoZQ0KPiB6ZXJvLWNoZWNrc3Vt IG5vZGUsIHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbiBbUkZDNjkzNV0gW1JGQzY5MzZdDQoN CnMvbm9kZS9tb2RlDQoNCj4gU0hPVUxEIGJlIHN0cmljdGx5IGZvbGxvd2VkLiBOb3RlIHRoYXQg b3RoZXIgSVAgZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMgZG8gbm90DQo+IGhhdmUgYSBjaGVja3N1 bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCj4NCj4gWGlhb2h1DQo+DQo+ID4gLS0tLS3Tyrz+1K28 /i0tLS0tDQo+ID4gt6K8/sjLOiBsLndvb2RAc3VycmV5LmFjLnVrIFttYWlsdG86bC53b29kQHN1 cnJleS5hYy51a10NCj4gPiC3osvNyrG85DogMjAxNMTqMdTCMjTI1SA5OjI2DQo+ID4gytW8/sjL OiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBw LmNvbQ0KPiA+ILOty806IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiDW98zi OiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0K PiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ DQo+ID4gRm9yIHRoZSByZWFzb25zIG91dGxpbmVkIGluIFJGQzY5MzYgc2VjdGlvbiAzLCB3aGlj aCBJIGNpdGVkLCBhbmQgZm9yDQo+ID4gdGhlIGRhbmdlciB0byBvdGhlciB0cmFmZmljLCB3aGlj aCB3ZSBoYXZlIGRpc2N1c3NlZCBpbiB0aGlzIHRocmVhZC4NCj4gPg0KPiA+IEkgcXVvdGUgUkZD MzkzNjoNCj4gPg0KPiA+ICBDdXJyZW50bHksIGZvciB0aGUgZ2VuZXJhbCBJbnRlcm5ldCwgdGhl cmUgaXMgbm8gZXZpZGVuY2UgdGhhdA0KPiA+IGNvcnJ1cHRpb24gaXMgcmFyZSwgbm9yIGlzIHRo ZXJlIGV2aWRlbmNlIHRoYXQgY29ycnVwdGlvbiBpbiBJUHY2IGlzDQo+ID4gcmFyZS4gVGhlcmVm b3JlLCBpdCBzZWVtcyBwcnVkZW50IG5vdCB0byByZWxheCBjaGVja3Mgb24gIG1pc2RlbGl2ZXJ5 Lg0KPiA+DQo+ID4NCj4gPiBMbG95ZCBXb29kDQo+ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29v ZA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBGcm9t OiBYdXhpYW9odSBbeHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPiBTZW50OiAyNCBKYW51YXJ5IDIw MTQgMDE6MDANCj4gPiBUbzogV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpOyBBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsNCj4gPiBsYXJzQG5ldGFwcC5jb20NCj4gPiBDYzogam9l bGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6ILTwuLQ6IFttcGxzXSBM YXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiAoRW5jYXBzdWxh dGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPg0KPiA+IFdlIGFyZSB0 YWxraW5nIGFib3V0IHVzaW5nIFVEUCBhcyBhIHR1bm5lbCBmb3IgTVBMUyB0cmFmZmljLiBTbyB3 aHkNCj4gPiBjYW4ndCBhbGxvdyB0aGUgVURQIHR1bm5lbCB0byB1c2UgemVybyBjaGVja3N1bXMg Zm9yIHBlcmZvcm1hbmNlLA0KPiA+IHdoaWNoIGlzIHRoZSByZWNvbW1lbmRhdGlvbiBmcm9tIFJG QzY5MzUuDQo+ID4NCj4gPiBYaWFvaHUNCj4gPg0KPiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ ID4gPiC3orz+yMs6IGwud29vZEBzdXJyZXkuYWMudWsgW21haWx0bzpsLndvb2RAc3VycmV5LmFj LnVrXQ0KPiA+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjI0yNUgODo0OA0KPiA+ID4gytW8/sjLOiBY dXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBwLmNv bQ0KPiA+ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4g1vfM 4jogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4N Cj4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0K PiA+ID4NCj4gPiA+IFJGQzY5MzUgd2FzIHdyaXR0ZW4gZnJvbSBhIHR1bm5lbGxpbmcgcGVyc3Bl Y3RpdmUsIHRvIGFsbG93DQo+ID4gPiB0dW5uZWxsaW5nIHRvIHVzZSB6ZXJvIGNoZWNrc3VtcyBm b3IgcGVyZm9ybWFuY2UsIGFuZCBhbmFseXNlZCByaXNrcw0KPiA+ID4gdG8gdGhlIHR1bm5lbCB0 cmFmZmljIC0gYnV0IG5vdCB0byBvdGhlciB1c2Vycy4NCj4gPiA+DQo+ID4gPiAgICAiV2hpbGUg dGhlIG1ldGhvZHMgZG8NCj4gPiA+ICAgIG5vdCBndWFyYW50ZWUgY29ycmVjdG5lc3MsIHRoZXkg Y2FuIHJlZHVjZSB0aGUgcmlza3Mgb2YgcmVsYXhpbmcgdGhlDQo+ID4gPiAgICBVRFAgY2hlY2tz dW0gcmVxdWlyZW1lbnQgZm9yIGEgdHVubmVsIGFwcGxpY2F0aW9uIHVzaW5nIElQdjYuIg0KPiA+ ID4NCj4gPiA+IFJpc2tzIHRvIG90aGVyIGFwcGxpY2F0aW9ucyBhcmUgbm90IGFzc2Vzc2VkLCBh bmQgbm90IHN0YXRlZC4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gTGxveWQgV29vZA0KPiA+ID4gaHR0 cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+ID4gRnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5jb21d DQo+ID4gPiBTZW50OiAyNCBKYW51YXJ5IDIwMTQgMDA6MzQNCj4gPiA+IFRvOiBXb29kIEwgIERy IChFbGVjdHJvbmljIEVuZyk7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0KPiA+ ID4gbGFyc0BuZXRhcHAuY29tDQo+ID4gPiBDYzogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRm Lm9yZw0KPiA+ID4gU3ViamVjdDogtPC4tDogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYt bXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRv IFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPg0KPiA+ID4gSXQgc2VlbXMgdGhhdCB5b3UgYXJlIGFn YWluc3QgUkZDNjkzNSBhbmQgUkZDNjkzNiwgcmlnaHQ/DQo+ID4gPg0KPiA+ID4gWGlhb2h1DQo+ ID4gPg0KPiA+ID4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ID4gt6K8/sjLOiBsLndvb2RA c3VycmV5LmFjLnVrIFttYWlsdG86bC53b29kQHN1cnJleS5hYy51a10NCj4gPiA+ID4gt6LLzcqx vOQ6IDIwMTTE6jHUwjI0yNUgMToxOA0KPiA+ID4gPiDK1bz+yMs6IFh1eGlhb2h1OyBBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tDQo+ID4gPiA+ILOty806 IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4g1vfM4jogUkU6IFttcGxz XSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gKEVu Y2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPiA+DQo+ ID4gPiA+IHRoZSB0ZXh0IGlzIG5vdCBzYXRpc2ZhY3RvcnkuIG5ldmVyIHJlY29tbWVuZCBzZXR0 aW5nIHRvIHplcm8sIGFzDQo+ID4gPiA+IHRoYXQgcG9zZXMgYSByaXNrIHRvIHlvdXIgYW5kIHRv IG90aGVyIHRyYWZmaWMuIFN1Z2dlc3RlZCB0ZXh0Og0KPiA+ID4gPiAqKioNCj4gPiA+ID4gVGhl IFVEUCBjaGVja3N1bSBTSE9VTEQgYmUgdXNlZCB0byBwcm90ZWN0IHRoZSBwYXlsb2FkIGFuZCBl bnN1cmUNCj4gPiA+ID4gY29ycmVjdCBkZW11bHRpcGxleGluZyBhbmQgZGVsaXZlcnkgdG8gdGhl IHR1bm5lbCwgYW5kIG5vdCB0bw0KPiA+ID4gPiBvdGhlciBVRFAgZGVzdGluYXRpb25zLCBieSBw cm90ZWN0aW5nIHRoZSBVRFAgcHNldWRvaGVhZGVyLg0KPiA+ID4gPiBVc2Ugb2YgYSB6ZXJvIFVE UCBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQsIGV2ZW4gd2hlbiBkZXNpcmVkDQo+ID4gPiA+ IGZvciBwZXJmb3JtYW5jZSBvciBuZWNlc3NpdGF0ZWQgYnkgaW1wbGVtZW50YXRpb24gcmVhc29u cywgZm9yIHRoZQ0KPiA+ID4gPiByZWFzb25zIG91dGxpbmVkIGluIFtSRkM2OTM2XSBzZWN0aW9u IDMuDQo+ID4gPiA+DQo+ID4gPiA+IFVEUC1MaXRlIFtSRkMzODI4XSBjYW4gcHJvdmlkZSBhIGRl bXVsdGlwbGV4aW5nIGNoZWNrIGFuZCBNUExTDQo+ID4gPiA+IHN0YWNrIGludGVncml0eSBjaGVj ayB3aGlsZSBhdm9pZGluZyB0aGUgb3ZlcmhlYWQgb2YgY29tcHV0aW5nIGFuDQo+ID4gPiA+IGlu dGVncml0eSBjaGVjayBvdmVyIGEgdHVubmVsbGVkIGZyYW1lIHRoYXQgaGFzIGl0cyBvd24gaW50 ZWdyaXR5IGNoZWNrLg0KPiA+ID4gPiAqKioNCj4gPiA+ID4NCj4gPiA+ID4gTGxveWQgV29vZA0K PiA+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRnJvbTogWHV4aWFvaHUgW3h1eGlh b2h1QGh1YXdlaS5jb21dDQo+ID4gPiA+IFNlbnQ6IDIzIEphbnVhcnkgMjAxNCAxMjozNQ0KPiA+ ID4gPiBUbzogV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpOyBBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTsNCj4gPiA+ID4gbGFyc0BuZXRhcHAuY29tDQo+ID4gPiA+IENjOiBqb2Vs amFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IHJlOiBbbXBsc10g TGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiA+IChFbmNh cHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPg0KPiA+ ID4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ID4gPiA+ILeivP7IyzogbC53b29kQHN1cnJl eS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ID4gPiA+ID4gt6LLzcqxvOQ6 IDIwMTTE6jHUwjIzyNUgMTI6NDQNCj4gPiA+ID4gPiDK1bz+yMs6IFh1eGlhb2h1OyBBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsNCj4gbGFyc0BuZXRhcHAuY29tDQo+ID4gPiA+ID4g s63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+INb3zOI6IFJF OiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4g PiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBTYXNoYQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtIFVEUCBj aGVja3N1bXMgKG9yIGxhY2sgdGhlcmVvZikgaXMgYSBub24taXNzdWUgYmVjYXVzZQ0KPiA+ID4g PiA+ID4gbmF0aXZlIE1QTFMgZG9lcyBub3QgaGF2ZSBhbnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5 ZXMsIHRoZXJlDQo+ID4gPiA+ID4gPiBhcmUgY2FzZXMgd2hlcmUgcGFja2V0cyBhcmUgY29ycnVw dGVkIHdpdGhpbiB0aGUgcm91dGVycykNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFNvIHlvdSBhZG1p dCB0aGF0IHBhY2tldHMgY2FuIGJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMgLQ0KPiA+ ID4gPiA+IGEgY2hlY2sgdGhhdCBjYW4gb25seSBiZSBjYXVnaHQgYnkgYW4gZW5kLXRvLWVuZCBj aGVjaywgYQ0KPiA+ID4gPiA+IGNvcnJ1cHRpb24gdGhhdCBjYW4gbGVhZCB0byB0aGUgcHJvYmxl bXMgZGV0YWlsZWQgaW4gUkZDIDY5MzYNCj4gPiA+ID4gPiBzZWN0aW9uIDMgLSBhbmQgdGhlbiB5 b3Ugc2F5IGl0J3MgYSBub24taXNzdWUgYmVjYXVzZSB0aGlzDQo+ID4gPiA+ID4gZG9lc24ndCBh ZmZlY3QgbmF0aXZlIE1QTFMuIEJ1dCB3ZSdyZQ0KPiA+ID4gPiBub3QgZG9pbmcgbmF0aXZlIE1Q TFMgaGVyZS4NCj4gPiA+ID4gPiBXZSdyZSBkb2luZyBNUExTIG92ZXIgVURQLg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQgaXMgYWJvdXQgdHVubmVs bGluZyBNUExTIGluIFVEUC4gSXQncyBhbg0KPiBpc3N1ZS4NCj4gPiA+ID4gPiBQbGVhc2UgcmVh ZCB0aGUgb3RoZXIgMTUwIG1lc3NhZ2VzIHRoYXQgeW91IHJlZmVyIHRvLg0KPiA+ID4gPg0KPiA+ ID4gPiBIaSBMbG95ZCwNCj4gPiA+ID4NCj4gPiA+ID4gVGhlIGRyYWZ0IGRvZXNuJ3QgcmVxdWly ZSB0aGUgSVB2NiBVRFAgY2hlY2tzdW0gdG8gYmUgc2V0IHRvIHplcm8NCj4gPiByZWdhcmRsZXNz Lg0KPiA+ID4gPiBTZWUgdGhlIGZvbGxvd2luZyB0ZXh0IHF1b3RlZCBmcm9tIHRoYXQgZHJhZnQ6 DQo+ID4gPiA+DQo+ID4gPiA+IFVEUCBDaGVja3N1bQ0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgdXNh Z2Ugb2YgdGhpcyBmaWVsZCBpcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGN1cnJlbnQgVURQDQo+ ID4gPiA+IHNwZWNpZmljYXRpb24gW1JGQzc2OF0uIFRvIHNpbXBsaWZ5IHRoZSBvcGVyYXRpb24g b24gdGhlDQo+ID4gPiA+IGRlY2Fwc3VsYXRvciwgdGhpcyBmaWVsZCBpcyBSRUNPTU1FTkRFRCB0 byBiZSBzZXQgdG8gemVybyBpbiBJUHY0DQo+ID4gPiA+IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2Uu IEluIHRoZSBJUHY2IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2UsIGlmDQo+ID4gPiA+IGFwcHJvcHJp YXRlIGFjY29yZGluZyB0byB0aGUgcmVxdWlyZW1lbnRzIGRlZmluZWQgaW4gW1JGQzY5MzVdDQo+ ID4gPiA+IFtSRkM2OTM2XSwgdGhpcyBmaWVsZCBpcyBhbHNvDQo+ID4gPiBSRUNPTU1FTkRFRCB0 byBiZSBzZXQgdG8gemVyby4NCj4gPiA+ID4gU3BlY2lmaWNhbGx5LCBpZiB0aGUgTVBMUyBwYXls b2FkIGlzIEludGVybmV0IFByb3RvY29sIChJUHY0IG9yDQo+ID4gPiA+IElQdjYpIHBhY2tldHMs IGl0IGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIHdoZW4gdGhlIGlubmVyDQo+ID4g PiA+IHBhY2tldCBpbnRlZ3JpdHkgY2hlY2tzIGlzIGF2YWlsYWJsZS4gSW4gYWRkaXRpb24sIGlm IHRoZSBNUExTDQo+ID4gPiA+IHBheWxvYWQgaXMgbm9uLUlQIHBhY2tldCB3aGljaCBpcyBzcGVj aWZpY2FsbHkgZGVzaWduZWQgZm9yDQo+ID4gPiA+IHRyYW5zbWlzc2lvbiBvdmVyIGEgbG93ZXIg bGF5ZXIgdGhhdCBkb2VzIG5vdCBwcm92aWRlIGEgcGFja2V0DQo+ID4gPiA+IGludGVncml0eSBn dWFyYW50ZWUsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGFzIHdlbGwuDQo+ ID4gPiA+IE90aGVyd2lzZSwgdXNpbmcgemVybyBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQu IE5vdGUgdGhhdCBvdGhlcg0KPiA+ID4gPiBJUCBlbmNhcHN1bGF0aW9ucyBmb3IgTVBMUyBkbyBu b3QNCj4gPiA+IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCj4gPiA+ID4N Cj4gPiA+ID4gSWYgeW91IHN0aWxsIGJlbGlldmUgdGhlIGFib3ZlIHRleHQgaXMgbm90IHNhdGlz ZmFjdG9yeSwgcGxlYXNlIHByb3ZpZGUgeW91cg0KPiB0ZXh0Lg0KPiA+ID4gPg0KPiA+ID4gPiBC ZXN0IHJlZ2FyZHMsDQo+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPg0KPiA+ID4gPiA+IExsb3lkIFdv b2QNCj4gPiA+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gPiA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+IEZyb206IG1wbHMg W21wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQo+ID4gPiA+ID4g W3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiA+ID4gU2VudDogMjMgSmFudWFyeSAyMDE0IDAz OjE2DQo+ID4gPiA+ID4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBFZ2dlcnQsIExhcnMNCj4g PiA+ID4gPiBDYzogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gU3ViamVj dDogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4N Cj4gPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRh cmQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhpDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0t 08q8/tStvP4tLS0tLQ0KPiA+ID4gPiA+ID4gt6K8/sjLOiBBbGV4YW5kZXIgVmFpbnNodGVpbg0K PiA+ID4gPiA+ID4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4g PiA+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyMsjVIDE5OjA1DQo+ID4gPiA+ID4gPiDK1bz+ yMs6IEVnZ2VydCwgTGFycw0KPiA+ID4gPiA+ID4gs63LzTogSm9lbCBKYWVnZ2xpOyBtcGxzQGll dGYub3JnOyBYdXhpYW9odQ0KPiA+ID4gPiA+ID4g1vfM4jogUkU6IFttcGxzXSBMYXN0IENhbGw6 IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiA+IChFbmNhcHN1bGF0 aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IExhcnMgYW5kIGFsbCwNCj4gPiA+ID4gPiA+IExhc3QgdGltZSBJJ3ZlIGNvdW50ZWQg dGhlIElFVEYgTEMgdGhyZWFkIG9uIHRoaXMgZHJhZnQgaGFzDQo+ID4gPiA+ID4gPiBtb3JlIHRo YW4NCj4gPiA+ID4gPiA+IDE1MCBtZXNzYWdlcyBpbiBpdCwgYW5kIGl0IHNlZW1zIHRoYXQgb24g c29tZSBpc3N1ZXMNCj4gPiA+ID4gPiA+IChjb25nZXN0aW9uIGNvbnRyb2wgYW5kIFVEUA0KPiA+ ID4gPiA+ID4gY2hlY2tzdW1zKSB3ZSBhcmUgZ29pbmcgcm91bmQgdGhlIG11bGJlcnJ5IGJ1c2gu DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSU1ITyBhbmQgRldJVzoNCj4gPiA+ID4gPiA+IC0g VURQIGNoZWNrc3VtcyAob3IgbGFjayB0aGVyZW9mKSBpcyBhIG5vbi1pc3N1ZSBiZWNhdXNlDQo+ ID4gPiA+ID4gPiBuYXRpdmUgTVBMUyBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIGxpa2UgdGhhdC4g QW5kIHllcywgdGhlcmUNCj4gPiA+ID4gPiA+IGFyZSBjYXNlcyB3aGVyZSBwYWNrZXRzIGFyZSBj b3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKSwgYnV0DQo+ID4gPiA+ID4gPiBzbyBmYXIgaXQg ZGlkIG5vdCBwcmV2ZW50IE1QTFMgZGVwbG95bWVudC4gVGhlcmUgaXMsIGUuZy4sIFJGQw0KPiA+ ID4gPiA+ID4gNDcyMCBmb3IgRkNTIHJldGVudGlvbiBpbiBQV3MsIGJ1dCBJIGRvdWJ0IGl0IGlz IHdpZGVseQ0KPiA+ID4gPiA+ID4gaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkICh3b3VsZCBiZSBu aWNlIHRvDQo+ID4gPiA+ID4ga25vdykuDQo+ID4gPiA+ID4gPiAtIEUyRSBjb25nZXN0aW9uIGNv bnRyb2wgKHJlZ2FyZGxlc3Mgb2YgaXRzIGltcGxpY2F0aW9ucykNCj4gPiA+ID4gPiA+IHNpbXBs eSBjYW5ub3QgYmUgYWRkZWQgdG8gdGhpcyBwcm90b2NvbCB3aXRob3V0IHNvbWUgbWFqb3INCj4g PiA+ID4gPiA+IGNoYW5nZXMuIEEgc2hvcnQgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZXhwbGFp bmluZyB0aGF0IHNob3VsZCBzdWZmaWNlDQo+IElNTy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhp IFNhc2hhLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9p bnRzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPiA+IFhpYW9o dQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBNeSAyYywNCj4gPiA+ID4gPiA+ICAgICAgICBTYXNo YQ0KPiA+ID4gPiA+ID4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+ ID4gPiA+ID4gPiBNb2JpbGU6IDA1NC05MjY2MzAyDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gPiBGcm9tOiBtcGxzIFtt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiA+ID4gPiA+ID4g RWdnZXJ0LCBMYXJzDQo+ID4gPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMiwg MjAxNCAxMjoyMyBQTQ0KPiA+ID4gPiA+ID4gPiBUbzogWHV4aWFvaHUNCj4gPiA+ID4gPiA+ID4g Q2M6IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBS ZTogW21wbHNdIExhc3QgQ2FsbDoNCj4gPiA+ID4gPiA+ID4gPGRyYWZ0LWlldGYtbXBscy1pbi11 ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkNCj4gPiA+ID4gPiA+ID4gdG8g UHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSGksDQo+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IE9uIDIwMTQtMS0yMiwgYXQgMTE6MTIsIFh1eGlhb2h1 IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPiBJIHdvbmRlciB3 aGV0aGVyIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBPSyB0byB5b3U6DQo+ID4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gPiBTaW5jZSB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiBjYXVz ZXMgTVBMUyBwYWNrZXRzIHRvDQo+ID4gPiA+ID4gPiA+ID4gYmUNCj4gPiA+ID4gPiA+ID4gZm9y d2FyZGVkIHRocm91Z2ggIlVEUCB0dW5uZWxzIiwgdGhlIGNvbmdlc3Rpb24gY29udHJvbA0KPiA+ ID4gPiA+ID4gPiBndWlkZWxpbmVzIGZvciBVRFAgdHVubmVscyBhcyBkZWZpbmVkIGluIFNlY3Rp b24gMy4xLjMgb2YNCj4gPiA+ID4gPiA+ID4gW1JGQzU0MDVdIFNIT1VMRCBiZQ0KPiA+ID4gPiA+ IGZvbGxvd2VkLg0KPiA+ID4gPiA+ID4gPiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5IGEg bnVtYmVyIG9mIGRpZmZlcmVudCBwcm90b2NvbHMNCj4gPiA+ID4gPiA+ID4gYXMNCj4gPiBwYXls b2Fkcy4NCj4gPiA+ID4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMg cGF5bG9hZCB0cmFmZmljIHRoYXQgaXMNCj4gPiA+ID4gPiA+ID4ga25vd24gYXQgY29uZmlndXJh dGlvbiB0aW1lIHRvIGJlIElQLWJhc2VkIGFuZA0KPiA+ID4gPiA+ID4gPiBjb25nZXN0aW9uLWNv bnRyb2xsZWQsIHRoZSBVRFAgdHVubmVsIFNIT1VMRCBOT1QgZW1wbG95IGl0cw0KPiA+ID4gPiA+ ID4gPiBvd24gY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSwgYmVjYXVzZSBjb25nZXN0aW9u IGxvc3Nlcw0KPiA+ID4gPiA+ID4gPiBvZiB0dW5uZWxlZCB0cmFmZmljIHdpbGwgdHJpZ2dlciBh biBjb25nZXN0aW9uIHJlc3BvbnNlIGF0DQo+ID4gPiA+ID4gPiA+IHRoZSBvcmlnaW5hbCBzZW5k ZXJzIG9mIHRoZSB0dW5uZWxlZA0KPiA+ID4gPiB0cmFmZmljLg0KPiA+ID4gPiA+ID4gPiBXaGVu IGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcw0K PiA+ID4gPiA+ID4gPiBrbm93biBhdCBjb25maWd1cmF0aW9uIHRpbWUgbm90IHRvIGJlIElQLWJh c2VkIGFuZA0KPiA+ID4gPiA+ID4gPiBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFAgdHVu bmVsIFNIT1VMRCBlbXBsb3kgYW4NCj4gPiA+ID4gPiA+ID4gYXBwcm9wcmlhdGUgY29uZ2VzdGlv biBjb250cm9sIG1lY2hhbmlzbSBhcyBkZXNjcmliZWQgaW4NCj4gPiA+ID4gPiA+ID4gW1JGQzM5 ODVdLiBOb3RlIHRoYXQgaXQgU1RST05HTFkgUkVDT01NRU5ERUQgdG8gZGVwbG95IHN1Y2gNCj4g PiA+ID4gPiA+ID4gZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IG9ubHkgd2l0aGluIGEgU1AgbmV0 d29yayBvcg0KPiA+ID4gPiA+ID4gPiBuZXR3b3JrcyBvZiBhbiBhZGphY2VudCBzZXQgb2YgY28t b3BlcmF0aW5nIFNQcywgcmF0aGVyIHRoYW4NCj4gPiA+ID4gPiA+ID4gb3ZlciB0aGUNCj4gPiA+ ID4gPiBJbnRlcm5ldC4NCj4gPiA+ID4gPiA+ID4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJz IHNob3VsZCBiZSBhZGRlZCB0byBibG9jayB0cmFmZmljDQo+ID4gPiA+ID4gPiA+IHdpdGggdGhl IFVEUCBwb3J0IG51bWJlciBmb3IgTVBMUyBvdmVyIFVEUCB0byBwcmV2ZW50IE1QTFMNCj4gPiA+ ID4gPiA+ID4gb3ZlciBVRFAgcGFja2V0cyB0byBlc2NhcGUgZnJvbSB0aGUgc2VydmljZSBwcm92 aWRlcg0KPiA+ID4gPiA+ID4gPiBuZXR3b3JrcyBkdWUgdG8gbWlzY29uZmlndWF0aW9uIG9yIHBh Y2tldA0KPiA+ID4gPiA+ID4gZXJyb3JzLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBJ IHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBkZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wgbG9v cA0KPiA+ID4gPiA+ID4gPiBpbg0KPiA+ID4gPiA+ID4gPiAoc29tZSkgbW9yZSBkZXRhaWwsIHJh dGhlciB0aGFuIHBvaW50aW5nIHRvIFJGQzM5ODUsIHdoaWNoDQo+ID4gPiA+ID4gPiA+IGRvZXNu J3QgaGF2ZSBhIHdob2xlIGxvdCBvZiBkZXRhaWwgZWl0aGVyLiBBbHNvIGJlY2F1c2UgdGhlDQo+ ID4gPiA+ID4gPiA+IGFkZGluZyBvZiBmaXJld2FsbCBydWxlcyByZXF1aXJlcyBhbiBPQU0gaG9v ay4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gU2luY2UgU1RST05HTFkgUkVDT01NRU5E RUQgaXMgbm90IGFuIFJGQzIxMTkgdGVybSBhbmQNCj4gPiA+ID4gPiA+IFJFQ09NTUVOREVEIGlz DQo+ID4gPiA+ID4gPiA+IHRvbyB3ZWFrLCBJJ2Qgc3VnZ2VzdCB0byBjaGFuZ2UgdGhpcyB0byBN VVNULg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBGaW5hbGx5LCB0aGUgYXBwbGljYWJp bGl0eSBzdGF0ZW1lbnQgc2hvdWxkIGJlIHByb21pbmVudGx5DQo+ID4gPiA+ID4gPiA+IG1hZGUg aW4gdGhlIGFic3RyYWN0LCBpbnRyb2R1Y3Rpb24sIGV0Yy4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4gTGFycw0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBt cGxzQGlldGYub3JnDQo+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo= From jmh@joelhalpern.com Thu Jan 23 18:31:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879D91A01BE; Thu, 23 Jan 2014 18:31:51 -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 OUa0nL06So02; Thu, 23 Jan 2014 18:31:49 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 80E311A0195; Thu, 23 Jan 2014 18:31:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C83A84415B9; Thu, 23 Jan 2014 18:31:48 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (24-104-115-2-ip-static.hfc.comcastbusiness.net [24.104.115.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5DBC31C05A5; Thu, 23 Jan 2014 18:31:48 -0800 (PST) Message-ID: <52E1D093.8040603@joelhalpern.com> Date: Thu, 23 Jan 2014 21:31:47 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joe Touch , Edward Crabbe References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> In-Reply-To: <52E18BF1.1040004@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:31:51 -0000 Joe, while your argument is internally consistent, it is not consistent with history. We have not demanded that tunnel entries behave fully like source hosts for any of the other myriad kinds of tunnels we have done over the years. If we take your logic as stated, then the usage of IPSec over UDP would be required to apply congestion control unless it knew that all the content traffic was TCP. Is that really your intent? Yours, Joel On 1/23/14 4:38 PM, Joe Touch wrote: > > > On 1/23/2014 1:27 PM, Edward Crabbe wrote: >> Part of the point of using UDP is to make use of lowest common >> denominator forwarding hardware in introducing entropy to protocols that >> lack it ( this is particularly true of the GRE in UDP use case also >> under discussion elsewhere). >> >> The tunnel is not the source of the traffic. The _source of the >> traffic_ is the source of the traffic. > > To the Internet, the tunnel encapusulator is the source of traffic. > Tracing the data back further than that is a mirage at best - and > irrelevant. > > The tunnel head-end is responsible for the tunnel walking, talking, and > quaking like a duck (host). When the tunnel head-end knows something > about the ultimate origin of the traffic - whether real, imagined, or > from Asgard - then it has done it's duty (e.g., that it's already > congestion controlled). > > But that head end is responsible, regardless of what it knows or > doesn't. And when it doesn't know, the only way to be responsible is to > put in its own reactivity. > >> The originating application >> who's traffic is being tunneled should be responsible for congestion >> control, or lack there of. > > Perhaps it should be, but that's an agreement between whomever > implements/deploys the tunnel headend and whomever provides the > originating traffic to them. The problem is that this isn't true for the > typical use case for this kind of encapsulation. > > I.e., if we were talking about MPLS traffic that already was reactive, > we wouldn't be claiming the need for additional encapsulator mechanism. > It's precisely because nothing is known about the MPLS traffic that the > encapsulator needs to act. > > > Are we advocating a return to intermediate >> congestion control (I like X.25 as much as the next guy, but...). This >> is a very stark change of direction. >> >> I think mandating congestion control is not technically sound from >> either a theoretical (violation of end to end principle, stacking of >> congestion control algorithms leading to complex and potentially >> suboptimal results) or economic perspective (as a very large backbone, >> we've been doing just fine without intermediate congestion management >> thank you very much, and I have 0 desire to pay for a cost prohibitive, >> unnecessary feature in silicon.) > > Write that up, and we'll see how it turns out in the IETF. However, > right now, the IETF BCPs do require reactive congestion management of > transport streams. > > If you don't want/like that, then either don't use transport > encapsulation, or change the BCPs. > >> I get Lars comments regarding reach, to some limited extent. >> Ultimately, the implication seems to be that the protocols riding the >> L2 network will have no form of congestion control and are fundamentally >> different than protocols that would reside on a typical wan. I have >> some serious doubts about this, although I'm sure this is the case in >> some specialized environments. At any rate, it seems to me that a stern >> warning regarding edge filtering on interdomain boundaries will be >> sufficient. > > My concern may be slightly different that his. My concern is that you > want the benefits of a UDP header, but don't like the responsibilities > that come along with it. > > Joe > > From xuxiaohu@huawei.com Thu Jan 23 18:42:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0831A02EB for ; Thu, 23 Jan 2014 18:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 Zt5WB9xcngA4 for ; Thu, 23 Jan 2014 18:42:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 038A41A0340 for ; Thu, 23 Jan 2014 18:42:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAJ17807; Fri, 24 Jan 2014 02:42:12 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 02:42:05 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 02:42:10 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 10:42:06 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "Alexander.Vainshtein@ecitele.com" , "lars@netapp.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAAvVgIABlLXwgAAZTiOAAIGV4IAASynFgAB+v4CAAAUDQYAAAhRggAAIfvuAAAIPgIAAASaAgAALJECAAASQYA== Date: Fri, 24 Jan 2014 02:42:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478FD@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082472BE@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E2@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247440@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082477E6@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824784D@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E8@EXMB01CMS.surrey.ac.uk> ,<1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478AB@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346E9@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346E9@EXMB01CMS.surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:42:20 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBb bWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ILeiy83KsbzkOiAyMDE0xOox1MIyNMjVIDEw OjMwDQo+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t OyBsYXJzQG5ldGFwcC5jb20NCj4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9y Zw0KPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAt MDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTDQo+IGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRh cmQNCj4gDQo+IEkgYW0gbm90IGFnYWluc3QgdGhlIGJ1bGsgb2YgUkZDNjkzNi4gQnV0IHVubGlr ZSAnMzYsDQo+IFJGQzY5MzUgaXMgdmVyeSBtdWNoIHdyaXR0ZW4gZm9yIHRoZSBiZW5lZml0IG9m IHR1bm5lbGVycy4NCj4gDQo+IFJGQzY5MzUgYW5kIDM2IGNhbiBiZSByZWFkIHRvIGdpdmUgY29u ZmxpY3RpbmcgYWR2aWNlICgzNSAtIHplcm8hDQo+IDM2IC0gdW0sIHRoYXQgbGVhZHMgdG8gdGhl c2Ugc3VidGxlIGFuZCBudWFuY2VkIHBycm9ibGVtcywgc28gbWF5YmUgbm90KSwgc28NCj4ganVz dCByZWZlcnJpbmcgdG8gdGhlbSBhbmQgbGVhdmluZyB0aGUgaW1wbGVtZW50ZXIgd2l0aG91dCBj bGVhciBkaXJlY3Rpb24gaXMgbm90DQo+IHN1ZmZpY2llbnQgaW1vLg0KDQpJZiBzbywgd291bGRu J3QgaXQgYmUgYmV0dGVyIHRvIHNvbHZlIHN1Y2ggY29uZmxpY3Rpb24gYW5kIGNvbmZ1c2lvbiBj YXVzZWQgYnkgNjkzNSBhbmQgNjkzNiBieSB1cGRhdGluZyB0aGVtPyBTaW5jZSB0aGVzZSB0d28g ZHJhZnRzIGFyZSBvcmlnaW5hdGVkIGZyb20gdGhlIFRTViBXRywgaXQgc2hvdWxkIHJlcHJlc2Vu dCB0aGUgcm9ndWUgV0cgY29uc2Vuc3VzIGluc3RlYWQgb2YgbWFraW5nIGNvbmZ1c2lvbiB0byBv dGhlcnMuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odSANCg0KPiBSRkM2OTM1IGlzIGNvbnNpZGVy aW5nICB0dW5uZWxsZWQgdHJhZmZpYywgbm90IHRoZSBlZmZlY3Qgb24gb3RoZXIgdHJhZmZpYywg cG9ydHMNCj4gYW5kIGRlc3RpbmF0aW9ucywgd2hpY2ggUkZDNjkzNiB3YXJucyBhZ2FpbnN0LkJ1 dCBldmVuIFJGQzY5MzUsIHdoaWNoDQo+IHByaW1hcmlseSBjb25zaWRlcnMgdGhlIGNvc3RzL2Jl bmVmaXRzIHRvIHR1bm5lbHMsIG5vdCB0byB0cmFmZmljIHNoYXJpbmcgdGhlDQo+IG5ldHdvcmsg d2l0aCB0dW5uZWxzIGRvZXMgc2F5Og0KPiANCj4gICBPbmUgdW5mb3J0dW5hdGUgc2lkZSBlZmZl Y3Qgb2YgaW5jcmVhc2VkIHVzZSBvZiBhIHplcm8gY2hlY2tzdW0gaXMNCj4gICAgdGhhdCBpdCBh bHNvIGluY3JlYXNlcyB0aGUgbGlrZWxpaG9vZCBvZiBhY2NlcHRhbmNlIHdoZW4gYSBkYXRhZ3Jh bQ0KPiAgICB3aXRoIGEgemVybyBVRFAgY2hlY2tzdW0gaXMgbWlzZGVsaXZlcmVkLg0KPiANCj4g VW5mb3J0dW5hdGUsIGJ1dCBub3QgZm9yIHRoZSB0dW5uZWwsIHdoaWNoIGp1c3Qgc2VlcyBhIGRy b3AuDQo+IA0KPiAuLndoaWNoIGlzIHdoeSB0aGUgdGV4dCBJIHByb3Bvc2Ugc2F5cyAnU0hPVUxE JyB1c2UgYSBjaGVja3N1bSwgd2hpbGUNCj4gYWNrbm93bGVkZ2luZyB0aGF0IHBlcmZvcm1hbmNl IGFuZCBpbXBsZW1lbnRhdGlvbiByZWFzb25zIG1heSBkaWN0YXRlDQo+IG90aGVyd2lzZS4NCg0K PiA+IE5vdGUgdGhhdCBvdGhlciBJUCBlbmNhcHN1bGF0aW9ucyBmb3IgTVBMUyBkbyBub3QgaGF2 ZSBhIGNoZWNrc3VtIGluDQo+ID4gdGhlIHR1bm5lbCBoZWFkZXIuDQo+IA0KPiBPdGhlciBlbmNh cHN1bGF0aW9ucyBkb24ndCBoYXZlIFVEUCBwb3J0cyB0aGF0IGNhbiBiZSBjb3JydXB0ZWQsIHNv IGV2ZW4gaWYgdGhlDQo+IGFkZHJlc3MgaXMgY29ycnVwdGVkLCBkZWNhcHN1bGF0aW9uIGF0IGFu b3RoZXIgdHVubmVsIGVuZHBvaW50IGlzIGZhciBsZXNzIGxpa2VseS4NCj4gQnV0IGhvc3RzIHN1 cHBvcnRpbmcgVURQIHNlcnZpY2VzIGFyZSB2ZXJ5IHZlcnkgY29tbW9uLg0KPiANCj4gTGxveWQg V29vZA0KPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5j b21dDQo+IFNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwMTozOA0KPiBUbzogWHV4aWFvaHU7IFdvb2Qg TCAgRHIgKEVsZWN0cm9uaWMgRW5nKTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207 DQo+IGxhcnNAbmV0YXBwLmNvbQ0KPiBDYzogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiByZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11 ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTDQo+IGluIFVEUCkgdG8gUHJvcG9zZWQgU3Rh bmRhcmQNCj4gDQo+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiBYdXhpYW9odQ0K PiA+ILeiy83KsbzkOiAyMDE0xOox1MIyNMjVIDk6MzYNCj4gPiDK1bz+yMs6ICdsLndvb2RAc3Vy cmV5LmFjLnVrJzsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207DQo+ID4gbGFyc0Bu ZXRhcHAuY29tDQo+ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ INb3zOI6ILTwuLQ6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0 LnR4dD4NCj4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRh cmQNCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gU2luY2UgeW91IGFyZSBub3QgYWdhaW5zdCBSRkM2 OTM2IGFuZCBSRkM2OTM1LCBob3cgYWJvdXQgbWFraW5nIHRoZQ0KPiA+IGZvbGxvd2luZyBjaGFu Z2U6DQo+ID4NCj4gPiBPTEQ6DQo+ID4NCj4gPiBJbiB0aGUgSVB2NiBVRFAgZW5jYXBzdWxhdGlv biBjYXNlLCBpZiBhcHByb3ByaWF0ZSBhY2NvcmRpbmcgdG8gdGhlDQo+ID4gcmVxdWlyZW1lbnRz IGRlZmluZWQgaW4gW1JGQzY5MzVdIFtSRkM2OTM2XSwgdGhpcyBmaWVsZCBpcyBhbHNvDQo+ID4g UkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8uIFNwZWNpZmljYWxseSwgaWYgdGhlIE1QTFMg cGF5bG9hZCBpcw0KPiA+IEludGVybmV0IFByb3RvY29sIChJUHY0IG9yDQo+ID4gSVB2NikgcGFj a2V0cywgaXQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gd2hlbiB0aGUgaW5uZXIN Cj4gPiBwYWNrZXQgaW50ZWdyaXR5IGNoZWNrcyBpcyBhdmFpbGFibGUuIEluIGFkZGl0aW9uLCBp ZiB0aGUgTVBMUyBwYXlsb2FkDQo+ID4gaXMgbm9uLUlQIHBhY2tldCB3aGljaCBpcyBzcGVjaWZp Y2FsbHkgZGVzaWduZWQgZm9yIHRyYW5zbWlzc2lvbiBvdmVyDQo+ID4gYSBsb3dlciBsYXllciB0 aGF0IGRvZXMgbm90IHByb3ZpZGUgYSBwYWNrZXQgaW50ZWdyaXR5IGd1YXJhbnRlZSwgaXQNCj4g PiBpcyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyBhcyB3ZWxsLiBPdGhlcndpc2UsIHVz aW5nIHplcm8NCj4gPiBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQuIE5vdGUgdGhhdCBvdGhl ciBJUCBlbmNhcHN1bGF0aW9ucyBmb3IgTVBMUw0KPiBkbyBub3QgaGF2ZSBhIGNoZWNrc3VtIGlu IHRoZSB0dW5uZWwgaGVhZGVyLg0KPiA+DQo+ID4gTkVXOg0KPiA+DQo+ID4gSW4gdGhlIElQdjYg VURQIGVuY2Fwc3VsYXRpb24gY2FzZSwgYXMgZm9yIHdoZXRoZXIgb3Igbm90IGl0IGlzDQo+ID4g c3VpdGFibGUgdG8gdXNlIHRoZSB6ZXJvLWNoZWNrc3VtIG5vZGUsIHRoZSByZXF1aXJlbWVudHMg ZGVmaW5lZCBpbg0KPiA+IFtSRkM2OTM1XSBbUkZDNjkzNl0NCj4gDQo+IHMvbm9kZS9tb2RlDQo+ IA0KPiA+IFNIT1VMRCBiZSBzdHJpY3RseSBmb2xsb3dlZC4gTm90ZSB0aGF0IG90aGVyIElQIGVu Y2Fwc3VsYXRpb25zIGZvcg0KPiA+IE1QTFMgZG8gbm90IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUg dHVubmVsIGhlYWRlci4NCj4gPg0KPiA+IFhpYW9odQ0KPiA+DQo+ID4gPiAtLS0tLdPKvP7Urbz+ LS0tLS0NCj4gPiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBz dXJyZXkuYWMudWtdDQo+ID4gPiC3osvNyrG85DogMjAxNMTqMdTCMjTI1SA5OjI2DQo+ID4gPiDK 1bz+yMs6IFh1eGlhb2h1OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0Bu ZXRhcHAuY29tDQo+ID4gPiCzrcvNOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ ID4gPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAt MDQudHh0Pg0KPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0 YW5kYXJkDQo+ID4gPg0KPiA+ID4gRm9yIHRoZSByZWFzb25zIG91dGxpbmVkIGluIFJGQzY5MzYg c2VjdGlvbiAzLCB3aGljaCBJIGNpdGVkLCBhbmQNCj4gPiA+IGZvciB0aGUgZGFuZ2VyIHRvIG90 aGVyIHRyYWZmaWMsIHdoaWNoIHdlIGhhdmUgZGlzY3Vzc2VkIGluIHRoaXMgdGhyZWFkLg0KPiA+ ID4NCj4gPiA+IEkgcXVvdGUgUkZDMzkzNjoNCj4gPiA+DQo+ID4gPiAgQ3VycmVudGx5LCBmb3Ig dGhlIGdlbmVyYWwgSW50ZXJuZXQsIHRoZXJlIGlzIG5vIGV2aWRlbmNlIHRoYXQNCj4gPiA+IGNv cnJ1cHRpb24gaXMgcmFyZSwgbm9yIGlzIHRoZXJlIGV2aWRlbmNlIHRoYXQgY29ycnVwdGlvbiBp biBJUHY2IGlzDQo+ID4gPiByYXJlLiBUaGVyZWZvcmUsIGl0IHNlZW1zIHBydWRlbnQgbm90IHRv IHJlbGF4IGNoZWNrcyBvbiAgbWlzZGVsaXZlcnkuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IExsb3lk IFdvb2QNCj4gPiA+IGh0dHA6Ly9hYm91dC5tZS9sbG95ZHdvb2QNCj4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IEZyb206IFh1eGlhb2h1IFt4dXhp YW9odUBodWF3ZWkuY29tXQ0KPiA+ID4gU2VudDogMjQgSmFudWFyeSAyMDE0IDAxOjAwDQo+ID4g PiBUbzogV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTsNCj4gPiA+IGxhcnNAbmV0YXBwLmNvbQ0KPiA+ID4gQ2M6IGpvZWxqYUBib2d1 cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6ILTwuLQ6IFttcGxzXSBMYXN0IENh bGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChFbmNhcHN1bGF0aW5n IE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+IFdlIGFyZSB0 YWxraW5nIGFib3V0IHVzaW5nIFVEUCBhcyBhIHR1bm5lbCBmb3IgTVBMUyB0cmFmZmljLiBTbyB3 aHkNCj4gPiA+IGNhbid0IGFsbG93IHRoZSBVRFAgdHVubmVsIHRvIHVzZSB6ZXJvIGNoZWNrc3Vt cyBmb3IgcGVyZm9ybWFuY2UsDQo+ID4gPiB3aGljaCBpcyB0aGUgcmVjb21tZW5kYXRpb24gZnJv bSBSRkM2OTM1Lg0KPiA+ID4NCj4gPiA+IFhpYW9odQ0KPiA+ID4NCj4gPiA+ID4gLS0tLS3Tyrz+ 1K28/i0tLS0tDQo+ID4gPiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRvOmwu d29vZEBzdXJyZXkuYWMudWtdDQo+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyNMjVIDg6NDgN Cj4gPiA+ID4gytW8/sjLOiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b207IGxhcnNAbmV0YXBwLmNvbQ0KPiA+ID4gPiCzrcvNOiBqb2VsamFAYm9ndXMuY29tOyBtcGxz QGlldGYub3JnDQo+ID4gPiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0 Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQ KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPg0KPiA+ID4gPiBSRkM2OTM1IHdhcyB3cml0 dGVuIGZyb20gYSB0dW5uZWxsaW5nIHBlcnNwZWN0aXZlLCB0byBhbGxvdw0KPiA+ID4gPiB0dW5u ZWxsaW5nIHRvIHVzZSB6ZXJvIGNoZWNrc3VtcyBmb3IgcGVyZm9ybWFuY2UsIGFuZCBhbmFseXNl ZA0KPiA+ID4gPiByaXNrcyB0byB0aGUgdHVubmVsIHRyYWZmaWMgLSBidXQgbm90IHRvIG90aGVy IHVzZXJzLg0KPiA+ID4gPg0KPiA+ID4gPiAgICAiV2hpbGUgdGhlIG1ldGhvZHMgZG8NCj4gPiA+ ID4gICAgbm90IGd1YXJhbnRlZSBjb3JyZWN0bmVzcywgdGhleSBjYW4gcmVkdWNlIHRoZSByaXNr cyBvZiByZWxheGluZyB0aGUNCj4gPiA+ID4gICAgVURQIGNoZWNrc3VtIHJlcXVpcmVtZW50IGZv ciBhIHR1bm5lbCBhcHBsaWNhdGlvbiB1c2luZyBJUHY2LiINCj4gPiA+ID4NCj4gPiA+ID4gUmlz a3MgdG8gb3RoZXIgYXBwbGljYXRpb25zIGFyZSBub3QgYXNzZXNzZWQsIGFuZCBub3Qgc3RhdGVk Lg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBMbG95ZCBXb29kDQo+ID4gPiA+IGh0dHA6Ly9h Ym91dC5tZS9sbG95ZHdvb2QNCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+ID4gPiBGcm9tOiBYdXhpYW9odSBbeHV4aWFvaHVAaHVhd2VpLmNvbV0N Cj4gPiA+ID4gU2VudDogMjQgSmFudWFyeSAyMDE0IDAwOjM0DQo+ID4gPiA+IFRvOiBXb29kIEwg IERyIChFbGVjdHJvbmljIEVuZyk7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0K PiA+ID4gPiBsYXJzQG5ldGFwcC5jb20NCj4gPiA+ID4gQ2M6IGpvZWxqYUBib2d1cy5jb207IG1w bHNAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogtPC4tDogW21wbHNdIExhc3QgQ2FsbDogPGRy YWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExT IGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4NCj4gPiA+ID4gSXQgc2VlbXMg dGhhdCB5b3UgYXJlIGFnYWluc3QgUkZDNjkzNSBhbmQgUkZDNjkzNiwgcmlnaHQ/DQo+ID4gPiA+ DQo+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiA+ID4gPiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJy ZXkuYWMudWtdDQo+ID4gPiA+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjI0yNUgMToxOA0KPiA+ID4g PiA+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0K PiBsYXJzQG5ldGFwcC5jb20NCj4gPiA+ID4gPiCzrcvNOiBqb2VsamFAYm9ndXMuY29tOyBtcGxz QGlldGYub3JnDQo+ID4gPiA+ID4g1vfM4jogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1p ZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGlu IFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IHRoZSB0ZXh0 IGlzIG5vdCBzYXRpc2ZhY3RvcnkuIG5ldmVyIHJlY29tbWVuZCBzZXR0aW5nIHRvIHplcm8sDQo+ ID4gPiA+ID4gYXMgdGhhdCBwb3NlcyBhIHJpc2sgdG8geW91ciBhbmQgdG8gb3RoZXIgdHJhZmZp Yy4gU3VnZ2VzdGVkIHRleHQ6DQo+ID4gPiA+ID4gKioqDQo+ID4gPiA+ID4gVGhlIFVEUCBjaGVj a3N1bSBTSE9VTEQgYmUgdXNlZCB0byBwcm90ZWN0IHRoZSBwYXlsb2FkIGFuZA0KPiA+ID4gPiA+ IGVuc3VyZSBjb3JyZWN0IGRlbXVsdGlwbGV4aW5nIGFuZCBkZWxpdmVyeSB0byB0aGUgdHVubmVs LCBhbmQNCj4gPiA+ID4gPiBub3QgdG8gb3RoZXIgVURQIGRlc3RpbmF0aW9ucywgYnkgcHJvdGVj dGluZyB0aGUgVURQIHBzZXVkb2hlYWRlci4NCj4gPiA+ID4gPiBVc2Ugb2YgYSB6ZXJvIFVEUCBj aGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQsIGV2ZW4gd2hlbiBkZXNpcmVkDQo+ID4gPiA+ID4g Zm9yIHBlcmZvcm1hbmNlIG9yIG5lY2Vzc2l0YXRlZCBieSBpbXBsZW1lbnRhdGlvbiByZWFzb25z LCBmb3INCj4gPiA+ID4gPiB0aGUgcmVhc29ucyBvdXRsaW5lZCBpbiBbUkZDNjkzNl0gc2VjdGlv biAzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVURQLUxpdGUgW1JGQzM4MjhdIGNhbiBwcm92aWRl IGEgZGVtdWx0aXBsZXhpbmcgY2hlY2sgYW5kIE1QTFMNCj4gPiA+ID4gPiBzdGFjayBpbnRlZ3Jp dHkgY2hlY2sgd2hpbGUgYXZvaWRpbmcgdGhlIG92ZXJoZWFkIG9mIGNvbXB1dGluZw0KPiA+ID4g PiA+IGFuIGludGVncml0eSBjaGVjayBvdmVyIGEgdHVubmVsbGVkIGZyYW1lIHRoYXQgaGFzIGl0 cyBvd24gaW50ZWdyaXR5DQo+IGNoZWNrLg0KPiA+ID4gPiA+ICoqKg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gTGxveWQgV29vZA0KPiA+ID4gPiA+IGh0dHA6Ly9hYm91dC5tZS9sbG95ZHdvb2QNCj4g PiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ ID4gRnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiA+ID4gU2VudDog MjMgSmFudWFyeSAyMDE0IDEyOjM1DQo+ID4gPiA+ID4gVG86IFdvb2QgTCAgRHIgKEVsZWN0cm9u aWMgRW5nKTsNCj4gPiA+ID4gPiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFy c0BuZXRhcHAuY29tDQo+ID4gPiA+ID4gQ2M6IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5v cmcNCj4gPiA+ID4gPiBTdWJqZWN0OiByZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYt bXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQ KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLdPKvP7U rbz+LS0tLS0NCj4gPiA+ID4gPiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRv Omwud29vZEBzdXJyZXkuYWMudWtdDQo+ID4gPiA+ID4gPiC3osvNyrG85DogMjAxNMTqMdTCMjPI 1SAxMjo0NA0KPiA+ID4gPiA+ID4gytW8/sjLOiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb207DQo+ID4gbGFyc0BuZXRhcHAuY29tDQo+ID4gPiA+ID4gPiCzrcvNOiBq b2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gPiDW98ziOiBSRTogW21w bHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiA+ ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gU2FzaGENCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IC0g VURQIGNoZWNrc3VtcyAob3IgbGFjayB0aGVyZW9mKSBpcyBhIG5vbi1pc3N1ZSBiZWNhdXNlDQo+ ID4gPiA+ID4gPiA+IG5hdGl2ZSBNUExTIGRvZXMgbm90IGhhdmUgYW55dGhpbmcgbGlrZSB0aGF0 LiBBbmQgeWVzLCB0aGVyZQ0KPiA+ID4gPiA+ID4gPiBhcmUgY2FzZXMgd2hlcmUgcGFja2V0cyBh cmUgY29ycnVwdGVkIHdpdGhpbiB0aGUgcm91dGVycykNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiBTbyB5b3UgYWRtaXQgdGhhdCBwYWNrZXRzIGNhbiBiZSBjb3JydXB0ZWQgd2l0aGluIHRoZSBy b3V0ZXJzDQo+ID4gPiA+ID4gPiAtIGEgY2hlY2sgdGhhdCBjYW4gb25seSBiZSBjYXVnaHQgYnkg YW4gZW5kLXRvLWVuZCBjaGVjaywgYQ0KPiA+ID4gPiA+ID4gY29ycnVwdGlvbiB0aGF0IGNhbiBs ZWFkIHRvIHRoZSBwcm9ibGVtcyBkZXRhaWxlZCBpbiBSRkMgNjkzNg0KPiA+ID4gPiA+ID4gc2Vj dGlvbiAzIC0gYW5kIHRoZW4geW91IHNheSBpdCdzIGEgbm9uLWlzc3VlIGJlY2F1c2UgdGhpcw0K PiA+ID4gPiA+ID4gZG9lc24ndCBhZmZlY3QgbmF0aXZlIE1QTFMuIEJ1dCB3ZSdyZQ0KPiA+ID4g PiA+IG5vdCBkb2luZyBuYXRpdmUgTVBMUyBoZXJlLg0KPiA+ID4gPiA+ID4gV2UncmUgZG9pbmcg TVBMUyBvdmVyIFVEUC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBkcmFmdC1pZXRmLW1wbHMt aW4tdWRwLTA0LnR4dCBpcyBhYm91dCB0dW5uZWxsaW5nIE1QTFMgaW4gVURQLg0KPiA+ID4gPiA+ ID4gSXQncyBhbg0KPiA+IGlzc3VlLg0KPiA+ID4gPiA+ID4gUGxlYXNlIHJlYWQgdGhlIG90aGVy IDE1MCBtZXNzYWdlcyB0aGF0IHlvdSByZWZlciB0by4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhp IExsb3lkLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIGRyYWZ0IGRvZXNuJ3QgcmVxdWlyZSB0 aGUgSVB2NiBVRFAgY2hlY2tzdW0gdG8gYmUgc2V0IHRvDQo+ID4gPiA+ID4gemVybw0KPiA+ID4g cmVnYXJkbGVzcy4NCj4gPiA+ID4gPiBTZWUgdGhlIGZvbGxvd2luZyB0ZXh0IHF1b3RlZCBmcm9t IHRoYXQgZHJhZnQ6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBVRFAgQ2hlY2tzdW0NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IFRoZSB1c2FnZSBvZiB0aGlzIGZpZWxkIGlzIGluIGFjY29yZGFuY2Ugd2l0 aCB0aGUgY3VycmVudCBVRFANCj4gPiA+ID4gPiBzcGVjaWZpY2F0aW9uIFtSRkM3NjhdLiBUbyBz aW1wbGlmeSB0aGUgb3BlcmF0aW9uIG9uIHRoZQ0KPiA+ID4gPiA+IGRlY2Fwc3VsYXRvciwgdGhp cyBmaWVsZCBpcyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyBpbg0KPiA+ID4gPiA+IElQ djQgVURQIGVuY2Fwc3VsYXRpb24gY2FzZS4gSW4gdGhlIElQdjYgVURQIGVuY2Fwc3VsYXRpb24g Y2FzZSwNCj4gPiA+ID4gPiBpZiBhcHByb3ByaWF0ZSBhY2NvcmRpbmcgdG8gdGhlIHJlcXVpcmVt ZW50cyBkZWZpbmVkIGluDQo+ID4gPiA+ID4gW1JGQzY5MzVdIFtSRkM2OTM2XSwgdGhpcyBmaWVs ZCBpcyBhbHNvDQo+ID4gPiA+IFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvLg0KPiA+ID4g PiA+IFNwZWNpZmljYWxseSwgaWYgdGhlIE1QTFMgcGF5bG9hZCBpcyBJbnRlcm5ldCBQcm90b2Nv bCAoSVB2NCBvcg0KPiA+ID4gPiA+IElQdjYpIHBhY2tldHMsIGl0IGlzIFJFQ09NTUVOREVEIHRv IGJlIHNldCB0byB6ZXJvIHdoZW4gdGhlDQo+ID4gPiA+ID4gaW5uZXIgcGFja2V0IGludGVncml0 eSBjaGVja3MgaXMgYXZhaWxhYmxlLiBJbiBhZGRpdGlvbiwgaWYgdGhlDQo+ID4gPiA+ID4gTVBM UyBwYXlsb2FkIGlzIG5vbi1JUCBwYWNrZXQgd2hpY2ggaXMgc3BlY2lmaWNhbGx5IGRlc2lnbmVk IGZvcg0KPiA+ID4gPiA+IHRyYW5zbWlzc2lvbiBvdmVyIGEgbG93ZXIgbGF5ZXIgdGhhdCBkb2Vz IG5vdCBwcm92aWRlIGEgcGFja2V0DQo+ID4gPiA+ID4gaW50ZWdyaXR5IGd1YXJhbnRlZSwgaXQg aXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gYXMgd2VsbC4NCj4gPiA+ID4gPiBPdGhl cndpc2UsIHVzaW5nIHplcm8gY2hlY2tzdW0gaXMgTk9UIFJFQ09NTUVOREVELiBOb3RlIHRoYXQN Cj4gPiA+ID4gPiBvdGhlciBJUCBlbmNhcHN1bGF0aW9ucyBmb3IgTVBMUyBkbyBub3QNCj4gPiA+ ID4gaGF2ZSBhIGNoZWNrc3VtIGluIHRoZSB0dW5uZWwgaGVhZGVyLg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gSWYgeW91IHN0aWxsIGJlbGlldmUgdGhlIGFib3ZlIHRleHQgaXMgbm90IHNhdGlzZmFj dG9yeSwgcGxlYXNlDQo+ID4gPiA+ID4gcHJvdmlkZSB5b3VyDQo+ID4gdGV4dC4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IEJlc3QgcmVnYXJkcywNCj4gPiA+ID4gPiBYaWFvaHUNCj4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gTGxveWQgV29vZA0KPiA+ID4gPiA+ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lk d29vZA0KPiA+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+ID4gPiA+ID4gRnJvbTogbXBscyBbbXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgWHV4aWFvaHUNCj4gPiA+ID4gPiA+IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiA+ID4g PiA+ID4gU2VudDogMjMgSmFudWFyeSAyMDE0IDAzOjE2DQo+ID4gPiA+ID4gPiBUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW47IEVnZ2VydCwgTGFycw0KPiA+ID4gPiA+ID4gQ2M6IEpvZWwgSmFlZ2ds aTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBMYXN0IENh bGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiA+IChFbmNhcHN1 bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IEhpDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAtLS0tLdPKvP7Urbz+LS0t LS0NCj4gPiA+ID4gPiA+ID4gt6K8/sjLOiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPiA+ID4gPiA+ ID4gPiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ID4gPiA+ ID4gPiC3osvNyrG85DogMjAxNMTqMdTCMjLI1SAxOTowNQ0KPiA+ID4gPiA+ID4gPiDK1bz+yMs6 IEVnZ2VydCwgTGFycw0KPiA+ID4gPiA+ID4gPiCzrcvNOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0 Zi5vcmc7IFh1eGlhb2h1DQo+ID4gPiA+ID4gPiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxs OiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiA+ID4gPiA+IChFbmNhcHN1 bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiBMYXJzIGFuZCBhbGwsDQo+ID4gPiA+ID4gPiA+IExhc3QgdGltZSBJJ3Zl IGNvdW50ZWQgdGhlIElFVEYgTEMgdGhyZWFkIG9uIHRoaXMgZHJhZnQgaGFzDQo+ID4gPiA+ID4g PiA+IG1vcmUgdGhhbg0KPiA+ID4gPiA+ID4gPiAxNTAgbWVzc2FnZXMgaW4gaXQsIGFuZCBpdCBz ZWVtcyB0aGF0IG9uIHNvbWUgaXNzdWVzDQo+ID4gPiA+ID4gPiA+IChjb25nZXN0aW9uIGNvbnRy b2wgYW5kIFVEUA0KPiA+ID4gPiA+ID4gPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyByb3VuZCB0 aGUgbXVsYmVycnkgYnVzaC4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSU1ITyBhbmQg RldJVzoNCj4gPiA+ID4gPiA+ID4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlz IGEgbm9uLWlzc3VlIGJlY2F1c2UNCj4gPiA+ID4gPiA+ID4gbmF0aXZlIE1QTFMgZG9lcyBub3Qg aGF2ZSBhbnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlDQo+ID4gPiA+ID4gPiA+IGFy ZSBjYXNlcyB3aGVyZSBwYWNrZXRzIGFyZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKSwN Cj4gPiA+ID4gPiA+ID4gYnV0IHNvIGZhciBpdCBkaWQgbm90IHByZXZlbnQgTVBMUyBkZXBsb3lt ZW50LiBUaGVyZSBpcywNCj4gPiA+ID4gPiA+ID4gZS5nLiwgUkZDDQo+ID4gPiA+ID4gPiA+IDQ3 MjAgZm9yIEZDUyByZXRlbnRpb24gaW4gUFdzLCBidXQgSSBkb3VidCBpdCBpcyB3aWRlbHkNCj4g PiA+ID4gPiA+ID4gaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkICh3b3VsZCBiZSBuaWNlIHRvDQo+ ID4gPiA+ID4gPiBrbm93KS4NCj4gPiA+ID4gPiA+ID4gLSBFMkUgY29uZ2VzdGlvbiBjb250cm9s IChyZWdhcmRsZXNzIG9mIGl0cyBpbXBsaWNhdGlvbnMpDQo+ID4gPiA+ID4gPiA+IHNpbXBseSBj YW5ub3QgYmUgYWRkZWQgdG8gdGhpcyBwcm90b2NvbCB3aXRob3V0IHNvbWUgbWFqb3INCj4gPiA+ ID4gPiA+ID4gY2hhbmdlcy4gQSBzaG9ydCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBleHBsYWlu aW5nIHRoYXQNCj4gPiA+ID4gPiA+ID4gc2hvdWxkIHN1ZmZpY2UNCj4gPiBJTU8uDQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gSGkgU2FzaGEsDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSSBm dWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnRzLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEJl c3QgcmVnYXJkcywNCj4gPiA+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gTXkgMmMsDQo+ID4gPiA+ID4gPiA+ICAgICAgICBTYXNoYQ0KPiA+ID4gPiA+ID4gPiBFbWFp bDogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gPiA+ID4gPiA+ID4gTW9iaWxl OiAwNTQtOTI2NjMwMg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+ID4gRnJvbTogbXBscyBbbWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gPiA+ID4gPiA+ID4gRWdnZXJ0LCBM YXJzDQo+ID4gPiA+ID4gPiA+ID4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIyLCAyMDE0IDEy OjIzIFBNDQo+ID4gPiA+ID4gPiA+ID4gVG86IFh1eGlhb2h1DQo+ID4gPiA+ID4gPiA+ID4gQ2M6 IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJl OiBbbXBsc10gTGFzdCBDYWxsOg0KPiA+ID4gPiA+ID4gPiA+IDxkcmFmdC1pZXRmLW1wbHMtaW4t dWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbg0KPiA+ID4gPiA+ID4gPiA+IFVEUCkg dG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IEhp LA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gT24gMjAxNC0xLTIyLCBhdCAxMTox MiwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+IHdyb3RlOg0KPiA+ID4gPiA+ID4g PiA+ID4gSSB3b25kZXIgd2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0sgdG8geW91Og0K PiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IFNpbmNlIHRoZSBNUExTLWluLVVE UCBlbmNhcHN1bGF0aW9uIGNhdXNlcyBNUExTIHBhY2tldHMNCj4gPiA+ID4gPiA+ID4gPiA+IHRv IGJlDQo+ID4gPiA+ID4gPiA+ID4gZm9yd2FyZGVkIHRocm91Z2ggIlVEUCB0dW5uZWxzIiwgdGhl IGNvbmdlc3Rpb24gY29udHJvbA0KPiA+ID4gPiA+ID4gPiA+IGd1aWRlbGluZXMgZm9yIFVEUCB0 dW5uZWxzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuMyBvZg0KPiA+ID4gPiA+ID4gPiA+IFtS RkM1NDA1XSBTSE9VTEQgYmUNCj4gPiA+ID4gPiA+IGZvbGxvd2VkLg0KPiA+ID4gPiA+ID4gPiA+ IFNwZWNpZmljYWxseSwgTVBMUyBjYW4gY2FycnkgYSBudW1iZXIgb2YgZGlmZmVyZW50DQo+ID4g PiA+ID4gPiA+ID4gcHJvdG9jb2xzIGFzDQo+ID4gPiBwYXlsb2Fkcy4NCj4gPiA+ID4gPiA+ID4g PiBXaGVuIGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhh dA0KPiA+ID4gPiA+ID4gPiA+IGlzIGtub3duIGF0IGNvbmZpZ3VyYXRpb24gdGltZSB0byBiZSBJ UC1iYXNlZCBhbmQNCj4gPiA+ID4gPiA+ID4gPiBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBV RFAgdHVubmVsIFNIT1VMRCBOT1QgZW1wbG95DQo+ID4gPiA+ID4gPiA+ID4gaXRzIG93biBjb25n ZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLCBiZWNhdXNlIGNvbmdlc3Rpb24NCj4gPiA+ID4gPiA+ ID4gPiBsb3NzZXMgb2YgdHVubmVsZWQgdHJhZmZpYyB3aWxsIHRyaWdnZXIgYW4gY29uZ2VzdGlv bg0KPiA+ID4gPiA+ID4gPiA+IHJlc3BvbnNlIGF0IHRoZSBvcmlnaW5hbCBzZW5kZXJzIG9mIHRo ZSB0dW5uZWxlZA0KPiA+ID4gPiA+IHRyYWZmaWMuDQo+ID4gPiA+ID4gPiA+ID4gV2hlbiBhbiBV RFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFmZmljIHRoYXQNCj4gPiA+ID4g PiA+ID4gPiBpcyBrbm93biBhdCBjb25maWd1cmF0aW9uIHRpbWUgbm90IHRvIGJlIElQLWJhc2Vk IGFuZA0KPiA+ID4gPiA+ID4gPiA+IGNvbmdlc3Rpb24tY29udHJvbGxlZCwgdGhlIFVEUCB0dW5u ZWwgU0hPVUxEIGVtcGxveSBhbg0KPiA+ID4gPiA+ID4gPiA+IGFwcHJvcHJpYXRlIGNvbmdlc3Rp b24gY29udHJvbCBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluDQo+ID4gPiA+ID4gPiA+ID4gW1JG QzM5ODVdLiBOb3RlIHRoYXQgaXQgU1RST05HTFkgUkVDT01NRU5ERUQgdG8gZGVwbG95DQo+ID4g PiA+ID4gPiA+ID4gc3VjaCBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kgb25seSB3aXRoaW4gYSBT UCBuZXR3b3JrIG9yDQo+ID4gPiA+ID4gPiA+ID4gbmV0d29ya3Mgb2YgYW4gYWRqYWNlbnQgc2V0 IG9mIGNvLW9wZXJhdGluZyBTUHMsIHJhdGhlcg0KPiA+ID4gPiA+ID4gPiA+IHRoYW4gb3ZlciB0 aGUNCj4gPiA+ID4gPiA+IEludGVybmV0Lg0KPiA+ID4gPiA+ID4gPiA+IEZ1cnRoZXJtb3JlLCBw YWNrZXQgZmlsdGVycyBzaG91bGQgYmUgYWRkZWQgdG8gYmxvY2sNCj4gPiA+ID4gPiA+ID4gPiB0 cmFmZmljIHdpdGggdGhlIFVEUCBwb3J0IG51bWJlciBmb3IgTVBMUyBvdmVyIFVEUCB0bw0KPiA+ ID4gPiA+ID4gPiA+IHByZXZlbnQgTVBMUyBvdmVyIFVEUCBwYWNrZXRzIHRvIGVzY2FwZSBmcm9t IHRoZSBzZXJ2aWNlDQo+ID4gPiA+ID4gPiA+ID4gcHJvdmlkZXIgbmV0d29ya3MgZHVlIHRvIG1p c2NvbmZpZ3VhdGlvbiBvciBwYWNrZXQNCj4gPiA+ID4gPiA+ID4gZXJyb3JzLg0KPiA+ID4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVz Y3JpYmUgdGhlIE9BTSBjb250cm9sDQo+ID4gPiA+ID4gPiA+ID4gbG9vcCBpbg0KPiA+ID4gPiA+ ID4gPiA+IChzb21lKSBtb3JlIGRldGFpbCwgcmF0aGVyIHRoYW4gcG9pbnRpbmcgdG8gUkZDMzk4 NSwgd2hpY2gNCj4gPiA+ID4gPiA+ID4gPiBkb2Vzbid0IGhhdmUgYSB3aG9sZSBsb3Qgb2YgZGV0 YWlsIGVpdGhlci4gQWxzbyBiZWNhdXNlDQo+ID4gPiA+ID4gPiA+ID4gdGhlIGFkZGluZyBvZiBm aXJld2FsbCBydWxlcyByZXF1aXJlcyBhbiBPQU0gaG9vay4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gPiA+IFNpbmNlIFNUUk9OR0xZIFJFQ09NTUVOREVEIGlzIG5vdCBhbiBSRkMyMTE5 IHRlcm0gYW5kDQo+ID4gPiA+ID4gPiA+IFJFQ09NTUVOREVEIGlzDQo+ID4gPiA+ID4gPiA+ID4g dG9vIHdlYWssIEknZCBzdWdnZXN0IHRvIGNoYW5nZSB0aGlzIHRvIE1VU1QuDQo+ID4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBGaW5hbGx5LCB0aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1l bnQgc2hvdWxkIGJlIHByb21pbmVudGx5DQo+ID4gPiA+ID4gPiA+ID4gbWFkZSBpbiB0aGUgYWJz dHJhY3QsIGludHJvZHVjdGlvbiwgZXRjLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ ID4gTGFycw0KPiA+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA+ID4gPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPiBt cGxzQGlldGYub3JnDQo+ID4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCg== From xuxiaohu@huawei.com Thu Jan 23 18:47:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA731A0340 for ; Thu, 23 Jan 2014 18:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 LNohVEp7C1NO for ; Thu, 23 Jan 2014 18:47:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E9A661A035A for ; Thu, 23 Jan 2014 18:47:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAJ18017; Fri, 24 Jan 2014 02:47:05 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 02:46:59 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 02:47:04 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 10:46:59 +0800 From: Xuxiaohu To: Edward Crabbe Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF0bUVpx4VpP9lE+4fynfG27EApqQgu4g//+AJQCAAZGOsIABjYUA//+BFACAAIpIYA== Date: Fri, 24 Jan 2014 02:46:58 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247917@NKGEML512-MBS.china.huawei.com> References: <201401212014.s0LKEDXM065730@maildrop2.v6ds.occnc.com> <1811208D-230A-4EA7-B5AA-07E2C0460120@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08246CA3@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478D0@NKGEML512-MBS.china.huawei.com> 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.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247917NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Joel Jaeggli , "mpls@ietf.org" , "Eggert, Lars" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:47:10 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247917NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRWR3YXJkLA0KDQoNClN0ZXdhcnQgaGFkIGdpdmVuIHRoZSBmb2xsb3dpbmcgc3VnZ2VzdGlv bjoNCg0KKysrKysrKysrKysrKysrKysrKysrKysrDQoNCk9uIDIyLzAxLzIwMTQgMDE6MDQsIGwu d29vZEBzdXJyZXkuYWMudWs8bWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWs+IHdyb3RlOg0KDQo+ IEN1cnRpcywNCg0KPg0KDQo+IHRoZSAnaW50ZW5kZWQgZm9yIHVzZSB3aXRoaW4gYSBzZXJ2aWNl IHByb3ZpZGVyJw0KDQpQcmVzdW1hYmxlIHdpdGhpbiBhbiBTUCBvciBhbiBhZGphY2VudCBzZXQg b2YgY28tb3BlcmF0aW5nIFNQcw0KDQoNCg0KU3Rld2FydA0KKysrKysrKysrKysrKysrKysrKysr KysrKw0KDQpTbywgaXQgbWF5IGJlIG1vcmUgY2xlYXIgdG8gY2hhbmdlIKGwd2l0aGluIFNQIG5l dHdvcmtzobEgdG8gobB3aXRoaW4gYW4gU1Agb3IgYW4gYWRqYWNlbnQgc2V0IG9mIGNvLW9wZXJh dGluZyBTUHMgobENCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCreivP7IyzogRWR3YXJkIENy YWJiZSBbbWFpbHRvOmVkY0Bnb29nbGUuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jHUwjI0yNUgMTA6 MjgNCsrVvP7IyzogWHV4aWFvaHUNCrOty806IEVnZ2VydCwgTGFyczsgSm9lbCBKYWVnZ2xpOyBt cGxzQGlldGYub3JnDQrW98ziOiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBs cy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQg U3RhbmRhcmQNCg0KInRoZSBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uIFNIT1VMRCBvbmx5IGJl IGRlcGxveWVkIG9uIGFuIGludHJhZG9tYWluIGJhc2lzLCBhbmQgU0hPVUxEIG5vdCBnZW5lcmFs bHkgdHJhdmVyc2UgaW50ZXJkb21haW4gYm91bmRhcmllcyINCg0KT24gVGh1LCBKYW4gMjMsIDIw MTQgYXQgNjoyMiBQTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlh b2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIExhcnMgYW5kIGFsbCwNCg0KSSB0aGluayBhIGNv bmdlc3Rpb24gY29uc2lkZXJhdGlvbiBzZWN0aW9uIGNvbnRhaW5pbmcgdGhlIGZvbGxvd2luZyB0 ZXh0IGNvdWxkIGJlIHJlbWFpbmVkIGZvciBwZW9wbGUgdG8ga25vdyB0aGUgYmFja2dyb3VuZCBm b3IgdGhlIGFwcGxpY2F0aW9uIHN0YXRlbWVudHMuDQoNCjUuIENvbmdlc3Rpb24gQ29uc2lkZXJh dGlvbnMNCg0KU2luY2UgdGhlIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24gY2F1c2VzIE1QTFMg cGFja2V0cyB0byBiZSBmb3J3YXJkZWQgdGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2Vz dGlvbiBjb250cm9sIGd1aWRlbGluZXMgZm9yIFVEUCB0dW5uZWxzIGFzIGRlZmluZWQgaW4gW1JG QzU0MDVdIFNIT1VMRCBiZSBmb2xsb3dlZC4gU3BlY2lmaWNhbGx5LCBhcyBzdGF0ZWQgaW4gU2Vj dGlvbiAzLjEuMyBvZiBbUkZDNTQwNV0gIi4uLkZpbmFsbHksIHNvbWUgYnVsayB0cmFuc2ZlciBh cHBsaWNhdGlvbnMgbWF5IGNob29zZSBub3QgdG8gaW1wbGVtZW50IGFueSBjb25nZXN0aW9uIGNv bnRyb2wgbWVjaGFuaXNtIGFuZCBpbnN0ZWFkIHJlbHkgb24gdHJhbnNtaXR0aW5nIGFjcm9zcyBy ZXNlcnZlZCBwYXRoIGNhcGFjaXR5LiBUaGlzIG1pZ2h0IGJlIGFuIGFjY2VwdGFibGUgY2hvaWNl IGZvciBhIHN1YnNldCBvZiByZXN0cmljdGVkIG5ldHdvcmtpbmcgZW52aXJvbm1lbnRzLCBidXQg aXMgYnkgbm8gbWVhbnMgYSBzYWZlIHByYWN0aWNlIGZvciBvcGVyYXRpb24gaW4gdGhlIEludGVy bmV0LiAiIER1ZSB0byB0aGUgZmFjdCB0aGF0IHRoZSBwcm92ZW4gTVBMUy1pbi1HUkUgYW5kIE1Q TFMtaW4tSVAgW1JGQzQwMjNdIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9naWVzIGhhdmUgYmVlbiBz dWNjZXNzZnVsbHkgZGVwbG95ZWQgd2l0aGluIFNQIG5ldHdvcmtzIHdpdGhvdXQgYW55IGNvbmdl c3Rpb24gY29udHJvbCBtZWNoYW5pc20gYW5kIHRoZSBmYWN0IHRoYXQgdGhlIGN1cnJlbnQgTVBM UyB0ZWNobm9sb2d5IGNvdWxkbid0IHByb3ZpZGUgY29uZ2VzdGlvbiBjb250cm9sIHdpdGhvdXQg bWFqb3IgY2hhbmdlcywgdGhlIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24gTVVTVCBvbmx5IGJl IGRlcGxveWVkIGluIFNQIG5ldHdvcmtzIHdoaWNoIGlzIGEgcmVzdHJpY3RlZCBuZXR3b3JrIGVu dmlyb25tZW50Lg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLdPKvP7Urbz+LS0t LS0NCj4gt6K8/sjLOiBYdXhpYW9odQ0KPiC3osvNyrG85DogMjAxNMTqMdTCMjPI1SAxMTowMQ0K PiDK1bz+yMs6ICdFZ2dlcnQsIExhcnMnDQo+ILOty806IGN1cnRpc0BpcHY2Lm9jY25jLmNvbTxt YWlsdG86Y3VydGlzQGlwdjYub2NjbmMuY29tPjsgSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3Jn PG1haWx0bzptcGxzQGlldGYub3JnPg0KPiDW98ziOiByZTogW21wbHNdIExhc3QgQ2FsbDogPGRy YWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluDQo+IFVE UCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4NCj4gSGkgTGFycywNCj4NCj4gPiAtLS0tLdPKvP7U rbz+LS0tLS0NCj4gPiC3orz+yMs6IEVnZ2VydCwgTGFycyBbbWFpbHRvOmxhcnNAbmV0YXBwLmNv bTxtYWlsdG86bGFyc0BuZXRhcHAuY29tPl0NCj4gPiC3osvNyrG85DogMjAxNMTqMdTCMjLI1SAx ODoyMw0KPiA+IMrVvP7IyzogWHV4aWFvaHUNCj4gPiCzrcvNOiBjdXJ0aXNAaXB2Ni5vY2NuYy5j b208bWFpbHRvOmN1cnRpc0BpcHY2Lm9jY25jLmNvbT47IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRm Lm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gPiDW98ziOiBSZTogW21wbHNdIExhc3QgQ2Fs bDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+IChFbmNhcHN1bGF0aW5nIE1Q TFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBP biAyMDE0LTEtMjIsIGF0IDExOjEyLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWls dG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPiA+ID4gSSB3b25kZXIgd2hldGhlciB0 aGUgZm9sbG93aW5nIHRleHQgaXMgT0sgdG8geW91Og0KPiA+ID4NCj4gPiA+IFNpbmNlIHRoZSBN UExTLWluLVVEUCBlbmNhcHN1bGF0aW9uIGNhdXNlcyBNUExTIHBhY2tldHMgdG8gYmUNCj4gPiA+ IGZvcndhcmRlZA0KPiA+IHRocm91Z2ggIlVEUCB0dW5uZWxzIiwgdGhlIGNvbmdlc3Rpb24gY29u dHJvbCBndWlkZWxpbmVzIGZvciBVRFANCj4gPiB0dW5uZWxzIGFzIGRlZmluZWQgaW4gU2VjdGlv biAzLjEuMyBvZiBbUkZDNTQwNV0gU0hPVUxEIGJlIGZvbGxvd2VkLg0KPiA+IFNwZWNpZmljYWxs eSwgTVBMUyBjYW4gY2FycnkgYSBudW1iZXIgb2YgZGlmZmVyZW50IHByb3RvY29scyBhcw0KPiA+ IHBheWxvYWRzLiBXaGVuIGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRy YWZmaWMgdGhhdCBpcw0KPiA+IGtub3duIGF0IGNvbmZpZ3VyYXRpb24gdGltZSB0byBiZSBJUC1i YXNlZCBhbmQgY29uZ2VzdGlvbi1jb250cm9sbGVkLA0KPiA+IHRoZSBVRFAgdHVubmVsIFNIT1VM RCBOT1QgZW1wbG95IGl0cyBvd24gY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSwNCj4gPiBi ZWNhdXNlIGNvbmdlc3Rpb24gbG9zc2VzIG9mIHR1bm5lbGVkIHRyYWZmaWMgd2lsbCB0cmlnZ2Vy IGFuIGNvbmdlc3Rpb24NCj4gcmVzcG9uc2UgYXQgdGhlIG9yaWdpbmFsIHNlbmRlcnMgb2YgdGhl IHR1bm5lbGVkIHRyYWZmaWMuDQo+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1Q TFMgcGF5bG9hZCB0cmFmZmljIHRoYXQgaXMga25vd24gYXQNCj4gPiBjb25maWd1cmF0aW9uIHRp bWUgbm90IHRvIGJlIElQLWJhc2VkIGFuZCBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZQ0KPiA+ IFVEUCB0dW5uZWwgU0hPVUxEIGVtcGxveSBhbiBhcHByb3ByaWF0ZSBjb25nZXN0aW9uIGNvbnRy b2wgbWVjaGFuaXNtDQo+ID4gYXMgZGVzY3JpYmVkIGluIFtSRkMzOTg1XS4gTm90ZSB0aGF0IGl0 IFNUUk9OR0xZIFJFQ09NTUVOREVEIHRvIGRlcGxveQ0KPiA+IHN1Y2ggZW5jYXBzdWxhdGlvbiB0 ZWNobm9sb2d5IG9ubHkgd2l0aGluIGEgU1AgbmV0d29yayBvciBuZXR3b3JrcyBvZg0KPiA+IGFu IGFkamFjZW50IHNldCBvZiBjby1vcGVyYXRpbmcgU1BzLCByYXRoZXIgdGhhbiBvdmVyIHRoZSBJ bnRlcm5ldC4NCj4gPiBGdXJ0aGVybW9yZSwgcGFja2V0IGZpbHRlcnMgc2hvdWxkIGJlIGFkZGVk IHRvIGJsb2NrIHRyYWZmaWMgd2l0aCB0aGUNCj4gPiBVRFAgcG9ydCBudW1iZXIgZm9yIE1QTFMg b3ZlciBVRFAgdG8gcHJldmVudCBNUExTIG92ZXIgVURQIHBhY2tldHMgdG8NCj4gPiBlc2NhcGUg ZnJvbSB0aGUgc2VydmljZSBwcm92aWRlciBuZXR3b3JrcyBkdWUgdG8gbWlzY29uZmlndWF0aW9u IG9yIHBhY2tldA0KPiBlcnJvcnMuDQo+ID4NCj4gPiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRl ciB0byBkZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wgbG9vcCBpbiAoc29tZSkNCj4gPiBtb3JlIGRl dGFpbCwgcmF0aGVyIHRoYW4gcG9pbnRpbmcgdG8gUkZDMzk4NSwgd2hpY2ggZG9lc24ndCBoYXZl IGENCj4gPiB3aG9sZSBsb3Qgb2YgZGV0YWlsIGVpdGhlci4gQWxzbyBiZWNhdXNlIHRoZSBhZGRp bmcgb2YgZmlyZXdhbGwgcnVsZXMgcmVxdWlyZXMgYW4NCj4gT0FNIGhvb2suDQo+ID4NCj4gPiBT aW5jZSBTVFJPTkdMWSBSRUNPTU1FTkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJtIGFuZA0KPiBS RUNPTU1FTkRFRCBpcw0KPiA+IHRvbyB3ZWFrLCBJJ2Qgc3VnZ2VzdCB0byBjaGFuZ2UgdGhpcyB0 byBNVVNULg0KPg0KPiBJdCdzIGZpbmUgdG8gbWFrZSB0aGF0IGNoYW5nZS4NCj4NCj4gPiBGaW5h bGx5LCB0aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgc2hvdWxkIGJlIHByb21pbmVudGx5IG1h ZGUgaW4gdGhlDQo+ID4gYWJzdHJhY3QsIGludHJvZHVjdGlvbiwgZXRjLg0KPg0KPiBUaGUgYXBw bGljYXRpb24gc3RhdGVtZW50IGlzIHByb21pbmVudGx5IGRlc2NyaWJlZCBpbiBhIGRlZGljYXRl ZCBzdWItc2VjdGlvbiBvZg0KPiB0aGUgSW50cm9kdWN0aW9uIFNlY3Rpb24gYXMgZm9sbG93czoN Cj4NCj4gMS4zLiBBcHBsaWNhdGlvbiBTdGF0ZW1lbnRzDQo+DQo+IFRoZSBNUExTLWluLVVEUCBl bmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kgTVVTVCBvbmx5IGJlIGRlcGxveWVkIHdpdGhpbiBhIFNQ DQo+IG5ldHdvcmsgb3IgbmV0d29ya3Mgb2YgYW4gYWRqYWNlbnQgc2V0IG9mIGNvLW9wZXJhdGlu ZyBTUHMgd2hlcmUgdGhlDQo+IGNvbmdlc3Rpb24gY29udHJvbCBpcyBub3QgYSBjb25jZXJuLCBy YXRoZXIgdGhhbiBvdmVyIHRoZSBJbnRlcm5ldCB3aGVyZSB0aGUNCj4gY29uZ2VzdGlvbiBjb250 cm9sIGlzIGEgbXVzdC4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3VsZCBiZSBhZGRl ZCB0bw0KPiBwcmV2ZW50IE1QTFMgb3ZlciBVRFAgcGFja2V0cyBmcm9tIGVzY2FwaW5nIGZyb20g dGhlIHNlcnZpY2UgcHJvdmlkZXINCj4gbmV0d29ya3MgZHVlIHRvIG1pc2NvbmZpZ3VhdGlvbiBv ciBwYWNrZXQgZXJyb3JzLiBOb3RlIHRoYXQgdGhlIHByb3Zlbg0KPiBNUExTLWluLUdSRSBhbmQg TVBMUy1pbi1JUCBbUkZDNDAyM10gZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2dpZXMgd2hpY2ggaGF2 ZQ0KPiBhbHJlYWR5IGJlZW4gZGVwbG95ZWQgd2l0aGluIFNQIG5ldHdvcmtzIGRvbid0IHJlcXVp cmUgYW55IGNvbmdlc3Rpb24gY29udHJvbA0KPiBtZWNoYW5pc20uDQo+DQo+IEluIGFkZGl0aW9u LCB0aGUgZm9sbG93aW5nIHRleHQgaXMgYWRkZWQgdG8gdGhlIGFic3RyYWN0IHNlY3Rpb246IiBO b3RlIHRoYXQgdGhlDQo+IE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9neSBNVVNU IG9ubHkgYmUgZGVwbG95ZWQgd2l0aGluIGEgU1ANCj4gbmV0d29yayBvciBuZXR3b3JrcyBvZiBh biBhZGphY2VudCBzZXQgb2YgY28tb3BlcmF0aW5nIFNQcyB3aGVyZSB0aGUNCj4gY29uZ2VzdGlv biBjb250cm9sIGlzIG5vdCBhIGNvbmNlcm4uIg0KPg0KPiBEdWUgdG8gdGhlIGFib3ZlIGV4cGxp Y2l0IGFwcGxpY2F0aW9uIHN0YXRlbWVudCwgSSB3b25kZXIgd2hldGhlciBpdCdzIHN0aWxsDQo+ IG5lY2Vzc2FyeSB0byBkZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wgbG9vcCBpbiAoc29tZSkgbW9y ZSBkZXRhaWwsIHJhdGhlciB0aGFuDQo+IHNpbXBseSBwb2ludGluZyB0byBSRkMzOTg1LiBJIGV2 ZW4gd29uZGVyIHdoZXRoZXIgaXQncyBzdGlsbCBuZWNlc3NhcnkgdG8gcmVtYWluDQo+IHRoZSBj b25nZXN0aW9uIGNvbnNpZGVyYXRpb24gc2VjdGlvbi4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBY aWFvaHUNCj4NCj4gPiBMYXJzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247917NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Edward,=

 = ;

Stewart had given the follow= ing suggestion:

 = ;

++= +++++++++++++++= +++++++

On 22/01/2014 01:04, l.wood@surrey.ac.uk wrote:

> Curtis,

> =

> the 'intended for use w= ithin a service provider'

Presumable within an SP or a= n adjacent set of co-operating SPs

 

Stewart

++= +++++++++++++++= ++++++++

 = ;

So, it may= be more clear to change =A1=B0within SP networks=A1=B1 to =A1=B0within an = SP or an adjacent set of co-operating SPs =A1=B1

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8= =CB: Edward Crabbe [mailto:edc@google.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C224=C8=D5 1= 0:28
=CA=D5=BC=FE=C8=CB: Xuxiaohu
=B3=AD=CB=CD: Eggert, Lars; Joel Jaeggli; mpls@ietf.org
=D6=F7=CC=E2: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulatin= g MPLS in UDP) to Proposed Standard

 

"the MPLS-in-UDP enca= psulation SHOULD only be deployed on an intradomain basis, and SHOULD not g= enerally traverse interdomain boundaries"<= o:p>

=  

On Thu, Jan 23, 2014 at 6:22 PM= , Xuxiaohu <xux= iaohu@huawei.com> wrote:

Hi Lars and all,

I think a congestion consideration section containing the following text co= uld be remained for people to know the background for the application state= ments.

5. Congestion Considerations

Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded thr= ough "UDP tunnels", the congestion control guidelines for UDP tun= nels as defined in [RFC5405] SHOULD be followed. Specifically, as stated in= Section 3.1.3 of [RFC5405] "...Finally, some bulk transfer applications may choose not to implement any congestion cont= rol mechanism and instead rely on transmitting across reserved path capacit= y. This might be an acceptable choice for a subset of restricted networking= environments, but is by no means a safe practice for operation in the Internet. " Due to the fact that= the proven MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation technologies= have been successfully deployed within SP networks without any congestion = control mechanism and the fact that the current MPLS technology couldn't provide congestion control without major = changes, the MPLS-in-UDP encapsulation MUST only be deployed in SP networks= which is a restricted network environment.

Best regards,
Xiaohu

> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Xuxiaohu
> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4= =EA1=D4=C223=C8=D5<= span lang=3D"EN-US"> 11:01
> =CA=D5=BC=FE=C8=CB: 'Eggert, Lars'

> =B3=AD=CB=CD: curtis@ipv6.occnc.com; Joel Jaeggli; m= pls@ietf.org

> =D6=F7=CC=E2: re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>= (Encapsulating MPLS in
> UDP) to Proposed Standard
>

> Hi Lars,
>
> > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Eggert, Lars [mai= lto:lars@netapp.com]
> > =B7=A2=CB=CD=CA=B1=BC=E4: 2014= =C4=EA1=D4=C222=C8= =D5 18:23
> > =CA=D5=BC=FE=C8=CB: Xuxiaohu

> > =B3=AD=CB=CD: curtis@ipv6.occnc.com; Joel Jaeggli; m= pls@ietf.org

> > =D6=F7=CC=E2: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.tx= t>
> > (Encapsulating MPLS in UDP) to Proposed Standard
> >

> > Hi,
> >
> > On 2014-1-22, at 11:12, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> > > I wonder whether the following text is OK to you:
> > >
> > > Since the MPLS-in-UDP encapsulation causes MPLS packets to b= e
> > > forwarded
> > through "UDP tunnels", the congestion control guideline= s for UDP
> > tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be follow= ed.
> > Specifically, MPLS can carry a number of different protocols as > > payloads. When an UDP tunnel is used for MPLS payload traffic tha= t is
> > known at configuration time to be IP-based and congestion-control= led,
> > the UDP tunnel SHOULD NOT employ its own congestion control mecha= nism,
> > because congestion losses of tunneled traffic will trigger an con= gestion
> response at the original senders of the tunneled traffic.
> > When an UDP tunnel is used for MPLS payload traffic that is known= at
> > configuration time not to be IP-based and congestion-controlled, = the
> > UDP tunnel SHOULD employ an appropriate congestion control mechan= ism
> > as described in [RFC3985]. Note that it STRONGLY RECOMMENDED to d= eploy
> > such encapsulation technology only within a SP network or network= s of
> > an adjacent set of co-operating SPs, rather than over the Interne= t.
> > Furthermore, packet filters should be added to block traffic with= the
> > UDP port number for MPLS over UDP to prevent MPLS over UDP packet= s to
> > escape from the service provider networks due to misconfiguation = or packet
> errors.
> >
> > I think it would be better to describe the OAM control loop in (s= ome)
> > more detail, rather than pointing to RFC3985, which doesn't have = a
> > whole lot of detail either. Also because the adding of firewall r= ules requires an
> OAM hook.
> >
> > Since STRONGLY RECOMMENDED is not an RFC2119 term and
> RECOMMENDED is
> > too weak, I'd suggest to change this to MUST.
>

> It's fine to make that cha= nge.
>

> > Finally, the applicab= ility statement should be prominently made in the
> > abstract, introduction, etc.
>

> The application statement = is prominently described in a dedicated sub-section of
> the Introduction Section as follows:
>
> 1.3. Application Statements
>

> The MPLS-in-UDP encapsulat= ion technology MUST only be deployed within a SP

> network or networks of an = adjacent set of co-operating SPs where the
> congestion control is not a concern, rather than over the Internet whe= re the

> congestion control is a mu= st. Furthermore, packet filters should be added to
> prevent MPLS over UDP packets from escaping from the service provider<= o:p>

> networks due to misconfigu= ation or packet errors. Note that the proven
> MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation technologies which = have
> already been deployed within SP networks don't require any congestion = control
> mechanism.
>
> In addition, the following text is added to the abstract section:"= ; Note that the

> MPLS-in-UDP encapsulation = technology MUST only be deployed within a SP

> network or networks of an = adjacent set of co-operating SPs where the
> congestion control is not a concern."
>
> Due to the above explicit application statement, I wonder whether it's= still

> necessary to describe the = OAM control loop in (some) more detail, rather than

> simply pointing to RFC3985= . I even wonder whether it's still necessary to remain
> the congestion consideration section.
>
> Best regards,
> Xiaohu
>
> > Lars

_______________________________= ________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247917NKGEML512MBSchi_-- From curtis@ipv6.occnc.com Thu Jan 23 19:21:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A241A012A; Thu, 23 Jan 2014 19:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RP_MATCHES_RCVD=-0.535, 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 mIB3PqSSyeRi; Thu, 23 Jan 2014 19:20:58 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1B1A018F; Thu, 23 Jan 2014 19:20:57 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0O3KsR9013700; Thu, 23 Jan 2014 22:20:54 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> To: Joe Touch From: Curtis Villamizar In-reply-to: Your message of "Thu, 23 Jan 2014 13:22:24 -0800." <52E18810.1010701@isi.edu> Date: Thu, 23 Jan 2014 22:20:54 -0500 Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 03:21:02 -0000 In message <52E18810.1010701@isi.edu> Joe Touch writes: > Curtis, > > If you're going with this argument (SHOULD vs MUST), then you need to > explain exactly *why* you're not doing what's recommended. "SHOULD" > isn't carte blanche to claim an exception. > > And the need to avoid layered congestion control is a good justification > for not layering TCP-friendly on top of TCP-friendly, but not for > avoiding circuit breaker-style congestion controls/limits. > > Joe Joe, I agree with you that the word SHOULD is not an automatic pass and quoted from RFC 2119 because I think that on this thread the criteria "valid reasons in particular circumstances" and "implications ... carefully weighed" have both been met. Perhaps you joined the discussion a little late. Please allow me to recap. There are two issues under discussion, UDP checksums and congestion control. All parties seem to be OK with limiting the use of MPLS over UDP to service providers only within their own infrastructure only, except among cooperating service providers with explicit agreement (consenting adults). Within that context, some service providers find that parts of their infrastructure either doesn't support MPLS at all or doesn't support a usable variation of multipath for MPLS but does support IP ECMP (as I understand it, this is primarily in the fringes, access and less so edge - but someone who knows for sure please correct me if not). This eliminates the "expands the reach of MPLS argument". First UDP checksums: The UDP checksum is at the beginning of the payload. Please see http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html This makes filling in a new UDP checksum infeasible on most high end hardware. Within all of that context, all of the links have at least 32 bit FCS (either Ethernet framing or SONET or OTN) and some has much better such as the FEC found in OTN. This makes undetected corruption by any of the links extremely unlikely. Corruption internal to the router the only potential impact. There is good reason to think that this is extremely rare. Infeasibility of doing UDP checksums in some instances (not just performance concerns) is sufficient to make use of UDP checksums a SHOULD. On to congestion control: Some MPLS payloads such as IP over MPLS have congestion control. While it can't be assured that all IP traffic makes use of congestion control, the problem is in the UDP services carried over MPLS regardless of whether MPLS over UDP is used. The only other type of traffic carried by MPLS in any volume (not counting ISIS control traffic carried as CLNP over MPLS, for example) is PW. PW in turn supports Ethernet, FR, ATM, TDM, and maybe a few others. The vast majority of payload in Ethernet, FR, ATM, is IP so were are back to the prior bullet. It PW packlet carrying Ethernet, FR, or ATM are dropped the congestion response is virtually identical to IP because the payload is IP. The other PW case is TDM. TDM serves two purposes in SP networks. A small number of legacy customers circuits, generally T1 or T3 use it. These are 1.5 and 45 Mb/s services on 1 Gb/s and 10 Gb/s links. Hardly a source of congestion, plus they pay a lot more and therefore are priority traffic. Another is 3G mobile backhaul. Again this is T1 or T3, but maybe as much as small multiples of T3. Still very low capacity. TCP-like congestion control in a tunnel is very bad for any TCP carried within the tunnel. The vast majority on MPLS traffic is IP and therefore is TCP. Regardless of the weak argument in favor of it given the operational reality, the authors have conceded to state that "MPLS over UDP SHOULD have congestion control" in the document. Because in the scenario it is intended to be deploy congestion control is very unlikely to prove to be needed, defining the exact form of congestion control is deferred to a later document which will be written only if needed. That said, I have in the past argued that the "circuit breaker" form of congestion control would be one of the worst things we could possibly do. It would be terrible for TCP and most anything else. See http://www.ietf.org/mail-archive/web/mpls/current/msg11262.html The right place to put any circuit breaker would be TDM over PW, but given the capacities involved, that is not really needed either. In the past I've said: The technical sticky point is knowing that the congestion is occuring. Perhaps a LM like packet on another UDP port could be exchanged with the same caveats about inaccuracy if implemented in software and inaccuracy if reordering occurs, and a recommendation can be made to do something to introduce drop if congestion is indicated by this method. How to introduce drop should be an implementation detail, a form of AQM or leaky bucket being possible choices, but entirely a local matter. MPLS LM OAM would be a good choice for detection of congestion (as evidenced by loss). A leaky bucket (aka shaper) likely with AQM seems like a reasonable choice. This could be put into another document if a need ever truly arises for congestion control in MPLS and it could be applied to MPLS over anything (though it could prove impractical for MPLS over avian carrier). Curtis > On 1/21/2014 12:58 PM, Curtis Villamizar wrote: > > Lars, > > > > The IETF consensus in RFC5405 was to put a SHOULD in regarding use of > > congestion control in tunneling protocols. > > > > RFC2119 states: > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > > > We have discussed the reasons why congestion control is in general a > > good thing. We have also discussed why there may be valid reasons to > > not include congestion control in MPLS over UDP. > > > > The question is not whether there is already IETF consensus on > > congestion control in UDP in general. There is consensus and that > > consensus was to use the word "SHOULD". > > > > The question we now face is whether MPLS in UDP needs to up the prior > > consensus to a MUST or can keep it as SHOULD. I see one or maybe two > > people vigorously arguing to upgrade this to a MUST and otherwise > > consensus to keep this as SHOULD. Further I see no objection except > > the same one or maybe two people to making the congestion control the > > topic of a later work if a need for it arises. Consensus does not > > require unanimous agreeement. > > > > If we are trying to gauge consensus, maybe both you and I should sit > > back and let other people weigh in. > > > > Curtis > > > > > > In message > > "Eggert, Lars" writes: > >> > >> Hi, > >> > >> On 2014-1-17, at 18:19, Curtis Villamizar wrote: > >>> You have made your assertions about your desire to uphold the purity > >>> of any new UDP applications and adhere to the BCP you wrote. > >>> =20 > >>> You appear to be very nearly alone in this argument and certainly no > >>> one that works with MPLS is siding with you. > >> > >> the reason we wrote the RFC when I was TSV AD was that we were seeing a = > >> whole bunch of questionable uses of UDP over the eyars and we were = > >> having the same arguments over and over. That's why we decided to write = > >> down the practices we expect users of UDP to follow. This is yet another = > >> such questionable use. > >> > >> (Also, I don't appreciate you turning this into a personal argument.) > > > > Nothing personal intended. > > > > The important point is the sentence "You appear to be very nearly > > alone in this argument and certainly no one that works with MPLS is > > siding with you." was intended to point out that there is no consensus > > behind your argument regardless of how vigorously you make that > > argument. > > > >>> In the end we can put anything we want in the RFC *but* IETF has never > >>> truly had the final word on what vendors and operators do in provider > >>> networks. > >> > >> Aka the "take my toys and go home" argument. Heard it many times. > > > > It has been successful many times in the past. It turns into the "its > > deployed so get over it" argument after a few years. > > > >>> In this case, regardless of what changes are made to the draft, > >>> implementations will offer at least the option for non-RFC behavior by > >>> using zero checksums and not using any congestion control. And > >>> providers will make use of it, perhaps exclusively. > >> > >> And there's nothing wrong with that - the BCP even says that one SHOULD = > >> NOT use congestion control for some deployment cases. > >> > >> But for others, one SHOULD. For those, a mechanism needs to be = > >> available, i.e., it needs to be specified and implemented. > >> > >>> The document might as well reflect reality, despite reality not > >>> conforming to your notions of architectural purity. > >> > >> I'm sorry, but we have certain architectural principles in the Internet = > >> that we have IETF consensus on. At least since RFC2914, that includes = > >> the need to have congestion control in place. > >> > >> There are always special deployment scenarios where these principles do = > >> not apply, and we typically explain in applicability statements when out = > >> specifications can only be safely used under certain conditions. I don't = > >> see any such statement in draft-ietf-mpls-in-udp, which to me means it's = > >> targeted at general Internet-wide use. > >> > >>> The best course of action is to put a SHOULD in regarding checksums > >>> and put a SHOULD in regarding congestion avoidance. Even the BCP does > >>> not go any further than to say a tunneling protocol SHOULD use > >>> congestion control and there were reasons that the word MUST was not > >>> acceptable in the BCP. > >> > >> The SHOULD for congestion control needs to actually describe a mechanism = > >> that can be used when needed. It can't be a blanket "you SHOULD use = > >> something but we don't tell you what it is"-statement. > >> > >>> If we are still arguing over two instances of SHOULD vs MUST we have > >>> wasted a lot of bandwidth on those two words. > >> > >> It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it needs = > >> to be specified what is to be done. In the case of checksums, that's = > >> obvious (calculate it and check it); in the case of congestion control, = > >> some actual mechanism needs to be described (e.g., a circuit breaker). > >> > >>> IMHO The only remaining question is whether the document can go = > >> forward > >>> with the definition of congestion control for MPLS over UDP left out > >>> of scope and for another document if a need arises. > >> > >> In my opinion, it cannot. > >> > >>> If this is not acceptable to you (I doubt it is) please indicate what > >>> you would like to see in the document and since this is IETF last call > >>> where consensus matters and no one individual has veto power, we'll > >>> have to see if there is consensus behind your proposed changes. > >> > >> I would like the document to specify at the very least a circuit breaker = > >> mechanism, that stops the tunneled traffic if severe packet loss is = > >> detected along the path. > >> > >> And this isn't about an "individual veto". This is about a document that = > >> is at the moment in violation of IETF consensus at least as far back as = > >> RFC2914. > >> > >> Lars From curtis@ipv6.occnc.com Thu Jan 23 19:52:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4121A025B for ; Thu, 23 Jan 2014 19:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RP_MATCHES_RCVD=-0.535, 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 Lb8tE7rW2RdK for ; Thu, 23 Jan 2014 19:52:50 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id BD5E31A025A for ; Thu, 23 Jan 2014 19:52:49 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0O3qVia014059; Thu, 23 Jan 2014 22:52:32 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Thu, 23 Jan 2014 17:18:22 +0000." <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> Date: Thu, 23 Jan 2014 22:52:31 -0500 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 03:52:57 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > the text is not satisfactory. never recommend setting to zero, > as that poses a risk to your and to other traffic. Suggested text: > *** > The UDP checksum SHOULD be used to protect the payload and > ensure correct demultiplexing and delivery to the tunnel, and not to > other UDP destinations, by protecting the UDP pseudoheader. > Use of a zero UDP checksum is NOT RECOMMENDED, even when > desired for performance or necessitated by implementation > reasons, for the reasons outlined in [RFC6936] section 3. I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to zero). There are cases where it is impossible so it can't be MUST. > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS > stack integrity check while avoiding the overhead of computing an > integrity check over a tunnelled frame that has its own integrity check. UDP-List doesn't solve the ECMP problems because most of the older LSR that are forcing the use of MPLS over UDP to get ECMP don't look at the port numbers if the protocol is not 6 or 17. But this has only been said three or four times so maybe you missed it. > *** > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Xuxiaohu [xuxiaohu@huawei.com] > Sent: 23 January 2014 12:35 > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; lars@netapp.com > Cc: joelja@bogus.com; mpls@ietf.org > Subject: re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > > -----ÓʼþÔ­¼þ----- > > ·¢¼þÈË: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ23ÈÕ 12:44 > > ÊÕ¼þÈË: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com > > ³­ËÍ: joelja@bogus.com; mpls@ietf.org > > Ö÷Ìâ: RE: [mpls] Last Call: (Encapsulating MPLS > > in UDP) to Proposed Standard > > > > Sasha > > > > > - UDP checksums (or lack thereof) is a non-issue because native MPLS > > > does not have anything like that. And yes, there are cases where > > > packets are corrupted within the routers) > > > > So you admit that packets can be corrupted within the routers - a check that can > > only be caught by an end-to-end check, a corruption that can lead to the > > problems detailed in RFC 6936 section 3 - and then you say it's a non-issue > > because this doesn't affect native MPLS. But we're not doing native MPLS here. > > We're doing MPLS over UDP. > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's an issue. > > Please read the other 150 messages that you refer to. > > Hi Lloyd, > > The draft doesn't require the IPv6 UDP checksum to be set to zero regardless. See the following text quoted from that draft: > > UDP Checksum > > The usage of this field is in accordance with the current UDP specification [RFC768]. To simplify the operation on the decapsulator, this field is RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In the IPv6 UDP encapsulation case, if appropriate according to the requirements defined in [RFC6935] [RFC6936], this field is also RECOMMENDED to be set to zero. Specifically, if the MPLS payload is Internet Protocol (IPv4 or IPv6) packets, it is RECOMMENDED to be set to zero when the inner packet integrity checks is available. In addition, if the MPLS payload is non-IP packet which is specifically designed for transmission over a lower layer that does not provide a packet integrity guarantee, it is RECOMMENDED to be set to zero as well. Otherwise, using zero checksum is NOT RECOMMENDED. Note that other IP encapsulations for MPLS do not have a checksum in the tunnel header. > > If you still believe the above text is not satisfactory, please provide your text. > > Best regards, > Xiaohu > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > [xuxiaohu@huawei.com] > > Sent: 23 January 2014 03:16 > > To: Alexander Vainshtein; Eggert, Lars > > Cc: Joel Jaeggli; mpls@ietf.org > > Subject: Re: [mpls] Last Call: (Encapsulating > > MPLS in UDP) to Proposed Standard > > > > Hi > > > > > -----ÓʼþÔ­¼þ----- > > > ·¢¼þÈË: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ22ÈÕ 19:05 > > > ÊÕ¼þÈË: Eggert, Lars > > > ³­ËÍ: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > Lars and all, > > > Last time I've counted the IETF LC thread on this draft has more than > > > 150 messages in it, and it seems that on some issues (congestion > > > control and UDP > > > checksums) we are going round the mulberry bush. > > > > > > IMHO and FWIW: > > > - UDP checksums (or lack thereof) is a non-issue because native MPLS > > > does not have anything like that. And yes, there are cases where > > > packets are corrupted within the routers), but so far it did not > > > prevent MPLS deployment. There is, e.g., RFC 4720 for FCS retention in > > > PWs, but I doubt it is widely implemented and deployed (would be nice to > > know). > > > - E2E congestion control (regardless of its implications) simply > > > cannot be added to this protocol without some major changes. A short > > > applicability statement explaining that should suffice IMO. > > > > Hi Sasha, > > > > I fully agree with your points. > > > > Best regards, > > Xiaohu > > > > > My 2c, > > > Sasha > > > Email: Alexander.Vainshtein@ecitele.com > > > Mobile: 054-9266302 > > > > > > > -----Original Message----- > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > To: Xuxiaohu > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > Subject: Re: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Hi, > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > > > forwarded through "UDP tunnels", the congestion control guidelines > > > > for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be > > followed. > > > > Specifically, MPLS can carry a number of different protocols as payloads. > > > > When an UDP tunnel is used for MPLS payload traffic that is known at > > > > configuration time to be IP-based and congestion-controlled, the UDP > > > > tunnel SHOULD NOT employ its own congestion control mechanism, > > > > because congestion losses of tunneled traffic will trigger an > > > > congestion response at the original senders of the tunneled traffic. > > > > When an UDP tunnel is used for MPLS payload traffic that is known at > > > > configuration time not to be IP-based and congestion-controlled, the > > > > UDP tunnel SHOULD employ an appropriate congestion control mechanism > > > > as described in [RFC3985]. Note that it STRONGLY RECOMMENDED to > > > > deploy such encapsulation technology only within a SP network or > > > > networks of an adjacent set of co-operating SPs, rather than over the > > Internet. > > > > Furthermore, packet filters should be added to block traffic with > > > > the UDP port number for MPLS over UDP to prevent MPLS over UDP > > > > packets to escape from the service provider networks due to > > > > misconfiguation or packet > > > errors. > > > > > > > > I think it would be better to describe the OAM control loop in > > > > (some) more detail, rather than pointing to RFC3985, which doesn't > > > > have a whole lot of detail either. Also because the adding of > > > > firewall rules requires an OAM hook. > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > RECOMMENDED is > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > Finally, the applicability statement should be prominently made in > > > > the abstract, introduction, etc. > > > > > > > > Lars From xuxiaohu@huawei.com Thu Jan 23 20:01:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7021A0383 for ; Thu, 23 Jan 2014 20:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 t78tKKq2tnlc for ; Thu, 23 Jan 2014 20:01:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8284E1A0360 for ; Thu, 23 Jan 2014 20:01:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCW26393; Fri, 24 Jan 2014 04:00:59 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 04:00:51 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 04:00:56 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 12:00:54 +0800 From: Xuxiaohu To: "curtis@ipv6.occnc.com" , "l.wood@surrey.ac.uk" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGLe0Vpx4VpP9lE+4fynfG27EApqTPtnw Date: Fri, 24 Jan 2014 04:00:53 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247954@NKGEML512-MBS.china.huawei.com> References: Your message of "Thu, 23 Jan 2014 17:18:22 +0000." <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com> In-Reply-To: <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" , "lars@netapp.com" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 04:01:07 -0000 SGksDQoNClBsZWFzZSBjaGVjayB3aGV0aGVyIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBPSy4NCg0K SW4gdGhlIElQdjYgVURQIGVuY2Fwc3VsYXRpb24gY2FzZSwgYXMgZm9yIHdoZXRoZXIgb3Igbm90 IGl0IGlzIHN1aXRhYmxlIHRvIHVzZSB0aGUgemVyby1jaGVja3N1bSBub2RlLCB0aGUgcmVxdWly ZW1lbnRzIGRlZmluZWQgaW4gW1JGQzY5MzVdIFtSRkM2OTM2XSBTSE9VTEQgYmUgc3RyaWN0bHkg Zm9sbG93ZWQuIEdlbmVyYWxseSBzcGVha2luZywgdGhlIHVzZSBvZiBhIHplcm8gVURQIGNoZWNr c3VtIGlzIE5PVCBSRUNPTU1FTkRFRC4gTm90ZSB0aGF0IG90aGVyIElQIGVuY2Fwc3VsYXRpb25z IGZvciBNUExTIGRvIG5vdCBoYXZlIGEgY2hlY2tzdW0gaW4gdGhlIHR1bm5lbCBoZWFkZXIuDQoN CkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6 IEN1cnRpcyBWaWxsYW1pemFyIFttYWlsdG86Y3VydGlzQGlwdjYub2NjbmMuY29tXQ0KPiC3osvN yrG85DogMjAxNMTqMdTCMjTI1SAxMTo1Mw0KPiDK1bz+yMs6IGwud29vZEBzdXJyZXkuYWMudWsN Cj4gs63LzTogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBsYXJz QG5ldGFwcC5jb207DQo+IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4g1vfM4jog UmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVu Y2Fwc3VsYXRpbmcgTVBMUw0KPiBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiAN Cj4gSW4gbWVzc2FnZQ0KPiA8MjkwRTIwQjQ1NUM2Njc0M0JFMTc4QzVDODRGMTI0MDg0N0U2MzM0 NkUzQEVYTUIwMUNNUy5zdXJyZXkuYQ0KPiBjLnVrPg0KPiBsLndvb2RAc3VycmV5LmFjLnVrIHdy aXRlczoNCj4gDQo+ID4gdGhlIHRleHQgaXMgbm90IHNhdGlzZmFjdG9yeS4gbmV2ZXIgcmVjb21t ZW5kIHNldHRpbmcgdG8gemVybywgYXMgdGhhdA0KPiA+IHBvc2VzIGEgcmlzayB0byB5b3VyIGFu ZCB0byBvdGhlciB0cmFmZmljLiBTdWdnZXN0ZWQgdGV4dDoNCj4gPiAqKioNCj4gPiBUaGUgVURQ IGNoZWNrc3VtIFNIT1VMRCBiZSB1c2VkIHRvIHByb3RlY3QgdGhlIHBheWxvYWQgYW5kIGVuc3Vy ZQ0KPiA+IGNvcnJlY3QgZGVtdWx0aXBsZXhpbmcgYW5kIGRlbGl2ZXJ5IHRvIHRoZSB0dW5uZWws IGFuZCBub3QgdG8gb3RoZXINCj4gPiBVRFAgZGVzdGluYXRpb25zLCBieSBwcm90ZWN0aW5nIHRo ZSBVRFAgcHNldWRvaGVhZGVyLg0KPiA+IFVzZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzIE5P VCBSRUNPTU1FTkRFRCwgZXZlbiB3aGVuIGRlc2lyZWQgZm9yDQo+ID4gcGVyZm9ybWFuY2Ugb3Ig bmVjZXNzaXRhdGVkIGJ5IGltcGxlbWVudGF0aW9uIHJlYXNvbnMsIGZvciB0aGUgcmVhc29ucw0K PiA+IG91dGxpbmVkIGluIFtSRkM2OTM2XSBzZWN0aW9uIDMuDQo+IA0KPiBJIGFncmVlIHRoYXQg VURQIGNoZWNrc3VtcyBTSE9VTEQgYmUgdXNlZCAoaWU6IFNIT1VMRCBOT1QgYmUgc2V0IHRvIHpl cm8pLg0KPiBUaGVyZSBhcmUgY2FzZXMgd2hlcmUgaXQgaXMgaW1wb3NzaWJsZSBzbyBpdCBjYW4n dCBiZSBNVVNULg0KPiANCj4gPiBVRFAtTGl0ZSBbUkZDMzgyOF0gY2FuIHByb3ZpZGUgYSBkZW11 bHRpcGxleGluZyBjaGVjayBhbmQgTVBMUyBzdGFjaw0KPiA+IGludGVncml0eSBjaGVjayB3aGls ZSBhdm9pZGluZyB0aGUgb3ZlcmhlYWQgb2YgY29tcHV0aW5nIGFuIGludGVncml0eQ0KPiA+IGNo ZWNrIG92ZXIgYSB0dW5uZWxsZWQgZnJhbWUgdGhhdCBoYXMgaXRzIG93biBpbnRlZ3JpdHkgY2hl Y2suDQo+IA0KPiBVRFAtTGlzdCBkb2Vzbid0IHNvbHZlIHRoZSBFQ01QIHByb2JsZW1zIGJlY2F1 c2UgbW9zdCBvZiB0aGUgb2xkZXIgTFNSIHRoYXQNCj4gYXJlIGZvcmNpbmcgdGhlIHVzZSBvZiBN UExTIG92ZXIgVURQIHRvIGdldCBFQ01QIGRvbid0IGxvb2sgYXQgdGhlIHBvcnQNCj4gbnVtYmVy cyBpZiB0aGUgcHJvdG9jb2wgaXMgbm90IDYgb3IgMTcuICBCdXQgdGhpcyBoYXMgb25seSBiZWVu IHNhaWQgdGhyZWUgb3IgZm91cg0KPiB0aW1lcyBzbyBtYXliZSB5b3UgbWlzc2VkIGl0Lg0KPiAN Cj4gPiAqKioNCj4gPg0KPiA+IExsb3lkIFdvb2QNCj4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3 b29kDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZy b206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IDIzIEphbnVhcnkg MjAxNCAxMjozNQ0KPiA+IFRvOiBXb29kIEwgIERyIChFbGVjdHJvbmljIEVuZyk7IEFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0KPiA+IGxhcnNAbmV0YXBwLmNvbQ0KPiA+IENjOiBq b2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4gU3ViamVjdDogcmU6IFttcGxzXSBM YXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiAoRW5jYXBzdWxh dGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPg0KPiA+ID4gLS0tLS3T yrz+1K28/i0tLS0tDQo+ID4gPiC3orz+yMs6IGwud29vZEBzdXJyZXkuYWMudWsgW21haWx0bzps Lndvb2RAc3VycmV5LmFjLnVrXQ0KPiA+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjIzyNUgMTI6NDQN Cj4gPiA+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t OyBsYXJzQG5ldGFwcC5jb20NCj4gPiA+ILOty806IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0 Zi5vcmcNCj4gPiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxz LWluLXVkcC0wNC50eHQ+DQo+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJv cG9zZWQgU3RhbmRhcmQNCj4gPiA+DQo+ID4gPiBTYXNoYQ0KPiA+ID4NCj4gPiA+ID4gLSBVRFAg Y2hlY2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJlY2F1c2UgbmF0aXZl DQo+ID4gPiA+IE1QTFMgZG9lcyBub3QgaGF2ZSBhbnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMs IHRoZXJlIGFyZSBjYXNlcw0KPiA+ID4gPiB3aGVyZSBwYWNrZXRzIGFyZSBjb3JydXB0ZWQgd2l0 aGluIHRoZSByb3V0ZXJzKQ0KPiA+ID4NCj4gPiA+IFNvIHlvdSBhZG1pdCB0aGF0IHBhY2tldHMg Y2FuIGJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMgLSBhDQo+ID4gPiBjaGVjayB0aGF0 IGNhbiBvbmx5IGJlIGNhdWdodCBieSBhbiBlbmQtdG8tZW5kIGNoZWNrLCBhIGNvcnJ1cHRpb24N Cj4gPiA+IHRoYXQgY2FuIGxlYWQgdG8gdGhlIHByb2JsZW1zIGRldGFpbGVkIGluIFJGQyA2OTM2 IHNlY3Rpb24gMyAtIGFuZA0KPiA+ID4gdGhlbiB5b3Ugc2F5IGl0J3MgYSBub24taXNzdWUgYmVj YXVzZSB0aGlzIGRvZXNuJ3QgYWZmZWN0IG5hdGl2ZSBNUExTLiBCdXQNCj4gd2UncmUgbm90IGRv aW5nIG5hdGl2ZSBNUExTIGhlcmUuDQo+ID4gPiBXZSdyZSBkb2luZyBNUExTIG92ZXIgVURQLg0K PiA+ID4NCj4gPiA+IGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0IGlzIGFib3V0IHR1bm5l bGxpbmcgTVBMUyBpbiBVRFAuIEl0J3MgYW4gaXNzdWUuDQo+ID4gPiBQbGVhc2UgcmVhZCB0aGUg b3RoZXIgMTUwIG1lc3NhZ2VzIHRoYXQgeW91IHJlZmVyIHRvLg0KPiA+DQo+ID4gSGkgTGxveWQs DQo+ID4NCj4gPiBUaGUgZHJhZnQgZG9lc24ndCByZXF1aXJlIHRoZSBJUHY2IFVEUCBjaGVja3N1 bSB0byBiZSBzZXQgdG8gemVybyByZWdhcmRsZXNzLg0KPiBTZWUgdGhlIGZvbGxvd2luZyB0ZXh0 IHF1b3RlZCBmcm9tIHRoYXQgZHJhZnQ6DQo+ID4NCj4gPiBVRFAgQ2hlY2tzdW0NCj4gPg0KPiA+ IFRoZSB1c2FnZSBvZiB0aGlzIGZpZWxkIGlzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgY3VycmVu dCBVRFAgc3BlY2lmaWNhdGlvbg0KPiBbUkZDNzY4XS4gVG8gc2ltcGxpZnkgdGhlIG9wZXJhdGlv biBvbiB0aGUgZGVjYXBzdWxhdG9yLCB0aGlzIGZpZWxkIGlzDQo+IFJFQ09NTUVOREVEIHRvIGJl IHNldCB0byB6ZXJvIGluIElQdjQgVURQIGVuY2Fwc3VsYXRpb24gY2FzZS4gSW4gdGhlIElQdjYN Cj4gVURQIGVuY2Fwc3VsYXRpb24gY2FzZSwgaWYgYXBwcm9wcmlhdGUgYWNjb3JkaW5nIHRvIHRo ZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbg0KPiBbUkZDNjkzNV0gW1JGQzY5MzZdLCB0aGlzIGZp ZWxkIGlzIGFsc28gUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8uDQo+IFNwZWNpZmljYWxs eSwgaWYgdGhlIE1QTFMgcGF5bG9hZCBpcyBJbnRlcm5ldCBQcm90b2NvbCAoSVB2NCBvciBJUHY2 KSBwYWNrZXRzLCBpdCBpcw0KPiBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyB3aGVuIHRo ZSBpbm5lciBwYWNrZXQgaW50ZWdyaXR5IGNoZWNrcyBpcw0KPiBhdmFpbGFibGUuIEluIGFkZGl0 aW9uLCBpZiB0aGUgTVBMUyBwYXlsb2FkIGlzIG5vbi1JUCBwYWNrZXQgd2hpY2ggaXMgc3BlY2lm aWNhbGx5DQo+IGRlc2lnbmVkIGZvciB0cmFuc21pc3Npb24gb3ZlciBhIGxvd2VyIGxheWVyIHRo YXQgZG9lcyBub3QgcHJvdmlkZSBhIHBhY2tldA0KPiBpbnRlZ3JpdHkgZ3VhcmFudGVlLCBpdCBp cyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyBhcyB3ZWxsLiBPdGhlcndpc2UsDQo+IHVz aW5nIHplcm8gY2hlY2tzdW0gaXMgTk9UIFJFQ09NTUVOREVELiBOb3RlIHRoYXQgb3RoZXIgSVAg ZW5jYXBzdWxhdGlvbnMNCj4gZm9yIE1QTFMgZG8gbm90IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUg dHVubmVsIGhlYWRlci4NCj4gPg0KPiA+IElmIHlvdSBzdGlsbCBiZWxpZXZlIHRoZSBhYm92ZSB0 ZXh0IGlzIG5vdCBzYXRpc2ZhY3RvcnksIHBsZWFzZSBwcm92aWRlIHlvdXIgdGV4dC4NCj4gPg0K PiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+ID4gTGxveWQgV29vZA0KPiA+ ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRnJvbTogbXBscyBbbXBscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNCj4gPiA+IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0K PiA+ID4gU2VudDogMjMgSmFudWFyeSAyMDE0IDAzOjE2DQo+ID4gPiBUbzogQWxleGFuZGVyIFZh aW5zaHRlaW47IEVnZ2VydCwgTGFycw0KPiA+ID4gQ2M6IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRm Lm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1w bHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQ cm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+IEhpDQo+ID4gPg0KPiA+ID4gPiAtLS0tLdPK vP7Urbz+LS0tLS0NCj4gPiA+ID4gt6K8/sjLOiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPiA+ID4g PiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ID4gPiC3osvN yrG85DogMjAxNMTqMdTCMjLI1SAxOTowNQ0KPiA+ID4gPiDK1bz+yMs6IEVnZ2VydCwgTGFycw0K PiA+ID4gPiCzrcvNOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1DQo+ID4g PiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0w NC50eHQ+DQo+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBT dGFuZGFyZA0KPiA+ID4gPg0KPiA+ID4gPiBMYXJzIGFuZCBhbGwsDQo+ID4gPiA+IExhc3QgdGlt ZSBJJ3ZlIGNvdW50ZWQgdGhlIElFVEYgTEMgdGhyZWFkIG9uIHRoaXMgZHJhZnQgaGFzIG1vcmUN Cj4gPiA+ID4gdGhhbg0KPiA+ID4gPiAxNTAgbWVzc2FnZXMgaW4gaXQsIGFuZCBpdCBzZWVtcyB0 aGF0IG9uIHNvbWUgaXNzdWVzIChjb25nZXN0aW9uDQo+ID4gPiA+IGNvbnRyb2wgYW5kIFVEUA0K PiA+ID4gPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyByb3VuZCB0aGUgbXVsYmVycnkgYnVzaC4N Cj4gPiA+ID4NCj4gPiA+ID4gSU1ITyBhbmQgRldJVzoNCj4gPiA+ID4gLSBVRFAgY2hlY2tzdW1z IChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJlY2F1c2UgbmF0aXZlDQo+ID4gPiA+ IE1QTFMgZG9lcyBub3QgaGF2ZSBhbnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFy ZSBjYXNlcw0KPiA+ID4gPiB3aGVyZSBwYWNrZXRzIGFyZSBjb3JydXB0ZWQgd2l0aGluIHRoZSBy b3V0ZXJzKSwgYnV0IHNvIGZhciBpdCBkaWQNCj4gPiA+ID4gbm90IHByZXZlbnQgTVBMUyBkZXBs b3ltZW50LiBUaGVyZSBpcywgZS5nLiwgUkZDIDQ3MjAgZm9yIEZDUw0KPiA+ID4gPiByZXRlbnRp b24gaW4gUFdzLCBidXQgSSBkb3VidCBpdCBpcyB3aWRlbHkgaW1wbGVtZW50ZWQgYW5kDQo+ID4g PiA+IGRlcGxveWVkICh3b3VsZCBiZSBuaWNlIHRvDQo+ID4gPiBrbm93KS4NCj4gPiA+ID4gLSBF MkUgY29uZ2VzdGlvbiBjb250cm9sIChyZWdhcmRsZXNzIG9mIGl0cyBpbXBsaWNhdGlvbnMpIHNp bXBseQ0KPiA+ID4gPiBjYW5ub3QgYmUgYWRkZWQgdG8gdGhpcyBwcm90b2NvbCB3aXRob3V0IHNv bWUgbWFqb3IgY2hhbmdlcy4gQQ0KPiA+ID4gPiBzaG9ydCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVu dCBleHBsYWluaW5nIHRoYXQgc2hvdWxkIHN1ZmZpY2UgSU1PLg0KPiA+ID4NCj4gPiA+IEhpIFNh c2hhLA0KPiA+ID4NCj4gPiA+IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHBvaW50cy4NCj4gPiA+ DQo+ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiBYaWFvaHUNCj4gPiA+DQo+ID4gPiA+IE15IDJj LA0KPiA+ID4gPiAgICAgICAgU2FzaGENCj4gPiA+ID4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tDQo+ID4gPiA+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4gPiA+ID4NCj4g PiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IG1wbHMg W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFZ2dlcnQsDQo+ID4g PiA+ID4gTGFycw0KPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMiwgMjAxNCAx MjoyMyBQTQ0KPiA+ID4gPiA+IFRvOiBYdXhpYW9odQ0KPiA+ID4gPiA+IENjOiBKb2VsIEphZWdn bGk7IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2Fs bDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiA+IChFbmNhcHN1bGF0 aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gSGksDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPbiAyMDE0LTEtMjIsIGF0IDExOjEyLCBYdXhp YW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4gPiBJIHdvbmRlciB3 aGV0aGVyIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBPSyB0byB5b3U6DQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gU2luY2UgdGhlIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24gY2F1c2VzIE1QTFMg cGFja2V0cyB0byBiZQ0KPiA+ID4gPiA+IGZvcndhcmRlZCB0aHJvdWdoICJVRFAgdHVubmVscyIs IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wNCj4gPiA+ID4gPiBndWlkZWxpbmVzIGZvciBVRFAgdHVu bmVscyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjMgb2YNCj4gPiA+ID4gPiBbUkZDNTQwNV0g U0hPVUxEIGJlDQo+ID4gPiBmb2xsb3dlZC4NCj4gPiA+ID4gPiBTcGVjaWZpY2FsbHksIE1QTFMg Y2FuIGNhcnJ5IGEgbnVtYmVyIG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMgcGF5bG9hZHMuDQo+ ID4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFm ZmljIHRoYXQgaXMNCj4gPiA+ID4gPiBrbm93biBhdCBjb25maWd1cmF0aW9uIHRpbWUgdG8gYmUg SVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUgVURQIHR1 bm5lbCBTSE9VTEQgTk9UIGVtcGxveSBpdHMgb3duDQo+ID4gPiA+ID4gY29uZ2VzdGlvbiBjb250 cm9sIG1lY2hhbmlzbSwgYmVjYXVzZSBjb25nZXN0aW9uIGxvc3NlcyBvZg0KPiA+ID4gPiA+IHR1 bm5lbGVkIHRyYWZmaWMgd2lsbCB0cmlnZ2VyIGFuIGNvbmdlc3Rpb24gcmVzcG9uc2UgYXQgdGhl IG9yaWdpbmFsDQo+IHNlbmRlcnMgb2YgdGhlIHR1bm5lbGVkIHRyYWZmaWMuDQo+ID4gPiA+ID4g V2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFmZmljIHRoYXQg aXMNCj4gPiA+ID4gPiBrbm93biBhdCBjb25maWd1cmF0aW9uIHRpbWUgbm90IHRvIGJlIElQLWJh c2VkIGFuZA0KPiA+ID4gPiA+IGNvbmdlc3Rpb24tY29udHJvbGxlZCwgdGhlIFVEUCB0dW5uZWwg U0hPVUxEIGVtcGxveSBhbg0KPiA+ID4gPiA+IGFwcHJvcHJpYXRlIGNvbmdlc3Rpb24gY29udHJv bCBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluDQo+ID4gPiA+ID4gW1JGQzM5ODVdLiBOb3RlIHRo YXQgaXQgU1RST05HTFkgUkVDT01NRU5ERUQgdG8gZGVwbG95IHN1Y2gNCj4gPiA+ID4gPiBlbmNh cHN1bGF0aW9uIHRlY2hub2xvZ3kgb25seSB3aXRoaW4gYSBTUCBuZXR3b3JrIG9yIG5ldHdvcmtz IG9mDQo+ID4gPiA+ID4gYW4gYWRqYWNlbnQgc2V0IG9mIGNvLW9wZXJhdGluZyBTUHMsIHJhdGhl ciB0aGFuIG92ZXIgdGhlDQo+ID4gPiBJbnRlcm5ldC4NCj4gPiA+ID4gPiBGdXJ0aGVybW9yZSwg cGFja2V0IGZpbHRlcnMgc2hvdWxkIGJlIGFkZGVkIHRvIGJsb2NrIHRyYWZmaWMNCj4gPiA+ID4g PiB3aXRoIHRoZSBVRFAgcG9ydCBudW1iZXIgZm9yIE1QTFMgb3ZlciBVRFAgdG8gcHJldmVudCBN UExTIG92ZXINCj4gPiA+ID4gPiBVRFAgcGFja2V0cyB0byBlc2NhcGUgZnJvbSB0aGUgc2Vydmlj ZSBwcm92aWRlciBuZXR3b3JrcyBkdWUgdG8NCj4gPiA+ID4gPiBtaXNjb25maWd1YXRpb24gb3Ig cGFja2V0DQo+ID4gPiA+IGVycm9ycy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgdGhpbmsgaXQg d291bGQgYmUgYmV0dGVyIHRvIGRlc2NyaWJlIHRoZSBPQU0gY29udHJvbCBsb29wIGluDQo+ID4g PiA+ID4gKHNvbWUpIG1vcmUgZGV0YWlsLCByYXRoZXIgdGhhbiBwb2ludGluZyB0byBSRkMzOTg1 LCB3aGljaA0KPiA+ID4gPiA+IGRvZXNuJ3QgaGF2ZSBhIHdob2xlIGxvdCBvZiBkZXRhaWwgZWl0 aGVyLiBBbHNvIGJlY2F1c2UgdGhlDQo+ID4gPiA+ID4gYWRkaW5nIG9mIGZpcmV3YWxsIHJ1bGVz IHJlcXVpcmVzIGFuIE9BTSBob29rLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gU2luY2UgU1RST05H TFkgUkVDT01NRU5ERUQgaXMgbm90IGFuIFJGQzIxMTkgdGVybSBhbmQNCj4gPiA+ID4gUkVDT01N RU5ERUQgaXMNCj4gPiA+ID4gPiB0b28gd2VhaywgSSdkIHN1Z2dlc3QgdG8gY2hhbmdlIHRoaXMg dG8gTVVTVC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEZpbmFsbHksIHRoZSBhcHBsaWNhYmlsaXR5 IHN0YXRlbWVudCBzaG91bGQgYmUgcHJvbWluZW50bHkgbWFkZQ0KPiA+ID4gPiA+IGluIHRoZSBh YnN0cmFjdCwgaW50cm9kdWN0aW9uLCBldGMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBMYXJzDQo= From curtis@ipv6.occnc.com Thu Jan 23 20:05:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6D31A045D; Thu, 23 Jan 2014 20:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 29x39oZsyOWd; Thu, 23 Jan 2014 20:05:14 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE21A03D6; Thu, 23 Jan 2014 20:05:14 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0O45AEB014301; Thu, 23 Jan 2014 23:05:11 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401240405.s0O45AEB014301@maildrop2.v6ds.occnc.com> To: Alia Atlas From: Curtis Villamizar In-reply-to: Your message of "Thu, 23 Jan 2014 19:07:25 -0500." Date: Thu, 23 Jan 2014 23:05:10 -0500 Cc: "mpls@ietf.org" , IETF discussion list , Noel Chiappa , Joe Touch Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 04:05:17 -0000 +1 Alia - Nice concise summary. Thanks. Curtis In message Alia Atlas writes: > > I don't want to get in the way of vehement discussion, but I thought > we were on the verge of finding an actual solution... > > IMHO, that was a combination of an applicability statement, using > SHOULD for congestion control and checksum, and defining a longer-term > OAM-based approach (as Stewart Bryant suggested) to be able to verify > that packet corruption or excessive drops aren't happening. > > Does that sound like an acceptable set? > > Alia > > > On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch wrote: > > > > > > > On 1/23/2014 3:32 PM, Edward Crabbe wrote: > > > >> Joe, thanks for your response. Comments inline: > >> > >> > >> On 1/23/2014 1:27 PM, Edward Crabbe wrote: > >> > >> Part of the point of using UDP is to make use of lowest common > >> denominator forwarding hardware in introducing entropy to > >> protocols that > >> lack it ( this is particularly true of the GRE in UDP use case > >> also > >> under discussion elsewhere). > >> > >> The tunnel is not the source of the traffic. The _source of the > >> traffic_ is the source of the traffic. > >> > >> > >> To the Internet, the tunnel encapusulator is the source of traffic. > >> Tracing the data back further than that is a mirage at best - and > >> irrelevant. > >> > >> > >> The 'internet' cares about characteristics of reactivity to congestion. > >> This is guaranteed by the /source of the traffic/ independent of any > >> intermediate node. > >> > > > > Are you prepared to make that a requirement of this document, i.e., that > > the only MPLS traffic that can be UDP encapsulated is known to react to > > congestion? > > > > How exactly can you know that? > > > > > > The tunnel head-end is responsible for the tunnel walking, talking, > >> and quaking like a duck (host). When the tunnel head-end knows > >> something about the ultimate origin of the traffic - whether real, > >> imagined, or from Asgard - then it has done it's duty (e.g., that > >> it's already congestion controlled). > >> > >> But that head end is responsible, regardless of what it knows or > >> doesn't. And when it doesn't know, the only way to be responsible is > >> to put in its own reactivity. > >> > >> This is not fact; it's actually precisely the principle we're currently > >> arguing about. ;) > >> > > > > Actually, it's a paraphrasing of Section 3.1.3 of RFC5405. > > > > We can continue to debate it, but until it's been *changed* by a revision, > > it remains BCP. > > > > > > I would posit: > >> > >> The tunnel doesn't have to know anything about congestion or performance > >> characteristics because the originating application must. > >> > > > > That works only if you know that fact about the originating application. > > However, there are plenty of applications whose traffic goes over MPLS that > > isn't congestion reactive or bandwidth-limited. > > > > > > > See GRE, > > > >> MPLS, many other tunnel types, > >> > > > > This isn't an issue for all tunnels until they enter the Internet... > > > > > > including several existing within the > >> IETF that make use of an outer UDP header. > >> > > > > Which are all already supposed to follow the recommendations of RFC5405. > > To the extent that they don't, they don't agree with that BCP. > > > > I'm not saying such things never can or will exist, but I don't think the > > IETF should be self-contradictory. We already agreed as a group on such > > BCPs and other standards, and new standards-track docs need to follow them. > > > > > > The originating application > >> who's traffic is being tunneled should be responsible for > >> congestion > >> control, or lack there of. > >> > >> Perhaps it should be, but that's an agreement between whomever > >> implements/deploys the tunnel headend and whomever provides the > >> originating traffic to them. The problem is that this isn't true for > >> the typical use case for this kind of encapsulation. > >> > >> How so? As mentioned before, this is the same case as standard GRE/MPLS > >> etc. > >> > > > > It's putting MPLS inside UDP. That's a different case, and the reason > > RFC5405 applies. > > > > > > I.e., if we were talking about MPLS traffic that already was > >> reactive, we wouldn't be claiming the need for additional > >> encapsulator mechanism. It's precisely because nothing is known > >> about the MPLS traffic that the encapsulator needs to act. > >> > >> The MPLS traffic doesn't have to be reactive, it's the applications > >> being encapsulated / traversing a particular tunnel that are responsible > >> for and aware of path and congestion charateristics. Because the MPLS > >> head end knows nothing about the /end to end application 'session'/ > >> characteristics it /shouldn't/ have anything to do with congestion > >> management. > >> > > > > OK, so what you're saying is that "traffic using this encapsulation MUST > > be known to be congestion reactive". Put that in the doc and we'll debate > > whether we believe it. > > > > But right now you're basically saying that because you think it's someone > > else's problem (the originating application), it isn't yours. The > > difficulty with that logic is that you (the tunnel headend) is responsible > > to ensure that this is true - either by *knowing* that the originating > > traffic is congestion reactive, or by putting in its own mechanism to > > ensure that this happens if the originating application isn't. > > > > > > > Are we advocating a return to intermediate > >> > >> congestion control (I like X.25 as much as the next guy, > >> but...). This > >> is a very stark change of direction. > >> > >> I think mandating congestion control is not technically sound > >> from > >> either a theoretical (violation of end to end principle, stacking > >> of > >> congestion control algorithms leading to complex and potentially > >> suboptimal results) or economic perspective (as a very large > >> backbone, > >> we've been doing just fine without intermediate congestion > >> management > >> thank you very much, and I have 0 desire to pay for a cost > >> prohibitive, > >> unnecessary feature in silicon.) > >> > >> Write that up, and we'll see how it turns out in the IETF. However, > >> right now, the IETF BCPs do require reactive congestion management > >> of transport streams. > >> > >> Which part? The end-to-end principle, or the aversion to congestion > >> control stacking? These have been implicit in all tunneling protocols > >> produced by the IETF for the modern internet. > >> > > > > Sure, and that's reflected in RFC5405 already. However, please, PLEASE > > appreciate that NOBODY here is asking you to put in "congestion control > > stacking"; that happens when you run two dynamic, reactive control > > algorithms using the same timescale on top of each other. > > > > Equally well-known in CC circles is that you CAN - and often *should* - > > stack different kinds of mechanisms at different layers with different > > timescales. E.g., that's why we have an AQM WG - because even when all the > > traffic is TCP, that's not quite enough inside the network. That's also why > > Lars was suggesting something coarse on a longer timescale - a circuit > > breaker - rather than AIMD on a RTT basis. > > > > Keep in mind as well that the E2E argument says that you can't get an E2E > > service by composing the equivalent HBH one; it also says that HBH > > mechanisms can be required for efficiency. That's what we're talking about > > here - the efficiency impact of congestion, not the overall correctness of > > E2E control. > > > > > > If you don't want/like that, then either don't use transport > >> encapsulation, or change the BCPs. > >> > >> These BCPs are defined for an originating /application/. > >> > > > > Yes, and I don't understand why you (and others) keep thinking it matters > > that there are layers of things behind the tunnel head end. It doesn't - > > unless you KNOW what those layers are, and can ensure that they behave as > > you expect. > > > > > > In this case > >> the UDP header is simply a shim header applied to existing application > >> traffic. > >> > > > > It's not "simply a shim" - if that's the case, use IP and we're done. No > > need for congestion control. > > > > The reason congestion issues arise is because you're inserting a header > > ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO REACT TO****. > > > > If you put in a UDP-like header that nobody in the Internet would > > interpret, this wouldn't be an issue. > > > > But you simply cannot expect the Internet to treat you like "application" > > traffic if you won't enforce acting like that traffic too. > > > > > > The tunnel head does not introduce traffic independent of the > >> originating application. > >> > > > > The Internet ****neither knows nor cares****. > > > > To the Internet, the head-end is the source. Whatever data the head end > > puts inside the UDP packets *is application data* to the rest of the > > Internet. > > > > Again, if you are saying that you know so much about the originating > > source that you know you don't need additional mechanism at the headend, > > say so - but then live by that requirement. > > > > If *any* MPLS traffic could show up at the headend, then it becomes the > > headend's responsibility to do something. > > > > --- > > > > Consider the following case: > > > > - video shows up inside the OS, destined for the network > > > > - software X bundles that video and sends it to go out > > > > - software Y puts that data into UDP packets to go > > to the Internet > > > > So what's the "application" here? To the Internet, it's software Y -- the > > thing that puts the 'application' data into UDP packets. The previous steps > > are irrelevant - just as irrelevant as the singer your video camera is > > filming, as irrelevant as the sun that created the light that is reflected > > off the singer to your camera. > > > > If software Y knows so much about the steps that lead to its input data > > that it knows it's congestion reactive, nothing more need be done. > > > > If NOT (and that's the relevant corollary here), then it becomes software > > Y's responsibility to put in some reactivity. > > > > Joe From curtis@ipv6.occnc.com Thu Jan 23 20:25:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABF61A025A for ; Thu, 23 Jan 2014 20:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RP_MATCHES_RCVD=-0.535, 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 qQ2a--zl5OAH for ; Thu, 23 Jan 2014 20:25:55 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDA01A0250 for ; Thu, 23 Jan 2014 20:25:55 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0O4PjO9014541; Thu, 23 Jan 2014 23:25:45 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401240425.s0O4PjO9014541@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Fri, 24 Jan 2014 00:48:23 +0000." <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk> Date: Thu, 23 Jan 2014 23:25:45 -0500 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 04:25:58 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > RFC6935 was written from a tunnelling perspective, to allow tunnelling > to use zero checksums for performance, and analysed risks to the > tunnel traffic - but not to other users. > > "While the methods do > not guarantee correctness, they can reduce the risks of relaxing the > UDP checksum requirement for a tunnel application using IPv6." > > Risks to other applications are not assessed, and not stated. > > Lloyd Wood > http://about.me/lloydwood Help me out here Lloyd. Previously on this thread Lars was vigorously arguing that we needed to follow years of IETF consensus about UDP checksums. Do you disagree with Lars on that point about following IETF consensus or are you saying there was no IETF consensus in this particular RFC. [ Life if tough for people who try to deal in absolutes. ] In any case, both UDP checksums and congestion control are SHOULD in various document with conflicting SHOULD and SHOULD NOT some cases. We have met the criteria for not going along with SHOULD with a very tight applicability statement establishing a extroidinary circumstance and that the decision and consequences have been thought about. Could we *please* review proposed wording changes (on list). Curtis > ________________________________________ > From: Xuxiaohu [xuxiaohu@huawei.com] > Sent: 24 January 2014 00:34 > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; lars@netapp.com > Cc: joelja@bogus.com; mpls@ietf.org > Subject: ´ð¸´: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > It seems that you are against RFC6935 and RFC6936, right? > > Xiaohu > > > -----ÓʼþÔ­¼þ----- > > ·¢¼þÈË: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ24ÈÕ 1:18 > > ÊÕ¼þÈË: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com > > ³­ËÍ: joelja@bogus.com; mpls@ietf.org > > Ö÷Ìâ: RE: [mpls] Last Call: (Encapsulating MPLS > > in UDP) to Proposed Standard > > > > the text is not satisfactory. never recommend setting to zero, as that poses a risk > > to your and to other traffic. Suggested text: > > *** > > The UDP checksum SHOULD be used to protect the payload and ensure correct > > demultiplexing and delivery to the tunnel, and not to other UDP destinations, by > > protecting the UDP pseudoheader. > > Use of a zero UDP checksum is NOT RECOMMENDED, even when desired for > > performance or necessitated by implementation reasons, for the reasons > > outlined in [RFC6936] section 3. > > > > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS stack > > integrity check while avoiding the overhead of computing an integrity check > > over a tunnelled frame that has its own integrity check. > > *** > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Xuxiaohu [xuxiaohu@huawei.com] > > Sent: 23 January 2014 12:35 > > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; > > lars@netapp.com > > Cc: joelja@bogus.com; mpls@ietf.org > > Subject: re: [mpls] Last Call: (Encapsulating MPLS > > in UDP) to Proposed Standard > > > > > -----ÓʼþÔ­¼þ----- > > > ·¢¼þÈË: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ23ÈÕ 12:44 > > > ÊÕ¼þÈË: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com > > > ³­ËÍ: joelja@bogus.com; mpls@ietf.org > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > Sasha > > > > > > > - UDP checksums (or lack thereof) is a non-issue because native MPLS > > > > does not have anything like that. And yes, there are cases where > > > > packets are corrupted within the routers) > > > > > > So you admit that packets can be corrupted within the routers - a > > > check that can only be caught by an end-to-end check, a corruption > > > that can lead to the problems detailed in RFC 6936 section 3 - and > > > then you say it's a non-issue because this doesn't affect native MPLS. But we're > > not doing native MPLS here. > > > We're doing MPLS over UDP. > > > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's an issue. > > > Please read the other 150 messages that you refer to. > > > > Hi Lloyd, > > > > The draft doesn't require the IPv6 UDP checksum to be set to zero regardless. > > See the following text quoted from that draft: > > > > UDP Checksum > > > > The usage of this field is in accordance with the current UDP specification > > [RFC768]. To simplify the operation on the decapsulator, this field is > > RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In the IPv6 > > UDP encapsulation case, if appropriate according to the requirements defined in > > [RFC6935] [RFC6936], this field is also RECOMMENDED to be set to zero. > > Specifically, if the MPLS payload is Internet Protocol (IPv4 or IPv6) packets, it is > > RECOMMENDED to be set to zero when the inner packet integrity checks is > > available. In addition, if the MPLS payload is non-IP packet which is specifically > > designed for transmission over a lower layer that does not provide a packet > > integrity guarantee, it is RECOMMENDED to be set to zero as well. Otherwise, > > using zero checksum is NOT RECOMMENDED. Note that other IP encapsulations > > for MPLS do not have a checksum in the tunnel header. > > > > If you still believe the above text is not satisfactory, please provide your text. > > > > Best regards, > > Xiaohu > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > [xuxiaohu@huawei.com] > > > Sent: 23 January 2014 03:16 > > > To: Alexander Vainshtein; Eggert, Lars > > > Cc: Joel Jaeggli; mpls@ietf.org > > > Subject: Re: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > Hi > > > > > > > -----ÓʼþÔ­¼þ----- > > > > ·¢¼þÈË: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ22ÈÕ 19:05 > > > > ÊÕ¼þÈË: Eggert, Lars > > > > ³­ËÍ: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Lars and all, > > > > Last time I've counted the IETF LC thread on this draft has more > > > > than > > > > 150 messages in it, and it seems that on some issues (congestion > > > > control and UDP > > > > checksums) we are going round the mulberry bush. > > > > > > > > IMHO and FWIW: > > > > - UDP checksums (or lack thereof) is a non-issue because native MPLS > > > > does not have anything like that. And yes, there are cases where > > > > packets are corrupted within the routers), but so far it did not > > > > prevent MPLS deployment. There is, e.g., RFC 4720 for FCS retention > > > > in PWs, but I doubt it is widely implemented and deployed (would be > > > > nice to > > > know). > > > > - E2E congestion control (regardless of its implications) simply > > > > cannot be added to this protocol without some major changes. A short > > > > applicability statement explaining that should suffice IMO. > > > > > > Hi Sasha, > > > > > > I fully agree with your points. > > > > > > Best regards, > > > Xiaohu > > > > > > > My 2c, > > > > Sasha > > > > Email: Alexander.Vainshtein@ecitele.com > > > > Mobile: 054-9266302 > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, > > > > > Lars > > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > > To: Xuxiaohu > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > Subject: Re: [mpls] Last Call: > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > Hi, > > > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > > > > forwarded through "UDP tunnels", the congestion control guidelines > > > > > for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be > > > followed. > > > > > Specifically, MPLS can carry a number of different protocols as payloads. > > > > > When an UDP tunnel is used for MPLS payload traffic that is known > > > > > at configuration time to be IP-based and congestion-controlled, > > > > > the UDP tunnel SHOULD NOT employ its own congestion control > > > > > mechanism, because congestion losses of tunneled traffic will > > > > > trigger an congestion response at the original senders of the tunneled > > traffic. > > > > > When an UDP tunnel is used for MPLS payload traffic that is known > > > > > at configuration time not to be IP-based and > > > > > congestion-controlled, the UDP tunnel SHOULD employ an appropriate > > > > > congestion control mechanism as described in [RFC3985]. Note that > > > > > it STRONGLY RECOMMENDED to deploy such encapsulation technology > > > > > only within a SP network or networks of an adjacent set of > > > > > co-operating SPs, rather than over the > > > Internet. > > > > > Furthermore, packet filters should be added to block traffic with > > > > > the UDP port number for MPLS over UDP to prevent MPLS over UDP > > > > > packets to escape from the service provider networks due to > > > > > misconfiguation or packet > > > > errors. > > > > > > > > > > I think it would be better to describe the OAM control loop in > > > > > (some) more detail, rather than pointing to RFC3985, which doesn't > > > > > have a whole lot of detail either. Also because the adding of > > > > > firewall rules requires an OAM hook. > > > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > > RECOMMENDED is > > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > > > Finally, the applicability statement should be prominently made in > > > > > the abstract, introduction, etc. > > > > > > > > > > Lars From curtis@ipv6.occnc.com Thu Jan 23 20:35:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8311A0051 for ; Thu, 23 Jan 2014 20:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RP_MATCHES_RCVD=-0.535, 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 vH8sMWjrmUcf for ; Thu, 23 Jan 2014 20:35:02 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 387481A002B for ; Thu, 23 Jan 2014 20:35:02 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0O4YtYE014649; Thu, 23 Jan 2014 23:34:55 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401240434.s0O4YtYE014649@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Fri, 24 Jan 2014 01:26:13 +0000." <290E20B455C66743BE178C5C84F1240847E63346E8@EXMB01CMS.surrey.ac.uk> Date: Thu, 23 Jan 2014 23:34:55 -0500 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 04:35:05 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346E8@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > For the reasons outlined in RFC6936 section 3, which I cited, and for > the danger to other traffic, which we have discussed in this thread. > > I quote RFC3936: > > Currently, for the general Internet, there is no evidence that > corruption is rare, nor is there evidence that corruption in IPv6 is > rare. Therefore, it seems prudent not to relax checks on misdelivery. One of the edits to the document states that the use is only with a single provider network or among cooperating providers. If you like we can add wording indicating that providers SHOULD not use MPLS over UDP unless it is parts of their infrastructure where corruption of packets is known to be rare. I don't know how many times we need to repeat that the applicability is not the general Internet and that this restriction is now part of the document. The above RFC3936 quote is about the general Internet. > Lloyd Wood > http://about.me/lloydwood Curtis > From: Xuxiaohu [xuxiaohu@huawei.com] > Sent: 24 January 2014 01:00 > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; lars@netapp.com > Cc: joelja@bogus.com; mpls@ietf.org > Subject: ´ð¸´: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > We are talking about using UDP as a tunnel for MPLS traffic. So why can't allow the UDP tunnel to use zero checksums for performance, which is the recommendation from RFC6935. > > Xiaohu > > > -----ÓʼþÔ­¼þ----- > > ·¢¼þÈË: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ24ÈÕ 8:48 > > ÊÕ¼þÈË: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com > > ³­ËÍ: joelja@bogus.com; mpls@ietf.org > > Ö÷Ìâ: RE: [mpls] Last Call: (Encapsulating MPLS > > in UDP) to Proposed Standard > > > > RFC6935 was written from a tunnelling perspective, to allow tunnelling to use > > zero checksums for performance, and analysed risks to the tunnel traffic - but > > not to other users. > > > > "While the methods do > > not guarantee correctness, they can reduce the risks of relaxing the > > UDP checksum requirement for a tunnel application using IPv6." > > > > Risks to other applications are not assessed, and not stated. > > > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Xuxiaohu [xuxiaohu@huawei.com] > > Sent: 24 January 2014 00:34 > > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; > > lars@netapp.com > > Cc: joelja@bogus.com; mpls@ietf.org > > Subject: ´ð¸´: [mpls] Last Call: (Encapsulating > > MPLS in UDP) to Proposed Standard > > > > It seems that you are against RFC6935 and RFC6936, right? > > > > Xiaohu > > > > > -----ÓʼþÔ­¼þ----- > > > ·¢¼þÈË: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ24ÈÕ 1:18 > > > ÊÕ¼þÈË: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com > > > ³­ËÍ: joelja@bogus.com; mpls@ietf.org > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > the text is not satisfactory. never recommend setting to zero, as that > > > poses a risk to your and to other traffic. Suggested text: > > > *** > > > The UDP checksum SHOULD be used to protect the payload and ensure > > > correct demultiplexing and delivery to the tunnel, and not to other > > > UDP destinations, by protecting the UDP pseudoheader. > > > Use of a zero UDP checksum is NOT RECOMMENDED, even when desired for > > > performance or necessitated by implementation reasons, for the reasons > > > outlined in [RFC6936] section 3. > > > > > > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS stack > > > integrity check while avoiding the overhead of computing an integrity > > > check over a tunnelled frame that has its own integrity check. > > > *** > > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: Xuxiaohu [xuxiaohu@huawei.com] > > > Sent: 23 January 2014 12:35 > > > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; > > > lars@netapp.com > > > Cc: joelja@bogus.com; mpls@ietf.org > > > Subject: re: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > -----ÓʼþÔ­¼þ----- > > > > ·¢¼þÈË: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ23ÈÕ 12:44 > > > > ÊÕ¼þÈË: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com > > > > ³­ËÍ: joelja@bogus.com; mpls@ietf.org > > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Sasha > > > > > > > > > - UDP checksums (or lack thereof) is a non-issue because native > > > > > MPLS does not have anything like that. And yes, there are cases > > > > > where packets are corrupted within the routers) > > > > > > > > So you admit that packets can be corrupted within the routers - a > > > > check that can only be caught by an end-to-end check, a corruption > > > > that can lead to the problems detailed in RFC 6936 section 3 - and > > > > then you say it's a non-issue because this doesn't affect native > > > > MPLS. But we're > > > not doing native MPLS here. > > > > We're doing MPLS over UDP. > > > > > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's an issue. > > > > Please read the other 150 messages that you refer to. > > > > > > Hi Lloyd, > > > > > > The draft doesn't require the IPv6 UDP checksum to be set to zero regardless. > > > See the following text quoted from that draft: > > > > > > UDP Checksum > > > > > > The usage of this field is in accordance with the current UDP > > > specification [RFC768]. To simplify the operation on the decapsulator, > > > this field is RECOMMENDED to be set to zero in IPv4 UDP encapsulation > > > case. In the IPv6 UDP encapsulation case, if appropriate according to > > > the requirements defined in [RFC6935] [RFC6936], this field is also > > RECOMMENDED to be set to zero. > > > Specifically, if the MPLS payload is Internet Protocol (IPv4 or IPv6) > > > packets, it is RECOMMENDED to be set to zero when the inner packet > > > integrity checks is available. In addition, if the MPLS payload is > > > non-IP packet which is specifically designed for transmission over a > > > lower layer that does not provide a packet integrity guarantee, it is > > > RECOMMENDED to be set to zero as well. Otherwise, using zero checksum > > > is NOT RECOMMENDED. Note that other IP encapsulations for MPLS do not > > have a checksum in the tunnel header. > > > > > > If you still believe the above text is not satisfactory, please provide your text. > > > > > > Best regards, > > > Xiaohu > > > > > > > Lloyd Wood > > > > http://about.me/lloydwood > > > > ________________________________________ > > > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > > [xuxiaohu@huawei.com] > > > > Sent: 23 January 2014 03:16 > > > > To: Alexander Vainshtein; Eggert, Lars > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > Subject: Re: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Hi > > > > > > > > > -----ÓʼþÔ­¼þ----- > > > > > ·¢¼þÈË: Alexander Vainshtein > > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ22ÈÕ 19:05 > > > > > ÊÕ¼þÈË: Eggert, Lars > > > > > ³­ËÍ: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > Lars and all, > > > > > Last time I've counted the IETF LC thread on this draft has more > > > > > than > > > > > 150 messages in it, and it seems that on some issues (congestion > > > > > control and UDP > > > > > checksums) we are going round the mulberry bush. > > > > > > > > > > IMHO and FWIW: > > > > > - UDP checksums (or lack thereof) is a non-issue because native > > > > > MPLS does not have anything like that. And yes, there are cases > > > > > where packets are corrupted within the routers), but so far it did > > > > > not prevent MPLS deployment. There is, e.g., RFC 4720 for FCS > > > > > retention in PWs, but I doubt it is widely implemented and > > > > > deployed (would be nice to > > > > know). > > > > > - E2E congestion control (regardless of its implications) simply > > > > > cannot be added to this protocol without some major changes. A > > > > > short applicability statement explaining that should suffice IMO. > > > > > > > > Hi Sasha, > > > > > > > > I fully agree with your points. > > > > > > > > Best regards, > > > > Xiaohu > > > > > > > > > My 2c, > > > > > Sasha > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > Mobile: 054-9266302 > > > > > > > > > > > -----Original Message----- > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, > > > > > > Lars > > > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > > > To: Xuxiaohu > > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > > Subject: Re: [mpls] Last Call: > > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > > > Hi, > > > > > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > > > > > forwarded through "UDP tunnels", the congestion control > > > > > > guidelines for UDP tunnels as defined in Section 3.1.3 of > > > > > > [RFC5405] SHOULD be > > > > followed. > > > > > > Specifically, MPLS can carry a number of different protocols as payloads. > > > > > > When an UDP tunnel is used for MPLS payload traffic that is > > > > > > known at configuration time to be IP-based and > > > > > > congestion-controlled, the UDP tunnel SHOULD NOT employ its own > > > > > > congestion control mechanism, because congestion losses of > > > > > > tunneled traffic will trigger an congestion response at the > > > > > > original senders of the tunneled > > > traffic. > > > > > > When an UDP tunnel is used for MPLS payload traffic that is > > > > > > known at configuration time not to be IP-based and > > > > > > congestion-controlled, the UDP tunnel SHOULD employ an > > > > > > appropriate congestion control mechanism as described in > > > > > > [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such > > > > > > encapsulation technology only within a SP network or networks of > > > > > > an adjacent set of co-operating SPs, rather than over the > > > > Internet. > > > > > > Furthermore, packet filters should be added to block traffic > > > > > > with the UDP port number for MPLS over UDP to prevent MPLS over > > > > > > UDP packets to escape from the service provider networks due to > > > > > > misconfiguation or packet > > > > > errors. > > > > > > > > > > > > I think it would be better to describe the OAM control loop in > > > > > > (some) more detail, rather than pointing to RFC3985, which > > > > > > doesn't have a whole lot of detail either. Also because the > > > > > > adding of firewall rules requires an OAM hook. > > > > > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > > > RECOMMENDED is > > > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > > > > > Finally, the applicability statement should be prominently made > > > > > > in the abstract, introduction, etc. > > > > > > > > > > > > Lars From l.wood@surrey.ac.uk Thu Jan 23 20:55:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FFC1A00FB for ; Thu, 23 Jan 2014 20:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, 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 akCjjwzkXQZ1 for ; Thu, 23 Jan 2014 20:55:34 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7461A00C3 for ; Thu, 23 Jan 2014 20:55:33 -0800 (PST) Received: from [85.158.136.51:5876] by server-17.bemta-5.messagelabs.com id 0E/77-19152-342F1E25; Fri, 24 Jan 2014 04:55:31 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-10.tower-49.messagelabs.com!1390539330!24805396!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3510 invoked from network); 24 Jan 2014 04:55:30 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-10.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jan 2014 04:55:30 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Fri, 24 Jan 2014 04:55:30 +0000 From: To: Date: Fri, 24 Jan 2014 04:55:29 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8YvGLnlOaNpRf6R0uvXcIT78Xy/gAAiAQB Message-ID: <290E20B455C66743BE178C5C84F1240847E63346EB@EXMB01CMS.surrey.ac.uk> References: Your message of "Fri, 24 Jan 2014 00:48:23 +0000." <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.uk>, <201401240425.s0O4PjO9014541@maildrop2.v6ds.occnc.com> In-Reply-To: <201401240425.s0O4PjO9014541@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 04:55:38 -0000 Lars has primarily vigorously commented on congestion, not checksums. RFC6935 is standards track, for convenience of tunnel implementers. RFC6936 is standards track, filled with indications of the dire things that happen when you follow RFC6935. I'm fine with SHOULD implement checksums. Checksums are RECOMMENDED. Leaving off UDP checksums for tunnel implementation reasons(performance, not seeing whole packets) in private networks is an exception that needs to be explicitly called out. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 24 January 2014 04:25 To: Wood L Dr (Electronic Eng) Cc: xuxiaohu@huawei.com; Alexander.Vainshtein@ecitele.com; lars@netapp.com;= joelja@bogus.com; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard In message <290E20B455C66743BE178C5C84F1240847E63346E7@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > RFC6935 was written from a tunnelling perspective, to allow tunnelling > to use zero checksums for performance, and analysed risks to the > tunnel traffic - but not to other users. > > "While the methods do > not guarantee correctness, they can reduce the risks of relaxing the > UDP checksum requirement for a tunnel application using IPv6." > > Risks to other applications are not assessed, and not stated. > > Lloyd Wood > http://about.me/lloydwood Help me out here Lloyd. Previously on this thread Lars was vigorously arguing that we needed to follow years of IETF consensus about UDP checksums. Do you disagree with Lars on that point about following IETF consensus or are you saying there was no IETF consensus in this particular RFC. [ Life if tough for people who try to deal in absolutes. ] In any case, both UDP checksums and congestion control are SHOULD in various document with conflicting SHOULD and SHOULD NOT some cases. We have met the criteria for not going along with SHOULD with a very tight applicability statement establishing a extroidinary circumstance and that the decision and consequences have been thought about. Could we *please* review proposed wording changes (on list). Curtis > ________________________________________ > From: Xuxiaohu [xuxiaohu@huawei.com] > Sent: 24 January 2014 00:34 > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; lars@n= etapp.com > Cc: joelja@bogus.com; mpls@ietf.org > Subject: =B4=F0=B8=B4: [mpls] Last Call: = (Encapsulating MPLS in UDP) to Proposed Standard > > It seems that you are against RFC6935 and RFC6936, right? > > Xiaohu > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C224=C8=D5 1:18 > > =CA=D5=BC=FE=C8=CB: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@ne= tapp.com > > =B3=AD=CB=CD: joelja@bogus.com; mpls@ietf.org > > =D6=F7=CC=E2: RE: [mpls] Last Call: (En= capsulating MPLS > > in UDP) to Proposed Standard > > > > the text is not satisfactory. never recommend setting to zero, as that = poses a risk > > to your and to other traffic. Suggested text: > > *** > > The UDP checksum SHOULD be used to protect the payload and ensure corre= ct > > demultiplexing and delivery to the tunnel, and not to other UDP destina= tions, by > > protecting the UDP pseudoheader. > > Use of a zero UDP checksum is NOT RECOMMENDED, even when desired for > > performance or necessitated by implementation reasons, for the reasons > > outlined in [RFC6936] section 3. > > > > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS stack > > integrity check while avoiding the overhead of computing an integrity c= heck > > over a tunnelled frame that has its own integrity check. > > *** > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Xuxiaohu [xuxiaohu@huawei.com] > > Sent: 23 January 2014 12:35 > > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; > > lars@netapp.com > > Cc: joelja@bogus.com; mpls@ietf.org > > Subject: re: [mpls] Last Call: (Encapsu= lating MPLS > > in UDP) to Proposed Standard > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C223=C8=D5 12:44 > > > =CA=D5=BC=FE=C8=CB: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@= netapp.com > > > =B3=AD=CB=CD: joelja@bogus.com; mpls@ietf.org > > > =D6=F7=CC=E2: RE: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > Sasha > > > > > > > - UDP checksums (or lack thereof) is a non-issue because native MPL= S > > > > does not have anything like that. And yes, there are cases where > > > > packets are corrupted within the routers) > > > > > > So you admit that packets can be corrupted within the routers - a > > > check that can only be caught by an end-to-end check, a corruption > > > that can lead to the problems detailed in RFC 6936 section 3 - and > > > then you say it's a non-issue because this doesn't affect native MPLS= . But we're > > not doing native MPLS here. > > > We're doing MPLS over UDP. > > > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's a= n issue. > > > Please read the other 150 messages that you refer to. > > > > Hi Lloyd, > > > > The draft doesn't require the IPv6 UDP checksum to be set to zero regar= dless. > > See the following text quoted from that draft: > > > > UDP Checksum > > > > The usage of this field is in accordance with the current UDP specifica= tion > > [RFC768]. To simplify the operation on the decapsulator, this field is > > RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In the IP= v6 > > UDP encapsulation case, if appropriate according to the requirements de= fined in > > [RFC6935] [RFC6936], this field is also RECOMMENDED to be set to zero. > > Specifically, if the MPLS payload is Internet Protocol (IPv4 or IPv6) p= ackets, it is > > RECOMMENDED to be set to zero when the inner packet integrity checks is > > available. In addition, if the MPLS payload is non-IP packet which is s= pecifically > > designed for transmission over a lower layer that does not provide a pa= cket > > integrity guarantee, it is RECOMMENDED to be set to zero as well. Other= wise, > > using zero checksum is NOT RECOMMENDED. Note that other IP encapsulatio= ns > > for MPLS do not have a checksum in the tunnel header. > > > > If you still believe the above text is not satisfactory, please provide= your text. > > > > Best regards, > > Xiaohu > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > [xuxiaohu@huawei.com] > > > Sent: 23 January 2014 03:16 > > > To: Alexander Vainshtein; Eggert, Lars > > > Cc: Joel Jaeggli; mpls@ietf.org > > > Subject: Re: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > Hi > > > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > > =B7=A2=BC=FE=C8=CB: Alexander Vainshtein [mailto:Alexander.Vainshte= in@ecitele.com] > > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C222=C8=D5 19:05 > > > > =CA=D5=BC=FE=C8=CB: Eggert, Lars > > > > =B3=AD=CB=CD: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > > =D6=F7=CC=E2: RE: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Lars and all, > > > > Last time I've counted the IETF LC thread on this draft has more > > > > than > > > > 150 messages in it, and it seems that on some issues (congestion > > > > control and UDP > > > > checksums) we are going round the mulberry bush. > > > > > > > > IMHO and FWIW: > > > > - UDP checksums (or lack thereof) is a non-issue because native MPL= S > > > > does not have anything like that. And yes, there are cases where > > > > packets are corrupted within the routers), but so far it did not > > > > prevent MPLS deployment. There is, e.g., RFC 4720 for FCS retention > > > > in PWs, but I doubt it is widely implemented and deployed (would be > > > > nice to > > > know). > > > > - E2E congestion control (regardless of its implications) simply > > > > cannot be added to this protocol without some major changes. A shor= t > > > > applicability statement explaining that should suffice IMO. > > > > > > Hi Sasha, > > > > > > I fully agree with your points. > > > > > > Best regards, > > > Xiaohu > > > > > > > My 2c, > > > > Sasha > > > > Email: Alexander.Vainshtein@ecitele.com > > > > Mobile: 054-9266302 > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, > > > > > Lars > > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > > To: Xuxiaohu > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > Subject: Re: [mpls] Last Call: > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > Hi, > > > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > > > > forwarded through "UDP tunnels", the congestion control guideline= s > > > > > for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD b= e > > > followed. > > > > > Specifically, MPLS can carry a number of different protocols as p= ayloads. > > > > > When an UDP tunnel is used for MPLS payload traffic that is known > > > > > at configuration time to be IP-based and congestion-controlled, > > > > > the UDP tunnel SHOULD NOT employ its own congestion control > > > > > mechanism, because congestion losses of tunneled traffic will > > > > > trigger an congestion response at the original senders of the tun= neled > > traffic. > > > > > When an UDP tunnel is used for MPLS payload traffic that is known > > > > > at configuration time not to be IP-based and > > > > > congestion-controlled, the UDP tunnel SHOULD employ an appropriat= e > > > > > congestion control mechanism as described in [RFC3985]. Note that > > > > > it STRONGLY RECOMMENDED to deploy such encapsulation technology > > > > > only within a SP network or networks of an adjacent set of > > > > > co-operating SPs, rather than over the > > > Internet. > > > > > Furthermore, packet filters should be added to block traffic with > > > > > the UDP port number for MPLS over UDP to prevent MPLS over UDP > > > > > packets to escape from the service provider networks due to > > > > > misconfiguation or packet > > > > errors. > > > > > > > > > > I think it would be better to describe the OAM control loop in > > > > > (some) more detail, rather than pointing to RFC3985, which doesn'= t > > > > > have a whole lot of detail either. Also because the adding of > > > > > firewall rules requires an OAM hook. > > > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > > RECOMMENDED is > > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > > > Finally, the applicability statement should be prominently made i= n > > > > > the abstract, introduction, etc. > > > > > > > > > > Lars From l.wood@surrey.ac.uk Thu Jan 23 21:00:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41FD1A0179 for ; Thu, 23 Jan 2014 21:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wEUsvvUzxPZZ for ; Thu, 23 Jan 2014 21:00:39 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) by ietfa.amsl.com (Postfix) with ESMTP id DD4DD1A00FB for ; Thu, 23 Jan 2014 21:00:38 -0800 (PST) Received: from [85.158.136.51:13080] by server-16.bemta-5.messagelabs.com id 15/01-11843-573F1E25; Fri, 24 Jan 2014 05:00:37 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-49.messagelabs.com!1390539636!20536105!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4467 invoked from network); 24 Jan 2014 05:00:37 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-14.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jan 2014 05:00:37 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 24 Jan 2014 05:00:36 +0000 From: To: Date: Fri, 24 Jan 2014 04:55:46 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8Yt8Qso3Bou1K+QdK0zzPeUQEy8wACMdXx Message-ID: <290E20B455C66743BE178C5C84F1240847E63346EC@EXMB01CMS.surrey.ac.uk> References: Your message of "Thu, 23 Jan 2014 17:18:22 +0000." <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk>, <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com> In-Reply-To: <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 05:00:42 -0000 > I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to > zero). There are cases where it is impossible so it can't be MUST. Agreed. > UDP-List doesn't solve the ECMP problems because most of the older LSR > that are forcing the use of MPLS over UDP to get ECMP don't look at > the port numbers if the protocol is not 6 or 17. But this has only > been said three or four times so maybe you missed it. I believe you mean Lite, not List. UDP-Lite is standards track, and solves the performance concern while providing the demux check that IPv4 needs and v6 needs even more. It's worth mentioning for that reason; it is well-suited to this problem. (There's a lot of older MPLS hardware out there that only does=20 IPv4. Why is the draft mentioning v6? Or perhaps we shouldn't be completely constrained by the field?) Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 24 January 2014 03:52 To: Wood L Dr (Electronic Eng) Cc: xuxiaohu@huawei.com; Alexander.Vainshtein@ecitele.com; lars@netapp.com;= joelja@bogus.com; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard In message <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > the text is not satisfactory. never recommend setting to zero, > as that poses a risk to your and to other traffic. Suggested text: > *** > The UDP checksum SHOULD be used to protect the payload and > ensure correct demultiplexing and delivery to the tunnel, and not to > other UDP destinations, by protecting the UDP pseudoheader. > Use of a zero UDP checksum is NOT RECOMMENDED, even when > desired for performance or necessitated by implementation > reasons, for the reasons outlined in [RFC6936] section 3. I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to zero). There are cases where it is impossible so it can't be MUST. > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS > stack integrity check while avoiding the overhead of computing an > integrity check over a tunnelled frame that has its own integrity check. UDP-List doesn't solve the ECMP problems because most of the older LSR that are forcing the use of MPLS over UDP to get ECMP don't look at the port numbers if the protocol is not 6 or 17. But this has only been said three or four times so maybe you missed it. > *** > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Xuxiaohu [xuxiaohu@huawei.com] > Sent: 23 January 2014 12:35 > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; lars@n= etapp.com > Cc: joelja@bogus.com; mpls@ietf.org > Subject: re: [mpls] Last Call: (Encapsula= ting MPLS in UDP) to Proposed Standard > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C223=C8=D5 12:44 > > =CA=D5=BC=FE=C8=CB: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@ne= tapp.com > > =B3=AD=CB=CD: joelja@bogus.com; mpls@ietf.org > > =D6=F7=CC=E2: RE: [mpls] Last Call: (En= capsulating MPLS > > in UDP) to Proposed Standard > > > > Sasha > > > > > - UDP checksums (or lack thereof) is a non-issue because native MPLS > > > does not have anything like that. And yes, there are cases where > > > packets are corrupted within the routers) > > > > So you admit that packets can be corrupted within the routers - a check= that can > > only be caught by an end-to-end check, a corruption that can lead to th= e > > problems detailed in RFC 6936 section 3 - and then you say it's a non-i= ssue > > because this doesn't affect native MPLS. But we're not doing native MPL= S here. > > We're doing MPLS over UDP. > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's an = issue. > > Please read the other 150 messages that you refer to. > > Hi Lloyd, > > The draft doesn't require the IPv6 UDP checksum to be set to zero regardl= ess. See the following text quoted from that draft: > > UDP Checksum > > The usage of this field is in accordance with the current UDP specificati= on [RFC768]. To simplify the operation on the decapsulator, this field is R= ECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In the IPv6 UD= P encapsulation case, if appropriate according to the requirements defined = in [RFC6935] [RFC6936], this field is also RECOMMENDED to be set to zero. S= pecifically, if the MPLS payload is Internet Protocol (IPv4 or IPv6) packet= s, it is RECOMMENDED to be set to zero when the inner packet integrity chec= ks is available. In addition, if the MPLS payload is non-IP packet which is= specifically designed for transmission over a lower layer that does not pr= ovide a packet integrity guarantee, it is RECOMMENDED to be set to zero as = well. Otherwise, using zero checksum is NOT RECOMMENDED. Note that other IP= encapsulations for MPLS do not have a checksum in the tunnel header. > > If you still believe the above text is not satisfactory, please provide y= our text. > > Best regards, > Xiaohu > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > [xuxiaohu@huawei.com] > > Sent: 23 January 2014 03:16 > > To: Alexander Vainshtein; Eggert, Lars > > Cc: Joel Jaeggli; mpls@ietf.org > > Subject: Re: [mpls] Last Call: (Encapsu= lating > > MPLS in UDP) to Proposed Standard > > > > Hi > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: Alexander Vainshtein [mailto:Alexander.Vainshtein= @ecitele.com] > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C222=C8=D5 19:05 > > > =CA=D5=BC=FE=C8=CB: Eggert, Lars > > > =B3=AD=CB=CD: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > =D6=F7=CC=E2: RE: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > Lars and all, > > > Last time I've counted the IETF LC thread on this draft has more than > > > 150 messages in it, and it seems that on some issues (congestion > > > control and UDP > > > checksums) we are going round the mulberry bush. > > > > > > IMHO and FWIW: > > > - UDP checksums (or lack thereof) is a non-issue because native MPLS > > > does not have anything like that. And yes, there are cases where > > > packets are corrupted within the routers), but so far it did not > > > prevent MPLS deployment. There is, e.g., RFC 4720 for FCS retention i= n > > > PWs, but I doubt it is widely implemented and deployed (would be nice= to > > know). > > > - E2E congestion control (regardless of its implications) simply > > > cannot be added to this protocol without some major changes. A short > > > applicability statement explaining that should suffice IMO. > > > > Hi Sasha, > > > > I fully agree with your points. > > > > Best regards, > > Xiaohu > > > > > My 2c, > > > Sasha > > > Email: Alexander.Vainshtein@ecitele.com > > > Mobile: 054-9266302 > > > > > > > -----Original Message----- > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > To: Xuxiaohu > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > Subject: Re: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Hi, > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > > > forwarded through "UDP tunnels", the congestion control guidelines > > > > for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be > > followed. > > > > Specifically, MPLS can carry a number of different protocols as pay= loads. > > > > When an UDP tunnel is used for MPLS payload traffic that is known a= t > > > > configuration time to be IP-based and congestion-controlled, the UD= P > > > > tunnel SHOULD NOT employ its own congestion control mechanism, > > > > because congestion losses of tunneled traffic will trigger an > > > > congestion response at the original senders of the tunneled traffic= . > > > > When an UDP tunnel is used for MPLS payload traffic that is known a= t > > > > configuration time not to be IP-based and congestion-controlled, th= e > > > > UDP tunnel SHOULD employ an appropriate congestion control mechanis= m > > > > as described in [RFC3985]. Note that it STRONGLY RECOMMENDED to > > > > deploy such encapsulation technology only within a SP network or > > > > networks of an adjacent set of co-operating SPs, rather than over t= he > > Internet. > > > > Furthermore, packet filters should be added to block traffic with > > > > the UDP port number for MPLS over UDP to prevent MPLS over UDP > > > > packets to escape from the service provider networks due to > > > > misconfiguation or packet > > > errors. > > > > > > > > I think it would be better to describe the OAM control loop in > > > > (some) more detail, rather than pointing to RFC3985, which doesn't > > > > have a whole lot of detail either. Also because the adding of > > > > firewall rules requires an OAM hook. > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > RECOMMENDED is > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > Finally, the applicability statement should be prominently made in > > > > the abstract, introduction, etc. > > > > > > > > Lars From l.wood@surrey.ac.uk Thu Jan 23 21:04:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074201A0179 for ; Thu, 23 Jan 2014 21:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, 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 kfeyBlgNJ7jA for ; Thu, 23 Jan 2014 21:04:39 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.110]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8721A00A1 for ; Thu, 23 Jan 2014 21:04:38 -0800 (PST) Received: from [193.109.255.147:18253] by server-6.bemta-14.messagelabs.com id D2/11-14958-364F1E25; Fri, 24 Jan 2014 05:04:35 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-6.tower-72.messagelabs.com!1390539875!13439156!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8589 invoked from network); 24 Jan 2014 05:04:35 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-6.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jan 2014 05:04:35 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 24 Jan 2014 05:04:34 +0000 From: To: , Date: Fri, 24 Jan 2014 05:00:54 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGLe0Vpx4VpP9lE+4fynfG27EApqTPtnwgAASPbc= Message-ID: <290E20B455C66743BE178C5C84F1240847E63346ED@EXMB01CMS.surrey.ac.uk> References: Your message of "Thu, 23 Jan 2014 17:18:22 +0000." <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247954@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247954@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 05:04:43 -0000 SSB3b3VsZCBiZSBnb29kIHdpdGg6DQoNCiJHZW5lcmFsbHkgc3BlYWtpbmcsIGEgVURQIGNoZWNr c3VtIFNIT1VMRCBiZSB1c2VkLiBUaGUgY29uc2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluIFtSRkM2 OTM1XSBbUkZDNjkzNl0gU0hPVUxEIGJlIGV4YW1pbmVkIGlmIFVEUCBjaGVja3N1bXMgbmVlZCB0 byBiZSBkaXNhYmxlZCBmb3IgcGVyZm9ybWFuY2Ugb3IgaW1wbGVtZW50YXRpb24gcmVhc29ucyBm b3IgdHJhZmZpYyBhY3Jvc3MgcHJpdmF0ZSBuZXR3b3Jrcy4gVGhlIHVzZSBvZiBhIHplcm8gVURQ IGNoZWNrc3VtIGlzIE5PVCBSRUNPTU1FTkRFRC4iDQoNCkkgd291bGRuJ3QgbWFrZSB0aGlzIElQ djYgc3BlY2lmaWMgLSBJUHY0IHN0aWxsIGhhcyBwcm9ibGVtcyAoVURQIHBvcnQgZGVtdXgpLCBJ UHY2J3MgcHJvYmxlbXMgYXJlIGp1c3Qgd29yc2UuDQoNCkxsb3lkIFdvb2QNCmh0dHA6Ly9hYm91 dC5tZS9sbG95ZHdvb2QNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KU2VudDogMjQgSmFudWFyeSAy MDE0IDA0OjAwDQpUbzogY3VydGlzQGlwdjYub2NjbmMuY29tOyBXb29kIEwgIERyIChFbGVjdHJv bmljIEVuZykNCkNjOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRh cHAuY29tOyBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiByZTogW21w bHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxh dGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KSGksDQoNClBsZWFzZSBj aGVjayB3aGV0aGVyIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBPSy4NCg0KSW4gdGhlIElQdjYgVURQ IGVuY2Fwc3VsYXRpb24gY2FzZSwgYXMgZm9yIHdoZXRoZXIgb3Igbm90IGl0IGlzIHN1aXRhYmxl IHRvIHVzZSB0aGUgemVyby1jaGVja3N1bSBub2RlLCB0aGUgcmVxdWlyZW1lbnRzIGRlZmluZWQg aW4gW1JGQzY5MzVdIFtSRkM2OTM2XSBTSE9VTEQgYmUgc3RyaWN0bHkgZm9sbG93ZWQuIEdlbmVy YWxseSBzcGVha2luZywgdGhlIHVzZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzIE5PVCBSRUNP TU1FTkRFRC4gTm90ZSB0aGF0IG90aGVyIElQIGVuY2Fwc3VsYXRpb25zIGZvciBNUExTIGRvIG5v dCBoYXZlIGEgY2hlY2tzdW0gaW4gdGhlIHR1bm5lbCBoZWFkZXIuDQoNCkJlc3QgcmVnYXJkcywN ClhpYW9odQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IEN1cnRpcyBWaWxsYW1p emFyIFttYWlsdG86Y3VydGlzQGlwdjYub2NjbmMuY29tXQ0KPiC3osvNyrG85DogMjAxNMTqMdTC MjTI1SAxMTo1Mw0KPiDK1bz+yMs6IGwud29vZEBzdXJyZXkuYWMudWsNCj4gs63LzTogWHV4aWFv aHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5ldGFwcC5jb207DQo+ IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFttcGxzXSBMYXN0 IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBM Uw0KPiBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+DQo+DQo+IEluIG1lc3NhZ2UNCj4g PDI5MEUyMEI0NTVDNjY3NDNCRTE3OEM1Qzg0RjEyNDA4NDdFNjMzNDZFM0BFWE1CMDFDTVMuc3Vy cmV5LmENCj4gYy51az4NCj4gbC53b29kQHN1cnJleS5hYy51ayB3cml0ZXM6DQo+DQo+ID4gdGhl IHRleHQgaXMgbm90IHNhdGlzZmFjdG9yeS4gbmV2ZXIgcmVjb21tZW5kIHNldHRpbmcgdG8gemVy bywgYXMgdGhhdA0KPiA+IHBvc2VzIGEgcmlzayB0byB5b3VyIGFuZCB0byBvdGhlciB0cmFmZmlj LiBTdWdnZXN0ZWQgdGV4dDoNCj4gPiAqKioNCj4gPiBUaGUgVURQIGNoZWNrc3VtIFNIT1VMRCBi ZSB1c2VkIHRvIHByb3RlY3QgdGhlIHBheWxvYWQgYW5kIGVuc3VyZQ0KPiA+IGNvcnJlY3QgZGVt dWx0aXBsZXhpbmcgYW5kIGRlbGl2ZXJ5IHRvIHRoZSB0dW5uZWwsIGFuZCBub3QgdG8gb3RoZXIN Cj4gPiBVRFAgZGVzdGluYXRpb25zLCBieSBwcm90ZWN0aW5nIHRoZSBVRFAgcHNldWRvaGVhZGVy Lg0KPiA+IFVzZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzIE5PVCBSRUNPTU1FTkRFRCwgZXZl biB3aGVuIGRlc2lyZWQgZm9yDQo+ID4gcGVyZm9ybWFuY2Ugb3IgbmVjZXNzaXRhdGVkIGJ5IGlt cGxlbWVudGF0aW9uIHJlYXNvbnMsIGZvciB0aGUgcmVhc29ucw0KPiA+IG91dGxpbmVkIGluIFtS RkM2OTM2XSBzZWN0aW9uIDMuDQo+DQo+IEkgYWdyZWUgdGhhdCBVRFAgY2hlY2tzdW1zIFNIT1VM RCBiZSB1c2VkIChpZTogU0hPVUxEIE5PVCBiZSBzZXQgdG8gemVybykuDQo+IFRoZXJlIGFyZSBj YXNlcyB3aGVyZSBpdCBpcyBpbXBvc3NpYmxlIHNvIGl0IGNhbid0IGJlIE1VU1QuDQo+DQo+ID4g VURQLUxpdGUgW1JGQzM4MjhdIGNhbiBwcm92aWRlIGEgZGVtdWx0aXBsZXhpbmcgY2hlY2sgYW5k IE1QTFMgc3RhY2sNCj4gPiBpbnRlZ3JpdHkgY2hlY2sgd2hpbGUgYXZvaWRpbmcgdGhlIG92ZXJo ZWFkIG9mIGNvbXB1dGluZyBhbiBpbnRlZ3JpdHkNCj4gPiBjaGVjayBvdmVyIGEgdHVubmVsbGVk IGZyYW1lIHRoYXQgaGFzIGl0cyBvd24gaW50ZWdyaXR5IGNoZWNrLg0KPg0KPiBVRFAtTGlzdCBk b2Vzbid0IHNvbHZlIHRoZSBFQ01QIHByb2JsZW1zIGJlY2F1c2UgbW9zdCBvZiB0aGUgb2xkZXIg TFNSIHRoYXQNCj4gYXJlIGZvcmNpbmcgdGhlIHVzZSBvZiBNUExTIG92ZXIgVURQIHRvIGdldCBF Q01QIGRvbid0IGxvb2sgYXQgdGhlIHBvcnQNCj4gbnVtYmVycyBpZiB0aGUgcHJvdG9jb2wgaXMg bm90IDYgb3IgMTcuICBCdXQgdGhpcyBoYXMgb25seSBiZWVuIHNhaWQgdGhyZWUgb3IgZm91cg0K PiB0aW1lcyBzbyBtYXliZSB5b3UgbWlzc2VkIGl0Lg0KPg0KPiA+ICoqKg0KPiA+DQo+ID4gTGxv eWQgV29vZA0KPiA+IGh0dHA6Ly9hYm91dC5tZS9sbG95ZHdvb2QNCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1 QGh1YXdlaS5jb21dDQo+ID4gU2VudDogMjMgSmFudWFyeSAyMDE0IDEyOjM1DQo+ID4gVG86IFdv b2QgTCAgRHIgKEVsZWN0cm9uaWMgRW5nKTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b207DQo+ID4gbGFyc0BuZXRhcHAuY29tDQo+ID4gQ2M6IGpvZWxqYUBib2d1cy5jb207IG1wbHNA aWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiByZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYt bXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQ cm9wb3NlZCBTdGFuZGFyZA0KPiA+DQo+ID4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ILei vP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ ID4gPiC3osvNyrG85DogMjAxNMTqMdTCMjPI1SAxMjo0NA0KPiA+ID4gytW8/sjLOiBYdXhpYW9o dTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBwLmNvbQ0KPiA+ ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4g1vfM4jogUkU6 IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4N Cj4gPiA+IFNhc2hhDQo+ID4gPg0KPiA+ID4gPiAtIFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhl cmVvZikgaXMgYSBub24taXNzdWUgYmVjYXVzZSBuYXRpdmUNCj4gPiA+ID4gTVBMUyBkb2VzIG5v dCBoYXZlIGFueXRoaW5nIGxpa2UgdGhhdC4gQW5kIHllcywgdGhlcmUgYXJlIGNhc2VzDQo+ID4g PiA+IHdoZXJlIHBhY2tldHMgYXJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMpDQo+ID4g Pg0KPiA+ID4gU28geW91IGFkbWl0IHRoYXQgcGFja2V0cyBjYW4gYmUgY29ycnVwdGVkIHdpdGhp biB0aGUgcm91dGVycyAtIGENCj4gPiA+IGNoZWNrIHRoYXQgY2FuIG9ubHkgYmUgY2F1Z2h0IGJ5 IGFuIGVuZC10by1lbmQgY2hlY2ssIGEgY29ycnVwdGlvbg0KPiA+ID4gdGhhdCBjYW4gbGVhZCB0 byB0aGUgcHJvYmxlbXMgZGV0YWlsZWQgaW4gUkZDIDY5MzYgc2VjdGlvbiAzIC0gYW5kDQo+ID4g PiB0aGVuIHlvdSBzYXkgaXQncyBhIG5vbi1pc3N1ZSBiZWNhdXNlIHRoaXMgZG9lc24ndCBhZmZl Y3QgbmF0aXZlIE1QTFMuIEJ1dA0KPiB3ZSdyZSBub3QgZG9pbmcgbmF0aXZlIE1QTFMgaGVyZS4N Cj4gPiA+IFdlJ3JlIGRvaW5nIE1QTFMgb3ZlciBVRFAuDQo+ID4gPg0KPiA+ID4gZHJhZnQtaWV0 Zi1tcGxzLWluLXVkcC0wNC50eHQgaXMgYWJvdXQgdHVubmVsbGluZyBNUExTIGluIFVEUC4gSXQn cyBhbiBpc3N1ZS4NCj4gPiA+IFBsZWFzZSByZWFkIHRoZSBvdGhlciAxNTAgbWVzc2FnZXMgdGhh dCB5b3UgcmVmZXIgdG8uDQo+ID4NCj4gPiBIaSBMbG95ZCwNCj4gPg0KPiA+IFRoZSBkcmFmdCBk b2Vzbid0IHJlcXVpcmUgdGhlIElQdjYgVURQIGNoZWNrc3VtIHRvIGJlIHNldCB0byB6ZXJvIHJl Z2FyZGxlc3MuDQo+IFNlZSB0aGUgZm9sbG93aW5nIHRleHQgcXVvdGVkIGZyb20gdGhhdCBkcmFm dDoNCj4gPg0KPiA+IFVEUCBDaGVja3N1bQ0KPiA+DQo+ID4gVGhlIHVzYWdlIG9mIHRoaXMgZmll bGQgaXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBjdXJyZW50IFVEUCBzcGVjaWZpY2F0aW9uDQo+ IFtSRkM3NjhdLiBUbyBzaW1wbGlmeSB0aGUgb3BlcmF0aW9uIG9uIHRoZSBkZWNhcHN1bGF0b3Is IHRoaXMgZmllbGQgaXMNCj4gUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gaW4gSVB2NCBV RFAgZW5jYXBzdWxhdGlvbiBjYXNlLiBJbiB0aGUgSVB2Ng0KPiBVRFAgZW5jYXBzdWxhdGlvbiBj YXNlLCBpZiBhcHByb3ByaWF0ZSBhY2NvcmRpbmcgdG8gdGhlIHJlcXVpcmVtZW50cyBkZWZpbmVk IGluDQo+IFtSRkM2OTM1XSBbUkZDNjkzNl0sIHRoaXMgZmllbGQgaXMgYWxzbyBSRUNPTU1FTkRF RCB0byBiZSBzZXQgdG8gemVyby4NCj4gU3BlY2lmaWNhbGx5LCBpZiB0aGUgTVBMUyBwYXlsb2Fk IGlzIEludGVybmV0IFByb3RvY29sIChJUHY0IG9yIElQdjYpIHBhY2tldHMsIGl0IGlzDQo+IFJF Q09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIHdoZW4gdGhlIGlubmVyIHBhY2tldCBpbnRlZ3Jp dHkgY2hlY2tzIGlzDQo+IGF2YWlsYWJsZS4gSW4gYWRkaXRpb24sIGlmIHRoZSBNUExTIHBheWxv YWQgaXMgbm9uLUlQIHBhY2tldCB3aGljaCBpcyBzcGVjaWZpY2FsbHkNCj4gZGVzaWduZWQgZm9y IHRyYW5zbWlzc2lvbiBvdmVyIGEgbG93ZXIgbGF5ZXIgdGhhdCBkb2VzIG5vdCBwcm92aWRlIGEg cGFja2V0DQo+IGludGVncml0eSBndWFyYW50ZWUsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGJlIHNl dCB0byB6ZXJvIGFzIHdlbGwuIE90aGVyd2lzZSwNCj4gdXNpbmcgemVybyBjaGVja3N1bSBpcyBO T1QgUkVDT01NRU5ERUQuIE5vdGUgdGhhdCBvdGhlciBJUCBlbmNhcHN1bGF0aW9ucw0KPiBmb3Ig TVBMUyBkbyBub3QgaGF2ZSBhIGNoZWNrc3VtIGluIHRoZSB0dW5uZWwgaGVhZGVyLg0KPiA+DQo+ ID4gSWYgeW91IHN0aWxsIGJlbGlldmUgdGhlIGFib3ZlIHRleHQgaXMgbm90IHNhdGlzZmFjdG9y eSwgcGxlYXNlIHByb3ZpZGUgeW91ciB0ZXh0Lg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+ IFhpYW9odQ0KPiA+DQo+ID4gPiBMbG95ZCBXb29kDQo+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxv eWR3b29kDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiBGcm9tOiBtcGxzIFttcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBYdXhp YW9odQ0KPiA+ID4gW3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiBTZW50OiAyMyBKYW51YXJ5 IDIwMTQgMDM6MTYNCj4gPiA+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgRWdnZXJ0LCBMYXJz DQo+ID4gPiBDYzogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBS ZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4g Pg0KPiA+ID4gSGkNCj4gPiA+DQo+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ID4gPiC3 orz+yMs6IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+ID4gPiA+IFttYWlsdG86QWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb21dDQo+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyMsjVIDE5 OjA1DQo+ID4gPiA+IMrVvP7IyzogRWdnZXJ0LCBMYXJzDQo+ID4gPiA+ILOty806IEpvZWwgSmFl Z2dsaTsgbXBsc0BpZXRmLm9yZzsgWHV4aWFvaHUNCj4gPiA+ID4g1vfM4jogUkU6IFttcGxzXSBM YXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gKEVuY2Fw c3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPiA+DQo+ID4g PiA+IExhcnMgYW5kIGFsbCwNCj4gPiA+ID4gTGFzdCB0aW1lIEkndmUgY291bnRlZCB0aGUgSUVU RiBMQyB0aHJlYWQgb24gdGhpcyBkcmFmdCBoYXMgbW9yZQ0KPiA+ID4gPiB0aGFuDQo+ID4gPiA+ IDE1MCBtZXNzYWdlcyBpbiBpdCwgYW5kIGl0IHNlZW1zIHRoYXQgb24gc29tZSBpc3N1ZXMgKGNv bmdlc3Rpb24NCj4gPiA+ID4gY29udHJvbCBhbmQgVURQDQo+ID4gPiA+IGNoZWNrc3Vtcykgd2Ug YXJlIGdvaW5nIHJvdW5kIHRoZSBtdWxiZXJyeSBidXNoLg0KPiA+ID4gPg0KPiA+ID4gPiBJTUhP IGFuZCBGV0lXOg0KPiA+ID4gPiAtIFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhlcmVvZikgaXMg YSBub24taXNzdWUgYmVjYXVzZSBuYXRpdmUNCj4gPiA+ID4gTVBMUyBkb2VzIG5vdCBoYXZlIGFu eXRoaW5nIGxpa2UgdGhhdC4gQW5kIHllcywgdGhlcmUgYXJlIGNhc2VzDQo+ID4gPiA+IHdoZXJl IHBhY2tldHMgYXJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMpLCBidXQgc28gZmFyIGl0 IGRpZA0KPiA+ID4gPiBub3QgcHJldmVudCBNUExTIGRlcGxveW1lbnQuIFRoZXJlIGlzLCBlLmcu LCBSRkMgNDcyMCBmb3IgRkNTDQo+ID4gPiA+IHJldGVudGlvbiBpbiBQV3MsIGJ1dCBJIGRvdWJ0 IGl0IGlzIHdpZGVseSBpbXBsZW1lbnRlZCBhbmQNCj4gPiA+ID4gZGVwbG95ZWQgKHdvdWxkIGJl IG5pY2UgdG8NCj4gPiA+IGtub3cpLg0KPiA+ID4gPiAtIEUyRSBjb25nZXN0aW9uIGNvbnRyb2wg KHJlZ2FyZGxlc3Mgb2YgaXRzIGltcGxpY2F0aW9ucykgc2ltcGx5DQo+ID4gPiA+IGNhbm5vdCBi ZSBhZGRlZCB0byB0aGlzIHByb3RvY29sIHdpdGhvdXQgc29tZSBtYWpvciBjaGFuZ2VzLiBBDQo+ ID4gPiA+IHNob3J0IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGV4cGxhaW5pbmcgdGhhdCBzaG91 bGQgc3VmZmljZSBJTU8uDQo+ID4gPg0KPiA+ID4gSGkgU2FzaGEsDQo+ID4gPg0KPiA+ID4gSSBm dWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnRzLg0KPiA+ID4NCj4gPiA+IEJlc3QgcmVnYXJkcywN Cj4gPiA+IFhpYW9odQ0KPiA+ID4NCj4gPiA+ID4gTXkgMmMsDQo+ID4gPiA+ICAgICAgICBTYXNo YQ0KPiA+ID4gPiBFbWFpbDogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gPiA+ ID4gTW9iaWxlOiAwNTQtOTI2NjMwMg0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVnZ2VydCwNCj4gPiA+ID4gPiBMYXJzDQo+ID4gPiA+ID4g U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIyLCAyMDE0IDEyOjIzIFBNDQo+ID4gPiA+ID4gVG86 IFh1eGlhb2h1DQo+ID4gPiA+ID4gQ2M6IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+ ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWlu LXVkcC0wNC50eHQ+DQo+ID4gPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFBy b3Bvc2VkIFN0YW5kYXJkDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBIaSwNCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IE9uIDIwMTQtMS0yMiwgYXQgMTE6MTIsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWku Y29tPiB3cm90ZToNCj4gPiA+ID4gPiA+IEkgd29uZGVyIHdoZXRoZXIgdGhlIGZvbGxvd2luZyB0 ZXh0IGlzIE9LIHRvIHlvdToNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTaW5jZSB0aGUgTVBM Uy1pbi1VRFAgZW5jYXBzdWxhdGlvbiBjYXVzZXMgTVBMUyBwYWNrZXRzIHRvIGJlDQo+ID4gPiA+ ID4gZm9yd2FyZGVkIHRocm91Z2ggIlVEUCB0dW5uZWxzIiwgdGhlIGNvbmdlc3Rpb24gY29udHJv bA0KPiA+ID4gPiA+IGd1aWRlbGluZXMgZm9yIFVEUCB0dW5uZWxzIGFzIGRlZmluZWQgaW4gU2Vj dGlvbiAzLjEuMyBvZg0KPiA+ID4gPiA+IFtSRkM1NDA1XSBTSE9VTEQgYmUNCj4gPiA+IGZvbGxv d2VkLg0KPiA+ID4gPiA+IFNwZWNpZmljYWxseSwgTVBMUyBjYW4gY2FycnkgYSBudW1iZXIgb2Yg ZGlmZmVyZW50IHByb3RvY29scyBhcyBwYXlsb2Fkcy4NCj4gPiA+ID4gPiBXaGVuIGFuIFVEUCB0 dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcw0KPiA+ID4gPiA+ IGtub3duIGF0IGNvbmZpZ3VyYXRpb24gdGltZSB0byBiZSBJUC1iYXNlZCBhbmQNCj4gPiA+ID4g PiBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFAgdHVubmVsIFNIT1VMRCBOT1QgZW1wbG95 IGl0cyBvd24NCj4gPiA+ID4gPiBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLCBiZWNhdXNl IGNvbmdlc3Rpb24gbG9zc2VzIG9mDQo+ID4gPiA+ID4gdHVubmVsZWQgdHJhZmZpYyB3aWxsIHRy aWdnZXIgYW4gY29uZ2VzdGlvbiByZXNwb25zZSBhdCB0aGUgb3JpZ2luYWwNCj4gc2VuZGVycyBv ZiB0aGUgdHVubmVsZWQgdHJhZmZpYy4NCj4gPiA+ID4gPiBXaGVuIGFuIFVEUCB0dW5uZWwgaXMg dXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcw0KPiA+ID4gPiA+IGtub3duIGF0 IGNvbmZpZ3VyYXRpb24gdGltZSBub3QgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gY29u Z2VzdGlvbi1jb250cm9sbGVkLCB0aGUgVURQIHR1bm5lbCBTSE9VTEQgZW1wbG95IGFuDQo+ID4g PiA+ID4gYXBwcm9wcmlhdGUgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSBhcyBkZXNjcmli ZWQgaW4NCj4gPiA+ID4gPiBbUkZDMzk4NV0uIE5vdGUgdGhhdCBpdCBTVFJPTkdMWSBSRUNPTU1F TkRFRCB0byBkZXBsb3kgc3VjaA0KPiA+ID4gPiA+IGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9neSBv bmx5IHdpdGhpbiBhIFNQIG5ldHdvcmsgb3IgbmV0d29ya3Mgb2YNCj4gPiA+ID4gPiBhbiBhZGph Y2VudCBzZXQgb2YgY28tb3BlcmF0aW5nIFNQcywgcmF0aGVyIHRoYW4gb3ZlciB0aGUNCj4gPiA+ IEludGVybmV0Lg0KPiA+ID4gPiA+IEZ1cnRoZXJtb3JlLCBwYWNrZXQgZmlsdGVycyBzaG91bGQg YmUgYWRkZWQgdG8gYmxvY2sgdHJhZmZpYw0KPiA+ID4gPiA+IHdpdGggdGhlIFVEUCBwb3J0IG51 bWJlciBmb3IgTVBMUyBvdmVyIFVEUCB0byBwcmV2ZW50IE1QTFMgb3Zlcg0KPiA+ID4gPiA+IFVE UCBwYWNrZXRzIHRvIGVzY2FwZSBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmtzIGR1 ZSB0bw0KPiA+ID4gPiA+IG1pc2NvbmZpZ3VhdGlvbiBvciBwYWNrZXQNCj4gPiA+ID4gZXJyb3Jz Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVz Y3JpYmUgdGhlIE9BTSBjb250cm9sIGxvb3AgaW4NCj4gPiA+ID4gPiAoc29tZSkgbW9yZSBkZXRh aWwsIHJhdGhlciB0aGFuIHBvaW50aW5nIHRvIFJGQzM5ODUsIHdoaWNoDQo+ID4gPiA+ID4gZG9l c24ndCBoYXZlIGEgd2hvbGUgbG90IG9mIGRldGFpbCBlaXRoZXIuIEFsc28gYmVjYXVzZSB0aGUN Cj4gPiA+ID4gPiBhZGRpbmcgb2YgZmlyZXdhbGwgcnVsZXMgcmVxdWlyZXMgYW4gT0FNIGhvb2su DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBTaW5jZSBTVFJPTkdMWSBSRUNPTU1FTkRFRCBpcyBub3Qg YW4gUkZDMjExOSB0ZXJtIGFuZA0KPiA+ID4gPiBSRUNPTU1FTkRFRCBpcw0KPiA+ID4gPiA+IHRv byB3ZWFrLCBJJ2Qgc3VnZ2VzdCB0byBjaGFuZ2UgdGhpcyB0byBNVVNULg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gRmluYWxseSwgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHNob3VsZCBiZSBw cm9taW5lbnRseSBtYWRlDQo+ID4gPiA+ID4gaW4gdGhlIGFic3RyYWN0LCBpbnRyb2R1Y3Rpb24s IGV0Yy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IExhcnMNCg== From l.wood@surrey.ac.uk Thu Jan 23 21:06:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFAC1A01C6 for ; Thu, 23 Jan 2014 21:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 x9MZkuhTvVHy for ; Thu, 23 Jan 2014 21:06:26 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6D91A0179 for ; Thu, 23 Jan 2014 21:06:25 -0800 (PST) Received: from [85.158.137.99:53678] by server-4.bemta-3.messagelabs.com id EB/77-10414-EC4F1E25; Fri, 24 Jan 2014 05:06:22 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-5.tower-217.messagelabs.com!1390539981!17615673!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6695 invoked from network); 24 Jan 2014 05:06:21 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-5.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jan 2014 05:06:21 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Fri, 24 Jan 2014 05:06:21 +0000 From: To: , , Date: Fri, 24 Jan 2014 05:04:55 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGLe0Vpx4VpP9lE+4fynfG27EApqTPtnwgAASPbeAAAEfLw== Message-ID: <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.ac.uk> References: Your message of "Thu, 23 Jan 2014 17:18:22 +0000." <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247954@NKGEML512-MBS.china.huawei.com>, <290E20B455C66743BE178C5C84F1240847E63346ED@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346ED@EXMB01CMS.surrey.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 05:06:29 -0000 QWgsIG1ha2UgdGhhdDoNCg0KIkdlbmVyYWxseSBzcGVha2luZywgYSBVRFAgY2hlY2tzdW0gU0hP VUxEIGJlIHVzZWQuIFRoZSBjb25zaWRlcmF0aW9ucyBkZXNjcmliZWQgaW4gZGV0YWlsIGluIFtS RkM2OTM1XSBbUkZDNjkzNl0gTVVTVCBiZSBleGFtaW5lZCBpZiBVRFAgY2hlY2tzdW1zIG5lZWQg dG8gYmUgZGlzYWJsZWQgZm9yIHBlcmZvcm1hbmNlIG9yIGltcGxlbWVudGF0aW9uIHJlYXNvbnMg Zm9yIHRyYWZmaWMgYWNyb3NzIHByaXZhdGUgbmV0d29ya3MuIFRoZSB1c2Ugb2YgYSB6ZXJvIFVE UCBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQuIg0KDQppZSBpZiB5b3UncmUgZXZlbiB0aGlu a2luZyBvZiB0dXJuaW5nIG9mZiBjaGVja3N1bXMsIGdvIHJlYWQgdGhvc2UgUkZDcyBmaXJzdC4N Cg0KTGxveWQgV29vZA0KaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogV29vZCBMICBEciAoRWxlY3Ryb25pYyBF bmcpDQpTZW50OiAyNCBKYW51YXJ5IDIwMTQgMDU6MDANClRvOiBYdXhpYW9odTsgY3VydGlzQGlw djYub2NjbmMuY29tDQpDYzogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNA bmV0YXBwLmNvbTsgam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6 IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fw c3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCkkgd291bGQgYmUg Z29vZCB3aXRoOg0KDQoiR2VuZXJhbGx5IHNwZWFraW5nLCBhIFVEUCBjaGVja3N1bSBTSE9VTEQg YmUgdXNlZC4gVGhlIGNvbnNpZGVyYXRpb25zIGRlc2NyaWJlZCBpbiBbUkZDNjkzNV0gW1JGQzY5 MzZdIFNIT1VMRCBiZSBleGFtaW5lZCBpZiBVRFAgY2hlY2tzdW1zIG5lZWQgdG8gYmUgZGlzYWJs ZWQgZm9yIHBlcmZvcm1hbmNlIG9yIGltcGxlbWVudGF0aW9uIHJlYXNvbnMgZm9yIHRyYWZmaWMg YWNyb3NzIHByaXZhdGUgbmV0d29ya3MuIFRoZSB1c2Ugb2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBp cyBOT1QgUkVDT01NRU5ERUQuIg0KDQpJIHdvdWxkbid0IG1ha2UgdGhpcyBJUHY2IHNwZWNpZmlj IC0gSVB2NCBzdGlsbCBoYXMgcHJvYmxlbXMgKFVEUCBwb3J0IGRlbXV4KSwgSVB2NidzIHByb2Js ZW1zIGFyZSBqdXN0IHdvcnNlLg0KDQpMbG95ZCBXb29kDQpodHRwOi8vYWJvdXQubWUvbGxveWR3 b29kDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBYdXhp YW9odSBbeHV4aWFvaHVAaHVhd2VpLmNvbV0NClNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwNDowMA0K VG86IGN1cnRpc0BpcHY2Lm9jY25jLmNvbTsgV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpDQpD YzogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBwLmNvbTsgam9l bGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENh bGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBp biBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCkhpLA0KDQpQbGVhc2UgY2hlY2sgd2hldGhl ciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0suDQoNCkluIHRoZSBJUHY2IFVEUCBlbmNhcHN1bGF0 aW9uIGNhc2UsIGFzIGZvciB3aGV0aGVyIG9yIG5vdCBpdCBpcyBzdWl0YWJsZSB0byB1c2UgdGhl IHplcm8tY2hlY2tzdW0gbm9kZSwgdGhlIHJlcXVpcmVtZW50cyBkZWZpbmVkIGluIFtSRkM2OTM1 XSBbUkZDNjkzNl0gU0hPVUxEIGJlIHN0cmljdGx5IGZvbGxvd2VkLiBHZW5lcmFsbHkgc3BlYWtp bmcsIHRoZSB1c2Ugb2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQuIE5v dGUgdGhhdCBvdGhlciBJUCBlbmNhcHN1bGF0aW9ucyBmb3IgTVBMUyBkbyBub3QgaGF2ZSBhIGNo ZWNrc3VtIGluIHRoZSB0dW5uZWwgaGVhZGVyLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0K PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBDdXJ0aXMgVmlsbGFtaXphciBbbWFpbHRv OmN1cnRpc0BpcHY2Lm9jY25jLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTTE6jHUwjI0yNUgMTE6NTMN Cj4gytW8/sjLOiBsLndvb2RAc3VycmV5LmFjLnVrDQo+ILOty806IFh1eGlhb2h1OyBBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tOw0KPiBqb2VsamFAYm9n dXMuY29tOyBtcGxzQGlldGYub3JnDQo+INb3zOI6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJh ZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMNCj4gaW4gVURQ KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPg0KPg0KPiBJbiBtZXNzYWdlDQo+IDwyOTBFMjBCNDU1 QzY2NzQzQkUxNzhDNUM4NEYxMjQwODQ3RTYzMzQ2RTNARVhNQjAxQ01TLnN1cnJleS5hDQo+IGMu dWs+DQo+IGwud29vZEBzdXJyZXkuYWMudWsgd3JpdGVzOg0KPg0KPiA+IHRoZSB0ZXh0IGlzIG5v dCBzYXRpc2ZhY3RvcnkuIG5ldmVyIHJlY29tbWVuZCBzZXR0aW5nIHRvIHplcm8sIGFzIHRoYXQN Cj4gPiBwb3NlcyBhIHJpc2sgdG8geW91ciBhbmQgdG8gb3RoZXIgdHJhZmZpYy4gU3VnZ2VzdGVk IHRleHQ6DQo+ID4gKioqDQo+ID4gVGhlIFVEUCBjaGVja3N1bSBTSE9VTEQgYmUgdXNlZCB0byBw cm90ZWN0IHRoZSBwYXlsb2FkIGFuZCBlbnN1cmUNCj4gPiBjb3JyZWN0IGRlbXVsdGlwbGV4aW5n IGFuZCBkZWxpdmVyeSB0byB0aGUgdHVubmVsLCBhbmQgbm90IHRvIG90aGVyDQo+ID4gVURQIGRl c3RpbmF0aW9ucywgYnkgcHJvdGVjdGluZyB0aGUgVURQIHBzZXVkb2hlYWRlci4NCj4gPiBVc2Ug b2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQsIGV2ZW4gd2hlbiBkZXNp cmVkIGZvcg0KPiA+IHBlcmZvcm1hbmNlIG9yIG5lY2Vzc2l0YXRlZCBieSBpbXBsZW1lbnRhdGlv biByZWFzb25zLCBmb3IgdGhlIHJlYXNvbnMNCj4gPiBvdXRsaW5lZCBpbiBbUkZDNjkzNl0gc2Vj dGlvbiAzLg0KPg0KPiBJIGFncmVlIHRoYXQgVURQIGNoZWNrc3VtcyBTSE9VTEQgYmUgdXNlZCAo aWU6IFNIT1VMRCBOT1QgYmUgc2V0IHRvIHplcm8pLg0KPiBUaGVyZSBhcmUgY2FzZXMgd2hlcmUg aXQgaXMgaW1wb3NzaWJsZSBzbyBpdCBjYW4ndCBiZSBNVVNULg0KPg0KPiA+IFVEUC1MaXRlIFtS RkMzODI4XSBjYW4gcHJvdmlkZSBhIGRlbXVsdGlwbGV4aW5nIGNoZWNrIGFuZCBNUExTIHN0YWNr DQo+ID4gaW50ZWdyaXR5IGNoZWNrIHdoaWxlIGF2b2lkaW5nIHRoZSBvdmVyaGVhZCBvZiBjb21w dXRpbmcgYW4gaW50ZWdyaXR5DQo+ID4gY2hlY2sgb3ZlciBhIHR1bm5lbGxlZCBmcmFtZSB0aGF0 IGhhcyBpdHMgb3duIGludGVncml0eSBjaGVjay4NCj4NCj4gVURQLUxpc3QgZG9lc24ndCBzb2x2 ZSB0aGUgRUNNUCBwcm9ibGVtcyBiZWNhdXNlIG1vc3Qgb2YgdGhlIG9sZGVyIExTUiB0aGF0DQo+ IGFyZSBmb3JjaW5nIHRoZSB1c2Ugb2YgTVBMUyBvdmVyIFVEUCB0byBnZXQgRUNNUCBkb24ndCBs b29rIGF0IHRoZSBwb3J0DQo+IG51bWJlcnMgaWYgdGhlIHByb3RvY29sIGlzIG5vdCA2IG9yIDE3 LiAgQnV0IHRoaXMgaGFzIG9ubHkgYmVlbiBzYWlkIHRocmVlIG9yIGZvdXINCj4gdGltZXMgc28g bWF5YmUgeW91IG1pc3NlZCBpdC4NCj4NCj4gPiAqKioNCj4gPg0KPiA+IExsb3lkIFdvb2QNCj4g PiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IEZyb206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29t XQ0KPiA+IFNlbnQ6IDIzIEphbnVhcnkgMjAxNCAxMjozNQ0KPiA+IFRvOiBXb29kIEwgIERyIChF bGVjdHJvbmljIEVuZyk7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0KPiA+IGxh cnNAbmV0YXBwLmNvbQ0KPiA+IENjOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ ID4gU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRw LTA0LnR4dD4NCj4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3Rh bmRhcmQNCj4gPg0KPiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gPiC3orz+yMs6IGwud29v ZEBzdXJyZXkuYWMudWsgW21haWx0bzpsLndvb2RAc3VycmV5LmFjLnVrXQ0KPiA+ID4gt6LLzcqx vOQ6IDIwMTTE6jHUwjIzyNUgMTI6NDQNCj4gPiA+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5ldGFwcC5jb20NCj4gPiA+ILOty806IGpv ZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiA+INb3zOI6IFJFOiBbbXBsc10gTGFz dCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiAoRW5jYXBzdWxh dGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+DQo+ID4gPiBTYXNo YQ0KPiA+ID4NCj4gPiA+ID4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEg bm9uLWlzc3VlIGJlY2F1c2UgbmF0aXZlDQo+ID4gPiA+IE1QTFMgZG9lcyBub3QgaGF2ZSBhbnl0 aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFyZSBjYXNlcw0KPiA+ID4gPiB3aGVyZSBw YWNrZXRzIGFyZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKQ0KPiA+ID4NCj4gPiA+IFNv IHlvdSBhZG1pdCB0aGF0IHBhY2tldHMgY2FuIGJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRl cnMgLSBhDQo+ID4gPiBjaGVjayB0aGF0IGNhbiBvbmx5IGJlIGNhdWdodCBieSBhbiBlbmQtdG8t ZW5kIGNoZWNrLCBhIGNvcnJ1cHRpb24NCj4gPiA+IHRoYXQgY2FuIGxlYWQgdG8gdGhlIHByb2Js ZW1zIGRldGFpbGVkIGluIFJGQyA2OTM2IHNlY3Rpb24gMyAtIGFuZA0KPiA+ID4gdGhlbiB5b3Ug c2F5IGl0J3MgYSBub24taXNzdWUgYmVjYXVzZSB0aGlzIGRvZXNuJ3QgYWZmZWN0IG5hdGl2ZSBN UExTLiBCdXQNCj4gd2UncmUgbm90IGRvaW5nIG5hdGl2ZSBNUExTIGhlcmUuDQo+ID4gPiBXZSdy ZSBkb2luZyBNUExTIG92ZXIgVURQLg0KPiA+ID4NCj4gPiA+IGRyYWZ0LWlldGYtbXBscy1pbi11 ZHAtMDQudHh0IGlzIGFib3V0IHR1bm5lbGxpbmcgTVBMUyBpbiBVRFAuIEl0J3MgYW4gaXNzdWUu DQo+ID4gPiBQbGVhc2UgcmVhZCB0aGUgb3RoZXIgMTUwIG1lc3NhZ2VzIHRoYXQgeW91IHJlZmVy IHRvLg0KPiA+DQo+ID4gSGkgTGxveWQsDQo+ID4NCj4gPiBUaGUgZHJhZnQgZG9lc24ndCByZXF1 aXJlIHRoZSBJUHY2IFVEUCBjaGVja3N1bSB0byBiZSBzZXQgdG8gemVybyByZWdhcmRsZXNzLg0K PiBTZWUgdGhlIGZvbGxvd2luZyB0ZXh0IHF1b3RlZCBmcm9tIHRoYXQgZHJhZnQ6DQo+ID4NCj4g PiBVRFAgQ2hlY2tzdW0NCj4gPg0KPiA+IFRoZSB1c2FnZSBvZiB0aGlzIGZpZWxkIGlzIGluIGFj Y29yZGFuY2Ugd2l0aCB0aGUgY3VycmVudCBVRFAgc3BlY2lmaWNhdGlvbg0KPiBbUkZDNzY4XS4g VG8gc2ltcGxpZnkgdGhlIG9wZXJhdGlvbiBvbiB0aGUgZGVjYXBzdWxhdG9yLCB0aGlzIGZpZWxk IGlzDQo+IFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGluIElQdjQgVURQIGVuY2Fwc3Vs YXRpb24gY2FzZS4gSW4gdGhlIElQdjYNCj4gVURQIGVuY2Fwc3VsYXRpb24gY2FzZSwgaWYgYXBw cm9wcmlhdGUgYWNjb3JkaW5nIHRvIHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbg0KPiBbUkZD NjkzNV0gW1JGQzY5MzZdLCB0aGlzIGZpZWxkIGlzIGFsc28gUkVDT01NRU5ERUQgdG8gYmUgc2V0 IHRvIHplcm8uDQo+IFNwZWNpZmljYWxseSwgaWYgdGhlIE1QTFMgcGF5bG9hZCBpcyBJbnRlcm5l dCBQcm90b2NvbCAoSVB2NCBvciBJUHY2KSBwYWNrZXRzLCBpdCBpcw0KPiBSRUNPTU1FTkRFRCB0 byBiZSBzZXQgdG8gemVybyB3aGVuIHRoZSBpbm5lciBwYWNrZXQgaW50ZWdyaXR5IGNoZWNrcyBp cw0KPiBhdmFpbGFibGUuIEluIGFkZGl0aW9uLCBpZiB0aGUgTVBMUyBwYXlsb2FkIGlzIG5vbi1J UCBwYWNrZXQgd2hpY2ggaXMgc3BlY2lmaWNhbGx5DQo+IGRlc2lnbmVkIGZvciB0cmFuc21pc3Np b24gb3ZlciBhIGxvd2VyIGxheWVyIHRoYXQgZG9lcyBub3QgcHJvdmlkZSBhIHBhY2tldA0KPiBp bnRlZ3JpdHkgZ3VhcmFudGVlLCBpdCBpcyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyBh cyB3ZWxsLiBPdGhlcndpc2UsDQo+IHVzaW5nIHplcm8gY2hlY2tzdW0gaXMgTk9UIFJFQ09NTUVO REVELiBOb3RlIHRoYXQgb3RoZXIgSVAgZW5jYXBzdWxhdGlvbnMNCj4gZm9yIE1QTFMgZG8gbm90 IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCj4gPg0KPiA+IElmIHlvdSBz dGlsbCBiZWxpZXZlIHRoZSBhYm92ZSB0ZXh0IGlzIG5vdCBzYXRpc2ZhY3RvcnksIHBsZWFzZSBw cm92aWRlIHlvdXIgdGV4dC4NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4g Pg0KPiA+ID4gTGxveWQgV29vZA0KPiA+ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRnJvbTog bXBscyBbbXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNCj4gPiA+ IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiA+ID4gU2VudDogMjMgSmFudWFyeSAyMDE0IDAzOjE2 DQo+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IEVnZ2VydCwgTGFycw0KPiA+ID4gQ2M6 IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBM YXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChFbmNhcHN1 bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+IEhp DQo+ID4gPg0KPiA+ID4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ID4gt6K8/sjLOiBBbGV4 YW5kZXIgVmFpbnNodGVpbg0KPiA+ID4gPiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tXQ0KPiA+ID4gPiC3osvNyrG85DogMjAxNMTqMdTCMjLI1SAxOTowNQ0KPiA+ID4g PiDK1bz+yMs6IEVnZ2VydCwgTGFycw0KPiA+ID4gPiCzrcvNOiBKb2VsIEphZWdnbGk7IG1wbHNA aWV0Zi5vcmc7IFh1eGlhb2h1DQo+ID4gPiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8 ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1Q TFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPg0KPiA+ID4gPiBMYXJzIGFu ZCBhbGwsDQo+ID4gPiA+IExhc3QgdGltZSBJJ3ZlIGNvdW50ZWQgdGhlIElFVEYgTEMgdGhyZWFk IG9uIHRoaXMgZHJhZnQgaGFzIG1vcmUNCj4gPiA+ID4gdGhhbg0KPiA+ID4gPiAxNTAgbWVzc2Fn ZXMgaW4gaXQsIGFuZCBpdCBzZWVtcyB0aGF0IG9uIHNvbWUgaXNzdWVzIChjb25nZXN0aW9uDQo+ ID4gPiA+IGNvbnRyb2wgYW5kIFVEUA0KPiA+ID4gPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyBy b3VuZCB0aGUgbXVsYmVycnkgYnVzaC4NCj4gPiA+ID4NCj4gPiA+ID4gSU1ITyBhbmQgRldJVzoN Cj4gPiA+ID4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3Vl IGJlY2F1c2UgbmF0aXZlDQo+ID4gPiA+IE1QTFMgZG9lcyBub3QgaGF2ZSBhbnl0aGluZyBsaWtl IHRoYXQuIEFuZCB5ZXMsIHRoZXJlIGFyZSBjYXNlcw0KPiA+ID4gPiB3aGVyZSBwYWNrZXRzIGFy ZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKSwgYnV0IHNvIGZhciBpdCBkaWQNCj4gPiA+ ID4gbm90IHByZXZlbnQgTVBMUyBkZXBsb3ltZW50LiBUaGVyZSBpcywgZS5nLiwgUkZDIDQ3MjAg Zm9yIEZDUw0KPiA+ID4gPiByZXRlbnRpb24gaW4gUFdzLCBidXQgSSBkb3VidCBpdCBpcyB3aWRl bHkgaW1wbGVtZW50ZWQgYW5kDQo+ID4gPiA+IGRlcGxveWVkICh3b3VsZCBiZSBuaWNlIHRvDQo+ ID4gPiBrbm93KS4NCj4gPiA+ID4gLSBFMkUgY29uZ2VzdGlvbiBjb250cm9sIChyZWdhcmRsZXNz IG9mIGl0cyBpbXBsaWNhdGlvbnMpIHNpbXBseQ0KPiA+ID4gPiBjYW5ub3QgYmUgYWRkZWQgdG8g dGhpcyBwcm90b2NvbCB3aXRob3V0IHNvbWUgbWFqb3IgY2hhbmdlcy4gQQ0KPiA+ID4gPiBzaG9y dCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBleHBsYWluaW5nIHRoYXQgc2hvdWxkIHN1ZmZpY2Ug SU1PLg0KPiA+ID4NCj4gPiA+IEhpIFNhc2hhLA0KPiA+ID4NCj4gPiA+IEkgZnVsbHkgYWdyZWUg d2l0aCB5b3VyIHBvaW50cy4NCj4gPiA+DQo+ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiBYaWFv aHUNCj4gPiA+DQo+ID4gPiA+IE15IDJjLA0KPiA+ID4gPiAgICAgICAgU2FzaGENCj4gPiA+ID4g RW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+ID4gPiA+IE1vYmlsZTog MDU0LTkyNjYzMDINCj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+ID4gPiA+IEZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBFZ2dlcnQsDQo+ID4gPiA+ID4gTGFycw0KPiA+ID4gPiA+IFNlbnQ6IFdlZG5l c2RheSwgSmFudWFyeSAyMiwgMjAxNCAxMjoyMyBQTQ0KPiA+ID4gPiA+IFRvOiBYdXhpYW9odQ0K PiA+ID4gPiA+IENjOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJq ZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0 Pg0KPiA+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFu ZGFyZA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSGksDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPbiAy MDE0LTEtMjIsIGF0IDExOjEyLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6 DQo+ID4gPiA+ID4gPiBJIHdvbmRlciB3aGV0aGVyIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBPSyB0 byB5b3U6DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gU2luY2UgdGhlIE1QTFMtaW4tVURQIGVu Y2Fwc3VsYXRpb24gY2F1c2VzIE1QTFMgcGFja2V0cyB0byBiZQ0KPiA+ID4gPiA+IGZvcndhcmRl ZCB0aHJvdWdoICJVRFAgdHVubmVscyIsIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wNCj4gPiA+ID4g PiBndWlkZWxpbmVzIGZvciBVRFAgdHVubmVscyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjMg b2YNCj4gPiA+ID4gPiBbUkZDNTQwNV0gU0hPVUxEIGJlDQo+ID4gPiBmb2xsb3dlZC4NCj4gPiA+ ID4gPiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5IGEgbnVtYmVyIG9mIGRpZmZlcmVudCBw cm90b2NvbHMgYXMgcGF5bG9hZHMuDQo+ID4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVz ZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFmZmljIHRoYXQgaXMNCj4gPiA+ID4gPiBrbm93biBhdCBj b25maWd1cmF0aW9uIHRpbWUgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gY29uZ2VzdGlv bi1jb250cm9sbGVkLCB0aGUgVURQIHR1bm5lbCBTSE9VTEQgTk9UIGVtcGxveSBpdHMgb3duDQo+ ID4gPiA+ID4gY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSwgYmVjYXVzZSBjb25nZXN0aW9u IGxvc3NlcyBvZg0KPiA+ID4gPiA+IHR1bm5lbGVkIHRyYWZmaWMgd2lsbCB0cmlnZ2VyIGFuIGNv bmdlc3Rpb24gcmVzcG9uc2UgYXQgdGhlIG9yaWdpbmFsDQo+IHNlbmRlcnMgb2YgdGhlIHR1bm5l bGVkIHRyYWZmaWMuDQo+ID4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1Q TFMgcGF5bG9hZCB0cmFmZmljIHRoYXQgaXMNCj4gPiA+ID4gPiBrbm93biBhdCBjb25maWd1cmF0 aW9uIHRpbWUgbm90IHRvIGJlIElQLWJhc2VkIGFuZA0KPiA+ID4gPiA+IGNvbmdlc3Rpb24tY29u dHJvbGxlZCwgdGhlIFVEUCB0dW5uZWwgU0hPVUxEIGVtcGxveSBhbg0KPiA+ID4gPiA+IGFwcHJv cHJpYXRlIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluDQo+ID4g PiA+ID4gW1JGQzM5ODVdLiBOb3RlIHRoYXQgaXQgU1RST05HTFkgUkVDT01NRU5ERUQgdG8gZGVw bG95IHN1Y2gNCj4gPiA+ID4gPiBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kgb25seSB3aXRoaW4g YSBTUCBuZXR3b3JrIG9yIG5ldHdvcmtzIG9mDQo+ID4gPiA+ID4gYW4gYWRqYWNlbnQgc2V0IG9m IGNvLW9wZXJhdGluZyBTUHMsIHJhdGhlciB0aGFuIG92ZXIgdGhlDQo+ID4gPiBJbnRlcm5ldC4N Cj4gPiA+ID4gPiBGdXJ0aGVybW9yZSwgcGFja2V0IGZpbHRlcnMgc2hvdWxkIGJlIGFkZGVkIHRv IGJsb2NrIHRyYWZmaWMNCj4gPiA+ID4gPiB3aXRoIHRoZSBVRFAgcG9ydCBudW1iZXIgZm9yIE1Q TFMgb3ZlciBVRFAgdG8gcHJldmVudCBNUExTIG92ZXINCj4gPiA+ID4gPiBVRFAgcGFja2V0cyB0 byBlc2NhcGUgZnJvbSB0aGUgc2VydmljZSBwcm92aWRlciBuZXR3b3JrcyBkdWUgdG8NCj4gPiA+ ID4gPiBtaXNjb25maWd1YXRpb24gb3IgcGFja2V0DQo+ID4gPiA+IGVycm9ycy4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGRlc2NyaWJlIHRoZSBP QU0gY29udHJvbCBsb29wIGluDQo+ID4gPiA+ID4gKHNvbWUpIG1vcmUgZGV0YWlsLCByYXRoZXIg dGhhbiBwb2ludGluZyB0byBSRkMzOTg1LCB3aGljaA0KPiA+ID4gPiA+IGRvZXNuJ3QgaGF2ZSBh IHdob2xlIGxvdCBvZiBkZXRhaWwgZWl0aGVyLiBBbHNvIGJlY2F1c2UgdGhlDQo+ID4gPiA+ID4g YWRkaW5nIG9mIGZpcmV3YWxsIHJ1bGVzIHJlcXVpcmVzIGFuIE9BTSBob29rLg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gU2luY2UgU1RST05HTFkgUkVDT01NRU5ERUQgaXMgbm90IGFuIFJGQzIxMTkg dGVybSBhbmQNCj4gPiA+ID4gUkVDT01NRU5ERUQgaXMNCj4gPiA+ID4gPiB0b28gd2VhaywgSSdk IHN1Z2dlc3QgdG8gY2hhbmdlIHRoaXMgdG8gTVVTVC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEZp bmFsbHksIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBzaG91bGQgYmUgcHJvbWluZW50bHkg bWFkZQ0KPiA+ID4gPiA+IGluIHRoZSBhYnN0cmFjdCwgaW50cm9kdWN0aW9uLCBldGMuDQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBMYXJzDQo= From xuxiaohu@huawei.com Thu Jan 23 21:59:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3071A01BA for ; Thu, 23 Jan 2014 21:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 ynTdxY8B_8DD for ; Thu, 23 Jan 2014 21:59:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E50CC1A01AD for ; Thu, 23 Jan 2014 21:59:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAJ29239; Fri, 24 Jan 2014 05:59:00 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 05:58:40 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 05:58:57 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 13:58:53 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGLe0Vpx4VpP9lE+4fynfG27EApqTPtnwgAASPbeAAAEfL4AACmVQ Date: Fri, 24 Jan 2014 05:58:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082479A5@NKGEML512-MBS.china.huawei.com> References: Your message of "Thu, 23 Jan 2014 17:18:22 +0000." <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247954@NKGEML512-MBS.china.huawei.com>, <290E20B455C66743BE178C5C84F1240847E63346ED@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" , "lars@netapp.com" Subject: [mpls] =?gb2312?b?tPC4tDogIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg?= =?gb2312?b?dG8gUHJvcG9zZWQgU3RhbmRhcmQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 05:59:08 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBb bWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ILeiy83KsbzkOiAyMDE0xOox1MIyNMjVIDEz OjA1DQo+IMrVvP7IyzogbC53b29kQHN1cnJleS5hYy51azsgWHV4aWFvaHU7IGN1cnRpc0BpcHY2 Lm9jY25jLmNvbQ0KPiCzrcvNOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFy c0BuZXRhcHAuY29tOyBqb2VsamFAYm9ndXMuY29tOw0KPiBtcGxzQGlldGYub3JnDQo+INb3zOI6 IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChF bmNhcHN1bGF0aW5nIE1QTFMNCj4gaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4g QWgsIG1ha2UgdGhhdDoNCj4gDQo+ICJHZW5lcmFsbHkgc3BlYWtpbmcsIGEgVURQIGNoZWNrc3Vt IFNIT1VMRCBiZSB1c2VkLiBUaGUgY29uc2lkZXJhdGlvbnMNCj4gZGVzY3JpYmVkIGluIGRldGFp bCBpbiBbUkZDNjkzNV0gW1JGQzY5MzZdIE1VU1QgYmUgZXhhbWluZWQgaWYgVURQDQo+IGNoZWNr c3VtcyBuZWVkIHRvIGJlIGRpc2FibGVkIGZvciBwZXJmb3JtYW5jZSBvciBpbXBsZW1lbnRhdGlv biByZWFzb25zIGZvcg0KPiB0cmFmZmljIGFjcm9zcyBwcml2YXRlIG5ldHdvcmtzLiBUaGUgdXNl IG9mIGEgemVybyBVRFAgY2hlY2tzdW0gaXMgTk9UDQo+IFJFQ09NTUVOREVELiINCg0KR29vZCBz dWdnZXN0aW9uLiBCVFcsIEkgc3VnZ2VzdGlvbiByZW1vdmluZyAiZm9yIHRyYWZmaWMgYWNyb3Nz IHByaXZhdGUgbmV0d29yayIgZHVlIHRvIHRoZSBmb2xsb3dpbmcgcmVhc29uczogRmlyc3QsIHRo ZXJlIGhhcyBiZWVuIGEgZGVkaWNhdGVkIGFwcGxpY2F0aW9uIHN0YXRlbWVudCB3aGljaCBleHBs aWNpdGx5IG1lbnRpb25lZCB0aGF0LiBTZWNvbmQsIFNQIG5ldHdvcmtzIGFyZSBub3QgY29tbW9u bHkgY2FsbGVkIGFzICJwcml2YXRlIG5ldHdvcmtzIi4gDQoNCj4gaWUgaWYgeW91J3JlIGV2ZW4g dGhpbmtpbmcgb2YgdHVybmluZyBvZmYgY2hlY2tzdW1zLCBnbyByZWFkIHRob3NlIFJGQ3MgZmly c3QuDQo+IA0KPiBMbG95ZCBXb29kDQo+IGh0dHA6Ly9hYm91dC5tZS9sbG95ZHdvb2QNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBXb29kIEwgIERy IChFbGVjdHJvbmljIEVuZykNCj4gU2VudDogMjQgSmFudWFyeSAyMDE0IDA1OjAwDQo+IFRvOiBY dXhpYW9odTsgY3VydGlzQGlwdjYub2NjbmMuY29tDQo+IENjOiBBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tOyBqb2VsamFAYm9ndXMuY29tOw0KPiBtcGxz QGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1t cGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nDQo+IE1QTFMgaW4gVURQKSB0byBQcm9w b3NlZCBTdGFuZGFyZA0KPiANCj4gSSB3b3VsZCBiZSBnb29kIHdpdGg6DQo+IA0KPiAiR2VuZXJh bGx5IHNwZWFraW5nLCBhIFVEUCBjaGVja3N1bSBTSE9VTEQgYmUgdXNlZC4gVGhlIGNvbnNpZGVy YXRpb25zDQo+IGRlc2NyaWJlZCBpbiBbUkZDNjkzNV0gW1JGQzY5MzZdIFNIT1VMRCBiZSBleGFt aW5lZCBpZiBVRFAgY2hlY2tzdW1zDQo+IG5lZWQgdG8gYmUgZGlzYWJsZWQgZm9yIHBlcmZvcm1h bmNlIG9yIGltcGxlbWVudGF0aW9uIHJlYXNvbnMgZm9yIHRyYWZmaWMNCj4gYWNyb3NzIHByaXZh dGUgbmV0d29ya3MuIFRoZSB1c2Ugb2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBpcyBOT1QNCj4gUkVD T01NRU5ERUQuIg0KPiANCj4gSSB3b3VsZG4ndCBtYWtlIHRoaXMgSVB2NiBzcGVjaWZpYyAtIElQ djQgc3RpbGwgaGFzIHByb2JsZW1zIChVRFAgcG9ydCBkZW11eCksDQo+IElQdjYncyBwcm9ibGVt cyBhcmUganVzdCB3b3JzZS4NCj4gDQo+IExsb3lkIFdvb2QNCj4gaHR0cDovL2Fib3V0Lm1lL2xs b3lkd29vZA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZy b206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiBTZW50OiAyNCBKYW51YXJ5IDIw MTQgMDQ6MDANCj4gVG86IGN1cnRpc0BpcHY2Lm9jY25jLmNvbTsgV29vZCBMICBEciAoRWxlY3Ry b25pYyBFbmcpDQo+IENjOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0Bu ZXRhcHAuY29tOyBqb2VsamFAYm9ndXMuY29tOw0KPiBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6 IHJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChF bmNhcHN1bGF0aW5nIE1QTFMNCj4gaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4g SGksDQo+IA0KPiBQbGVhc2UgY2hlY2sgd2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0su DQo+IA0KPiBJbiB0aGUgSVB2NiBVRFAgZW5jYXBzdWxhdGlvbiBjYXNlLCBhcyBmb3Igd2hldGhl ciBvciBub3QgaXQgaXMgc3VpdGFibGUgdG8gdXNlIHRoZQ0KPiB6ZXJvLWNoZWNrc3VtIG5vZGUs IHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbiBbUkZDNjkzNV0gW1JGQzY5MzZdDQo+IFNIT1VM RCBiZSBzdHJpY3RseSBmb2xsb3dlZC4gR2VuZXJhbGx5IHNwZWFraW5nLCB0aGUgdXNlIG9mIGEg emVybyBVRFANCj4gY2hlY2tzdW0gaXMgTk9UIFJFQ09NTUVOREVELiBOb3RlIHRoYXQgb3RoZXIg SVAgZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMNCj4gZG8gbm90IGhhdmUgYSBjaGVja3N1bSBpbiB0 aGUgdHVubmVsIGhlYWRlci4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IA0KPiA+ IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ILeivP7IyzogQ3VydGlzIFZpbGxhbWl6YXIgW21haWx0 bzpjdXJ0aXNAaXB2Ni5vY2NuYy5jb21dDQo+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjI0yNUgMTE6 NTMNCj4gPiDK1bz+yMs6IGwud29vZEBzdXJyZXkuYWMudWsNCj4gPiCzrcvNOiBYdXhpYW9odTsg QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBwLmNvbTsNCj4gPiBq b2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4g1vfM4jogUmU6IFttcGxzXSBMYXN0 IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiAoRW5jYXBzdWxhdGlu ZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPg0KPiA+DQo+ID4gSW4gbWVz c2FnZQ0KPiA+DQo+IDwyOTBFMjBCNDU1QzY2NzQzQkUxNzhDNUM4NEYxMjQwODQ3RTYzMzQ2RTNA RVhNQjAxQ01TLnN1cnJleS5hDQo+ID4gYy51az4NCj4gPiBsLndvb2RAc3VycmV5LmFjLnVrIHdy aXRlczoNCj4gPg0KPiA+ID4gdGhlIHRleHQgaXMgbm90IHNhdGlzZmFjdG9yeS4gbmV2ZXIgcmVj b21tZW5kIHNldHRpbmcgdG8gemVybywgYXMNCj4gPiA+IHRoYXQgcG9zZXMgYSByaXNrIHRvIHlv dXIgYW5kIHRvIG90aGVyIHRyYWZmaWMuIFN1Z2dlc3RlZCB0ZXh0Og0KPiA+ID4gKioqDQo+ID4g PiBUaGUgVURQIGNoZWNrc3VtIFNIT1VMRCBiZSB1c2VkIHRvIHByb3RlY3QgdGhlIHBheWxvYWQg YW5kIGVuc3VyZQ0KPiA+ID4gY29ycmVjdCBkZW11bHRpcGxleGluZyBhbmQgZGVsaXZlcnkgdG8g dGhlIHR1bm5lbCwgYW5kIG5vdCB0byBvdGhlcg0KPiA+ID4gVURQIGRlc3RpbmF0aW9ucywgYnkg cHJvdGVjdGluZyB0aGUgVURQIHBzZXVkb2hlYWRlci4NCj4gPiA+IFVzZSBvZiBhIHplcm8gVURQ IGNoZWNrc3VtIGlzIE5PVCBSRUNPTU1FTkRFRCwgZXZlbiB3aGVuIGRlc2lyZWQgZm9yDQo+ID4g PiBwZXJmb3JtYW5jZSBvciBuZWNlc3NpdGF0ZWQgYnkgaW1wbGVtZW50YXRpb24gcmVhc29ucywg Zm9yIHRoZQ0KPiA+ID4gcmVhc29ucyBvdXRsaW5lZCBpbiBbUkZDNjkzNl0gc2VjdGlvbiAzLg0K PiA+DQo+ID4gSSBhZ3JlZSB0aGF0IFVEUCBjaGVja3N1bXMgU0hPVUxEIGJlIHVzZWQgKGllOiBT SE9VTEQgTk9UIGJlIHNldCB0byB6ZXJvKS4NCj4gPiBUaGVyZSBhcmUgY2FzZXMgd2hlcmUgaXQg aXMgaW1wb3NzaWJsZSBzbyBpdCBjYW4ndCBiZSBNVVNULg0KPiA+DQo+ID4gPiBVRFAtTGl0ZSBb UkZDMzgyOF0gY2FuIHByb3ZpZGUgYSBkZW11bHRpcGxleGluZyBjaGVjayBhbmQgTVBMUyBzdGFj aw0KPiA+ID4gaW50ZWdyaXR5IGNoZWNrIHdoaWxlIGF2b2lkaW5nIHRoZSBvdmVyaGVhZCBvZiBj b21wdXRpbmcgYW4NCj4gPiA+IGludGVncml0eSBjaGVjayBvdmVyIGEgdHVubmVsbGVkIGZyYW1l IHRoYXQgaGFzIGl0cyBvd24gaW50ZWdyaXR5IGNoZWNrLg0KPiA+DQo+ID4gVURQLUxpc3QgZG9l c24ndCBzb2x2ZSB0aGUgRUNNUCBwcm9ibGVtcyBiZWNhdXNlIG1vc3Qgb2YgdGhlIG9sZGVyIExT Ug0KPiA+IHRoYXQgYXJlIGZvcmNpbmcgdGhlIHVzZSBvZiBNUExTIG92ZXIgVURQIHRvIGdldCBF Q01QIGRvbid0IGxvb2sgYXQNCj4gPiB0aGUgcG9ydCBudW1iZXJzIGlmIHRoZSBwcm90b2NvbCBp cyBub3QgNiBvciAxNy4gIEJ1dCB0aGlzIGhhcyBvbmx5DQo+ID4gYmVlbiBzYWlkIHRocmVlIG9y IGZvdXIgdGltZXMgc28gbWF5YmUgeW91IG1pc3NlZCBpdC4NCj4gPg0KPiA+ID4gKioqDQo+ID4g Pg0KPiA+ID4gTGxveWQgV29vZA0KPiA+ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRnJvbTog WHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiBTZW50OiAyMyBKYW51YXJ5IDIw MTQgMTI6MzUNCj4gPiA+IFRvOiBXb29kIEwgIERyIChFbGVjdHJvbmljIEVuZyk7IEFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0KPiA+ID4gbGFyc0BuZXRhcHAuY29tDQo+ID4gPiBD Yzogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogcmU6IFtt cGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChF bmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4g PiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gPiA+ILeivP7IyzogbC53b29kQHN1cnJleS5h Yy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ID4gPiA+ILeiy83KsbzkOiAyMDE0 xOox1MIyM8jVIDEyOjQ0DQo+ID4gPiA+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5ldGFwcC5jb20NCj4gPiA+ID4gs63LzTogam9lbGph QGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiDW98ziOiBSRTogW21wbHNdIExhc3Qg Q2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiAoRW5jYXBzdWxh dGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4NCj4gPiA+ID4g U2FzaGENCj4gPiA+ID4NCj4gPiA+ID4gPiAtIFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhlcmVv ZikgaXMgYSBub24taXNzdWUgYmVjYXVzZSBuYXRpdmUNCj4gPiA+ID4gPiBNUExTIGRvZXMgbm90 IGhhdmUgYW55dGhpbmcgbGlrZSB0aGF0LiBBbmQgeWVzLCB0aGVyZSBhcmUgY2FzZXMNCj4gPiA+ ID4gPiB3aGVyZSBwYWNrZXRzIGFyZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKQ0KPiA+ ID4gPg0KPiA+ID4gPiBTbyB5b3UgYWRtaXQgdGhhdCBwYWNrZXRzIGNhbiBiZSBjb3JydXB0ZWQg d2l0aGluIHRoZSByb3V0ZXJzIC0gYQ0KPiA+ID4gPiBjaGVjayB0aGF0IGNhbiBvbmx5IGJlIGNh dWdodCBieSBhbiBlbmQtdG8tZW5kIGNoZWNrLCBhIGNvcnJ1cHRpb24NCj4gPiA+ID4gdGhhdCBj YW4gbGVhZCB0byB0aGUgcHJvYmxlbXMgZGV0YWlsZWQgaW4gUkZDIDY5MzYgc2VjdGlvbiAzIC0g YW5kDQo+ID4gPiA+IHRoZW4geW91IHNheSBpdCdzIGEgbm9uLWlzc3VlIGJlY2F1c2UgdGhpcyBk b2Vzbid0IGFmZmVjdCBuYXRpdmUNCj4gPiA+ID4gTVBMUy4gQnV0DQo+ID4gd2UncmUgbm90IGRv aW5nIG5hdGl2ZSBNUExTIGhlcmUuDQo+ID4gPiA+IFdlJ3JlIGRvaW5nIE1QTFMgb3ZlciBVRFAu DQo+ID4gPiA+DQo+ID4gPiA+IGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0IGlzIGFib3V0 IHR1bm5lbGxpbmcgTVBMUyBpbiBVRFAuIEl0J3MgYW4gaXNzdWUuDQo+ID4gPiA+IFBsZWFzZSBy ZWFkIHRoZSBvdGhlciAxNTAgbWVzc2FnZXMgdGhhdCB5b3UgcmVmZXIgdG8uDQo+ID4gPg0KPiA+ ID4gSGkgTGxveWQsDQo+ID4gPg0KPiA+ID4gVGhlIGRyYWZ0IGRvZXNuJ3QgcmVxdWlyZSB0aGUg SVB2NiBVRFAgY2hlY2tzdW0gdG8gYmUgc2V0IHRvIHplcm8NCj4gcmVnYXJkbGVzcy4NCj4gPiBT ZWUgdGhlIGZvbGxvd2luZyB0ZXh0IHF1b3RlZCBmcm9tIHRoYXQgZHJhZnQ6DQo+ID4gPg0KPiA+ ID4gVURQIENoZWNrc3VtDQo+ID4gPg0KPiA+ID4gVGhlIHVzYWdlIG9mIHRoaXMgZmllbGQgaXMg aW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBjdXJyZW50IFVEUA0KPiA+ID4gc3BlY2lmaWNhdGlvbg0K PiA+IFtSRkM3NjhdLiBUbyBzaW1wbGlmeSB0aGUgb3BlcmF0aW9uIG9uIHRoZSBkZWNhcHN1bGF0 b3IsIHRoaXMgZmllbGQgaXMNCj4gPiBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyBpbiBJ UHY0IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2UuIEluIHRoZQ0KPiA+IElQdjYgVURQIGVuY2Fwc3Vs YXRpb24gY2FzZSwgaWYgYXBwcm9wcmlhdGUgYWNjb3JkaW5nIHRvIHRoZQ0KPiA+IHJlcXVpcmVt ZW50cyBkZWZpbmVkIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0sIHRoaXMgZmllbGQgaXMgYWxzbw0K PiBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVyby4NCj4gPiBTcGVjaWZpY2FsbHksIGlmIHRo ZSBNUExTIHBheWxvYWQgaXMgSW50ZXJuZXQgUHJvdG9jb2wgKElQdjQgb3IgSVB2NikNCj4gPiBw YWNrZXRzLCBpdCBpcyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyB3aGVuIHRoZSBpbm5l ciBwYWNrZXQNCj4gPiBpbnRlZ3JpdHkgY2hlY2tzIGlzIGF2YWlsYWJsZS4gSW4gYWRkaXRpb24s IGlmIHRoZSBNUExTIHBheWxvYWQgaXMNCj4gPiBub24tSVAgcGFja2V0IHdoaWNoIGlzIHNwZWNp ZmljYWxseSBkZXNpZ25lZCBmb3IgdHJhbnNtaXNzaW9uIG92ZXIgYQ0KPiA+IGxvd2VyIGxheWVy IHRoYXQgZG9lcyBub3QgcHJvdmlkZSBhIHBhY2tldCBpbnRlZ3JpdHkgZ3VhcmFudGVlLCBpdCBp cw0KPiA+IFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGFzIHdlbGwuIE90aGVyd2lzZSwg dXNpbmcgemVybyBjaGVja3N1bQ0KPiA+IGlzIE5PVCBSRUNPTU1FTkRFRC4gTm90ZSB0aGF0IG90 aGVyIElQIGVuY2Fwc3VsYXRpb25zIGZvciBNUExTIGRvIG5vdA0KPiBoYXZlIGEgY2hlY2tzdW0g aW4gdGhlIHR1bm5lbCBoZWFkZXIuDQo+ID4gPg0KPiA+ID4gSWYgeW91IHN0aWxsIGJlbGlldmUg dGhlIGFib3ZlIHRleHQgaXMgbm90IHNhdGlzZmFjdG9yeSwgcGxlYXNlIHByb3ZpZGUgeW91ciB0 ZXh0Lg0KPiA+ID4NCj4gPiA+IEJlc3QgcmVnYXJkcywNCj4gPiA+IFhpYW9odQ0KPiA+ID4NCj4g PiA+ID4gTGxveWQgV29vZA0KPiA+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4g PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRnJv bTogbXBscyBbbXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNCj4g PiA+ID4gW3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiA+IFNlbnQ6IDIzIEphbnVhcnkgMjAx NCAwMzoxNg0KPiA+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IEVnZ2VydCwgTGFycw0K PiA+ID4gPiBDYzogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6 IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0K PiA+ID4gPg0KPiA+ID4gPiBIaQ0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0t LQ0KPiA+ID4gPiA+ILeivP7IyzogQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4gPiA+ID4gPiBbbWFp bHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ID4gPiA+ILeiy83Ksbzk OiAyMDE0xOox1MIyMsjVIDE5OjA1DQo+ID4gPiA+ID4gytW8/sjLOiBFZ2dlcnQsIExhcnMNCj4g PiA+ID4gPiCzrcvNOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1DQo+ID4g PiA+ID4g1vfM4jogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRw LTA0LnR4dD4NCj4gPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9z ZWQgU3RhbmRhcmQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IExhcnMgYW5kIGFsbCwNCj4gPiA+ID4g PiBMYXN0IHRpbWUgSSd2ZSBjb3VudGVkIHRoZSBJRVRGIExDIHRocmVhZCBvbiB0aGlzIGRyYWZ0 IGhhcyBtb3JlDQo+ID4gPiA+ID4gdGhhbg0KPiA+ID4gPiA+IDE1MCBtZXNzYWdlcyBpbiBpdCwg YW5kIGl0IHNlZW1zIHRoYXQgb24gc29tZSBpc3N1ZXMgKGNvbmdlc3Rpb24NCj4gPiA+ID4gPiBj b250cm9sIGFuZCBVRFANCj4gPiA+ID4gPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyByb3VuZCB0 aGUgbXVsYmVycnkgYnVzaC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IElNSE8gYW5kIEZXSVc6DQo+ ID4gPiA+ID4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3Vl IGJlY2F1c2UgbmF0aXZlDQo+ID4gPiA+ID4gTVBMUyBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIGxp a2UgdGhhdC4gQW5kIHllcywgdGhlcmUgYXJlIGNhc2VzDQo+ID4gPiA+ID4gd2hlcmUgcGFja2V0 cyBhcmUgY29ycnVwdGVkIHdpdGhpbiB0aGUgcm91dGVycyksIGJ1dCBzbyBmYXIgaXQNCj4gPiA+ ID4gPiBkaWQgbm90IHByZXZlbnQgTVBMUyBkZXBsb3ltZW50LiBUaGVyZSBpcywgZS5nLiwgUkZD IDQ3MjAgZm9yDQo+ID4gPiA+ID4gRkNTIHJldGVudGlvbiBpbiBQV3MsIGJ1dCBJIGRvdWJ0IGl0 IGlzIHdpZGVseSBpbXBsZW1lbnRlZCBhbmQNCj4gPiA+ID4gPiBkZXBsb3llZCAod291bGQgYmUg bmljZSB0bw0KPiA+ID4gPiBrbm93KS4NCj4gPiA+ID4gPiAtIEUyRSBjb25nZXN0aW9uIGNvbnRy b2wgKHJlZ2FyZGxlc3Mgb2YgaXRzIGltcGxpY2F0aW9ucykgc2ltcGx5DQo+ID4gPiA+ID4gY2Fu bm90IGJlIGFkZGVkIHRvIHRoaXMgcHJvdG9jb2wgd2l0aG91dCBzb21lIG1ham9yIGNoYW5nZXMu IEENCj4gPiA+ID4gPiBzaG9ydCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBleHBsYWluaW5nIHRo YXQgc2hvdWxkIHN1ZmZpY2UgSU1PLg0KPiA+ID4gPg0KPiA+ID4gPiBIaSBTYXNoYSwNCj4gPiA+ ID4NCj4gPiA+ID4gSSBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnRzLg0KPiA+ID4gPg0KPiA+ ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPg0KPiA+ID4gPiA+IE15 IDJjLA0KPiA+ID4gPiA+ICAgICAgICBTYXNoYQ0KPiA+ID4gPiA+IEVtYWlsOiBBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPiA+ID4gPiA+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g PiA+IEZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBFZ2dlcnQsDQo+ID4gPiA+ID4gPiBMYXJzDQo+ID4gPiA+ID4gPiBTZW50OiBXZWRuZXNkYXks IEphbnVhcnkgMjIsIDIwMTQgMTI6MjMgUE0NCj4gPiA+ID4gPiA+IFRvOiBYdXhpYW9odQ0KPiA+ ID4gPiA+ID4gQ2M6IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gU3Vi amVjdDogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4 dD4NCj4gPiA+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBT dGFuZGFyZA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhpLA0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IE9uIDIwMTQtMS0yMiwgYXQgMTE6MTIsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWku Y29tPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gSSB3b25kZXIgd2hldGhlciB0aGUgZm9sbG93aW5n IHRleHQgaXMgT0sgdG8geW91Og0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBTaW5jZSB0 aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiBjYXVzZXMgTVBMUyBwYWNrZXRzIHRvDQo+ID4g PiA+ID4gPiA+IGJlDQo+ID4gPiA+ID4gPiBmb3J3YXJkZWQgdGhyb3VnaCAiVURQIHR1bm5lbHMi LCB0aGUgY29uZ2VzdGlvbiBjb250cm9sDQo+ID4gPiA+ID4gPiBndWlkZWxpbmVzIGZvciBVRFAg dHVubmVscyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjMgb2YNCj4gPiA+ID4gPiA+IFtSRkM1 NDA1XSBTSE9VTEQgYmUNCj4gPiA+ID4gZm9sbG93ZWQuDQo+ID4gPiA+ID4gPiBTcGVjaWZpY2Fs bHksIE1QTFMgY2FuIGNhcnJ5IGEgbnVtYmVyIG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMNCj4g cGF5bG9hZHMuDQo+ID4gPiA+ID4gPiBXaGVuIGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBM UyBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcw0KPiA+ID4gPiA+ID4ga25vd24gYXQgY29uZmlndXJh dGlvbiB0aW1lIHRvIGJlIElQLWJhc2VkIGFuZA0KPiA+ID4gPiA+ID4gY29uZ2VzdGlvbi1jb250 cm9sbGVkLCB0aGUgVURQIHR1bm5lbCBTSE9VTEQgTk9UIGVtcGxveSBpdHMNCj4gPiA+ID4gPiA+ IG93biBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLCBiZWNhdXNlIGNvbmdlc3Rpb24gbG9z c2VzIG9mDQo+ID4gPiA+ID4gPiB0dW5uZWxlZCB0cmFmZmljIHdpbGwgdHJpZ2dlciBhbiBjb25n ZXN0aW9uIHJlc3BvbnNlIGF0IHRoZQ0KPiA+ID4gPiA+ID4gb3JpZ2luYWwNCj4gPiBzZW5kZXJz IG9mIHRoZSB0dW5uZWxlZCB0cmFmZmljLg0KPiA+ID4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVs IGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFmZmljIHRoYXQgaXMNCj4gPiA+ID4gPiA+IGtu b3duIGF0IGNvbmZpZ3VyYXRpb24gdGltZSBub3QgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+ ID4gPiBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFAgdHVubmVsIFNIT1VMRCBlbXBsb3kg YW4NCj4gPiA+ID4gPiA+IGFwcHJvcHJpYXRlIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20g YXMgZGVzY3JpYmVkIGluDQo+ID4gPiA+ID4gPiBbUkZDMzk4NV0uIE5vdGUgdGhhdCBpdCBTVFJP TkdMWSBSRUNPTU1FTkRFRCB0byBkZXBsb3kgc3VjaA0KPiA+ID4gPiA+ID4gZW5jYXBzdWxhdGlv biB0ZWNobm9sb2d5IG9ubHkgd2l0aGluIGEgU1AgbmV0d29yayBvciBuZXR3b3Jrcw0KPiA+ID4g PiA+ID4gb2YgYW4gYWRqYWNlbnQgc2V0IG9mIGNvLW9wZXJhdGluZyBTUHMsIHJhdGhlciB0aGFu IG92ZXIgdGhlDQo+ID4gPiA+IEludGVybmV0Lg0KPiA+ID4gPiA+ID4gRnVydGhlcm1vcmUsIHBh Y2tldCBmaWx0ZXJzIHNob3VsZCBiZSBhZGRlZCB0byBibG9jayB0cmFmZmljDQo+ID4gPiA+ID4g PiB3aXRoIHRoZSBVRFAgcG9ydCBudW1iZXIgZm9yIE1QTFMgb3ZlciBVRFAgdG8gcHJldmVudCBN UExTDQo+ID4gPiA+ID4gPiBvdmVyIFVEUCBwYWNrZXRzIHRvIGVzY2FwZSBmcm9tIHRoZSBzZXJ2 aWNlIHByb3ZpZGVyIG5ldHdvcmtzDQo+ID4gPiA+ID4gPiBkdWUgdG8gbWlzY29uZmlndWF0aW9u IG9yIHBhY2tldA0KPiA+ID4gPiA+IGVycm9ycy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJ IHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBkZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wgbG9v cCBpbg0KPiA+ID4gPiA+ID4gKHNvbWUpIG1vcmUgZGV0YWlsLCByYXRoZXIgdGhhbiBwb2ludGlu ZyB0byBSRkMzOTg1LCB3aGljaA0KPiA+ID4gPiA+ID4gZG9lc24ndCBoYXZlIGEgd2hvbGUgbG90 IG9mIGRldGFpbCBlaXRoZXIuIEFsc28gYmVjYXVzZSB0aGUNCj4gPiA+ID4gPiA+IGFkZGluZyBv ZiBmaXJld2FsbCBydWxlcyByZXF1aXJlcyBhbiBPQU0gaG9vay4NCj4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiBTaW5jZSBTVFJPTkdMWSBSRUNPTU1FTkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJt IGFuZA0KPiA+ID4gPiA+IFJFQ09NTUVOREVEIGlzDQo+ID4gPiA+ID4gPiB0b28gd2VhaywgSSdk IHN1Z2dlc3QgdG8gY2hhbmdlIHRoaXMgdG8gTVVTVC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiBGaW5hbGx5LCB0aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgc2hvdWxkIGJlIHByb21pbmVu dGx5DQo+ID4gPiA+ID4gPiBtYWRlIGluIHRoZSBhYnN0cmFjdCwgaW50cm9kdWN0aW9uLCBldGMu DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gTGFycw0K From xuxiaohu@huawei.com Thu Jan 23 22:03:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2441A01BB for ; Thu, 23 Jan 2014 22:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 VkkAlyAui5L6 for ; Thu, 23 Jan 2014 22:02:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5025E1A01BA for ; Thu, 23 Jan 2014 22:02:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCW33184; Fri, 24 Jan 2014 06:02:56 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 06:02:26 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 06:02:30 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 14:02:25 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGLe0Vpx4VpP9lE+4fynfG27EApqTPtnwgAASPbeAABBtMA== Date: Fri, 24 Jan 2014 06:02:25 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082479BA@NKGEML512-MBS.china.huawei.com> References: Your message of "Thu, 23 Jan 2014 17:18:22 +0000." <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247954@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346ED@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346ED@EXMB01CMS.surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" , "lars@netapp.com" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 06:03:02 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBb bWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ILeiy83KsbzkOiAyMDE0xOox1MIyNMjVIDEz OjAxDQo+IMrVvP7IyzogWHV4aWFvaHU7IGN1cnRpc0BpcHY2Lm9jY25jLmNvbQ0KPiCzrcvNOiBB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tOyBqb2VsamFA Ym9ndXMuY29tOw0KPiBtcGxzQGlldGYub3JnDQo+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxs OiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMNCj4g aW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gSSB3b3VsZCBiZSBnb29kIHdpdGg6 DQo+IA0KPiAiR2VuZXJhbGx5IHNwZWFraW5nLCBhIFVEUCBjaGVja3N1bSBTSE9VTEQgYmUgdXNl ZC4gVGhlIGNvbnNpZGVyYXRpb25zDQo+IGRlc2NyaWJlZCBpbiBbUkZDNjkzNV0gW1JGQzY5MzZd IFNIT1VMRCBiZSBleGFtaW5lZCBpZiBVRFAgY2hlY2tzdW1zDQo+IG5lZWQgdG8gYmUgZGlzYWJs ZWQgZm9yIHBlcmZvcm1hbmNlIG9yIGltcGxlbWVudGF0aW9uIHJlYXNvbnMgZm9yIHRyYWZmaWMN Cj4gYWNyb3NzIHByaXZhdGUgbmV0d29ya3MuIFRoZSB1c2Ugb2YgYSB6ZXJvIFVEUCBjaGVja3N1 bSBpcyBOT1QNCj4gUkVDT01NRU5ERUQuIg0KPiANCj4gSSB3b3VsZG4ndCBtYWtlIHRoaXMgSVB2 NiBzcGVjaWZpYyAtIElQdjQgc3RpbGwgaGFzIHByb2JsZW1zIChVRFAgcG9ydCBkZW11eCksDQo+ IElQdjYncyBwcm9ibGVtcyBhcmUganVzdCB3b3JzZS4NCg0KSWYgbm90IElQdjYgc3BlY2lmaWMs IGl0IHNlZW1zIGNvbmZsaWN0IHdpdGggdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgcXVvdGVkIGZy b20gUkZDNjkzNjoNCg0KICAgVGhlIHVzZSBvZiBVRFAgd2l0aCBhIHplcm8gVURQIGNoZWNrc3Vt IGhhcyBtZXJpdHMgZm9yDQogICBzb21lIGFwcGxpY2F0aW9ucywgc3VjaCBhcyB0dW5uZWwgZW5j YXBzdWxhdGlvbiwgYW5kIGlzIHdpZGVseSB1c2VkDQogICBpbiBJUHY0LiAgSG93ZXZlciwgdGhl cmUgYXJlIGRpZmZlcmVudCBkYW5nZXJzIGZvciBJUHY2LiAgVGhlcmUgaXMgYW4NCiAgIGluY3Jl YXNlZCByaXNrIG9mIGNvcnJ1cHRpb24gYW5kIG1pc2RlbGl2ZXJ5IHdoZW4gdXNpbmcgemVybyBV RFANCiAgIGNoZWNrc3VtIGluIElQdjYgY29tcGFyZWQgdG8gdXNpbmcgSVB2NCBkdWUgdG8gdGhl IGxhY2sgb2YgYW4gSVB2Ng0KICAgaGVhZGVyIGNoZWNrc3VtLiAgDQoNClhpYW9odQ0KDQo+IExs b3lkIFdvb2QNCj4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3 ZWkuY29tXQ0KPiBTZW50OiAyNCBKYW51YXJ5IDIwMTQgMDQ6MDANCj4gVG86IGN1cnRpc0BpcHY2 Lm9jY25jLmNvbTsgV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpDQo+IENjOiBBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tOyBqb2VsamFAYm9ndXMuY29t Ow0KPiBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IHJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJh ZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMNCj4gaW4gVURQ KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gSGksDQo+IA0KPiBQbGVhc2UgY2hlY2sgd2hl dGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0suDQo+IA0KPiBJbiB0aGUgSVB2NiBVRFAgZW5j YXBzdWxhdGlvbiBjYXNlLCBhcyBmb3Igd2hldGhlciBvciBub3QgaXQgaXMgc3VpdGFibGUgdG8g dXNlIHRoZQ0KPiB6ZXJvLWNoZWNrc3VtIG5vZGUsIHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBp biBbUkZDNjkzNV0gW1JGQzY5MzZdDQo+IFNIT1VMRCBiZSBzdHJpY3RseSBmb2xsb3dlZC4gR2Vu ZXJhbGx5IHNwZWFraW5nLCB0aGUgdXNlIG9mIGEgemVybyBVRFANCj4gY2hlY2tzdW0gaXMgTk9U IFJFQ09NTUVOREVELiBOb3RlIHRoYXQgb3RoZXIgSVAgZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMN Cj4gZG8gbm90IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCj4gDQo+IEJl c3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IA0KPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ILei vP7IyzogQ3VydGlzIFZpbGxhbWl6YXIgW21haWx0bzpjdXJ0aXNAaXB2Ni5vY2NuYy5jb21dDQo+ ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjI0yNUgMTE6NTMNCj4gPiDK1bz+yMs6IGwud29vZEBzdXJy ZXkuYWMudWsNCj4gPiCzrcvNOiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb207IGxhcnNAbmV0YXBwLmNvbTsNCj4gPiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYu b3JnDQo+ID4g1vfM4jogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4t dWRwLTA0LnR4dD4NCj4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQg U3RhbmRhcmQNCj4gPg0KPiA+DQo+ID4gSW4gbWVzc2FnZQ0KPiA+DQo+IDwyOTBFMjBCNDU1QzY2 NzQzQkUxNzhDNUM4NEYxMjQwODQ3RTYzMzQ2RTNARVhNQjAxQ01TLnN1cnJleS5hDQo+ID4gYy51 az4NCj4gPiBsLndvb2RAc3VycmV5LmFjLnVrIHdyaXRlczoNCj4gPg0KPiA+ID4gdGhlIHRleHQg aXMgbm90IHNhdGlzZmFjdG9yeS4gbmV2ZXIgcmVjb21tZW5kIHNldHRpbmcgdG8gemVybywgYXMN Cj4gPiA+IHRoYXQgcG9zZXMgYSByaXNrIHRvIHlvdXIgYW5kIHRvIG90aGVyIHRyYWZmaWMuIFN1 Z2dlc3RlZCB0ZXh0Og0KPiA+ID4gKioqDQo+ID4gPiBUaGUgVURQIGNoZWNrc3VtIFNIT1VMRCBi ZSB1c2VkIHRvIHByb3RlY3QgdGhlIHBheWxvYWQgYW5kIGVuc3VyZQ0KPiA+ID4gY29ycmVjdCBk ZW11bHRpcGxleGluZyBhbmQgZGVsaXZlcnkgdG8gdGhlIHR1bm5lbCwgYW5kIG5vdCB0byBvdGhl cg0KPiA+ID4gVURQIGRlc3RpbmF0aW9ucywgYnkgcHJvdGVjdGluZyB0aGUgVURQIHBzZXVkb2hl YWRlci4NCj4gPiA+IFVzZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzIE5PVCBSRUNPTU1FTkRF RCwgZXZlbiB3aGVuIGRlc2lyZWQgZm9yDQo+ID4gPiBwZXJmb3JtYW5jZSBvciBuZWNlc3NpdGF0 ZWQgYnkgaW1wbGVtZW50YXRpb24gcmVhc29ucywgZm9yIHRoZQ0KPiA+ID4gcmVhc29ucyBvdXRs aW5lZCBpbiBbUkZDNjkzNl0gc2VjdGlvbiAzLg0KPiA+DQo+ID4gSSBhZ3JlZSB0aGF0IFVEUCBj aGVja3N1bXMgU0hPVUxEIGJlIHVzZWQgKGllOiBTSE9VTEQgTk9UIGJlIHNldCB0byB6ZXJvKS4N Cj4gPiBUaGVyZSBhcmUgY2FzZXMgd2hlcmUgaXQgaXMgaW1wb3NzaWJsZSBzbyBpdCBjYW4ndCBi ZSBNVVNULg0KPiA+DQo+ID4gPiBVRFAtTGl0ZSBbUkZDMzgyOF0gY2FuIHByb3ZpZGUgYSBkZW11 bHRpcGxleGluZyBjaGVjayBhbmQgTVBMUyBzdGFjaw0KPiA+ID4gaW50ZWdyaXR5IGNoZWNrIHdo aWxlIGF2b2lkaW5nIHRoZSBvdmVyaGVhZCBvZiBjb21wdXRpbmcgYW4NCj4gPiA+IGludGVncml0 eSBjaGVjayBvdmVyIGEgdHVubmVsbGVkIGZyYW1lIHRoYXQgaGFzIGl0cyBvd24gaW50ZWdyaXR5 IGNoZWNrLg0KPiA+DQo+ID4gVURQLUxpc3QgZG9lc24ndCBzb2x2ZSB0aGUgRUNNUCBwcm9ibGVt cyBiZWNhdXNlIG1vc3Qgb2YgdGhlIG9sZGVyIExTUg0KPiA+IHRoYXQgYXJlIGZvcmNpbmcgdGhl IHVzZSBvZiBNUExTIG92ZXIgVURQIHRvIGdldCBFQ01QIGRvbid0IGxvb2sgYXQNCj4gPiB0aGUg cG9ydCBudW1iZXJzIGlmIHRoZSBwcm90b2NvbCBpcyBub3QgNiBvciAxNy4gIEJ1dCB0aGlzIGhh cyBvbmx5DQo+ID4gYmVlbiBzYWlkIHRocmVlIG9yIGZvdXIgdGltZXMgc28gbWF5YmUgeW91IG1p c3NlZCBpdC4NCj4gPg0KPiA+ID4gKioqDQo+ID4gPg0KPiA+ID4gTGxveWQgV29vZA0KPiA+ID4g aHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gRnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5j b21dDQo+ID4gPiBTZW50OiAyMyBKYW51YXJ5IDIwMTQgMTI6MzUNCj4gPiA+IFRvOiBXb29kIEwg IERyIChFbGVjdHJvbmljIEVuZyk7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0K PiA+ID4gbGFyc0BuZXRhcHAuY29tDQo+ID4gPiBDYzogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0Bp ZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRm LW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0 byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ ID4gPiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXku YWMudWtdDQo+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyM8jVIDEyOjQ0DQo+ID4gPiA+IMrV vP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5l dGFwcC5jb20NCj4gPiA+ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0K PiA+ID4gPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11 ZHAtMDQudHh0Pg0KPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9z ZWQgU3RhbmRhcmQNCj4gPiA+ID4NCj4gPiA+ID4gU2FzaGENCj4gPiA+ID4NCj4gPiA+ID4gPiAt IFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhlcmVvZikgaXMgYSBub24taXNzdWUgYmVjYXVzZSBu YXRpdmUNCj4gPiA+ID4gPiBNUExTIGRvZXMgbm90IGhhdmUgYW55dGhpbmcgbGlrZSB0aGF0LiBB bmQgeWVzLCB0aGVyZSBhcmUgY2FzZXMNCj4gPiA+ID4gPiB3aGVyZSBwYWNrZXRzIGFyZSBjb3Jy dXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKQ0KPiA+ID4gPg0KPiA+ID4gPiBTbyB5b3UgYWRtaXQg dGhhdCBwYWNrZXRzIGNhbiBiZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzIC0gYQ0KPiA+ ID4gPiBjaGVjayB0aGF0IGNhbiBvbmx5IGJlIGNhdWdodCBieSBhbiBlbmQtdG8tZW5kIGNoZWNr LCBhIGNvcnJ1cHRpb24NCj4gPiA+ID4gdGhhdCBjYW4gbGVhZCB0byB0aGUgcHJvYmxlbXMgZGV0 YWlsZWQgaW4gUkZDIDY5MzYgc2VjdGlvbiAzIC0gYW5kDQo+ID4gPiA+IHRoZW4geW91IHNheSBp dCdzIGEgbm9uLWlzc3VlIGJlY2F1c2UgdGhpcyBkb2Vzbid0IGFmZmVjdCBuYXRpdmUNCj4gPiA+ ID4gTVBMUy4gQnV0DQo+ID4gd2UncmUgbm90IGRvaW5nIG5hdGl2ZSBNUExTIGhlcmUuDQo+ID4g PiA+IFdlJ3JlIGRvaW5nIE1QTFMgb3ZlciBVRFAuDQo+ID4gPiA+DQo+ID4gPiA+IGRyYWZ0LWll dGYtbXBscy1pbi11ZHAtMDQudHh0IGlzIGFib3V0IHR1bm5lbGxpbmcgTVBMUyBpbiBVRFAuIEl0 J3MgYW4gaXNzdWUuDQo+ID4gPiA+IFBsZWFzZSByZWFkIHRoZSBvdGhlciAxNTAgbWVzc2FnZXMg dGhhdCB5b3UgcmVmZXIgdG8uDQo+ID4gPg0KPiA+ID4gSGkgTGxveWQsDQo+ID4gPg0KPiA+ID4g VGhlIGRyYWZ0IGRvZXNuJ3QgcmVxdWlyZSB0aGUgSVB2NiBVRFAgY2hlY2tzdW0gdG8gYmUgc2V0 IHRvIHplcm8NCj4gcmVnYXJkbGVzcy4NCj4gPiBTZWUgdGhlIGZvbGxvd2luZyB0ZXh0IHF1b3Rl ZCBmcm9tIHRoYXQgZHJhZnQ6DQo+ID4gPg0KPiA+ID4gVURQIENoZWNrc3VtDQo+ID4gPg0KPiA+ ID4gVGhlIHVzYWdlIG9mIHRoaXMgZmllbGQgaXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBjdXJy ZW50IFVEUA0KPiA+ID4gc3BlY2lmaWNhdGlvbg0KPiA+IFtSRkM3NjhdLiBUbyBzaW1wbGlmeSB0 aGUgb3BlcmF0aW9uIG9uIHRoZSBkZWNhcHN1bGF0b3IsIHRoaXMgZmllbGQgaXMNCj4gPiBSRUNP TU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyBpbiBJUHY0IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2Uu IEluIHRoZQ0KPiA+IElQdjYgVURQIGVuY2Fwc3VsYXRpb24gY2FzZSwgaWYgYXBwcm9wcmlhdGUg YWNjb3JkaW5nIHRvIHRoZQ0KPiA+IHJlcXVpcmVtZW50cyBkZWZpbmVkIGluIFtSRkM2OTM1XSBb UkZDNjkzNl0sIHRoaXMgZmllbGQgaXMgYWxzbw0KPiBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8g emVyby4NCj4gPiBTcGVjaWZpY2FsbHksIGlmIHRoZSBNUExTIHBheWxvYWQgaXMgSW50ZXJuZXQg UHJvdG9jb2wgKElQdjQgb3IgSVB2NikNCj4gPiBwYWNrZXRzLCBpdCBpcyBSRUNPTU1FTkRFRCB0 byBiZSBzZXQgdG8gemVybyB3aGVuIHRoZSBpbm5lciBwYWNrZXQNCj4gPiBpbnRlZ3JpdHkgY2hl Y2tzIGlzIGF2YWlsYWJsZS4gSW4gYWRkaXRpb24sIGlmIHRoZSBNUExTIHBheWxvYWQgaXMNCj4g PiBub24tSVAgcGFja2V0IHdoaWNoIGlzIHNwZWNpZmljYWxseSBkZXNpZ25lZCBmb3IgdHJhbnNt aXNzaW9uIG92ZXIgYQ0KPiA+IGxvd2VyIGxheWVyIHRoYXQgZG9lcyBub3QgcHJvdmlkZSBhIHBh Y2tldCBpbnRlZ3JpdHkgZ3VhcmFudGVlLCBpdCBpcw0KPiA+IFJFQ09NTUVOREVEIHRvIGJlIHNl dCB0byB6ZXJvIGFzIHdlbGwuIE90aGVyd2lzZSwgdXNpbmcgemVybyBjaGVja3N1bQ0KPiA+IGlz IE5PVCBSRUNPTU1FTkRFRC4gTm90ZSB0aGF0IG90aGVyIElQIGVuY2Fwc3VsYXRpb25zIGZvciBN UExTIGRvIG5vdA0KPiBoYXZlIGEgY2hlY2tzdW0gaW4gdGhlIHR1bm5lbCBoZWFkZXIuDQo+ID4g Pg0KPiA+ID4gSWYgeW91IHN0aWxsIGJlbGlldmUgdGhlIGFib3ZlIHRleHQgaXMgbm90IHNhdGlz ZmFjdG9yeSwgcGxlYXNlIHByb3ZpZGUgeW91ciB0ZXh0Lg0KPiA+ID4NCj4gPiA+IEJlc3QgcmVn YXJkcywNCj4gPiA+IFhpYW9odQ0KPiA+ID4NCj4gPiA+ID4gTGxveWQgV29vZA0KPiA+ID4gPiBo dHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRnJvbTogbXBscyBbbXBscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNCj4gPiA+ID4gW3h1eGlhb2h1QGh1YXdlaS5jb21d DQo+ID4gPiA+IFNlbnQ6IDIzIEphbnVhcnkgMjAxNCAwMzoxNg0KPiA+ID4gPiBUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW47IEVnZ2VydCwgTGFycw0KPiA+ID4gPiBDYzogSm9lbCBKYWVnZ2xpOyBt cGxzQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJh ZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMg aW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPg0KPiA+ID4gPiBIaQ0KPiA+ID4g Pg0KPiA+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ID4gPiA+ILeivP7IyzogQWxleGFu ZGVyIFZhaW5zaHRlaW4NCj4gPiA+ID4gPiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tXQ0KPiA+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyMsjVIDE5OjA1DQo+ID4g PiA+ID4gytW8/sjLOiBFZ2dlcnQsIExhcnMNCj4gPiA+ID4gPiCzrcvNOiBKb2VsIEphZWdnbGk7 IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1DQo+ID4gPiA+ID4g1vfM4jogUkU6IFttcGxzXSBMYXN0 IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiAoRW5jYXBz dWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IExhcnMgYW5kIGFsbCwNCj4gPiA+ID4gPiBMYXN0IHRpbWUgSSd2ZSBjb3VudGVkIHRo ZSBJRVRGIExDIHRocmVhZCBvbiB0aGlzIGRyYWZ0IGhhcyBtb3JlDQo+ID4gPiA+ID4gdGhhbg0K PiA+ID4gPiA+IDE1MCBtZXNzYWdlcyBpbiBpdCwgYW5kIGl0IHNlZW1zIHRoYXQgb24gc29tZSBp c3N1ZXMgKGNvbmdlc3Rpb24NCj4gPiA+ID4gPiBjb250cm9sIGFuZCBVRFANCj4gPiA+ID4gPiBj aGVja3N1bXMpIHdlIGFyZSBnb2luZyByb3VuZCB0aGUgbXVsYmVycnkgYnVzaC4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IElNSE8gYW5kIEZXSVc6DQo+ID4gPiA+ID4gLSBVRFAgY2hlY2tzdW1zIChv ciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJlY2F1c2UgbmF0aXZlDQo+ID4gPiA+ID4g TVBMUyBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIGxpa2UgdGhhdC4gQW5kIHllcywgdGhlcmUgYXJl IGNhc2VzDQo+ID4gPiA+ID4gd2hlcmUgcGFja2V0cyBhcmUgY29ycnVwdGVkIHdpdGhpbiB0aGUg cm91dGVycyksIGJ1dCBzbyBmYXIgaXQNCj4gPiA+ID4gPiBkaWQgbm90IHByZXZlbnQgTVBMUyBk ZXBsb3ltZW50LiBUaGVyZSBpcywgZS5nLiwgUkZDIDQ3MjAgZm9yDQo+ID4gPiA+ID4gRkNTIHJl dGVudGlvbiBpbiBQV3MsIGJ1dCBJIGRvdWJ0IGl0IGlzIHdpZGVseSBpbXBsZW1lbnRlZCBhbmQN Cj4gPiA+ID4gPiBkZXBsb3llZCAod291bGQgYmUgbmljZSB0bw0KPiA+ID4gPiBrbm93KS4NCj4g PiA+ID4gPiAtIEUyRSBjb25nZXN0aW9uIGNvbnRyb2wgKHJlZ2FyZGxlc3Mgb2YgaXRzIGltcGxp Y2F0aW9ucykgc2ltcGx5DQo+ID4gPiA+ID4gY2Fubm90IGJlIGFkZGVkIHRvIHRoaXMgcHJvdG9j b2wgd2l0aG91dCBzb21lIG1ham9yIGNoYW5nZXMuIEENCj4gPiA+ID4gPiBzaG9ydCBhcHBsaWNh YmlsaXR5IHN0YXRlbWVudCBleHBsYWluaW5nIHRoYXQgc2hvdWxkIHN1ZmZpY2UgSU1PLg0KPiA+ ID4gPg0KPiA+ID4gPiBIaSBTYXNoYSwNCj4gPiA+ID4NCj4gPiA+ID4gSSBmdWxseSBhZ3JlZSB3 aXRoIHlvdXIgcG9pbnRzLg0KPiA+ID4gPg0KPiA+ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiA+ IFhpYW9odQ0KPiA+ID4gPg0KPiA+ID4gPiA+IE15IDJjLA0KPiA+ID4gPiA+ICAgICAgICBTYXNo YQ0KPiA+ID4gPiA+IEVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPiA+ ID4gPiA+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+IEZyb206IG1wbHMgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFZ2dlcnQsDQo+ID4gPiA+ID4gPiBMYXJz DQo+ID4gPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjIsIDIwMTQgMTI6MjMgUE0N Cj4gPiA+ID4gPiA+IFRvOiBYdXhpYW9odQ0KPiA+ID4gPiA+ID4gQ2M6IEpvZWwgSmFlZ2dsaTsg bXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBMYXN0IENhbGw6 IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiA+IChFbmNhcHN1bGF0 aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IEhpLA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE9uIDIwMTQtMS0yMiwgYXQgMTE6 MTIsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4g SSB3b25kZXIgd2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0sgdG8geW91Og0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBTaW5jZSB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlv biBjYXVzZXMgTVBMUyBwYWNrZXRzIHRvDQo+ID4gPiA+ID4gPiA+IGJlDQo+ID4gPiA+ID4gPiBm b3J3YXJkZWQgdGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250cm9sDQo+ ID4gPiA+ID4gPiBndWlkZWxpbmVzIGZvciBVRFAgdHVubmVscyBhcyBkZWZpbmVkIGluIFNlY3Rp b24gMy4xLjMgb2YNCj4gPiA+ID4gPiA+IFtSRkM1NDA1XSBTSE9VTEQgYmUNCj4gPiA+ID4gZm9s bG93ZWQuDQo+ID4gPiA+ID4gPiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5IGEgbnVtYmVy IG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMNCj4gcGF5bG9hZHMuDQo+ID4gPiA+ID4gPiBXaGVu IGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcw0K PiA+ID4gPiA+ID4ga25vd24gYXQgY29uZmlndXJhdGlvbiB0aW1lIHRvIGJlIElQLWJhc2VkIGFu ZA0KPiA+ID4gPiA+ID4gY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUgVURQIHR1bm5lbCBTSE9V TEQgTk9UIGVtcGxveSBpdHMNCj4gPiA+ID4gPiA+IG93biBjb25nZXN0aW9uIGNvbnRyb2wgbWVj aGFuaXNtLCBiZWNhdXNlIGNvbmdlc3Rpb24gbG9zc2VzIG9mDQo+ID4gPiA+ID4gPiB0dW5uZWxl ZCB0cmFmZmljIHdpbGwgdHJpZ2dlciBhbiBjb25nZXN0aW9uIHJlc3BvbnNlIGF0IHRoZQ0KPiA+ ID4gPiA+ID4gb3JpZ2luYWwNCj4gPiBzZW5kZXJzIG9mIHRoZSB0dW5uZWxlZCB0cmFmZmljLg0K PiA+ID4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0 cmFmZmljIHRoYXQgaXMNCj4gPiA+ID4gPiA+IGtub3duIGF0IGNvbmZpZ3VyYXRpb24gdGltZSBu b3QgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gPiBjb25nZXN0aW9uLWNvbnRyb2xsZWQs IHRoZSBVRFAgdHVubmVsIFNIT1VMRCBlbXBsb3kgYW4NCj4gPiA+ID4gPiA+IGFwcHJvcHJpYXRl IGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluDQo+ID4gPiA+ID4g PiBbUkZDMzk4NV0uIE5vdGUgdGhhdCBpdCBTVFJPTkdMWSBSRUNPTU1FTkRFRCB0byBkZXBsb3kg c3VjaA0KPiA+ID4gPiA+ID4gZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IG9ubHkgd2l0aGluIGEg U1AgbmV0d29yayBvciBuZXR3b3Jrcw0KPiA+ID4gPiA+ID4gb2YgYW4gYWRqYWNlbnQgc2V0IG9m IGNvLW9wZXJhdGluZyBTUHMsIHJhdGhlciB0aGFuIG92ZXIgdGhlDQo+ID4gPiA+IEludGVybmV0 Lg0KPiA+ID4gPiA+ID4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3VsZCBiZSBhZGRl ZCB0byBibG9jayB0cmFmZmljDQo+ID4gPiA+ID4gPiB3aXRoIHRoZSBVRFAgcG9ydCBudW1iZXIg Zm9yIE1QTFMgb3ZlciBVRFAgdG8gcHJldmVudCBNUExTDQo+ID4gPiA+ID4gPiBvdmVyIFVEUCBw YWNrZXRzIHRvIGVzY2FwZSBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmtzDQo+ID4g PiA+ID4gPiBkdWUgdG8gbWlzY29uZmlndWF0aW9uIG9yIHBhY2tldA0KPiA+ID4gPiA+IGVycm9y cy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0 byBkZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wgbG9vcCBpbg0KPiA+ID4gPiA+ID4gKHNvbWUpIG1v cmUgZGV0YWlsLCByYXRoZXIgdGhhbiBwb2ludGluZyB0byBSRkMzOTg1LCB3aGljaA0KPiA+ID4g PiA+ID4gZG9lc24ndCBoYXZlIGEgd2hvbGUgbG90IG9mIGRldGFpbCBlaXRoZXIuIEFsc28gYmVj YXVzZSB0aGUNCj4gPiA+ID4gPiA+IGFkZGluZyBvZiBmaXJld2FsbCBydWxlcyByZXF1aXJlcyBh biBPQU0gaG9vay4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTaW5jZSBTVFJPTkdMWSBSRUNP TU1FTkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJtIGFuZA0KPiA+ID4gPiA+IFJFQ09NTUVOREVE IGlzDQo+ID4gPiA+ID4gPiB0b28gd2VhaywgSSdkIHN1Z2dlc3QgdG8gY2hhbmdlIHRoaXMgdG8g TVVTVC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBGaW5hbGx5LCB0aGUgYXBwbGljYWJpbGl0 eSBzdGF0ZW1lbnQgc2hvdWxkIGJlIHByb21pbmVudGx5DQo+ID4gPiA+ID4gPiBtYWRlIGluIHRo ZSBhYnN0cmFjdCwgaW50cm9kdWN0aW9uLCBldGMuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g TGFycw0K From l.wood@surrey.ac.uk Thu Jan 23 22:11:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106DC1A020D for ; Thu, 23 Jan 2014 22:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, 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 UcD-yAkdoMmW for ; Thu, 23 Jan 2014 22:11:16 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.105]) by ietfa.amsl.com (Postfix) with ESMTP id 654681A0208 for ; Thu, 23 Jan 2014 22:11:15 -0800 (PST) Received: from [193.109.255.147:9482] by server-1.bemta-14.messagelabs.com id 53/07-15600-10402E25; Fri, 24 Jan 2014 06:11:13 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-72.messagelabs.com!1390543872!14550834!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24602 invoked from network); 24 Jan 2014 06:11:12 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-14.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jan 2014 06:11:12 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Fri, 24 Jan 2014 06:11:11 +0000 From: To: , Date: Fri, 24 Jan 2014 06:11:11 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGLe0Vpx4VpP9lE+4fynfG27EApqTPtnwgAASPbeAABBtMIAAAYC7 Message-ID: <290E20B455C66743BE178C5C84F1240847E63346EF@EXMB01CMS.surrey.ac.uk> References: Your message of "Thu, 23 Jan 2014 17:18:22 +0000." <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247954@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346ED@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082479BA@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082479BA@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 06:11:21 -0000 VGhleSdyZSBub3QgaW4gY29uZmxpY3QuDQoNCkluIElQdjQsIHlvdSBoYXZlIHRoZSBJUCBoZWFk ZXIgY2hlY2tzdW0gYXMgYSBjaGVjayB0aGF0IHRoZQ0KZGVzdGluYXRpb24gYWRkcmVzcyBpcyBy aWdodC4gV2l0aCBhIHplcm8gVURQIGNoZWNrc3VtLCB0aGUgcG9ydHMgYXJlbid0IGNoZWNrZWQg LSBidXQgDQppZiB5b3VyIHR1bm5lbCBkZXN0aW5hdGlvbiBob3N0IGlzbid0IHJ1bm5pbmcgb3Ro ZXIgVURQIGFwcHMsIGxpbWl0ZWQgcHJvYmxlbQ0KDQpXaXRoIElQdjYgYW5kIG5vIGhlYWRlciBj aGVja3N1bSwgYWRkcmVzcyBjYW4gYmUgY29ycnVwdGVkIGFzIHdlbGwuDQpUaGUgcGFja2V0IGNh biBiZSByZWNlaXZlZCBvbiBvdGhlciBob3N0cyB3aGljaCBjYW4gcnVuIFVEUC4NCg0KVGhhdCBp cyB3aHkgdGhlIHRleHQgeW91IHF1b3RlIHNheXM6DQogICJUaGVyZSBpcyBhbiAgaW5jcmVhc2Vk IHJpc2sgb2YgY29ycnVwdGlvbiBhbmQgbWlzZGVsaXZlcnkgd2hlbiB1c2luZyB6ZXJvIFVEUA0K ICAgY2hlY2tzdW0gaW4gSVB2NiBjb21wYXJlZCB0byB1c2luZyBJUHY0Ig0KDQpJUHY0IHJpc2sg aXMgc21hbGxlciwgYnV0IG5vdCBub256ZXJvLiBUdXJuaW5nIG9mZiBVRFAgY2hlY2tzdW1zIGlu IHY0DQppcyBhZ2FpbiBmb3IgY29udmVuaWVuY2UsIGFuZCBoYXMgYmVlbiBtb3JlIGNvbW1vbiAo d2l0aCBsb3ZlbHkNCmV4YW1wbGVzIGdpdmluZyBwZXJmb3JtYW5jZSBnYWlucyB0aGF0IGNvcnJ1 cHQgZGF0YWJhc2UgdHJhbnNhY3Rpb25zKSwNCmJ1dCB0aGVyZSBpcyBzdGlsbCByaXNrIGFzc29j aWF0ZWQgd2l0aCB0dXJuaW5nIG9mZiBJUHY0IFVEUCBjaGVja3N1bXMuDQoNCihBbmQgaW4gYm90 aCB2NCBhbmQgdjYsIGEgemVybyBjaGVja3N1bSBtZWFucyB0aGF0IGEgY2hlY2sgYWNyb3NzDQp0 aGUgTVBMUyBzdGFjayBpcyByZW1vdmVkLCBhbmQgY29ycnVwdGlvbiBpbiB0aGF0IGNhbm5vdCBi ZSBkZXRlY3RlZCkNCg0KTGxveWQgV29vZA0KaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogWHV4aWFvaHUgW3h1 eGlhb2h1QGh1YXdlaS5jb21dDQpTZW50OiAyNCBKYW51YXJ5IDIwMTQgMDY6MDINClRvOiBXb29k IEwgIERyIChFbGVjdHJvbmljIEVuZyk7IGN1cnRpc0BpcHY2Lm9jY25jLmNvbQ0KQ2M6IEFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5ldGFwcC5jb207IGpvZWxqYUBib2d1 cy5jb207IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IHJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJh ZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0 byBQcm9wb3NlZCBTdGFuZGFyZA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGwu d29vZEBzdXJyZXkuYWMudWsgW21haWx0bzpsLndvb2RAc3VycmV5LmFjLnVrXQ0KPiC3osvNyrG8 5DogMjAxNMTqMdTCMjTI1SAxMzowMQ0KPiDK1bz+yMs6IFh1eGlhb2h1OyBjdXJ0aXNAaXB2Ni5v Y2NuYy5jb20NCj4gs63LzTogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNA bmV0YXBwLmNvbTsgam9lbGphQGJvZ3VzLmNvbTsNCj4gbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBS RTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5j YXBzdWxhdGluZyBNUExTDQo+IGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4NCj4gSSB3 b3VsZCBiZSBnb29kIHdpdGg6DQo+DQo+ICJHZW5lcmFsbHkgc3BlYWtpbmcsIGEgVURQIGNoZWNr c3VtIFNIT1VMRCBiZSB1c2VkLiBUaGUgY29uc2lkZXJhdGlvbnMNCj4gZGVzY3JpYmVkIGluIFtS RkM2OTM1XSBbUkZDNjkzNl0gU0hPVUxEIGJlIGV4YW1pbmVkIGlmIFVEUCBjaGVja3N1bXMNCj4g bmVlZCB0byBiZSBkaXNhYmxlZCBmb3IgcGVyZm9ybWFuY2Ugb3IgaW1wbGVtZW50YXRpb24gcmVh c29ucyBmb3IgdHJhZmZpYw0KPiBhY3Jvc3MgcHJpdmF0ZSBuZXR3b3Jrcy4gVGhlIHVzZSBvZiBh IHplcm8gVURQIGNoZWNrc3VtIGlzIE5PVA0KPiBSRUNPTU1FTkRFRC4iDQo+DQo+IEkgd291bGRu J3QgbWFrZSB0aGlzIElQdjYgc3BlY2lmaWMgLSBJUHY0IHN0aWxsIGhhcyBwcm9ibGVtcyAoVURQ IHBvcnQgZGVtdXgpLA0KPiBJUHY2J3MgcHJvYmxlbXMgYXJlIGp1c3Qgd29yc2UuDQoNCklmIG5v dCBJUHY2IHNwZWNpZmljLCBpdCBzZWVtcyBjb25mbGljdCB3aXRoIHRoZSBmb2xsb3dpbmcgc3Rh dGVtZW50IHF1b3RlZCBmcm9tIFJGQzY5MzY6DQoNCiAgIFRoZSB1c2Ugb2YgVURQIHdpdGggYSB6 ZXJvIFVEUCBjaGVja3N1bSBoYXMgbWVyaXRzIGZvcg0KICAgc29tZSBhcHBsaWNhdGlvbnMsIHN1 Y2ggYXMgdHVubmVsIGVuY2Fwc3VsYXRpb24sIGFuZCBpcyB3aWRlbHkgdXNlZA0KICAgaW4gSVB2 NC4gIEhvd2V2ZXIsIHRoZXJlIGFyZSBkaWZmZXJlbnQgZGFuZ2VycyBmb3IgSVB2Ni4gIFRoZXJl IGlzIGFuDQogICBpbmNyZWFzZWQgcmlzayBvZiBjb3JydXB0aW9uIGFuZCBtaXNkZWxpdmVyeSB3 aGVuIHVzaW5nIHplcm8gVURQDQogICBjaGVja3N1bSBpbiBJUHY2IGNvbXBhcmVkIHRvIHVzaW5n IElQdjQgZHVlIHRvIHRoZSBsYWNrIG9mIGFuIElQdjYNCiAgIGhlYWRlciBjaGVja3N1bS4NCg0K WGlhb2h1DQoNCj4gTGxveWQgV29vZA0KPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogWHV4aWFvaHUg W3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+IFNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwNDowMA0KPiBU bzogY3VydGlzQGlwdjYub2NjbmMuY29tOyBXb29kIEwgIERyIChFbGVjdHJvbmljIEVuZykNCj4g Q2M6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5ldGFwcC5jb207IGpv ZWxqYUBib2d1cy5jb207DQo+IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogcmU6IFttcGxzXSBM YXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcg TVBMUw0KPiBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+DQo+IEhpLA0KPg0KPiBQbGVh c2UgY2hlY2sgd2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0suDQo+DQo+IEluIHRoZSBJ UHY2IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2UsIGFzIGZvciB3aGV0aGVyIG9yIG5vdCBpdCBpcyBz dWl0YWJsZSB0byB1c2UgdGhlDQo+IHplcm8tY2hlY2tzdW0gbm9kZSwgdGhlIHJlcXVpcmVtZW50 cyBkZWZpbmVkIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0NCj4gU0hPVUxEIGJlIHN0cmljdGx5IGZv bGxvd2VkLiBHZW5lcmFsbHkgc3BlYWtpbmcsIHRoZSB1c2Ugb2YgYSB6ZXJvIFVEUA0KPiBjaGVj a3N1bSBpcyBOT1QgUkVDT01NRU5ERUQuIE5vdGUgdGhhdCBvdGhlciBJUCBlbmNhcHN1bGF0aW9u cyBmb3IgTVBMUw0KPiBkbyBub3QgaGF2ZSBhIGNoZWNrc3VtIGluIHRoZSB0dW5uZWwgaGVhZGVy Lg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPg0KPiA+IC0tLS0t08q8/tStvP4tLS0t LQ0KPiA+ILeivP7IyzogQ3VydGlzIFZpbGxhbWl6YXIgW21haWx0bzpjdXJ0aXNAaXB2Ni5vY2Nu Yy5jb21dDQo+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjI0yNUgMTE6NTMNCj4gPiDK1bz+yMs6IGwu d29vZEBzdXJyZXkuYWMudWsNCj4gPiCzrcvNOiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBwLmNvbTsNCj4gPiBqb2VsamFAYm9ndXMuY29tOyBt cGxzQGlldGYub3JnDQo+ID4g1vfM4jogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRm LW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8g UHJvcG9zZWQgU3RhbmRhcmQNCj4gPg0KPiA+DQo+ID4gSW4gbWVzc2FnZQ0KPiA+DQo+IDwyOTBF MjBCNDU1QzY2NzQzQkUxNzhDNUM4NEYxMjQwODQ3RTYzMzQ2RTNARVhNQjAxQ01TLnN1cnJleS5h DQo+ID4gYy51az4NCj4gPiBsLndvb2RAc3VycmV5LmFjLnVrIHdyaXRlczoNCj4gPg0KPiA+ID4g dGhlIHRleHQgaXMgbm90IHNhdGlzZmFjdG9yeS4gbmV2ZXIgcmVjb21tZW5kIHNldHRpbmcgdG8g emVybywgYXMNCj4gPiA+IHRoYXQgcG9zZXMgYSByaXNrIHRvIHlvdXIgYW5kIHRvIG90aGVyIHRy YWZmaWMuIFN1Z2dlc3RlZCB0ZXh0Og0KPiA+ID4gKioqDQo+ID4gPiBUaGUgVURQIGNoZWNrc3Vt IFNIT1VMRCBiZSB1c2VkIHRvIHByb3RlY3QgdGhlIHBheWxvYWQgYW5kIGVuc3VyZQ0KPiA+ID4g Y29ycmVjdCBkZW11bHRpcGxleGluZyBhbmQgZGVsaXZlcnkgdG8gdGhlIHR1bm5lbCwgYW5kIG5v dCB0byBvdGhlcg0KPiA+ID4gVURQIGRlc3RpbmF0aW9ucywgYnkgcHJvdGVjdGluZyB0aGUgVURQ IHBzZXVkb2hlYWRlci4NCj4gPiA+IFVzZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzIE5PVCBS RUNPTU1FTkRFRCwgZXZlbiB3aGVuIGRlc2lyZWQgZm9yDQo+ID4gPiBwZXJmb3JtYW5jZSBvciBu ZWNlc3NpdGF0ZWQgYnkgaW1wbGVtZW50YXRpb24gcmVhc29ucywgZm9yIHRoZQ0KPiA+ID4gcmVh c29ucyBvdXRsaW5lZCBpbiBbUkZDNjkzNl0gc2VjdGlvbiAzLg0KPiA+DQo+ID4gSSBhZ3JlZSB0 aGF0IFVEUCBjaGVja3N1bXMgU0hPVUxEIGJlIHVzZWQgKGllOiBTSE9VTEQgTk9UIGJlIHNldCB0 byB6ZXJvKS4NCj4gPiBUaGVyZSBhcmUgY2FzZXMgd2hlcmUgaXQgaXMgaW1wb3NzaWJsZSBzbyBp dCBjYW4ndCBiZSBNVVNULg0KPiA+DQo+ID4gPiBVRFAtTGl0ZSBbUkZDMzgyOF0gY2FuIHByb3Zp ZGUgYSBkZW11bHRpcGxleGluZyBjaGVjayBhbmQgTVBMUyBzdGFjaw0KPiA+ID4gaW50ZWdyaXR5 IGNoZWNrIHdoaWxlIGF2b2lkaW5nIHRoZSBvdmVyaGVhZCBvZiBjb21wdXRpbmcgYW4NCj4gPiA+ IGludGVncml0eSBjaGVjayBvdmVyIGEgdHVubmVsbGVkIGZyYW1lIHRoYXQgaGFzIGl0cyBvd24g aW50ZWdyaXR5IGNoZWNrLg0KPiA+DQo+ID4gVURQLUxpc3QgZG9lc24ndCBzb2x2ZSB0aGUgRUNN UCBwcm9ibGVtcyBiZWNhdXNlIG1vc3Qgb2YgdGhlIG9sZGVyIExTUg0KPiA+IHRoYXQgYXJlIGZv cmNpbmcgdGhlIHVzZSBvZiBNUExTIG92ZXIgVURQIHRvIGdldCBFQ01QIGRvbid0IGxvb2sgYXQN Cj4gPiB0aGUgcG9ydCBudW1iZXJzIGlmIHRoZSBwcm90b2NvbCBpcyBub3QgNiBvciAxNy4gIEJ1 dCB0aGlzIGhhcyBvbmx5DQo+ID4gYmVlbiBzYWlkIHRocmVlIG9yIGZvdXIgdGltZXMgc28gbWF5 YmUgeW91IG1pc3NlZCBpdC4NCj4gPg0KPiA+ID4gKioqDQo+ID4gPg0KPiA+ID4gTGxveWQgV29v ZA0KPiA+ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiA+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1 QGh1YXdlaS5jb21dDQo+ID4gPiBTZW50OiAyMyBKYW51YXJ5IDIwMTQgMTI6MzUNCj4gPiA+IFRv OiBXb29kIEwgIERyIChFbGVjdHJvbmljIEVuZyk7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tOw0KPiA+ID4gbGFyc0BuZXRhcHAuY29tDQo+ID4gPiBDYzogam9lbGphQGJvZ3VzLmNv bTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxk cmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMg aW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+ID4gLS0tLS3Tyrz+1K28 /i0tLS0tDQo+ID4gPiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29v ZEBzdXJyZXkuYWMudWtdDQo+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyM8jVIDEyOjQ0DQo+ ID4gPiA+IMrVvP7IyzogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t OyBsYXJzQG5ldGFwcC5jb20NCj4gPiA+ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0Bp ZXRmLm9yZw0KPiA+ID4gPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYt bXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg dG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4NCj4gPiA+ID4gU2FzaGENCj4gPiA+ID4NCj4g PiA+ID4gPiAtIFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhlcmVvZikgaXMgYSBub24taXNzdWUg YmVjYXVzZSBuYXRpdmUNCj4gPiA+ID4gPiBNUExTIGRvZXMgbm90IGhhdmUgYW55dGhpbmcgbGlr ZSB0aGF0LiBBbmQgeWVzLCB0aGVyZSBhcmUgY2FzZXMNCj4gPiA+ID4gPiB3aGVyZSBwYWNrZXRz IGFyZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKQ0KPiA+ID4gPg0KPiA+ID4gPiBTbyB5 b3UgYWRtaXQgdGhhdCBwYWNrZXRzIGNhbiBiZSBjb3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJz IC0gYQ0KPiA+ID4gPiBjaGVjayB0aGF0IGNhbiBvbmx5IGJlIGNhdWdodCBieSBhbiBlbmQtdG8t ZW5kIGNoZWNrLCBhIGNvcnJ1cHRpb24NCj4gPiA+ID4gdGhhdCBjYW4gbGVhZCB0byB0aGUgcHJv YmxlbXMgZGV0YWlsZWQgaW4gUkZDIDY5MzYgc2VjdGlvbiAzIC0gYW5kDQo+ID4gPiA+IHRoZW4g eW91IHNheSBpdCdzIGEgbm9uLWlzc3VlIGJlY2F1c2UgdGhpcyBkb2Vzbid0IGFmZmVjdCBuYXRp dmUNCj4gPiA+ID4gTVBMUy4gQnV0DQo+ID4gd2UncmUgbm90IGRvaW5nIG5hdGl2ZSBNUExTIGhl cmUuDQo+ID4gPiA+IFdlJ3JlIGRvaW5nIE1QTFMgb3ZlciBVRFAuDQo+ID4gPiA+DQo+ID4gPiA+ IGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0IGlzIGFib3V0IHR1bm5lbGxpbmcgTVBMUyBp biBVRFAuIEl0J3MgYW4gaXNzdWUuDQo+ID4gPiA+IFBsZWFzZSByZWFkIHRoZSBvdGhlciAxNTAg bWVzc2FnZXMgdGhhdCB5b3UgcmVmZXIgdG8uDQo+ID4gPg0KPiA+ID4gSGkgTGxveWQsDQo+ID4g Pg0KPiA+ID4gVGhlIGRyYWZ0IGRvZXNuJ3QgcmVxdWlyZSB0aGUgSVB2NiBVRFAgY2hlY2tzdW0g dG8gYmUgc2V0IHRvIHplcm8NCj4gcmVnYXJkbGVzcy4NCj4gPiBTZWUgdGhlIGZvbGxvd2luZyB0 ZXh0IHF1b3RlZCBmcm9tIHRoYXQgZHJhZnQ6DQo+ID4gPg0KPiA+ID4gVURQIENoZWNrc3VtDQo+ ID4gPg0KPiA+ID4gVGhlIHVzYWdlIG9mIHRoaXMgZmllbGQgaXMgaW4gYWNjb3JkYW5jZSB3aXRo IHRoZSBjdXJyZW50IFVEUA0KPiA+ID4gc3BlY2lmaWNhdGlvbg0KPiA+IFtSRkM3NjhdLiBUbyBz aW1wbGlmeSB0aGUgb3BlcmF0aW9uIG9uIHRoZSBkZWNhcHN1bGF0b3IsIHRoaXMgZmllbGQgaXMN Cj4gPiBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyBpbiBJUHY0IFVEUCBlbmNhcHN1bGF0 aW9uIGNhc2UuIEluIHRoZQ0KPiA+IElQdjYgVURQIGVuY2Fwc3VsYXRpb24gY2FzZSwgaWYgYXBw cm9wcmlhdGUgYWNjb3JkaW5nIHRvIHRoZQ0KPiA+IHJlcXVpcmVtZW50cyBkZWZpbmVkIGluIFtS RkM2OTM1XSBbUkZDNjkzNl0sIHRoaXMgZmllbGQgaXMgYWxzbw0KPiBSRUNPTU1FTkRFRCB0byBi ZSBzZXQgdG8gemVyby4NCj4gPiBTcGVjaWZpY2FsbHksIGlmIHRoZSBNUExTIHBheWxvYWQgaXMg SW50ZXJuZXQgUHJvdG9jb2wgKElQdjQgb3IgSVB2NikNCj4gPiBwYWNrZXRzLCBpdCBpcyBSRUNP TU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyB3aGVuIHRoZSBpbm5lciBwYWNrZXQNCj4gPiBpbnRl Z3JpdHkgY2hlY2tzIGlzIGF2YWlsYWJsZS4gSW4gYWRkaXRpb24sIGlmIHRoZSBNUExTIHBheWxv YWQgaXMNCj4gPiBub24tSVAgcGFja2V0IHdoaWNoIGlzIHNwZWNpZmljYWxseSBkZXNpZ25lZCBm b3IgdHJhbnNtaXNzaW9uIG92ZXIgYQ0KPiA+IGxvd2VyIGxheWVyIHRoYXQgZG9lcyBub3QgcHJv dmlkZSBhIHBhY2tldCBpbnRlZ3JpdHkgZ3VhcmFudGVlLCBpdCBpcw0KPiA+IFJFQ09NTUVOREVE IHRvIGJlIHNldCB0byB6ZXJvIGFzIHdlbGwuIE90aGVyd2lzZSwgdXNpbmcgemVybyBjaGVja3N1 bQ0KPiA+IGlzIE5PVCBSRUNPTU1FTkRFRC4gTm90ZSB0aGF0IG90aGVyIElQIGVuY2Fwc3VsYXRp b25zIGZvciBNUExTIGRvIG5vdA0KPiBoYXZlIGEgY2hlY2tzdW0gaW4gdGhlIHR1bm5lbCBoZWFk ZXIuDQo+ID4gPg0KPiA+ID4gSWYgeW91IHN0aWxsIGJlbGlldmUgdGhlIGFib3ZlIHRleHQgaXMg bm90IHNhdGlzZmFjdG9yeSwgcGxlYXNlIHByb3ZpZGUgeW91ciB0ZXh0Lg0KPiA+ID4NCj4gPiA+ IEJlc3QgcmVnYXJkcywNCj4gPiA+IFhpYW9odQ0KPiA+ID4NCj4gPiA+ID4gTGxveWQgV29vZA0K PiA+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRnJvbTogbXBscyBbbXBscy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNCj4gPiA+ID4gW3h1eGlhb2h1QGh1 YXdlaS5jb21dDQo+ID4gPiA+IFNlbnQ6IDIzIEphbnVhcnkgMjAxNCAwMzoxNg0KPiA+ID4gPiBU bzogQWxleGFuZGVyIFZhaW5zaHRlaW47IEVnZ2VydCwgTGFycw0KPiA+ID4gPiBDYzogSm9lbCBK YWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gTGFzdCBD YWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiA+IChFbmNhcHN1bGF0 aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPg0KPiA+ID4gPiBI aQ0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ID4gPiA+ILeivP7I yzogQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4gPiA+ID4gPiBbbWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyMsjVIDE5 OjA1DQo+ID4gPiA+ID4gytW8/sjLOiBFZ2dlcnQsIExhcnMNCj4gPiA+ID4gPiCzrcvNOiBKb2Vs IEphZWdnbGk7IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1DQo+ID4gPiA+ID4g1vfM4jogUkU6IFtt cGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4g PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IExhcnMgYW5kIGFsbCwNCj4gPiA+ID4gPiBMYXN0IHRpbWUgSSd2ZSBj b3VudGVkIHRoZSBJRVRGIExDIHRocmVhZCBvbiB0aGlzIGRyYWZ0IGhhcyBtb3JlDQo+ID4gPiA+ ID4gdGhhbg0KPiA+ID4gPiA+IDE1MCBtZXNzYWdlcyBpbiBpdCwgYW5kIGl0IHNlZW1zIHRoYXQg b24gc29tZSBpc3N1ZXMgKGNvbmdlc3Rpb24NCj4gPiA+ID4gPiBjb250cm9sIGFuZCBVRFANCj4g PiA+ID4gPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyByb3VuZCB0aGUgbXVsYmVycnkgYnVzaC4N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IElNSE8gYW5kIEZXSVc6DQo+ID4gPiA+ID4gLSBVRFAgY2hl Y2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJlY2F1c2UgbmF0aXZlDQo+ ID4gPiA+ID4gTVBMUyBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIGxpa2UgdGhhdC4gQW5kIHllcywg dGhlcmUgYXJlIGNhc2VzDQo+ID4gPiA+ID4gd2hlcmUgcGFja2V0cyBhcmUgY29ycnVwdGVkIHdp dGhpbiB0aGUgcm91dGVycyksIGJ1dCBzbyBmYXIgaXQNCj4gPiA+ID4gPiBkaWQgbm90IHByZXZl bnQgTVBMUyBkZXBsb3ltZW50LiBUaGVyZSBpcywgZS5nLiwgUkZDIDQ3MjAgZm9yDQo+ID4gPiA+ ID4gRkNTIHJldGVudGlvbiBpbiBQV3MsIGJ1dCBJIGRvdWJ0IGl0IGlzIHdpZGVseSBpbXBsZW1l bnRlZCBhbmQNCj4gPiA+ID4gPiBkZXBsb3llZCAod291bGQgYmUgbmljZSB0bw0KPiA+ID4gPiBr bm93KS4NCj4gPiA+ID4gPiAtIEUyRSBjb25nZXN0aW9uIGNvbnRyb2wgKHJlZ2FyZGxlc3Mgb2Yg aXRzIGltcGxpY2F0aW9ucykgc2ltcGx5DQo+ID4gPiA+ID4gY2Fubm90IGJlIGFkZGVkIHRvIHRo aXMgcHJvdG9jb2wgd2l0aG91dCBzb21lIG1ham9yIGNoYW5nZXMuIEENCj4gPiA+ID4gPiBzaG9y dCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBleHBsYWluaW5nIHRoYXQgc2hvdWxkIHN1ZmZpY2Ug SU1PLg0KPiA+ID4gPg0KPiA+ID4gPiBIaSBTYXNoYSwNCj4gPiA+ID4NCj4gPiA+ID4gSSBmdWxs eSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnRzLg0KPiA+ID4gPg0KPiA+ID4gPiBCZXN0IHJlZ2FyZHMs DQo+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPg0KPiA+ID4gPiA+IE15IDJjLA0KPiA+ID4gPiA+ICAg ICAgICBTYXNoYQ0KPiA+ID4gPiA+IEVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbQ0KPiA+ID4gPiA+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+IEZyb206IG1wbHMgW21h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFZ2dlcnQsDQo+ID4gPiA+ ID4gPiBMYXJzDQo+ID4gPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjIsIDIwMTQg MTI6MjMgUE0NCj4gPiA+ID4gPiA+IFRvOiBYdXhpYW9odQ0KPiA+ID4gPiA+ID4gQ2M6IEpvZWwg SmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBM YXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiA+IChF bmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IEhpLA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE9uIDIwMTQtMS0y MiwgYXQgMTE6MTIsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+ ID4gPiA+ID4gSSB3b25kZXIgd2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0sgdG8geW91 Og0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBTaW5jZSB0aGUgTVBMUy1pbi1VRFAgZW5j YXBzdWxhdGlvbiBjYXVzZXMgTVBMUyBwYWNrZXRzIHRvDQo+ID4gPiA+ID4gPiA+IGJlDQo+ID4g PiA+ID4gPiBmb3J3YXJkZWQgdGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBj b250cm9sDQo+ID4gPiA+ID4gPiBndWlkZWxpbmVzIGZvciBVRFAgdHVubmVscyBhcyBkZWZpbmVk IGluIFNlY3Rpb24gMy4xLjMgb2YNCj4gPiA+ID4gPiA+IFtSRkM1NDA1XSBTSE9VTEQgYmUNCj4g PiA+ID4gZm9sbG93ZWQuDQo+ID4gPiA+ID4gPiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5 IGEgbnVtYmVyIG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYXMNCj4gcGF5bG9hZHMuDQo+ID4gPiA+ ID4gPiBXaGVuIGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMg dGhhdCBpcw0KPiA+ID4gPiA+ID4ga25vd24gYXQgY29uZmlndXJhdGlvbiB0aW1lIHRvIGJlIElQ LWJhc2VkIGFuZA0KPiA+ID4gPiA+ID4gY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUgVURQIHR1 bm5lbCBTSE9VTEQgTk9UIGVtcGxveSBpdHMNCj4gPiA+ID4gPiA+IG93biBjb25nZXN0aW9uIGNv bnRyb2wgbWVjaGFuaXNtLCBiZWNhdXNlIGNvbmdlc3Rpb24gbG9zc2VzIG9mDQo+ID4gPiA+ID4g PiB0dW5uZWxlZCB0cmFmZmljIHdpbGwgdHJpZ2dlciBhbiBjb25nZXN0aW9uIHJlc3BvbnNlIGF0 IHRoZQ0KPiA+ID4gPiA+ID4gb3JpZ2luYWwNCj4gPiBzZW5kZXJzIG9mIHRoZSB0dW5uZWxlZCB0 cmFmZmljLg0KPiA+ID4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMg cGF5bG9hZCB0cmFmZmljIHRoYXQgaXMNCj4gPiA+ID4gPiA+IGtub3duIGF0IGNvbmZpZ3VyYXRp b24gdGltZSBub3QgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gPiBjb25nZXN0aW9uLWNv bnRyb2xsZWQsIHRoZSBVRFAgdHVubmVsIFNIT1VMRCBlbXBsb3kgYW4NCj4gPiA+ID4gPiA+IGFw cHJvcHJpYXRlIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluDQo+ ID4gPiA+ID4gPiBbUkZDMzk4NV0uIE5vdGUgdGhhdCBpdCBTVFJPTkdMWSBSRUNPTU1FTkRFRCB0 byBkZXBsb3kgc3VjaA0KPiA+ID4gPiA+ID4gZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IG9ubHkg d2l0aGluIGEgU1AgbmV0d29yayBvciBuZXR3b3Jrcw0KPiA+ID4gPiA+ID4gb2YgYW4gYWRqYWNl bnQgc2V0IG9mIGNvLW9wZXJhdGluZyBTUHMsIHJhdGhlciB0aGFuIG92ZXIgdGhlDQo+ID4gPiA+ IEludGVybmV0Lg0KPiA+ID4gPiA+ID4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3Vs ZCBiZSBhZGRlZCB0byBibG9jayB0cmFmZmljDQo+ID4gPiA+ID4gPiB3aXRoIHRoZSBVRFAgcG9y dCBudW1iZXIgZm9yIE1QTFMgb3ZlciBVRFAgdG8gcHJldmVudCBNUExTDQo+ID4gPiA+ID4gPiBv dmVyIFVEUCBwYWNrZXRzIHRvIGVzY2FwZSBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdv cmtzDQo+ID4gPiA+ID4gPiBkdWUgdG8gbWlzY29uZmlndWF0aW9uIG9yIHBhY2tldA0KPiA+ID4g PiA+IGVycm9ycy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJIHRoaW5rIGl0IHdvdWxkIGJl IGJldHRlciB0byBkZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wgbG9vcCBpbg0KPiA+ID4gPiA+ID4g KHNvbWUpIG1vcmUgZGV0YWlsLCByYXRoZXIgdGhhbiBwb2ludGluZyB0byBSRkMzOTg1LCB3aGlj aA0KPiA+ID4gPiA+ID4gZG9lc24ndCBoYXZlIGEgd2hvbGUgbG90IG9mIGRldGFpbCBlaXRoZXIu IEFsc28gYmVjYXVzZSB0aGUNCj4gPiA+ID4gPiA+IGFkZGluZyBvZiBmaXJld2FsbCBydWxlcyBy ZXF1aXJlcyBhbiBPQU0gaG9vay4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTaW5jZSBTVFJP TkdMWSBSRUNPTU1FTkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJtIGFuZA0KPiA+ID4gPiA+IFJF Q09NTUVOREVEIGlzDQo+ID4gPiA+ID4gPiB0b28gd2VhaywgSSdkIHN1Z2dlc3QgdG8gY2hhbmdl IHRoaXMgdG8gTVVTVC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBGaW5hbGx5LCB0aGUgYXBw bGljYWJpbGl0eSBzdGF0ZW1lbnQgc2hvdWxkIGJlIHByb21pbmVudGx5DQo+ID4gPiA+ID4gPiBt YWRlIGluIHRoZSBhYnN0cmFjdCwgaW50cm9kdWN0aW9uLCBldGMuDQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gTGFycw0K From xuxiaohu@huawei.com Thu Jan 23 22:37:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD1E1A012A for ; Thu, 23 Jan 2014 22:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 OFJI9s87t2FJ for ; Thu, 23 Jan 2014 22:37:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 92A7F1A010B for ; Thu, 23 Jan 2014 22:37:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCW35401; Fri, 24 Jan 2014 06:37:18 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 06:37:11 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 06:37:16 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 14:37:14 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGLe0Vpx4VpP9lE+4fynfG27EApqTPtnwgAASPbeAABBtMIAAAYC7gAADWaA= Date: Fri, 24 Jan 2014 06:37:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082479D6@NKGEML512-MBS.china.huawei.com> References: Your message of "Thu, 23 Jan 2014 17:18:22 +0000." <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247954@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346ED@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082479BA@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346EF@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346EF@EXMB01CMS.surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" , "lars@netapp.com" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 06:37:25 -0000 R2l2ZW4gdGhlIGZhY3QgdGhhdCB6ZXJvLWNoZWNrc3VtIGZvciBJUHY0IFVEUCB0dW5uZWwgaGFz IGJlZW4gd2lkZWx5IHVzZWQsIEkgcGVyc29uYWxseSBwcmVmZXIgdG8gdGFrZSB5b3VyIHN1Z2dl c3RlZCB0ZXh0IGFzIElQdjYgc3BlY2lmaWMgd2hpbGUga2VlcGluZyB0aGUgSVB2NCBVRFAgY2hl Y2tzdW0gYmVoYXZpb3IgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBjdXJyZW50IHByYWN0aWNlLiBJ biBvdGhlciB3b3JkLCAiaW4gdGhlIElQdjQgVURQIGNhc2UsIHRoaXMgY2hlY2tzdW0gZmllbGQg aXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8iLiBJZiBzb21lIG9wZXJhdG9ycyBhcmUg c3RpbGwgY29uY2VybmVkIHdpdGggdGhlIHJhcmUgcHJvYmxlbSBjYXVzZWQgYnkgSVB2NCBVRFAg emVyby1jaGVja3N1bSwgdGhleSB3b3VsZCBkaXNhYmxlIHRoZSBjaGVja3N1bS16ZXJvLiANCg0K WGlhb2h1DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGwud29vZEBzdXJyZXkuYWMu dWsgW21haWx0bzpsLndvb2RAc3VycmV5LmFjLnVrXQ0KPiC3osvNyrG85DogMjAxNMTqMdTCMjTI 1SAxNDoxMQ0KPiDK1bz+yMs6IFh1eGlhb2h1OyBjdXJ0aXNAaXB2Ni5vY2NuYy5jb20NCj4gs63L zTogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBwLmNvbTsgam9l bGphQGJvZ3VzLmNvbTsNCj4gbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBSRTogW21wbHNdIExhc3Qg Q2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExT DQo+IGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+IFRoZXkncmUgbm90IGluIGNv bmZsaWN0Lg0KPiANCj4gSW4gSVB2NCwgeW91IGhhdmUgdGhlIElQIGhlYWRlciBjaGVja3N1bSBh cyBhIGNoZWNrIHRoYXQgdGhlIGRlc3RpbmF0aW9uDQo+IGFkZHJlc3MgaXMgcmlnaHQuIFdpdGgg YSB6ZXJvIFVEUCBjaGVja3N1bSwgdGhlIHBvcnRzIGFyZW4ndCBjaGVja2VkIC0gYnV0IGlmDQo+ IHlvdXIgdHVubmVsIGRlc3RpbmF0aW9uIGhvc3QgaXNuJ3QgcnVubmluZyBvdGhlciBVRFAgYXBw cywgbGltaXRlZCBwcm9ibGVtDQo+IA0KPiBXaXRoIElQdjYgYW5kIG5vIGhlYWRlciBjaGVja3N1 bSwgYWRkcmVzcyBjYW4gYmUgY29ycnVwdGVkIGFzIHdlbGwuDQo+IFRoZSBwYWNrZXQgY2FuIGJl IHJlY2VpdmVkIG9uIG90aGVyIGhvc3RzIHdoaWNoIGNhbiBydW4gVURQLg0KPiANCj4gVGhhdCBp cyB3aHkgdGhlIHRleHQgeW91IHF1b3RlIHNheXM6DQo+ICAgIlRoZXJlIGlzIGFuICBpbmNyZWFz ZWQgcmlzayBvZiBjb3JydXB0aW9uIGFuZCBtaXNkZWxpdmVyeSB3aGVuIHVzaW5nIHplcm8NCj4g VURQDQo+ICAgIGNoZWNrc3VtIGluIElQdjYgY29tcGFyZWQgdG8gdXNpbmcgSVB2NCINCj4gDQo+ IElQdjQgcmlzayBpcyBzbWFsbGVyLCBidXQgbm90IG5vbnplcm8uIFR1cm5pbmcgb2ZmIFVEUCBj aGVja3N1bXMgaW4gdjQgaXMgYWdhaW4NCj4gZm9yIGNvbnZlbmllbmNlLCBhbmQgaGFzIGJlZW4g bW9yZSBjb21tb24gKHdpdGggbG92ZWx5IGV4YW1wbGVzIGdpdmluZw0KPiBwZXJmb3JtYW5jZSBn YWlucyB0aGF0IGNvcnJ1cHQgZGF0YWJhc2UgdHJhbnNhY3Rpb25zKSwgYnV0IHRoZXJlIGlzIHN0 aWxsIHJpc2sNCj4gYXNzb2NpYXRlZCB3aXRoIHR1cm5pbmcgb2ZmIElQdjQgVURQIGNoZWNrc3Vt cy4NCj4gDQo+IChBbmQgaW4gYm90aCB2NCBhbmQgdjYsIGEgemVybyBjaGVja3N1bSBtZWFucyB0 aGF0IGEgY2hlY2sgYWNyb3NzIHRoZSBNUExTDQo+IHN0YWNrIGlzIHJlbW92ZWQsIGFuZCBjb3Jy dXB0aW9uIGluIHRoYXQgY2Fubm90IGJlIGRldGVjdGVkKQ0KPiANCj4gTGxveWQgV29vZA0KPiBo dHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gRnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+IFNl bnQ6IDI0IEphbnVhcnkgMjAxNCAwNjowMg0KPiBUbzogV29vZCBMICBEciAoRWxlY3Ryb25pYyBF bmcpOyBjdXJ0aXNAaXB2Ni5vY2NuYy5jb20NCj4gQ2M6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tOyBsYXJzQG5ldGFwcC5jb207IGpvZWxqYUBib2d1cy5jb207DQo+IG1wbHNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMt aW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUw0KPiBpbiBVRFApIHRvIFByb3Bvc2Vk IFN0YW5kYXJkDQo+IA0KPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ILeivP7IyzogbC53b29k QHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ID4gt6LLzcqxvOQ6 IDIwMTTE6jHUwjI0yNUgMTM6MDENCj4gPiDK1bz+yMs6IFh1eGlhb2h1OyBjdXJ0aXNAaXB2Ni5v Y2NuYy5jb20NCj4gPiCzrcvNOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFy c0BuZXRhcHAuY29tOw0KPiA+IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiDW 98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0 Pg0KPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0K PiA+DQo+ID4gSSB3b3VsZCBiZSBnb29kIHdpdGg6DQo+ID4NCj4gPiAiR2VuZXJhbGx5IHNwZWFr aW5nLCBhIFVEUCBjaGVja3N1bSBTSE9VTEQgYmUgdXNlZC4gVGhlIGNvbnNpZGVyYXRpb25zDQo+ ID4gZGVzY3JpYmVkIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0gU0hPVUxEIGJlIGV4YW1pbmVkIGlm IFVEUCBjaGVja3N1bXMNCj4gPiBuZWVkIHRvIGJlIGRpc2FibGVkIGZvciBwZXJmb3JtYW5jZSBv ciBpbXBsZW1lbnRhdGlvbiByZWFzb25zIGZvcg0KPiA+IHRyYWZmaWMgYWNyb3NzIHByaXZhdGUg bmV0d29ya3MuIFRoZSB1c2Ugb2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBpcyBOT1QNCj4gPiBSRUNP TU1FTkRFRC4iDQo+ID4NCj4gPiBJIHdvdWxkbid0IG1ha2UgdGhpcyBJUHY2IHNwZWNpZmljIC0g SVB2NCBzdGlsbCBoYXMgcHJvYmxlbXMgKFVEUCBwb3J0DQo+ID4gZGVtdXgpLCBJUHY2J3MgcHJv YmxlbXMgYXJlIGp1c3Qgd29yc2UuDQo+IA0KPiBJZiBub3QgSVB2NiBzcGVjaWZpYywgaXQgc2Vl bXMgY29uZmxpY3Qgd2l0aCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBxdW90ZWQgZnJvbQ0KPiBS RkM2OTM2Og0KPiANCj4gICAgVGhlIHVzZSBvZiBVRFAgd2l0aCBhIHplcm8gVURQIGNoZWNrc3Vt IGhhcyBtZXJpdHMgZm9yDQo+ICAgIHNvbWUgYXBwbGljYXRpb25zLCBzdWNoIGFzIHR1bm5lbCBl bmNhcHN1bGF0aW9uLCBhbmQgaXMgd2lkZWx5IHVzZWQNCj4gICAgaW4gSVB2NC4gIEhvd2V2ZXIs IHRoZXJlIGFyZSBkaWZmZXJlbnQgZGFuZ2VycyBmb3IgSVB2Ni4gIFRoZXJlIGlzIGFuDQo+ICAg IGluY3JlYXNlZCByaXNrIG9mIGNvcnJ1cHRpb24gYW5kIG1pc2RlbGl2ZXJ5IHdoZW4gdXNpbmcg emVybyBVRFANCj4gICAgY2hlY2tzdW0gaW4gSVB2NiBjb21wYXJlZCB0byB1c2luZyBJUHY0IGR1 ZSB0byB0aGUgbGFjayBvZiBhbiBJUHY2DQo+ICAgIGhlYWRlciBjaGVja3N1bS4NCj4gDQo+IFhp YW9odQ0KPiANCj4gPiBMbG95ZCBXb29kDQo+ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBGcm9tOiBY dXhpYW9odSBbeHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPiBTZW50OiAyNCBKYW51YXJ5IDIwMTQg MDQ6MDANCj4gPiBUbzogY3VydGlzQGlwdjYub2NjbmMuY29tOyBXb29kIEwgIERyIChFbGVjdHJv bmljIEVuZykNCj4gPiBDYzogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNA bmV0YXBwLmNvbTsNCj4gPiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4gU3Vi amVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4 dD4NCj4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQN Cj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gUGxlYXNlIGNoZWNrIHdoZXRoZXIgdGhlIGZvbGxvd2lu ZyB0ZXh0IGlzIE9LLg0KPiA+DQo+ID4gSW4gdGhlIElQdjYgVURQIGVuY2Fwc3VsYXRpb24gY2Fz ZSwgYXMgZm9yIHdoZXRoZXIgb3Igbm90IGl0IGlzDQo+ID4gc3VpdGFibGUgdG8gdXNlIHRoZSB6 ZXJvLWNoZWNrc3VtIG5vZGUsIHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbg0KPiA+IFtSRkM2 OTM1XSBbUkZDNjkzNl0gU0hPVUxEIGJlIHN0cmljdGx5IGZvbGxvd2VkLiBHZW5lcmFsbHkgc3Bl YWtpbmcsDQo+ID4gdGhlIHVzZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzIE5PVCBSRUNPTU1F TkRFRC4gTm90ZSB0aGF0IG90aGVyIElQDQo+ID4gZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMgZG8g bm90IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCj4gPg0KPiA+IEJlc3Qg cmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4g PiC3orz+yMs6IEN1cnRpcyBWaWxsYW1pemFyIFttYWlsdG86Y3VydGlzQGlwdjYub2NjbmMuY29t XQ0KPiA+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjI0yNUgMTE6NTMNCj4gPiA+IMrVvP7IyzogbC53 b29kQHN1cnJleS5hYy51aw0KPiA+ID4gs63LzTogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5ldGFwcC5jb207DQo+ID4gPiBqb2VsamFAYm9ndXMuY29t OyBtcGxzQGlldGYub3JnDQo+ID4gPiDW98ziOiBSZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBV RFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPg0KPiA+ID4NCj4gPiA+IEluIG1lc3NhZ2UN Cj4gPiA+DQo+ID4NCj4gPDI5MEUyMEI0NTVDNjY3NDNCRTE3OEM1Qzg0RjEyNDA4NDdFNjMzNDZF M0BFWE1CMDFDTVMuc3VycmV5LmENCj4gPiA+IGMudWs+DQo+ID4gPiBsLndvb2RAc3VycmV5LmFj LnVrIHdyaXRlczoNCj4gPiA+DQo+ID4gPiA+IHRoZSB0ZXh0IGlzIG5vdCBzYXRpc2ZhY3Rvcnku IG5ldmVyIHJlY29tbWVuZCBzZXR0aW5nIHRvIHplcm8sIGFzDQo+ID4gPiA+IHRoYXQgcG9zZXMg YSByaXNrIHRvIHlvdXIgYW5kIHRvIG90aGVyIHRyYWZmaWMuIFN1Z2dlc3RlZCB0ZXh0Og0KPiA+ ID4gPiAqKioNCj4gPiA+ID4gVGhlIFVEUCBjaGVja3N1bSBTSE9VTEQgYmUgdXNlZCB0byBwcm90 ZWN0IHRoZSBwYXlsb2FkIGFuZCBlbnN1cmUNCj4gPiA+ID4gY29ycmVjdCBkZW11bHRpcGxleGlu ZyBhbmQgZGVsaXZlcnkgdG8gdGhlIHR1bm5lbCwgYW5kIG5vdCB0bw0KPiA+ID4gPiBvdGhlciBV RFAgZGVzdGluYXRpb25zLCBieSBwcm90ZWN0aW5nIHRoZSBVRFAgcHNldWRvaGVhZGVyLg0KPiA+ ID4gPiBVc2Ugb2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQsIGV2ZW4g d2hlbiBkZXNpcmVkDQo+ID4gPiA+IGZvciBwZXJmb3JtYW5jZSBvciBuZWNlc3NpdGF0ZWQgYnkg aW1wbGVtZW50YXRpb24gcmVhc29ucywgZm9yIHRoZQ0KPiA+ID4gPiByZWFzb25zIG91dGxpbmVk IGluIFtSRkM2OTM2XSBzZWN0aW9uIDMuDQo+ID4gPg0KPiA+ID4gSSBhZ3JlZSB0aGF0IFVEUCBj aGVja3N1bXMgU0hPVUxEIGJlIHVzZWQgKGllOiBTSE9VTEQgTk9UIGJlIHNldCB0bw0KPiB6ZXJv KS4NCj4gPiA+IFRoZXJlIGFyZSBjYXNlcyB3aGVyZSBpdCBpcyBpbXBvc3NpYmxlIHNvIGl0IGNh bid0IGJlIE1VU1QuDQo+ID4gPg0KPiA+ID4gPiBVRFAtTGl0ZSBbUkZDMzgyOF0gY2FuIHByb3Zp ZGUgYSBkZW11bHRpcGxleGluZyBjaGVjayBhbmQgTVBMUw0KPiA+ID4gPiBzdGFjayBpbnRlZ3Jp dHkgY2hlY2sgd2hpbGUgYXZvaWRpbmcgdGhlIG92ZXJoZWFkIG9mIGNvbXB1dGluZyBhbg0KPiA+ ID4gPiBpbnRlZ3JpdHkgY2hlY2sgb3ZlciBhIHR1bm5lbGxlZCBmcmFtZSB0aGF0IGhhcyBpdHMg b3duIGludGVncml0eSBjaGVjay4NCj4gPiA+DQo+ID4gPiBVRFAtTGlzdCBkb2Vzbid0IHNvbHZl IHRoZSBFQ01QIHByb2JsZW1zIGJlY2F1c2UgbW9zdCBvZiB0aGUgb2xkZXINCj4gPiA+IExTUiB0 aGF0IGFyZSBmb3JjaW5nIHRoZSB1c2Ugb2YgTVBMUyBvdmVyIFVEUCB0byBnZXQgRUNNUCBkb24n dCBsb29rDQo+ID4gPiBhdCB0aGUgcG9ydCBudW1iZXJzIGlmIHRoZSBwcm90b2NvbCBpcyBub3Qg NiBvciAxNy4gIEJ1dCB0aGlzIGhhcw0KPiA+ID4gb25seSBiZWVuIHNhaWQgdGhyZWUgb3IgZm91 ciB0aW1lcyBzbyBtYXliZSB5b3UgbWlzc2VkIGl0Lg0KPiA+ID4NCj4gPiA+ID4gKioqDQo+ID4g PiA+DQo+ID4gPiA+IExsb3lkIFdvb2QNCj4gPiA+ID4gaHR0cDovL2Fib3V0Lm1lL2xsb3lkd29v ZA0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g PiA+IEZyb206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiA+ID4gPiBTZW50OiAy MyBKYW51YXJ5IDIwMTQgMTI6MzUNCj4gPiA+ID4gVG86IFdvb2QgTCAgRHIgKEVsZWN0cm9uaWMg RW5nKTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207DQo+ID4gPiA+IGxhcnNAbmV0 YXBwLmNvbQ0KPiA+ID4gPiBDYzogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ ID4gPiBTdWJqZWN0OiByZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11 ZHAtMDQudHh0Pg0KPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9z ZWQgU3RhbmRhcmQNCj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ ID4gPiC3orz+yMs6IGwud29vZEBzdXJyZXkuYWMudWsgW21haWx0bzpsLndvb2RAc3VycmV5LmFj LnVrXQ0KPiA+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyM8jVIDEyOjQ0DQo+ID4gPiA+ID4g ytW8/sjLOiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207DQo+IGxh cnNAbmV0YXBwLmNvbQ0KPiA+ID4gPiA+ILOty806IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0 Zi5vcmcNCj4gPiA+ID4gPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYt bXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQ KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gU2FzaGENCj4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEg bm9uLWlzc3VlIGJlY2F1c2UNCj4gPiA+ID4gPiA+IG5hdGl2ZSBNUExTIGRvZXMgbm90IGhhdmUg YW55dGhpbmcgbGlrZSB0aGF0LiBBbmQgeWVzLCB0aGVyZQ0KPiA+ID4gPiA+ID4gYXJlIGNhc2Vz IHdoZXJlIHBhY2tldHMgYXJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMpDQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBTbyB5b3UgYWRtaXQgdGhhdCBwYWNrZXRzIGNhbiBiZSBjb3JydXB0ZWQg d2l0aGluIHRoZSByb3V0ZXJzIC0NCj4gPiA+ID4gPiBhIGNoZWNrIHRoYXQgY2FuIG9ubHkgYmUg Y2F1Z2h0IGJ5IGFuIGVuZC10by1lbmQgY2hlY2ssIGENCj4gPiA+ID4gPiBjb3JydXB0aW9uIHRo YXQgY2FuIGxlYWQgdG8gdGhlIHByb2JsZW1zIGRldGFpbGVkIGluIFJGQyA2OTM2DQo+ID4gPiA+ ID4gc2VjdGlvbiAzIC0gYW5kIHRoZW4geW91IHNheSBpdCdzIGEgbm9uLWlzc3VlIGJlY2F1c2Ug dGhpcw0KPiA+ID4gPiA+IGRvZXNuJ3QgYWZmZWN0IG5hdGl2ZSBNUExTLiBCdXQNCj4gPiA+IHdl J3JlIG5vdCBkb2luZyBuYXRpdmUgTVBMUyBoZXJlLg0KPiA+ID4gPiA+IFdlJ3JlIGRvaW5nIE1Q TFMgb3ZlciBVRFAuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBkcmFmdC1pZXRmLW1wbHMtaW4tdWRw LTA0LnR4dCBpcyBhYm91dCB0dW5uZWxsaW5nIE1QTFMgaW4gVURQLiBJdCdzIGFuDQo+IGlzc3Vl Lg0KPiA+ID4gPiA+IFBsZWFzZSByZWFkIHRoZSBvdGhlciAxNTAgbWVzc2FnZXMgdGhhdCB5b3Ug cmVmZXIgdG8uDQo+ID4gPiA+DQo+ID4gPiA+IEhpIExsb3lkLA0KPiA+ID4gPg0KPiA+ID4gPiBU aGUgZHJhZnQgZG9lc24ndCByZXF1aXJlIHRoZSBJUHY2IFVEUCBjaGVja3N1bSB0byBiZSBzZXQg dG8gemVybw0KPiA+IHJlZ2FyZGxlc3MuDQo+ID4gPiBTZWUgdGhlIGZvbGxvd2luZyB0ZXh0IHF1 b3RlZCBmcm9tIHRoYXQgZHJhZnQ6DQo+ID4gPiA+DQo+ID4gPiA+IFVEUCBDaGVja3N1bQ0KPiA+ ID4gPg0KPiA+ID4gPiBUaGUgdXNhZ2Ugb2YgdGhpcyBmaWVsZCBpcyBpbiBhY2NvcmRhbmNlIHdp dGggdGhlIGN1cnJlbnQgVURQDQo+ID4gPiA+IHNwZWNpZmljYXRpb24NCj4gPiA+IFtSRkM3Njhd LiBUbyBzaW1wbGlmeSB0aGUgb3BlcmF0aW9uIG9uIHRoZSBkZWNhcHN1bGF0b3IsIHRoaXMgZmll bGQNCj4gPiA+IGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGluIElQdjQgVURQIGVu Y2Fwc3VsYXRpb24gY2FzZS4gSW4NCj4gPiA+IHRoZQ0KPiA+ID4gSVB2NiBVRFAgZW5jYXBzdWxh dGlvbiBjYXNlLCBpZiBhcHByb3ByaWF0ZSBhY2NvcmRpbmcgdG8gdGhlDQo+ID4gPiByZXF1aXJl bWVudHMgZGVmaW5lZCBpbiBbUkZDNjkzNV0gW1JGQzY5MzZdLCB0aGlzIGZpZWxkIGlzIGFsc28N Cj4gPiBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVyby4NCj4gPiA+IFNwZWNpZmljYWxseSwg aWYgdGhlIE1QTFMgcGF5bG9hZCBpcyBJbnRlcm5ldCBQcm90b2NvbCAoSVB2NCBvcg0KPiA+ID4g SVB2NikgcGFja2V0cywgaXQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gd2hlbiB0 aGUgaW5uZXINCj4gPiA+IHBhY2tldCBpbnRlZ3JpdHkgY2hlY2tzIGlzIGF2YWlsYWJsZS4gSW4g YWRkaXRpb24sIGlmIHRoZSBNUExTDQo+ID4gPiBwYXlsb2FkIGlzIG5vbi1JUCBwYWNrZXQgd2hp Y2ggaXMgc3BlY2lmaWNhbGx5IGRlc2lnbmVkIGZvcg0KPiA+ID4gdHJhbnNtaXNzaW9uIG92ZXIg YSBsb3dlciBsYXllciB0aGF0IGRvZXMgbm90IHByb3ZpZGUgYSBwYWNrZXQNCj4gPiA+IGludGVn cml0eSBndWFyYW50ZWUsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGFzIHdl bGwuDQo+ID4gPiBPdGhlcndpc2UsIHVzaW5nIHplcm8gY2hlY2tzdW0gaXMgTk9UIFJFQ09NTUVO REVELiBOb3RlIHRoYXQgb3RoZXINCj4gPiA+IElQIGVuY2Fwc3VsYXRpb25zIGZvciBNUExTIGRv IG5vdA0KPiA+IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCj4gPiA+ID4N Cj4gPiA+ID4gSWYgeW91IHN0aWxsIGJlbGlldmUgdGhlIGFib3ZlIHRleHQgaXMgbm90IHNhdGlz ZmFjdG9yeSwgcGxlYXNlIHByb3ZpZGUgeW91cg0KPiB0ZXh0Lg0KPiA+ID4gPg0KPiA+ID4gPiBC ZXN0IHJlZ2FyZHMsDQo+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPg0KPiA+ID4gPiA+IExsb3lkIFdv b2QNCj4gPiA+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gPiA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+IEZyb206IG1wbHMg W21wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQo+ID4gPiA+ID4g W3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiA+ID4gU2VudDogMjMgSmFudWFyeSAyMDE0IDAz OjE2DQo+ID4gPiA+ID4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBFZ2dlcnQsIExhcnMNCj4g PiA+ID4gPiBDYzogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gU3ViamVj dDogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4N Cj4gPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRh cmQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhpDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0t 08q8/tStvP4tLS0tLQ0KPiA+ID4gPiA+ID4gt6K8/sjLOiBBbGV4YW5kZXIgVmFpbnNodGVpbg0K PiA+ID4gPiA+ID4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4g PiA+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyMsjVIDE5OjA1DQo+ID4gPiA+ID4gPiDK1bz+ yMs6IEVnZ2VydCwgTGFycw0KPiA+ID4gPiA+ID4gs63LzTogSm9lbCBKYWVnZ2xpOyBtcGxzQGll dGYub3JnOyBYdXhpYW9odQ0KPiA+ID4gPiA+ID4g1vfM4jogUkU6IFttcGxzXSBMYXN0IENhbGw6 IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiA+IChFbmNhcHN1bGF0 aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IExhcnMgYW5kIGFsbCwNCj4gPiA+ID4gPiA+IExhc3QgdGltZSBJJ3ZlIGNvdW50ZWQg dGhlIElFVEYgTEMgdGhyZWFkIG9uIHRoaXMgZHJhZnQgaGFzDQo+ID4gPiA+ID4gPiBtb3JlIHRo YW4NCj4gPiA+ID4gPiA+IDE1MCBtZXNzYWdlcyBpbiBpdCwgYW5kIGl0IHNlZW1zIHRoYXQgb24g c29tZSBpc3N1ZXMNCj4gPiA+ID4gPiA+IChjb25nZXN0aW9uIGNvbnRyb2wgYW5kIFVEUA0KPiA+ ID4gPiA+ID4gY2hlY2tzdW1zKSB3ZSBhcmUgZ29pbmcgcm91bmQgdGhlIG11bGJlcnJ5IGJ1c2gu DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSU1ITyBhbmQgRldJVzoNCj4gPiA+ID4gPiA+IC0g VURQIGNoZWNrc3VtcyAob3IgbGFjayB0aGVyZW9mKSBpcyBhIG5vbi1pc3N1ZSBiZWNhdXNlDQo+ ID4gPiA+ID4gPiBuYXRpdmUgTVBMUyBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIGxpa2UgdGhhdC4g QW5kIHllcywgdGhlcmUNCj4gPiA+ID4gPiA+IGFyZSBjYXNlcyB3aGVyZSBwYWNrZXRzIGFyZSBj b3JydXB0ZWQgd2l0aGluIHRoZSByb3V0ZXJzKSwgYnV0DQo+ID4gPiA+ID4gPiBzbyBmYXIgaXQg ZGlkIG5vdCBwcmV2ZW50IE1QTFMgZGVwbG95bWVudC4gVGhlcmUgaXMsIGUuZy4sIFJGQw0KPiA+ ID4gPiA+ID4gNDcyMCBmb3IgRkNTIHJldGVudGlvbiBpbiBQV3MsIGJ1dCBJIGRvdWJ0IGl0IGlz IHdpZGVseQ0KPiA+ID4gPiA+ID4gaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkICh3b3VsZCBiZSBu aWNlIHRvDQo+ID4gPiA+ID4ga25vdykuDQo+ID4gPiA+ID4gPiAtIEUyRSBjb25nZXN0aW9uIGNv bnRyb2wgKHJlZ2FyZGxlc3Mgb2YgaXRzIGltcGxpY2F0aW9ucykNCj4gPiA+ID4gPiA+IHNpbXBs eSBjYW5ub3QgYmUgYWRkZWQgdG8gdGhpcyBwcm90b2NvbCB3aXRob3V0IHNvbWUgbWFqb3INCj4g PiA+ID4gPiA+IGNoYW5nZXMuIEEgc2hvcnQgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZXhwbGFp bmluZyB0aGF0IHNob3VsZCBzdWZmaWNlDQo+IElNTy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhp IFNhc2hhLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9p bnRzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPiA+IFhpYW9o dQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBNeSAyYywNCj4gPiA+ID4gPiA+ICAgICAgICBTYXNo YQ0KPiA+ID4gPiA+ID4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+ ID4gPiA+ID4gPiBNb2JpbGU6IDA1NC05MjY2MzAyDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gPiBGcm9tOiBtcGxzIFtt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiA+ID4gPiA+ID4g RWdnZXJ0LCBMYXJzDQo+ID4gPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMiwg MjAxNCAxMjoyMyBQTQ0KPiA+ID4gPiA+ID4gPiBUbzogWHV4aWFvaHUNCj4gPiA+ID4gPiA+ID4g Q2M6IEpvZWwgSmFlZ2dsaTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBS ZTogW21wbHNdIExhc3QgQ2FsbDoNCj4gPiA+ID4gPiA+ID4gPGRyYWZ0LWlldGYtbXBscy1pbi11 ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkNCj4gPiA+ID4gPiA+ID4gdG8g UHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSGksDQo+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IE9uIDIwMTQtMS0yMiwgYXQgMTE6MTIsIFh1eGlhb2h1 IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPiBJIHdvbmRlciB3 aGV0aGVyIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBPSyB0byB5b3U6DQo+ID4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gPiBTaW5jZSB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiBjYXVz ZXMgTVBMUyBwYWNrZXRzIHRvDQo+ID4gPiA+ID4gPiA+ID4gYmUNCj4gPiA+ID4gPiA+ID4gZm9y d2FyZGVkIHRocm91Z2ggIlVEUCB0dW5uZWxzIiwgdGhlIGNvbmdlc3Rpb24gY29udHJvbA0KPiA+ ID4gPiA+ID4gPiBndWlkZWxpbmVzIGZvciBVRFAgdHVubmVscyBhcyBkZWZpbmVkIGluIFNlY3Rp b24gMy4xLjMgb2YNCj4gPiA+ID4gPiA+ID4gW1JGQzU0MDVdIFNIT1VMRCBiZQ0KPiA+ID4gPiA+ IGZvbGxvd2VkLg0KPiA+ID4gPiA+ID4gPiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5IGEg bnVtYmVyIG9mIGRpZmZlcmVudCBwcm90b2NvbHMNCj4gPiA+ID4gPiA+ID4gYXMNCj4gPiBwYXls b2Fkcy4NCj4gPiA+ID4gPiA+ID4gV2hlbiBhbiBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMg cGF5bG9hZCB0cmFmZmljIHRoYXQgaXMNCj4gPiA+ID4gPiA+ID4ga25vd24gYXQgY29uZmlndXJh dGlvbiB0aW1lIHRvIGJlIElQLWJhc2VkIGFuZA0KPiA+ID4gPiA+ID4gPiBjb25nZXN0aW9uLWNv bnRyb2xsZWQsIHRoZSBVRFAgdHVubmVsIFNIT1VMRCBOT1QgZW1wbG95IGl0cw0KPiA+ID4gPiA+ ID4gPiBvd24gY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSwgYmVjYXVzZSBjb25nZXN0aW9u IGxvc3Nlcw0KPiA+ID4gPiA+ID4gPiBvZiB0dW5uZWxlZCB0cmFmZmljIHdpbGwgdHJpZ2dlciBh biBjb25nZXN0aW9uIHJlc3BvbnNlIGF0DQo+ID4gPiA+ID4gPiA+IHRoZSBvcmlnaW5hbA0KPiA+ ID4gc2VuZGVycyBvZiB0aGUgdHVubmVsZWQgdHJhZmZpYy4NCj4gPiA+ID4gPiA+ID4gV2hlbiBh biBVRFAgdHVubmVsIGlzIHVzZWQgZm9yIE1QTFMgcGF5bG9hZCB0cmFmZmljIHRoYXQgaXMNCj4g PiA+ID4gPiA+ID4ga25vd24gYXQgY29uZmlndXJhdGlvbiB0aW1lIG5vdCB0byBiZSBJUC1iYXNl ZCBhbmQNCj4gPiA+ID4gPiA+ID4gY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUgVURQIHR1bm5l bCBTSE9VTEQgZW1wbG95IGFuDQo+ID4gPiA+ID4gPiA+IGFwcHJvcHJpYXRlIGNvbmdlc3Rpb24g Y29udHJvbCBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluDQo+ID4gPiA+ID4gPiA+IFtSRkMzOTg1 XS4gTm90ZSB0aGF0IGl0IFNUUk9OR0xZIFJFQ09NTUVOREVEIHRvIGRlcGxveSBzdWNoDQo+ID4g PiA+ID4gPiA+IGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9neSBvbmx5IHdpdGhpbiBhIFNQIG5ldHdv cmsgb3INCj4gPiA+ID4gPiA+ID4gbmV0d29ya3Mgb2YgYW4gYWRqYWNlbnQgc2V0IG9mIGNvLW9w ZXJhdGluZyBTUHMsIHJhdGhlciB0aGFuDQo+ID4gPiA+ID4gPiA+IG92ZXIgdGhlDQo+ID4gPiA+ ID4gSW50ZXJuZXQuDQo+ID4gPiA+ID4gPiA+IEZ1cnRoZXJtb3JlLCBwYWNrZXQgZmlsdGVycyBz aG91bGQgYmUgYWRkZWQgdG8gYmxvY2sgdHJhZmZpYw0KPiA+ID4gPiA+ID4gPiB3aXRoIHRoZSBV RFAgcG9ydCBudW1iZXIgZm9yIE1QTFMgb3ZlciBVRFAgdG8gcHJldmVudCBNUExTDQo+ID4gPiA+ ID4gPiA+IG92ZXIgVURQIHBhY2tldHMgdG8gZXNjYXBlIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlk ZXINCj4gPiA+ID4gPiA+ID4gbmV0d29ya3MgZHVlIHRvIG1pc2NvbmZpZ3VhdGlvbiBvciBwYWNr ZXQNCj4gPiA+ID4gPiA+IGVycm9ycy4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSSB0 aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVzY3JpYmUgdGhlIE9BTSBjb250cm9sIGxvb3AN Cj4gPiA+ID4gPiA+ID4gaW4NCj4gPiA+ID4gPiA+ID4gKHNvbWUpIG1vcmUgZGV0YWlsLCByYXRo ZXIgdGhhbiBwb2ludGluZyB0byBSRkMzOTg1LCB3aGljaA0KPiA+ID4gPiA+ID4gPiBkb2Vzbid0 IGhhdmUgYSB3aG9sZSBsb3Qgb2YgZGV0YWlsIGVpdGhlci4gQWxzbyBiZWNhdXNlIHRoZQ0KPiA+ ID4gPiA+ID4gPiBhZGRpbmcgb2YgZmlyZXdhbGwgcnVsZXMgcmVxdWlyZXMgYW4gT0FNIGhvb2su DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFNpbmNlIFNUUk9OR0xZIFJFQ09NTUVOREVE IGlzIG5vdCBhbiBSRkMyMTE5IHRlcm0gYW5kDQo+ID4gPiA+ID4gPiBSRUNPTU1FTkRFRCBpcw0K PiA+ID4gPiA+ID4gPiB0b28gd2VhaywgSSdkIHN1Z2dlc3QgdG8gY2hhbmdlIHRoaXMgdG8gTVVT VC4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gRmluYWxseSwgdGhlIGFwcGxpY2FiaWxp dHkgc3RhdGVtZW50IHNob3VsZCBiZSBwcm9taW5lbnRseQ0KPiA+ID4gPiA+ID4gPiBtYWRlIGlu IHRoZSBhYnN0cmFjdCwgaW50cm9kdWN0aW9uLCBldGMuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+IExhcnMNCg== From l.wood@surrey.ac.uk Thu Jan 23 23:41:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642E61A01A0 for ; Thu, 23 Jan 2014 23:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 Y_S-w65INVht for ; Thu, 23 Jan 2014 23:41:40 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.173]) by ietfa.amsl.com (Postfix) with ESMTP id AD8DD1A0189 for ; Thu, 23 Jan 2014 23:41:39 -0800 (PST) Received: from [195.245.230.131:25949] by server-13.bemta-3.messagelabs.com id 4D/B4-28603-13912E25; Fri, 24 Jan 2014 07:41:37 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-78.messagelabs.com!1390549296!26893321!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4340 invoked from network); 24 Jan 2014 07:41:36 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-14.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jan 2014 07:41:36 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Fri, 24 Jan 2014 07:41:36 +0000 From: To: , Date: Fri, 24 Jan 2014 07:37:06 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGLe0Vpx4VpP9lE+4fynfG27EApqTPtnwgAASPbeAABBtMIAAAYC7gAADWaCAABZeFg== Message-ID: <290E20B455C66743BE178C5C84F1240847E63346F1@EXMB01CMS.surrey.ac.uk> References: Your message of "Thu, 23 Jan 2014 17:18:22 +0000." <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> <201401240352.s0O3qVia014059@maildrop2.v6ds.occnc.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247954@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346ED@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082479BA@NKGEML512-MBS.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E63346EF@EXMB01CMS.surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082479D6@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082479D6@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 07:41:44 -0000 dGhlIHByb2JsZW0gd2l0aCByZWNvbW1lbmRpbmcgZGlzYWJsaW5nIElQdjQgVURQIGNoZWNrc3Vt cyBpcyB0aGF0IGl0aGUgY2hlY2tzdW0gY2FwYWJpbGl0eSBkb2Vzbid0IGdldCBpbXBsZW1lbnRl ZCwgYW5kIHRoZW4gd2hlbiB5b3UgcnVuIGludG8gcHJvYmxlbXMgeW91IGNhbid0IHR1cm4gY2hl Y2tzdW1zIGJhY2sgb24sIGJlY2F1c2UgdGhlIGNhcGFiaWxpdHkgaXNuJ3QgdGhlcmUuDQoNCkxs b3lkIFdvb2QNCmh0dHA6Ly9hYm91dC5tZS9sbG95ZHdvb2QNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29t XQ0KU2VudDogMjQgSmFudWFyeSAyMDE0IDA2OjM3DQpUbzogV29vZCBMICBEciAoRWxlY3Ryb25p YyBFbmcpOyBjdXJ0aXNAaXB2Ni5vY2NuYy5jb20NCkNjOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tOyBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYu b3JnDQpTdWJqZWN0OiByZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11 ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRh cmQNCg0KR2l2ZW4gdGhlIGZhY3QgdGhhdCB6ZXJvLWNoZWNrc3VtIGZvciBJUHY0IFVEUCB0dW5u ZWwgaGFzIGJlZW4gd2lkZWx5IHVzZWQsIEkgcGVyc29uYWxseSBwcmVmZXIgdG8gdGFrZSB5b3Vy IHN1Z2dlc3RlZCB0ZXh0IGFzIElQdjYgc3BlY2lmaWMgd2hpbGUga2VlcGluZyB0aGUgSVB2NCBV RFAgY2hlY2tzdW0gYmVoYXZpb3IgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBjdXJyZW50IHByYWN0 aWNlLiBJbiBvdGhlciB3b3JkLCAiaW4gdGhlIElQdjQgVURQIGNhc2UsIHRoaXMgY2hlY2tzdW0g ZmllbGQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8iLiBJZiBzb21lIG9wZXJhdG9y cyBhcmUgc3RpbGwgY29uY2VybmVkIHdpdGggdGhlIHJhcmUgcHJvYmxlbSBjYXVzZWQgYnkgSVB2 NCBVRFAgemVyby1jaGVja3N1bSwgdGhleSB3b3VsZCBkaXNhYmxlIHRoZSBjaGVja3N1bS16ZXJv Lg0KDQpYaWFvaHUNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbC53b29kQHN1cnJl eS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ILeiy83KsbzkOiAyMDE0xOox 1MIyNMjVIDE0OjExDQo+IMrVvP7IyzogWHV4aWFvaHU7IGN1cnRpc0BpcHY2Lm9jY25jLmNvbQ0K PiCzrcvNOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29t OyBqb2VsamFAYm9ndXMuY29tOw0KPiBtcGxzQGlldGYub3JnDQo+INb3zOI6IFJFOiBbbXBsc10g TGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5n IE1QTFMNCj4gaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPg0KPiBUaGV5J3JlIG5vdCBp biBjb25mbGljdC4NCj4NCj4gSW4gSVB2NCwgeW91IGhhdmUgdGhlIElQIGhlYWRlciBjaGVja3N1 bSBhcyBhIGNoZWNrIHRoYXQgdGhlIGRlc3RpbmF0aW9uDQo+IGFkZHJlc3MgaXMgcmlnaHQuIFdp dGggYSB6ZXJvIFVEUCBjaGVja3N1bSwgdGhlIHBvcnRzIGFyZW4ndCBjaGVja2VkIC0gYnV0IGlm DQo+IHlvdXIgdHVubmVsIGRlc3RpbmF0aW9uIGhvc3QgaXNuJ3QgcnVubmluZyBvdGhlciBVRFAg YXBwcywgbGltaXRlZCBwcm9ibGVtDQo+DQo+IFdpdGggSVB2NiBhbmQgbm8gaGVhZGVyIGNoZWNr c3VtLCBhZGRyZXNzIGNhbiBiZSBjb3JydXB0ZWQgYXMgd2VsbC4NCj4gVGhlIHBhY2tldCBjYW4g YmUgcmVjZWl2ZWQgb24gb3RoZXIgaG9zdHMgd2hpY2ggY2FuIHJ1biBVRFAuDQo+DQo+IFRoYXQg aXMgd2h5IHRoZSB0ZXh0IHlvdSBxdW90ZSBzYXlzOg0KPiAgICJUaGVyZSBpcyBhbiAgaW5jcmVh c2VkIHJpc2sgb2YgY29ycnVwdGlvbiBhbmQgbWlzZGVsaXZlcnkgd2hlbiB1c2luZyB6ZXJvDQo+ IFVEUA0KPiAgICBjaGVja3N1bSBpbiBJUHY2IGNvbXBhcmVkIHRvIHVzaW5nIElQdjQiDQo+DQo+ IElQdjQgcmlzayBpcyBzbWFsbGVyLCBidXQgbm90IG5vbnplcm8uIFR1cm5pbmcgb2ZmIFVEUCBj aGVja3N1bXMgaW4gdjQgaXMgYWdhaW4NCj4gZm9yIGNvbnZlbmllbmNlLCBhbmQgaGFzIGJlZW4g bW9yZSBjb21tb24gKHdpdGggbG92ZWx5IGV4YW1wbGVzIGdpdmluZw0KPiBwZXJmb3JtYW5jZSBn YWlucyB0aGF0IGNvcnJ1cHQgZGF0YWJhc2UgdHJhbnNhY3Rpb25zKSwgYnV0IHRoZXJlIGlzIHN0 aWxsIHJpc2sNCj4gYXNzb2NpYXRlZCB3aXRoIHR1cm5pbmcgb2ZmIElQdjQgVURQIGNoZWNrc3Vt cy4NCj4NCj4gKEFuZCBpbiBib3RoIHY0IGFuZCB2NiwgYSB6ZXJvIGNoZWNrc3VtIG1lYW5zIHRo YXQgYSBjaGVjayBhY3Jvc3MgdGhlIE1QTFMNCj4gc3RhY2sgaXMgcmVtb3ZlZCwgYW5kIGNvcnJ1 cHRpb24gaW4gdGhhdCBjYW5ub3QgYmUgZGV0ZWN0ZWQpDQo+DQo+IExsb3lkIFdvb2QNCj4gaHR0 cDovL2Fib3V0Lm1lL2xsb3lkd29vZA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEZyb206IFh1eGlhb2h1IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiBTZW50 OiAyNCBKYW51YXJ5IDIwMTQgMDY6MDINCj4gVG86IFdvb2QgTCAgRHIgKEVsZWN0cm9uaWMgRW5n KTsgY3VydGlzQGlwdjYub2NjbmMuY29tDQo+IENjOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tOyBqb2VsamFAYm9ndXMuY29tOw0KPiBtcGxzQGlldGYu b3JnDQo+IFN1YmplY3Q6IHJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWlu LXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMNCj4gaW4gVURQKSB0byBQcm9wb3NlZCBT dGFuZGFyZA0KPg0KPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ILeivP7IyzogbC53b29kQHN1 cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ID4gt6LLzcqxvOQ6IDIw MTTE6jHUwjI0yNUgMTM6MDENCj4gPiDK1bz+yMs6IFh1eGlhb2h1OyBjdXJ0aXNAaXB2Ni5vY2Nu Yy5jb20NCj4gPiCzrcvNOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0Bu ZXRhcHAuY29tOw0KPiA+IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiDW98zi OiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0K PiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ DQo+ID4gSSB3b3VsZCBiZSBnb29kIHdpdGg6DQo+ID4NCj4gPiAiR2VuZXJhbGx5IHNwZWFraW5n LCBhIFVEUCBjaGVja3N1bSBTSE9VTEQgYmUgdXNlZC4gVGhlIGNvbnNpZGVyYXRpb25zDQo+ID4g ZGVzY3JpYmVkIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0gU0hPVUxEIGJlIGV4YW1pbmVkIGlmIFVE UCBjaGVja3N1bXMNCj4gPiBuZWVkIHRvIGJlIGRpc2FibGVkIGZvciBwZXJmb3JtYW5jZSBvciBp bXBsZW1lbnRhdGlvbiByZWFzb25zIGZvcg0KPiA+IHRyYWZmaWMgYWNyb3NzIHByaXZhdGUgbmV0 d29ya3MuIFRoZSB1c2Ugb2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBpcyBOT1QNCj4gPiBSRUNPTU1F TkRFRC4iDQo+ID4NCj4gPiBJIHdvdWxkbid0IG1ha2UgdGhpcyBJUHY2IHNwZWNpZmljIC0gSVB2 NCBzdGlsbCBoYXMgcHJvYmxlbXMgKFVEUCBwb3J0DQo+ID4gZGVtdXgpLCBJUHY2J3MgcHJvYmxl bXMgYXJlIGp1c3Qgd29yc2UuDQo+DQo+IElmIG5vdCBJUHY2IHNwZWNpZmljLCBpdCBzZWVtcyBj b25mbGljdCB3aXRoIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50IHF1b3RlZCBmcm9tDQo+IFJGQzY5 MzY6DQo+DQo+ICAgIFRoZSB1c2Ugb2YgVURQIHdpdGggYSB6ZXJvIFVEUCBjaGVja3N1bSBoYXMg bWVyaXRzIGZvcg0KPiAgICBzb21lIGFwcGxpY2F0aW9ucywgc3VjaCBhcyB0dW5uZWwgZW5jYXBz dWxhdGlvbiwgYW5kIGlzIHdpZGVseSB1c2VkDQo+ICAgIGluIElQdjQuICBIb3dldmVyLCB0aGVy ZSBhcmUgZGlmZmVyZW50IGRhbmdlcnMgZm9yIElQdjYuICBUaGVyZSBpcyBhbg0KPiAgICBpbmNy ZWFzZWQgcmlzayBvZiBjb3JydXB0aW9uIGFuZCBtaXNkZWxpdmVyeSB3aGVuIHVzaW5nIHplcm8g VURQDQo+ICAgIGNoZWNrc3VtIGluIElQdjYgY29tcGFyZWQgdG8gdXNpbmcgSVB2NCBkdWUgdG8g dGhlIGxhY2sgb2YgYW4gSVB2Ng0KPiAgICBoZWFkZXIgY2hlY2tzdW0uDQo+DQo+IFhpYW9odQ0K Pg0KPiA+IExsb3lkIFdvb2QNCj4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206IFh1eGlhb2h1 IFt4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwNDowMA0K PiA+IFRvOiBjdXJ0aXNAaXB2Ni5vY2NuYy5jb207IFdvb2QgTCAgRHIgKEVsZWN0cm9uaWMgRW5n KQ0KPiA+IENjOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAu Y29tOw0KPiA+IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBy ZTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+DQo+ ID4gSGksDQo+ID4NCj4gPiBQbGVhc2UgY2hlY2sgd2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQg aXMgT0suDQo+ID4NCj4gPiBJbiB0aGUgSVB2NiBVRFAgZW5jYXBzdWxhdGlvbiBjYXNlLCBhcyBm b3Igd2hldGhlciBvciBub3QgaXQgaXMNCj4gPiBzdWl0YWJsZSB0byB1c2UgdGhlIHplcm8tY2hl Y2tzdW0gbm9kZSwgdGhlIHJlcXVpcmVtZW50cyBkZWZpbmVkIGluDQo+ID4gW1JGQzY5MzVdIFtS RkM2OTM2XSBTSE9VTEQgYmUgc3RyaWN0bHkgZm9sbG93ZWQuIEdlbmVyYWxseSBzcGVha2luZywN Cj4gPiB0aGUgdXNlIG9mIGEgemVybyBVRFAgY2hlY2tzdW0gaXMgTk9UIFJFQ09NTUVOREVELiBO b3RlIHRoYXQgb3RoZXIgSVANCj4gPiBlbmNhcHN1bGF0aW9ucyBmb3IgTVBMUyBkbyBub3QgaGF2 ZSBhIGNoZWNrc3VtIGluIHRoZSB0dW5uZWwgaGVhZGVyLg0KPiA+DQo+ID4gQmVzdCByZWdhcmRz LA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ILeivP7I yzogQ3VydGlzIFZpbGxhbWl6YXIgW21haWx0bzpjdXJ0aXNAaXB2Ni5vY2NuYy5jb21dDQo+ID4g PiC3osvNyrG85DogMjAxNMTqMdTCMjTI1SAxMTo1Mw0KPiA+ID4gytW8/sjLOiBsLndvb2RAc3Vy cmV5LmFjLnVrDQo+ID4gPiCzrcvNOiBYdXhpYW9odTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb207IGxhcnNAbmV0YXBwLmNvbTsNCj4gPiA+IGpvZWxqYUBib2d1cy5jb207IG1wbHNA aWV0Zi5vcmcNCj4gPiA+INb3zOI6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1t cGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8g UHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+DQo+ID4gPg0KPiA+ID4gSW4gbWVzc2FnZQ0KPiA+ID4N Cj4gPg0KPiA8MjkwRTIwQjQ1NUM2Njc0M0JFMTc4QzVDODRGMTI0MDg0N0U2MzM0NkUzQEVYTUIw MUNNUy5zdXJyZXkuYQ0KPiA+ID4gYy51az4NCj4gPiA+IGwud29vZEBzdXJyZXkuYWMudWsgd3Jp dGVzOg0KPiA+ID4NCj4gPiA+ID4gdGhlIHRleHQgaXMgbm90IHNhdGlzZmFjdG9yeS4gbmV2ZXIg cmVjb21tZW5kIHNldHRpbmcgdG8gemVybywgYXMNCj4gPiA+ID4gdGhhdCBwb3NlcyBhIHJpc2sg dG8geW91ciBhbmQgdG8gb3RoZXIgdHJhZmZpYy4gU3VnZ2VzdGVkIHRleHQ6DQo+ID4gPiA+ICoq Kg0KPiA+ID4gPiBUaGUgVURQIGNoZWNrc3VtIFNIT1VMRCBiZSB1c2VkIHRvIHByb3RlY3QgdGhl IHBheWxvYWQgYW5kIGVuc3VyZQ0KPiA+ID4gPiBjb3JyZWN0IGRlbXVsdGlwbGV4aW5nIGFuZCBk ZWxpdmVyeSB0byB0aGUgdHVubmVsLCBhbmQgbm90IHRvDQo+ID4gPiA+IG90aGVyIFVEUCBkZXN0 aW5hdGlvbnMsIGJ5IHByb3RlY3RpbmcgdGhlIFVEUCBwc2V1ZG9oZWFkZXIuDQo+ID4gPiA+IFVz ZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzIE5PVCBSRUNPTU1FTkRFRCwgZXZlbiB3aGVuIGRl c2lyZWQNCj4gPiA+ID4gZm9yIHBlcmZvcm1hbmNlIG9yIG5lY2Vzc2l0YXRlZCBieSBpbXBsZW1l bnRhdGlvbiByZWFzb25zLCBmb3IgdGhlDQo+ID4gPiA+IHJlYXNvbnMgb3V0bGluZWQgaW4gW1JG QzY5MzZdIHNlY3Rpb24gMy4NCj4gPiA+DQo+ID4gPiBJIGFncmVlIHRoYXQgVURQIGNoZWNrc3Vt cyBTSE9VTEQgYmUgdXNlZCAoaWU6IFNIT1VMRCBOT1QgYmUgc2V0IHRvDQo+IHplcm8pLg0KPiA+ ID4gVGhlcmUgYXJlIGNhc2VzIHdoZXJlIGl0IGlzIGltcG9zc2libGUgc28gaXQgY2FuJ3QgYmUg TVVTVC4NCj4gPiA+DQo+ID4gPiA+IFVEUC1MaXRlIFtSRkMzODI4XSBjYW4gcHJvdmlkZSBhIGRl bXVsdGlwbGV4aW5nIGNoZWNrIGFuZCBNUExTDQo+ID4gPiA+IHN0YWNrIGludGVncml0eSBjaGVj ayB3aGlsZSBhdm9pZGluZyB0aGUgb3ZlcmhlYWQgb2YgY29tcHV0aW5nIGFuDQo+ID4gPiA+IGlu dGVncml0eSBjaGVjayBvdmVyIGEgdHVubmVsbGVkIGZyYW1lIHRoYXQgaGFzIGl0cyBvd24gaW50 ZWdyaXR5IGNoZWNrLg0KPiA+ID4NCj4gPiA+IFVEUC1MaXN0IGRvZXNuJ3Qgc29sdmUgdGhlIEVD TVAgcHJvYmxlbXMgYmVjYXVzZSBtb3N0IG9mIHRoZSBvbGRlcg0KPiA+ID4gTFNSIHRoYXQgYXJl IGZvcmNpbmcgdGhlIHVzZSBvZiBNUExTIG92ZXIgVURQIHRvIGdldCBFQ01QIGRvbid0IGxvb2sN Cj4gPiA+IGF0IHRoZSBwb3J0IG51bWJlcnMgaWYgdGhlIHByb3RvY29sIGlzIG5vdCA2IG9yIDE3 LiAgQnV0IHRoaXMgaGFzDQo+ID4gPiBvbmx5IGJlZW4gc2FpZCB0aHJlZSBvciBmb3VyIHRpbWVz IHNvIG1heWJlIHlvdSBtaXNzZWQgaXQuDQo+ID4gPg0KPiA+ID4gPiAqKioNCj4gPiA+ID4NCj4g PiA+ID4gTGxveWQgV29vZA0KPiA+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4g PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRnJv bTogWHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiA+IFNlbnQ6IDIzIEphbnVh cnkgMjAxNCAxMjozNQ0KPiA+ID4gPiBUbzogV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpOyBB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsNCj4gPiA+ID4gbGFyc0BuZXRhcHAuY29t DQo+ID4gPiA+IENjOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+IFN1 YmplY3Q6IHJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50 eHQ+DQo+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFu ZGFyZA0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ID4gPiA+ILei vP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJyZXkuYWMudWtdDQo+ ID4gPiA+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjIzyNUgMTI6NDQNCj4gPiA+ID4gPiDK1bz+yMs6 IFh1eGlhb2h1OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsNCj4gbGFyc0BuZXRh cHAuY29tDQo+ID4gPiA+ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0K PiA+ID4gPiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWlu LXVkcC0wNC50eHQ+DQo+ID4gPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFBy b3Bvc2VkIFN0YW5kYXJkDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBTYXNoYQ0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiAtIFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhlcmVvZikgaXMgYSBub24taXNz dWUgYmVjYXVzZQ0KPiA+ID4gPiA+ID4gbmF0aXZlIE1QTFMgZG9lcyBub3QgaGF2ZSBhbnl0aGlu ZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlDQo+ID4gPiA+ID4gPiBhcmUgY2FzZXMgd2hlcmUg cGFja2V0cyBhcmUgY29ycnVwdGVkIHdpdGhpbiB0aGUgcm91dGVycykNCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IFNvIHlvdSBhZG1pdCB0aGF0IHBhY2tldHMgY2FuIGJlIGNvcnJ1cHRlZCB3aXRoaW4g dGhlIHJvdXRlcnMgLQ0KPiA+ID4gPiA+IGEgY2hlY2sgdGhhdCBjYW4gb25seSBiZSBjYXVnaHQg YnkgYW4gZW5kLXRvLWVuZCBjaGVjaywgYQ0KPiA+ID4gPiA+IGNvcnJ1cHRpb24gdGhhdCBjYW4g bGVhZCB0byB0aGUgcHJvYmxlbXMgZGV0YWlsZWQgaW4gUkZDIDY5MzYNCj4gPiA+ID4gPiBzZWN0 aW9uIDMgLSBhbmQgdGhlbiB5b3Ugc2F5IGl0J3MgYSBub24taXNzdWUgYmVjYXVzZSB0aGlzDQo+ ID4gPiA+ID4gZG9lc24ndCBhZmZlY3QgbmF0aXZlIE1QTFMuIEJ1dA0KPiA+ID4gd2UncmUgbm90 IGRvaW5nIG5hdGl2ZSBNUExTIGhlcmUuDQo+ID4gPiA+ID4gV2UncmUgZG9pbmcgTVBMUyBvdmVy IFVEUC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0 IGlzIGFib3V0IHR1bm5lbGxpbmcgTVBMUyBpbiBVRFAuIEl0J3MgYW4NCj4gaXNzdWUuDQo+ID4g PiA+ID4gUGxlYXNlIHJlYWQgdGhlIG90aGVyIDE1MCBtZXNzYWdlcyB0aGF0IHlvdSByZWZlciB0 by4NCj4gPiA+ID4NCj4gPiA+ID4gSGkgTGxveWQsDQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBkcmFm dCBkb2Vzbid0IHJlcXVpcmUgdGhlIElQdjYgVURQIGNoZWNrc3VtIHRvIGJlIHNldCB0byB6ZXJv DQo+ID4gcmVnYXJkbGVzcy4NCj4gPiA+IFNlZSB0aGUgZm9sbG93aW5nIHRleHQgcXVvdGVkIGZy b20gdGhhdCBkcmFmdDoNCj4gPiA+ID4NCj4gPiA+ID4gVURQIENoZWNrc3VtDQo+ID4gPiA+DQo+ ID4gPiA+IFRoZSB1c2FnZSBvZiB0aGlzIGZpZWxkIGlzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUg Y3VycmVudCBVRFANCj4gPiA+ID4gc3BlY2lmaWNhdGlvbg0KPiA+ID4gW1JGQzc2OF0uIFRvIHNp bXBsaWZ5IHRoZSBvcGVyYXRpb24gb24gdGhlIGRlY2Fwc3VsYXRvciwgdGhpcyBmaWVsZA0KPiA+ ID4gaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gaW4gSVB2NCBVRFAgZW5jYXBzdWxh dGlvbiBjYXNlLiBJbg0KPiA+ID4gdGhlDQo+ID4gPiBJUHY2IFVEUCBlbmNhcHN1bGF0aW9uIGNh c2UsIGlmIGFwcHJvcHJpYXRlIGFjY29yZGluZyB0byB0aGUNCj4gPiA+IHJlcXVpcmVtZW50cyBk ZWZpbmVkIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0sIHRoaXMgZmllbGQgaXMgYWxzbw0KPiA+IFJF Q09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvLg0KPiA+ID4gU3BlY2lmaWNhbGx5LCBpZiB0aGUg TVBMUyBwYXlsb2FkIGlzIEludGVybmV0IFByb3RvY29sIChJUHY0IG9yDQo+ID4gPiBJUHY2KSBw YWNrZXRzLCBpdCBpcyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVybyB3aGVuIHRoZSBpbm5l cg0KPiA+ID4gcGFja2V0IGludGVncml0eSBjaGVja3MgaXMgYXZhaWxhYmxlLiBJbiBhZGRpdGlv biwgaWYgdGhlIE1QTFMNCj4gPiA+IHBheWxvYWQgaXMgbm9uLUlQIHBhY2tldCB3aGljaCBpcyBz cGVjaWZpY2FsbHkgZGVzaWduZWQgZm9yDQo+ID4gPiB0cmFuc21pc3Npb24gb3ZlciBhIGxvd2Vy IGxheWVyIHRoYXQgZG9lcyBub3QgcHJvdmlkZSBhIHBhY2tldA0KPiA+ID4gaW50ZWdyaXR5IGd1 YXJhbnRlZSwgaXQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gYXMgd2VsbC4NCj4g PiA+IE90aGVyd2lzZSwgdXNpbmcgemVybyBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQuIE5v dGUgdGhhdCBvdGhlcg0KPiA+ID4gSVAgZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMgZG8gbm90DQo+ ID4gaGF2ZSBhIGNoZWNrc3VtIGluIHRoZSB0dW5uZWwgaGVhZGVyLg0KPiA+ID4gPg0KPiA+ID4g PiBJZiB5b3Ugc3RpbGwgYmVsaWV2ZSB0aGUgYWJvdmUgdGV4dCBpcyBub3Qgc2F0aXNmYWN0b3J5 LCBwbGVhc2UgcHJvdmlkZSB5b3VyDQo+IHRleHQuDQo+ID4gPiA+DQo+ID4gPiA+IEJlc3QgcmVn YXJkcywNCj4gPiA+ID4gWGlhb2h1DQo+ID4gPiA+DQo+ID4gPiA+ID4gTGxveWQgV29vZA0KPiA+ ID4gPiA+IGh0dHA6Ly9hYm91dC5tZS9sbG95ZHdvb2QNCj4gPiA+ID4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gRnJvbTogbXBscyBbbXBscy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNCj4gPiA+ID4gPiBbeHV4aWFv aHVAaHVhd2VpLmNvbV0NCj4gPiA+ID4gPiBTZW50OiAyMyBKYW51YXJ5IDIwMTQgMDM6MTYNCj4g PiA+ID4gPiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47IEVnZ2VydCwgTGFycw0KPiA+ID4gPiA+ IENjOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBSZTog W21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4g PiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gSGkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS3Tyrz+1K28 /i0tLS0tDQo+ID4gPiA+ID4gPiC3orz+yMs6IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+ID4gPiA+ ID4gPiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ID4gPiA+ ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjIyyNUgMTk6MDUNCj4gPiA+ID4gPiA+IMrVvP7IyzogRWdn ZXJ0LCBMYXJzDQo+ID4gPiA+ID4gPiCzrcvNOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmc7 IFh1eGlhb2h1DQo+ID4gPiA+ID4gPiDW98ziOiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtbXBscy1pbi11ZHAtMDQudHh0Pg0KPiA+ID4gPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBM UyBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g TGFycyBhbmQgYWxsLA0KPiA+ID4gPiA+ID4gTGFzdCB0aW1lIEkndmUgY291bnRlZCB0aGUgSUVU RiBMQyB0aHJlYWQgb24gdGhpcyBkcmFmdCBoYXMNCj4gPiA+ID4gPiA+IG1vcmUgdGhhbg0KPiA+ ID4gPiA+ID4gMTUwIG1lc3NhZ2VzIGluIGl0LCBhbmQgaXQgc2VlbXMgdGhhdCBvbiBzb21lIGlz c3Vlcw0KPiA+ID4gPiA+ID4gKGNvbmdlc3Rpb24gY29udHJvbCBhbmQgVURQDQo+ID4gPiA+ID4g PiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyByb3VuZCB0aGUgbXVsYmVycnkgYnVzaC4NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiBJTUhPIGFuZCBGV0lXOg0KPiA+ID4gPiA+ID4gLSBVRFAgY2hl Y2tzdW1zIChvciBsYWNrIHRoZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJlY2F1c2UNCj4gPiA+ID4g PiA+IG5hdGl2ZSBNUExTIGRvZXMgbm90IGhhdmUgYW55dGhpbmcgbGlrZSB0aGF0LiBBbmQgeWVz LCB0aGVyZQ0KPiA+ID4gPiA+ID4gYXJlIGNhc2VzIHdoZXJlIHBhY2tldHMgYXJlIGNvcnJ1cHRl ZCB3aXRoaW4gdGhlIHJvdXRlcnMpLCBidXQNCj4gPiA+ID4gPiA+IHNvIGZhciBpdCBkaWQgbm90 IHByZXZlbnQgTVBMUyBkZXBsb3ltZW50LiBUaGVyZSBpcywgZS5nLiwgUkZDDQo+ID4gPiA+ID4g PiA0NzIwIGZvciBGQ1MgcmV0ZW50aW9uIGluIFBXcywgYnV0IEkgZG91YnQgaXQgaXMgd2lkZWx5 DQo+ID4gPiA+ID4gPiBpbXBsZW1lbnRlZCBhbmQgZGVwbG95ZWQgKHdvdWxkIGJlIG5pY2UgdG8N Cj4gPiA+ID4gPiBrbm93KS4NCj4gPiA+ID4gPiA+IC0gRTJFIGNvbmdlc3Rpb24gY29udHJvbCAo cmVnYXJkbGVzcyBvZiBpdHMgaW1wbGljYXRpb25zKQ0KPiA+ID4gPiA+ID4gc2ltcGx5IGNhbm5v dCBiZSBhZGRlZCB0byB0aGlzIHByb3RvY29sIHdpdGhvdXQgc29tZSBtYWpvcg0KPiA+ID4gPiA+ ID4gY2hhbmdlcy4gQSBzaG9ydCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBleHBsYWluaW5nIHRo YXQgc2hvdWxkIHN1ZmZpY2UNCj4gSU1PLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSGkgU2FzaGEs DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGZ1bGx5IGFncmVlIHdpdGggeW91ciBwb2ludHMuDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiA+ID4gWGlhb2h1DQo+ID4g PiA+ID4NCj4gPiA+ID4gPiA+IE15IDJjLA0KPiA+ID4gPiA+ID4gICAgICAgIFNhc2hhDQo+ID4g PiA+ID4gPiBFbWFpbDogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gPiA+ID4g PiA+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+IEZyb206IG1wbHMgW21haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+ID4gPiA+ID4gPiBFZ2dlcnQs IExhcnMNCj4gPiA+ID4gPiA+ID4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIyLCAyMDE0IDEy OjIzIFBNDQo+ID4gPiA+ID4gPiA+IFRvOiBYdXhpYW9odQ0KPiA+ID4gPiA+ID4gPiBDYzogSm9l bCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBs c10gTGFzdCBDYWxsOg0KPiA+ID4gPiA+ID4gPiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50 eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKQ0KPiA+ID4gPiA+ID4gPiB0byBQcm9wb3Nl ZCBTdGFuZGFyZA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBIaSwNCj4gPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ID4gT24gMjAxNC0xLTIyLCBhdCAxMToxMiwgWHV4aWFvaHUgPHh1eGlh b2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ID4gPiA+ID4gPiA+IEkgd29uZGVyIHdoZXRoZXIg dGhlIGZvbGxvd2luZyB0ZXh0IGlzIE9LIHRvIHlvdToNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPiA+IFNpbmNlIHRoZSBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uIGNhdXNlcyBNUExT IHBhY2tldHMgdG8NCj4gPiA+ID4gPiA+ID4gPiBiZQ0KPiA+ID4gPiA+ID4gPiBmb3J3YXJkZWQg dGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250cm9sDQo+ID4gPiA+ID4g PiA+IGd1aWRlbGluZXMgZm9yIFVEUCB0dW5uZWxzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEu MyBvZg0KPiA+ID4gPiA+ID4gPiBbUkZDNTQwNV0gU0hPVUxEIGJlDQo+ID4gPiA+ID4gZm9sbG93 ZWQuDQo+ID4gPiA+ID4gPiA+IFNwZWNpZmljYWxseSwgTVBMUyBjYW4gY2FycnkgYSBudW1iZXIg b2YgZGlmZmVyZW50IHByb3RvY29scw0KPiA+ID4gPiA+ID4gPiBhcw0KPiA+IHBheWxvYWRzLg0K PiA+ID4gPiA+ID4gPiBXaGVuIGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2Fk IHRyYWZmaWMgdGhhdCBpcw0KPiA+ID4gPiA+ID4gPiBrbm93biBhdCBjb25maWd1cmF0aW9uIHRp bWUgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gPiA+IGNvbmdlc3Rpb24tY29udHJvbGxl ZCwgdGhlIFVEUCB0dW5uZWwgU0hPVUxEIE5PVCBlbXBsb3kgaXRzDQo+ID4gPiA+ID4gPiA+IG93 biBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLCBiZWNhdXNlIGNvbmdlc3Rpb24gbG9zc2Vz DQo+ID4gPiA+ID4gPiA+IG9mIHR1bm5lbGVkIHRyYWZmaWMgd2lsbCB0cmlnZ2VyIGFuIGNvbmdl c3Rpb24gcmVzcG9uc2UgYXQNCj4gPiA+ID4gPiA+ID4gdGhlIG9yaWdpbmFsDQo+ID4gPiBzZW5k ZXJzIG9mIHRoZSB0dW5uZWxlZCB0cmFmZmljLg0KPiA+ID4gPiA+ID4gPiBXaGVuIGFuIFVEUCB0 dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhhdCBpcw0KPiA+ID4gPiA+ ID4gPiBrbm93biBhdCBjb25maWd1cmF0aW9uIHRpbWUgbm90IHRvIGJlIElQLWJhc2VkIGFuZA0K PiA+ID4gPiA+ID4gPiBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFAgdHVubmVsIFNIT1VM RCBlbXBsb3kgYW4NCj4gPiA+ID4gPiA+ID4gYXBwcm9wcmlhdGUgY29uZ2VzdGlvbiBjb250cm9s IG1lY2hhbmlzbSBhcyBkZXNjcmliZWQgaW4NCj4gPiA+ID4gPiA+ID4gW1JGQzM5ODVdLiBOb3Rl IHRoYXQgaXQgU1RST05HTFkgUkVDT01NRU5ERUQgdG8gZGVwbG95IHN1Y2gNCj4gPiA+ID4gPiA+ ID4gZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IG9ubHkgd2l0aGluIGEgU1AgbmV0d29yayBvcg0K PiA+ID4gPiA+ID4gPiBuZXR3b3JrcyBvZiBhbiBhZGphY2VudCBzZXQgb2YgY28tb3BlcmF0aW5n IFNQcywgcmF0aGVyIHRoYW4NCj4gPiA+ID4gPiA+ID4gb3ZlciB0aGUNCj4gPiA+ID4gPiBJbnRl cm5ldC4NCj4gPiA+ID4gPiA+ID4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3VsZCBi ZSBhZGRlZCB0byBibG9jayB0cmFmZmljDQo+ID4gPiA+ID4gPiA+IHdpdGggdGhlIFVEUCBwb3J0 IG51bWJlciBmb3IgTVBMUyBvdmVyIFVEUCB0byBwcmV2ZW50IE1QTFMNCj4gPiA+ID4gPiA+ID4g b3ZlciBVRFAgcGFja2V0cyB0byBlc2NhcGUgZnJvbSB0aGUgc2VydmljZSBwcm92aWRlcg0KPiA+ ID4gPiA+ID4gPiBuZXR3b3JrcyBkdWUgdG8gbWlzY29uZmlndWF0aW9uIG9yIHBhY2tldA0KPiA+ ID4gPiA+ID4gZXJyb3JzLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBJIHRoaW5rIGl0 IHdvdWxkIGJlIGJldHRlciB0byBkZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wgbG9vcA0KPiA+ID4g PiA+ID4gPiBpbg0KPiA+ID4gPiA+ID4gPiAoc29tZSkgbW9yZSBkZXRhaWwsIHJhdGhlciB0aGFu IHBvaW50aW5nIHRvIFJGQzM5ODUsIHdoaWNoDQo+ID4gPiA+ID4gPiA+IGRvZXNuJ3QgaGF2ZSBh IHdob2xlIGxvdCBvZiBkZXRhaWwgZWl0aGVyLiBBbHNvIGJlY2F1c2UgdGhlDQo+ID4gPiA+ID4g PiA+IGFkZGluZyBvZiBmaXJld2FsbCBydWxlcyByZXF1aXJlcyBhbiBPQU0gaG9vay4NCj4gPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gU2luY2UgU1RST05HTFkgUkVDT01NRU5ERUQgaXMgbm90 IGFuIFJGQzIxMTkgdGVybSBhbmQNCj4gPiA+ID4gPiA+IFJFQ09NTUVOREVEIGlzDQo+ID4gPiA+ ID4gPiA+IHRvbyB3ZWFrLCBJJ2Qgc3VnZ2VzdCB0byBjaGFuZ2UgdGhpcyB0byBNVVNULg0KPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBGaW5hbGx5LCB0aGUgYXBwbGljYWJpbGl0eSBzdGF0 ZW1lbnQgc2hvdWxkIGJlIHByb21pbmVudGx5DQo+ID4gPiA+ID4gPiA+IG1hZGUgaW4gdGhlIGFi c3RyYWN0LCBpbnRyb2R1Y3Rpb24sIGV0Yy4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g TGFycw0K From lars@netapp.com Fri Jan 24 00:02:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724881A01D1 for ; Fri, 24 Jan 2014 00:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 BiiAW4xk2X7L for ; Fri, 24 Jan 2014 00:02:42 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id E9D531A01C6 for ; Fri, 24 Jan 2014 00:02:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,711,1384329600"; d="scan'208";a="97848096" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 24 Jan 2014 00:02:40 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 00:02:40 -0800 From: "Eggert, Lars" To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGLxZFyKjVtdEy02x6qUpK40JLJqUCe8A Date: Fri, 24 Jan 2014 08:02:39 +0000 Message-ID: <78AE1B8C-AC1C-42D6-AF8B-129F7442836C@netapp.com> References: <201401240425.s0O4PjO9014541@maildrop2.v6ds.occnc.com> In-Reply-To: <201401240425.s0O4PjO9014541@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <58718F792E071F47AE07DF2310907C90@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Joel Jaeggli , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 08:02:43 -0000 Curtis, On 2014-1-24, at 5:25, Curtis Villamizar wrote: > Help me out here Lloyd. Previously on this thread Lars was vigorously > arguing that we needed to follow years of IETF consensus about UDP > checksums. you must have me confused with someone else (there were a lot of messages.) None of my emails on draft-ietf-mpls-in-udp even mentioned checksums. Lars From internet-drafts@ietf.org Fri Jan 24 00:19:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C391A014B; Fri, 24 Jan 2014 00:19:03 -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 pxNQT_EI3RzZ; Fri, 24 Jan 2014 00:19:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE721A0140; Fri, 24 Jan 2014 00:19:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124081900.28565.6162.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 00:19:00 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 08:19:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Encapsulating MPLS in UDP Authors : Xiaohu Xu Nischal Sheth Lucy Yong Carlos Pignataro Yongbing Fan Filename : draft-ietf-mpls-in-udp-05.txt Pages : 10 Date : 2014-01-24 Abstract: This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol). Note that the MPLS-in-UDP encapsulation technology MUST only be deployed within a service provider network or networks of an adjacent set of co-operating service providers where the congestion control is not a concern. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-in-udp-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 xuxiaohu@huawei.com Fri Jan 24 00:34:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE861A0199 for ; Fri, 24 Jan 2014 00:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 VXuMsTqzJaIv for ; Fri, 24 Jan 2014 00:34:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 969711A014B for ; Fri, 24 Jan 2014 00:33:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCW45002; Fri, 24 Jan 2014 08:33:57 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 08:33:50 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 08:33:56 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 16:33:50 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: New Version Notification - draft-ietf-mpls-in-udp-05.txt Thread-Index: AQHPGN0CRIJN/zeWNk66TstAxB0Be5qTi+jw Date: Fri, 24 Jan 2014 08:33:49 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247A2B@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] fwd: New Version Notification - draft-ietf-mpls-in-udp-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 08:34:02 -0000 SGkgYWxsLA0KDQpBIG5ldyB2ZXJzaW9uICgtMDUpIGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgZHJh ZnQtaWV0Zi1tcGxzLWluLXVkcDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDUudHh0IA0KDQpEaWZmIGZyb20gcHJldmlvdXMgdmVy c2lvbjoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1p bi11ZHAtMDUNCg0KVGhlIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyByZWNlaXZlZCBkdXJpbmcg dGhlIExhc3QgQ2FsbCBoYXMgYmVlbiBpbmNvcnBvcmF0ZWQgaW4gdGhpcyByZXZpc2lvbiwgZXNw ZWNpYWxseSB0aGUgcm91Z2ggY29uc2Vuc3VzIG9uIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgY2hl Y2tzdW0uIFRoYW5rcyBhIGxvdCBmb3IgdGhvc2UgcGVvcGxlIHdobyBoYXZlIGNvbnRyaWJ1dGVk IHRoZWlyIHRpbWUgYW5kIGVuZXJneSB0byByZXZpZXcgYW5kIGhlbHAgaW1wcm92aW5nIHRoaXMg ZG9jLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUgKG9uIGJlaGFsZiBvZiBhbGwgY28tYXV0aG9y cykNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiDlj5HpgIHm l7bpl7Q6IDIwMTTlubQx5pyIMjTml6UgMTY6MTkNCj4g5pS25Lu25Lq6OiBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsNCj4g YWRyaWFuQG9sZGRvZy5jby51aw0KPiDkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAt IGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDUudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiAo LTA1KSBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIGRyYWZ0LWlldGYtbXBscy1pbi11ZHA6DQo+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy1pbi11ZHAt MDUudHh0DQo+IA0KPiBTdWIgc3RhdGUgaGFzIGJlZW4gY2hhbmdlZCB0byBBRCBGb2xsb3d1cCBm cm9tIFJldmlzZWQgSUQgTmVlZGVkDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgcGFn ZSBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC8NCj4gDQo+IERpZmYgZnJvbSBwcmV2aW91 cyB2ZXJzaW9uOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LW1wbHMtaW4tdWRwLTA1DQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+IA0KPiBJRVRGIFNlY3JldGFyaWF0Lg0KDQo= From ietf-secretariat-reply@ietf.org Fri Jan 24 05:05:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E4A1A0347 for ; Fri, 24 Jan 2014 05:05:12 -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 8bCjZ98QIwZX for ; Fri, 24 Jan 2014 05:05:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3042C1A034E for ; Fri, 24 Jan 2014 05:05:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124130505.31810.26319.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 05:05:05 -0800 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 13:05:12 -0000 Changed milestone "Submit draft-ietf-mpls-moving-iana-registries for publication", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Fri Jan 24 05:09:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039091A0347 for ; Fri, 24 Jan 2014 05:09:58 -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 ryOKGjc6Jifa for ; Fri, 24 Jan 2014 05:09:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A861B1A034E for ; Fri, 24 Jan 2014 05:09:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124130955.13453.4892.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 05:09:55 -0800 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 13:09:58 -0000 Changed milestone "Submit draft-ietf-mpls-tp-p2mp-framework for publication", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From gdaley@au.logicalis.com Thu Jan 23 19:38:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED461A012A; Thu, 23 Jan 2014 19:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.535, 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 kSGdqo_qWe88; Thu, 23 Jan 2014 19:38:48 -0800 (PST) Received: from smtp2.au.logicalis.com (smtp2.au.logicalis.com [203.8.7.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0721A0117; Thu, 23 Jan 2014 19:38:48 -0800 (PST) Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp2.au.logicalis.com with ESMTP; 24 Jan 2014 14:38:47 +1100 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0347.000; Fri, 24 Jan 2014 14:38:45 +1100 From: Greg Daley To: "'Joel M. Halpern'" , Joe Touch , Edward Crabbe Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF5eBZzPPQlRcgk6ua2U45NfiYJqQTqiAgAHKKoCAAL8zyf//mUCAgAC+CKA= Date: Fri, 24 Jan 2014 03:38:44 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D992817FD35E1@sdcexchms.au.logicalis.com> References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> <52E1D093.8040603@joelhalpern.com> In-Reply-To: <52E1D093.8040603@joelhalpern.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.183] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 24 Jan 2014 05:10:23 -0800 Cc: "mpls@ietf.org" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 03:38:51 -0000 Hi Joel,=20 > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, 24 January 2014 1:32 PM > To: Joe Touch; Edward Crabbe > Cc: mpls@ietf.org; Noel Chiappa; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsula= ting > MPLS in UDP) to Proposed Standard >=20 > Joe, while your argument is internally consistent, it is not consistent w= ith > history. We have not demanded that tunnel entries behave fully like sour= ce > hosts for any of the other myriad kinds of tunnels we have done over the = years. Actually, many of the tunnel protocols on the standards track have been eit= her for upper-layer IP or Transport protocols or require congestion mitigat= ion: RFC 4448 for EoMPLS, and 5994 for Ethernet pseudowires over MPLS each ask t= hat tunnelled protocols support congestion mechanisms, RFC5085 and 5586: VCCV and BFD with VCCV define congestion considerations = for pseudowire tunnels. RFC 4719 updated by RFC 5641: Ethernet pseudowires over L2TP (a UDP encapsu= lated protocol) permit packet loss indications to take down the active cir= cuit.=20 RFC 4454: ATM over L2TPv3 indicates that inelastic flows are stopped when c= ongestion occurs. They (ATM over L2TPv3 and Ethernet PW over L2TPv3) also require usage over = a traffic engineered network. RFC 4817 MPLS over L2TPv3 requires non-IP upper layer protocols not to exce= ed the offered load of a typical TCP application on the same path. For those protocols which have IP, UDP, TCP, SCCP or DCCP this is just pass= ing the buck to the upper layer protocol (which is OK, so long as the appli= cation protocol in UDP has congestion measures). For environments where thi= s cannot be relied upon, additional protocol specification and applicabilit= y statements have previously been applied. > If we take your logic as stated, then the usage of IPSec over UDP would b= e > required to apply congestion control unless it knew that all the content = traffic > was TCP. Is that really your intent? Actually, one of the compelling use cases for running MPLS over UDP (or L2T= Pv3) would be to encapsulate the traffic in ESP in order to combat passive = snooping. For ESP I believe the implicit assumption (via the Traffic Selectors in IKE= ) was that the upper layer protocol is IP or in transport mode another prot= ocol such as TCP, UDP etc. Sincerely,=20 Greg Daley gdaley@au.logicalis.com From internet-drafts@ietf.org Fri Jan 24 06:00:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010DE1A0448; Fri, 24 Jan 2014 06:00:31 -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 xV142zUUOikU; Fri, 24 Jan 2014 06:00:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6161A0215; Fri, 24 Jan 2014 06:00:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124140029.25216.91630.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 06:00:29 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-extended-admin-group-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 14:00:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Extended Administrative Groups in MPLS-TE Author : Eric Osborne Filename : draft-ietf-mpls-extended-admin-group-02.txt Pages : 6 Date : 2014-01-24 Abstract: MPLS-TE advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV of the Link TLV. This is defined for OSPFv2 [RFC3630], OSPFv3 [RFC5329] and ISIS [RFC5305]. This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-extended-admin-group/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-extended-admin-group-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-extended-admin-group-02 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 internet-drafts@ietf.org Fri Jan 24 06:01:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23A71A0452; Fri, 24 Jan 2014 06:01: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 n7mFQkxhMRqk; Fri, 24 Jan 2014 06:01:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6431A0465; Fri, 24 Jan 2014 06:01:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124140118.16319.81238.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 06:01:18 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-psc-updates-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 14:01:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Updates to PSC Author : Eric Osborne Filename : draft-ietf-mpls-psc-updates-01.txt Pages : 8 Date : 2014-01-24 Abstract: This document contains four updates to the Protection State Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile (MPLS-TP) Linear Protection" . Two of the updates correct existing behavior. The third clarifies a behavior which was not explained in the RFC, and the fourth adds rules around handling capabilities mismatches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-psc-updates-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-psc-updates-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jdrake@juniper.net Fri Jan 24 07:01:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E461A011E; Fri, 24 Jan 2014 07:01:14 -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 i2xlTVp2sVK1; Fri, 24 Jan 2014 07:01:11 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2311A00BE; Fri, 24 Jan 2014 07:01:10 -0800 (PST) Received: from mail35-am1-R.bigfish.com (10.3.201.253) by AM1EHSOBE026.bigfish.com (10.3.207.148) with Microsoft SMTP Server id 14.1.225.22; Fri, 24 Jan 2014 15:01:08 +0000 Received: from mail35-am1 (localhost [127.0.0.1]) by mail35-am1-R.bigfish.com (Postfix) with ESMTP id 92406480495; Fri, 24 Jan 2014 15:01:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VPS-33(z579ehzbb2dI98dI9371I3071M936eIc85fh11f6Nzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24ach24d7h9a9j1155h) Received-SPF: pass (mail35-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(979002)(124014002)(479174003)(377454003)(24454002)(377424004)(189002)(199002)(45984002)(4396001)(79102001)(83322001)(47446002)(65816001)(81342001)(2171001)(74502001)(2656002)(33646001)(63696002)(92566001)(81686001)(74876001)(74662001)(80022001)(59766001)(50986001)(77982001)(87266001)(85306002)(81542001)(66066001)(47976001)(74366001)(47736001)(80976001)(87936001)(19580395003)(49866001)(81816001)(31966008)(19580405001)(76786001)(15202345003)(76796001)(93516002)(83072002)(86362001)(85852003)(19300405004)(74316001)(15975445006)(19609705001)(93136001)(90146001)(56816005)(16236675002)(46102001)(51856001)(76576001)(69226001)(56776001)(54356001)(54316002)(76482001)(53806001)(74706001)(94316002)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB564; H:BLUPR05MB562.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail35-am1 (localhost.localdomain [127.0.0.1]) by mail35-am1 (MessageSwitch) id 1390575665842961_4215; Fri, 24 Jan 2014 15:01:05 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.253]) by mail35-am1.bigfish.com (Postfix) with ESMTP id C8495E0075; Fri, 24 Jan 2014 15:01:05 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 24 Jan 2014 15:01:05 +0000 Received: from BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 24 Jan 2014 15:01:03 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) with Microsoft SMTP Server (TLS) id 15.0.859.15; Fri, 24 Jan 2014 15:01:02 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0859.013; Fri, 24 Jan 2014 15:01:02 +0000 From: John E Drake To: Edward Crabbe , Joe Touch Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPF5eBadQG/CmveUie5TOX7n7WJpqRBw+AgAHKKoCAAANeAIABJGlQ Date: Fri, 24 Jan 2014 15:01:01 +0000 Message-ID: References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.14] x-forefront-prvs: 01018CB5B3 Content-Type: multipart/alternative; boundary="_000_e807421cc9fb4d98a46dce129aa39c82BLUPR05MB562namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "Eggert, Lars" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 15:01:15 -0000 --_000_e807421cc9fb4d98a46dce129aa39c82BLUPR05MB562namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ed, I completely agree with your email, below. As an aside, the L2 packets tha= t Lars is worried about are transported over a pseudo-wire using MPLS, so t= he logical place to place congestion awareness is in the pseudo-wire endpoi= nts. I remember that this was in the PWE3's charter some time ago. Yours Irrespectively, John From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Edward Crabbe Sent: Thursday, January 23, 2014 1:27 PM To: Joe Touch Cc: mpls@ietf.org; Eggert, Lars; Noel Chiappa; IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Part of the point of using UDP is to make use of lowest common denominator = forwarding hardware in introducing entropy to protocols that lack it ( this= is particularly true of the GRE in UDP use case also under discussion else= where). The tunnel is not the source of the traffic. The _source of the traffic_ i= s the source of the traffic. The originating application who's traffic is = being tunneled should be responsible for congestion control, or lack there = of. Are we advocating a return to intermediate congestion control (I like = X.25 as much as the next guy, but...). This is a very stark change of dire= ction. I think mandating congestion control is not technically sound from either = a theoretical (violation of end to end principle, stacking of congestion co= ntrol algorithms leading to complex and potentially suboptimal results) or = economic perspective (as a very large backbone, we've been doing just fine = without intermediate congestion management thank you very much, and I have = 0 desire to pay for a cost prohibitive, unnecessary feature in silicon.) I get Lars comments regarding reach, to some limited extent. Ultimately, t= he implication seems to be that the protocols riding the L2 network will ha= ve no form of congestion control and are fundamentally different than proto= cols that would reside on a typical wan. I have some serious doubts about = this, although I'm sure this is the case in some specialized environments. = At any rate, it seems to me that a stern warning regarding edge filtering = on interdomain boundaries will be sufficient. On Thu, Jan 23, 2014 at 1:15 PM, Joe Touch > wrote: On 1/22/2014 9:55 AM, Eggert, Lars wrote: Hi, On 2014-1-22, at 18:29, Noel Chiappa > wrote: Envision the following 4 (or more) scenarios for one Border Tunneling Routi= ng (BTR), BTR A, to send packets to another BTR, BTR B, on the path from ultim= ate source S (somewhere before BTR A) to destination D (somewhere after BTR B). - Plain IP - Some existing encapsulation like GRE - A new, custom encapsulation - Encapsulation using UDP What you seem to be claiming is that in case 4 we need to have congestion detection and response at the intermediate forwarding node BTR A - but it would not be required in cases 1-3? This makes no sense. FWIW, the whole point of using UDP is to leverage the Internet's ability to= interpret the tunneled traffic as application data - to manage it accordin= g to port-based flow interpretation. There's a cost associated with that privilege - the cost of needing to reac= t to congestion. That doesn't require 1-RTT, TCP-friendly dynamic congestio= n control; it does mean *reacting* to congestion in some way, over some tim= escale more than just ignoring things. This should be expected of any tunneling system that encapsulates non-react= ive flows - regardless of technology. Joe _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_e807421cc9fb4d98a46dce129aa39c82BLUPR05MB562namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ed,

 <= /p>

I completely agree with y= our email, below.  As an aside, the L2 packets that Lars is worried ab= out are transported over a pseudo-wire using MPLS, so the logical place to place congestion awareness is in the pseudo-wire endpoints. = I remember that this was in the PWE3’s charter some time ago.

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: mpls [= mailto:mpls-bounces@ietf.org] On Behalf Of Edward Crabbe
Sent: Thursday, January 23, 2014 1:27 PM
To: Joe Touch
Cc: mpls@ietf.org; Eggert, Lars; Noel Chiappa; IETF discussion list<= br> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>= (Encapsulating MPLS in UDP) to Proposed Standard

 

Part of the point of using UDP is to make use of low= est common denominator forwarding hardware in introducing entropy to protoc= ols that lack it ( this is particularly true of the GRE in UDP use case als= o under discussion elsewhere). 

 

The tunnel is not the source of the traffic.  T= he _source of the traffic_ is the source of the traffic.  The originat= ing application who's traffic is being tunneled should be responsible for c= ongestion control, or lack there of.  Are we advocating a return to intermediate congestion control (I like X.25 as muc= h as the next guy, but...).  This is a very stark change of direction.=  

 

I think mandating congestion control  is not te= chnically sound from either a theoretical (violation of end to end principl= e, stacking of congestion control algorithms leading to complex and potenti= ally suboptimal results) or economic perspective (as a very large backbone, we've been doing just fine without intermediate= congestion management thank you very much, and I have 0 desire to pay for = a cost prohibitive, unnecessary feature in silicon.)

 

I get Lars comments regarding reach, to some limited= extent.  Ultimately, the implication seems to be that the protocols r= iding the L2 network will have no form of congestion control and are fundam= entally different than protocols that would reside on a typical wan.  I have some serious doubts about this, alth= ough I'm sure this is the case in some specialized environments.  At a= ny rate, it seems to me that a stern warning regarding edge filtering on in= terdomain boundaries will be sufficient.  

 

On Thu, Jan 23, 2014 at 1:15 PM, Joe Touch <touch@isi.edu> wrote:<= o:p>



On 1/22/2014 9:55 AM, Eggert, Lars wrote:

Hi,

On 2014-1-22, at 18:29, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

Envision the following 4 (or more) scenarios for one= Border Tunneling Routing
(BTR), BTR A, to send packets to another BTR, BTR B, on the path from ultim= ate
source S (somewhere before BTR A) to destination D (somewhere after BTR B).=

- Plain IP
- Some existing encapsulation like GRE
- A new, custom encapsulation
- Encapsulation using UDP

What you seem to be claiming is that in case 4 we need to have congestion detection and response at the intermediate forwarding node BTR A - but it would not be required in cases 1-3? This makes no sense.

 

FWIW, the whole point of using UDP is to leverage th= e Internet's ability to interpret the tunneled traffic as application data = - to manage it according to port-based flow interpretation.

There's a cost associated with that privilege - the cost of needing to reac= t to congestion. That doesn't require 1-RTT, TCP-friendly dynamic congestio= n control; it does mean *reacting* to congestion in some way, over some tim= escale more than just ignoring things.

This should be expected of any tunneling system that encapsulates non-react= ive flows - regardless of technology.

Joe


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

--_000_e807421cc9fb4d98a46dce129aa39c82BLUPR05MB562namprd05pro_-- From scott.brim@gmail.com Fri Jan 24 07:47:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D702E1A001E; Fri, 24 Jan 2014 07:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9rnNVEzP44L; Fri, 24 Jan 2014 07:47:24 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 416091A0021; Fri, 24 Jan 2014 07:47:24 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wn1so3802458obc.9 for ; Fri, 24 Jan 2014 07:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qzq02ldwbLGHF7RdIB2Z2MxN5PPTXEtwQ5xp1pk0oQI=; b=fhq8nQpVU0/pq7HEao/1Y28bykdX4UEarLJNYYB2UwvSU4poHaUmOcQs9wAje79g5f 31rGUq9PfdRj8TwmmvyAvc3DKUA7ULvOador2z7Cl8eGkSwifYSf1qkPIkGFnH78d0tg DKylKfj57yVI5Ooisvhnms7vhGFcJrOIvxm7FacEMsD6iCeOBYOfuwk/OipoGGcNhami tccTrcozdVFJKHCfOvdhuytFvUWDrkSTDwfHvgAwH4+9FbO0fzgW8GE3p/JIuA4jnxmI EiLHTBmIhuRMSVyB9ArXmJKwSBbUbTttwGN8zBczyMabrP8ovsgltoUDx9jO7AqgWnAJ 0Htg== X-Received: by 10.60.69.38 with SMTP id b6mr3342840oeu.27.1390578442952; Fri, 24 Jan 2014 07:47:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Fri, 24 Jan 2014 07:47:01 -0800 (PST) In-Reply-To: References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> From: Scott Brim Date: Fri, 24 Jan 2014 10:47:01 -0500 Message-ID: To: John E Drake Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , IETF discussion list , Noel Chiappa , Joe Touch Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 15:47:26 -0000 -05 version is out. From ietf-ipr@ietf.org Fri Jan 24 08:37:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6A21A04DA; Fri, 24 Jan 2014 08:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-KqbpLZYNwv; Fri, 24 Jan 2014 08:37:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B776E1A04CF; Fri, 24 Jan 2014 08:37:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: ryoo@etri.re.kr, Eric.Gray@Ericsson.com, huub.van.helvoort@huawei.com, alessandro.dalessandro@telecomitalia.it, cts@etri.re.kr, eosborne@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124163715.30234.75519.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 08:37:15 -0800 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:37:17 -0000 Dear Jeong-dong Ryoo, Eric Gray, Huub van Helvoort, Alessandro D'Alessandro= , Tae-sik Cheung, Eric Osborne: An IPR disclosure that pertains to your Internet-Draft entitled "MPLS Tran= sport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators" (draft-ietf-mpls-tp-psc-= itu) was submitted to the IETF Secretariat on 2014-01-24 and has been posted on = the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2306/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mp= ls- tp-psc-itu-01.""); The IETF Secretariat From stbryant@cisco.com Fri Jan 24 10:04:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732261A0040; Fri, 24 Jan 2014 10:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 3r0WeC_ELcZh; Fri, 24 Jan 2014 10:04:57 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 691091A003B; Fri, 24 Jan 2014 10:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5743; q=dns/txt; s=iport; t=1390586695; x=1391796295; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=38Pz967vdvkDhMGfnp2j9WEtHzW/xJWBdxFgrAvQajI=; b=FkWN2GAhM1dmD6cX5qS9xQiCIy1OO2kbZBPALYkb/r+W5y2wGaGh157G h+hBiHB4DuGPKoyK5xqpyQJZT+LJIRY8IZxclF0kI42AFUBnLqJJc2+1/ z4J60+JjWLXjcESemShIr9oYGBtMBS5iRvLCrnFsI8Fd86e59G8Unnzxb s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAAmr4lKQ/khM/2dsb2JhbABaDoI6RDi9C4ENFnSCJQEBAQQtSwEQCxgJFgQLCQMCAQIBRQYBDAEHAQGIAQ3INxMEjioRAVAHhDgEmCeSHoFvfz+BcQ X-IronPort-AV: E=Sophos;i="4.95,714,1384300800"; d="scan'208,217";a="3473128" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 24 Jan 2014 18:04:54 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0OI4r35000313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jan 2014 18:04:53 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0OI4one006108; Fri, 24 Jan 2014 18:04:51 GMT Message-ID: <52E2AB42.8060206@cisco.com> Date: Fri, 24 Jan 2014 18:04:50 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: John E Drake , Edward Crabbe , Joe Touch References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060005050208040809040604" Cc: "mpls@ietf.org" , "Eggert, Lars" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:04:59 -0000 This is a multi-part message in MIME format. --------------060005050208040809040604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 24/01/2014 15:01, John E Drake wrote: > > Ed, > > I completely agree with your email, below. As an aside, the L2 > packets that Lars is worried about are transported over a pseudo-wire > using MPLS, so the logical place to place congestion awareness is in > the pseudo-wire endpoints. I remember that this was in the PWE3's > charter some time ago. > > Yours Irrespectively, > > John > The charter says: Whilst a service provider may traffic engineer their network in such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. Congestion avoidance may be more difficult with P2MP pseudowires than P2P pseudowires. The WG will consider both cases. https://datatracker.ietf.org/doc/draft-stein-pwe3-congcons/ has expired, but if you are interested in working on the subject I am sure the authors would be delighted to talk to you. Stewart --------------060005050208040809040604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 24/01/2014 15:01, John E Drake wrote:

Ed,

 

I completely agree with your email, below.  As an aside, the L2 packets that Lars is worried about are transported over a pseudo-wire using MPLS, so the logical place to place congestion awareness is in the pseudo-wire endpoints.  I remember that this was in the PWE3’s charter some time ago.

 

Yours Irrespectively,

 

John

The charter says:

Whilst a service provider may traffic engineer their network
in such a way that PW traffic will not cause significant
congestion, a PW deployed by an end-user may cause
congestion of the underlying PSN. Suitable congestion
avoidance mechanisms are therefore needed to protect the
Internet from the unconstrained deployment of PWs. Congestion
avoidance may be more difficult with P2MP pseudowires than
P2P pseudowires. The WG will consider both cases.

https://datatracker.ietf.org/doc/draft-stein-pwe3-congcons/
has expired, but if you are interested in working on the subject
I am sure the authors would be delighted to talk to you.

Stewart
--------------060005050208040809040604-- From touch@isi.edu Fri Jan 24 10:51:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7EC1A00F4; Fri, 24 Jan 2014 10:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 1HpRDKyP-F1j; Fri, 24 Jan 2014 10:51:24 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F31231A00F7; Fri, 24 Jan 2014 10:51:22 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0OIoSFs019424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Jan 2014 10:50:31 -0800 (PST) Message-ID: <52E2B5F4.8050008@isi.edu> Date: Fri, 24 Jan 2014 10:50:28 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Joel M. Halpern" , Edward Crabbe References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> <52E1D093.8040603@joelhalpern.com> In-Reply-To: <52E1D093.8040603@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:51:26 -0000 On 1/23/2014 6:31 PM, Joel M. Halpern wrote: > Joe, while your argument is internally consistent, it is not consistent > with history. That's also why we're not exchanging email over X.25. We learn and move on. However, the fact that tunnel heads ought to act like hosts is an issue I've been raising in the IETF for over 15 years, and was the primary reason why I argued for transport mode support in routers for tunneling (see RFC 3884). > We have not demanded that tunnel entries behave fully > like source hosts for any of the other myriad kinds of tunnels we have > done over the years. That has been a continual mistake, one that a group was formed in 2005 to address, which resulted in an INTAREA document on this: http://tools.ietf.org/html/draft-touch-intarea-tunnels-01 That doc has been fallow for a while largely because the problem and its complexity hasn't been fully appreciated. We're hoping to correct that and revive it, FWIW. > If we take your logic as stated, then the usage of IPSec over UDP would > be required to apply congestion control unless it knew that all the > content traffic was TCP. Is that really your intent? Yes, and that's already what RFC 5405 says. The fact that IPsec-UDP encap doesn't address this is because RFC 3948 predates RFC 5405. This document (mpls-in-udp) does not, however. Joe > Yours, > Joel > > On 1/23/14 4:38 PM, Joe Touch wrote: >> >> >> On 1/23/2014 1:27 PM, Edward Crabbe wrote: >>> Part of the point of using UDP is to make use of lowest common >>> denominator forwarding hardware in introducing entropy to protocols that >>> lack it ( this is particularly true of the GRE in UDP use case also >>> under discussion elsewhere). >>> >>> The tunnel is not the source of the traffic. The _source of the >>> traffic_ is the source of the traffic. >> >> To the Internet, the tunnel encapusulator is the source of traffic. >> Tracing the data back further than that is a mirage at best - and >> irrelevant. >> >> The tunnel head-end is responsible for the tunnel walking, talking, and >> quaking like a duck (host). When the tunnel head-end knows something >> about the ultimate origin of the traffic - whether real, imagined, or >> from Asgard - then it has done it's duty (e.g., that it's already >> congestion controlled). >> >> But that head end is responsible, regardless of what it knows or >> doesn't. And when it doesn't know, the only way to be responsible is to >> put in its own reactivity. >> >>> The originating application >>> who's traffic is being tunneled should be responsible for congestion >>> control, or lack there of. >> >> Perhaps it should be, but that's an agreement between whomever >> implements/deploys the tunnel headend and whomever provides the >> originating traffic to them. The problem is that this isn't true for the >> typical use case for this kind of encapsulation. >> >> I.e., if we were talking about MPLS traffic that already was reactive, >> we wouldn't be claiming the need for additional encapsulator mechanism. >> It's precisely because nothing is known about the MPLS traffic that the >> encapsulator needs to act. >> >> > Are we advocating a return to intermediate >>> congestion control (I like X.25 as much as the next guy, but...). This >>> is a very stark change of direction. >>> >>> I think mandating congestion control is not technically sound from >>> either a theoretical (violation of end to end principle, stacking of >>> congestion control algorithms leading to complex and potentially >>> suboptimal results) or economic perspective (as a very large backbone, >>> we've been doing just fine without intermediate congestion management >>> thank you very much, and I have 0 desire to pay for a cost prohibitive, >>> unnecessary feature in silicon.) >> >> Write that up, and we'll see how it turns out in the IETF. However, >> right now, the IETF BCPs do require reactive congestion management of >> transport streams. >> >> If you don't want/like that, then either don't use transport >> encapsulation, or change the BCPs. >> >>> I get Lars comments regarding reach, to some limited extent. >>> Ultimately, the implication seems to be that the protocols riding the >>> L2 network will have no form of congestion control and are fundamentally >>> different than protocols that would reside on a typical wan. I have >>> some serious doubts about this, although I'm sure this is the case in >>> some specialized environments. At any rate, it seems to me that a stern >>> warning regarding edge filtering on interdomain boundaries will be >>> sufficient. >> >> My concern may be slightly different that his. My concern is that you >> want the benefits of a UDP header, but don't like the responsibilities >> that come along with it. >> >> Joe >> >> From touch@isi.edu Fri Jan 24 11:16:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5B51A017C; Fri, 24 Jan 2014 11:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.235 X-Spam-Level: X-Spam-Status: No, score=-4.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 0sSaa6_DS5SQ; Fri, 24 Jan 2014 11:16:30 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F1CB51A0175; Fri, 24 Jan 2014 11:16:13 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0OJFCsn023069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Jan 2014 11:15:13 -0800 (PST) Message-ID: <52E2BBC0.2030203@isi.edu> Date: Fri, 24 Jan 2014 11:15:12 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> In-Reply-To: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , "Eggert, Lars" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:16:36 -0000 On 1/23/2014 7:20 PM, Curtis Villamizar wrote: ... > Joe, > > I agree with you that the word SHOULD is not an automatic pass and > quoted from RFC 2119 because I think that on this thread the criteria > "valid reasons in particular circumstances" and "implications > ... carefully weighed" have both been met. > > Perhaps you joined the discussion a little late. > > Please allow me to recap. There are two issues under discussion, UDP > checksums and congestion control. > > All parties seem to be OK with limiting the use of MPLS over UDP to > service providers only within their own infrastructure only, except > among cooperating service providers with explicit agreement > (consenting adults). > > Within that context, some service providers find that parts of their > infrastructure either doesn't support MPLS at all or doesn't support a > usable variation of multipath for MPLS but does support IP ECMP (as I > understand it, this is primarily in the fringes, access and less so > edge - but someone who knows for sure please correct me if not). > > This eliminates the "expands the reach of MPLS argument". > > First UDP checksums: > > The UDP checksum is at the beginning of the payload. Please see > http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html > This makes filling in a new UDP checksum infeasible on most high end > hardware. That argument would make sense if most hardware wasn't store-and-forward on a per-packet basis. > Within all of that context, all of the links have at least 32 bit > FCS (either Ethernet framing or SONET or OTN) and some has much > better such as the FEC found in OTN. This makes undetected > corruption by any of the links extremely unlikely. > > Corruption internal to the router the only potential impact. There > is good reason to think that this is extremely rare. I don't buy the argument that per-hop checksums replace the need for end-to-end checksums; that's part of why more modern tunneling systems (e.g., SEAL) include their own head-to-tail checksum. So while I agree that UDP checksums may not be strong enough here, that might be an argument for a better tunneling mechanism than raw MPLS in IP, rather than ditching UDP checksums. > Infeasibility of doing UDP checksums in some instances (not just > performance concerns) is sufficient to make use of UDP checksums a > SHOULD. Your argument hinges on feasibility, but that doesn't hold water (esp. given I've designed hardware that does Internet checksums - including some recent all-optical designs). > On to congestion control: > > Some MPLS payloads such as IP over MPLS have congestion control. > While it can't be assured that all IP traffic makes use of > congestion control, the problem is in the UDP services carried over > MPLS regardless of whether MPLS over UDP is used. That is the key problem. As you point out below, other traffic is somewhat 'noise' on the overall equation. > The only other type of traffic carried by MPLS in any volume (not > counting ISIS control traffic carried as CLNP over MPLS, for > example) is PW. > > PW in turn supports Ethernet, FR, ATM, TDM, and maybe a few > others. The vast majority of payload in Ethernet, FR, ATM, is IP > so were are back to the prior bullet. It PW packlet carrying > Ethernet, FR, or ATM are dropped the congestion response is > virtually identical to IP because the payload is IP. > > The other PW case is TDM. TDM serves two purposes in SP networks. > A small number of legacy customers circuits, generally T1 or T3 > use it. These are 1.5 and 45 Mb/s services on 1 Gb/s and 10 Gb/s > links. Hardly a source of congestion, plus they pay a lot more > and therefore are priority traffic. Another is 3G mobile > backhaul. Again this is T1 or T3, but maybe as much as small > multiples of T3. Still very low capacity. You can't know whether the PW cases you expect will change over time, or are accurate as per above. I would not be surprised if someone started (or is already) using PW to connect datacenters to exchange bulk data using non-CC protocols. > TCP-like congestion control in a tunnel is very bad for any TCP > carried within the tunnel. The vast majority on MPLS traffic is IP > and therefore is TCP. Yes, and that's why nobody is asking for that. > Regardless of the weak argument in favor of it given the operational > reality, the authors have conceded to state that "MPLS over UDP > SHOULD have congestion control" in the document. OK (that matches RFC 5405). > Because in the scenario it is intended to be deploy congestion > control is very unlikely to prove to be needed, That's pure speculation, and more importantly undermines the SHOULD you've just conceded. > defining the exact > form of congestion control is deferred to a later document which > will be written only if needed. That document is needed now, exactly because of the SHOULD. You can't make a SHOULD recommendation without backing it up with the detail needed to implement it. Other wise, it's a MAY, or (more to the point), a (nonexistent) MIGHT SOMEDAY. > That said, I have in the past argued that the "circuit breaker" form > of congestion control would be one of the worst things we could > possibly do. It would be terrible for TCP and most anything else. Maybe, but if so, then you need the head-end to employ that breaker only on non-CC traffic. > See http://www.ietf.org/mail-archive/web/mpls/current/msg11262.html > The right place to put any circuit breaker would be TDM over PW, but > given the capacities involved, that is not really needed either. > > In the past I've said: > > The technical sticky point is knowing that the congestion is > occuring. Perhaps a LM like packet on another UDP port could be > exchanged with the same caveats about inaccuracy if implemented in > software and inaccuracy if reordering occurs, and a recommendation > can be made to do something to introduce drop if congestion is > indicated by this method. How to introduce drop should be an > implementation detail, a form of AQM or leaky bucket being possible > choices, but entirely a local matter. > > MPLS LM OAM would be a good choice for detection of congestion (as > evidenced by loss). A leaky bucket (aka shaper) likely with AQM seems > like a reasonable choice. This could be put into another document if > a need ever truly arises for congestion control in MPLS and it could > be applied to MPLS over anything (though it could prove impractical > for MPLS over avian carrier). See above. MIGHT SOMEDAY isn't a reasonable solution to a problem for which the need for a solution is already conceded. Joe > > Curtis > > >> On 1/21/2014 12:58 PM, Curtis Villamizar wrote: >>> Lars, >>> >>> The IETF consensus in RFC5405 was to put a SHOULD in regarding use of >>> congestion control in tunneling protocols. >>> >>> RFC2119 states: >>> >>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >>> may exist valid reasons in particular circumstances to ignore a >>> particular item, but the full implications must be understood and >>> carefully weighed before choosing a different course. >>> >>> We have discussed the reasons why congestion control is in general a >>> good thing. We have also discussed why there may be valid reasons to >>> not include congestion control in MPLS over UDP. >>> >>> The question is not whether there is already IETF consensus on >>> congestion control in UDP in general. There is consensus and that >>> consensus was to use the word "SHOULD". >>> >>> The question we now face is whether MPLS in UDP needs to up the prior >>> consensus to a MUST or can keep it as SHOULD. I see one or maybe two >>> people vigorously arguing to upgrade this to a MUST and otherwise >>> consensus to keep this as SHOULD. Further I see no objection except >>> the same one or maybe two people to making the congestion control the >>> topic of a later work if a need for it arises. Consensus does not >>> require unanimous agreeement. >>> >>> If we are trying to gauge consensus, maybe both you and I should sit >>> back and let other people weigh in. >>> >>> Curtis >>> >>> >>> In message >>> "Eggert, Lars" writes: >>>> >>>> Hi, >>>> >>>> On 2014-1-17, at 18:19, Curtis Villamizar wrote: >>>>> You have made your assertions about your desire to uphold the purity >>>>> of any new UDP applications and adhere to the BCP you wrote. >>>>> =20 >>>>> You appear to be very nearly alone in this argument and certainly no >>>>> one that works with MPLS is siding with you. >>>> >>>> the reason we wrote the RFC when I was TSV AD was that we were seeing a = >>>> whole bunch of questionable uses of UDP over the eyars and we were = >>>> having the same arguments over and over. That's why we decided to write = >>>> down the practices we expect users of UDP to follow. This is yet another = >>>> such questionable use. >>>> >>>> (Also, I don't appreciate you turning this into a personal argument.) >>> >>> Nothing personal intended. >>> >>> The important point is the sentence "You appear to be very nearly >>> alone in this argument and certainly no one that works with MPLS is >>> siding with you." was intended to point out that there is no consensus >>> behind your argument regardless of how vigorously you make that >>> argument. >>> >>>>> In the end we can put anything we want in the RFC *but* IETF has never >>>>> truly had the final word on what vendors and operators do in provider >>>>> networks. >>>> >>>> Aka the "take my toys and go home" argument. Heard it many times. >>> >>> It has been successful many times in the past. It turns into the "its >>> deployed so get over it" argument after a few years. >>> >>>>> In this case, regardless of what changes are made to the draft, >>>>> implementations will offer at least the option for non-RFC behavior by >>>>> using zero checksums and not using any congestion control. And >>>>> providers will make use of it, perhaps exclusively. >>>> >>>> And there's nothing wrong with that - the BCP even says that one SHOULD = >>>> NOT use congestion control for some deployment cases. >>>> >>>> But for others, one SHOULD. For those, a mechanism needs to be = >>>> available, i.e., it needs to be specified and implemented. >>>> >>>>> The document might as well reflect reality, despite reality not >>>>> conforming to your notions of architectural purity. >>>> >>>> I'm sorry, but we have certain architectural principles in the Internet = >>>> that we have IETF consensus on. At least since RFC2914, that includes = >>>> the need to have congestion control in place. >>>> >>>> There are always special deployment scenarios where these principles do = >>>> not apply, and we typically explain in applicability statements when out = >>>> specifications can only be safely used under certain conditions. I don't = >>>> see any such statement in draft-ietf-mpls-in-udp, which to me means it's = >>>> targeted at general Internet-wide use. >>>> >>>>> The best course of action is to put a SHOULD in regarding checksums >>>>> and put a SHOULD in regarding congestion avoidance. Even the BCP does >>>>> not go any further than to say a tunneling protocol SHOULD use >>>>> congestion control and there were reasons that the word MUST was not >>>>> acceptable in the BCP. >>>> >>>> The SHOULD for congestion control needs to actually describe a mechanism = >>>> that can be used when needed. It can't be a blanket "you SHOULD use = >>>> something but we don't tell you what it is"-statement. >>>> >>>>> If we are still arguing over two instances of SHOULD vs MUST we have >>>>> wasted a lot of bandwidth on those two words. >>>> >>>> It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it needs = >>>> to be specified what is to be done. In the case of checksums, that's = >>>> obvious (calculate it and check it); in the case of congestion control, = >>>> some actual mechanism needs to be described (e.g., a circuit breaker). >>>> >>>>> IMHO The only remaining question is whether the document can go = >>>> forward >>>>> with the definition of congestion control for MPLS over UDP left out >>>>> of scope and for another document if a need arises. >>>> >>>> In my opinion, it cannot. >>>> >>>>> If this is not acceptable to you (I doubt it is) please indicate what >>>>> you would like to see in the document and since this is IETF last call >>>>> where consensus matters and no one individual has veto power, we'll >>>>> have to see if there is consensus behind your proposed changes. >>>> >>>> I would like the document to specify at the very least a circuit breaker = >>>> mechanism, that stops the tunneled traffic if severe packet loss is = >>>> detected along the path. >>>> >>>> And this isn't about an "individual veto". This is about a document that = >>>> is at the moment in violation of IETF consensus at least as far back as = >>>> RFC2914. >>>> >>>> Lars From spencerdawkins.ietf@gmail.com Fri Jan 24 14:13:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2791A0185; Fri, 24 Jan 2014 14:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoZXp5tSIVnW; Fri, 24 Jan 2014 14:13:23 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id ECBEE1A001A; Fri, 24 Jan 2014 14:13:22 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id wn1so4245279obc.34 for ; Fri, 24 Jan 2014 14:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=z+TI4U3m5PbgLUPDpL/eYcK4iOGTB3v4XB1gJEuieKo=; b=HIxJDJjo4gbVE8mpZTjnEwcmMkKcuUCXx4jzGilUX3djfps1N4vAsCVlqyRWPTDdCo tb5vhL6F4wkYDWDI1lQnhDoXhUjJYOjM6bIkJjTgiZiaj3ksTPkaMLwh1CxU+t1S9pI9 3yuFSyltkV/Co8DpRGLR1H4aC3cfcOyju0xSPDYCC/d/v4tRG9rSc1XTpx37ghWl5/ki 3RDKS1DpIieoyYAt5Lf53+zab+BBLIsp4QfRFLSfKIJK+zWlcCF3hcz262zxngFcxzhc 4swEqS146c4w/nTk4QLZ/PvFVQ/gblSmxJOzwrESYTcYsGD4OBqRo0WpCIDU6my7sAW1 yA2Q== X-Received: by 10.182.22.18 with SMTP id z18mr13814867obe.42.1390601600648; Fri, 24 Jan 2014 14:13:20 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id ii8sm3847353obb.11.2014.01.24.14.13.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jan 2014 14:13:19 -0800 (PST) Message-ID: <52E2E57D.70403@gmail.com> Date: Fri, 24 Jan 2014 16:13:17 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alia Atlas , Joe Touch References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu> <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com> <52E18661.4060000@isi.edu> <52E18BF1.1040004@isi.edu> <52E1AC3E.2040204@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , Noel Chiappa , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 22:13:24 -0000 On 01/23/2014 06:07 PM, Alia Atlas wrote: > I don't want to get in the way of vehement discussion, but I thought > we were on the verge of finding an actual solution... > > IMHO, that was a combination of an applicability statement, using > SHOULD for congestion control and checksum, and defining a longer-term > OAM-based approach (as Stewart Bryant suggested) to be able to verify > that packet corruption or excessive drops aren't happening. > > Does that sound like an acceptable set? Alia, I certainly hope so (speaking as an individual), and I appreciate you conjuring up the specter of an applicability statement (speaking as TSV AD). I expect to find that helpful. Spencer From nobo@cisco.com Fri Jan 24 15:31:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1BA1A021B for ; Fri, 24 Jan 2014 15:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 EE4jk7wLz1ws for ; Fri, 24 Jan 2014 15:31:23 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 31EA81A01E5 for ; Fri, 24 Jan 2014 15:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4399; q=dns/txt; s=iport; t=1390606282; x=1391815882; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=a0aJUPfSgQctGN8c0tsXlCfClzXI65WcsCZjkIDWmOY=; b=YqDWo0k+NoFhHEaf0XO8Ut2VEsQ9W5x4YrBdxOfLPBaz11+MgjcQrebj cEYLMf1NkyQiARBPpcWXEAtB21Z3uSC+yyuYLdKNU/GTA7wnEHuz2aTQU nSB1vr6NPGrco2jobLUWByXk8l+adRZRS+W3AQbkKU0cgcui+aDjjERGl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAAr34lKtJXG//2dsb2JhbABagmshOFa8QYEIFnSCJQEBAQMBAQEBCywrBgMLBQkCAgEIGAoUBQsbDAslAgQBDQUIh3UIAQzJDhMEBI4mCwYBHzEHgySBFASqRYFvgT6BaQgXIg X-IronPort-AV: E=Sophos;i="4.95,715,1384300800"; d="scan'208";a="15408006" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 24 Jan 2014 23:31:21 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0ONVLLa028808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 23:31:21 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 17:31:21 -0600 From: "Nobo Akiya (nobo)" To: Sriganesh Kini , Loa Andersson , Xuxiaohu , Curtis Villamizar , "Daniel King" Thread-Topic: [mpls] Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping Thread-Index: AQHPGKol81npwEdCf0ygsxPSUYRMGZqUhDqw Date: Fri, 24 Jan 2014 23:31:20 +0000 Message-ID: References: <52C67349.4020701@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" , "draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 23:31:26 -0000 Hi Sri, Thank you for comments. > Hello authors, >=20 > The draft is reasonably coherent. It addresses a useful problem. > Technically it is a start. The document is ready to be considered for WG > adoption. >=20 > A few comments - >=20 >=20 > 1. sec 8. DSMAP is deprecated. Should be removed. Even though "Multipath > Info" field was in DSMAP too, since a more recent RFC has deprecated it, = it > should no longer be used. Some implementations referring to DSMAP is not > a reason to continue using if the intention is to get to a proposed stand= ard. I see. I will speak to few people and if this is indeed the case, I will re= move DSMAP from document (either next revision or later revision). >=20 > 2. The notation {x, y, z} is introduced in section 2, without mentioning = what > it means. I am assuming it means one-of. Should be stated clearly. Good point. I will add a description on this notion. >=20 > 3. sec 9 bullet 1 - If the transit node encounters a deep label stack, it= may > not be able to access labels till the bottom of stack to compute the hash= . If > this is the case, "Depth Limit" should take care of this. It is not clear= what > this unsupported-case is and why it should occur. Yes "Depth Limit" can communicate something. One question is, is this top N= labels or bottom M labels? Either way, if Flow Label or Entropy Label is n= ot included in this "Depth Limit", then initiator LSP cannot make changes t= o the label stack to traverse all ECMP paths at this point. >=20 > 4. sec 9. bullet 2 - Is this case when the transit node is using other la= bels in > the label stack "in addition to the EL" OR is it when the transit node is= using > a non-EL label in the stack even if EL is included ? > The former case is typical. The latter case I would imagine can occur if = the > transit LSR cannot access the entire label stack depth. Again not clear w= hat > the unsupported case is. I will rewrite this entire section on what is and isn't supported. Hopefull= y next revision will be more clearer. >=20 > 5. Does the draft make a distinction between the two cases allowed by > RFC6790, namely - >=20 > a. Load balance solely on the EL >=20 > b. Use as-much of the label-stack as feasible This will be covered with section 9 rewrite. >=20 > 6. The "Associated Label Multipath Information" field should be better > explained. I would suggest a separate section to improve the coherency. I believe this is well described in section 8. Please let me know if you th= ink it is still insufficient. Thanks again! -Nobo >=20 >=20 >=20 > Thanks >=20 > Sri >=20 > On 1/3/14 12:22 AM, "Loa Andersson" wrote: >=20 > >Folks, > > > >This was the wrong document - I intended to have the review done for > >draft-akiya-mpls-entropy-lsp-ping sorry for the confusion. > > > >All other cordinates correct! > > > >On 2014-01-03 14:44, Loa Andersson wrote: > >> Sri, Xiaohu, Curtis and Dan, > >> > >> You have been selected as MPLS Review team reviewers for > >> draft-akiya-mpls-entropy-lsp-ping-01. > >> > >> Note to authors: You have been CC'd on this email so that you can > >> know that this review is going on. However, please do not review your > >> own document. > >> > >> Reviews should comment on whether the document is coherent, is it > >> useful (ie, is it likely to be actually useful in operational > >> networks), and is the document technically sound? We are interested > >> in knowing whether the document is ready to be considered for WG > >> adoption (ie, it doesn't have to be perfect at this point, but should > >> be a good start). > >> > >> Reviews should be sent to the document authors, WG co-chairs and WG > >> secretary, and CC'd to the MPLS WG email list. If necessary, comments > >> may be sent privately to only the WG chairs. > >> > >> Are you able to review this draft by January 20, 2014? > >> > >> Thanks, Loa > >> (as MPLS WG chair) > > > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From wwwrun@rfc-editor.org Fri Jan 24 16:36:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C651A029D; Fri, 24 Jan 2014 16:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 d78BPZMUSr7W; Fri, 24 Jan 2014 16:36:10 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 77FFF1A0291; Fri, 24 Jan 2014 16:36:08 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1F7E97FC3AB; Fri, 24 Jan 2014 16:36:06 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140125003606.1F7E97FC3AB@rfc-editor.org> Date: Fri, 24 Jan 2014 16:36:06 -0800 (PST) Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7110 on Return Path Specified Label Switched Path (LSP) Ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 00:36:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7110 Title: Return Path Specified Label Switched Path (LSP) Ping Author: M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord Status: Standards Track Stream: IETF Date: January 2014 Mailbox: mach.chen@huawei.com, wayne.caowei@huawei.com, ning.so@tatacommunications.com, frederic.jounay@orange.ch, simon.delord@alcatel-lucent.com Pages: 21 Characters: 44625 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-return-path-specified-lsp-ping-15.txt URL: http://www.rfc-editor.org/rfc/rfc7110.txt This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From loa@pi.nu Fri Jan 24 21:19:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369A01A0051 for ; Fri, 24 Jan 2014 21:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 TNZFRW0Plc1c for ; Fri, 24 Jan 2014 21:19:51 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB9B1A0036 for ; Fri, 24 Jan 2014 21:19:50 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.1.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id EB8B2180145E; Sat, 25 Jan 2014 06:19:46 +0100 (CET) Message-ID: <52E3496F.6070003@pi.nu> Date: Sat, 25 Jan 2014 13:19:43 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6.all@tools.ietf.org" Subject: [mpls] return the draft-ietf-mpls-ldp-ipv6 to the working group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 05:19:53 -0000 Adrian, Can you please return draft-ietf-mpls-ldp-ipv6 to the mpls working group for more work. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From huubatwork@gmail.com Sat Jan 25 03:46:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55011A0483 for ; Sat, 25 Jan 2014 03:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUu-m7EotjUM for ; Sat, 25 Jan 2014 03:46:47 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 818E11A0474 for ; Sat, 25 Jan 2014 03:46:47 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id n12so3992940wgh.12 for ; Sat, 25 Jan 2014 03:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=zx7j4H2JKyDlP0Ue3l46dsnlfM5ajLsU/OXElQkjmKE=; b=rMHPjaCYYLbUs5PdPW5w1CHWF+IfV3OAlVVV3mGri0Nk7XqRsv492Bh/IM5p//v8aO PZeMJvY9aRua4piSy+D11K6QpweDuXb6y7DjtyUhkW/8v5jimWEQHZLapU06BUtU2K7I TaHB3OisMZWsDnr0nbNowvg5bdG5tR0OcThlQKpiGKK4Cg1VK8n1NDF8tvAx9juhGnMg 2KQBtAICMRwckwlkqENtXLuZ8Q9vN6MICq8DcqVn2FmRMTe/SBWTneaoY4l8AKFBhLPx gXosxQC3xzGtU6O2Qlwk0WrgyEP3RCxcZ/P++GLlc5SfVHgiWLcf2vCMvnRXSBfJHcOi uJpg== X-Received: by 10.194.219.132 with SMTP id po4mr14129712wjc.7.1390650405518; Sat, 25 Jan 2014 03:46:45 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id q15sm9296952wjw.18.2014.01.25.03.46.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 03:46:45 -0800 (PST) Message-ID: <52E3A424.209@gmail.com> Date: Sat, 25 Jan 2014 12:46:44 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls-chairs@tools.ietf.org" References: <20140125073602.3234.76134.idtracker@ietfa.amsl.com> In-Reply-To: <20140125073602.3234.76134.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140125073602.3234.76134.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 11:46:50 -0000 Dear WG chairs, The authors of draft-zulr-mpls-tp-linear-protection-switching have decided to publish the document on the independent stream as an informational RFC. Because it documents the pre-standard implementation of MPLS-TP linear protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication these pre-standard implementations were still in operation carrying live traffic. Best regards, Huub van Helvoort. -------- Original Message -------- Subject: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt Date: Fri, 24 Jan 2014 23:36:02 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Pre-standard Linear Protection Switching in MPLS-TP Authors : Huub van Helvoort Jeong-dong Ryoo Haiyan Zhang Feng Huang Han Li Alessandro D'Alessandro Filename : draft-zulr-mpls-tp-linear-protection-switching-09.txt Pages : 27 Date : 2014-01-24 Abstract: The IETF Standards Track solution for MPLS Transport Profile (MPLS- TP) Linear Protection is provided in RFC 6378, draft-ietf-mpls-psc- updates and draft-ietf- mpls-tp-psc-itu. This document describes the pre-standard implementation of MPLS-TP Linear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication these pre-standard implementations were still in operation carrying live traffic." The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by MPLS-TP data plane, and can work without any control plane. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [Editor's note] To be included in "Status of Memo": This document is not an Internet Standards Track specification; it is published for informational purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zulr-mpls-tp-linear-protection-switching/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection-switching-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-zulr-mpls-tp-linear-protection-switching-09 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From curtis@ipv6.occnc.com Sat Jan 25 12:15:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56F31A0027 for ; Sat, 25 Jan 2014 12:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RP_MATCHES_RCVD=-0.535, 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 kyWKeOHW25iF for ; Sat, 25 Jan 2014 12:15:05 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id A77C01A0041 for ; Sat, 25 Jan 2014 12:15:05 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0PKEMun048512; Sat, 25 Jan 2014 15:14:22 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401252014.s0PKEMun048512@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Fri, 24 Jan 2014 04:55:46 +0000." <290E20B455C66743BE178C5C84F1240847E63346EC@EXMB01CMS.surrey.ac.uk> Date: Sat, 25 Jan 2014 15:14:22 -0500 Cc: mpls@ietf.org, joelja@bogus.com, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 20:15:08 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346EC@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to > > zero). There are cases where it is impossible so it can't be MUST. > > Agreed. > > > UDP-List doesn't solve the ECMP problems because most of the older LSR > > that are forcing the use of MPLS over UDP to get ECMP don't look at > > the port numbers if the protocol is not 6 or 17. But this has only > > been said three or four times so maybe you missed it. > > I believe you mean Lite, not List. UDP-Lite is standards track, and > solves the performance concern while providing the demux check > that IPv4 needs and v6 needs even more. It's worth mentioning > for that reason; it is well-suited to this problem. Typo. I meant UDP-Lite. > (There's a lot of older MPLS hardware out there that only does > IPv4. Why is the draft mentioning v6? Or perhaps we shouldn't > be completely constrained by the field?) There is a lot of brand new hardware being shipped today that only looks for protocol 6 or 17. However a useful addition to the draft would be: If it is not possible to use UDP checksums, and if it is possible to use UDP-Lite [RFCxxxx] then UDP-Lite is a better solution than UDP with zero checksums. OK? Curtis > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 24 January 2014 03:52 > To: Wood L Dr (Electronic Eng) > Cc: xuxiaohu@huawei.com; Alexander.Vainshtein@ecitele.com; lars@netapp.com; joelja@bogus.com; mpls@ietf.org > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > In message <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > the text is not satisfactory. never recommend setting to zero, > > as that poses a risk to your and to other traffic. Suggested text: > > *** > > The UDP checksum SHOULD be used to protect the payload and > > ensure correct demultiplexing and delivery to the tunnel, and not to > > other UDP destinations, by protecting the UDP pseudoheader. > > Use of a zero UDP checksum is NOT RECOMMENDED, even when > > desired for performance or necessitated by implementation > > reasons, for the reasons outlined in [RFC6936] section 3. > > I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to > zero). There are cases where it is impossible so it can't be MUST. > > > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS > > stack integrity check while avoiding the overhead of computing an > > integrity check over a tunnelled frame that has its own integrity check. > > UDP-List doesn't solve the ECMP problems because most of the older LSR > that are forcing the use of MPLS over UDP to get ECMP don't look at > the port numbers if the protocol is not 6 or 17. But this has only > been said three or four times so maybe you missed it. > > > *** > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Xuxiaohu [xuxiaohu@huawei.com] > > Sent: 23 January 2014 12:35 > > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; lars@netapp.com > > Cc: joelja@bogus.com; mpls@ietf.org > > Subject: re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > > > > -----ÓʼþÔ­¼þ----- > > > ·¢¼þÈË: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ23ÈÕ 12:44 > > > ÊÕ¼þÈË: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com > > > ³­ËÍ: joelja@bogus.com; mpls@ietf.org > > > Ö÷Ìâ: RE: [mpls] Last Call: (Encapsulating MPLS > > > in UDP) to Proposed Standard > > > > > > Sasha > > > > > > > - UDP checksums (or lack thereof) is a non-issue because native MPLS > > > > does not have anything like that. And yes, there are cases where > > > > packets are corrupted within the routers) > > > > > > So you admit that packets can be corrupted within the routers - a check that can > > > only be caught by an end-to-end check, a corruption that can lead to the > > > problems detailed in RFC 6936 section 3 - and then you say it's a non-issue > > > because this doesn't affect native MPLS. But we're not doing native MPLS here. > > > We're doing MPLS over UDP. > > > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's an issue. > > > Please read the other 150 messages that you refer to. > > > > Hi Lloyd, > > > > The draft doesn't require the IPv6 UDP checksum to be set to zero regardless. See the following text quoted from that draft: > > > > UDP Checksum > > > > The usage of this field is in accordance with the current UDP specification [RFC768]. To simplify the operation on the decapsulator, this field is RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In the IPv6 UDP encapsulation case, if appropriate according to the requirements defined in [RFC6935] [RFC6936], this field is also RECOMMENDED to be set to zero. Specifically, if the MPLS payload is Internet Protocol (IPv4 or IPv6) packets, it is RECOMMENDED to be set to zero when the inner packet integrity checks is available. In addition, if the MPLS payload is non-IP packet which is specifically designed for transmission over a lower layer that does not provide a packet integrity guarantee, it is RECOMMENDED to be set to zero as well. Otherwise, using zero checksum is NOT RECOMMENDED. Note that other IP encapsulations for MPLS do not have a checksum in the tunnel header. > > > > If you still believe the above text is not satisfactory, please provide your text. > > > > Best regards, > > Xiaohu > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > [xuxiaohu@huawei.com] > > > Sent: 23 January 2014 03:16 > > > To: Alexander Vainshtein; Eggert, Lars > > > Cc: Joel Jaeggli; mpls@ietf.org > > > Subject: Re: [mpls] Last Call: (Encapsulating > > > MPLS in UDP) to Proposed Standard > > > > > > Hi > > > > > > > -----ÓʼþÔ­¼þ----- > > > > ·¢¼þÈË: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ22ÈÕ 19:05 > > > > ÊÕ¼þÈË: Eggert, Lars > > > > ³­ËÍ: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Lars and all, > > > > Last time I've counted the IETF LC thread on this draft has more than > > > > 150 messages in it, and it seems that on some issues (congestion > > > > control and UDP > > > > checksums) we are going round the mulberry bush. > > > > > > > > IMHO and FWIW: > > > > - UDP checksums (or lack thereof) is a non-issue because native MPLS > > > > does not have anything like that. And yes, there are cases where > > > > packets are corrupted within the routers), but so far it did not > > > > prevent MPLS deployment. There is, e.g., RFC 4720 for FCS retention in > > > > PWs, but I doubt it is widely implemented and deployed (would be nice to > > > know). > > > > - E2E congestion control (regardless of its implications) simply > > > > cannot be added to this protocol without some major changes. A short > > > > applicability statement explaining that should suffice IMO. > > > > > > Hi Sasha, > > > > > > I fully agree with your points. > > > > > > Best regards, > > > Xiaohu > > > > > > > My 2c, > > > > Sasha > > > > Email: Alexander.Vainshtein@ecitele.com > > > > Mobile: 054-9266302 > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars > > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > > To: Xuxiaohu > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > Subject: Re: [mpls] Last Call: > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > Hi, > > > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > > > > forwarded through "UDP tunnels", the congestion control guidelines > > > > > for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be > > > followed. > > > > > Specifically, MPLS can carry a number of different protocols as payloads. > > > > > When an UDP tunnel is used for MPLS payload traffic that is known at > > > > > configuration time to be IP-based and congestion-controlled, the UDP > > > > > tunnel SHOULD NOT employ its own congestion control mechanism, > > > > > because congestion losses of tunneled traffic will trigger an > > > > > congestion response at the original senders of the tunneled traffic. > > > > > When an UDP tunnel is used for MPLS payload traffic that is known at > > > > > configuration time not to be IP-based and congestion-controlled, the > > > > > UDP tunnel SHOULD employ an appropriate congestion control mechanism > > > > > as described in [RFC3985]. Note that it STRONGLY RECOMMENDED to > > > > > deploy such encapsulation technology only within a SP network or > > > > > networks of an adjacent set of co-operating SPs, rather than over the > > > Internet. > > > > > Furthermore, packet filters should be added to block traffic with > > > > > the UDP port number for MPLS over UDP to prevent MPLS over UDP > > > > > packets to escape from the service provider networks due to > > > > > misconfiguation or packet > > > > errors. > > > > > > > > > > I think it would be better to describe the OAM control loop in > > > > > (some) more detail, rather than pointing to RFC3985, which doesn't > > > > > have a whole lot of detail either. Also because the adding of > > > > > firewall rules requires an OAM hook. > > > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > > RECOMMENDED is > > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > > > Finally, the applicability statement should be prominently made in > > > > > the abstract, introduction, etc. > > > > > > > > > > Lars From curtis@ipv6.occnc.com Sat Jan 25 12:25:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850F51A0041 for ; Sat, 25 Jan 2014 12:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RP_MATCHES_RCVD=-0.535, 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 5zsFWpTx1Lfx for ; Sat, 25 Jan 2014 12:25:31 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id E8EAC1A0027 for ; Sat, 25 Jan 2014 12:25:30 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0PKPKtn048651; Sat, 25 Jan 2014 15:25:20 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401252025.s0PKPKtn048651@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Fri, 24 Jan 2014 05:04:55 +0000." <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.ac.uk> Date: Sat, 25 Jan 2014 15:25:20 -0500 Cc: mpls@ietf.org, joelja@bogus.com, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 20:25:35 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > Ah, make that: > > "Generally speaking, a UDP checksum SHOULD be used. The > considerations described in detail in [RFC6935] [RFC6936] MUST be > examined if UDP checksums need to be disabled for performance or > implementation reasons for traffic across private networks. The use > of a zero UDP checksum is NOT RECOMMENDED." > > ie if you're even thinking of turning off checksums, go read those > RFCs first. > > Lloyd Wood > http://about.me/lloydwood This is fine with me but Xuxiaohu is the author. I would go a little further with the wording: Except in extroidinary cases, UDP checksum SHOULD be used. The considerations described in detail in [RFC6935] [RFC6936] MUST be examined if UDP checksums need to be disabled for performance or implementation reasons. UDP checksum should only be disabled on private networks or where MPLS in UDP encapsualation is added by a service provider with MPLS in UDP traffic entirely confined to the network of that service provider or cooperating service providers with explicit permission. Where it is not possible to use full UDP checksum, and if using UDP-Lite [RFC3828] is feasible, UDP-Lite SHOULD be used rather than UDP with disabled checksums. Is this better? Xuxiaohu - is this OK with you? Curtis > From: Wood L Dr (Electronic Eng) > Sent: 24 January 2014 05:00 > To: Xuxiaohu; curtis@ipv6.occnc.com > Cc: Alexander.Vainshtein@ecitele.com; lars@netapp.com; joelja@bogus.com; mpls@ietf.org > Subject: RE: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > I would be good with: > > "Generally speaking, a UDP checksum SHOULD be used. The considerations described in [RFC6935] [RFC6936] SHOULD be examined if UDP checksums need to be disabled for performance or implementation reasons for traffic across private networks. The use of a zero UDP checksum is NOT RECOMMENDED." > > I wouldn't make this IPv6 specific - IPv4 still has problems (UDP port demux), IPv6's problems are just worse. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Xuxiaohu [xuxiaohu@huawei.com] > Sent: 24 January 2014 04:00 > To: curtis@ipv6.occnc.com; Wood L Dr (Electronic Eng) > Cc: Alexander.Vainshtein@ecitele.com; lars@netapp.com; joelja@bogus.com; mpls@ietf.org > Subject: re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > Hi, > > Please check whether the following text is OK. > > In the IPv6 UDP encapsulation case, as for whether or not it is suitable to use the zero-checksum node, the requirements defined in [RFC6935] [RFC6936] SHOULD be strictly followed. Generally speaking, the use of a zero UDP checksum is NOT RECOMMENDED. Note that other IP encapsulations for MPLS do not have a checksum in the tunnel header. > > Best regards, > Xiaohu > > > -----ÓʼþÔ­¼þ----- > > ·¢¼þÈË: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ24ÈÕ 11:53 > > ÊÕ¼þÈË: l.wood@surrey.ac.uk > > ³­ËÍ: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com; > > joelja@bogus.com; mpls@ietf.org > > Ö÷Ìâ: Re: [mpls] Last Call: (Encapsulating MPLS > > in UDP) to Proposed Standard > > > > > > In message > > <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.a > > c.uk> > > l.wood@surrey.ac.uk writes: > > > > > the text is not satisfactory. never recommend setting to zero, as that > > > poses a risk to your and to other traffic. Suggested text: > > > *** > > > The UDP checksum SHOULD be used to protect the payload and ensure > > > correct demultiplexing and delivery to the tunnel, and not to other > > > UDP destinations, by protecting the UDP pseudoheader. > > > Use of a zero UDP checksum is NOT RECOMMENDED, even when desired for > > > performance or necessitated by implementation reasons, for the reasons > > > outlined in [RFC6936] section 3. > > > > I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to zero). > > There are cases where it is impossible so it can't be MUST. > > > > > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS stack > > > integrity check while avoiding the overhead of computing an integrity > > > check over a tunnelled frame that has its own integrity check. > > > > UDP-List doesn't solve the ECMP problems because most of the older LSR that > > are forcing the use of MPLS over UDP to get ECMP don't look at the port > > numbers if the protocol is not 6 or 17. But this has only been said three or four > > times so maybe you missed it. > > > > > *** > > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: Xuxiaohu [xuxiaohu@huawei.com] > > > Sent: 23 January 2014 12:35 > > > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; > > > lars@netapp.com > > > Cc: joelja@bogus.com; mpls@ietf.org > > > Subject: re: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > -----ÓʼþÔ­¼þ----- > > > > ·¢¼þÈË: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ23ÈÕ 12:44 > > > > ÊÕ¼þÈË: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com > > > > ³­ËÍ: joelja@bogus.com; mpls@ietf.org > > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Sasha > > > > > > > > > - UDP checksums (or lack thereof) is a non-issue because native > > > > > MPLS does not have anything like that. And yes, there are cases > > > > > where packets are corrupted within the routers) > > > > > > > > So you admit that packets can be corrupted within the routers - a > > > > check that can only be caught by an end-to-end check, a corruption > > > > that can lead to the problems detailed in RFC 6936 section 3 - and > > > > then you say it's a non-issue because this doesn't affect native MPLS. But > > we're not doing native MPLS here. > > > > We're doing MPLS over UDP. > > > > > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's an issue. > > > > Please read the other 150 messages that you refer to. > > > > > > Hi Lloyd, > > > > > > The draft doesn't require the IPv6 UDP checksum to be set to zero regardless. > > See the following text quoted from that draft: > > > > > > UDP Checksum > > > > > > The usage of this field is in accordance with the current UDP specification > > [RFC768]. To simplify the operation on the decapsulator, this field is > > RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In the IPv6 > > UDP encapsulation case, if appropriate according to the requirements defined in > > [RFC6935] [RFC6936], this field is also RECOMMENDED to be set to zero. > > Specifically, if the MPLS payload is Internet Protocol (IPv4 or IPv6) packets, it is > > RECOMMENDED to be set to zero when the inner packet integrity checks is > > available. In addition, if the MPLS payload is non-IP packet which is specifically > > designed for transmission over a lower layer that does not provide a packet > > integrity guarantee, it is RECOMMENDED to be set to zero as well. Otherwise, > > using zero checksum is NOT RECOMMENDED. Note that other IP encapsulations > > for MPLS do not have a checksum in the tunnel header. > > > > > > If you still believe the above text is not satisfactory, please provide your text. > > > > > > Best regards, > > > Xiaohu > > > > > > > Lloyd Wood > > > > http://about.me/lloydwood > > > > ________________________________________ > > > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > > [xuxiaohu@huawei.com] > > > > Sent: 23 January 2014 03:16 > > > > To: Alexander Vainshtein; Eggert, Lars > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > Subject: Re: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Hi > > > > > > > > > -----ÓʼþÔ­¼þ----- > > > > > ·¢¼þÈË: Alexander Vainshtein > > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ22ÈÕ 19:05 > > > > > ÊÕ¼þÈË: Eggert, Lars > > > > > ³­ËÍ: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > Lars and all, > > > > > Last time I've counted the IETF LC thread on this draft has more > > > > > than > > > > > 150 messages in it, and it seems that on some issues (congestion > > > > > control and UDP > > > > > checksums) we are going round the mulberry bush. > > > > > > > > > > IMHO and FWIW: > > > > > - UDP checksums (or lack thereof) is a non-issue because native > > > > > MPLS does not have anything like that. And yes, there are cases > > > > > where packets are corrupted within the routers), but so far it did > > > > > not prevent MPLS deployment. There is, e.g., RFC 4720 for FCS > > > > > retention in PWs, but I doubt it is widely implemented and > > > > > deployed (would be nice to > > > > know). > > > > > - E2E congestion control (regardless of its implications) simply > > > > > cannot be added to this protocol without some major changes. A > > > > > short applicability statement explaining that should suffice IMO. > > > > > > > > Hi Sasha, > > > > > > > > I fully agree with your points. > > > > > > > > Best regards, > > > > Xiaohu > > > > > > > > > My 2c, > > > > > Sasha > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > Mobile: 054-9266302 > > > > > > > > > > > -----Original Message----- > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, > > > > > > Lars > > > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > > > To: Xuxiaohu > > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > > Subject: Re: [mpls] Last Call: > > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > > > Hi, > > > > > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > > > > > forwarded through "UDP tunnels", the congestion control > > > > > > guidelines for UDP tunnels as defined in Section 3.1.3 of > > > > > > [RFC5405] SHOULD be > > > > followed. > > > > > > Specifically, MPLS can carry a number of different protocols as payloads. > > > > > > When an UDP tunnel is used for MPLS payload traffic that is > > > > > > known at configuration time to be IP-based and > > > > > > congestion-controlled, the UDP tunnel SHOULD NOT employ its own > > > > > > congestion control mechanism, because congestion losses of > > > > > > tunneled traffic will trigger an congestion response at the original > > senders of the tunneled traffic. > > > > > > When an UDP tunnel is used for MPLS payload traffic that is > > > > > > known at configuration time not to be IP-based and > > > > > > congestion-controlled, the UDP tunnel SHOULD employ an > > > > > > appropriate congestion control mechanism as described in > > > > > > [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such > > > > > > encapsulation technology only within a SP network or networks of > > > > > > an adjacent set of co-operating SPs, rather than over the > > > > Internet. > > > > > > Furthermore, packet filters should be added to block traffic > > > > > > with the UDP port number for MPLS over UDP to prevent MPLS over > > > > > > UDP packets to escape from the service provider networks due to > > > > > > misconfiguation or packet > > > > > errors. > > > > > > > > > > > > I think it would be better to describe the OAM control loop in > > > > > > (some) more detail, rather than pointing to RFC3985, which > > > > > > doesn't have a whole lot of detail either. Also because the > > > > > > adding of firewall rules requires an OAM hook. > > > > > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > > > RECOMMENDED is > > > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > > > > > Finally, the applicability statement should be prominently made > > > > > > in the abstract, introduction, etc. > > > > > > > > > > > > Lars From l.wood@surrey.ac.uk Sat Jan 25 12:33:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E918E1A0040 for ; Sat, 25 Jan 2014 12:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, 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 n5qZQNPq5PCg for ; Sat, 25 Jan 2014 12:33:08 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9341A0027 for ; Sat, 25 Jan 2014 12:33:07 -0800 (PST) Received: from [195.245.230.131:51605] by server-4.bemta-3.messagelabs.com id DA/BE-10414-08F14E25; Sat, 25 Jan 2014 20:33:04 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-16.tower-78.messagelabs.com!1390681983!29794081!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27417 invoked from network); 25 Jan 2014 20:33:03 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-16.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jan 2014 20:33:03 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Sat, 25 Jan 2014 20:33:02 +0000 From: To: Date: Sat, 25 Jan 2014 20:32:42 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8aCi+OpTx+vgbXQQCtWSOyx5ZTlwAAmkz6 Message-ID: <290E20B455C66743BE178C5C84F1240847E63346F2@EXMB01CMS.surrey.ac.uk> References: Your message of "Fri, 24 Jan 2014 04:55:46 +0000." <290E20B455C66743BE178C5C84F1240847E63346EC@EXMB01CMS.surrey.ac.uk>, <201401252014.s0PKEMun048512@maildrop2.v6ds.occnc.com> In-Reply-To: <201401252014.s0PKEMun048512@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 20:33:12 -0000 yes, ok Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 25 January 2014 20:14 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com; xuxiaohu@huawei.com; Alexander.Vainshtein@ecitel= e.com; lars@netapp.com; joelja@bogus.com; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard In message <290E20B455C66743BE178C5C84F1240847E63346EC@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > > I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to > > zero). There are cases where it is impossible so it can't be MUST. > > Agreed. > > > UDP-List doesn't solve the ECMP problems because most of the older LSR > > that are forcing the use of MPLS over UDP to get ECMP don't look at > > the port numbers if the protocol is not 6 or 17. But this has only > > been said three or four times so maybe you missed it. > > I believe you mean Lite, not List. UDP-Lite is standards track, and > solves the performance concern while providing the demux check > that IPv4 needs and v6 needs even more. It's worth mentioning > for that reason; it is well-suited to this problem. Typo. I meant UDP-Lite. > (There's a lot of older MPLS hardware out there that only does > IPv4. Why is the draft mentioning v6? Or perhaps we shouldn't > be completely constrained by the field?) There is a lot of brand new hardware being shipped today that only looks for protocol 6 or 17. However a useful addition to the draft would be: If it is not possible to use UDP checksums, and if it is possible to use UDP-Lite [RFCxxxx] then UDP-Lite is a better solution than UDP with zero checksums. OK? Curtis > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 24 January 2014 03:52 > To: Wood L Dr (Electronic Eng) > Cc: xuxiaohu@huawei.com; Alexander.Vainshtein@ecitele.com; lars@netapp.co= m; joelja@bogus.com; mpls@ietf.org > Subject: Re: [mpls] Last Call: (Encapsula= ting MPLS in UDP) to Proposed Standard > > In message <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.a= c.uk> > l.wood@surrey.ac.uk writes: > > > the text is not satisfactory. never recommend setting to zero, > > as that poses a risk to your and to other traffic. Suggested text: > > *** > > The UDP checksum SHOULD be used to protect the payload and > > ensure correct demultiplexing and delivery to the tunnel, and not to > > other UDP destinations, by protecting the UDP pseudoheader. > > Use of a zero UDP checksum is NOT RECOMMENDED, even when > > desired for performance or necessitated by implementation > > reasons, for the reasons outlined in [RFC6936] section 3. > > I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to > zero). There are cases where it is impossible so it can't be MUST. > > > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS > > stack integrity check while avoiding the overhead of computing an > > integrity check over a tunnelled frame that has its own integrity check= . > > UDP-List doesn't solve the ECMP problems because most of the older LSR > that are forcing the use of MPLS over UDP to get ECMP don't look at > the port numbers if the protocol is not 6 or 17. But this has only > been said three or four times so maybe you missed it. > > > *** > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Xuxiaohu [xuxiaohu@huawei.com] > > Sent: 23 January 2014 12:35 > > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; lars= @netapp.com > > Cc: joelja@bogus.com; mpls@ietf.org > > Subject: re: [mpls] Last Call: (Encapsu= lating MPLS in UDP) to Proposed Standard > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C223=C8=D5 12:44 > > > =CA=D5=BC=FE=C8=CB: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@= netapp.com > > > =B3=AD=CB=CD: joelja@bogus.com; mpls@ietf.org > > > =D6=F7=CC=E2: RE: [mpls] Last Call: (= Encapsulating MPLS > > > in UDP) to Proposed Standard > > > > > > Sasha > > > > > > > - UDP checksums (or lack thereof) is a non-issue because native MPL= S > > > > does not have anything like that. And yes, there are cases where > > > > packets are corrupted within the routers) > > > > > > So you admit that packets can be corrupted within the routers - a che= ck that can > > > only be caught by an end-to-end check, a corruption that can lead to = the > > > problems detailed in RFC 6936 section 3 - and then you say it's a non= -issue > > > because this doesn't affect native MPLS. But we're not doing native M= PLS here. > > > We're doing MPLS over UDP. > > > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's a= n issue. > > > Please read the other 150 messages that you refer to. > > > > Hi Lloyd, > > > > The draft doesn't require the IPv6 UDP checksum to be set to zero regar= dless. See the following text quoted from that draft: > > > > UDP Checksum > > > > The usage of this field is in accordance with the current UDP specifica= tion [RFC768]. To simplify the operation on the decapsulator, this field is= RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In the IPv6 = UDP encapsulation case, if appropriate according to the requirements define= d in [RFC6935] [RFC6936], this field is also RECOMMENDED to be set to zero.= Specifically, if the MPLS payload is Internet Protocol (IPv4 or IPv6) pack= ets, it is RECOMMENDED to be set to zero when the inner packet integrity ch= ecks is available. In addition, if the MPLS payload is non-IP packet which = is specifically designed for transmission over a lower layer that does not = provide a packet integrity guarantee, it is RECOMMENDED to be set to zero a= s well. Otherwise, using zero checksum is NOT RECOMMENDED. Note that other = IP encapsulations for MPLS do not have a checksum in the tunnel header. > > > > If you still believe the above text is not satisfactory, please provide= your text. > > > > Best regards, > > Xiaohu > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > [xuxiaohu@huawei.com] > > > Sent: 23 January 2014 03:16 > > > To: Alexander Vainshtein; Eggert, Lars > > > Cc: Joel Jaeggli; mpls@ietf.org > > > Subject: Re: [mpls] Last Call: (Encap= sulating > > > MPLS in UDP) to Proposed Standard > > > > > > Hi > > > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > > =B7=A2=BC=FE=C8=CB: Alexander Vainshtein [mailto:Alexander.Vainshte= in@ecitele.com] > > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C222=C8=D5 19:05 > > > > =CA=D5=BC=FE=C8=CB: Eggert, Lars > > > > =B3=AD=CB=CD: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > > =D6=F7=CC=E2: RE: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Lars and all, > > > > Last time I've counted the IETF LC thread on this draft has more th= an > > > > 150 messages in it, and it seems that on some issues (congestion > > > > control and UDP > > > > checksums) we are going round the mulberry bush. > > > > > > > > IMHO and FWIW: > > > > - UDP checksums (or lack thereof) is a non-issue because native MPL= S > > > > does not have anything like that. And yes, there are cases where > > > > packets are corrupted within the routers), but so far it did not > > > > prevent MPLS deployment. There is, e.g., RFC 4720 for FCS retention= in > > > > PWs, but I doubt it is widely implemented and deployed (would be ni= ce to > > > know). > > > > - E2E congestion control (regardless of its implications) simply > > > > cannot be added to this protocol without some major changes. A shor= t > > > > applicability statement explaining that should suffice IMO. > > > > > > Hi Sasha, > > > > > > I fully agree with your points. > > > > > > Best regards, > > > Xiaohu > > > > > > > My 2c, > > > > Sasha > > > > Email: Alexander.Vainshtein@ecitele.com > > > > Mobile: 054-9266302 > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, La= rs > > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > > To: Xuxiaohu > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > Subject: Re: [mpls] Last Call: > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > Hi, > > > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > > > > forwarded through "UDP tunnels", the congestion control guideline= s > > > > > for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD b= e > > > followed. > > > > > Specifically, MPLS can carry a number of different protocols as p= ayloads. > > > > > When an UDP tunnel is used for MPLS payload traffic that is known= at > > > > > configuration time to be IP-based and congestion-controlled, the = UDP > > > > > tunnel SHOULD NOT employ its own congestion control mechanism, > > > > > because congestion losses of tunneled traffic will trigger an > > > > > congestion response at the original senders of the tunneled traff= ic. > > > > > When an UDP tunnel is used for MPLS payload traffic that is known= at > > > > > configuration time not to be IP-based and congestion-controlled, = the > > > > > UDP tunnel SHOULD employ an appropriate congestion control mechan= ism > > > > > as described in [RFC3985]. Note that it STRONGLY RECOMMENDED to > > > > > deploy such encapsulation technology only within a SP network or > > > > > networks of an adjacent set of co-operating SPs, rather than over= the > > > Internet. > > > > > Furthermore, packet filters should be added to block traffic with > > > > > the UDP port number for MPLS over UDP to prevent MPLS over UDP > > > > > packets to escape from the service provider networks due to > > > > > misconfiguation or packet > > > > errors. > > > > > > > > > > I think it would be better to describe the OAM control loop in > > > > > (some) more detail, rather than pointing to RFC3985, which doesn'= t > > > > > have a whole lot of detail either. Also because the adding of > > > > > firewall rules requires an OAM hook. > > > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > > RECOMMENDED is > > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > > > Finally, the applicability statement should be prominently made i= n > > > > > the abstract, introduction, etc. > > > > > > > > > > Lars From curtis@ipv6.occnc.com Sat Jan 25 12:35:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4121A0040 for ; Sat, 25 Jan 2014 12:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 yZMJ9-98IHEZ for ; Sat, 25 Jan 2014 12:35:02 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 431401A0027 for ; Sat, 25 Jan 2014 12:35:02 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0PKYrAF048759; Sat, 25 Jan 2014 15:34:53 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401252034.s0PKYrAF048759@maildrop2.v6ds.occnc.com> To: Xuxiaohu From: Curtis Villamizar In-reply-to: Your message of "Fri, 24 Jan 2014 02:42:06 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478FD@NKGEML512-MBS.china.huawei.com> Date: Sat, 25 Jan 2014 15:34:53 -0500 Cc: "joelja@bogus.com" , "mpls@ietf.org" , "lars@netapp.com" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 20:35:04 -0000 In message <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478FD@NKGEML512-MBS.china.huawei.com> Xuxiaohu writes: > > > > I am not against the bulk of RFC6936. But unlike '36, > > RFC6935 is very much written for the benefit of tunnelers. > > > > RFC6935 and 36 can be read to give conflicting advice (35 - zero! > > 36 - um, that leads to these subtle and nuanced prroblems, so maybe not), so > > just referring to them and leaving the implementer without clear > > direction is not sufficient imo. > > If so, wouldn't it be better to solve such confliction and confusion > caused by 6935 and 6936 by updating them? Since these two drafts are > originated from the TSV WG, it should represent the rogue WG consensus > instead of making confusion to others. > > Best regards, > Xiaohu I believe you meant "rough" but perhaps "rogue" works too. :-) Curtis From curtis@ipv6.occnc.com Sat Jan 25 12:47:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DAB1A0067 for ; Sat, 25 Jan 2014 12:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuTS6kZJgN7e for ; Sat, 25 Jan 2014 12:47:55 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id C10F61A0045 for ; Sat, 25 Jan 2014 12:47:54 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0PKlmgS048899; Sat, 25 Jan 2014 15:47:49 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401252047.s0PKlmgS048899@maildrop2.v6ds.occnc.com> To: Greg Daley From: Curtis Villamizar In-reply-to: Your message of "Fri, 24 Jan 2014 03:38:44 +0000." <72381AF1F18BAE4F890A0813768D992817FD35E1@sdcexchms.au.logicalis.com> Date: Sat, 25 Jan 2014 15:47:48 -0500 Cc: "mpls@ietf.org" , IETF discussion list , Joe Touch , Noel Chiappa Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 20:47:56 -0000 In message <72381AF1F18BAE4F890A0813768D992817FD35E1@sdcexchms.au.logicalis.com> Greg Daley writes: > Hi Joel, > > > -----Original Message----- > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: Friday, 24 January 2014 1:32 PM > > To: Joe Touch; Edward Crabbe > > Cc: mpls@ietf.org; Noel Chiappa; IETF discussion list > > Subject: Re: [mpls] Last Call: (Encapsulating > > MPLS in UDP) to Proposed Standard > > > > Joe, while your argument is internally consistent, it is not consistent with > > history. We have not demanded that tunnel entries behave fully like source > > hosts for any of the other myriad kinds of tunnels we have done over the years. > > > Actually, many of the tunnel protocols on the standards track have > been either for upper-layer IP or Transport protocols or require > congestion mitigation: > > RFC 4448 for EoMPLS, and 5994 for Ethernet pseudowires over MPLS > each ask that tunnelled protocols support congestion mechanisms, > RFC5085 and 5586: VCCV and BFD with VCCV define congestion > considerations for pseudowire tunnels. RFC 4719 updated by RFC > 5641: Ethernet pseudowires over L2TP (a UDP encapsulated protocol) > permit packet loss indications to take down the active circuit. > RFC 4454: ATM over L2TPv3 indicates that inelastic flows are > stopped when congestion occurs. > > They (ATM over L2TPv3 and Ethernet PW over L2TPv3) also require usage > over a traffic engineered network. > > RFC 4817 MPLS over L2TPv3 requires non-IP upper layer protocols not to > exceed the offered load of a typical TCP application on the same path. > > For those protocols which have IP, UDP, TCP, SCCP or DCCP this is just > passing the buck to the upper layer protocol (which is OK, so long as > the application protocol in UDP has congestion measures). For > environments where this cannot be relied upon, additional protocol > specification and applicability statements have previously been > applied. > > > If we take your logic as stated, then the usage of IPSec over UDP would be > > required to apply congestion control unless it knew that all the > > content traffic was TCP. Is that really your intent? > > Actually, one of the compelling use cases for running MPLS over UDP > (or L2TPv3) would be to encapsulate the traffic in ESP in order to > combat passive snooping. > > For ESP I believe the implicit assumption (via the Traffic Selectors > in IKE) was that the upper layer protocol is IP or in transport mode > another protocol such as TCP, UDP etc. > > Sincerely, > > Greg Daley > gdaley@au.logicalis.com Reality check time. To get the PW over MPLS drafts past the TSV AD there is a SHOULD regarding congestion control. AFAIK: No service providers ask for it. No one implements it. If they did implement it no one would deploy it. PW over MPLS is generally carrying relatively low volumes of high priority traffic. The TC bits (MPLS flavor of Diffserv DSCP) are used to enforce the higher priority. If congestion occurs other traffic on that infrastructure (typically plain old Internet) sees loss. That is intended. This is the reality of how PW over MPLS is deployed. Anyone who knows of implementation or deployment of congestion control for PW over MPLS can correct me. I don't know about the "over GRE" or "over L2TP" tunneling. Curtis From l.wood@surrey.ac.uk Sat Jan 25 14:39:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646D01A00A4 for ; Sat, 25 Jan 2014 14:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 47_SDqWN-Z1k for ; Sat, 25 Jan 2014 14:39:14 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.144]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBEE1A009D for ; Sat, 25 Jan 2014 14:39:13 -0800 (PST) Received: from [85.158.136.51:47395] by server-8.bemta-5.messagelabs.com id 24/DF-29838-D0D34E25; Sat, 25 Jan 2014 22:39:09 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-13.tower-49.messagelabs.com!1390689548!15736466!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30699 invoked from network); 25 Jan 2014 22:39:09 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-13.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jan 2014 22:39:09 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Sat, 25 Jan 2014 22:39:08 +0000 From: To: Date: Sat, 25 Jan 2014 22:35:00 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8aC5tbgFqIpxkbSnqwqHmRPnq+dgAEhN0m Message-ID: <290E20B455C66743BE178C5C84F1240847E63346F3@EXMB01CMS.surrey.ac.uk> References: Your message of "Fri, 24 Jan 2014 05:04:55 +0000." <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.ac.uk>, <201401252025.s0PKPKtn048651@maildrop2.v6ds.occnc.com> In-Reply-To: <201401252025.s0PKPKtn048651@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joelja@bogus.com, mpls@ietf.org, lars@netapp.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 22:39:20 -0000 Curtis, thanks, this is good, and I think sets the right tone: lays out the warning= s, indicates the existence of an appropriate engineering solution (Lite), and while recognising performance needs, does not favour performance over reliability. (typos: extraordinary, the full UDP checksum) I like it. I hope X does too. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 25 January 2014 20:25 To: Wood L Dr (Electronic Eng) Cc: xuxiaohu@huawei.com; curtis@ipv6.occnc.com; Alexander.Vainshtein@ecitel= e.com; lars@netapp.com; joelja@bogus.com; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard In message <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > Ah, make that: > > "Generally speaking, a UDP checksum SHOULD be used. The > considerations described in detail in [RFC6935] [RFC6936] MUST be > examined if UDP checksums need to be disabled for performance or > implementation reasons for traffic across private networks. The use > of a zero UDP checksum is NOT RECOMMENDED." > > ie if you're even thinking of turning off checksums, go read those > RFCs first. > > Lloyd Wood > http://about.me/lloydwood This is fine with me but Xuxiaohu is the author. I would go a little further with the wording: Except in extroidinary cases, UDP checksum SHOULD be used. The considerations described in detail in [RFC6935] [RFC6936] MUST be examined if UDP checksums need to be disabled for performance or implementation reasons. UDP checksum should only be disabled on private networks or where MPLS in UDP encapsualation is added by a service provider with MPLS in UDP traffic entirely confined to the network of that service provider or cooperating service providers with explicit permission. Where it is not possible to use full UDP checksum, and if using UDP-Lite [RFC3828] is feasible, UDP-Lite SHOULD be used rather than UDP with disabled checksums. Is this better? Xuxiaohu - is this OK with you? Curtis > From: Wood L Dr (Electronic Eng) > Sent: 24 January 2014 05:00 > To: Xuxiaohu; curtis@ipv6.occnc.com > Cc: Alexander.Vainshtein@ecitele.com; lars@netapp.com; joelja@bogus.com; = mpls@ietf.org > Subject: RE: [mpls] Last Call: (Encapsula= ting MPLS in UDP) to Proposed Standard > > I would be good with: > > "Generally speaking, a UDP checksum SHOULD be used. The considerations de= scribed in [RFC6935] [RFC6936] SHOULD be examined if UDP checksums need to = be disabled for performance or implementation reasons for traffic across pr= ivate networks. The use of a zero UDP checksum is NOT RECOMMENDED." > > I wouldn't make this IPv6 specific - IPv4 still has problems (UDP port de= mux), IPv6's problems are just worse. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Xuxiaohu [xuxiaohu@huawei.com] > Sent: 24 January 2014 04:00 > To: curtis@ipv6.occnc.com; Wood L Dr (Electronic Eng) > Cc: Alexander.Vainshtein@ecitele.com; lars@netapp.com; joelja@bogus.com; = mpls@ietf.org > Subject: re: [mpls] Last Call: (Encapsula= ting MPLS in UDP) to Proposed Standard > > Hi, > > Please check whether the following text is OK. > > In the IPv6 UDP encapsulation case, as for whether or not it is suitable = to use the zero-checksum node, the requirements defined in [RFC6935] [RFC69= 36] SHOULD be strictly followed. Generally speaking, the use of a zero UDP = checksum is NOT RECOMMENDED. Note that other IP encapsulations for MPLS do = not have a checksum in the tunnel header. > > Best regards, > Xiaohu > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C224=C8=D5 11:53 > > =CA=D5=BC=FE=C8=CB: l.wood@surrey.ac.uk > > =B3=AD=CB=CD: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.c= om; > > joelja@bogus.com; mpls@ietf.org > > =D6=F7=CC=E2: Re: [mpls] Last Call: (En= capsulating MPLS > > in UDP) to Proposed Standard > > > > > > In message > > <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.a > > c.uk> > > l.wood@surrey.ac.uk writes: > > > > > the text is not satisfactory. never recommend setting to zero, as tha= t > > > poses a risk to your and to other traffic. Suggested text: > > > *** > > > The UDP checksum SHOULD be used to protect the payload and ensure > > > correct demultiplexing and delivery to the tunnel, and not to other > > > UDP destinations, by protecting the UDP pseudoheader. > > > Use of a zero UDP checksum is NOT RECOMMENDED, even when desired for > > > performance or necessitated by implementation reasons, for the reason= s > > > outlined in [RFC6936] section 3. > > > > I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to zer= o). > > There are cases where it is impossible so it can't be MUST. > > > > > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS stack > > > integrity check while avoiding the overhead of computing an integrity > > > check over a tunnelled frame that has its own integrity check. > > > > UDP-List doesn't solve the ECMP problems because most of the older LSR = that > > are forcing the use of MPLS over UDP to get ECMP don't look at the port > > numbers if the protocol is not 6 or 17. But this has only been said th= ree or four > > times so maybe you missed it. > > > > > *** > > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: Xuxiaohu [xuxiaohu@huawei.com] > > > Sent: 23 January 2014 12:35 > > > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; > > > lars@netapp.com > > > Cc: joelja@bogus.com; mpls@ietf.org > > > Subject: re: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > > =B7=A2=BC=FE=C8=CB: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk= ] > > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C223=C8=D5 12:44 > > > > =CA=D5=BC=FE=C8=CB: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lar= s@netapp.com > > > > =B3=AD=CB=CD: joelja@bogus.com; mpls@ietf.org > > > > =D6=F7=CC=E2: RE: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Sasha > > > > > > > > > - UDP checksums (or lack thereof) is a non-issue because native > > > > > MPLS does not have anything like that. And yes, there are cases > > > > > where packets are corrupted within the routers) > > > > > > > > So you admit that packets can be corrupted within the routers - a > > > > check that can only be caught by an end-to-end check, a corruption > > > > that can lead to the problems detailed in RFC 6936 section 3 - and > > > > then you say it's a non-issue because this doesn't affect native MP= LS. But > > we're not doing native MPLS here. > > > > We're doing MPLS over UDP. > > > > > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's= an issue. > > > > Please read the other 150 messages that you refer to. > > > > > > Hi Lloyd, > > > > > > The draft doesn't require the IPv6 UDP checksum to be set to zero reg= ardless. > > See the following text quoted from that draft: > > > > > > UDP Checksum > > > > > > The usage of this field is in accordance with the current UDP specifi= cation > > [RFC768]. To simplify the operation on the decapsulator, this field is > > RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In the IP= v6 > > UDP encapsulation case, if appropriate according to the requirements de= fined in > > [RFC6935] [RFC6936], this field is also RECOMMENDED to be set to zero. > > Specifically, if the MPLS payload is Internet Protocol (IPv4 or IPv6) p= ackets, it is > > RECOMMENDED to be set to zero when the inner packet integrity checks is > > available. In addition, if the MPLS payload is non-IP packet which is s= pecifically > > designed for transmission over a lower layer that does not provide a pa= cket > > integrity guarantee, it is RECOMMENDED to be set to zero as well. Other= wise, > > using zero checksum is NOT RECOMMENDED. Note that other IP encapsulatio= ns > > for MPLS do not have a checksum in the tunnel header. > > > > > > If you still believe the above text is not satisfactory, please provi= de your text. > > > > > > Best regards, > > > Xiaohu > > > > > > > Lloyd Wood > > > > http://about.me/lloydwood > > > > ________________________________________ > > > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > > [xuxiaohu@huawei.com] > > > > Sent: 23 January 2014 03:16 > > > > To: Alexander Vainshtein; Eggert, Lars > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > Subject: Re: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > Hi > > > > > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > > > =B7=A2=BC=FE=C8=CB: Alexander Vainshtein > > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C222=C8=D5 19:05 > > > > > =CA=D5=BC=FE=C8=CB: Eggert, Lars > > > > > =B3=AD=CB=CD: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > > > =D6=F7=CC=E2: RE: [mpls] Last Call: > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > Lars and all, > > > > > Last time I've counted the IETF LC thread on this draft has more > > > > > than > > > > > 150 messages in it, and it seems that on some issues (congestion > > > > > control and UDP > > > > > checksums) we are going round the mulberry bush. > > > > > > > > > > IMHO and FWIW: > > > > > - UDP checksums (or lack thereof) is a non-issue because native > > > > > MPLS does not have anything like that. And yes, there are cases > > > > > where packets are corrupted within the routers), but so far it di= d > > > > > not prevent MPLS deployment. There is, e.g., RFC 4720 for FCS > > > > > retention in PWs, but I doubt it is widely implemented and > > > > > deployed (would be nice to > > > > know). > > > > > - E2E congestion control (regardless of its implications) simply > > > > > cannot be added to this protocol without some major changes. A > > > > > short applicability statement explaining that should suffice IMO. > > > > > > > > Hi Sasha, > > > > > > > > I fully agree with your points. > > > > > > > > Best regards, > > > > Xiaohu > > > > > > > > > My 2c, > > > > > Sasha > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > Mobile: 054-9266302 > > > > > > > > > > > -----Original Message----- > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, > > > > > > Lars > > > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > > > To: Xuxiaohu > > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > > Subject: Re: [mpls] Last Call: > > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > > > Hi, > > > > > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > > > > > forwarded through "UDP tunnels", the congestion control > > > > > > guidelines for UDP tunnels as defined in Section 3.1.3 of > > > > > > [RFC5405] SHOULD be > > > > followed. > > > > > > Specifically, MPLS can carry a number of different protocols as= payloads. > > > > > > When an UDP tunnel is used for MPLS payload traffic that is > > > > > > known at configuration time to be IP-based and > > > > > > congestion-controlled, the UDP tunnel SHOULD NOT employ its own > > > > > > congestion control mechanism, because congestion losses of > > > > > > tunneled traffic will trigger an congestion response at the ori= ginal > > senders of the tunneled traffic. > > > > > > When an UDP tunnel is used for MPLS payload traffic that is > > > > > > known at configuration time not to be IP-based and > > > > > > congestion-controlled, the UDP tunnel SHOULD employ an > > > > > > appropriate congestion control mechanism as described in > > > > > > [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such > > > > > > encapsulation technology only within a SP network or networks o= f > > > > > > an adjacent set of co-operating SPs, rather than over the > > > > Internet. > > > > > > Furthermore, packet filters should be added to block traffic > > > > > > with the UDP port number for MPLS over UDP to prevent MPLS over > > > > > > UDP packets to escape from the service provider networks due to > > > > > > misconfiguation or packet > > > > > errors. > > > > > > > > > > > > I think it would be better to describe the OAM control loop in > > > > > > (some) more detail, rather than pointing to RFC3985, which > > > > > > doesn't have a whole lot of detail either. Also because the > > > > > > adding of firewall rules requires an OAM hook. > > > > > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > > > RECOMMENDED is > > > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > > > > > Finally, the applicability statement should be prominently made > > > > > > in the abstract, introduction, etc. > > > > > > > > > > > > Lars From xuxiaohu@huawei.com Sat Jan 25 17:04:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EDC1A00C1 for ; Sat, 25 Jan 2014 17:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 vyYk7R6lXxs8 for ; Sat, 25 Jan 2014 17:04:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 476B01A00BF for ; Sat, 25 Jan 2014 17:04:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAK57196; Sun, 26 Jan 2014 01:04:30 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 01:04:05 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 01:04:28 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 09:04:22 +0800 From: Xuxiaohu To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGgzmVpx4VpP9lE+4fynfG27EApqWMIWw Date: Sun, 26 Jan 2014 01:04:21 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247F97@NKGEML512-MBS.china.huawei.com> References: Your message of "Fri, 24 Jan 2014 02:42:06 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082478FD@NKGEML512-MBS.china.huawei.com> <201401252034.s0PKYrAF048759@maildrop2.v6ds.occnc.com> In-Reply-To: <201401252034.s0PKYrAF048759@maildrop2.v6ds.occnc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" , "lars@netapp.com" Subject: [mpls] =?gb2312?b?tPC4tDogIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1pbi11ZHAtMDQudHh0PiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkg?= =?gb2312?b?dG8gUHJvcG9zZWQgU3RhbmRhcmQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 01:04:38 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogQ3VydGlzIFZpbGxhbWl6YXIgW21h aWx0bzpjdXJ0aXNAaXB2Ni5vY2NuYy5jb21dDQo+ILeiy83KsbzkOiAyMDE0xOox1MIyNsjVIDQ6 MzUNCj4gytW8/sjLOiBYdXhpYW9odQ0KPiCzrcvNOiBsLndvb2RAc3VycmV5LmFjLnVrOyBBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsNCj4gbGFyc0BuZXRhcHAuY29tOyBqb2VsamFA Ym9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+INb3zOI6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8 ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+IChFbmNhcHN1bGF0aW5nIE1QTFMNCj4gaW4g VURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gDQo+IEluIG1lc3NhZ2UNCj4gPDFGRUUz RjhGNUNDREU2NEM5QThFOEY0QUQyN0MxOUVFMDgyNDc4RkRATktHRU1MNTEyLU1CUy5jaGluYS4N Cj4gaHVhd2VpLmNvbT4NCj4gWHV4aWFvaHUgd3JpdGVzOg0KPiA+ID4NCj4gPiA+IEkgYW0gbm90 IGFnYWluc3QgdGhlIGJ1bGsgb2YgUkZDNjkzNi4gQnV0IHVubGlrZSAnMzYsDQo+ID4gPiBSRkM2 OTM1IGlzIHZlcnkgbXVjaCB3cml0dGVuIGZvciB0aGUgYmVuZWZpdCBvZiB0dW5uZWxlcnMuDQo+ ID4gPg0KPiA+ID4gUkZDNjkzNSBhbmQgMzYgY2FuIGJlIHJlYWQgdG8gZ2l2ZSBjb25mbGljdGlu ZyBhZHZpY2UgKDM1IC0gemVybyENCj4gPiA+IDM2IC0gdW0sIHRoYXQgbGVhZHMgdG8gdGhlc2Ug c3VidGxlIGFuZCBudWFuY2VkIHBycm9ibGVtcywgc28gbWF5YmUNCj4gPiA+IG5vdCksIHNvIGp1 c3QgcmVmZXJyaW5nIHRvIHRoZW0gYW5kIGxlYXZpbmcgdGhlIGltcGxlbWVudGVyIHdpdGhvdXQN Cj4gPiA+IGNsZWFyIGRpcmVjdGlvbiBpcyBub3Qgc3VmZmljaWVudCBpbW8uDQo+ID4NCj4gPiBJ ZiBzbywgd291bGRuJ3QgaXQgYmUgYmV0dGVyIHRvIHNvbHZlIHN1Y2ggY29uZmxpY3Rpb24gYW5k IGNvbmZ1c2lvbg0KPiA+IGNhdXNlZCBieSA2OTM1IGFuZCA2OTM2IGJ5IHVwZGF0aW5nIHRoZW0/ IFNpbmNlIHRoZXNlIHR3byBkcmFmdHMgYXJlDQo+ID4gb3JpZ2luYXRlZCBmcm9tIHRoZSBUU1Yg V0csIGl0IHNob3VsZCByZXByZXNlbnQgdGhlIHJvZ3VlIFdHIGNvbnNlbnN1cw0KPiA+IGluc3Rl YWQgb2YgbWFraW5nIGNvbmZ1c2lvbiB0byBvdGhlcnMuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMs DQo+ID4gWGlhb2h1DQo+IA0KPiANCj4gSSBiZWxpZXZlIHlvdSBtZWFudCAicm91Z2giIGJ1dCBw ZXJoYXBzICJyb2d1ZSIgd29ya3MgdG9vLiAgOi0pDQoNClNvcnJ5IGZvciB0aGF0IHR5cG8gZXJy b3IuIEkgbWVhbnQgInJvdWdoIi4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCg0KPiBDdXJ0 aXMNCg== From xuxiaohu@huawei.com Sat Jan 25 19:48:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E461A00E8 for ; Sat, 25 Jan 2014 19:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 0_KMt3i9Xg93 for ; Sat, 25 Jan 2014 19:48:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1F84A1A00E2 for ; Sat, 25 Jan 2014 19:48:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAK63834; Sun, 26 Jan 2014 03:48:12 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 03:47:46 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 03:48:09 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 11:48:06 +0800 From: Xuxiaohu To: "curtis@ipv6.occnc.com" , "l.wood@surrey.ac.uk" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGguRVpx4VpP9lE+4fynfG27EApqWW65Q Date: Sun, 26 Jan 2014 03:48:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082480D2@NKGEML512-MBS.china.huawei.com> References: Your message of "Fri, 24 Jan 2014 05:04:55 +0000." <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.ac.uk> <201401252025.s0PKPKtn048651@maildrop2.v6ds.occnc.com> In-Reply-To: <201401252025.s0PKPKtn048651@maildrop2.v6ds.occnc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" , "lars@netapp.com" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 03:48:22 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogQ3VydGlzIFZpbGxhbWl6YXIgW21h aWx0bzpjdXJ0aXNAaXB2Ni5vY2NuYy5jb21dDQo+ILeiy83KsbzkOiAyMDE0xOox1MIyNsjVIDQ6 MjUNCj4gytW8/sjLOiBsLndvb2RAc3VycmV5LmFjLnVrDQo+ILOty806IFh1eGlhb2h1OyBjdXJ0 aXNAaXB2Ni5vY2NuYy5jb207IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOw0KPiBs YXJzQG5ldGFwcC5jb207IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4g1vfM4jog UmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVu Y2Fwc3VsYXRpbmcgTVBMUw0KPiBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiAN Cj4gSW4gbWVzc2FnZQ0KPiA8MjkwRTIwQjQ1NUM2Njc0M0JFMTc4QzVDODRGMTI0MDg0N0U2MzM0 NkVFQEVYTUIwMUNNUy5zdXJyZXkuYQ0KPiBjLnVrPg0KPiBsLndvb2RAc3VycmV5LmFjLnVrIHdy aXRlczoNCj4gDQo+ID4gQWgsIG1ha2UgdGhhdDoNCj4gPg0KPiA+ICAgICJHZW5lcmFsbHkgc3Bl YWtpbmcsIGEgVURQIGNoZWNrc3VtIFNIT1VMRCBiZSB1c2VkLiBUaGUNCj4gPiAgICBjb25zaWRl cmF0aW9ucyBkZXNjcmliZWQgaW4gZGV0YWlsIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0gTVVTVCBi ZQ0KPiA+ICAgIGV4YW1pbmVkIGlmIFVEUCBjaGVja3N1bXMgbmVlZCB0byBiZSBkaXNhYmxlZCBm b3IgcGVyZm9ybWFuY2Ugb3INCj4gPiAgICBpbXBsZW1lbnRhdGlvbiByZWFzb25zIGZvciB0cmFm ZmljIGFjcm9zcyBwcml2YXRlIG5ldHdvcmtzLiBUaGUgdXNlDQo+ID4gICAgb2YgYSB6ZXJvIFVE UCBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQuIg0KPiA+DQo+ID4gaWUgaWYgeW91J3JlIGV2 ZW4gdGhpbmtpbmcgb2YgdHVybmluZyBvZmYgY2hlY2tzdW1zLCBnbyByZWFkIHRob3NlDQo+ID4g UkZDcyBmaXJzdC4NCj4gPg0KPiA+IExsb3lkIFdvb2QNCj4gPiBodHRwOi8vYWJvdXQubWUvbGxv eWR3b29kDQo+IA0KPiBUaGlzIGlzIGZpbmUgd2l0aCBtZSBidXQgWHV4aWFvaHUgaXMgdGhlIGF1 dGhvci4NCj4gDQo+IEkgd291bGQgZ28gYSBsaXR0bGUgZnVydGhlciB3aXRoIHRoZSB3b3JkaW5n Og0KPiANCj4gICBFeGNlcHQgaW4gZXh0cm9pZGluYXJ5IGNhc2VzLCBVRFAgY2hlY2tzdW0gU0hP VUxEIGJlIHVzZWQuIFRoZQ0KPiAgIGNvbnNpZGVyYXRpb25zIGRlc2NyaWJlZCBpbiBkZXRhaWwg aW4gW1JGQzY5MzVdIFtSRkM2OTM2XSBNVVNUIGJlDQo+ICAgZXhhbWluZWQgaWYgVURQIGNoZWNr c3VtcyBuZWVkIHRvIGJlIGRpc2FibGVkIGZvciBwZXJmb3JtYW5jZSBvcg0KPiAgIGltcGxlbWVu dGF0aW9uIHJlYXNvbnMuICBVRFAgY2hlY2tzdW0gc2hvdWxkIG9ubHkgYmUgZGlzYWJsZWQgb24N Cj4gICBwcml2YXRlIG5ldHdvcmtzIG9yIHdoZXJlIE1QTFMgaW4gVURQIGVuY2Fwc3VhbGF0aW9u IGlzIGFkZGVkIGJ5IGENCj4gICBzZXJ2aWNlIHByb3ZpZGVyIHdpdGggTVBMUyBpbiBVRFAgdHJh ZmZpYyBlbnRpcmVseSBjb25maW5lZCB0byB0aGUNCj4gICBuZXR3b3JrIG9mIHRoYXQgc2Vydmlj ZSBwcm92aWRlciBvciBjb29wZXJhdGluZyBzZXJ2aWNlIHByb3ZpZGVycw0KPiAgIHdpdGggZXhw bGljaXQgcGVybWlzc2lvbi4NCj4gDQo+ICAgV2hlcmUgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHVz ZSBmdWxsIFVEUCBjaGVja3N1bSwgYW5kIGlmIHVzaW5nDQo+ICAgVURQLUxpdGUgW1JGQzM4Mjhd IGlzIGZlYXNpYmxlLCBVRFAtTGl0ZSBTSE9VTEQgYmUgdXNlZCByYXRoZXIgdGhhbg0KPiAgIFVE UCB3aXRoIGRpc2FibGVkIGNoZWNrc3Vtcy4NCj4gDQo+IElzIHRoaXMgYmV0dGVyPw0KPiANCj4g WHV4aWFvaHUgLSBpcyB0aGlzIE9LIHdpdGggeW91Pw0KDQpIaSBDdXJ0aXMsDQoNCk1vc3Qgb2Yg dGhlIGFib3ZlIHRleHQgbG9va3MgZmluZSB0byBtZS4gSG93ZXZlciwgSSBqdXN0IHdvbmRlciB3 aGV0aGVyIGl0IGlzIGZlYXNpYmxlIHRvIHVzZSBVRFAtbGl0ZSB0dW5uZWwgZm9yIGltcHJvdmlu ZyBsb2FkLWJhbGFuY2luZyBpbiBwcmFjdGljZS4gDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K DQo+IEN1cnRpcw0KPiANCj4gDQo+ID4gRnJvbTogV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcp DQo+ID4gU2VudDogMjQgSmFudWFyeSAyMDE0IDA1OjAwDQo+ID4gVG86IFh1eGlhb2h1OyBjdXJ0 aXNAaXB2Ni5vY2NuYy5jb20NCj4gPiBDYzogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b207IGxhcnNAbmV0YXBwLmNvbTsNCj4gPiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3Jn DQo+ID4gU3ViamVjdDogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4t dWRwLTA0LnR4dD4NCj4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQg U3RhbmRhcmQNCj4gPg0KPiA+IEkgd291bGQgYmUgZ29vZCB3aXRoOg0KPiA+DQo+ID4gIkdlbmVy YWxseSBzcGVha2luZywgYSBVRFAgY2hlY2tzdW0gU0hPVUxEIGJlIHVzZWQuIFRoZSBjb25zaWRl cmF0aW9ucw0KPiBkZXNjcmliZWQgaW4gW1JGQzY5MzVdIFtSRkM2OTM2XSBTSE9VTEQgYmUgZXhh bWluZWQgaWYgVURQIGNoZWNrc3Vtcw0KPiBuZWVkIHRvIGJlIGRpc2FibGVkIGZvciBwZXJmb3Jt YW5jZSBvciBpbXBsZW1lbnRhdGlvbiByZWFzb25zIGZvciB0cmFmZmljDQo+IGFjcm9zcyBwcml2 YXRlIG5ldHdvcmtzLiBUaGUgdXNlIG9mIGEgemVybyBVRFAgY2hlY2tzdW0gaXMgTk9UDQo+IFJF Q09NTUVOREVELiINCj4gPg0KPiA+IEkgd291bGRuJ3QgbWFrZSB0aGlzIElQdjYgc3BlY2lmaWMg LSBJUHY0IHN0aWxsIGhhcyBwcm9ibGVtcyAoVURQIHBvcnQgZGVtdXgpLA0KPiBJUHY2J3MgcHJv YmxlbXMgYXJlIGp1c3Qgd29yc2UuDQo+ID4NCj4gPiBMbG95ZCBXb29kDQo+ID4gaHR0cDovL2Fi b3V0Lm1lL2xsb3lkd29vZA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBGcm9tOiBYdXhpYW9odSBbeHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPiBTZW50 OiAyNCBKYW51YXJ5IDIwMTQgMDQ6MDANCj4gPiBUbzogY3VydGlzQGlwdjYub2NjbmMuY29tOyBX b29kIEwgIERyIChFbGVjdHJvbmljIEVuZykNCj4gPiBDYzogQWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb207IGxhcnNAbmV0YXBwLmNvbTsNCj4gPiBqb2VsamFAYm9ndXMuY29tOyBtcGxz QGlldGYub3JnDQo+ID4gU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRm LW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8g UHJvcG9zZWQgU3RhbmRhcmQNCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gUGxlYXNlIGNoZWNrIHdo ZXRoZXIgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIE9LLg0KPiA+DQo+ID4gSW4gdGhlIElQdjYgVURQ IGVuY2Fwc3VsYXRpb24gY2FzZSwgYXMgZm9yIHdoZXRoZXIgb3Igbm90IGl0IGlzIHN1aXRhYmxl IHRvIHVzZQ0KPiB0aGUgemVyby1jaGVja3N1bSBub2RlLCB0aGUgcmVxdWlyZW1lbnRzIGRlZmlu ZWQgaW4gW1JGQzY5MzVdIFtSRkM2OTM2XQ0KPiBTSE9VTEQgYmUgc3RyaWN0bHkgZm9sbG93ZWQu IEdlbmVyYWxseSBzcGVha2luZywgdGhlIHVzZSBvZiBhIHplcm8gVURQDQo+IGNoZWNrc3VtIGlz IE5PVCBSRUNPTU1FTkRFRC4gTm90ZSB0aGF0IG90aGVyIElQIGVuY2Fwc3VsYXRpb25zIGZvciBN UExTDQo+IGRvIG5vdCBoYXZlIGEgY2hlY2tzdW0gaW4gdGhlIHR1bm5lbCBoZWFkZXIuDQo+ID4N Cj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPiA+IC0tLS0t08q8/tStvP4t LS0tLQ0KPiA+ID4gt6K8/sjLOiBDdXJ0aXMgVmlsbGFtaXphciBbbWFpbHRvOmN1cnRpc0BpcHY2 Lm9jY25jLmNvbV0NCj4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyNMjVIDExOjUzDQo+ID4gPiDK 1bz+yMs6IGwud29vZEBzdXJyZXkuYWMudWsNCj4gPiA+ILOty806IFh1eGlhb2h1OyBBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgbGFyc0BuZXRhcHAuY29tOw0KPiA+ID4gam9lbGph QGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4g1vfM4jogUmU6IFttcGxzXSBMYXN0IENh bGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+IChFbmNhcHN1bGF0aW5n IE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBJ biBtZXNzYWdlDQo+ID4gPg0KPiA8MjkwRTIwQjQ1NUM2Njc0M0JFMTc4QzVDODRGMTI0MDg0N0U2 MzM0NkUzQEVYTUIwMUNNUy5zdXJyZXkuYQ0KPiA+ID4gYy51az4NCj4gPiA+IGwud29vZEBzdXJy ZXkuYWMudWsgd3JpdGVzOg0KPiA+ID4NCj4gPiA+ID4gdGhlIHRleHQgaXMgbm90IHNhdGlzZmFj dG9yeS4gbmV2ZXIgcmVjb21tZW5kIHNldHRpbmcgdG8gemVybywgYXMNCj4gPiA+ID4gdGhhdCBw b3NlcyBhIHJpc2sgdG8geW91ciBhbmQgdG8gb3RoZXIgdHJhZmZpYy4gU3VnZ2VzdGVkIHRleHQ6 DQo+ID4gPiA+ICoqKg0KPiA+ID4gPiBUaGUgVURQIGNoZWNrc3VtIFNIT1VMRCBiZSB1c2VkIHRv IHByb3RlY3QgdGhlIHBheWxvYWQgYW5kIGVuc3VyZQ0KPiA+ID4gPiBjb3JyZWN0IGRlbXVsdGlw bGV4aW5nIGFuZCBkZWxpdmVyeSB0byB0aGUgdHVubmVsLCBhbmQgbm90IHRvDQo+ID4gPiA+IG90 aGVyIFVEUCBkZXN0aW5hdGlvbnMsIGJ5IHByb3RlY3RpbmcgdGhlIFVEUCBwc2V1ZG9oZWFkZXIu DQo+ID4gPiA+IFVzZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzIE5PVCBSRUNPTU1FTkRFRCwg ZXZlbiB3aGVuIGRlc2lyZWQNCj4gPiA+ID4gZm9yIHBlcmZvcm1hbmNlIG9yIG5lY2Vzc2l0YXRl ZCBieSBpbXBsZW1lbnRhdGlvbiByZWFzb25zLCBmb3IgdGhlDQo+ID4gPiA+IHJlYXNvbnMgb3V0 bGluZWQgaW4gW1JGQzY5MzZdIHNlY3Rpb24gMy4NCj4gPiA+DQo+ID4gPiBJIGFncmVlIHRoYXQg VURQIGNoZWNrc3VtcyBTSE9VTEQgYmUgdXNlZCAoaWU6IFNIT1VMRCBOT1QgYmUgc2V0IHRvDQo+ IHplcm8pLg0KPiA+ID4gVGhlcmUgYXJlIGNhc2VzIHdoZXJlIGl0IGlzIGltcG9zc2libGUgc28g aXQgY2FuJ3QgYmUgTVVTVC4NCj4gPiA+DQo+ID4gPiA+IFVEUC1MaXRlIFtSRkMzODI4XSBjYW4g cHJvdmlkZSBhIGRlbXVsdGlwbGV4aW5nIGNoZWNrIGFuZCBNUExTDQo+ID4gPiA+IHN0YWNrIGlu dGVncml0eSBjaGVjayB3aGlsZSBhdm9pZGluZyB0aGUgb3ZlcmhlYWQgb2YgY29tcHV0aW5nIGFu DQo+ID4gPiA+IGludGVncml0eSBjaGVjayBvdmVyIGEgdHVubmVsbGVkIGZyYW1lIHRoYXQgaGFz IGl0cyBvd24gaW50ZWdyaXR5IGNoZWNrLg0KPiA+ID4NCj4gPiA+IFVEUC1MaXN0IGRvZXNuJ3Qg c29sdmUgdGhlIEVDTVAgcHJvYmxlbXMgYmVjYXVzZSBtb3N0IG9mIHRoZSBvbGRlcg0KPiA+ID4g TFNSIHRoYXQgYXJlIGZvcmNpbmcgdGhlIHVzZSBvZiBNUExTIG92ZXIgVURQIHRvIGdldCBFQ01Q IGRvbid0IGxvb2sNCj4gPiA+IGF0IHRoZSBwb3J0IG51bWJlcnMgaWYgdGhlIHByb3RvY29sIGlz IG5vdCA2IG9yIDE3LiAgQnV0IHRoaXMgaGFzDQo+ID4gPiBvbmx5IGJlZW4gc2FpZCB0aHJlZSBv ciBmb3VyIHRpbWVzIHNvIG1heWJlIHlvdSBtaXNzZWQgaXQuDQo+ID4gPg0KPiA+ID4gPiAqKioN Cj4gPiA+ID4NCj4gPiA+ID4gTGxveWQgV29vZA0KPiA+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxv eWR3b29kDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+ID4gRnJvbTogWHV4aWFvaHUgW3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiA+IFNl bnQ6IDIzIEphbnVhcnkgMjAxNCAxMjozNQ0KPiA+ID4gPiBUbzogV29vZCBMICBEciAoRWxlY3Ry b25pYyBFbmcpOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsNCj4gPiA+ID4gbGFy c0BuZXRhcHAuY29tDQo+ID4gPiA+IENjOiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3Jn DQo+ID4gPiA+IFN1YmplY3Q6IHJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxz LWluLXVkcC0wNC50eHQ+DQo+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQ cm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiA+ID4gPiA+ILeivP7IyzogbC53b29kQHN1cnJleS5hYy51ayBbbWFpbHRvOmwud29vZEBzdXJy ZXkuYWMudWtdDQo+ID4gPiA+ID4gt6LLzcqxvOQ6IDIwMTTE6jHUwjIzyNUgMTI6NDQNCj4gPiA+ ID4gPiDK1bz+yMs6IFh1eGlhb2h1OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsN Cj4gbGFyc0BuZXRhcHAuY29tDQo+ID4gPiA+ID4gs63LzTogam9lbGphQGJvZ3VzLmNvbTsgbXBs c0BpZXRmLm9yZw0KPiA+ID4gPiA+INb3zOI6IFJFOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQt aWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBp biBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBTYXNoYQ0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtIFVEUCBjaGVja3N1bXMgKG9yIGxhY2sgdGhlcmVvZikg aXMgYSBub24taXNzdWUgYmVjYXVzZQ0KPiA+ID4gPiA+ID4gbmF0aXZlIE1QTFMgZG9lcyBub3Qg aGF2ZSBhbnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMsIHRoZXJlDQo+ID4gPiA+ID4gPiBhcmUg Y2FzZXMgd2hlcmUgcGFja2V0cyBhcmUgY29ycnVwdGVkIHdpdGhpbiB0aGUgcm91dGVycykNCj4g PiA+ID4gPg0KPiA+ID4gPiA+IFNvIHlvdSBhZG1pdCB0aGF0IHBhY2tldHMgY2FuIGJlIGNvcnJ1 cHRlZCB3aXRoaW4gdGhlIHJvdXRlcnMgLQ0KPiA+ID4gPiA+IGEgY2hlY2sgdGhhdCBjYW4gb25s eSBiZSBjYXVnaHQgYnkgYW4gZW5kLXRvLWVuZCBjaGVjaywgYQ0KPiA+ID4gPiA+IGNvcnJ1cHRp b24gdGhhdCBjYW4gbGVhZCB0byB0aGUgcHJvYmxlbXMgZGV0YWlsZWQgaW4gUkZDIDY5MzYNCj4g PiA+ID4gPiBzZWN0aW9uIDMgLSBhbmQgdGhlbiB5b3Ugc2F5IGl0J3MgYSBub24taXNzdWUgYmVj YXVzZSB0aGlzDQo+ID4gPiA+ID4gZG9lc24ndCBhZmZlY3QgbmF0aXZlIE1QTFMuIEJ1dA0KPiA+ ID4gd2UncmUgbm90IGRvaW5nIG5hdGl2ZSBNUExTIGhlcmUuDQo+ID4gPiA+ID4gV2UncmUgZG9p bmcgTVBMUyBvdmVyIFVEUC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IGRyYWZ0LWlldGYtbXBscy1p bi11ZHAtMDQudHh0IGlzIGFib3V0IHR1bm5lbGxpbmcgTVBMUyBpbiBVRFAuIEl0J3MgYW4NCj4g aXNzdWUuDQo+ID4gPiA+ID4gUGxlYXNlIHJlYWQgdGhlIG90aGVyIDE1MCBtZXNzYWdlcyB0aGF0 IHlvdSByZWZlciB0by4NCj4gPiA+ID4NCj4gPiA+ID4gSGkgTGxveWQsDQo+ID4gPiA+DQo+ID4g PiA+IFRoZSBkcmFmdCBkb2Vzbid0IHJlcXVpcmUgdGhlIElQdjYgVURQIGNoZWNrc3VtIHRvIGJl IHNldCB0byB6ZXJvDQo+IHJlZ2FyZGxlc3MuDQo+ID4gPiBTZWUgdGhlIGZvbGxvd2luZyB0ZXh0 IHF1b3RlZCBmcm9tIHRoYXQgZHJhZnQ6DQo+ID4gPiA+DQo+ID4gPiA+IFVEUCBDaGVja3N1bQ0K PiA+ID4gPg0KPiA+ID4gPiBUaGUgdXNhZ2Ugb2YgdGhpcyBmaWVsZCBpcyBpbiBhY2NvcmRhbmNl IHdpdGggdGhlIGN1cnJlbnQgVURQDQo+ID4gPiA+IHNwZWNpZmljYXRpb24NCj4gPiA+IFtSRkM3 NjhdLiBUbyBzaW1wbGlmeSB0aGUgb3BlcmF0aW9uIG9uIHRoZSBkZWNhcHN1bGF0b3IsIHRoaXMg ZmllbGQNCj4gPiA+IGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGluIElQdjQgVURQ IGVuY2Fwc3VsYXRpb24gY2FzZS4gSW4NCj4gPiA+IHRoZSBJUHY2IFVEUCBlbmNhcHN1bGF0aW9u IGNhc2UsIGlmIGFwcHJvcHJpYXRlIGFjY29yZGluZyB0byB0aGUNCj4gPiA+IHJlcXVpcmVtZW50 cyBkZWZpbmVkIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0sIHRoaXMgZmllbGQgaXMgYWxzbw0KPiBS RUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVyby4NCj4gPiA+IFNwZWNpZmljYWxseSwgaWYgdGhl IE1QTFMgcGF5bG9hZCBpcyBJbnRlcm5ldCBQcm90b2NvbCAoSVB2NCBvcg0KPiA+ID4gSVB2Nikg cGFja2V0cywgaXQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gd2hlbiB0aGUgaW5u ZXINCj4gPiA+IHBhY2tldCBpbnRlZ3JpdHkgY2hlY2tzIGlzIGF2YWlsYWJsZS4gSW4gYWRkaXRp b24sIGlmIHRoZSBNUExTDQo+ID4gPiBwYXlsb2FkIGlzIG5vbi1JUCBwYWNrZXQgd2hpY2ggaXMg c3BlY2lmaWNhbGx5IGRlc2lnbmVkIGZvcg0KPiA+ID4gdHJhbnNtaXNzaW9uIG92ZXIgYSBsb3dl ciBsYXllciB0aGF0IGRvZXMgbm90IHByb3ZpZGUgYSBwYWNrZXQNCj4gPiA+IGludGVncml0eSBn dWFyYW50ZWUsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGJlIHNldCB0byB6ZXJvIGFzIHdlbGwuDQo+ ID4gPiBPdGhlcndpc2UsIHVzaW5nIHplcm8gY2hlY2tzdW0gaXMgTk9UIFJFQ09NTUVOREVELiBO b3RlIHRoYXQgb3RoZXIgSVANCj4gZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMgZG8gbm90IGhhdmUg YSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCj4gPiA+ID4NCj4gPiA+ID4gSWYgeW91 IHN0aWxsIGJlbGlldmUgdGhlIGFib3ZlIHRleHQgaXMgbm90IHNhdGlzZmFjdG9yeSwgcGxlYXNl IHByb3ZpZGUgeW91cg0KPiB0ZXh0Lg0KPiA+ID4gPg0KPiA+ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ ID4gPiA+IFhpYW9odQ0KPiA+ID4gPg0KPiA+ID4gPiA+IExsb3lkIFdvb2QNCj4gPiA+ID4gPiBo dHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+IEZyb206IG1wbHMgW21wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQo+ID4gPiA+ID4gW3h1eGlhb2h1QGh1YXdl aS5jb21dDQo+ID4gPiA+ID4gU2VudDogMjMgSmFudWFyeSAyMDE0IDAzOjE2DQo+ID4gPiA+ID4g VG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBFZ2dlcnQsIExhcnMNCj4gPiA+ID4gPiBDYzogSm9l bCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBM YXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiAoRW5j YXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4gPg0K PiA+ID4gPiA+IEhpDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiA+ID4gPiA+ID4gt6K8/sjLOiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPiA+ID4gPiA+ID4gW21h aWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCj4gPiA+ID4gPiA+ILeiy83K sbzkOiAyMDE0xOox1MIyMsjVIDE5OjA1DQo+ID4gPiA+ID4gPiDK1bz+yMs6IEVnZ2VydCwgTGFy cw0KPiA+ID4gPiA+ID4gs63LzTogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnOyBYdXhpYW9o dQ0KPiA+ID4gPiA+ID4g1vfM4jogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1w bHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQ KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IExhcnMgYW5k IGFsbCwNCj4gPiA+ID4gPiA+IExhc3QgdGltZSBJJ3ZlIGNvdW50ZWQgdGhlIElFVEYgTEMgdGhy ZWFkIG9uIHRoaXMgZHJhZnQgaGFzDQo+ID4gPiA+ID4gPiBtb3JlIHRoYW4NCj4gPiA+ID4gPiA+ IDE1MCBtZXNzYWdlcyBpbiBpdCwgYW5kIGl0IHNlZW1zIHRoYXQgb24gc29tZSBpc3N1ZXMNCj4g PiA+ID4gPiA+IChjb25nZXN0aW9uIGNvbnRyb2wgYW5kIFVEUA0KPiA+ID4gPiA+ID4gY2hlY2tz dW1zKSB3ZSBhcmUgZ29pbmcgcm91bmQgdGhlIG11bGJlcnJ5IGJ1c2guDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gSU1ITyBhbmQgRldJVzoNCj4gPiA+ID4gPiA+IC0gVURQIGNoZWNrc3VtcyAo b3IgbGFjayB0aGVyZW9mKSBpcyBhIG5vbi1pc3N1ZSBiZWNhdXNlDQo+ID4gPiA+ID4gPiBuYXRp dmUgTVBMUyBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIGxpa2UgdGhhdC4gQW5kIHllcywgdGhlcmUN Cj4gPiA+ID4gPiA+IGFyZSBjYXNlcyB3aGVyZSBwYWNrZXRzIGFyZSBjb3JydXB0ZWQgd2l0aGlu IHRoZSByb3V0ZXJzKSwgYnV0DQo+ID4gPiA+ID4gPiBzbyBmYXIgaXQgZGlkIG5vdCBwcmV2ZW50 IE1QTFMgZGVwbG95bWVudC4gVGhlcmUgaXMsIGUuZy4sIFJGQw0KPiA+ID4gPiA+ID4gNDcyMCBm b3IgRkNTIHJldGVudGlvbiBpbiBQV3MsIGJ1dCBJIGRvdWJ0IGl0IGlzIHdpZGVseQ0KPiA+ID4g PiA+ID4gaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkICh3b3VsZCBiZSBuaWNlIHRvDQo+ID4gPiA+ ID4ga25vdykuDQo+ID4gPiA+ID4gPiAtIEUyRSBjb25nZXN0aW9uIGNvbnRyb2wgKHJlZ2FyZGxl c3Mgb2YgaXRzIGltcGxpY2F0aW9ucykNCj4gPiA+ID4gPiA+IHNpbXBseSBjYW5ub3QgYmUgYWRk ZWQgdG8gdGhpcyBwcm90b2NvbCB3aXRob3V0IHNvbWUgbWFqb3INCj4gPiA+ID4gPiA+IGNoYW5n ZXMuIEEgc2hvcnQgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZXhwbGFpbmluZyB0aGF0IHNob3Vs ZCBzdWZmaWNlDQo+IElNTy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhpIFNhc2hhLA0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gSSBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnRzLg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiBNeSAyYywNCj4gPiA+ID4gPiA+ICAgICAgICBTYXNoYQ0KPiA+ID4gPiA+ID4g RW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+ID4gPiA+ID4gPiBNb2Jp bGU6IDA1NC05MjY2MzAyDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gPiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiA+ID4gPiA+ID4gRWdnZXJ0LCBMYXJzDQo+ ID4gPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMiwgMjAxNCAxMjoyMyBQTQ0K PiA+ID4gPiA+ID4gPiBUbzogWHV4aWFvaHUNCj4gPiA+ID4gPiA+ID4gQ2M6IEpvZWwgSmFlZ2ds aTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3Qg Q2FsbDoNCj4gPiA+ID4gPiA+ID4gPGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDQudHh0PiAoRW5j YXBzdWxhdGluZyBNUExTIGluIFVEUCkNCj4gPiA+ID4gPiA+ID4gdG8gUHJvcG9zZWQgU3RhbmRh cmQNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSGksDQo+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+IE9uIDIwMTQtMS0yMiwgYXQgMTE6MTIsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3 ZWkuY29tPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPiBJIHdvbmRlciB3aGV0aGVyIHRoZSBmb2xs b3dpbmcgdGV4dCBpcyBPSyB0byB5b3U6DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g PiBTaW5jZSB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiBjYXVzZXMgTVBMUyBwYWNrZXRz IHRvDQo+ID4gPiA+ID4gPiA+ID4gYmUNCj4gPiA+ID4gPiA+ID4gZm9yd2FyZGVkIHRocm91Z2gg IlVEUCB0dW5uZWxzIiwgdGhlIGNvbmdlc3Rpb24gY29udHJvbA0KPiA+ID4gPiA+ID4gPiBndWlk ZWxpbmVzIGZvciBVRFAgdHVubmVscyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjMgb2YNCj4g PiA+ID4gPiA+ID4gW1JGQzU0MDVdIFNIT1VMRCBiZQ0KPiA+ID4gPiA+IGZvbGxvd2VkLg0KPiA+ ID4gPiA+ID4gPiBTcGVjaWZpY2FsbHksIE1QTFMgY2FuIGNhcnJ5IGEgbnVtYmVyIG9mIGRpZmZl cmVudCBwcm90b2NvbHMgYXMNCj4gcGF5bG9hZHMuDQo+ID4gPiA+ID4gPiA+IFdoZW4gYW4gVURQ IHR1bm5lbCBpcyB1c2VkIGZvciBNUExTIHBheWxvYWQgdHJhZmZpYyB0aGF0IGlzDQo+ID4gPiA+ ID4gPiA+IGtub3duIGF0IGNvbmZpZ3VyYXRpb24gdGltZSB0byBiZSBJUC1iYXNlZCBhbmQNCj4g PiA+ID4gPiA+ID4gY29uZ2VzdGlvbi1jb250cm9sbGVkLCB0aGUgVURQIHR1bm5lbCBTSE9VTEQg Tk9UIGVtcGxveSBpdHMNCj4gPiA+ID4gPiA+ID4gb3duIGNvbmdlc3Rpb24gY29udHJvbCBtZWNo YW5pc20sIGJlY2F1c2UgY29uZ2VzdGlvbiBsb3NzZXMNCj4gPiA+ID4gPiA+ID4gb2YgdHVubmVs ZWQgdHJhZmZpYyB3aWxsIHRyaWdnZXIgYW4gY29uZ2VzdGlvbiByZXNwb25zZSBhdA0KPiA+ID4g PiA+ID4gPiB0aGUgb3JpZ2luYWwNCj4gPiA+IHNlbmRlcnMgb2YgdGhlIHR1bm5lbGVkIHRyYWZm aWMuDQo+ID4gPiA+ID4gPiA+IFdoZW4gYW4gVURQIHR1bm5lbCBpcyB1c2VkIGZvciBNUExTIHBh eWxvYWQgdHJhZmZpYyB0aGF0IGlzDQo+ID4gPiA+ID4gPiA+IGtub3duIGF0IGNvbmZpZ3VyYXRp b24gdGltZSBub3QgdG8gYmUgSVAtYmFzZWQgYW5kDQo+ID4gPiA+ID4gPiA+IGNvbmdlc3Rpb24t Y29udHJvbGxlZCwgdGhlIFVEUCB0dW5uZWwgU0hPVUxEIGVtcGxveSBhbg0KPiA+ID4gPiA+ID4g PiBhcHByb3ByaWF0ZSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIGFzIGRlc2NyaWJlZCBp bg0KPiA+ID4gPiA+ID4gPiBbUkZDMzk4NV0uIE5vdGUgdGhhdCBpdCBTVFJPTkdMWSBSRUNPTU1F TkRFRCB0byBkZXBsb3kgc3VjaA0KPiA+ID4gPiA+ID4gPiBlbmNhcHN1bGF0aW9uIHRlY2hub2xv Z3kgb25seSB3aXRoaW4gYSBTUCBuZXR3b3JrIG9yDQo+ID4gPiA+ID4gPiA+IG5ldHdvcmtzIG9m IGFuIGFkamFjZW50IHNldCBvZiBjby1vcGVyYXRpbmcgU1BzLCByYXRoZXIgdGhhbg0KPiA+ID4g PiA+ID4gPiBvdmVyIHRoZQ0KPiA+ID4gPiA+IEludGVybmV0Lg0KPiA+ID4gPiA+ID4gPiBGdXJ0 aGVybW9yZSwgcGFja2V0IGZpbHRlcnMgc2hvdWxkIGJlIGFkZGVkIHRvIGJsb2NrIHRyYWZmaWMN Cj4gPiA+ID4gPiA+ID4gd2l0aCB0aGUgVURQIHBvcnQgbnVtYmVyIGZvciBNUExTIG92ZXIgVURQ IHRvIHByZXZlbnQgTVBMUw0KPiA+ID4gPiA+ID4gPiBvdmVyIFVEUCBwYWNrZXRzIHRvIGVzY2Fw ZSBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyDQo+ID4gPiA+ID4gPiA+IG5ldHdvcmtzIGR1ZSB0 byBtaXNjb25maWd1YXRpb24gb3IgcGFja2V0DQo+ID4gPiA+ID4gPiBlcnJvcnMuDQo+ID4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGRlc2Ny aWJlIHRoZSBPQU0gY29udHJvbCBsb29wDQo+ID4gPiA+ID4gPiA+IGluDQo+ID4gPiA+ID4gPiA+ IChzb21lKSBtb3JlIGRldGFpbCwgcmF0aGVyIHRoYW4gcG9pbnRpbmcgdG8gUkZDMzk4NSwgd2hp Y2gNCj4gPiA+ID4gPiA+ID4gZG9lc24ndCBoYXZlIGEgd2hvbGUgbG90IG9mIGRldGFpbCBlaXRo ZXIuIEFsc28gYmVjYXVzZSB0aGUNCj4gPiA+ID4gPiA+ID4gYWRkaW5nIG9mIGZpcmV3YWxsIHJ1 bGVzIHJlcXVpcmVzIGFuIE9BTSBob29rLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBT aW5jZSBTVFJPTkdMWSBSRUNPTU1FTkRFRCBpcyBub3QgYW4gUkZDMjExOSB0ZXJtIGFuZA0KPiA+ ID4gPiA+ID4gUkVDT01NRU5ERUQgaXMNCj4gPiA+ID4gPiA+ID4gdG9vIHdlYWssIEknZCBzdWdn ZXN0IHRvIGNoYW5nZSB0aGlzIHRvIE1VU1QuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ IEZpbmFsbHksIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBzaG91bGQgYmUgcHJvbWluZW50 bHkNCj4gPiA+ID4gPiA+ID4gbWFkZSBpbiB0aGUgYWJzdHJhY3QsIGludHJvZHVjdGlvbiwgZXRj Lg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBMYXJzDQoNCg== From ryoo@etri.re.kr Sun Jan 26 00:39:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AD11A0115 for ; Sun, 26 Jan 2014 00:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.454 X-Spam-Level: X-Spam-Status: No, score=-101.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 isTiANf7yPIL for ; Sun, 26 Jan 2014 00:39:16 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id B4CB51A0114 for ; Sun, 26 Jan 2014 00:39:14 -0800 (PST) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 26 Jan 2014 17:39:08 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Sun, 26 Jan 2014 17:39:08 +0900 From: "Ryoo, Jeong-dong" To: "adrian@olddog.co.uk" , 'Loa Andersson' , "mpls@ietf.org" Thread-Topic: [mpls] AD review : working group last call draft-ietf-mpls-tp-psc-itu-01 Thread-Index: Ac8W6jHMZ8uZf2LMS56KIUdobofaHQDhoS5g Date: Sun, 26 Jan 2014 08:39:06 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846@SMTP2.etri.info> References: <0bc301cf16ea$3981cd00$ac856700$@olddog.co.uk> In-Reply-To: <0bc301cf16ea$3981cd00$ac856700$@olddog.co.uk> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] AD review : working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 08:39:26 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRyaWFuIGFuZCBhbGwsDQoNCk1hbnkgdGhhbmtzIHRvIEFkcmlhbiBmb3IgaGlzIHRob3JvdWdo IGFuZCB2YWx1YWJsZSByZXZpZXcuDQpJbiBteSBvcGluaW9uLCBhbGwgdGhlIHdvcmRpbmcgZnJv bSBBRCByZXZpZXcgc2hvdWxkIGJlIHRha2VuIGV4Y2VwdCB0aGUgZm9sbG93aW5ncyB0aGF0IEkg d291bGQgbmVlZCBmdXJ0aGVyIGNsYXJpZmljYXRpb25zIG9yIGNvbmZpcm1hdGlvbnMgZnJvbSBB RDoNCi0tLQ0KQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbg0KRHVlIHRvIHRoZSBsaW1pdGF0aW9u IGluIHRoZSBsZW5ndGggb2YgQWJzdHJhY3QgYW5kIHRoZSBuYXR1cmUgb2YgdGhlIGFic3RyYWN0 LCB3aGljaCBnaXZlcyB0aGUgbWFpbiBwb2ludHMgb2YgKnRoaXMqIGRvY3VtZW50LCBJIHdvdWxk IGxpa2UgdG8gc2VlIGlmIHdlIGNhbiBhZGQgdGhlIHNlbnRlbmNlIGluIHRoZSBJbnRyb2R1Y3Rp b24gc2VjdGlvbiBvbmx5Lg0KLS0tDQpTZWN0aW9uIDQuMQ0KVGhlIHNlY29uZCBwYXJhZ3JhcGgg aW4gU2VjdGlvbiA0LjEgaXMgdG8gZW1waGFzaXMgdGhlIGltcG9ydGFuY2Ugb2YgdGhlIFBTQyBj b21tdW5pY2F0aW9uIGNoYW5uZWwgaW4gZGVsaXZlcmluZyB0aGUgZXh0ZXJuYWwgc3dpdGNoIGNv bW1hbmQsIHNvIHRoYXQgdGhlIGZhaWx1cmUgb2YgUFNDIGNvbW11bmljYXRpb24gY2hhbm5lbCBo YXMgaGlnaGVyIHByaW9yaXR5IHRoYW4gRlMuDQpJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0byBj aGFuZ2UgdGhlIHBhcmFncmFwaCBhcyBmb2xsb3dzOg0KPT09IE9MRCA9PT0NCkFjY29yZGluZyB0 byBTZWN0aW9uIDIuNCBvZiBSRkMgNTY1NCBbUkZDNTY1NF0gaXQgTVVTVCBiZSBwb3NzaWJsZSB0 bw0Kb3BlcmF0ZSBhbiBNUExTLVRQIG5ldHdvcmsgd2l0aG91dCB1c2luZyBhIGNvbnRyb2wgcGxh bmUuICBUaGlzIG1lYW5zDQp0aGF0IGV4dGVybmFsIHN3aXRjaCBjb21tYW5kcywgZS5nLiwgRlMs IGNhbiBiZSB0cmFuc2ZlcnJlZCB0byB0aGUNCnJlbW90ZSBMYWJlbCBFZGdlIFJvdXRlciAoTEVS KSBvbmx5IGJ5IHVzaW5nIHRoZSBQU0MgY29tbXVuaWNhdGlvbg0KY2hhbm5lbCBhbmQgc2hvdWxk IG5vdCByZWx5IG9uIHRoZSBwcmVzZW5jZSBvZiBhIGNvbnRyb2wgcGxhbmUuDQo9PT0gTkVXID09 PQ0KQWNjb3JkaW5nIHRvIFNlY3Rpb24gMi40IG9mIFJGQyA1NjU0IFtSRkM1NjU0XSBpdCBNVVNU IGJlIHBvc3NpYmxlIHRvDQpvcGVyYXRlIGFuIE1QTFMtVFAgbmV0d29yayB3aXRob3V0IHVzaW5n IGEgY29udHJvbCBwbGFuZS4gVGhpcyBtZWFucw0KdGhhdCB0aGUgUFNDIGNvbW11bmljYXRpb24g Y2hhbm5lbCBpcyB2ZXJ5IGltcG9ydGFudCBmb3IgdGhlIHRyYW5zZmVyDQpvZiBleHRlcm5hbCBz d2l0Y2ggY29tbWFuZHMgKGUuZy4sIEZTKSwgYW5kIHRoZXNlIGNvbW1hbmRzIHNob3VsZCBub3QN CnJlbHkgb24gdGhlIHByZXNlbmNlIG9mIGEgY29udHJvbCBwbGFuZS4gSW4gY29uc2VxdWVuY2Us IHRoZSBmYWlsdXJlDQpvZiB0aGUgUFNDIGNvbW11bmljYXRpb24gY2hhbm5lbCBoYXMgaGlnaGVy IHByaW9yaXR5IHRoYW4gRlMuDQotLS0NClNlY3Rpb24gNC4zDQpZb3Ugc3VnZ2VzdGVkIOKAnHMv YnJva2VuLCB0aGUgRnJlZXplIGNvbW1hbmQsL2Jyb2tlbi4gVGhlIEZyZWV6ZSBjb21tYW5kLC/i gJ0uDQpCdXQsIG15IHJlYWRpbmcgb2YgdHdvIHNlcGFyYXRlIHNlbnRlbmNlcyBpcyBub3Qgb2su IFRoZSBmaXJzdCBzZW50ZW5jZSBkb2VzbuKAmXQgc2VlbSB0byBiZSBjb21wbGV0ZS4gV291bGQg eW91IHBsZWFzZSBjaGVjayB0aGlzIGFnYWluPw0KDQotLS0NClNlY3Rpb25zIDkuMS4xLCBTZWN0 aW9uIDkuMS4yLCBTZWN0aW9uIDkuMS4zLjIgYW5kIFNlY3Rpb24gOS4xLjMuMw0KRm9yIHRob3Nl IGZvdXIgY29tbWVudHMgb24gU2VjdGlvbiA5LCBJIGNhbiB1bmRlcnN0YW5kIHRoZSBjb25jZXJu cy4gSW4gbXkgb3BpbmlvbiwgdGhlIHF1ZXN0aW9ucyBnaXZlbiBpbiB0aGUgQUQgcmV2aWV3IGNv bW1lbnRzIGFyZSB2ZXJ5IHZhbGlkIGFuZCBzaG91bGQgYmUgYW5zd2VyZWQuIEkgdGhpbmsgdGhl IHRleHQgbmVlZHMgdG8gYmUgY2hhbmdlZCByYXRoZXIgc2lnbmlmaWNhbnRseS4gSSB3aWxsIHBy ZXBhcmUgYSBuZXcgdGV4dCBwcm9wb3NhbCBhbmQgZnVydGhlciBjb21tdW5pY2F0ZSB3aXRoIEFk cmlhbi4NCi0tLQ0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tIDogIkFkcmlhbiBGYXJyZWwiIDxh ZHJpYW5Ab2xkZG9nLmNvLnVrPg0KU2VudCA6IDIwMTQtMDEtMjIgMDU6NDk6MjEgKCArMDk6MDAg KQ0KVG8gOiAnTG9hIEFuZGVyc3NvbicgPGxvYUBwaS5udT4sIG1wbHNAaWV0Zi5vcmcgPG1wbHNA aWV0Zi5vcmc+DQpDYyA6IG1wbHMtYWRzQHRvb2xzLmlldGYub3JnIDxtcGxzLWFkc0B0b29scy5p ZXRmLm9yZz4sIG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIDxtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZz4sIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnIDxkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz4NClN1YmplY3QgOiBbbXBsc10g QUQgcmV2aWV3IDogd29ya2luZyBncm91cCBsYXN0IGNhbGwgZHJhZnQtaWV0Zi1tcGxzLXRwLXBz Yy1pdHUtMDENCg0KSGksDQoNCkNvbmdyYXR1bGF0aW9ucyBvbiBzYWlsaW5nIGEgdmVyeSBkaWZm aWN1bHQgY291cnNlIGJldHdlZW4gdGVjaG5pY2FsIGFuZA0KcG9saXRpY2FsLiBZb3UgaGF2ZSBw cm9kdWNlZCBhIHJlYWRhYmxlIGFuZCBjb2hlcmVudCBkb2N1bWVudC4NCg0KSSBoYXZlIGNvbmR1 Y3RlZCBteSB1c3VhbCBBRCByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCBlYXJseSAoaS5lLiwgZHVy aW5nDQp3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCkgb24gcmVxdWVzdCBvZiB0aGUgd29ya2luZyBn cm91cCBjaGFpcnMuIFRoZQ0KcHVycG9zZSBvZiBteSByZXZpZXcgaXMgdG8gY2F0Y2ggYW5kIGNs ZWFuIHVwIGFueSBpc3N1ZXMgdGhhdCBtaWdodA0Kb3RoZXJ3aXNlIGJlIGZvdW5kIGR1cmluZyBJ RVRGIGxhc3QgY2FsbCBhbmQgSUVTRyBldmFsdWF0aW9uLiBUaHVzLCB0aGUNCmludGVudGlvbiBp cyB0byBwcm9kdWNlIGEgaGlnaGVyIHF1YWxpdHkgZG9jdW1lbnQgYW5kIGVuc3VyZSBzbW9vdGhl cg0KcGFzc2FnZSB0aHJvdWdoIHRob3NlIGxhdGVyIHN0YWdlcy4gQXMgc2hvdWxkIGJlIG9idmlv dXMsIGJ5IHJldmlld2luZw0KdGhlIGRvY3VtZW50IGJlZm9yZSBpdCBoYXMgc2VlbiB3b3JraW5n IGdyb3VwIGxhc3QgY2FsbCBhbmQgYmVlbiB1cGRhdGVkDQpJIG1heSBoYXZlIGZvdW5kIG1vcmUg aXNzdWVzIGFuZCBjb25jZXJucyB0aGFuIEkgd291bGQgaGF2ZSBkb25lIGhhZCBJDQpyZXZpZXdl ZCBpdCBsYXRlci4NCg0KTmV2ZXJ0aGVsZXNzLCBJIGZpbmQgdGhlIGRvY3VtZW50IHRvIGJlIGJh c2ljYWxseSBzb3VuZC4gVGhlcmUgYXJlIHF1aXRlDQphIGxvdCBvZiBjb21tZW50cyBiZWxvdywg YnV0IHRoZXkgYXJlIGFsbW9zdCBleGNsdXNpdmVseSBlZGl0b3JpYWwgaW4NCm5hdHVyZS4gVGhl IGVkaXRvcmlhbCBjb21tZW50cyBmYWxsIGludG8gdGhyZWUgY2F0ZWdvcmllczoNCg0KLSBwdXJl IG5pdHMgKHNob3VsZCBiZSBlbnRpcmVseSB1bmNvbnRlbnRpb3VzKQ0KLSBpc3N1ZXMgb2YgY2xh cml0eSBhbmQgcmVhZGFiaWxpdHkgKGhvcGVmdWxseSB0aGVzZSBhcmUgYWxzbyBlYXN5IHRvDQph Y2NlcHQsIGJ1dCBwbGVhc2UgY2hlY2sgdGhhdCBteSAiY2xlYW5pbmcgdXAiIG9mIHlvdXIgdGV4 dCBoYXMNCnByZXNlcnZlZCB0aGUgbWVhbmluZyB5b3UgaW50ZW5kZWQpDQotIGlzc3VlcyBvZiBz cGluL3BvbGl0aWNzIChzb21ldGltZXMgc2F5aW5nIHRoZSBzYW1lIHRoaW5nIGluIHNsaWdodGx5 DQpkaWZmZXJlbnQgd29yZHMgY2FuIG1ha2UgZXZlcnlvbmUgaGFwcHkpDQoNCkkgdGhpbmsgSSBm b3VuZCBvbmx5IHR3byB0ZWNobmljYWwgaXNzdWVzIC0gaW4gU2VjdGlvbiA5LjEuMSBhbmQNCjku MS4zLjMuDQoNCkluIGFsbCBjYXNlcyBJIGhhdmUgdHJpZWQgdG8gc3VnZ2VzdCBhbHRlcm5hdGl2 ZSB3b3JkaW5nIHNvIHRoYXQgeW91DQpkb24ndCBoYXZlIHRvIGd1ZXNzIHdoYXQgSSBtZWFuLiBC dXQgcGxlYXNlIChwbGVhc2UsIHBsZWFzZSkgZG8gbm90DQpmZWVsIHRoYXQgSSBhbSBpbnNpc3Rp bmcgb24gYW55IG9mIHRoZXNlIGNoYW5nZXMgb3Igb24gbXkgcHJlY2lzZSB3b3JkczoNCkkgYW0g anVzdCB0cnlpbmcgdG8gcG9saXNoIGFuZCBtb3ZlIHRoaXMgZG9jdW1lbnQgYWxvbmc7IGV2ZXJ5 dGhpbmcgaXMNCm9wZW4gZm9yIGRpc2N1c3Npb24uDQoNCk9uZSBsYXN0IHBvaW50OiBpZiBzb21l IGVudGh1c2lhc3RpYyBuYXRpdmUgc3BlYWtlciB3YXMgdG8gcmV2aWV3IGFuZA0KZWRpdCB0aGUg ZmluYWwgcmV2aXNpb24gKHBlcmhhcHMgaW4gcmV0dXJuIGZvciBiZWVyIG9yIGFuDQphY2tub3ds ZWRnZW1lbnQpIHRoZXkgd291bGQgYmUgZG9pbmcgdXMgYWxsIGEgZ3JlYXQgZmF2b3IuIEkgaGF2 ZSBub3QNCnBvaW50ZWQgb3V0IGV2ZXJ5IG1pbm9yIGlzc3VlIG9mIGxhbmd1YWdlIGluIG15IHJl dmlldy4NCg0KVGhhbmtzIGZvciB0aGUgd29yay4NCg0KQWRyaWFuDQoNCj09PQ0KDQpUaGUgQWJz dHJhY3QgYW5kIHRoZSBJbnRyb2R1Y3Rpb24gc2F5Og0KDQpUd28gbW9kZXMgYXJlIGRlZmluZWQg aW4NCnRoaXMgZG9jdW1lbnQ6IFByb3RlY3Rpb24gU3RhdGUgQ29vcmRpbmF0aW9uIChQU0MpIG1v ZGUgYW5kIEF1dG9tYXRpYw0KUHJvdGVjdGlvbiBTd2l0Y2hpbmcgKEFQUykgbW9kZS4NCg0KVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGJlaGF2aW9yIG9mIHRoZSBQU0MgcHJvdG9jb2wgaW5j bHVkaW5nDQpwcmlvcml0eSBsb2dpYyBhbmQgc3RhdGUgbWFjaGluZSB3aGVuIGFsbCB0aGUgY2Fw YWJpbGl0aWVzIGFzc29jaWF0ZWQNCndpdGggdGhlIEFQUyBtb2RlIGFyZSBlbmFibGVkLg0KDQpU aGlzIGxlYXZlcyB0aGUgcXVlc3Rpb246IHdoZXJlIGlzIHRoZSBwcm90b2NvbCBpbmNsdWRpbmcg cHJpb3JpdHkgbG9naWMNCmFuZCBzdGF0ZSBtYWNoaW5lIGRlZmluZWQgZm9yIHRoZSBQU0MgbW9k ZT8gSSBob3BlIHRoZSBhbnN3ZXIgaXMgImluDQpSRkMgNjM3OCwgaW4gd2hpY2ggY2FzZSB5b3Ug Y2FuIGVhc2lseSBhZGQgYSBub2RlIHN1Y2ggYXM6DQoNClRoZSBQU0MgcHJvdG9jb2wgYmVoYXZp b3IgZm9yIHRoZSBQU0MgbW9kZSBpcyBhcyBkZWZpbmVkIGluIFJGQyA2Mzc4Lg0KDQotLS0NCg0K VGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoZSBJbnRyb2R1Y3Rpb24gcmVhZHMNCg0KVGhpcyBkb2N1 bWVudCB1cGRhdGVzIFJGQyA2Mzc4IGluIHRoYXQgdGhlIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVu dA0KbWV0aG9kIGRlZmluZWQgaGVyZSBpcyBhbiBhZGRpdGlvbiB0byB0aGF0IGRvY3VtZW50LiBG b3IgYW4gZXhpc3RpbmcNCmltcGxlbWVudGF0aW9uIG9mIFJGQyA2Mzc4LCBpdCBpcyByZWNvbW1l bmRlZCB0byBiZSB1cGRhdGVkIHdpdGggdGhlDQpidWctZml4ZXMgaW4gW0ktRC5pZXRmLW1wbHMt cHNjLXVwZGF0ZXNdIGFuZCB0aGUgY2FwYWJpbGl0eQ0KYWR2ZXJ0aXNlbWVudCBpbiB0aGlzIGRv Y3VtZW50Lg0KDQpJIHN1Z2dlc3QgcmVwbGFjaW5nIHRoaXMgd2l0aCB0aGUgdGV4dCBiZWxvdy4g VGhlcmUgYXJlIHR3byByZWFzb25zIGZvcg0KbXkgc3VnZ2VzdGVkIGNoYW5nZXM6DQoNCjEuIEl0 IGxvb2tzIHZlcnkgb2RkIGZvciB0aGlzIGRvY3VtZW50IHRvIHJlY29tbWVuZCB1c2luZyBjaGFu Z2VzIGluDQphbm90aGVyIGRvY3VtZW50LiBUaGUgcmVzdWx0IG9mIHN1Y2ggYSBzdGF0ZW1lbnQg aXMgbGlrZWx5IHRvIGJlIGENCnJlcXVpcmVtZW50IHRoYXQgeW91IGJ1bmRsZSB0aGUgdHdvIGRv Y3VtZW50cyB0b2dldGhlci4gSSB0aGluayB0aGF0DQpbSS1ELmlldGYtbXBscy1wc2MtdXBkYXRl c10gY2FuIHN0YW5kIG9uIGl0cyBvd24uDQoNCjIuIFdoaWxlIHlvdSBjYW4gcmVjb21tZW5kIHRo YXQgdGhlIGluc3RhbGxlZCBiYXNlIGlzIHVwZGF0ZWQsIHlvdQ0KY2Fubm90IGZvcmNlIGl0IHRv IGhhcHBlbi4gSXQgaXMsIHRoZXJlZm9yZSwgdXNlZnVsIHRvIGRyYXcgYXR0ZW50aW9uDQp0byB0 aGUgaW1wb3J0YW50IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgdGV4dCB5b3UgaGF2ZSBpbiBTZWN0 aW9uIDkuMy4NCg0KU28gbXkgc3VnZ2VzdGVkIHRleHQgaXM6DQoNClRoaXMgZG9jdW1lbnQgdXBk YXRlcyBSRkMgNjM3OCBieSBhZGRpbmcgYSBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQNCm1lY2hh bmlzbS4gSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2Yg UkZDDQo2Mzc4IHNob3VsZCBiZSB1cGRhdGVkIHRvIHN1cHBvcnQgdGhpcyBjYXBhYmlsaXR5LCBo b3dldmVyIHRoZSBpc3N1ZQ0Kb2YgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBpcyBkZXNjcmliZWQNCmluIFNlY3Rpb24gOS4zLg0KDQotLS0NCg0K U2VjdGlvbiA0DQoNCkluIHRoaXMgZG9jdW1lbnQsIHRoZSBwcmlvcml0aWVzIG9mIEZTIGFuZCBT Ri1QIGFyZSBzd2FwcGVkIGFuZCB0aGUNCnByaW9yaXR5IG9mIENsZWFyIFNGIChTRmMpIGlzIHJh aXNlZC4gSW4gYWRkaXRpb24gdG8gdGhlIHByaW9yaXR5DQptb2RpZmljYXRpb24sIHRoaXMgZG9j dW1lbnQgaW50cm9kdWNlcyB0aGUgdXNlIG9mIEZyZWV6ZSBjb21tYW5kIGluDQpBcHBlbmRpeCBD LiBUaGUgcmVhc29ucyBmb3IgdGhlc2UgY2hhbmdlcyBhcmUgZXhwbGFpbmVkIGluIHRoZQ0KZm9s bG93aW5nIHN1Yi1zZWN0aW9ucyBmcm9tIHRlY2huaWNhbCBhbmQgbmV0d29yayBvcGVyYXRpb25h bA0KYXNwZWN0cy4NCg0KVGhlIGlzc3VlIEkgaGF2ZSB3aXRoIHRoaXMgdGV4dCBpcyB0aGF0IGEg c3dhcCBoYXMgdG8gYmUgcmVsYXRpdmUgdG8NCnNvbWV0aGluZy4gU28gd2Ugc2hvdWxkIG1ha2Ug aXQgY2xlYXIgd2hhdCBpcyBpbiA2Mzc4IGFuZCB0aGVuIGRlc2NyaWJlDQp3aGF0IHRoaXMgZG9j dW1lbnQgZG9lcy4uLg0KDQpbUkZDNjM3OF0gZGVmaW5lcyB0aGUgcHJpb3JpdHkgb2YgRlMgdG8g YmUgaGlnaGVyIHRoYW4gdGhhdCBvZiBTRi1QLg0KVGhhdCBkb2N1bWVudCBhbHNvIGRlZmluZXMg dGhlIHByaW9yaXR5IG9mIENsZWFyIFNGIChTRmMpIHRvIGJlIGxvdy4NClRoaXMgZG9jdW1lbnQg dGhlIGRlZmluZXMgdGhlIFByaW9yaXR5IE1vZGlmaWNhdGlvbiBjYXBhYmlsaXR5DQp3aGVyZWJ5 IHRoZSBwcmlvcml0aWVzIG9mIEZTIGFuZCBTRi1QIGFyZSBzd2FwcGVkIGFuZCB0aGUgcHJpb3Jp dHkgb2YNCkNsZWFyIFNGIChTRmMpIGlzIHJhaXNlZC4gSW4gYWRkaXRpb24sIHRoaXMgY2FwYWJp bGl0eSBpbnRyb2R1Y2VzDQp0aGUgdXNlIG9mIEZyZWV6ZSBjb21tYW5kIGFzIGRlc2NyaWJlZCBp biBBcHBlbmRpeCBDLiBUaGUgcmVhc29ucw0KZm9yIHRoZXNlIGNoYW5nZXMgYXJlIGV4cGxhaW5l ZCBpbiB0aGUgZm9sbG93aW5nIHN1Yi1zZWN0aW9ucyBmcm9tDQp0ZWNobmljYWwgYW5kIG5ldHdv cmsgb3BlcmF0aW9uYWwgYXNwZWN0cy4NCg0KLS0tDQoNClNlY3Rpb24gNC4xDQoNCk5vIHRlY2hu aWNhbCBjaGFuZ2UsIGp1c3QgZWFzZSBvZiByZWFkaW5nLg0KDQpPTEQNClNldHRpbmcgdGhlIHBy aW9yaXR5IG9mIGFueSBpbnB1dCB0aGF0IGlzIHN1cHBvc2VkIHRvIGJlIHNpZ25hbGVkIHRvDQp0 aGUgb3RoZXIgZW5kIHRvIGJlIGhpZ2hlciB0aGFuIHRoYXQgb2YgU0YtUCBjYW4gcmVzdWx0IGlu DQp1bnByZWRpY3RhYmxlIHByb3RlY3Rpb24gc3dpdGNoaW5nIHN0YXRlLCB3aGVuIHRoZSBwcm90 ZWN0aW9uIHBhdGgNCmhhcyBmYWlsZWQgYW5kIGNvbnNlcXVlbnRseSB0aGUgUFNDIGNvbW11bmlj YXRpb24gc3RvcHBlZC4NCk5FVw0KV2hlbiB0aGUgcHJvdGVjdGlvbiBwYXRoIGZhaWxzIFBTQyBj b21tdW5pY2F0aW9uIG1heSBzdG9wIGFzIGENCnJlc3VsdC4gSW4gdGhpcyBjYXNlLCBpZiBhbnkg aW5wdXQgdGhhdCBpcyBzdXBwb3NlZCB0byBiZSBzaWduYWxlZCB0bw0KdGhlIG90aGVyIGVuZCBo YXMgYSBoaWdoZXIgcHJpb3JpdHkgdGhhdCBTRi1QIHRoZW4gdGhpcyBjYW4gcmVzdWx0IGluDQp1 bnByZWRpY3RhYmxlIHByb3RlY3Rpb24gc3dpdGNoaW5nIHN0YXRlLg0KRU5EDQoNCi0tLQ0KDQpT ZWN0aW9uIDQuMQ0KDQpBY2NvcmRpbmcgdG8gU2VjdGlvbiAyLjQgb2YgUkZDIDU2NTQgW1JGQzU2 NTRdIGl0IE1VU1QgYmUgcG9zc2libGUgdG8NCm9wZXJhdGUgYW4gTVBMUy1UUCBuZXR3b3JrIHdp dGhvdXQgdXNpbmcgYSBjb250cm9sIHBsYW5lLiBUaGlzIG1lYW5zDQp0aGF0IGV4dGVybmFsIHN3 aXRjaCBjb21tYW5kcywgZS5nLiwgRlMsIGNhbiBiZSB0cmFuc2ZlcnJlZCB0byB0aGUNCnJlbW90 ZSBMYWJlbCBFZGdlIFJvdXRlciAoTEVSKSBvbmx5IGJ5IHVzaW5nIHRoZSBQU0MgY29tbXVuaWNh dGlvbg0KY2hhbm5lbCBhbmQgc2hvdWxkIG5vdCByZWx5IG9uIHRoZSBwcmVzZW5jZSBvZiBhIGNv bnRyb2wgcGxhbmUuDQoNClRoaXMgcGFyYWdyYXBoIGhhcyBzZXZlcmFsIGlzc3Vlcy4NCg0KMS4g SXQgaXMgbm90IHRydWUhIE5vdCB1c2luZyBhIGNvbnRyb2wgcGxhbmUgbGVhdmVzIHRoZSBvcHRp b24gb2YgUFNDIGFzDQp5b3Ugc2F5LCBhbmQgYWxzbyBsZWF2ZXMgdGhlIG9wdGlvbiBvZiB0aGUg bWFuYWdlbWVudCBwbGFuZS4gSW5kZWVkLA0KdGhlIFBTQyBjb21tdW5pY2F0aW9uIGNoYW5uZWwg aXMgcHJvYmFibHkgYSBzcGVjaWFsIGNhc2Ugb2YgdGhlIGluLQ0KYmFuZCBPQU0gY2hhbm5lbC4N Cg0KMi4gVGhpcyBzdGF0ZW1lbnQgZG9lcyBub3QgYXBwZWFyIHRvIGhhdmUgYW55dGhpbmcgdG8g ZG8gd2l0aCBzd2FwcGluZw0KdGhlIHByaW9yaXRpZXMgb2YgRlMgYW5kIFNGLVAuDQoNCkkgc3Vn Z2VzdCB0aGF0IGlmIHlvdSBjYW4gc2hvdyBob3cgdGhpcyBzdGF0ZW1lbnQgaXMgcmVsYXRlZCB0 byB0aGUgc3dhcA0Kb2YgcHJpb3JpdGllcyB5b3Ugc2hvdWxkIGFkZCBpdC4gSW4gdGhhdCBjYXNl IHlvdSBzaG91bGQgYWxzbyBzYXkuLi4NClRoaXMgbWVhbnMNCnRoYXQgZXh0ZXJuYWwgc3dpdGNo IGNvbW1hbmRzLCBlLmcuLCBGUywgY2FuIGJlIHRyYW5zZmVycmVkIHRvIHRoZQ0KcmVtb3RlIExh YmVsIEVkZ2UgUm91dGVyIChMRVIpIG9ubHkgYnkgdXNpbmcgdGhlIG1hbmFnZW1lbnQgcGxhbmUg b3INCnRoZSBpbi1iYW5kIE9BTSBjaGFubmVsIGFuZCBzaG91bGQgbm90IHJlbHkgb24gdGhlIHBy ZXNlbmNlIG9mIGENCmNvbnRyb2wgcGxhbmUuIFRoZSB1c2Ugb2YgdGhlIE9BTSBjaGFubmVsIGFz IHVzZWQgYnkgUFNDIG1lc3NhZ2VzIGlzDQpjb25zaWRlcmVkIG1vcmUgYXBwcm9wcmlhdGUgZm9y IGNvaGVyZW5jZSB3aXRoIG90aGVyIFBTQyBtZXNzYWdlcy4NCklmLCBvbiB0aGUgb3RoZXIgaGFu ZCwgeW91IGNhbid0IHNob3cgaG93IHRoaXMgc3RhdGVtZW50IGlzIHJlbGV2YW50IGZvcg0KdGhl IHN3YXBwaW5nIG9mIHRoZSBwcmlvcml0aWVzLCBJIHN1Z2dlc3QgcmVtb3ZpbmcgdGhlIHBhcmFn cmFwaC4NCg0KLS0tDQoNClNlY3Rpb24gNC4xDQoNCkkgdGhpbmsgdGhpcyBvbmUgaXMgbWFpbmx5 IHBvbGl0aWNhbCA6LSkNCg0KT0xEDQpBcyB0aGUgcHJpb3JpdHkgb2YgU0YtUCBoYXMgYmVlbiBo aWdoZXIgdGhhbiBGUyBpbiBvdGhlciB0cmFuc3BvcnQNCm5ldHdvcmtzLCBzdWNoIGFzIFNESCwg T1ROIGFuZCBFdGhlcm5ldCB0cmFuc3BvcnQgbmV0d29ya3MsIGZvcg0KbmV0d29yayBvcGVyYXRv cnMgaXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIE1QTFMtVFAgcHJvdGVjdGlvbg0Kc3dpdGNoaW5n IHByZXNlcnZlcyB0aGUgbmV0d29yayBvcGVyYXRpb24gYmVoYXZpb3IgdG8gd2hpY2ggbmV0d29y aw0Kb3BlcmF0b3JzIGhhdmUgYmVjb21lIGFjY3VzdG9tZWQuDQpORVcNCkluIG90aGVyIHRyYW5z cG9ydCBuZXR3b3JrcyAoc3VjaCBhcyBTREgsIE9UTiwgYW5kIEV0aGVybmV0IHRyYW5zcG9ydA0K bmV0d29ya3MpIHRoZSBwcmlvcml0eSBvZiBTRi1QIGlzIGJlZW4gaGlnaGVyIHRoYW4gRlMuIEl0 IGlzDQp0aGVyZWZvcmUgaW1wb3J0YW50IHRvIG9mZmVyIG5ldHdvcmsgb3BlcmF0b3JzIHRoZSBv cHRpb24gb2YgaGF2aW5nDQp0aGUgc2FtZSBiZWhhdmlvciBpbiB0aGVpciBNUExTLVRQIG5ldHdv cmsgc28gdGhhdCB0aGV5IGNhbiBoYXZlIHRoZQ0Kc2FtZSBvcGVyYXRpb25hbCBwcm90ZWN0aW9u IHN3aXRjaGluZyBiZWhhdmlvciB0byB3aGljaCB0aGV5IGhhdmUNCmJlY29tZSBhY2N1c3RvbWVk Lg0KRU5EDQoNCi0tLQ0KDQpTZWN0aW9uIDQuMw0KDQpzL2Jyb2tlbiwgdGhlIEZyZWV6ZSBjb21t YW5kLC9icm9rZW4uIFRoZSBGcmVlemUgY29tbWFuZCwvDQoNCi0tLQ0KDQpTZWN0aW9uIDQuNA0K DQpBcyB5b3UgaGF2ZSBhbHJlYWR5IGVzdGFibGlzaGVkIGVhcmxpZXIgaW4gdGhpcyBkb2N1bWVu dCwgdGhlDQptb2RpZmljYXRpb25zIHRvIDYzNzggYXJlIHRoZSBhZGRpdGlvbiBvZiB0aGUgY2Fw YWJpbGl0aWVzDQphZHZlcnRpc2VtZW50LiBTbyBJIHRoaW5rIHRoZSBsYW5ndWFnZSB1c2VkIGlu IHRoaXMgc2VjdGlvbiBpcyB0b28NCnN0cm9uZy4gSSBzdWdnZXN0Li4uDQoNCk9MRA0KNC40LiBN b2RpZmljYXRpb25zIHRvIFJGQyA2Mzc4DQoNClRoZSBsaXN0IG9mIGxvY2FsIHJlcXVlc3RzIGlu IG9yZGVyIG9mIHByaW9yaXR5IFNIQUxMIGJlIG1vZGlmaWVkIGFzDQpmb2xsb3dzOg0KDQooZnJv bSBoaWdoZXIgdG8gbG93ZXIpDQoNCm8gQ2xlYXIgU2lnbmFsIEZhaWwNCg0KbyBTaWduYWwgRmFp bCBvbiBQcm90ZWN0aW9uIHBhdGgNCg0KbyBGb3JjZWQgU3dpdGNoDQoNCm8gU2lnbmFsIEZhaWwg b24gV29ya2luZyBwYXRoDQoNClRoZSBjaGFuZ2Ugb2YgdGhlIFBTQyBDb250cm9sIGxvZ2ljIGlu Y2x1ZGluZyB0aGUgc3RhdGUgbWFjaGluZSBkdWUNCnRvIHRoaXMgcHJpb3JpdHkgbW9kaWZpY2F0 aW9uIGlzIGluY29ycG9yYXRlZCBpbiB0aGUgUFNDIENvbnRyb2wNCmxvZ2ljIGRlc2NyaXB0aW9u IGluIFNlY3Rpb24gMTAgYW5kIFNlY3Rpb24gMTEgd2hlbiBhbGwgdGhlDQpjYXBhYmlsaXRpZXMg YXJlIGVuYWJsZWQuDQpORVcNCjQuNC4gUHJvY2VkdXJlcyBpbiBTdXBwb3J0IG9mIENhcGFiaWxp dHkgMQ0KDQpXaGVuIHRoaXMgY2FwYWJpbGl0eSBpcyBpbiB1c2UgdGhlIGxpc3Qgb2YgbG9jYWwg cmVxdWVzdHMgaW4gb3JkZXIgb2YNCnByaW9yaXR5IFNIQUxMIGJlIGFzIGZvbGxvd3M6DQoNCihm cm9tIGhpZ2hlc3QgdG8gbG93ZXN0KQ0KDQpvIENsZWFyIFNpZ25hbCBGYWlsDQoNCm8gU2lnbmFs IEZhaWwgb24gUHJvdGVjdGlvbiBwYXRoDQoNCm8gRm9yY2VkIFN3aXRjaA0KDQpvIFNpZ25hbCBG YWlsIG9uIFdvcmtpbmcgcGF0aA0KDQpUaGlzIHJlcXVpcmVzIGRpZmZlcmVudCBQU0MgY29udHJv bCBsb2dpYyAoaW5jbHVkaW5nIHRoZSBzdGF0ZQ0KbWFjaGluZSkgY29tcGFyZWQgdG8gdGhhdCBz aG93biBpbiBbUkZDNjM3OF0uIFNlY3Rpb25zIDEwIGFuZCAxMQ0Kc2hvdyB0aGUgUFNDIGNvbnRy b2wgbG9naWMgYW5kIHN0YXRlIG1hY2hpbmUgd2hlbiBhbGwgb2YgdGhlDQpjYXBhYmlsaXRpZXMg aW4gQVBTIG1vZGUgYXJlIGVuYWJsZWQuDQpFTkQNCg0KLS0tDQoNClNlY3Rpb24gNQ0KDQpTaW1p bGFyIGNoYW5nZXMgdG8gdGhvc2UgcHJvcG9zZWQgZm9yIFNlY3Rpb25zIDQuMSBhbmQgNC40Lg0K DQpPTEQNCkhvd2V2ZXIsIFBTQyBwcm90b2NvbCBkZWZpbmVkIGluIFJGQyA2Mzc4IFtSRkM2Mzc4 XSBzdXBwb3J0cyB0aGlzDQpvcGVyYXRpb24gb25seSB3aGVuIHJlY292ZXJpbmcgZnJvbSBhIGRl ZmVjdCBjb25kaXRpb24sIGJ1dCBkb2VzIG5vdA0Kb3BlcmF0ZSBhcyBub24tcmV2ZXJ0aXZlIHdo ZW4gYW4gb3BlcmF0b3IncyBzd2l0Y2gtb3ZlciBjb21tYW5kIHN1Y2gNCmFzIEZTIG9yIE1hbnVh bCBTd2l0Y2ggKE1TKSBpcyBjbGVhcmVkLiBUbyBiZSBhbGlnbmVkIHdpdGggbGVnYWN5DQp0cmFu c3BvcnQgbmV0d29yayBiZWhhdmlvciBhbmQgUkZDIDQ0MjcsIGEgbm9kZSBzaG91bGQgZ28gaW50 byB0aGUNCkRvLW5vdC1SZXZlcnQgKEROUikgc3RhdGUgbm90IG9ubHkgd2hlbiBhIGZhaWx1cmUg Y29uZGl0aW9uIG9uIHRoZQ0Kd29ya2luZyBwYXRoIGlzIGNsZWFyZWQgYnV0IGFsc28gd2hlbiBh biBvcGVyYXRvciBjb21tYW5kIHJlcXVlc3RpbmcNCnN3aXRjaC1vdmVyIGlzIGNsZWFyZWQuDQoN ClRoZSBjaGFuZ2Ugb2YgdGhlIFBTQyBDb250cm9sIGxvZ2ljIGluY2x1ZGluZyB0aGUgc3RhdGUg bWFjaGluZSBkdWUNCnRvIHRoZSBtb2RpZmljYXRpb24gb2Ygbm9uLXJldmVydGl2ZSBvcGVyYXRp b24gaXMgaW5jb3Jwb3JhdGVkIGludG8NCnRoZSBQU0MgQ29udHJvbCBsb2dpYyBkZXNjcmlwdGlv biBpbiBTZWN0aW9uIDEwIGFuZCBTZWN0aW9uIDExIHdoZW4NCmFsbCB0aGUgY2FwYWJpbGl0aWVz IGFyZSBlbmFibGVkLg0KTkVXDQpIb3dldmVyLCB0aGUgUFNDIHByb3RvY29sIGRlZmluZWQgaW4g UkZDIDYzNzggW1JGQzYzNzhdIHN1cHBvcnRzIHRoaXMNCm9wZXJhdGlvbiBvbmx5IHdoZW4gcmVj b3ZlcmluZyBmcm9tIGEgZGVmZWN0IGNvbmRpdGlvbjogaXQgZG9lcyBub3QNCnN1cHBvcnQgdGhl IG5vbi1yZXZlcnRpdmUgZnVuY3Rpb24gd2hlbiBhbiBvcGVyYXRvcidzIHN3aXRjaC1vdmVyDQpj b21tYW5kLCBzdWNoIGFzIEZTIG9yIE1hbnVhbCBTd2l0Y2ggKE1TKSwgaXMgY2xlYXJlZC4gVG8g YmUgYWxpZ25lZA0Kd2l0aCB0aGUgYmVoYXZpb3VyIGluIG90aGVyIHRyYW5zcG9ydCBuZXR3b3Jr cyBhbmQgdG8gYmUgY29uc2lzdGVudA0Kd2l0aCBSRkMgNDQyNywgYSBub2RlIHNob3VsZCBnbyBp bnRvIHRoZSBEby1ub3QtUmV2ZXJ0IChETlIpIHN0YXRlDQpub3Qgb25seSB3aGVuIGEgZmFpbHVy ZSBjb25kaXRpb24gb24gdGhlIHdvcmtpbmcgcGF0aCBpcyBjbGVhcmVkLCBidXQNCmFsc28gd2hl biBhbiBvcGVyYXRvciBjb21tYW5kIHRoYXQgcmVxdWVzdGVkIHN3aXRjaC1vdmVyIGlzIGNsZWFy ZWQuDQoNClRoaXMgcmVxdWlyZXMgZGlmZmVyZW50IFBTQyBjb250cm9sIGxvZ2ljIChpbmNsdWRp bmcgdGhlIHN0YXRlDQptYWNoaW5lKSBjb21wYXJlZCB0byB0aGF0IHNob3duIGluIFtSRkM2Mzc4 XS4gU2VjdGlvbnMgMTAgYW5kIDExDQpzaG93IHRoZSBQU0MgY29udHJvbCBsb2dpYyBhbmQgc3Rh dGUgbWFjaGluZSB3aGVuIGFsbCBvZiB0aGUNCmNhcGFiaWxpdGllcyBpbiBBUFMgbW9kZSBhcmUg ZW5hYmxlZC4NCkVORA0KDQotLS0NCg0KU2VjdGlvbiA2LjENCg0KT0xEDQpDaGFuZ2luZyB0aGUg bm9uLXJldmVydGl2ZSBvcGVyYXRpb24NCk5FVw0KQ2hhbmdpbmcgdGhlIG5vbi1yZXZlcnRpdmUg b3BlcmF0aW9uIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUNCkVORA0KDQotLS0NCg0KU2VjdGlv biA2LjENCg0KT0xEDQpNYW51YWwgU3dpdGNoLW92ZXIgZm9yIHJlY292ZXJ5IExTUC9zcGFuIGNv bW1hbmQsIGRlZmluZWQgaW4gUkZDIDQ0MjcNCltSRkM0NDI3XSBhbmQgYWxzbyBkZWZpbmVkIGlu IFJGQyA1NjU0IFtSRkM1NjU0XSwgUmVxdWlyZW1lbnQgODMsIGFzDQpvbmUgb2YgdGhlIG1hbmRh dG9yeSBleHRlcm5hbCBjb21tYW5kcywgc2hvdWxkIGJlIHVzZWQgZm9yIHRoaXMNCnB1cnBvc2Us IGJ1dCBpcyBub3QgaW5jbHVkZWQgaW4gUkZDIDYzNzguIE5vdGUgdGhhdCB0aGUgIk1hbnVhbA0K U3dpdGNoLW92ZXIgZm9yIHJlY292ZXJ5IExTUC9zcGFuIiBjb21tYW5kIGlzIHRoZSBzYW1lIGFz IE1TLVcNCmNvbW1hbmQuDQpORVcNCk1hbnVhbCBTd2l0Y2gtb3ZlciBmb3IgcmVjb3ZlcnkgTFNQ L3NwYW4gY29tbWFuZCBpcyBkZWZpbmVkIGluIFJGQw0KNDQyNyBbUkZDNDQyN10uIFJlcXVpcmVt ZW50IDgzIGluIFJGQyA1NjU0IFtSRkM1NjU0XSBzdGF0ZXMgdGhhdCB0aGUNCmV4dGVybmFsIGNv bW1hbmRzIGRlZmluZWQgaW4gUkZDIDQ0MjcgbXVzdCBiZSBzdXBwb3J0ZWQuIE5vIHN1Y2gNCmNv bW1hbmQgaXMgc3VwcG9ydGVkIGluIFBTQyBhcyBkZWZpbmVkIGluIFJGQyA2Mzc4IHNvIHRoZXJl IGlzIGEgbmVlZA0KdG8gcHJvdmlkZSBzdXBwb3J0IGZvciB0aGF0IGZlYXR1cmUuIE5vdGUgdGhh dCB0aGUgIk1hbnVhbCBTd2l0Y2gtDQpvdmVyIGZvciByZWNvdmVyeSBMU1Avc3BhbiIgY29tbWFu ZCBpcyB0aGUgc2FtZSBhcyB0aGUgTVMtVyBjb21tYW5kLg0KRU5EDQoNCi0tLQ0KDQpJbiBTZWN0 aW9uIDYuMiwgd2hlbiB5b3Ugc2F5ICJyZXBsYWNlZCIgaXQgaW1wbGllcyB0aGF0IHRoaXMgaXMg bWFraW5nIGENCnNwZWNpZmljIHVwZGF0ZSB0byA2Mzc4LiBCdXQgSSBkb24ndCB0aGluayB5b3Ug bmVlZCB0byBkbyB0aGF0IChhbmQNCnBvc3NpYmx5IHRoYXQgd2Fzbid0IHRoZSBpbnRlbnRpb24u IEkgdGhpbmsgaXQgaXMgZW5vdWdoIHRvIGRlZmluZSB0aGUNCnRlcm1zIHlvdSB1c2UgaW4gdGhp cyBkb2N1bWVudC4gU28gSSBzdWdnZXN0Li4uDQoNCk9MRA0KVGhlIHRlcm0gIk1hbnVhbCBTd2l0 Y2giIGFuZCBpdHMgYWNyb255bSAiTVMiIHVzZWQgaW4gUkZDIDYzNzggYXJlDQpyZXBsYWNlZCBy ZXNwZWN0aXZlbHkgYnkgIk1hbnVhbCBTd2l0Y2ggdG8gUHJvdGVjdGlvbiBwYXRoIiBhbmQNCiJN Uy1QIiBieSB0aGlzIGRvY3VtZW50IHRvIGF2b2lkIGNvbmZ1c2lvbiB3aXRoICJNYW51YWwgU3dp dGNoIHRvDQpXb3JraW5nIHBhdGgiIGFuZCBpdHMgYWNyb255bSAiTVMtVyIuDQoNCkFsc28sIHRo ZSB0ZXJtICJQcm90ZWN0aW5nIGFkbWluaXN0cmF0aXZlIHN0YXRlIiB1c2VkIGluIFJGQyA2Mzc4 IGlzDQpyZXBsYWNlZCBieSAiU3dpdGNoaW5nIGFkbWluaXN0cmF0aXZlIHN0YXRlIiBieSB0aGlz IGRvY3VtZW50IHRvDQppbmNsdWRlIHRoZSBjYXNlIHdoZXJlIHRyYWZmaWMgaXMgc3dpdGNoZWQg YmFjayB0byB0aGUgd29ya2luZyBwYXRoDQpieSBhZG1pbmlzdHJhdGl2ZSBNUy1XIGNvbW1hbmQu DQpORVcNClJGQyA2Mzc4IHVzZXMgdGhlIHRlcm0gIk1hbnVhbCBTd2l0Y2giIGFuZCBpdHMgYWNy b255bSAiTVMiLiBUaGlzDQpkb2N1bWVudCB1c2VzIHRoZSB0ZXJtICJNYW51YWwgU3dpdGNoIHRv IFByb3RlY3Rpb24gcGF0aCIgYW5kDQoiTVMtUCIgdG8gaGF2ZSB0aGUgc2FtZSBtZWFuaW5nLCBi dXQgYXZvaWQgY29uZnVzaW9uIHdpdGggIk1hbnVhbA0KU3dpdGNoIHRvIFdvcmtpbmcgcGF0aCIg YW5kIGl0cyBhY3JvbnltICJNUy1XIi4NCg0KU2ltaWxhcmx5LCBSRkMgNjM3OCB1c2VzIHRoZSB0 ZXJtICJQcm90ZWN0aW5nIGFkbWluaXN0cmF0aXZlIHN0YXRlIiwNCmFuZCB0aGlzIGRvY3VtZW50 IHVzZXMgIlN3aXRjaGluZyBhZG1pbmlzdHJhdGl2ZSBzdGF0ZSIgdG8gY292ZXIgdGhlDQpzYW1l IGNvbmNlcHQgYnV0IGFsc28gaW5jbHVkZSB0aGUgY2FzZSB3aGVyZSB0cmFmZmljIGlzIHN3aXRj aGVkIGJhY2sNCnRvIHRoZSB3b3JraW5nIHBhdGggYnkgYWRtaW5pc3RyYXRpdmUgTVMtVyBjb21t YW5kLg0KRU5EDQoNCkluIGtlZXBpbmcgd2l0aCB0aGlzLCBpdCBtaWdodCBiZSBiZXR0ZXIgdG8g Y2hhbmdlIHRoZSBzZWN0aW9uIHRpdGxlIHRvDQoNCjYuMi4gVGVybWlub2xvZ3kgdG8gc3VwcG9y dCBNUy1XDQoNCi0tLQ0KDQpTZWN0aW9uIDYuMw0KDQpUaGVyZSBpcyBhIHNsaWdodCBkaXNjcmVw YW5jeSBpbiB0aGUgdGV4dCBiZWNhdXNlIGl0IHNheXMgdGhhdCB0aGUgTVMtUA0KYW5kIE1TLVcg Y29tbWFuZHMgaGF2ZSB0aGUgc2FtZSBwcmlvcml0eSwgYnV0IGFsc28gZ2l2ZXMgYW4gZXhhbXBs ZSBvZg0Kd2hlbiB0aGV5IGRvbid0IGhhdmUgdGhlIHNhbWUgcHJpb3JpdHkuDQoNCkkgdGhpbmsg YWxsIHRoZSByZWxldmFudCBtYXRlcmlhbCBpcyBwcmVzZW50LCBzbyBpdCBpcyBqdXN0IGEgbWF0 dGVyIG9mDQpyZS1vcmRlcmluZyBpdC4uLi4NCg0KT0xEDQpUaGUgTVMtUCBhbmQgTVMtVyBjb21t YW5kcyBTSEFMTCBoYXZlIHRoZSBzYW1lIHByaW9yaXR5LiBJZiBvbmUgb2YNCnRoZXNlIGNvbW1h bmRzIGlzIGFscmVhZHkgaXNzdWVkIGFuZCBhY2NlcHRlZCwgdGhlbiB0aGUgb3RoZXIgY29tbWFu ZA0KdGhhdCBpcyBpc3N1ZWQgYWZ0ZXJ3YXJkcyBTSEFMTCBiZSBpZ25vcmVkLiBJZiB0d28gTEVS cyBhcmUNCnJlcXVlc3Rpbmcgb3Bwb3NpdGUgb3BlcmF0aW9ucyBzaW11bHRhbmVvdXNseSwgaS5l LiBvbmUgTEVSIGlzDQpzZW5kaW5nIE1TLVAgd2hpbGUgdGhlIG90aGVyIExFUiBpcyBzZW5kaW5n IE1TLVcsIHRoZSBNUy1XIFNIQUxMIGJlDQpjb25zaWRlcmVkIHRvIGhhdmUgYSBoaWdoZXIgcHJp b3JpdHkgdGhhbiBNUy1QLCBhbmQgTVMtUCBTSEFMTCBiZQ0KaWdub3JlZCBhbmQgY2FuY2VsbGVk Lg0KTkVXDQpJZiBvbmUgb2YgdGhlIE1TLVAgYW5kIE1TLVcgY29tbWFuZHMgaXMgcmVjZWl2ZWQg YW5kIHByb2Nlc3NlZCBhZnRlcg0KdGhlIG90aGVyLCB0aGUgdHdvIGNvbW1hbmRzIFNIQUxMIGhh dmUgdGhlIHNhbWUgcHJpb3JpdHkgc3VjaCB0aGF0IGlmDQpvbmUgb2YgdGhlIGNvbW1hbmRzIGlz IGFscmVhZHkgaXNzdWVkIGFuZCBhY2NlcHRlZCwgdGhlIGNvbW1hbmQgdGhhdA0KaXMgaXNzdWVk IGFmdGVyd2FyZHMgU0hBTEwgYmUgaWdub3JlZC4gSG93ZXZlciwgaWYgdHdvIExFUnMgcmVxdWVz dA0Kb3Bwb3NpdGUgb3BlcmF0aW9ucyBzaW11bHRhbmVvdXNseSAoaS5lLiwgb25lIExFUiBzZW5k cyBNUy1QIGFuZCB0aGUNCm90aGVyIHNlbmRzIE1TLVcpLCB0aGUgTVMtVyBTSEFMTCBiZSBjb25z aWRlcmVkIHRvIGhhdmUgYSBoaWdoZXINCnByaW9yaXR5IHRoYW4gTVMtUCwgYW5kIE1TLVAgU0hB TEwgTk9UIGJlIGFjY2VwdGVkIGFuZCBTSEFMTCBiZQ0KY2FuY2VsbGVkLg0KRU5EDQoNCi0tLQ0K DQpTZWN0aW9uIDYuNA0KDQpKdXN0IGFzIDQuMSwgNC40LCBhbmQgNS4uLg0KDQpPTEQNClRoZSBj aGFuZ2Ugb2YgdGhlIFBTQyBDb250cm9sIGxvZ2ljIGluY2x1ZGluZyB0aGUgc3RhdGUgbWFjaGlu ZSBkdWUNCnRvIHRoZSBzdXBwb3J0IG9mIE1TLVcgY29tbWFuZCBpcyBpbmNvcnBvcmF0ZWQgaW50 byB0aGUgUFNDIENvbnRyb2wNCmxvZ2ljIGRlc2NyaXB0aW9uIGluIFNlY3Rpb24gMTAgYW5kIFNl Y3Rpb24gMTEgd2hlbiBhbGwgdGhlDQpjYXBhYmlsaXRpZXMgYXJlIGVuYWJsZWQNCk5FVw0KU3Vw cG9ydCBvciB0aGlzIGZ1bmN0aW9uIHJlcXVpcmVzIGNoYW5nZXMgdG8gdGhlIFBTQyBjb250cm9s IGxvZ2ljDQooaW5jbHVkaW5nIHRoZSBzdGF0ZSBtYWNoaW5lKSBjb21wYXJlZCB0byB0aGF0IHNo b3duIGluIFtSRkM2Mzc4XS4NClNlY3Rpb25zIDEwIGFuZCAxMSBzaG93IHRoZSBQU0MgY29udHJv bCBsb2dpYyBhbmQgc3RhdGUgbWFjaGluZSB3aGVuDQphbGwgb2YgdGhlIGNhcGFiaWxpdGllcyBp biBBUFMgbW9kZSBhcmUgZW5hYmxlZC4NCkVORA0KDQotLS0NCg0KU2VjdGlvbiA3LjENCg0KVGhl IFBTQyBwcm90b2NvbCBhc3NvY2lhdGVkIHdpdGggU0QgaXMgY292ZXJlZCBpbiB0aGlzIGRvY3Vt ZW50LCBhbmQNCnRoZSBzcGVjaWZpY3MgZm9yIHRoZSBtZXRob2Qgb2YgaWRlbnRpZnlpbmcgU0Qg aXMgb3V0IG9mIHRoZSBzY29wZSBvZg0KdGhlIHByb3RlY3Rpb24gcHJvdG9jb2wgc2ltaWxhciB0 byB0aGUgZmFjdHMgdGhhdCBob3cgU0YgaXMgZGV0ZWN0DQphbmQgaG93IE1TIGFuZCBGUyBjb21t YW5kcyBhcmUgaW5pdGlhdGVkIGluIGEgbWFuYWdlbWVudCBzeXN0ZW0gYW5kDQpzaWduYWxlZCB0 byBwcm90ZWN0aW9uIHN3aXRjaGluZyBhcmUgb3V0IG9mIGl0cyBzY29wZS4NCg0Kcy9hbmQgdGhl IHNwZWNpZmljcy9idXQgdGhlIHNwZWNpZmljcy8NCg0KSXQgaXMgT0sgdG8gaW5jbHVkZSB0aGUg InNpbWlsYXIgdG8uLi4iIGJ1dCBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIGdpdmUNCnRoaXMgcmVh c29uaW5nLg0KDQotLS0NCg0KU2VjdGlvbiA3LjINCg0KSnVzdCBsaWtlIFNlY3Rpb24gNi4yIHRo ZSB3b3JkICJyZXBsYWNlZCIgbWF5IGJlIG1pc2ludGVycHJldGVkLg0KDQpTbyBJIHN1Z2dlc3Qg bmFtaW5nIHRoZSBzZWN0aW9uLi4uDQo3LjIuIFRlcm1pbm9sb2d5IHRvIHN1cHBvcnQgU0QNCg0K Li4uIGFuZCByZXBsYWNpbmcNCg0KT0xEDQpJbnN0ZWFkIG9mIFNGYywgQ2xlYXIgU2lnbmFsIEZh aWwgb3IgRGVncmFkZSAoU0ZEYykgaXMgdXNlZCB0bw0KaW5kaWNhdGUgdGhlIGNsZWFyYW5jZSBv ZiBlaXRoZXIgYSBkZWdyYWRlZCBjb25kaXRpb24gb3IgYSBmYWlsdXJlDQpjb25kaXRpb24uDQpO RVcNCkluIHRoaXMgZG9jdW1lbnQgdGhlIHRlcm0gQ2xlYXIgU2lnbmFsIEZhaWwgb3IgRGVncmFk ZSAoU0ZEYykgaXMgdXNlZA0KdG8gaW5kaWNhdGUgdGhlIGNsZWFyYW5jZSBvZiBlaXRoZXIgYSBk ZWdyYWRlZCBjb25kaXRpb24gb3IgYSBmYWlsdXJlDQpjb25kaXRpb24uDQpFTkQNCg0KLS0tDQoN ClNlY3Rpb24gNy4zDQoNCkFnYWluLCBqdXN0IGEgc21hbGwgcG9saXRpY2FsIGNoYW5nZS4uLg0K DQpPTEQNCkluIG9yZGVyIHRvIG1haW50YWluIHRoZSBuZXR3b3JrIG9wZXJhdGlvbiBiZWhhdmlv ciB0byB3aGljaA0KdHJhbnNwb3J0IG5ldHdvcmsgb3BlcmF0b3JzIGhhdmUgYmVjb21lIGFjY3Vz dG9tZWQsIHRoZSBwcmlvcml0aWVzIG9mDQpTRC1QIGFuZCBTRC1XIGFyZSBkZWZpbmVkIHRvIGJl IGVxdWFsIGFzIGluIG90aGVyIHRyYW5zcG9ydCBuZXR3b3JrcywNCnN1Y2ggYXMgU0RILCBPVE4g YW5kIEV0aGVybmV0IHRyYW5zcG9ydCBuZXR3b3Jrcy4NCk5FVw0KSW4gb3JkZXIgdG8gbWFrZSB0 aGUgYmVoYXZpb3Igb2YgTVBMUy1UUCBuZXR3b3JrcyBjb25zaXN0ZW50IHdpdGgNCnRoYXQgb2Yg b3RoZXIgdHJhbnNwb3J0IG5ldHdvcmtzIChzdWNoIGFzIFNESCwgT1ROIGFuZCBFdGhlcm5ldA0K dHJhbnNwb3J0IG5ldHdvcmtzKSwgdGhlIHByaW9yaXRpZXMgb2YgU0QtUCBhbmQgU0QtVyBhcmUg ZGVmaW5lZCB0bw0KYmUgZXF1YWwuDQpFTkQNCg0KLS0tDQoNCkluIFNlY3Rpb24gNy40LCBmb3Ig Y2xhcml0eSwgSSB0aGluayB5b3Ugc2hvdWxkIGludGVuZCBhbmQgYnVsbGV0IHRoZQ0KdHdvIHBh cmFncmFwaHMgYmVnaW5uaW5nDQoNCldoZW4gTVMtVyBhbmQgTVMtUC4uLg0KYW5kDQpXaGVuIFNE LVcgYW5kIFNELVAuLi4NCg0KLS0tDQoNCkFuZCwgYXMgbm93IGlzIGJlY29taW5nIGZhbWlsaWFy LCBhdCB0aGUgZW5kIG9mIDcuNA0KDQpPTEQNClRoZSBjaGFuZ2Ugb2YgdGhlIFBTQyBDb250cm9s IGxvZ2ljIGluY2x1ZGluZyB0aGUgc3RhdGUgbWFjaGluZSBkdWUNCnRvIHRoZSBzdXBwb3J0IG9m IHByb3RlY3Rpb24gYWdhaW5zdCBTRCBpcyBpbmNvcnBvcmF0ZWQgaW50byB0aGUgUFNDDQpDb250 cm9sIGxvZ2ljIGRlc2NyaXB0aW9uIGluIFNlY3Rpb24gMTAgYW5kIFNlY3Rpb24gMTEgd2hlbiBh bGwgdGhlDQpjYXBhYmlsaXRpZXMgYXJlIGVuYWJsZWQuDQpORVcNClRoZSBhZGRpdGlvbiBvZiBz dXBwb3J0IGZvciBwcm90ZWN0aW9uIGFnYWluc3QgU0QgcmVxdWlyZXMgZGlmZmVyZW50DQpQU0Mg Y29udHJvbCBsb2dpYyAoaW5jbHVkaW5nIHRoZSBzdGF0ZSBtYWNoaW5lKSBjb21wYXJlZCB0byB0 aGF0DQpzaG93biBpbiBbUkZDNjM3OF0uIFNlY3Rpb25zIDEwIGFuZCAxMSBzaG93IHRoZSBQU0Mg Y29udHJvbCBsb2dpYyBhbmQNCnN0YXRlIG1hY2hpbmUgd2hlbiBhbGwgb2YgdGhlIGNhcGFiaWxp dGllcyBpbiBBUFMgbW9kZSBhcmUgZW5hYmxlZC4NCkVORA0KDQotLS0NCg0KU2VjdGlvbiA4IGlz IHVuY2xlYXIgaW4gdGhlIHJhY2UgbG9naWMuIFlvdSBoYXZlLi4uDQoNCldoZW4gRXhlcmNpc2Ug Y29tbWFuZHMgYXJlIGlucHV0IGF0IGJvdGggZW5kcywgYW4gRVhFUiwgaW5zdGVhZCBvZg0KUlIs IFNIQUxMIGJlIHRyYW5zbWl0dGVkIGZyb20gYm90aCBlbmRzLg0KDQpJIHRoaW5rIHRoYXQgdGhp cyBtZWFucyB0aGF0IEVYRVIgc2hhbGwgYmUgdGFrZW4gYXMgYSB2YWxpZCByZXNwb25zZSB0bw0K RVhFUiBhbmQgdGhhdCBpZiBhbiBMRVIgdGhhdCBoYXMgaXNzdWVkIGFuIEVYRVIgYW5kIGhhcyBu b3QgcmVjZWl2ZWQgYW4NClJSIHRoZW4sIGlmIGl0IHJlY2VpdmVzIGFuIEVYRVIgaXQgZG9lcyBu b3QgbmVlZCB0byAoU0hPVUxEIE5PVCkgc2VuZA0KUlIuDQoNCldlIGNvdWxkIGNhcHR1cmUgdGhp cyBhcy4uLg0KDQpPTEQNCldoZW4gRXhlcmNpc2UgY29tbWFuZHMgYXJlIGlucHV0IGF0IGJvdGgg ZW5kcywgYW4gRVhFUiwgaW5zdGVhZCBvZg0KUlIsIFNIQUxMIGJlIHRyYW5zbWl0dGVkIGZyb20g Ym90aCBlbmRzLg0KTkVXDQpJZiBFeGVyY2lzZSBjb21tYW5kcyBhcmUgaW5wdXQgYXQgYm90aCBl bmRzLCB0aGVuIGEgcmFjZSBjb25kaXRpb24NCm1heSBhcnJpc2UuIFRoaXMgaXMgcmVzb2x2ZWQg YXMgZm9sbG93czoNCg0KbyBJZiBhbiBMRVIgaGFzIGlzc3VlZCBFWEVSIGFuZCByZWNlaXZlcyBF WEVSIGJlZm9yZSByZWNlaXZpbmcgUlIsIGl0DQoNCm8gTVVTVCB0cmVhdCB0aGUgcmVjZWl2ZWQg RVhFUiBhcyBpdCB3b3VsZCBhbiBSUi4NCg0KbyBTSE9VTEQgTk9UIHJlc3BvbmQgd2l0aCBSUi4N CkVORA0KDQotLS0NCg0KU2VjdGlvbiA4DQoNClRoZSBmb2xsb3dpbmcgUFNDIFJlcXVlc3RzIFNI QUxMIGJlIGFkZGVkIHRvIFBTQyBSZXF1ZXN0IGZpZWxkIHRvDQpzdXBwb3J0IEV4ZXJjaXNlOg0K DQpXZSBkb24ndCBuZWVkIHRvIHVzZSBSRkMgMjExOSBsYW5ndWFnZSBoZXJlLiBZb3UgY2FuIGp1 c3Qgc2F5Li4uDQoNClRoZSBmb2xsb3dpbmcgUFNDIFJlcXVlc3RzIGFyZSBhZGRlZCB0byB0aGUg UFNDIFJlcXVlc3QgZmllbGQgdG8NCnN1cHBvcnQgdGhlIEV4ZXJjaXNlIGNvbW1hbmQgKHNlZSBh bHNvIFNlY3Rpb24gMTQuMSk6DQoNCi0tLQ0KDQpTZWN0aW9uIDgNCg0KVGhlIHByaW9yaXR5IG9m IEV4ZXJjaXNlIFNIQUxMIGJlIGluc2VydGVkIGJldHdlZW4gdGhlIHByaW9yaXRpZXMgb2YNCldU UiBFeHBpcmVzIGFuZCBObyBSZXF1ZXN0Lg0KDQpGb3IgdGhlIGF2b2lkYW5jZSBvZiBkb3VidCBp dCBpcyBuaWNlIHRvIGFjdHVhbGx5IGdpdmUgdGhlIG9yZGVyaW5nLiBBbmQNCnNpbmNlIHdlIGVu ZCB1cCB3aXRoIEV4ZXJjaXNlIG5vdCBiZWluZyBpbW1lZGlhdGVseSBhZGphY2VudCB0byBObw0K UmVxdWVzdCwgSSBzdWdnZXN0IHRoaXMgaXMgYmVzdCBoYW5kbGVkIGJ5IGEgZm9yd2FyZCByZWZl cmVuY2UgdG8NClNlY3Rpb24gMTAuMi4NCg0KVGhlIHJlbGF0aXZlIHByaW9yaXR5IG9mIEV4ZXJj aXNlIGlzIHNob3duIGluIHRoZSB0YWJsZSBpbiBTZWN0aW9uDQoxMC4yLg0KDQotLS0NCg0KU2Vj dGlvbiA5LjEuMQ0KDQpXZSBkbyBub3QgZGVzaWduIHByb3RvY29scyB0byBtYWtlIHRoZW0gcmVz aWxpZW50IGFnYWluc3QgYnVncyBpbg0KaW1wbGVtZW50YXRpb25zIG9mIHRoZSBwcm90b2NvbC4g VGhpcyBpcyBiZWNhdXNlIGFueSB0aWNrIHlvdSBjb21lIHVwDQp3aXRoIHdpbGwsIGl0c2VsZiwg YmUgdnVsbmVyYWJsZSB0byBhIGJ1ZyBpbiB0aGUgaW1wbGVtZW50YXRpb24uDQoNClRodXMsIHdo ZW4geW91IHNheS4uLg0KDQpQU0Mgc2VuZHMgbWVzc2FnZXMgaW4gcmVzcG9uc2UgdG8gZXh0ZXJu YWwgZXZlbnRzIGFuZCBpbiBwZXJpb2RpYw0KcmV0cmFuc21pc3Npb24gb2YgY3VycmVudCBzdGF0 dXMuIEl0IG1heSBiZSBleHBlbnNpdmUgdG8gc2VuZCBhbmQgdG8NCnBhcnNlIGFuIENhcGFiaWxp dGllcyBUTFYgYXR0YWNoZWQgdG8gYSBwYWNrZXQgaW50ZW5kZWQgdG8gdHJpZ2dlciBhDQpwcm90 ZWN0aW9uIHN3aXRjaCBvciBvdGhlciByZWFsLXRpbWUgYmVoYXZpb3IuIEhvd2V2ZXIsIGlmIGEg bm9kZQ0KZG9lcyBub3QgcGVyaW9kaWNhbGx5IHNlbmQgaXRzIENhcGFiaWxpdGllcyBUTFYsIHRo ZSByZWNlaXZpbmcgbm9kZQ0KY2Fubm90IGRpc2NyaW1pbmF0ZSBhIGRlbGliZXJhdGUgb21pc3Np b24gb2YgdGhlIENhcGFiaWxpdGllcyBUTFYgZm9yDQpwZXJmb3JtYW5jZSByZWFzb25zIGZyb20g YW4gYWNjaWRlbnRhbCBvbWlzc2lvbiBkdWUgdG8gYW4NCmltcGxlbWVudGF0aW9uIGlzc3VlLiBU byBndWFyZCBhZ2FpbnN0IHRoaXMsIGEgbm9kZSBNVVNUIGluY2x1ZGUgaXRzDQpDYXBhYmlsaXRp ZXMgVExWIGluIGV2ZXJ5IFBTQyBtZXNzYWdlIHRoYXQgaXQgc2VuZHMuDQoNCi4uLnlvdSBhcmUg bmVnbGVjdGluZyB0byBjb25zaWRlciB0aGF0IGVhY2ggYW5kIHZlcnkgb21pc3Npb24gb2YgYQ0K Y2FwYWJpbGl0eSBtaWdodCBiZSBkdWUgdG8gYW4gaW1wbGVtZW50YXRpb24gaXNzdWUuIFNvIHJl cXVpcmluZw0KaW5jbHVzaW9uIGluIGV2ZXJ5IFBTQyBtZXNzYWdlIGRvZXMgbm90IHJlc29sdmUg dGhpcy4NCg0KSG93ZXZlciwgeW91ICpkbyogc3RpbGwgbmVlZCB0byBpbmNsdWRlIHRoZSBDYXBh YmlsaXRpZXMgVExWIGluIGV2ZXJ5DQpQU0MgbWVzc2FnZSAoaWYgdGhlIGltcGxlbWVudGF0aW9u IHN1cHBvcnRzIHRoZSBDYXBhYmlsaXRpZXMgVExWKSBpZg0KYW5kIG9ubHkgaWYsIGFuIExFUiBp cyBhbGxvd2VkIHRvIGNoYW5nZSB0aGUgY2FwYWJpbGl0aWVzIGl0IHN1cHBvcnRzDQpkdXJpbmcg dGhlIGxpZmV0aW1lIG9mIGFuIExTUC4gVGhlIHJlYXNvbiBmb3IgdGhpcyBpcyB0aGF0IHRoZQ0K YWJzZW5jZSBvZiB0aGUgQ2FwYWJpbGl0aWVzIFRMViBpcyB2YWxpZCBmb3IgYmFja3dhcmQgY29t cGF0aWJpbGl0eQ0KcmVhc29uczogdGhlcmVmb3JlIHRoZXJlIGlzIG5vIHdheSB0byBkaXN0aW5n dWlzaCAiSSBoYXZlIHN0b3BwZWQNCnN1cHBvcnRpbmcgYWxsIG9mIHRoZSBjYXBhYmlsaXRpZXMi IGZyb20gIkkgaGF2ZSBsZWZ0IG91dCB0aGUNCkNhcGFiaWxpdGllcyBUTFYgYmVjYXVzZSBub3Ro aW5nIGhhcyBjaGFuZ2VkLiINCg0KKC4uLmJ1dCBzZWUgbXkgY29tbWVudCBvbiA5LjEuMy4yIHdy dCB0aGUgZmluYWwgcGFyYWdyYXBoIG9mIDkuMykuDQoNClNvLCB5b3UgbXVzdCBkZWNpZGU6IGNh biBhbiBMRVIgY2hhbmdlIHRoZSBjYXBhYmlsaXRpZXMgaXQgc3VwcG9ydHM/DQpJZiB5ZXMsIHRo ZW4geW91IG1ha2UgKnRoYXQqIHRoZSByZWFzb24gZm9yIHJlcXVpcmluZyB0aGUgVExWIHRvIGJl DQpwcmVzZW50IGluIGV2ZXJ5IG1lc3NhZ2UuDQpJZiBubywgdGhlbiB0aGUgVExWIGRvZXMgbm90 IG5lZWQgdG8gYmUgcHJlc2VudCBpbiBlYWNoIG1lc3NhZ2UsIGJ1dCB5b3UNCmRvIG5lZWQgdG8g bWFrZSBzdXJlIHRoZSBtZXNzYWdlIHRoYXQgd2FzIGNhcnJ5aW5nIGl0IGdvdCBkZWxpdmVyZWQu DQoNCkl0IGxvb2tzIHRvIG1lLCBmcm9tIDkuMS4yIHRoYXQgeW91IGFyZSBzZXQgb24gcmVxdWly aW5nIHJldHJhbnNtaXNzaW9uDQphbmQgY29udGludWFsIGNoZWNraW5nIG9mIENhcGFiaWxpdGll cyBldmVuIHRob3VnaCBpdCB3b3VsZCBiZQ0KaW1wb3NzaWJsZSB0byBhY2hpZXZlIGEgc3luY2hy b25pc2VkIGNoYW5nZSAodGhhdCBpcywgaWYgb25lIGVuZCB3ZXJlIHRvDQpjaGFuZ2UgaXRzIGNh cGFiaWxpdGllcyB0aGlzIHdvdWxkIGF1dG9tYXRpY2FsbHkgcmVzdWx0IGluIGFuIGVycm9yDQpj b25kaXRpb25zKS4gU28gaXQgcmVhbGx5IHNlZW1zIHRvIG1lIHRoYXQgdGhpcyBpcyB1bm5lY2Vz c2FyeQ0KcHJvY2Vzc2luZy4NCg0KLS0tDQoNClNlY3Rpb24gOS4xLjINCg0KVGhpcyBjb21tZW50 IG9ubHkgYXBwbGllcyBpZiB5b3UgZG9uJ3QgbWFrZSBhbnkgY2hhbmdlIGFzIGEgcmVzdWx0IG9m DQpteSBjb21tZW50IG9uIHRoZSBwcmV2aW91cyBzZWN0aW9uLg0KDQpJIHRoaW5rIHlvdSBzaG91 bGQgYWR2aXNlIGFuIGltcGxlbWVudGF0aW9uIG9uIHdoZXRoZXIgaXQgc2hvdWxkDQpjb21wYXJl IHRoZSBDYXBhYmlsaXRpZXMgVExWIGFzIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24gYmVmb3Jl IG9yDQphZnRlciBhY3Rpbmcgb24gdGhlIHJlY2VpdmVkIFBTQyBtZXNzYWdlLiBUaGF0IGlzIChm b3IgZXhhbXBsZSksIHNob3VsZA0KYSBwcm90ZWN0aW9uIHN3aXRjaCBiZSB0cmlnZ2VyZWQgYmVm b3JlIG9yIGFmdGVyIHRoZSBDYXBhYmlsaXRpZXMgaGF2ZQ0KYmVlbiBjaGVja2VkPw0KDQotLS0N Cg0KU2VjdGlvbiA5LjEuMy4yDQoNCkkgdGhpbmsgdGhlIGZpbmFsIHBhcmFncmFwaCBvZiBTZWN0 aW9uIDkuMyBpcyB2ZXJ5IHJlbGV2YW50IGhlcmUuIFlvdQ0Kc2hvdWxkIGVpdGhlciBjb3B5IHRo ZSB0ZXh0IGhlcmUgb3IgeW91IHNob3VsZCBwcm92aWRlIGEgZm9yd2FyZCBwb2ludGVyDQp0byBT ZWN0aW9uIDkuMy4NCg0KDQotLS0NCg0KU2VjdGlvbiA5LjEuMy4zDQoNClNldmVyYWwgdGhpbmdz IGFyZSBub3QgY2xlYXIgaW4gdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBlcnJvciBoYW5kbGluZzoN Ci0gaWYgYSBtaXNtYXRjaCAoOS4xLjMuMikgaXMgcmVjZWl2ZWQsIHNob3VsZCB0aGUgdGltZXIg YmUgc3RvcHBlZD8NCi0gaWYgdGhlcmUgaXMgYSB0aW1lb3V0ICg5LjEuMy4xKSBhbmQgdGhlbiBh IFBTQyBtZXNzYWdlIGlzIHJlY2VpdmVkLA0Kc2hvdWxkIHRoZSBjYXBhYmlsaXRpZXMgYmUgY29t cGFyZWQ/DQotIGlmIGEgbWlzbWF0Y2ggKDkuMS4zLjIpIGlzIHJlY2VpdmVkIGFuZCB0aGVuIGEg UFNDIG1lc3NhZ2UgaXMNCnJlY2VpdmVkLCBzaG91bGQgdGhlIGNhcGFiaWxpdGllcyBiZSBjb21w YXJlZD8NCi0gaG93IHNob3VsZCBhbGVydHMgdG8gYmUgdGhlIG9wZXJhdG9yIGJlIGhhbmRsZWQg aW4gdGhlIGV2ZW50IG9mDQpjb250aW51ZWQgbWlzbWF0Y2hlcyBvciB0aW1lb3V0cz8NCi0gd2hh dCBhY3Rpb25zIGFyZSBhdmFpbGFibGUgdG8gYW4gb3BlcmF0b3IgdG8gcmVzb2x2ZSBjYXBhYmls aXRpZXMNCm1pc21hdGNoZXM/DQoNCi0tLQ0KDQpTZWN0aW9uIDkuMi4xDQoNCk9MRA0KQSBub2Rl IGNhbiBzZW5kIGENCkNhcGFiaWxpdGllcyBUTFYgb2YgMHgwDQpORVcNCkEgbm9kZSBjYW4gc2Vu ZCBhDQpDYXBhYmlsaXRpZXMgVExWIHdpdGggRmxhZ3MgdmFsdWUgc2V0IHRvIDB4MA0KRU5EDQoN Ci0tLQ0KDQpTaW1pbGFybHkgaW4gOS4yLjMNCg0KT0xEDQpDYXBhYmlsaXRpZXMgVExWIG9mIDB4 MA0KTkVXDQpDYXBhYmlsaXRpZXMgVExWIHdpdGggRmxhZ3MgdmFsdWUgc2V0IHRvIDB4MA0KRU5E DQoNCi0tLQ0KDQpTZWN0aW9uIDEwLjENCg0KWW91IHJlYWxseSBzY2FyZWQgbWUhDQoNClRoZSB2 YWx1ZXMgb2YgIlJlcXVlc3QiIGZpZWxkIGluIFBTQyBwcm90b2NvbCBtZXNzYWdlLCB3aGljaCBp cyBzaG93bg0KaW4gRmlndXJlIDIgb2YgUkZDIDYzNzggW1JGQzYzNzhdLCBhcmUgcmVkZWZpbmVk IGFzIGZvbGxvd3M6DQoNCkZvcnR1bmF0ZWx5IHlvdSBhcmUgbm90IHJlZGVmaW5pbmcgdGhlIFJl cXVlc3QgdHlwZXMgZnJvbSBSRkMgNjM3OC4gWW91DQphcmUganVzdCBkZWZpbmluZyB0d28gbmV3 IG9uZXMuIFBoZXchDQoNClNvIHlvdSBjYW4gcmVwbGFjZSB0aGUgd2hvbGUgb2YgU2VjdGlvbiAx MC4xIHdpdGguLi4NCg0KTkVXDQpUaGlzIGRvY3VtZW50IGRlZmluZXMgdHdvIG5ldyB2YWx1ZXMg Zm9yIHRoZSAiUmVxdWVzdCIgZmllbGQgaW4gdGhlDQpQU0MgcHJvdG9jb2wgbWVzc2FnZSB0aGF0 IGlzIHNob3duIGluIEZpZ3VyZSAyIG9mIFJGQyA2Mzc4IFtSRkM2Mzc4XQ0KYXMgZm9sbG93czoN Cg0KKDMpIEV4ZXJjaXNlDQooMikgUmV2ZXJzZSBSZXF1ZXN0DQoNClNlZSBhbHNvIFNlY3Rpb24g MTQuMSBvZiB0aGlzIGRvY3VtZW50Lg0KRU5EDQoNCi0tLQ0KDQpFaXRoZXIgZmlsbCBpbiBvciBk ZWxldGUgU2VjdGlvbiAxNS4NCg0KLS0tDQoNCkkgdGhpbmsgdGhhdCBbSS1ELmlldGYtbXBscy1w c2MtdXBkYXRlc10gY2FuIGJlIG1vdmVkIGZyb20gbm9ybWF0aXZlIHRvDQppbmZvcm1hdGl2ZSBy ZWZlcmVuY2UuIFRoaXMgZG9lc24ndCBkZWNyZWFzZSBpdHMgdmFsdWUsIGJ1dCBJIGRvbid0DQp0 aGluayB0aGF0ICp0aGlzKiBkb2N1bWVudCByZXF1aXJlcyBbSS1ELmlldGYtbXBscy1wc2MtdXBk YXRlc10uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbXBscyBbbWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvYSBBbmRlcnNzb24NCj4g U2VudDogMjAgSmFudWFyeSAyMDE0IDAyOjI4DQo+IFRvOiBtcGxzQGlldGYub3JnDQo+IENjOiA7 IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtdHAtDQo+IHBzYy1p dHVAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAxDQo+DQo+IFdvcmtpbmcgR3JvdXAsDQo+ DQo+IFRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBv bg0KPiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0 OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQ7IFRFWFQtQVVUT1NQQUNF OiBpZGVvZ3JhcGgtbnVtZXJpYzsgV09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9u OiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxmb250IGZh Y2U9IuunkeydgCDqs6DrlJUiPjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBw dDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+unkeyd gCDqs6DrlJUnOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5n OiAwcHQiIGxhbmc9IkVOLVVTIj5BZHJpYW4gYW5kIGFsbCwNCjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBj bSAwY20gMTBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFL OiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9 Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5Hs nYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPjwvc3Bhbj48L2Zv bnQ+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAx NXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1l cmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9u dC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5Hs nYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1i aWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4t VVMiPk1hbnkmbmJzcDt0aGFua3MgdG8mbmJzcDtBZHJpYW4gZm9yIGhpcyB0aG9yb3VnaA0KIGFu ZCB2YWx1YWJsZSByZXZpZXcuPC9zcGFuPjwvZm9udD48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElH TjogbGVmdDsgTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFV VE9TUEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFn aW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXpl OiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6 ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQt a2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+SW4gbXkgb3BpbmlvbiwmbmJzcDthbGwgdGhlIHdv cmRpbmcgZnJvbSBBRA0KIHJldmlldyBzaG91bGQgYmUgdGFrZW4gZXhjZXB0IHRoZSBmb2xsb3dp bmdzIHRoYXQgSSB3b3VsZCBuZWVkIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbnMgb3IgY29uZmlybWF0 aW9ucyBmcm9tIEFEOjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxl ZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdDsgVEVYVC1BVVRPU1BB Q0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRp b246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAu MHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR 7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5p bmc6IDBwdCIgbGFuZz0iRU4tVVMiPi0tLTwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9IlRF WFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdDsg VEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsg bXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZv bnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsg bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1z by1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPkFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rp b248L3NwYW4+PC9mb250PjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhF SUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3Jh cGgtbnVtZXJpYzsgV09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1v cnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxmb250IGZhY2U9Iuunkeyd gCDqs6DrlJUiPjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWFz Y2lpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiAn66eR7J2AIOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUn OyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxh bmc9IkVOLVVTIj5EdWUgdG8gdGhlIGxpbWl0YXRpb24gaW4gdGhlIGxlbmd0aCBvZg0KIEFic3Ry YWN0IGFuZCB0aGUgbmF0dXJlIG9mJm5ic3A7dGhlIGFic3RyYWN0LCB3aGljaCBnaXZlcyB0aGUg bWFpbiBwb2ludHMgb2YgKnRoaXMqIGRvY3VtZW50LCBJIHdvdWxkIGxpa2UgdG8gc2VlIGlmIHdl IGNhbiBhZGQgdGhlIHNlbnRlbmNlIGluIHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBvbmx5Lg0K PC9zcGFuPjwvZm9udD48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlH SFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBo LW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3Jw aGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2Np aS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog J+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsg bXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5n PSJFTi1VUyI+LS0tPC9zcGFuPjwvZm9udD48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVm dDsgTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFVVE9TUEFD RTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlv bjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8Zm9udCBm YWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4w cHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1m b250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5Hs nYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2Vybmlu ZzogMHB0IiBsYW5nPSJFTi1VUyI+U2VjdGlvbiA0LjE8L3NwYW4+PC9mb250PjwvcD4NCjxwIHN0 eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNt IDEwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgV09SRC1CUkVBSzoga2Vl cC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJsZWZ0Ij4NCjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNv LWFzY2lpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+unkeydgCDqs6Dr lJUnOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQi IGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5UaGUgc2Vjb25kIHBhcmFn cmFwaCBpbiBTZWN0aW9uIDQuMSBpcw0KIHRvIGVtcGhhc2lzIHRoZSBpbXBvcnRhbmNlIG9mIHRo ZSBQU0MgY29tbXVuaWNhdGlvbiBjaGFubmVsIGluIGRlbGl2ZXJpbmcgdGhlIGV4dGVybmFsIHN3 aXRjaCBjb21tYW5kLCBzbyB0aGF0IHRoZSBmYWlsdXJlIG9mIFBTQyBjb21tdW5pY2F0aW9uIGNo YW5uZWwgaGFzIGhpZ2hlciBwcmlvcml0eSB0aGFuIEZTLg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNt IDBjbSAxMHB0OyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6 IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7 IG1zby1hc2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250 LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg 6rOg65SVJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzog MHB0IiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+SSB3b3VsZCBsaWtl IHRvIHByb3Bvc2UgdG8gY2hhbmdlIHRoZQ0KIHBhcmFncmFwaCBhcyBmb2xsb3dzOjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0 OyBNQVJHSU46IDBjbSAwY20gMTBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmlj OyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQt c2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFt aWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1m b250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi Pj09PSBPTEQgPT09PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVm dDsgTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFVVE9TUEFD RTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlv bjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAu MHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAw cHQiIGxhbmc9IkVOLVVTIj5BY2NvcmRpbmcgdG8gU2VjdGlvbiAyLjQgb2YgUkZDIDU2NTQgW1JG QzU2NTRdIGl0IE1VU1QgYmUgcG9zc2libGUgdG88L3NwYW4+PC9wPg0KPHAgc3R5bGU9IlRFWFQt QUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdDsgVEVY VC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNv LXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi Pg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tYmlkaS1mb250 LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQt a2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+b3BlcmF0ZSBhbiBNUExTLVRQIG5ldHdvcmsgd2l0 aG91dCB1c2luZyBhIGNvbnRyb2wgcGxhbmUuPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsNCjwvc3Bhbj5UaGlzIG1lYW5zDQo8P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBu cyA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIC8+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlHSFQ6 IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51 bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFu IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFz dC1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVT Ij50aGF0IGV4dGVybmFsIHN3aXRjaCBjb21tYW5kcywgZS5nLiwgRlMsIGNhbiBiZSB0cmFuc2Zl cnJlZCB0byB0aGU8L3NwYW4+PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUt SEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9n cmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93 LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5n PSJFTi1VUyI+cmVtb3RlIExhYmVsIEVkZ2UgUm91dGVyIChMRVIpIG9ubHkgYnkgdXNpbmcgdGhl IFBTQyBjb21tdW5pY2F0aW9uPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0 OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQ7IFRFWFQtQVVUT1NQQUNF OiBpZGVvZ3JhcGgtbnVtZXJpYzsgV09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9u OiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4w cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBw dCIgbGFuZz0iRU4tVVMiPmNoYW5uZWwgYW5kIHNob3VsZCBub3QgcmVseSBvbiB0aGUgcHJlc2Vu Y2Ugb2YgYSBjb250cm9sIHBsYW5lLjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjog bGVmdDsgTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFVVE9T UEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5h dGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3Bh biBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWls eTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6Dr lJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PT09IE5FVyA9PT08L2ZvbnQ+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20g MGNtIDEwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgV09SRC1CUkVBSzog a2VlcC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJsZWZ0Ij4NCjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3Jzsg bXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR 7J2AIOqzoOuUlSc7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPkFjY29yZGlu ZyB0byBTZWN0aW9uIDIuNCBvZiBSRkMgNTY1NCBbUkZDNTY1NF0gaXQgTVVTVCBiZSBwb3NzaWJs ZSB0bzwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlHSFQ6 IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51 bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFu IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFz dC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxh bmc9IkVOLVVTIj5vcGVyYXRlIGFuIE1QTFMtVFAgbmV0d29yayB3aXRob3V0IHVzaW5nIGEgY29u dHJvbCBwbGFuZS4gVGhpcyBtZWFuczwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjog bGVmdDsgTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFVVE9T UEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5h dGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtc2l6ZTog MTAuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZm9u dC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj50aGF0IHRoZSBQU0MgY29tbXVuaWNhdGlvbiBj aGFubmVsIGlzIHZlcnkgaW1wb3J0YW50IGZvciB0aGUgdHJhbnNmZXI8L3NwYW4+PC9wPg0KPHAg c3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAw Y20gMTBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBr ZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiPg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBt c28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5Hs nYAg6rOg65SVJzsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+b2YgZXh0ZXJu YWwgc3dpdGNoIGNvbW1hbmRzIChlLmcuLCBGUyksIGFuZCB0aGVzZSBjb21tYW5kcyBzaG91bGQg bm90PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDog MTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVt ZXJpYzsgV09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4i IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NvdXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFu Zz0iRU4tVVMiPnJlbHkgb24gdGhlIHByZXNlbmNlIG9mIGEgY29udHJvbCBwbGFuZS4gSW4gY29u c2VxdWVuY2UsIHRoZSBmYWlsdXJlPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBs ZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQ7IFRFWFQtQVVUT1NQ QUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgV09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0 aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1zaXplOiAx MC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mb250 LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPm9mIHRoZSBQU0MgY29tbXVuaWNhdGlvbiBjaGFu bmVsIGhhcyBoaWdoZXIgcHJpb3JpdHkgdGhhbiBGUy48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IlRF WFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdDsg VEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsg bXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZv bnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsg bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1z by1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPi0tLTwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBj bSAwY20gMTBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFL OiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9 Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5Hs nYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPlNlY3Rpb24gNC4z PC9zcGFuPjwvZm9udD48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlH SFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBo LW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3Jw aGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2Np aS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog J+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsg bXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5n PSJFTi1VUyI+WW91IHN1Z2dlc3RlZCDigJxzL2Jyb2tlbiwgdGhlIEZyZWV6ZSBjb21tYW5kLC9i cm9rZW4uDQogVGhlIEZyZWV6ZSBjb21tYW5kLC/igJ0uIDwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg c3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAw Y20gMTBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBXT1JELUJSRUFLOiBr ZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9Im1z by1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg 6rOg65SVJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhh bnNpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDq tbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPkJ1dCwgbXkgcmVhZGlu ZyBvZiB0d28gc2VwYXJhdGUgc2VudGVuY2VzDQogaXMgbm90IG9rLiBUaGUgZmlyc3Qgc2VudGVu Y2UgZG9lc27igJl0IHNlZW0gdG8gYmUgY29tcGxldGUuIFdvdWxkIHlvdSBwbGVhc2UgY2hlY2sg dGhpcyBhZ2Fpbj8NCjxiciBjbGVhcj0iYWxsIj4NCjxiciBjbGVhcj0iYWxsIj4NCi0tLTwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiAx NXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1l cmljOyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9u dC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5Hs nYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1i aWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4t VVMiPlNlY3Rpb25zIDkuMS4xLCBTZWN0aW9uIDkuMS4yLCBTZWN0aW9uDQogOS4xLjMuMiBhbmQg U2VjdGlvbiA5LjEuMy4zPC9zcGFuPjwvZm9udD48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjog bGVmdDsgTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFVVE9T UEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5h dGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAx MC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFz dC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfr p5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2Vy bmluZzogMHB0IiBsYW5nPSJFTi1VUyI+Rm9yIHRob3NlIGZvdXIgY29tbWVudHMmbmJzcDtvbiBT ZWN0aW9uIDksDQogSSBjYW4gdW5kZXJzdGFuZCB0aGUgY29uY2VybnMuIEluIG15IG9waW5pb24s IHRoZSBxdWVzdGlvbnMgZ2l2ZW4gaW4gdGhlIEFEIHJldmlldyBjb21tZW50cyBhcmUgdmVyeSB2 YWxpZCBhbmQgc2hvdWxkIGJlIGFuc3dlcmVkLiBJIHRoaW5rIHRoZSB0ZXh0IG5lZWRzIHRvIGJl IGNoYW5nZWQgcmF0aGVyIHNpZ25pZmljYW50bHkuIEkgd2lsbCBwcmVwYXJlIGEgbmV3IHRleHQg cHJvcG9zYWwgYW5kIGZ1cnRoZXIgY29tbXVuaWNhdGUgd2l0aCBBZHJpYW4uDQo8L3NwYW4+PC9m b250PjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsg TUFSR0lOOiAwY20gMGNtIDEwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsg V09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjxz cGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFt aWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqz oOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1m b250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXpl OiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6 ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQt a2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+LS0tPC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFS R0lOOiAwY20gMGNtIDEwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgV09S RC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjxzcGFu IHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5 OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuU lSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250 LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAx MC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFz dC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfr p5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2Vy bmluZzogMHB0IiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4g c3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6 ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SV JzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQt ZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEw LjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+un keydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJu aW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFu PjwvZm9udD48L3NwYW4+PC9mb250PiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBs ZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQ7IFRFWFQtQVVUT1NQ QUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgV09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0 aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEw LjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+un keydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJu aW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBz dHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTog J+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUn OyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1m YW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAu MHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR 7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5p bmc6IDBwdCIgbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjxzcGFuIHN0 eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAn 66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7 IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LWZh bWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj5CZXN0DQog cmVnYXJkcyw8L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVw dDsgTUFSR0lOOiAwY20gMGNtIDEwcHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJp YzsgV09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWFzY2lpLWZvbnQt ZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2A IOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlk aS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVT Ij48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1z aXplOiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28t ZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1p bHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZv bnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+ PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1m YW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg 6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMi Pjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNp emU6IDEwLjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWls eTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9u dC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48 c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZh bWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDq s6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGkt Zm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6 ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250 LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjxz cGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFt aWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqz oOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1m b250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXpl OiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6 ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQt a2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwv c3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9z cGFuPjwvZm9udD48L3NwYW4+PC9mb250PiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdO OiBsZWZ0OyBMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQ7IFRFWFQtQVVU T1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgV09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1wYWdp bmF0aW9uOiB3aWRvdy1vcnBoYW4iIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6 IDEwLjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTog J+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1r ZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3Bh biBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWls eTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6Dr lJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTog MTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn 66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtl cm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjxzcGFu IHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5 OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuU lSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250 LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAx MC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFz dC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfr p5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2Vy bmluZzogMHB0IiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4g c3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6 ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SV JzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQt ZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEw LjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+un keydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJu aW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBz dHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTog J+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUn OyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1m YW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+SmVvbmct ZG9uZzwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlHSFQ6IDE1cHQ7IE1B UkdJTjogMGNtIDBjbSAxMHB0OyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFdP UkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3Bh biBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWls eTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6Dr lJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTog MTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn 66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtl cm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjxzcGFu IHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5 OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuU lSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250 LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAx MC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFz dC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfr p5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2Vy bmluZzogMHB0IiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4g c3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6 ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SV JzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQt ZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEw LjBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ+un keydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJu aW5nOiAwcHQiIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBz dHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTog J+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUn OyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1m YW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1VUyI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAu MHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn66eR 7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5p bmc6IDBwdCIgbGFuZz0iRU4tVVMiPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+ PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48 L2ZvbnQ+PC9zcGFuPjwvZm9udD4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBj bSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPGJyPg0KPGJyPg0KPGRp diBpZD0iTWFpbFNpZ25TZW50Ij48YnI+DQo8L2Rpdj4NCjxociB0YWJpbmRleD0iLTEiPg0KPGI+ RnJvbSA6IDwvYj4mcXVvdDtBZHJpYW4gRmFycmVsJnF1b3Q7ICZsdDthZHJpYW5Ab2xkZG9nLmNv LnVrJmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAxNC0wMS0yMiAwNTo0OToyMSAoICYjNDM7MDk6 MDAgKTxicj4NCjxiPlRvIDogPC9iPidMb2EgQW5kZXJzc29uJyAmbHQ7bG9hQHBpLm51Jmd0Oywg bXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYyA6IDwvYj5tcGxz LWFkc0B0b29scy5pZXRmLm9yZyAmbHQ7bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmcmZ3Q7LCBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7 LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0 Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdCA6IDwv Yj5bbXBsc10gQUQgcmV2aWV3IDogd29ya2luZyBncm91cCBsYXN0IGNhbGwgZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHUtMDE8YnI+DQo8YnI+DQpIaSw8YnI+DQo8YnI+DQpDb25ncmF0dWxhdGlv bnMgb24gc2FpbGluZyBhIHZlcnkgZGlmZmljdWx0IGNvdXJzZSBiZXR3ZWVuIHRlY2huaWNhbCBh bmQ8YnI+DQpwb2xpdGljYWwuIFlvdSBoYXZlIHByb2R1Y2VkIGEgcmVhZGFibGUgYW5kIGNvaGVy ZW50IGRvY3VtZW50Ljxicj4NCjxicj4NCkkgaGF2ZSBjb25kdWN0ZWQgbXkgdXN1YWwgQUQgcmV2 aWV3IG9mIHRoaXMgZG9jdW1lbnQgZWFybHkgKGkuZS4sIGR1cmluZzxicj4NCndvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsKSBvbiByZXF1ZXN0IG9mIHRoZSB3b3JraW5nIGdyb3VwIGNoYWlycy4gVGhl PGJyPg0KcHVycG9zZSBvZiBteSByZXZpZXcgaXMgdG8gY2F0Y2ggYW5kIGNsZWFuIHVwIGFueSBp c3N1ZXMgdGhhdCBtaWdodDxicj4NCm90aGVyd2lzZSBiZSBmb3VuZCBkdXJpbmcgSUVURiBsYXN0 IGNhbGwgYW5kIElFU0cgZXZhbHVhdGlvbi4gVGh1cywgdGhlPGJyPg0KaW50ZW50aW9uIGlzIHRv IHByb2R1Y2UgYSBoaWdoZXIgcXVhbGl0eSBkb2N1bWVudCBhbmQgZW5zdXJlIHNtb290aGVyPGJy Pg0KcGFzc2FnZSB0aHJvdWdoIHRob3NlIGxhdGVyIHN0YWdlcy4gQXMgc2hvdWxkIGJlIG9idmlv dXMsIGJ5IHJldmlld2luZyA8YnI+DQp0aGUgZG9jdW1lbnQgYmVmb3JlIGl0IGhhcyBzZWVuIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGFuZCBiZWVuIHVwZGF0ZWQ8YnI+DQpJIG1heSBoYXZlIGZv dW5kIG1vcmUgaXNzdWVzIGFuZCBjb25jZXJucyB0aGFuIEkgd291bGQgaGF2ZSBkb25lIGhhZCBJ PGJyPg0KcmV2aWV3ZWQgaXQgbGF0ZXIuPGJyPg0KPGJyPg0KTmV2ZXJ0aGVsZXNzLCBJIGZpbmQg dGhlIGRvY3VtZW50IHRvIGJlIGJhc2ljYWxseSBzb3VuZC4gVGhlcmUgYXJlIHF1aXRlPGJyPg0K YSBsb3Qgb2YgY29tbWVudHMgYmVsb3csIGJ1dCB0aGV5IGFyZSBhbG1vc3QgZXhjbHVzaXZlbHkg ZWRpdG9yaWFsIGluIDxicj4NCm5hdHVyZS4gVGhlIGVkaXRvcmlhbCBjb21tZW50cyBmYWxsIGlu dG8gdGhyZWUgY2F0ZWdvcmllczo8YnI+DQo8YnI+DQotIHB1cmUgbml0cyAoc2hvdWxkIGJlIGVu dGlyZWx5IHVuY29udGVudGlvdXMpPGJyPg0KLSBpc3N1ZXMgb2YgY2xhcml0eSBhbmQgcmVhZGFi aWxpdHkgKGhvcGVmdWxseSB0aGVzZSBhcmUgYWxzbyBlYXN5IHRvPGJyPg0KYWNjZXB0LCBidXQg cGxlYXNlIGNoZWNrIHRoYXQgbXkgJnF1b3Q7Y2xlYW5pbmcgdXAmcXVvdDsgb2YgeW91ciB0ZXh0 IGhhcyA8YnI+DQpwcmVzZXJ2ZWQgdGhlIG1lYW5pbmcgeW91IGludGVuZGVkKTxicj4NCi0gaXNz dWVzIG9mIHNwaW4vcG9saXRpY3MgKHNvbWV0aW1lcyBzYXlpbmcgdGhlIHNhbWUgdGhpbmcgaW4g c2xpZ2h0bHk8YnI+DQpkaWZmZXJlbnQgd29yZHMgY2FuIG1ha2UgZXZlcnlvbmUgaGFwcHkpPGJy Pg0KPGJyPg0KSSB0aGluayBJIGZvdW5kIG9ubHkgdHdvIHRlY2huaWNhbCBpc3N1ZXMgLSBpbiBT ZWN0aW9uIDkuMS4xIGFuZDxicj4NCjkuMS4zLjMuPGJyPg0KPGJyPg0KSW4gYWxsIGNhc2VzIEkg aGF2ZSB0cmllZCB0byBzdWdnZXN0IGFsdGVybmF0aXZlIHdvcmRpbmcgc28gdGhhdCB5b3UgPGJy Pg0KZG9uJ3QgaGF2ZSB0byBndWVzcyB3aGF0IEkgbWVhbi4gQnV0IHBsZWFzZSAocGxlYXNlLCBw bGVhc2UpIGRvIG5vdCA8YnI+DQpmZWVsIHRoYXQgSSBhbSBpbnNpc3Rpbmcgb24gYW55IG9mIHRo ZXNlIGNoYW5nZXMgb3Igb24gbXkgcHJlY2lzZSB3b3Jkczo8YnI+DQpJIGFtIGp1c3QgdHJ5aW5n IHRvIHBvbGlzaCBhbmQgbW92ZSB0aGlzIGRvY3VtZW50IGFsb25nOyBldmVyeXRoaW5nIGlzPGJy Pg0Kb3BlbiBmb3IgZGlzY3Vzc2lvbi48YnI+DQo8YnI+DQpPbmUgbGFzdCBwb2ludDogaWYgc29t ZSBlbnRodXNpYXN0aWMgbmF0aXZlIHNwZWFrZXIgd2FzIHRvIHJldmlldyBhbmQ8YnI+DQplZGl0 IHRoZSBmaW5hbCByZXZpc2lvbiAocGVyaGFwcyBpbiByZXR1cm4gZm9yIGJlZXIgb3IgYW4gPGJy Pg0KYWNrbm93bGVkZ2VtZW50KSB0aGV5IHdvdWxkIGJlIGRvaW5nIHVzIGFsbCBhIGdyZWF0IGZh dm9yLiBJIGhhdmUgbm90PGJyPg0KcG9pbnRlZCBvdXQgZXZlcnkgbWlub3IgaXNzdWUgb2YgbGFu Z3VhZ2UgaW4gbXkgcmV2aWV3Ljxicj4NCjxicj4NClRoYW5rcyBmb3IgdGhlIHdvcmsuPGJyPg0K PGJyPg0KQWRyaWFuPGJyPg0KPGJyPg0KPT09PGJyPg0KPGJyPg0KVGhlIEFic3RyYWN0IGFuZCB0 aGUgSW50cm9kdWN0aW9uIHNheTo8YnI+DQo8YnI+DQpUd28gbW9kZXMgYXJlIGRlZmluZWQgaW48 YnI+DQp0aGlzIGRvY3VtZW50OiBQcm90ZWN0aW9uIFN0YXRlIENvb3JkaW5hdGlvbiAoUFNDKSBt b2RlIGFuZCBBdXRvbWF0aWM8YnI+DQpQcm90ZWN0aW9uIFN3aXRjaGluZyAoQVBTKSBtb2RlLjxi cj4NCjxicj4NClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBiZWhhdmlvciBvZiB0aGUgUFND IHByb3RvY29sIGluY2x1ZGluZzxicj4NCnByaW9yaXR5IGxvZ2ljIGFuZCBzdGF0ZSBtYWNoaW5l IHdoZW4gYWxsIHRoZSBjYXBhYmlsaXRpZXMgYXNzb2NpYXRlZDxicj4NCndpdGggdGhlIEFQUyBt b2RlIGFyZSBlbmFibGVkLjxicj4NCjxicj4NClRoaXMgbGVhdmVzIHRoZSBxdWVzdGlvbjogd2hl cmUgaXMgdGhlIHByb3RvY29sIGluY2x1ZGluZyBwcmlvcml0eSBsb2dpYyA8YnI+DQphbmQgc3Rh dGUgbWFjaGluZSBkZWZpbmVkIGZvciB0aGUgUFNDIG1vZGU/IEkgaG9wZSB0aGUgYW5zd2VyIGlz ICZxdW90O2luIDxicj4NClJGQyA2Mzc4LCBpbiB3aGljaCBjYXNlIHlvdSBjYW4gZWFzaWx5IGFk ZCBhIG5vZGUgc3VjaCBhczo8YnI+DQo8YnI+DQpUaGUgUFNDIHByb3RvY29sIGJlaGF2aW9yIGZv ciB0aGUgUFNDIG1vZGUgaXMgYXMgZGVmaW5lZCBpbiBSRkMgNjM3OC48YnI+DQo8YnI+DQotLS08 YnI+DQo8YnI+DQpUaGUgbGFzdCBwYXJhZ3JhcGggb2YgdGhlIEludHJvZHVjdGlvbiByZWFkczxi cj4NCjxicj4NClRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMgNjM3OCBpbiB0aGF0IHRoZSBjYXBh YmlsaXR5IGFkdmVydGlzZW1lbnQ8YnI+DQptZXRob2QgZGVmaW5lZCBoZXJlIGlzIGFuIGFkZGl0 aW9uIHRvIHRoYXQgZG9jdW1lbnQuIEZvciBhbiBleGlzdGluZzxicj4NCmltcGxlbWVudGF0aW9u IG9mIFJGQyA2Mzc4LCBpdCBpcyByZWNvbW1lbmRlZCB0byBiZSB1cGRhdGVkIHdpdGggdGhlPGJy Pg0KYnVnLWZpeGVzIGluIFtJLUQuaWV0Zi1tcGxzLXBzYy11cGRhdGVzXSBhbmQgdGhlIGNhcGFi aWxpdHk8YnI+DQphZHZlcnRpc2VtZW50IGluIHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KSSBz dWdnZXN0IHJlcGxhY2luZyB0aGlzIHdpdGggdGhlIHRleHQgYmVsb3cuIFRoZXJlIGFyZSB0d28g cmVhc29ucyBmb3I8YnI+DQpteSBzdWdnZXN0ZWQgY2hhbmdlczo8YnI+DQo8YnI+DQoxLiBJdCBs b29rcyB2ZXJ5IG9kZCBmb3IgdGhpcyBkb2N1bWVudCB0byByZWNvbW1lbmQgdXNpbmcgY2hhbmdl cyBpbiA8YnI+DQphbm90aGVyIGRvY3VtZW50LiBUaGUgcmVzdWx0IG9mIHN1Y2ggYSBzdGF0ZW1l bnQgaXMgbGlrZWx5IHRvIGJlIGE8YnI+DQpyZXF1aXJlbWVudCB0aGF0IHlvdSBidW5kbGUgdGhl IHR3byBkb2N1bWVudHMgdG9nZXRoZXIuIEkgdGhpbmsgdGhhdDxicj4NCltJLUQuaWV0Zi1tcGxz LXBzYy11cGRhdGVzXSBjYW4gc3RhbmQgb24gaXRzIG93bi48YnI+DQo8YnI+DQoyLiBXaGlsZSB5 b3UgY2FuIHJlY29tbWVuZCB0aGF0IHRoZSBpbnN0YWxsZWQgYmFzZSBpcyB1cGRhdGVkLCB5b3Ug PGJyPg0KY2Fubm90IGZvcmNlIGl0IHRvIGhhcHBlbi4gSXQgaXMsIHRoZXJlZm9yZSwgdXNlZnVs IHRvIGRyYXcgYXR0ZW50aW9uPGJyPg0KdG8gdGhlIGltcG9ydGFudCBiYWNrd2FyZCBjb21wYXRp YmlsaXR5IHRleHQgeW91IGhhdmUgaW4gU2VjdGlvbiA5LjMuPGJyPg0KPGJyPg0KU28gbXkgc3Vn Z2VzdGVkIHRleHQgaXM6PGJyPg0KPGJyPg0KVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA2Mzc4 IGJ5IGFkZGluZyBhIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudDxicj4NCm1lY2hhbmlzbS4gSXQg aXMgcmVjb21tZW5kZWQgdGhhdCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgUkZDPGJyPg0K NjM3OCBzaG91bGQgYmUgdXBkYXRlZCB0byBzdXBwb3J0IHRoaXMgY2FwYWJpbGl0eSwgaG93ZXZl ciB0aGUgaXNzdWUgPGJyPg0Kb2YgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBpcyBkZXNjcmliZWQ8YnI+DQppbiBTZWN0aW9uIDkuMy48YnI+DQo8 YnI+DQotLS08YnI+DQo8YnI+DQpTZWN0aW9uIDQ8YnI+DQo8YnI+DQpJbiB0aGlzIGRvY3VtZW50 LCB0aGUgcHJpb3JpdGllcyBvZiBGUyBhbmQgU0YtUCBhcmUgc3dhcHBlZCBhbmQgdGhlPGJyPg0K cHJpb3JpdHkgb2YgQ2xlYXIgU0YgKFNGYykgaXMgcmFpc2VkLiBJbiBhZGRpdGlvbiB0byB0aGUg cHJpb3JpdHk8YnI+DQptb2RpZmljYXRpb24sIHRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUg dXNlIG9mIEZyZWV6ZSBjb21tYW5kIGluPGJyPg0KQXBwZW5kaXggQy4gVGhlIHJlYXNvbnMgZm9y IHRoZXNlIGNoYW5nZXMgYXJlIGV4cGxhaW5lZCBpbiB0aGU8YnI+DQpmb2xsb3dpbmcgc3ViLXNl Y3Rpb25zIGZyb20gdGVjaG5pY2FsIGFuZCBuZXR3b3JrIG9wZXJhdGlvbmFsPGJyPg0KYXNwZWN0 cy48YnI+DQo8YnI+DQpUaGUgaXNzdWUgSSBoYXZlIHdpdGggdGhpcyB0ZXh0IGlzIHRoYXQgYSBz d2FwIGhhcyB0byBiZSByZWxhdGl2ZSB0byA8YnI+DQpzb21ldGhpbmcuIFNvIHdlIHNob3VsZCBt YWtlIGl0IGNsZWFyIHdoYXQgaXMgaW4gNjM3OCBhbmQgdGhlbiBkZXNjcmliZTxicj4NCndoYXQg dGhpcyBkb2N1bWVudCBkb2VzLi4uPGJyPg0KPGJyPg0KW1JGQzYzNzhdIGRlZmluZXMgdGhlIHBy aW9yaXR5IG9mIEZTIHRvIGJlIGhpZ2hlciB0aGFuIHRoYXQgb2YgU0YtUC48YnI+DQpUaGF0IGRv Y3VtZW50IGFsc28gZGVmaW5lcyB0aGUgcHJpb3JpdHkgb2YgQ2xlYXIgU0YgKFNGYykgdG8gYmUg bG93Ljxicj4NClRoaXMgZG9jdW1lbnQgdGhlIGRlZmluZXMgdGhlIFByaW9yaXR5IE1vZGlmaWNh dGlvbiBjYXBhYmlsaXR5PGJyPg0Kd2hlcmVieSB0aGUgcHJpb3JpdGllcyBvZiBGUyBhbmQgU0Yt UCBhcmUgc3dhcHBlZCBhbmQgdGhlIHByaW9yaXR5IG9mPGJyPg0KQ2xlYXIgU0YgKFNGYykgaXMg cmFpc2VkLiBJbiBhZGRpdGlvbiwgdGhpcyBjYXBhYmlsaXR5IGludHJvZHVjZXMgPGJyPg0KdGhl IHVzZSBvZiBGcmVlemUgY29tbWFuZCBhcyBkZXNjcmliZWQgaW4gQXBwZW5kaXggQy4gVGhlIHJl YXNvbnMgPGJyPg0KZm9yIHRoZXNlIGNoYW5nZXMgYXJlIGV4cGxhaW5lZCBpbiB0aGUgZm9sbG93 aW5nIHN1Yi1zZWN0aW9ucyBmcm9tIDxicj4NCnRlY2huaWNhbCBhbmQgbmV0d29yayBvcGVyYXRp b25hbCBhc3BlY3RzLjxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NClNlY3Rpb24gNC4xPGJyPg0K PGJyPg0KTm8gdGVjaG5pY2FsIGNoYW5nZSwganVzdCBlYXNlIG9mIHJlYWRpbmcuPGJyPg0KPGJy Pg0KT0xEPGJyPg0KU2V0dGluZyB0aGUgcHJpb3JpdHkgb2YgYW55IGlucHV0IHRoYXQgaXMgc3Vw cG9zZWQgdG8gYmUgc2lnbmFsZWQgdG88YnI+DQp0aGUgb3RoZXIgZW5kIHRvIGJlIGhpZ2hlciB0 aGFuIHRoYXQgb2YgU0YtUCBjYW4gcmVzdWx0IGluPGJyPg0KdW5wcmVkaWN0YWJsZSBwcm90ZWN0 aW9uIHN3aXRjaGluZyBzdGF0ZSwgd2hlbiB0aGUgcHJvdGVjdGlvbiBwYXRoPGJyPg0KaGFzIGZh aWxlZCBhbmQgY29uc2VxdWVudGx5IHRoZSBQU0MgY29tbXVuaWNhdGlvbiBzdG9wcGVkLjxicj4N Ck5FVzxicj4NCldoZW4gdGhlIHByb3RlY3Rpb24gcGF0aCBmYWlscyBQU0MgY29tbXVuaWNhdGlv biBtYXkgc3RvcCBhcyBhIDxicj4NCnJlc3VsdC4gSW4gdGhpcyBjYXNlLCBpZiBhbnkgaW5wdXQg dGhhdCBpcyBzdXBwb3NlZCB0byBiZSBzaWduYWxlZCB0bzxicj4NCnRoZSBvdGhlciBlbmQgaGFz IGEgaGlnaGVyIHByaW9yaXR5IHRoYXQgU0YtUCB0aGVuIHRoaXMgY2FuIHJlc3VsdCBpbjxicj4N CnVucHJlZGljdGFibGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgc3RhdGUuPGJyPg0KRU5EPGJyPg0K PGJyPg0KLS0tPGJyPg0KPGJyPg0KU2VjdGlvbiA0LjE8YnI+DQo8YnI+DQpBY2NvcmRpbmcgdG8g U2VjdGlvbiAyLjQgb2YgUkZDIDU2NTQgW1JGQzU2NTRdIGl0IE1VU1QgYmUgcG9zc2libGUgdG88 YnI+DQpvcGVyYXRlIGFuIE1QTFMtVFAgbmV0d29yayB3aXRob3V0IHVzaW5nIGEgY29udHJvbCBw bGFuZS4gVGhpcyBtZWFuczxicj4NCnRoYXQgZXh0ZXJuYWwgc3dpdGNoIGNvbW1hbmRzLCBlLmcu LCBGUywgY2FuIGJlIHRyYW5zZmVycmVkIHRvIHRoZTxicj4NCnJlbW90ZSBMYWJlbCBFZGdlIFJv dXRlciAoTEVSKSBvbmx5IGJ5IHVzaW5nIHRoZSBQU0MgY29tbXVuaWNhdGlvbjxicj4NCmNoYW5u ZWwgYW5kIHNob3VsZCBub3QgcmVseSBvbiB0aGUgcHJlc2VuY2Ugb2YgYSBjb250cm9sIHBsYW5l Ljxicj4NCjxicj4NClRoaXMgcGFyYWdyYXBoIGhhcyBzZXZlcmFsIGlzc3Vlcy48YnI+DQo8YnI+ DQoxLiBJdCBpcyBub3QgdHJ1ZSEgTm90IHVzaW5nIGEgY29udHJvbCBwbGFuZSBsZWF2ZXMgdGhl IG9wdGlvbiBvZiBQU0MgYXM8YnI+DQp5b3Ugc2F5LCBhbmQgYWxzbyBsZWF2ZXMgdGhlIG9wdGlv biBvZiB0aGUgbWFuYWdlbWVudCBwbGFuZS4gSW5kZWVkLDxicj4NCnRoZSBQU0MgY29tbXVuaWNh dGlvbiBjaGFubmVsIGlzIHByb2JhYmx5IGEgc3BlY2lhbCBjYXNlIG9mIHRoZSBpbi08YnI+DQpi YW5kIE9BTSBjaGFubmVsLjxicj4NCjxicj4NCjIuIFRoaXMgc3RhdGVtZW50IGRvZXMgbm90IGFw cGVhciB0byBoYXZlIGFueXRoaW5nIHRvIGRvIHdpdGggc3dhcHBpbmcgPGJyPg0KdGhlIHByaW9y aXRpZXMgb2YgRlMgYW5kIFNGLVAuPGJyPg0KPGJyPg0KSSBzdWdnZXN0IHRoYXQgaWYgeW91IGNh biBzaG93IGhvdyB0aGlzIHN0YXRlbWVudCBpcyByZWxhdGVkIHRvIHRoZSBzd2FwPGJyPg0Kb2Yg cHJpb3JpdGllcyB5b3Ugc2hvdWxkIGFkZCBpdC4gSW4gdGhhdCBjYXNlIHlvdSBzaG91bGQgYWxz byBzYXkuLi48YnI+DQpUaGlzIG1lYW5zPGJyPg0KdGhhdCBleHRlcm5hbCBzd2l0Y2ggY29tbWFu ZHMsIGUuZy4sIEZTLCBjYW4gYmUgdHJhbnNmZXJyZWQgdG8gdGhlPGJyPg0KcmVtb3RlIExhYmVs IEVkZ2UgUm91dGVyIChMRVIpIG9ubHkgYnkgdXNpbmcgdGhlIG1hbmFnZW1lbnQgcGxhbmUgb3I8 YnI+DQp0aGUgaW4tYmFuZCBPQU0gY2hhbm5lbCBhbmQgc2hvdWxkIG5vdCByZWx5IG9uIHRoZSBw cmVzZW5jZSBvZiBhIDxicj4NCmNvbnRyb2wgcGxhbmUuIFRoZSB1c2Ugb2YgdGhlIE9BTSBjaGFu bmVsIGFzIHVzZWQgYnkgUFNDIG1lc3NhZ2VzIGlzPGJyPg0KY29uc2lkZXJlZCBtb3JlIGFwcHJv cHJpYXRlIGZvciBjb2hlcmVuY2Ugd2l0aCBvdGhlciBQU0MgbWVzc2FnZXMuPGJyPg0KSWYsIG9u IHRoZSBvdGhlciBoYW5kLCB5b3UgY2FuJ3Qgc2hvdyBob3cgdGhpcyBzdGF0ZW1lbnQgaXMgcmVs ZXZhbnQgZm9yPGJyPg0KdGhlIHN3YXBwaW5nIG9mIHRoZSBwcmlvcml0aWVzLCBJIHN1Z2dlc3Qg cmVtb3ZpbmcgdGhlIHBhcmFncmFwaC48YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQpTZWN0aW9u IDQuMTxicj4NCjxicj4NCkkgdGhpbmsgdGhpcyBvbmUgaXMgbWFpbmx5IHBvbGl0aWNhbCA6LSk8 YnI+DQo8YnI+DQpPTEQ8YnI+DQpBcyB0aGUgcHJpb3JpdHkgb2YgU0YtUCBoYXMgYmVlbiBoaWdo ZXIgdGhhbiBGUyBpbiBvdGhlciB0cmFuc3BvcnQ8YnI+DQpuZXR3b3Jrcywgc3VjaCBhcyBTREgs IE9UTiBhbmQgRXRoZXJuZXQgdHJhbnNwb3J0IG5ldHdvcmtzLCBmb3I8YnI+DQpuZXR3b3JrIG9w ZXJhdG9ycyBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgTVBMUy1UUCBwcm90ZWN0aW9uPGJyPg0K c3dpdGNoaW5nIHByZXNlcnZlcyB0aGUgbmV0d29yayBvcGVyYXRpb24gYmVoYXZpb3IgdG8gd2hp Y2ggbmV0d29yazxicj4NCm9wZXJhdG9ycyBoYXZlIGJlY29tZSBhY2N1c3RvbWVkLjxicj4NCk5F Vzxicj4NCkluIG90aGVyIHRyYW5zcG9ydCBuZXR3b3JrcyAoc3VjaCBhcyBTREgsIE9UTiwgYW5k IEV0aGVybmV0IHRyYW5zcG9ydDxicj4NCm5ldHdvcmtzKSB0aGUgcHJpb3JpdHkgb2YgU0YtUCBp cyBiZWVuIGhpZ2hlciB0aGFuIEZTLiBJdCBpcyA8YnI+DQp0aGVyZWZvcmUgaW1wb3J0YW50IHRv IG9mZmVyIG5ldHdvcmsgb3BlcmF0b3JzIHRoZSBvcHRpb24gb2YgaGF2aW5nIDxicj4NCnRoZSBz YW1lIGJlaGF2aW9yIGluIHRoZWlyIE1QTFMtVFAgbmV0d29yayBzbyB0aGF0IHRoZXkgY2FuIGhh dmUgdGhlPGJyPg0Kc2FtZSBvcGVyYXRpb25hbCBwcm90ZWN0aW9uIHN3aXRjaGluZyBiZWhhdmlv ciB0byB3aGljaCB0aGV5IGhhdmU8YnI+DQpiZWNvbWUgYWNjdXN0b21lZC48YnI+DQpFTkQ8YnI+ DQo8YnI+DQotLS08YnI+DQo8YnI+DQpTZWN0aW9uIDQuMzxicj4NCjxicj4NCnMvYnJva2VuLCB0 aGUgRnJlZXplIGNvbW1hbmQsL2Jyb2tlbi4gVGhlIEZyZWV6ZSBjb21tYW5kLC88YnI+DQo8YnI+ DQotLS08YnI+DQo8YnI+DQpTZWN0aW9uIDQuNDxicj4NCjxicj4NCkFzIHlvdSBoYXZlIGFscmVh ZHkgZXN0YWJsaXNoZWQgZWFybGllciBpbiB0aGlzIGRvY3VtZW50LCB0aGU8YnI+DQptb2RpZmlj YXRpb25zIHRvIDYzNzggYXJlIHRoZSBhZGRpdGlvbiBvZiB0aGUgY2FwYWJpbGl0aWVzIDxicj4N CmFkdmVydGlzZW1lbnQuIFNvIEkgdGhpbmsgdGhlIGxhbmd1YWdlIHVzZWQgaW4gdGhpcyBzZWN0 aW9uIGlzIHRvbzxicj4NCnN0cm9uZy4gSSBzdWdnZXN0Li4uPGJyPg0KPGJyPg0KT0xEPGJyPg0K NC40LiBNb2RpZmljYXRpb25zIHRvIFJGQyA2Mzc4PGJyPg0KPGJyPg0KVGhlIGxpc3Qgb2YgbG9j YWwgcmVxdWVzdHMgaW4gb3JkZXIgb2YgcHJpb3JpdHkgU0hBTEwgYmUgbW9kaWZpZWQgYXM8YnI+ DQpmb2xsb3dzOjxicj4NCjxicj4NCihmcm9tIGhpZ2hlciB0byBsb3dlcik8YnI+DQo8YnI+DQpv IENsZWFyIFNpZ25hbCBGYWlsPGJyPg0KPGJyPg0KbyBTaWduYWwgRmFpbCBvbiBQcm90ZWN0aW9u IHBhdGg8YnI+DQo8YnI+DQpvIEZvcmNlZCBTd2l0Y2g8YnI+DQo8YnI+DQpvIFNpZ25hbCBGYWls IG9uIFdvcmtpbmcgcGF0aDxicj4NCjxicj4NClRoZSBjaGFuZ2Ugb2YgdGhlIFBTQyBDb250cm9s IGxvZ2ljIGluY2x1ZGluZyB0aGUgc3RhdGUgbWFjaGluZSBkdWU8YnI+DQp0byB0aGlzIHByaW9y aXR5IG1vZGlmaWNhdGlvbiBpcyBpbmNvcnBvcmF0ZWQgaW4gdGhlIFBTQyBDb250cm9sPGJyPg0K bG9naWMgZGVzY3JpcHRpb24gaW4gU2VjdGlvbiAxMCBhbmQgU2VjdGlvbiAxMSB3aGVuIGFsbCB0 aGU8YnI+DQpjYXBhYmlsaXRpZXMgYXJlIGVuYWJsZWQuPGJyPg0KTkVXPGJyPg0KNC40LiBQcm9j ZWR1cmVzIGluIFN1cHBvcnQgb2YgQ2FwYWJpbGl0eSAxPGJyPg0KPGJyPg0KV2hlbiB0aGlzIGNh cGFiaWxpdHkgaXMgaW4gdXNlIHRoZSBsaXN0IG9mIGxvY2FsIHJlcXVlc3RzIGluIG9yZGVyIG9m PGJyPg0KcHJpb3JpdHkgU0hBTEwgYmUgYXMgZm9sbG93czo8YnI+DQo8YnI+DQooZnJvbSBoaWdo ZXN0IHRvIGxvd2VzdCk8YnI+DQo8YnI+DQpvIENsZWFyIFNpZ25hbCBGYWlsPGJyPg0KPGJyPg0K byBTaWduYWwgRmFpbCBvbiBQcm90ZWN0aW9uIHBhdGg8YnI+DQo8YnI+DQpvIEZvcmNlZCBTd2l0 Y2g8YnI+DQo8YnI+DQpvIFNpZ25hbCBGYWlsIG9uIFdvcmtpbmcgcGF0aDxicj4NCjxicj4NClRo aXMgcmVxdWlyZXMgZGlmZmVyZW50IFBTQyBjb250cm9sIGxvZ2ljIChpbmNsdWRpbmcgdGhlIHN0 YXRlIDxicj4NCm1hY2hpbmUpIGNvbXBhcmVkIHRvIHRoYXQgc2hvd24gaW4gW1JGQzYzNzhdLiBT ZWN0aW9ucyAxMCBhbmQgMTE8YnI+DQpzaG93IHRoZSBQU0MgY29udHJvbCBsb2dpYyBhbmQgc3Rh dGUgbWFjaGluZSB3aGVuIGFsbCBvZiB0aGUgPGJyPg0KY2FwYWJpbGl0aWVzIGluIEFQUyBtb2Rl IGFyZSBlbmFibGVkLjxicj4NCkVORDxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NClNlY3Rpb24g NTxicj4NCjxicj4NClNpbWlsYXIgY2hhbmdlcyB0byB0aG9zZSBwcm9wb3NlZCBmb3IgU2VjdGlv bnMgNC4xIGFuZCA0LjQuPGJyPg0KPGJyPg0KT0xEPGJyPg0KSG93ZXZlciwgUFNDIHByb3RvY29s IGRlZmluZWQgaW4gUkZDIDYzNzggW1JGQzYzNzhdIHN1cHBvcnRzIHRoaXM8YnI+DQpvcGVyYXRp b24gb25seSB3aGVuIHJlY292ZXJpbmcgZnJvbSBhIGRlZmVjdCBjb25kaXRpb24sIGJ1dCBkb2Vz IG5vdDxicj4NCm9wZXJhdGUgYXMgbm9uLXJldmVydGl2ZSB3aGVuIGFuIG9wZXJhdG9yJ3Mgc3dp dGNoLW92ZXIgY29tbWFuZCBzdWNoPGJyPg0KYXMgRlMgb3IgTWFudWFsIFN3aXRjaCAoTVMpIGlz IGNsZWFyZWQuIFRvIGJlIGFsaWduZWQgd2l0aCBsZWdhY3k8YnI+DQp0cmFuc3BvcnQgbmV0d29y ayBiZWhhdmlvciBhbmQgUkZDIDQ0MjcsIGEgbm9kZSBzaG91bGQgZ28gaW50byB0aGU8YnI+DQpE by1ub3QtUmV2ZXJ0IChETlIpIHN0YXRlIG5vdCBvbmx5IHdoZW4gYSBmYWlsdXJlIGNvbmRpdGlv biBvbiB0aGU8YnI+DQp3b3JraW5nIHBhdGggaXMgY2xlYXJlZCBidXQgYWxzbyB3aGVuIGFuIG9w ZXJhdG9yIGNvbW1hbmQgcmVxdWVzdGluZzxicj4NCnN3aXRjaC1vdmVyIGlzIGNsZWFyZWQuPGJy Pg0KPGJyPg0KVGhlIGNoYW5nZSBvZiB0aGUgUFNDIENvbnRyb2wgbG9naWMgaW5jbHVkaW5nIHRo ZSBzdGF0ZSBtYWNoaW5lIGR1ZTxicj4NCnRvIHRoZSBtb2RpZmljYXRpb24gb2Ygbm9uLXJldmVy dGl2ZSBvcGVyYXRpb24gaXMgaW5jb3Jwb3JhdGVkIGludG88YnI+DQp0aGUgUFNDIENvbnRyb2wg bG9naWMgZGVzY3JpcHRpb24gaW4gU2VjdGlvbiAxMCBhbmQgU2VjdGlvbiAxMSB3aGVuPGJyPg0K YWxsIHRoZSBjYXBhYmlsaXRpZXMgYXJlIGVuYWJsZWQuPGJyPg0KTkVXPGJyPg0KSG93ZXZlciwg dGhlIFBTQyBwcm90b2NvbCBkZWZpbmVkIGluIFJGQyA2Mzc4IFtSRkM2Mzc4XSBzdXBwb3J0cyB0 aGlzPGJyPg0Kb3BlcmF0aW9uIG9ubHkgd2hlbiByZWNvdmVyaW5nIGZyb20gYSBkZWZlY3QgY29u ZGl0aW9uOiBpdCBkb2VzIG5vdDxicj4NCnN1cHBvcnQgdGhlIG5vbi1yZXZlcnRpdmUgZnVuY3Rp b24gd2hlbiBhbiBvcGVyYXRvcidzIHN3aXRjaC1vdmVyIDxicj4NCmNvbW1hbmQsIHN1Y2ggYXMg RlMgb3IgTWFudWFsIFN3aXRjaCAoTVMpLCBpcyBjbGVhcmVkLiBUbyBiZSBhbGlnbmVkPGJyPg0K d2l0aCB0aGUgYmVoYXZpb3VyIGluIG90aGVyIHRyYW5zcG9ydCBuZXR3b3JrcyBhbmQgdG8gYmUg Y29uc2lzdGVudCA8YnI+DQp3aXRoIFJGQyA0NDI3LCBhIG5vZGUgc2hvdWxkIGdvIGludG8gdGhl IERvLW5vdC1SZXZlcnQgKEROUikgc3RhdGUgPGJyPg0Kbm90IG9ubHkgd2hlbiBhIGZhaWx1cmUg Y29uZGl0aW9uIG9uIHRoZSB3b3JraW5nIHBhdGggaXMgY2xlYXJlZCwgYnV0PGJyPg0KYWxzbyB3 aGVuIGFuIG9wZXJhdG9yIGNvbW1hbmQgdGhhdCByZXF1ZXN0ZWQgc3dpdGNoLW92ZXIgaXMgY2xl YXJlZC48YnI+DQo8YnI+DQpUaGlzIHJlcXVpcmVzIGRpZmZlcmVudCBQU0MgY29udHJvbCBsb2dp YyAoaW5jbHVkaW5nIHRoZSBzdGF0ZSA8YnI+DQptYWNoaW5lKSBjb21wYXJlZCB0byB0aGF0IHNo b3duIGluIFtSRkM2Mzc4XS4gU2VjdGlvbnMgMTAgYW5kIDExPGJyPg0Kc2hvdyB0aGUgUFNDIGNv bnRyb2wgbG9naWMgYW5kIHN0YXRlIG1hY2hpbmUgd2hlbiBhbGwgb2YgdGhlIDxicj4NCmNhcGFi aWxpdGllcyBpbiBBUFMgbW9kZSBhcmUgZW5hYmxlZC48YnI+DQpFTkQ8YnI+DQo8YnI+DQotLS08 YnI+DQo8YnI+DQpTZWN0aW9uIDYuMTxicj4NCjxicj4NCk9MRDxicj4NCkNoYW5naW5nIHRoZSBu b24tcmV2ZXJ0aXZlIG9wZXJhdGlvbjxicj4NCk5FVzxicj4NCkNoYW5naW5nIHRoZSBub24tcmV2 ZXJ0aXZlIG9wZXJhdGlvbiBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1PGJyPg0KRU5EPGJyPg0K PGJyPg0KLS0tPGJyPg0KPGJyPg0KU2VjdGlvbiA2LjE8YnI+DQo8YnI+DQpPTEQ8YnI+DQpNYW51 YWwgU3dpdGNoLW92ZXIgZm9yIHJlY292ZXJ5IExTUC9zcGFuIGNvbW1hbmQsIGRlZmluZWQgaW4g UkZDIDQ0Mjc8YnI+DQpbUkZDNDQyN10gYW5kIGFsc28gZGVmaW5lZCBpbiBSRkMgNTY1NCBbUkZD NTY1NF0sIFJlcXVpcmVtZW50IDgzLCBhczxicj4NCm9uZSBvZiB0aGUgbWFuZGF0b3J5IGV4dGVy bmFsIGNvbW1hbmRzLCBzaG91bGQgYmUgdXNlZCBmb3IgdGhpczxicj4NCnB1cnBvc2UsIGJ1dCBp cyBub3QgaW5jbHVkZWQgaW4gUkZDIDYzNzguIE5vdGUgdGhhdCB0aGUgJnF1b3Q7TWFudWFsPGJy Pg0KU3dpdGNoLW92ZXIgZm9yIHJlY292ZXJ5IExTUC9zcGFuJnF1b3Q7IGNvbW1hbmQgaXMgdGhl IHNhbWUgYXMgTVMtVzxicj4NCmNvbW1hbmQuPGJyPg0KTkVXPGJyPg0KTWFudWFsIFN3aXRjaC1v dmVyIGZvciByZWNvdmVyeSBMU1Avc3BhbiBjb21tYW5kIGlzIGRlZmluZWQgaW4gUkZDPGJyPg0K NDQyNyBbUkZDNDQyN10uIFJlcXVpcmVtZW50IDgzIGluIFJGQyA1NjU0IFtSRkM1NjU0XSBzdGF0 ZXMgdGhhdCB0aGU8YnI+DQpleHRlcm5hbCBjb21tYW5kcyBkZWZpbmVkIGluIFJGQyA0NDI3IG11 c3QgYmUgc3VwcG9ydGVkLiBObyBzdWNoPGJyPg0KY29tbWFuZCBpcyBzdXBwb3J0ZWQgaW4gUFND IGFzIGRlZmluZWQgaW4gUkZDIDYzNzggc28gdGhlcmUgaXMgYSBuZWVkPGJyPg0KdG8gcHJvdmlk ZSBzdXBwb3J0IGZvciB0aGF0IGZlYXR1cmUuIE5vdGUgdGhhdCB0aGUgJnF1b3Q7TWFudWFsIFN3 aXRjaC08YnI+DQpvdmVyIGZvciByZWNvdmVyeSBMU1Avc3BhbiZxdW90OyBjb21tYW5kIGlzIHRo ZSBzYW1lIGFzIHRoZSBNUy1XIGNvbW1hbmQuPGJyPg0KRU5EPGJyPg0KPGJyPg0KLS0tPGJyPg0K PGJyPg0KSW4gU2VjdGlvbiA2LjIsIHdoZW4geW91IHNheSAmcXVvdDtyZXBsYWNlZCZxdW90OyBp dCBpbXBsaWVzIHRoYXQgdGhpcyBpcyBtYWtpbmcgYTxicj4NCnNwZWNpZmljIHVwZGF0ZSB0byA2 Mzc4LiBCdXQgSSBkb24ndCB0aGluayB5b3UgbmVlZCB0byBkbyB0aGF0IChhbmQgPGJyPg0KcG9z c2libHkgdGhhdCB3YXNuJ3QgdGhlIGludGVudGlvbi4gSSB0aGluayBpdCBpcyBlbm91Z2ggdG8g ZGVmaW5lIHRoZTxicj4NCnRlcm1zIHlvdSB1c2UgaW4gdGhpcyBkb2N1bWVudC4gU28gSSBzdWdn ZXN0Li4uPGJyPg0KPGJyPg0KT0xEPGJyPg0KVGhlIHRlcm0gJnF1b3Q7TWFudWFsIFN3aXRjaCZx dW90OyBhbmQgaXRzIGFjcm9ueW0gJnF1b3Q7TVMmcXVvdDsgdXNlZCBpbiBSRkMgNjM3OCBhcmU8 YnI+DQpyZXBsYWNlZCByZXNwZWN0aXZlbHkgYnkgJnF1b3Q7TWFudWFsIFN3aXRjaCB0byBQcm90 ZWN0aW9uIHBhdGgmcXVvdDsgYW5kPGJyPg0KJnF1b3Q7TVMtUCZxdW90OyBieSB0aGlzIGRvY3Vt ZW50IHRvIGF2b2lkIGNvbmZ1c2lvbiB3aXRoICZxdW90O01hbnVhbCBTd2l0Y2ggdG88YnI+DQpX b3JraW5nIHBhdGgmcXVvdDsgYW5kIGl0cyBhY3JvbnltICZxdW90O01TLVcmcXVvdDsuPGJyPg0K PGJyPg0KQWxzbywgdGhlIHRlcm0gJnF1b3Q7UHJvdGVjdGluZyBhZG1pbmlzdHJhdGl2ZSBzdGF0 ZSZxdW90OyB1c2VkIGluIFJGQyA2Mzc4IGlzPGJyPg0KcmVwbGFjZWQgYnkgJnF1b3Q7U3dpdGNo aW5nIGFkbWluaXN0cmF0aXZlIHN0YXRlJnF1b3Q7IGJ5IHRoaXMgZG9jdW1lbnQgdG88YnI+DQpp bmNsdWRlIHRoZSBjYXNlIHdoZXJlIHRyYWZmaWMgaXMgc3dpdGNoZWQgYmFjayB0byB0aGUgd29y a2luZyBwYXRoPGJyPg0KYnkgYWRtaW5pc3RyYXRpdmUgTVMtVyBjb21tYW5kLjxicj4NCk5FVzxi cj4NClJGQyA2Mzc4IHVzZXMgdGhlIHRlcm0gJnF1b3Q7TWFudWFsIFN3aXRjaCZxdW90OyBhbmQg aXRzIGFjcm9ueW0gJnF1b3Q7TVMmcXVvdDsuIFRoaXMgPGJyPg0KZG9jdW1lbnQgdXNlcyB0aGUg dGVybSAmcXVvdDtNYW51YWwgU3dpdGNoIHRvIFByb3RlY3Rpb24gcGF0aCZxdW90OyBhbmQ8YnI+ DQomcXVvdDtNUy1QJnF1b3Q7IHRvIGhhdmUgdGhlIHNhbWUgbWVhbmluZywgYnV0IGF2b2lkIGNv bmZ1c2lvbiB3aXRoICZxdW90O01hbnVhbCA8YnI+DQpTd2l0Y2ggdG8gV29ya2luZyBwYXRoJnF1 b3Q7IGFuZCBpdHMgYWNyb255bSAmcXVvdDtNUy1XJnF1b3Q7Ljxicj4NCjxicj4NClNpbWlsYXJs eSwgUkZDIDYzNzggdXNlcyB0aGUgdGVybSAmcXVvdDtQcm90ZWN0aW5nIGFkbWluaXN0cmF0aXZl IHN0YXRlJnF1b3Q7LDxicj4NCmFuZCB0aGlzIGRvY3VtZW50IHVzZXMgJnF1b3Q7U3dpdGNoaW5n IGFkbWluaXN0cmF0aXZlIHN0YXRlJnF1b3Q7IHRvIGNvdmVyIHRoZTxicj4NCnNhbWUgY29uY2Vw dCBidXQgYWxzbyBpbmNsdWRlIHRoZSBjYXNlIHdoZXJlIHRyYWZmaWMgaXMgc3dpdGNoZWQgYmFj azxicj4NCnRvIHRoZSB3b3JraW5nIHBhdGggYnkgYWRtaW5pc3RyYXRpdmUgTVMtVyBjb21tYW5k Ljxicj4NCkVORDxicj4NCjxicj4NCkluIGtlZXBpbmcgd2l0aCB0aGlzLCBpdCBtaWdodCBiZSBi ZXR0ZXIgdG8gY2hhbmdlIHRoZSBzZWN0aW9uIHRpdGxlIHRvPGJyPg0KPGJyPg0KNi4yLiBUZXJt aW5vbG9neSB0byBzdXBwb3J0IE1TLVc8YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQpTZWN0aW9u IDYuMzxicj4NCjxicj4NClRoZXJlIGlzIGEgc2xpZ2h0IGRpc2NyZXBhbmN5IGluIHRoZSB0ZXh0 IGJlY2F1c2UgaXQgc2F5cyB0aGF0IHRoZSBNUy1QPGJyPg0KYW5kIE1TLVcgY29tbWFuZHMgaGF2 ZSB0aGUgc2FtZSBwcmlvcml0eSwgYnV0IGFsc28gZ2l2ZXMgYW4gZXhhbXBsZSBvZjxicj4NCndo ZW4gdGhleSBkb24ndCBoYXZlIHRoZSBzYW1lIHByaW9yaXR5Ljxicj4NCjxicj4NCkkgdGhpbmsg YWxsIHRoZSByZWxldmFudCBtYXRlcmlhbCBpcyBwcmVzZW50LCBzbyBpdCBpcyBqdXN0IGEgbWF0 dGVyIG9mPGJyPg0KcmUtb3JkZXJpbmcgaXQuLi4uPGJyPg0KPGJyPg0KT0xEPGJyPg0KVGhlIE1T LVAgYW5kIE1TLVcgY29tbWFuZHMgU0hBTEwgaGF2ZSB0aGUgc2FtZSBwcmlvcml0eS4gSWYgb25l IG9mPGJyPg0KdGhlc2UgY29tbWFuZHMgaXMgYWxyZWFkeSBpc3N1ZWQgYW5kIGFjY2VwdGVkLCB0 aGVuIHRoZSBvdGhlciBjb21tYW5kPGJyPg0KdGhhdCBpcyBpc3N1ZWQgYWZ0ZXJ3YXJkcyBTSEFM TCBiZSBpZ25vcmVkLiBJZiB0d28gTEVScyBhcmU8YnI+DQpyZXF1ZXN0aW5nIG9wcG9zaXRlIG9w ZXJhdGlvbnMgc2ltdWx0YW5lb3VzbHksIGkuZS4gb25lIExFUiBpczxicj4NCnNlbmRpbmcgTVMt UCB3aGlsZSB0aGUgb3RoZXIgTEVSIGlzIHNlbmRpbmcgTVMtVywgdGhlIE1TLVcgU0hBTEwgYmU8 YnI+DQpjb25zaWRlcmVkIHRvIGhhdmUgYSBoaWdoZXIgcHJpb3JpdHkgdGhhbiBNUy1QLCBhbmQg TVMtUCBTSEFMTCBiZTxicj4NCmlnbm9yZWQgYW5kIGNhbmNlbGxlZC48YnI+DQpORVc8YnI+DQpJ ZiBvbmUgb2YgdGhlIE1TLVAgYW5kIE1TLVcgY29tbWFuZHMgaXMgcmVjZWl2ZWQgYW5kIHByb2Nl c3NlZCBhZnRlcjxicj4NCnRoZSBvdGhlciwgdGhlIHR3byBjb21tYW5kcyBTSEFMTCBoYXZlIHRo ZSBzYW1lIHByaW9yaXR5IHN1Y2ggdGhhdCBpZjxicj4NCm9uZSBvZiB0aGUgY29tbWFuZHMgaXMg YWxyZWFkeSBpc3N1ZWQgYW5kIGFjY2VwdGVkLCB0aGUgY29tbWFuZCB0aGF0PGJyPg0KaXMgaXNz dWVkIGFmdGVyd2FyZHMgU0hBTEwgYmUgaWdub3JlZC4gSG93ZXZlciwgaWYgdHdvIExFUnMgcmVx dWVzdDxicj4NCm9wcG9zaXRlIG9wZXJhdGlvbnMgc2ltdWx0YW5lb3VzbHkgKGkuZS4sIG9uZSBM RVIgc2VuZHMgTVMtUCBhbmQgdGhlPGJyPg0Kb3RoZXIgc2VuZHMgTVMtVyksIHRoZSBNUy1XIFNI QUxMIGJlIGNvbnNpZGVyZWQgdG8gaGF2ZSBhIGhpZ2hlciA8YnI+DQpwcmlvcml0eSB0aGFuIE1T LVAsIGFuZCBNUy1QIFNIQUxMIE5PVCBiZSBhY2NlcHRlZCBhbmQgU0hBTEwgYmU8YnI+DQpjYW5j ZWxsZWQuPGJyPg0KRU5EPGJyPg0KPGJyPg0KLS0tPGJyPg0KPGJyPg0KU2VjdGlvbiA2LjQ8YnI+ DQo8YnI+DQpKdXN0IGFzIDQuMSwgNC40LCBhbmQgNS4uLjxicj4NCjxicj4NCk9MRDxicj4NClRo ZSBjaGFuZ2Ugb2YgdGhlIFBTQyBDb250cm9sIGxvZ2ljIGluY2x1ZGluZyB0aGUgc3RhdGUgbWFj aGluZSBkdWU8YnI+DQp0byB0aGUgc3VwcG9ydCBvZiBNUy1XIGNvbW1hbmQgaXMgaW5jb3Jwb3Jh dGVkIGludG8gdGhlIFBTQyBDb250cm9sPGJyPg0KbG9naWMgZGVzY3JpcHRpb24gaW4gU2VjdGlv biAxMCBhbmQgU2VjdGlvbiAxMSB3aGVuIGFsbCB0aGU8YnI+DQpjYXBhYmlsaXRpZXMgYXJlIGVu YWJsZWQ8YnI+DQpORVc8YnI+DQpTdXBwb3J0IG9yIHRoaXMgZnVuY3Rpb24gcmVxdWlyZXMgY2hh bmdlcyB0byB0aGUgUFNDIGNvbnRyb2wgbG9naWM8YnI+DQooaW5jbHVkaW5nIHRoZSBzdGF0ZSBt YWNoaW5lKSBjb21wYXJlZCB0byB0aGF0IHNob3duIGluIFtSRkM2Mzc4XS48YnI+DQpTZWN0aW9u cyAxMCBhbmQgMTEgc2hvdyB0aGUgUFNDIGNvbnRyb2wgbG9naWMgYW5kIHN0YXRlIG1hY2hpbmUg d2hlbjxicj4NCmFsbCBvZiB0aGUgY2FwYWJpbGl0aWVzIGluIEFQUyBtb2RlIGFyZSBlbmFibGVk Ljxicj4NCkVORDxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NClNlY3Rpb24gNy4xPGJyPg0KPGJy Pg0KVGhlIFBTQyBwcm90b2NvbCBhc3NvY2lhdGVkIHdpdGggU0QgaXMgY292ZXJlZCBpbiB0aGlz IGRvY3VtZW50LCBhbmQ8YnI+DQp0aGUgc3BlY2lmaWNzIGZvciB0aGUgbWV0aG9kIG9mIGlkZW50 aWZ5aW5nIFNEIGlzIG91dCBvZiB0aGUgc2NvcGUgb2Y8YnI+DQp0aGUgcHJvdGVjdGlvbiBwcm90 b2NvbCBzaW1pbGFyIHRvIHRoZSBmYWN0cyB0aGF0IGhvdyBTRiBpcyBkZXRlY3Q8YnI+DQphbmQg aG93IE1TIGFuZCBGUyBjb21tYW5kcyBhcmUgaW5pdGlhdGVkIGluIGEgbWFuYWdlbWVudCBzeXN0 ZW0gYW5kPGJyPg0Kc2lnbmFsZWQgdG8gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgYXJlIG91dCBvZiBp dHMgc2NvcGUuPGJyPg0KPGJyPg0Kcy9hbmQgdGhlIHNwZWNpZmljcy9idXQgdGhlIHNwZWNpZmlj cy88YnI+DQo8YnI+DQpJdCBpcyBPSyB0byBpbmNsdWRlIHRoZSAmcXVvdDtzaW1pbGFyIHRvLi4u JnF1b3Q7IGJ1dCBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIGdpdmU8YnI+DQp0aGlzIHJlYXNvbmlu Zy48YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQpTZWN0aW9uIDcuMjxicj4NCjxicj4NCkp1c3Qg bGlrZSBTZWN0aW9uIDYuMiB0aGUgd29yZCAmcXVvdDtyZXBsYWNlZCZxdW90OyBtYXkgYmUgbWlz aW50ZXJwcmV0ZWQuPGJyPg0KPGJyPg0KU28gSSBzdWdnZXN0IG5hbWluZyB0aGUgc2VjdGlvbi4u Ljxicj4NCjcuMi4gVGVybWlub2xvZ3kgdG8gc3VwcG9ydCBTRDxicj4NCjxicj4NCi4uLiBhbmQg cmVwbGFjaW5nPGJyPg0KPGJyPg0KT0xEPGJyPg0KSW5zdGVhZCBvZiBTRmMsIENsZWFyIFNpZ25h bCBGYWlsIG9yIERlZ3JhZGUgKFNGRGMpIGlzIHVzZWQgdG88YnI+DQppbmRpY2F0ZSB0aGUgY2xl YXJhbmNlIG9mIGVpdGhlciBhIGRlZ3JhZGVkIGNvbmRpdGlvbiBvciBhIGZhaWx1cmU8YnI+DQpj b25kaXRpb24uPGJyPg0KTkVXPGJyPg0KSW4gdGhpcyBkb2N1bWVudCB0aGUgdGVybSBDbGVhciBT aWduYWwgRmFpbCBvciBEZWdyYWRlIChTRkRjKSBpcyB1c2VkPGJyPg0KdG8gaW5kaWNhdGUgdGhl IGNsZWFyYW5jZSBvZiBlaXRoZXIgYSBkZWdyYWRlZCBjb25kaXRpb24gb3IgYSBmYWlsdXJlPGJy Pg0KY29uZGl0aW9uLjxicj4NCkVORDxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NClNlY3Rpb24g Ny4zPGJyPg0KPGJyPg0KQWdhaW4sIGp1c3QgYSBzbWFsbCBwb2xpdGljYWwgY2hhbmdlLi4uPGJy Pg0KPGJyPg0KT0xEPGJyPg0KSW4gb3JkZXIgdG8gbWFpbnRhaW4gdGhlIG5ldHdvcmsgb3BlcmF0 aW9uIGJlaGF2aW9yIHRvIHdoaWNoPGJyPg0KdHJhbnNwb3J0IG5ldHdvcmsgb3BlcmF0b3JzIGhh dmUgYmVjb21lIGFjY3VzdG9tZWQsIHRoZSBwcmlvcml0aWVzIG9mPGJyPg0KU0QtUCBhbmQgU0Qt VyBhcmUgZGVmaW5lZCB0byBiZSBlcXVhbCBhcyBpbiBvdGhlciB0cmFuc3BvcnQgbmV0d29ya3Ms PGJyPg0Kc3VjaCBhcyBTREgsIE9UTiBhbmQgRXRoZXJuZXQgdHJhbnNwb3J0IG5ldHdvcmtzLjxi cj4NCk5FVzxicj4NCkluIG9yZGVyIHRvIG1ha2UgdGhlIGJlaGF2aW9yIG9mIE1QTFMtVFAgbmV0 d29ya3MgY29uc2lzdGVudCB3aXRoIDxicj4NCnRoYXQgb2Ygb3RoZXIgdHJhbnNwb3J0IG5ldHdv cmtzIChzdWNoIGFzIFNESCwgT1ROIGFuZCBFdGhlcm5ldDxicj4NCnRyYW5zcG9ydCBuZXR3b3Jr cyksIHRoZSBwcmlvcml0aWVzIG9mIFNELVAgYW5kIFNELVcgYXJlIGRlZmluZWQgdG88YnI+DQpi ZSBlcXVhbC48YnI+DQpFTkQ8YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQpJbiBTZWN0aW9uIDcu NCwgZm9yIGNsYXJpdHksIEkgdGhpbmsgeW91IHNob3VsZCBpbnRlbmQgYW5kIGJ1bGxldCB0aGU8 YnI+DQp0d28gcGFyYWdyYXBocyBiZWdpbm5pbmc8YnI+DQo8YnI+DQpXaGVuIE1TLVcgYW5kIE1T LVAuLi48YnI+DQphbmQ8YnI+DQpXaGVuIFNELVcgYW5kIFNELVAuLi48YnI+DQo8YnI+DQotLS08 YnI+DQo8YnI+DQpBbmQsIGFzIG5vdyBpcyBiZWNvbWluZyBmYW1pbGlhciwgYXQgdGhlIGVuZCBv ZiA3LjQ8YnI+DQo8YnI+DQpPTEQ8YnI+DQpUaGUgY2hhbmdlIG9mIHRoZSBQU0MgQ29udHJvbCBs b2dpYyBpbmNsdWRpbmcgdGhlIHN0YXRlIG1hY2hpbmUgZHVlPGJyPg0KdG8gdGhlIHN1cHBvcnQg b2YgcHJvdGVjdGlvbiBhZ2FpbnN0IFNEIGlzIGluY29ycG9yYXRlZCBpbnRvIHRoZSBQU0M8YnI+ DQpDb250cm9sIGxvZ2ljIGRlc2NyaXB0aW9uIGluIFNlY3Rpb24gMTAgYW5kIFNlY3Rpb24gMTEg d2hlbiBhbGwgdGhlPGJyPg0KY2FwYWJpbGl0aWVzIGFyZSBlbmFibGVkLjxicj4NCk5FVzxicj4N ClRoZSBhZGRpdGlvbiBvZiBzdXBwb3J0IGZvciBwcm90ZWN0aW9uIGFnYWluc3QgU0QgcmVxdWly ZXMgZGlmZmVyZW50PGJyPg0KUFNDIGNvbnRyb2wgbG9naWMgKGluY2x1ZGluZyB0aGUgc3RhdGUg bWFjaGluZSkgY29tcGFyZWQgdG8gdGhhdDxicj4NCnNob3duIGluIFtSRkM2Mzc4XS4gU2VjdGlv bnMgMTAgYW5kIDExIHNob3cgdGhlIFBTQyBjb250cm9sIGxvZ2ljIGFuZDxicj4NCnN0YXRlIG1h Y2hpbmUgd2hlbiBhbGwgb2YgdGhlIGNhcGFiaWxpdGllcyBpbiBBUFMgbW9kZSBhcmUgZW5hYmxl ZC48YnI+DQpFTkQ8YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQpTZWN0aW9uIDggaXMgdW5jbGVh ciBpbiB0aGUgcmFjZSBsb2dpYy4gWW91IGhhdmUuLi48YnI+DQo8YnI+DQpXaGVuIEV4ZXJjaXNl IGNvbW1hbmRzIGFyZSBpbnB1dCBhdCBib3RoIGVuZHMsIGFuIEVYRVIsIGluc3RlYWQgb2Y8YnI+ DQpSUiwgU0hBTEwgYmUgdHJhbnNtaXR0ZWQgZnJvbSBib3RoIGVuZHMuPGJyPg0KPGJyPg0KSSB0 aGluayB0aGF0IHRoaXMgbWVhbnMgdGhhdCBFWEVSIHNoYWxsIGJlIHRha2VuIGFzIGEgdmFsaWQg cmVzcG9uc2UgdG88YnI+DQpFWEVSIGFuZCB0aGF0IGlmIGFuIExFUiB0aGF0IGhhcyBpc3N1ZWQg YW4gRVhFUiBhbmQgaGFzIG5vdCByZWNlaXZlZCBhbjxicj4NClJSIHRoZW4sIGlmIGl0IHJlY2Vp dmVzIGFuIEVYRVIgaXQgZG9lcyBub3QgbmVlZCB0byAoU0hPVUxEIE5PVCkgc2VuZCA8YnI+DQpS Ui48YnI+DQo8YnI+DQpXZSBjb3VsZCBjYXB0dXJlIHRoaXMgYXMuLi48YnI+DQo8YnI+DQpPTEQ8 YnI+DQpXaGVuIEV4ZXJjaXNlIGNvbW1hbmRzIGFyZSBpbnB1dCBhdCBib3RoIGVuZHMsIGFuIEVY RVIsIGluc3RlYWQgb2Y8YnI+DQpSUiwgU0hBTEwgYmUgdHJhbnNtaXR0ZWQgZnJvbSBib3RoIGVu ZHMuPGJyPg0KTkVXPGJyPg0KSWYgRXhlcmNpc2UgY29tbWFuZHMgYXJlIGlucHV0IGF0IGJvdGgg ZW5kcywgdGhlbiBhIHJhY2UgY29uZGl0aW9uPGJyPg0KbWF5IGFycmlzZS4gVGhpcyBpcyByZXNv bHZlZCBhcyBmb2xsb3dzOjxicj4NCjxicj4NCm8gSWYgYW4gTEVSIGhhcyBpc3N1ZWQgRVhFUiBh bmQgcmVjZWl2ZXMgRVhFUiBiZWZvcmUgcmVjZWl2aW5nIFJSLCBpdDxicj4NCjxicj4NCm8gTVVT VCB0cmVhdCB0aGUgcmVjZWl2ZWQgRVhFUiBhcyBpdCB3b3VsZCBhbiBSUi48YnI+DQo8YnI+DQpv IFNIT1VMRCBOT1QgcmVzcG9uZCB3aXRoIFJSLjxicj4NCkVORDxicj4NCjxicj4NCi0tLTxicj4N Cjxicj4NClNlY3Rpb24gODxicj4NCjxicj4NClRoZSBmb2xsb3dpbmcgUFNDIFJlcXVlc3RzIFNI QUxMIGJlIGFkZGVkIHRvIFBTQyBSZXF1ZXN0IGZpZWxkIHRvPGJyPg0Kc3VwcG9ydCBFeGVyY2lz ZTo8YnI+DQo8YnI+DQpXZSBkb24ndCBuZWVkIHRvIHVzZSBSRkMgMjExOSBsYW5ndWFnZSBoZXJl LiBZb3UgY2FuIGp1c3Qgc2F5Li4uPGJyPg0KPGJyPg0KVGhlIGZvbGxvd2luZyBQU0MgUmVxdWVz dHMgYXJlIGFkZGVkIHRvIHRoZSBQU0MgUmVxdWVzdCBmaWVsZCB0bzxicj4NCnN1cHBvcnQgdGhl IEV4ZXJjaXNlIGNvbW1hbmQgKHNlZSBhbHNvIFNlY3Rpb24gMTQuMSk6PGJyPg0KPGJyPg0KLS0t PGJyPg0KPGJyPg0KU2VjdGlvbiA4PGJyPg0KPGJyPg0KVGhlIHByaW9yaXR5IG9mIEV4ZXJjaXNl IFNIQUxMIGJlIGluc2VydGVkIGJldHdlZW4gdGhlIHByaW9yaXRpZXMgb2Y8YnI+DQpXVFIgRXhw aXJlcyBhbmQgTm8gUmVxdWVzdC48YnI+DQo8YnI+DQpGb3IgdGhlIGF2b2lkYW5jZSBvZiBkb3Vi dCBpdCBpcyBuaWNlIHRvIGFjdHVhbGx5IGdpdmUgdGhlIG9yZGVyaW5nLiBBbmQ8YnI+DQpzaW5j ZSB3ZSBlbmQgdXAgd2l0aCBFeGVyY2lzZSBub3QgYmVpbmcgaW1tZWRpYXRlbHkgYWRqYWNlbnQg dG8gTm8gPGJyPg0KUmVxdWVzdCwgSSBzdWdnZXN0IHRoaXMgaXMgYmVzdCBoYW5kbGVkIGJ5IGEg Zm9yd2FyZCByZWZlcmVuY2UgdG88YnI+DQpTZWN0aW9uIDEwLjIuPGJyPg0KPGJyPg0KVGhlIHJl bGF0aXZlIHByaW9yaXR5IG9mIEV4ZXJjaXNlIGlzIHNob3duIGluIHRoZSB0YWJsZSBpbiBTZWN0 aW9uPGJyPg0KMTAuMi48YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQpTZWN0aW9uIDkuMS4xPGJy Pg0KPGJyPg0KV2UgZG8gbm90IGRlc2lnbiBwcm90b2NvbHMgdG8gbWFrZSB0aGVtIHJlc2lsaWVu dCBhZ2FpbnN0IGJ1Z3MgaW4gPGJyPg0KaW1wbGVtZW50YXRpb25zIG9mIHRoZSBwcm90b2NvbC4g VGhpcyBpcyBiZWNhdXNlIGFueSB0aWNrIHlvdSBjb21lIHVwPGJyPg0Kd2l0aCB3aWxsLCBpdHNl bGYsIGJlIHZ1bG5lcmFibGUgdG8gYSBidWcgaW4gdGhlIGltcGxlbWVudGF0aW9uLjxicj4NCjxi cj4NClRodXMsIHdoZW4geW91IHNheS4uLjxicj4NCjxicj4NClBTQyBzZW5kcyBtZXNzYWdlcyBp biByZXNwb25zZSB0byBleHRlcm5hbCBldmVudHMgYW5kIGluIHBlcmlvZGljPGJyPg0KcmV0cmFu c21pc3Npb24gb2YgY3VycmVudCBzdGF0dXMuIEl0IG1heSBiZSBleHBlbnNpdmUgdG8gc2VuZCBh bmQgdG88YnI+DQpwYXJzZSBhbiBDYXBhYmlsaXRpZXMgVExWIGF0dGFjaGVkIHRvIGEgcGFja2V0 IGludGVuZGVkIHRvIHRyaWdnZXIgYTxicj4NCnByb3RlY3Rpb24gc3dpdGNoIG9yIG90aGVyIHJl YWwtdGltZSBiZWhhdmlvci4gSG93ZXZlciwgaWYgYSBub2RlPGJyPg0KZG9lcyBub3QgcGVyaW9k aWNhbGx5IHNlbmQgaXRzIENhcGFiaWxpdGllcyBUTFYsIHRoZSByZWNlaXZpbmcgbm9kZTxicj4N CmNhbm5vdCBkaXNjcmltaW5hdGUgYSBkZWxpYmVyYXRlIG9taXNzaW9uIG9mIHRoZSBDYXBhYmls aXRpZXMgVExWIGZvcjxicj4NCnBlcmZvcm1hbmNlIHJlYXNvbnMgZnJvbSBhbiBhY2NpZGVudGFs IG9taXNzaW9uIGR1ZSB0byBhbjxicj4NCmltcGxlbWVudGF0aW9uIGlzc3VlLiBUbyBndWFyZCBh Z2FpbnN0IHRoaXMsIGEgbm9kZSBNVVNUIGluY2x1ZGUgaXRzPGJyPg0KQ2FwYWJpbGl0aWVzIFRM ViBpbiBldmVyeSBQU0MgbWVzc2FnZSB0aGF0IGl0IHNlbmRzLjxicj4NCjxicj4NCi4uLnlvdSBh cmUgbmVnbGVjdGluZyB0byBjb25zaWRlciB0aGF0IGVhY2ggYW5kIHZlcnkgb21pc3Npb24gb2Yg YSA8YnI+DQpjYXBhYmlsaXR5IG1pZ2h0IGJlIGR1ZSB0byBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1 ZS4gU28gcmVxdWlyaW5nIDxicj4NCmluY2x1c2lvbiBpbiBldmVyeSBQU0MgbWVzc2FnZSBkb2Vz IG5vdCByZXNvbHZlIHRoaXMuPGJyPg0KPGJyPg0KSG93ZXZlciwgeW91ICpkbyogc3RpbGwgbmVl ZCB0byBpbmNsdWRlIHRoZSBDYXBhYmlsaXRpZXMgVExWIGluIGV2ZXJ5PGJyPg0KUFNDIG1lc3Nh Z2UgKGlmIHRoZSBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyB0aGUgQ2FwYWJpbGl0aWVzIFRMVikg aWY8YnI+DQphbmQgb25seSBpZiwgYW4gTEVSIGlzIGFsbG93ZWQgdG8gY2hhbmdlIHRoZSBjYXBh YmlsaXRpZXMgaXQgc3VwcG9ydHM8YnI+DQpkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIGFuIExTUC4g VGhlIHJlYXNvbiBmb3IgdGhpcyBpcyB0aGF0IHRoZSA8YnI+DQphYnNlbmNlIG9mIHRoZSBDYXBh YmlsaXRpZXMgVExWIGlzIHZhbGlkIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IDxicj4NCnJl YXNvbnM6IHRoZXJlZm9yZSB0aGVyZSBpcyBubyB3YXkgdG8gZGlzdGluZ3Vpc2ggJnF1b3Q7SSBo YXZlIHN0b3BwZWQ8YnI+DQpzdXBwb3J0aW5nIGFsbCBvZiB0aGUgY2FwYWJpbGl0aWVzJnF1b3Q7 IGZyb20gJnF1b3Q7SSBoYXZlIGxlZnQgb3V0IHRoZTxicj4NCkNhcGFiaWxpdGllcyBUTFYgYmVj YXVzZSBub3RoaW5nIGhhcyBjaGFuZ2VkLiZxdW90Ozxicj4NCjxicj4NCiguLi5idXQgc2VlIG15 IGNvbW1lbnQgb24gOS4xLjMuMiB3cnQgdGhlIGZpbmFsIHBhcmFncmFwaCBvZiA5LjMpLjxicj4N Cjxicj4NClNvLCB5b3UgbXVzdCBkZWNpZGU6IGNhbiBhbiBMRVIgY2hhbmdlIHRoZSBjYXBhYmls aXRpZXMgaXQgc3VwcG9ydHM/PGJyPg0KSWYgeWVzLCB0aGVuIHlvdSBtYWtlICp0aGF0KiB0aGUg cmVhc29uIGZvciByZXF1aXJpbmcgdGhlIFRMViB0byBiZTxicj4NCnByZXNlbnQgaW4gZXZlcnkg bWVzc2FnZS48YnI+DQpJZiBubywgdGhlbiB0aGUgVExWIGRvZXMgbm90IG5lZWQgdG8gYmUgcHJl c2VudCBpbiBlYWNoIG1lc3NhZ2UsIGJ1dCB5b3U8YnI+DQpkbyBuZWVkIHRvIG1ha2Ugc3VyZSB0 aGUgbWVzc2FnZSB0aGF0IHdhcyBjYXJyeWluZyBpdCBnb3QgZGVsaXZlcmVkLjxicj4NCjxicj4N Ckl0IGxvb2tzIHRvIG1lLCBmcm9tIDkuMS4yIHRoYXQgeW91IGFyZSBzZXQgb24gcmVxdWlyaW5n IHJldHJhbnNtaXNzaW9uPGJyPg0KYW5kIGNvbnRpbnVhbCBjaGVja2luZyBvZiBDYXBhYmlsaXRp ZXMgZXZlbiB0aG91Z2ggaXQgd291bGQgYmUgPGJyPg0KaW1wb3NzaWJsZSB0byBhY2hpZXZlIGEg c3luY2hyb25pc2VkIGNoYW5nZSAodGhhdCBpcywgaWYgb25lIGVuZCB3ZXJlIHRvPGJyPg0KY2hh bmdlIGl0cyBjYXBhYmlsaXRpZXMgdGhpcyB3b3VsZCBhdXRvbWF0aWNhbGx5IHJlc3VsdCBpbiBh biBlcnJvcjxicj4NCmNvbmRpdGlvbnMpLiBTbyBpdCByZWFsbHkgc2VlbXMgdG8gbWUgdGhhdCB0 aGlzIGlzIHVubmVjZXNzYXJ5PGJyPg0KcHJvY2Vzc2luZy48YnI+DQo8YnI+DQotLS08YnI+DQo8 YnI+DQpTZWN0aW9uIDkuMS4yPGJyPg0KPGJyPg0KVGhpcyBjb21tZW50IG9ubHkgYXBwbGllcyBp ZiB5b3UgZG9uJ3QgbWFrZSBhbnkgY2hhbmdlIGFzIGEgcmVzdWx0IG9mPGJyPg0KbXkgY29tbWVu dCBvbiB0aGUgcHJldmlvdXMgc2VjdGlvbi48YnI+DQo8YnI+DQpJIHRoaW5rIHlvdSBzaG91bGQg YWR2aXNlIGFuIGltcGxlbWVudGF0aW9uIG9uIHdoZXRoZXIgaXQgc2hvdWxkIDxicj4NCmNvbXBh cmUgdGhlIENhcGFiaWxpdGllcyBUTFYgYXMgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiBiZWZv cmUgb3I8YnI+DQphZnRlciBhY3Rpbmcgb24gdGhlIHJlY2VpdmVkIFBTQyBtZXNzYWdlLiBUaGF0 IGlzIChmb3IgZXhhbXBsZSksIHNob3VsZDxicj4NCmEgcHJvdGVjdGlvbiBzd2l0Y2ggYmUgdHJp Z2dlcmVkIGJlZm9yZSBvciBhZnRlciB0aGUgQ2FwYWJpbGl0aWVzIGhhdmU8YnI+DQpiZWVuIGNo ZWNrZWQ/PGJyPg0KPGJyPg0KLS0tPGJyPg0KPGJyPg0KU2VjdGlvbiA5LjEuMy4yPGJyPg0KPGJy Pg0KSSB0aGluayB0aGUgZmluYWwgcGFyYWdyYXBoIG9mIFNlY3Rpb24gOS4zIGlzIHZlcnkgcmVs ZXZhbnQgaGVyZS4gWW91IDxicj4NCnNob3VsZCBlaXRoZXIgY29weSB0aGUgdGV4dCBoZXJlIG9y IHlvdSBzaG91bGQgcHJvdmlkZSBhIGZvcndhcmQgcG9pbnRlcjxicj4NCnRvIFNlY3Rpb24gOS4z Ljxicj4NCjxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NClNlY3Rpb24gOS4xLjMuMzxicj4NCjxi cj4NClNldmVyYWwgdGhpbmdzIGFyZSBub3QgY2xlYXIgaW4gdGhlIGRlc2NyaXB0aW9uIG9mIHRo ZSBlcnJvciBoYW5kbGluZzo8YnI+DQotIGlmIGEgbWlzbWF0Y2ggKDkuMS4zLjIpIGlzIHJlY2Vp dmVkLCBzaG91bGQgdGhlIHRpbWVyIGJlIHN0b3BwZWQ/PGJyPg0KLSBpZiB0aGVyZSBpcyBhIHRp bWVvdXQgKDkuMS4zLjEpIGFuZCB0aGVuIGEgUFNDIG1lc3NhZ2UgaXMgcmVjZWl2ZWQsPGJyPg0K c2hvdWxkIHRoZSBjYXBhYmlsaXRpZXMgYmUgY29tcGFyZWQ/PGJyPg0KLSBpZiBhIG1pc21hdGNo ICg5LjEuMy4yKSBpcyByZWNlaXZlZCBhbmQgdGhlbiBhIFBTQyBtZXNzYWdlIGlzIDxicj4NCnJl Y2VpdmVkLCBzaG91bGQgdGhlIGNhcGFiaWxpdGllcyBiZSBjb21wYXJlZD88YnI+DQotIGhvdyBz aG91bGQgYWxlcnRzIHRvIGJlIHRoZSBvcGVyYXRvciBiZSBoYW5kbGVkIGluIHRoZSBldmVudCBv ZiA8YnI+DQpjb250aW51ZWQgbWlzbWF0Y2hlcyBvciB0aW1lb3V0cz88YnI+DQotIHdoYXQgYWN0 aW9ucyBhcmUgYXZhaWxhYmxlIHRvIGFuIG9wZXJhdG9yIHRvIHJlc29sdmUgY2FwYWJpbGl0aWVz PGJyPg0KbWlzbWF0Y2hlcz88YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQpTZWN0aW9uIDkuMi4x PGJyPg0KPGJyPg0KT0xEPGJyPg0KQSBub2RlIGNhbiBzZW5kIGE8YnI+DQpDYXBhYmlsaXRpZXMg VExWIG9mIDB4MDxicj4NCk5FVzxicj4NCkEgbm9kZSBjYW4gc2VuZCBhPGJyPg0KQ2FwYWJpbGl0 aWVzIFRMViB3aXRoIEZsYWdzIHZhbHVlIHNldCB0byAweDA8YnI+DQpFTkQ8YnI+DQo8YnI+DQot LS08YnI+DQo8YnI+DQpTaW1pbGFybHkgaW4gOS4yLjM8YnI+DQo8YnI+DQpPTEQ8YnI+DQpDYXBh YmlsaXRpZXMgVExWIG9mIDB4MDxicj4NCk5FVzxicj4NCkNhcGFiaWxpdGllcyBUTFYgd2l0aCBG bGFncyB2YWx1ZSBzZXQgdG8gMHgwPGJyPg0KRU5EPGJyPg0KPGJyPg0KLS0tPGJyPg0KPGJyPg0K U2VjdGlvbiAxMC4xPGJyPg0KPGJyPg0KWW91IHJlYWxseSBzY2FyZWQgbWUhPGJyPg0KPGJyPg0K VGhlIHZhbHVlcyBvZiAmcXVvdDtSZXF1ZXN0JnF1b3Q7IGZpZWxkIGluIFBTQyBwcm90b2NvbCBt ZXNzYWdlLCB3aGljaCBpcyBzaG93bjxicj4NCmluIEZpZ3VyZSAyIG9mIFJGQyA2Mzc4IFtSRkM2 Mzc4XSwgYXJlIHJlZGVmaW5lZCBhcyBmb2xsb3dzOjxicj4NCjxicj4NCkZvcnR1bmF0ZWx5IHlv dSBhcmUgbm90IHJlZGVmaW5pbmcgdGhlIFJlcXVlc3QgdHlwZXMgZnJvbSBSRkMgNjM3OC4gWW91 IDxicj4NCmFyZSBqdXN0IGRlZmluaW5nIHR3byBuZXcgb25lcy4gUGhldyE8YnI+DQo8YnI+DQpT byB5b3UgY2FuIHJlcGxhY2UgdGhlIHdob2xlIG9mIFNlY3Rpb24gMTAuMSB3aXRoLi4uPGJyPg0K PGJyPg0KTkVXPGJyPg0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBuZXcgdmFsdWVzIGZvciB0 aGUgJnF1b3Q7UmVxdWVzdCZxdW90OyBmaWVsZCBpbiB0aGU8YnI+DQpQU0MgcHJvdG9jb2wgbWVz c2FnZSB0aGF0IGlzIHNob3duIGluIEZpZ3VyZSAyIG9mIFJGQyA2Mzc4IFtSRkM2Mzc4XTxicj4N CmFzIGZvbGxvd3M6PGJyPg0KPGJyPg0KKDMpIEV4ZXJjaXNlPGJyPg0KKDIpIFJldmVyc2UgUmVx dWVzdDxicj4NCjxicj4NClNlZSBhbHNvIFNlY3Rpb24gMTQuMSBvZiB0aGlzIGRvY3VtZW50Ljxi cj4NCkVORDxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NCkVpdGhlciBmaWxsIGluIG9yIGRlbGV0 ZSBTZWN0aW9uIDE1Ljxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCBbSS1E LmlldGYtbXBscy1wc2MtdXBkYXRlc10gY2FuIGJlIG1vdmVkIGZyb20gbm9ybWF0aXZlIHRvPGJy Pg0KaW5mb3JtYXRpdmUgcmVmZXJlbmNlLiBUaGlzIGRvZXNuJ3QgZGVjcmVhc2UgaXRzIHZhbHVl LCBidXQgSSBkb24ndCA8YnI+DQp0aGluayB0aGF0ICp0aGlzKiBkb2N1bWVudCByZXF1aXJlcyBb SS1ELmlldGYtbXBscy1wc2MtdXBkYXRlc10uPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvYSBBbmRlcnNzb248YnI+DQomZ3Q7IFNlbnQ6IDIwIEph bnVhcnkgMjAxNCAwMjoyODxicj4NCiZndDsgVG86IG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7IENj OiA8TVBMUy1BRFNAVE9PTFMuSUVURi5PUkc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsg ZHJhZnQtaWV0Zi1tcGxzLXRwLTxicj4NCiZndDsgcHNjLWl0dUB0b29scy5pZXRmLm9yZzxicj4N CiZndDsgU3ViamVjdDogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGRyYWZ0LWlldGYt bXBscy10cC1wc2MtaXR1LTAxPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdvcmtpbmcgR3JvdXAsPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbCBvbjxicj4NCiZndDsgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUuPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846SMTP2etriinfo_-- From adrian@olddog.co.uk Sun Jan 26 04:14:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E101A0138 for ; Sun, 26 Jan 2014 04:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 nqjDj19usJXo for ; Sun, 26 Jan 2014 04:14:01 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id A34B41A0136 for ; Sun, 26 Jan 2014 04:14:01 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0QCDq4M019169; Sun, 26 Jan 2014 12:13:53 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0QCDnnU019145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 Jan 2014 12:13:50 GMT From: "Adrian Farrel" To: "'Ryoo, Jeong-dong'" , "'Loa Andersson'" , References: <0bc301cf16ea$3981cd00$ac856700$@olddog.co.uk> <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846@SMTP2.etri.info> Date: Sun, 26 Jan 2014 12:13:48 -0000 Message-ID: <009101cf1a90$132a5d30$397f1790$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDDGELNpZkSuNS/NSgW0Szz71cHAI+7oqomh0Mk1A= Content-Language: en-gb Cc: mpls-ads@tools.ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject: Re: [mpls] AD review : working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 12:14:03 -0000 Hi Jeong-dong, > In my opinion, all the wording from AD review should be taken except = the > followings that I would need further clarifications or confirmations = from AD: > --- > Abstract and Introduction > Due to the limitation in the length of Abstract and the nature of the = abstract, > which gives the main points of *this* document, I would like to see if = we can > add the sentence in the Introduction section only.=20 Yes. Good point. > Section 4.1 > The second paragraph in Section 4.1 is to emphasis the importance of = the > PSC communication channel in delivering the external switch command,=20 > so that the failure of PSC communication channel has higher priority = than FS.=20 > I would like to propose to change the paragraph as follows: > =3D=3D=3D OLD =3D=3D=3D > According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to > operate an MPLS-TP network without using a control plane. This means=20 > that external switch commands, e.g., FS, can be transferred to the > remote Label Edge Router (LER) only by using the PSC communication > channel and should not rely on the presence of a control plane. > =3D=3D=3D NEW =3D=3D=3D > According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to > operate an MPLS-TP network without using a control plane. This means > that the PSC communication channel is very important for the transfer > of external switch commands (e.g., FS), and these commands should not > rely on the presence of a control plane. In consequence, the failure > of the PSC communication channel has higher priority than FS. Yes. Thanks. I had completely missed this point. Your new wording is helpful. > Section 4.3 > You suggested =E2=80=9Cs/broken, the Freeze command,/broken.=20 > The Freeze command,/=E2=80=9D.=20 > But, my reading of two separate sentences is not ok. The > first sentence doesn=E2=80=99t seem to be complete. Would you=20 > please check this again?=20 You're right. My mistake. Leave it as it is. > Sections 9.1.1, Section 9.1.2, Section 9.1.3.2 and Section 9.1.3.3 > For those four comments on Section 9, I can understand the=20 > concerns. In my opinion, the questions given in the AD review > comments are very valid and should be answered. I think the > text needs to be changed rather significantly. I will prepare a=20 > new text proposal and further communicate with Adrian.=20 OK. I'll look for that. Many thanks for the quick turn around and the constructive approach. Regards, Adrian From cpignata@cisco.com Sun Jan 26 05:11:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867A01A013D for ; Sun, 26 Jan 2014 05:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 ckZHXnvIDrhM for ; Sun, 26 Jan 2014 05:10:59 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 169E01A0136 for ; Sun, 26 Jan 2014 05:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2434; q=dns/txt; s=iport; t=1390741857; x=1391951457; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7fXGq9UmlEN7+nKpDWrUSNcrMA8SsKzg0dDWQbnoqoc=; b=ip4fik/nv1MheoNJSJcFtt/drKmVcDlB9OycP2tUrByae4nS9L5v8bUM Lvfg9EtSGK/ETPZv9UDubmfdhKE1r7Hke6KcTT9P+TQUNTTRDJn9P4CZ+ O0O1FGeVmVlFJsfaps8QueHNOg9OFY0o+Km8/2gRG+Q6A1GFnoLSkfeyD A=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAGsI5VKtJV2a/2dsb2JhbABagww4VrxUgQQWdIIlAQEBAwEBAQFoAwYFBQkCAgEIRhsMCyUCBA4FDodvCA3HaRMEBI4nEAIBTweDJIEUBJA9gTKGOJIegy2CKg X-IronPort-AV: E=Sophos;i="4.95,724,1384300800"; d="asc'?scan'208";a="15608237" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 26 Jan 2014 13:10:56 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0QDAuvk026352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Jan 2014 13:10:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Sun, 26 Jan 2014 07:10:56 -0600 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-forwarding Thread-Index: AQHPEn1IQ4zR1tdQVESNp8+yeeMkO5qXb7UA Date: Sun, 26 Jan 2014 13:10:56 +0000 Message-ID: References: <52D77069.2050405@pi.nu> In-Reply-To: <52D77069.2050405@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.229.159] Content-Type: multipart/signed; boundary="Apple-Mail=_F968C22D-3025-4C79-AEFA-3CEF1D048CC6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] IPR poll on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 13:11:05 -0000 --Apple-Mail=_F968C22D-3025-4C79-AEFA-3CEF1D048CC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Loa, I am not aware of any IPR that applies to this document. Thanks, -- Carlos. On Jan 16, 2014, at 12:38 AM, Loa Andersson wrote: > Working Group, >=20 > we have just requested publication of draft-ietf-mpls-forwarding-04. >=20 > Since the IPR poll on the individual document is fairly recent, we = will > do the final poll in parallel to the initial steps of post publication > request steps. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-forwarding? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are three IPR disclosures that relates to this = document. >=20 > If you are listed as a document author or contributor please respond = to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The = document will not advance to the next stage until a response has been > received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author = or > contributor, then please explicitly respond only if you are aware of = any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_F968C22D-3025-4C79-AEFA-3CEF1D048CC6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLlCWIACgkQtfDPGTp3USwZ7gCgwR9dJ076HLZ6tUojsHYMxKqB bQYAnifEtgp7DjNVA7O8X/0kLXQf0ycB =kFBi -----END PGP SIGNATURE----- --Apple-Mail=_F968C22D-3025-4C79-AEFA-3CEF1D048CC6-- From internet-drafts@ietf.org Sun Jan 26 05:52:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D581A0147; Sun, 26 Jan 2014 05:52:54 -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 Px9yFd1dxjd8; Sun, 26 Jan 2014 05:52:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FB71A00F6; Sun, 26 Jan 2014 05:52:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140126135253.20618.49625.idtracker@ietfa.amsl.com> Date: Sun, 26 Jan 2014 05:52:53 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-moving-iana-registries-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 13:52:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Moving Generic Associated Channel (G-ACh) IANA Re= gistries to a New Registry Authors : Loa Andersson Carlos Pignataro Filename : draft-ietf-mpls-moving-iana-registries-04.txt Pages : 8 Date : 2014-01-26 Abstract: RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh) Parameters" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This document updates RFC 5586. This document also updates RFC 6374, RFC 6428, RFC 6378, RFC 6427, RFC-ietf-mpls-gach-adv, and RFC-ietf-mpls-tp-ethernet-addressing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-moving-iana-registries/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-moving-iana-registries-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-moving-iana-registries-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From curtis@ipv6.occnc.com Sun Jan 26 09:32:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2E21A000A for ; Sun, 26 Jan 2014 09:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RP_MATCHES_RCVD=-0.535, 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 NCR_7_lbqglA for ; Sun, 26 Jan 2014 09:32:51 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 052791A0004 for ; Sun, 26 Jan 2014 09:32:50 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0QHWVZW066572; Sun, 26 Jan 2014 12:32:32 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401261732.s0QHWVZW066572@maildrop2.v6ds.occnc.com> To: Xuxiaohu From: Curtis Villamizar In-reply-to: Your message of "Sun, 26 Jan 2014 03:48:06 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082480D2@NKGEML512-MBS.china.huawei.com> Date: Sun, 26 Jan 2014 12:32:31 -0500 Cc: "mpls@ietf.org" , "joelja@bogus.com" , "lars@netapp.com" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 17:32:55 -0000 In message <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082480D2@NKGEML512-MBS.china.huawei.com> Xuxiaohu writes: > > -----ÓʼþÔ­¼þ----- > > ·¢¼þÈË: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ26ÈÕ 4:25 > > ÊÕ¼þÈË: l.wood@surrey.ac.uk > > ³­ËÍ: Xuxiaohu; curtis@ipv6.occnc.com; Alexander.Vainshtein@ecitele.com; > > lars@netapp.com; joelja@bogus.com; mpls@ietf.org > > Ö÷Ìâ: Re: [mpls] Last Call: (Encapsulating MPLS > > in UDP) to Proposed Standard > > > > > > In message > > <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.a > > c.uk> > > l.wood@surrey.ac.uk writes: > > > > > Ah, make that: > > > > > > "Generally speaking, a UDP checksum SHOULD be used. The > > > considerations described in detail in [RFC6935] [RFC6936] MUST be > > > examined if UDP checksums need to be disabled for performance or > > > implementation reasons for traffic across private networks. The use > > > of a zero UDP checksum is NOT RECOMMENDED." > > > > > > ie if you're even thinking of turning off checksums, go read those > > > RFCs first. > > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > > This is fine with me but Xuxiaohu is the author. > > > > I would go a little further with the wording: > > > > Except in extroidinary cases, UDP checksum SHOULD be used. The > > considerations described in detail in [RFC6935] [RFC6936] MUST be > > examined if UDP checksums need to be disabled for performance or > > implementation reasons. UDP checksum should only be disabled on > > private networks or where MPLS in UDP encapsualation is added by a > > service provider with MPLS in UDP traffic entirely confined to the > > network of that service provider or cooperating service providers > > with explicit permission. > > > > Where it is not possible to use full UDP checksum, and if using > > UDP-Lite [RFC3828] is feasible, UDP-Lite SHOULD be used rather than > > UDP with disabled checksums. > > > > Is this better? > > > > Xuxiaohu - is this OK with you? > > Hi Curtis, > > Most of the above text looks fine to me. However, I just wonder > whether it is feasible to use UDP-lite tunnel for improving > load-balancing in practice. > > Best regards, > Xiaohu It is probably not feasible today. The text says "... and if using UDP-Lite [RFC3828] is feasible" and also says SHOULD. Infeasibility due to congestion that would occur as a result of lack of load balance for UDP-Lite would be a reason to go against the SHOULD. The reason the SHOULD is put there for full UDP checksum and then the second SHOULD is there for UDP-Lite has to be considered and the nature of the intended deployment needs to be considered before going against the recommendation. This text allows zero checksums in extraordinary cases (spelled wrong above), but discourages them. Curtis > > Curtis > > > > > > > From: Wood L Dr (Electronic Eng) > > > Sent: 24 January 2014 05:00 > > > To: Xuxiaohu; curtis@ipv6.occnc.com > > > Cc: Alexander.Vainshtein@ecitele.com; lars@netapp.com; > > > joelja@bogus.com; mpls@ietf.org > > > Subject: RE: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > I would be good with: > > > > > > "Generally speaking, a UDP checksum SHOULD be used. The considerations > > described in [RFC6935] [RFC6936] SHOULD be examined if UDP checksums > > need to be disabled for performance or implementation reasons for traffic > > across private networks. The use of a zero UDP checksum is NOT > > RECOMMENDED." > > > > > > I wouldn't make this IPv6 specific - IPv4 still has problems (UDP port demux), > > IPv6's problems are just worse. > > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: Xuxiaohu [xuxiaohu@huawei.com] > > > Sent: 24 January 2014 04:00 > > > To: curtis@ipv6.occnc.com; Wood L Dr (Electronic Eng) > > > Cc: Alexander.Vainshtein@ecitele.com; lars@netapp.com; > > > joelja@bogus.com; mpls@ietf.org > > > Subject: re: [mpls] Last Call: > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > Hi, > > > > > > Please check whether the following text is OK. > > > > > > In the IPv6 UDP encapsulation case, as for whether or not it is suitable to use > > the zero-checksum node, the requirements defined in [RFC6935] [RFC6936] > > SHOULD be strictly followed. Generally speaking, the use of a zero UDP > > checksum is NOT RECOMMENDED. Note that other IP encapsulations for MPLS > > do not have a checksum in the tunnel header. > > > > > > Best regards, > > > Xiaohu > > > > > > > -----ÓʼþÔ­¼þ----- > > > > ·¢¼þÈË: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ24ÈÕ 11:53 > > > > ÊÕ¼þÈË: l.wood@surrey.ac.uk > > > > ³­ËÍ: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com; > > > > joelja@bogus.com; mpls@ietf.org > > > > Ö÷Ìâ: Re: [mpls] Last Call: > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > > > In message > > > > > > <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.a > > > > c.uk> > > > > l.wood@surrey.ac.uk writes: > > > > > > > > > the text is not satisfactory. never recommend setting to zero, as > > > > > that poses a risk to your and to other traffic. Suggested text: > > > > > *** > > > > > The UDP checksum SHOULD be used to protect the payload and ensure > > > > > correct demultiplexing and delivery to the tunnel, and not to > > > > > other UDP destinations, by protecting the UDP pseudoheader. > > > > > Use of a zero UDP checksum is NOT RECOMMENDED, even when desired > > > > > for performance or necessitated by implementation reasons, for the > > > > > reasons outlined in [RFC6936] section 3. > > > > > > > > I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to > > zero). > > > > There are cases where it is impossible so it can't be MUST. > > > > > > > > > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS > > > > > stack integrity check while avoiding the overhead of computing an > > > > > integrity check over a tunnelled frame that has its own integrity check. > > > > > > > > UDP-List doesn't solve the ECMP problems because most of the older > > > > LSR that are forcing the use of MPLS over UDP to get ECMP don't look > > > > at the port numbers if the protocol is not 6 or 17. But this has > > > > only been said three or four times so maybe you missed it. > > > > > > > > > *** > > > > > > > > > > Lloyd Wood > > > > > http://about.me/lloydwood > > > > > ________________________________________ > > > > > From: Xuxiaohu [xuxiaohu@huawei.com] > > > > > Sent: 23 January 2014 12:35 > > > > > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; > > > > > lars@netapp.com > > > > > Cc: joelja@bogus.com; mpls@ietf.org > > > > > Subject: re: [mpls] Last Call: > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > > -----ÓʼþÔ­¼þ----- > > > > > > ·¢¼þÈË: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ23ÈÕ 12:44 > > > > > > ÊÕ¼þÈË: Xuxiaohu; Alexander.Vainshtein@ecitele.com; > > lars@netapp.com > > > > > > ³­ËÍ: joelja@bogus.com; mpls@ietf.org > > > > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > > > Sasha > > > > > > > > > > > > > - UDP checksums (or lack thereof) is a non-issue because > > > > > > > native MPLS does not have anything like that. And yes, there > > > > > > > are cases where packets are corrupted within the routers) > > > > > > > > > > > > So you admit that packets can be corrupted within the routers - > > > > > > a check that can only be caught by an end-to-end check, a > > > > > > corruption that can lead to the problems detailed in RFC 6936 > > > > > > section 3 - and then you say it's a non-issue because this > > > > > > doesn't affect native MPLS. But > > > > we're not doing native MPLS here. > > > > > > We're doing MPLS over UDP. > > > > > > > > > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's an > > issue. > > > > > > Please read the other 150 messages that you refer to. > > > > > > > > > > Hi Lloyd, > > > > > > > > > > The draft doesn't require the IPv6 UDP checksum to be set to zero > > regardless. > > > > See the following text quoted from that draft: > > > > > > > > > > UDP Checksum > > > > > > > > > > The usage of this field is in accordance with the current UDP > > > > > specification > > > > [RFC768]. To simplify the operation on the decapsulator, this field > > > > is RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In > > > > the IPv6 UDP encapsulation case, if appropriate according to the > > > > requirements defined in [RFC6935] [RFC6936], this field is also > > RECOMMENDED to be set to zero. > > > > Specifically, if the MPLS payload is Internet Protocol (IPv4 or > > > > IPv6) packets, it is RECOMMENDED to be set to zero when the inner > > > > packet integrity checks is available. In addition, if the MPLS > > > > payload is non-IP packet which is specifically designed for > > > > transmission over a lower layer that does not provide a packet > > > > integrity guarantee, it is RECOMMENDED to be set to zero as well. > > > > Otherwise, using zero checksum is NOT RECOMMENDED. Note that other IP > > encapsulations for MPLS do not have a checksum in the tunnel header. > > > > > > > > > > If you still believe the above text is not satisfactory, please provide your > > text. > > > > > > > > > > Best regards, > > > > > Xiaohu > > > > > > > > > > > Lloyd Wood > > > > > > http://about.me/lloydwood > > > > > > ________________________________________ > > > > > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > > > > [xuxiaohu@huawei.com] > > > > > > Sent: 23 January 2014 03:16 > > > > > > To: Alexander Vainshtein; Eggert, Lars > > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > > Subject: Re: [mpls] Last Call: > > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > > > Hi > > > > > > > > > > > > > -----ÓʼþÔ­¼þ----- > > > > > > > ·¢¼þÈË: Alexander Vainshtein > > > > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ22ÈÕ 19:05 > > > > > > > ÊÕ¼þÈË: Eggert, Lars > > > > > > > ³­ËÍ: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > > > > > Ö÷Ìâ: RE: [mpls] Last Call: > > > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > > > > > Lars and all, > > > > > > > Last time I've counted the IETF LC thread on this draft has > > > > > > > more than > > > > > > > 150 messages in it, and it seems that on some issues > > > > > > > (congestion control and UDP > > > > > > > checksums) we are going round the mulberry bush. > > > > > > > > > > > > > > IMHO and FWIW: > > > > > > > - UDP checksums (or lack thereof) is a non-issue because > > > > > > > native MPLS does not have anything like that. And yes, there > > > > > > > are cases where packets are corrupted within the routers), but > > > > > > > so far it did not prevent MPLS deployment. There is, e.g., RFC > > > > > > > 4720 for FCS retention in PWs, but I doubt it is widely > > > > > > > implemented and deployed (would be nice to > > > > > > know). > > > > > > > - E2E congestion control (regardless of its implications) > > > > > > > simply cannot be added to this protocol without some major > > > > > > > changes. A short applicability statement explaining that should suffice > > IMO. > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > I fully agree with your points. > > > > > > > > > > > > Best regards, > > > > > > Xiaohu > > > > > > > > > > > > > My 2c, > > > > > > > Sasha > > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > Mobile: 054-9266302 > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of > > > > > > > > Eggert, Lars > > > > > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > > > > > To: Xuxiaohu > > > > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > > > > Subject: Re: [mpls] Last Call: > > > > > > > > (Encapsulating MPLS in UDP) > > > > > > > > to Proposed Standard > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu wrote: > > > > > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to > > > > > > > > > be > > > > > > > > forwarded through "UDP tunnels", the congestion control > > > > > > > > guidelines for UDP tunnels as defined in Section 3.1.3 of > > > > > > > > [RFC5405] SHOULD be > > > > > > followed. > > > > > > > > Specifically, MPLS can carry a number of different protocols as > > payloads. > > > > > > > > When an UDP tunnel is used for MPLS payload traffic that is > > > > > > > > known at configuration time to be IP-based and > > > > > > > > congestion-controlled, the UDP tunnel SHOULD NOT employ its > > > > > > > > own congestion control mechanism, because congestion losses > > > > > > > > of tunneled traffic will trigger an congestion response at > > > > > > > > the original > > > > senders of the tunneled traffic. > > > > > > > > When an UDP tunnel is used for MPLS payload traffic that is > > > > > > > > known at configuration time not to be IP-based and > > > > > > > > congestion-controlled, the UDP tunnel SHOULD employ an > > > > > > > > appropriate congestion control mechanism as described in > > > > > > > > [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such > > > > > > > > encapsulation technology only within a SP network or > > > > > > > > networks of an adjacent set of co-operating SPs, rather than > > > > > > > > over the > > > > > > Internet. > > > > > > > > Furthermore, packet filters should be added to block traffic > > > > > > > > with the UDP port number for MPLS over UDP to prevent MPLS > > > > > > > > over UDP packets to escape from the service provider > > > > > > > > networks due to misconfiguation or packet > > > > > > > errors. > > > > > > > > > > > > > > > > I think it would be better to describe the OAM control loop > > > > > > > > in > > > > > > > > (some) more detail, rather than pointing to RFC3985, which > > > > > > > > doesn't have a whole lot of detail either. Also because the > > > > > > > > adding of firewall rules requires an OAM hook. > > > > > > > > > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > > > > > RECOMMENDED is > > > > > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > > > > > > > > > Finally, the applicability statement should be prominently > > > > > > > > made in the abstract, introduction, etc. > > > > > > > > > > > > > > > > Lars From adrian@olddog.co.uk Sun Jan 26 10:02:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55191A0075 for ; Sun, 26 Jan 2014 10:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 JuzRmwm3P6DE for ; Sun, 26 Jan 2014 10:02:16 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id DCCB81A000A for ; Sun, 26 Jan 2014 10:02:15 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0QI2CAr020780; Sun, 26 Jan 2014 18:02:12 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0QI2Afw020761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 Jan 2014 18:02:11 GMT From: "Adrian Farrel" To: Date: Sun, 26 Jan 2014 18:02:08 -0000 Message-ID: <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8awLdikHZ/QNhcSpu9YE2obZKKtA== Content-Language: en-gb X-TM-AS-MML: No Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 18:02:19 -0000 Hi, Thank you for a really thorough and clear document. I have done my usual AD review upon receiving the publication request for this document. The purpose of the review is to catch any issues that might otherwise show up in IETF last call and IESG evaluation. In this case it is also an extra pair of eyes on what is a very detailed document. I have a number of comments below. A few are editorial nits (sorry) and some are questions for clarification of the text. There is very little where I come even remotely close to saying "wrong" or missing". It looks to me that a new revision would be useful just to mop up these comments, so I have put the document into "Revised I-D Needed" state and will wait to see the next revision before starting the IETF last call. Please debate any issues where you disagree with me or think that no document change is needed. Thanks for the work, Adrian === idnits notes that... == Outdated reference: draft-ietf-pwe3-vccv-impl-survey-results has been published as RFC 7079 --- Andy may want to update his coordinates. --- Your acronym list is commendably thorough, but a little enthusiastic. AC is only used once and then only at the point of expansion. CE doesn't appear to be used at all FEC only seems to be used in this document in the context of Forwarding Equivalence Classes (LDP) The following are all well-known acronyms according to http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt so they don't need to be included BGP CPU DDoS DoS GMPLS IANA IP IPv4 IPv6 LDP MPLS NTP QoS RTP TCP UDP WG I think Curtis may have heard this before :-) The "preferred" (by the RFC editor) expansion of ECMP is "Equal-Cost Multipath" Several acronyms are qualified with (LDP) (CE, FEC, P, PE). I haven't checked the usage in this document, but it seems to me that the terms might have wider applicability. Indeed, a quick search revealed "RSVP-TE PE". The third expansion of PSC could have a reference to RFC 6378. I think that to avoid confusion, you need to expand this in the text when you use it. You do this well everywhere except in Section 4.7 T#32, and in this acronym list itself at E-LSP and L-LSP. --- Section 1.3 bullet 5 5. The implementer and system designer MUST support pseudowire control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is being used on a pseudowire. The wording is a bit odd. "The implementation and system design..."? Ditto bullets 6 and 7 --- Section 1.3 While there is not wrong with the statements made in the bullets, some of the later ones refer to recent additions to the MPLS suite. Yet the list is presented as "there were some misconceptions." Clearly the early silicon did not have misconceptions about the inclusion of entropy labels. Just tweak the words at the top of the list? --- Section 2.1 Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, L2TP, or LDP, are out of scope. I think s/LDP/UDP/ --- 2.1.1 Maybe the first paragraph should clarify "special purpose labels at the top of the label stack" --- 2.1.1 I think that this section should note that labels 0-15 were commonly referred to as "reserved labels" and are only renamed to "special purpose labels" by [I-D.ietf-mpls-special-purpose-labels]. --- 2.1.4 MPLS hierarchy as described in [RFC4206] can in principle add up to four additional labels. MPLS hierarchy is discussed in Section 2.1.6. Similar text in 2.1.6 I wonder whether the choice of "four" here is because RFC 4203 defines 1 Packet-Switch Capable-1 (PSC-1) 2 Packet-Switch Capable-2 (PSC-2) 3 Packet-Switch Capable-3 (PSC-3) 4 Packet-Switch Capable-4 (PSC-4) If that is the case, we should note that RFC 7074 deprecates PSC-2 through 4 recognising that different switching levels within the PSC world were not applied and that LSP nesting was arbitrary and not limited to four levels. On the other hand, if "four" comes from somewhere else, perhaps you could give a clue in the text. --- While per platform label space is mentioned in 2.1.7 I wonder whether more information on per platform and per interface label spaces is needed. I recall early implementations that got very confused when parallel interfaces used the same label for different purposes. I guess the point there is that you cannot assume that your neighbor is or is not using the per platform label space. Upstream label allocation may also come into this. --- 2.1.8.1 1. The most common case is where reordering occurs is rare, One too many instances of "is" --- 2.1.8.1 3. If the edge is not using pseudowire control word (CW) and the core is using multipath, reordering will be far more common. If this is occurring, the best solution is to use CW on the edge, rather than try to fix the reordering using resequencing. Completely agree, but isn't the sequence number contained in a control word meaning that the resequencing could, in any case, not be done without using a control word? --- 2.1.8.1 4. Another avoidable case is where some core equipment has multipath and for some reason insists on periodically installing a new random number as the multipath hash seed. If supporting MPLS-TP, equipment MUST provide a means to disable periodic hash reseeding and deployments MUST disable periodic hash reseeding. Even if not supporting MPLS-TP, equipment should provide a means to disable periodic hash reseeding and deployments should disable periodic hash reseeding. Are those two "should" really "SHOULD"? --- Should 2.2 distinguish the order of magnitude of replication at branch nodes? This impacts the replication method used (some devices make a copy and cycle around, some devices can do multiple copies at once). On the whole is no different from IP multicast processing except (as you note) that each outgoing packet may be different by its label value. --- 2.4 So obvious you didn't say it? In order to support an adequately balanced load distribution across multiple links, IP header information must be used. Common practice today is to reinspect the IP headers at each LSR and use the label stack and IP header information in a hash performed at each LSR. Further details are provided in Section 2.4.5. Missing is the statement that a single "flow" must not be distributed across multiple paths because of the implication for potentially significant packet misordering. And feeding that is a common requirement that such packet misordering must not occur because applications and transport protocol implementations cannot survive such misordering. --- 2.4.2 uses "composite link" and "component link". I suggest picking just one term. --- 2.4.5.1 notes that special purpose and extended special purpose labels need to be excluded from the hash. Good. But it seems that some special purpose labels will indicate that the next label stack entry contains a label with special meaning. (ELI is an example that we specifically don't have to worry about.) How do we handle that? Should we be dividing up the extended special purpose label space to have one set of code points meaning "just this label is special" and another set meaning "this label is special and the next label stack entry is magic"? --- An issue that arises from the multipath support (2.4.5.1) is that hardware assumes that after a label stack entry with the S-bit set, there are only three possible next bytes... - a control word (indicated by b0000 or b0001) - an IPv4 header - an IPv6 header This is the case regardless of how the LSP was set up, and the next bytes cannot ever be further MPLS stack entries. While this comes up 2.4.5.1 it may merit further discussion in an earlier section of the document. I note that discussion of support of PWs without the CW drives you to say that hashing beyond the S-bit should be a configurable option which would (of course) support any payload including MPLS in MPLS with repeated bottom of stack. However, you might want to specifically preclude that. --- Q#7 introduces the terms "short-pipe" and "uniform model". It provides a pointer to 2.1.6, but that section does not mention these terms (and doesn't refer to RFC 3270). --- Section 7 could usefully point back at Section 2.6.1 From xuxiaohu@huawei.com Sun Jan 26 16:28:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CEE1A016C for ; Sun, 26 Jan 2014 16:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 2hKF0gp2k4Ea for ; Sun, 26 Jan 2014 16:28:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0081E1A0169 for ; Sun, 26 Jan 2014 16:28:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCY24585; Mon, 27 Jan 2014 00:28:19 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 00:27:51 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 00:28:17 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 27 Jan 2014 08:28:14 +0800 From: Xuxiaohu To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGryXVpx4VpP9lE+4fynfG27EApqXtnUA Date: Mon, 27 Jan 2014 00:28:14 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824825E@NKGEML512-MBS.china.huawei.com> References: Your message of "Sun, 26 Jan 2014 03:48:06 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082480D2@NKGEML512-MBS.china.huawei.com> <201401261732.s0QHWVZW066572@maildrop2.v6ds.occnc.com> In-Reply-To: <201401261732.s0QHWVZW066572@maildrop2.v6ds.occnc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "joelja@bogus.com" , "mpls@ietf.org" , "lars@netapp.com" Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 00:28:32 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogQ3VydGlzIFZpbGxhbWl6YXIgW21h aWx0bzpjdXJ0aXNAaXB2Ni5vY2NuYy5jb21dDQo+ILeiy83KsbzkOiAyMDE0xOox1MIyN8jVIDE6 MzMNCj4gytW8/sjLOiBYdXhpYW9odQ0KPiCzrcvNOiBjdXJ0aXNAaXB2Ni5vY2NuYy5jb207IGwu d29vZEBzdXJyZXkuYWMudWs7DQo+IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBs YXJzQG5ldGFwcC5jb207IGpvZWxqYUBib2d1cy5jb207DQo+IG1wbHNAaWV0Zi5vcmcNCj4g1vfM 4jogUmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4g KEVuY2Fwc3VsYXRpbmcgTVBMUw0KPiBpbiBVRFApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0K PiANCj4gSW4gbWVzc2FnZQ0KPiA8MUZFRTNGOEY1Q0NERTY0QzlBOEU4RjRBRDI3QzE5RUUwODI0 ODBEMkBOS0dFTUw1MTItTUJTLmNoaW5hLg0KPiBodWF3ZWkuY29tPg0KPiBYdXhpYW9odSB3cml0 ZXM6DQo+IA0KPiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gPiC3orz+yMs6IEN1cnRpcyBW aWxsYW1pemFyIFttYWlsdG86Y3VydGlzQGlwdjYub2NjbmMuY29tXQ0KPiA+ID4gt6LLzcqxvOQ6 IDIwMTTE6jHUwjI2yNUgNDoyNQ0KPiA+ID4gytW8/sjLOiBsLndvb2RAc3VycmV5LmFjLnVrDQo+ ID4gPiCzrcvNOiBYdXhpYW9odTsgY3VydGlzQGlwdjYub2NjbmMuY29tOw0KPiA+ID4gQWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBwLmNvbTsgam9lbGphQGJvZ3Vz LmNvbTsNCj4gPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiA+INb3zOI6IFJlOiBbbXBsc10gTGFzdCBD YWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4gPiAoRW5jYXBzdWxhdGlu ZyBNUExTIGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+DQo+ID4gPg0KPiA+ID4g SW4gbWVzc2FnZQ0KPiA+ID4NCj4gPDI5MEUyMEI0NTVDNjY3NDNCRTE3OEM1Qzg0RjEyNDA4NDdF NjMzNDZFRUBFWE1CMDFDTVMuc3VycmV5LmENCj4gPiA+IGMudWs+DQo+ID4gPiBsLndvb2RAc3Vy cmV5LmFjLnVrIHdyaXRlczoNCj4gPiA+DQo+ID4gPiA+IEFoLCBtYWtlIHRoYXQ6DQo+ID4gPiA+ DQo+ID4gPiA+ICAgICJHZW5lcmFsbHkgc3BlYWtpbmcsIGEgVURQIGNoZWNrc3VtIFNIT1VMRCBi ZSB1c2VkLiBUaGUNCj4gPiA+ID4gICAgY29uc2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluIGRldGFp bCBpbiBbUkZDNjkzNV0gW1JGQzY5MzZdIE1VU1QgYmUNCj4gPiA+ID4gICAgZXhhbWluZWQgaWYg VURQIGNoZWNrc3VtcyBuZWVkIHRvIGJlIGRpc2FibGVkIGZvciBwZXJmb3JtYW5jZSBvcg0KPiA+ ID4gPiAgICBpbXBsZW1lbnRhdGlvbiByZWFzb25zIGZvciB0cmFmZmljIGFjcm9zcyBwcml2YXRl IG5ldHdvcmtzLiBUaGUgdXNlDQo+ID4gPiA+ICAgIG9mIGEgemVybyBVRFAgY2hlY2tzdW0gaXMg Tk9UIFJFQ09NTUVOREVELiINCj4gPiA+ID4NCj4gPiA+ID4gaWUgaWYgeW91J3JlIGV2ZW4gdGhp bmtpbmcgb2YgdHVybmluZyBvZmYgY2hlY2tzdW1zLCBnbyByZWFkIHRob3NlDQo+ID4gPiA+IFJG Q3MgZmlyc3QuDQo+ID4gPiA+DQo+ID4gPiA+IExsb3lkIFdvb2QNCj4gPiA+ID4gaHR0cDovL2Fi b3V0Lm1lL2xsb3lkd29vZA0KPiA+ID4NCj4gPiA+IFRoaXMgaXMgZmluZSB3aXRoIG1lIGJ1dCBY dXhpYW9odSBpcyB0aGUgYXV0aG9yLg0KPiA+ID4NCj4gPiA+IEkgd291bGQgZ28gYSBsaXR0bGUg ZnVydGhlciB3aXRoIHRoZSB3b3JkaW5nOg0KPiA+ID4NCj4gPiA+ICAgRXhjZXB0IGluIGV4dHJv aWRpbmFyeSBjYXNlcywgVURQIGNoZWNrc3VtIFNIT1VMRCBiZSB1c2VkLiBUaGUNCj4gPiA+ICAg Y29uc2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluIGRldGFpbCBpbiBbUkZDNjkzNV0gW1JGQzY5MzZd IE1VU1QgYmUNCj4gPiA+ICAgZXhhbWluZWQgaWYgVURQIGNoZWNrc3VtcyBuZWVkIHRvIGJlIGRp c2FibGVkIGZvciBwZXJmb3JtYW5jZSBvcg0KPiA+ID4gICBpbXBsZW1lbnRhdGlvbiByZWFzb25z LiAgVURQIGNoZWNrc3VtIHNob3VsZCBvbmx5IGJlIGRpc2FibGVkIG9uDQo+ID4gPiAgIHByaXZh dGUgbmV0d29ya3Mgb3Igd2hlcmUgTVBMUyBpbiBVRFAgZW5jYXBzdWFsYXRpb24gaXMgYWRkZWQg YnkgYQ0KPiA+ID4gICBzZXJ2aWNlIHByb3ZpZGVyIHdpdGggTVBMUyBpbiBVRFAgdHJhZmZpYyBl bnRpcmVseSBjb25maW5lZCB0byB0aGUNCj4gPiA+ICAgbmV0d29yayBvZiB0aGF0IHNlcnZpY2Ug cHJvdmlkZXIgb3IgY29vcGVyYXRpbmcgc2VydmljZSBwcm92aWRlcnMNCj4gPiA+ICAgd2l0aCBl eHBsaWNpdCBwZXJtaXNzaW9uLg0KPiA+ID4NCj4gPiA+ICAgV2hlcmUgaXQgaXMgbm90IHBvc3Np YmxlIHRvIHVzZSBmdWxsIFVEUCBjaGVja3N1bSwgYW5kIGlmIHVzaW5nDQo+ID4gPiAgIFVEUC1M aXRlIFtSRkMzODI4XSBpcyBmZWFzaWJsZSwgVURQLUxpdGUgU0hPVUxEIGJlIHVzZWQgcmF0aGVy IHRoYW4NCj4gPiA+ICAgVURQIHdpdGggZGlzYWJsZWQgY2hlY2tzdW1zLg0KPiA+ID4NCj4gPiA+ IElzIHRoaXMgYmV0dGVyPw0KPiA+ID4NCj4gPiA+IFh1eGlhb2h1IC0gaXMgdGhpcyBPSyB3aXRo IHlvdT8NCj4gPg0KPiA+IEhpIEN1cnRpcywNCj4gPg0KPiA+IE1vc3Qgb2YgdGhlIGFib3ZlIHRl eHQgbG9va3MgZmluZSB0byBtZS4gSG93ZXZlciwgSSBqdXN0IHdvbmRlcg0KPiA+IHdoZXRoZXIg aXQgaXMgZmVhc2libGUgdG8gdXNlIFVEUC1saXRlIHR1bm5lbCBmb3IgaW1wcm92aW5nDQo+ID4g bG9hZC1iYWxhbmNpbmcgaW4gcHJhY3RpY2UuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4g WGlhb2h1DQo+IA0KPiANCj4gSXQgaXMgcHJvYmFibHkgbm90IGZlYXNpYmxlIHRvZGF5LiAgVGhl IHRleHQgc2F5cyAiLi4uIGFuZCBpZiB1c2luZyBVRFAtTGl0ZQ0KPiBbUkZDMzgyOF0gaXMgZmVh c2libGUiIGFuZCBhbHNvIHNheXMgU0hPVUxELiAgSW5mZWFzaWJpbGl0eSBkdWUgdG8gY29uZ2Vz dGlvbg0KPiB0aGF0IHdvdWxkIG9jY3VyIGFzIGEgcmVzdWx0IG9mIGxhY2sgb2YgbG9hZCBiYWxh bmNlIGZvciBVRFAtTGl0ZSB3b3VsZCBiZSBhDQo+IHJlYXNvbiB0byBnbyBhZ2FpbnN0IHRoZSBT SE9VTEQuICBUaGUgcmVhc29uIHRoZSBTSE9VTEQgaXMgcHV0IHRoZXJlIGZvciBmdWxsDQo+IFVE UCBjaGVja3N1bSBhbmQgdGhlbiB0aGUgc2Vjb25kIFNIT1VMRCBpcyB0aGVyZSBmb3IgVURQLUxp dGUgaGFzIHRvIGJlDQo+IGNvbnNpZGVyZWQgYW5kIHRoZSBuYXR1cmUgb2YgdGhlIGludGVuZGVk IGRlcGxveW1lbnQgbmVlZHMgdG8gYmUgY29uc2lkZXJlZA0KPiBiZWZvcmUgZ29pbmcgYWdhaW5z dCB0aGUgcmVjb21tZW5kYXRpb24uDQo+IA0KPiBUaGlzIHRleHQgYWxsb3dzIHplcm8gY2hlY2tz dW1zIGluIGV4dHJhb3JkaW5hcnkgY2FzZXMgKHNwZWxsZWQgd3JvbmcgYWJvdmUpLA0KPiBidXQg ZGlzY291cmFnZXMgdGhlbS4NCg0KSGkgQ3VydGlzLA0KDQpUaGF0J3MgZmluZS4gVGhhbmtzIGEg bG90IGZvciB5b3VyIHZhbHVhYmxlIHN1Z2dlc3Rpb25zLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFv aHUNCg0KPiBDdXJ0aXMNCj4gDQo+IA0KPiA+ID4gQ3VydGlzDQo+ID4gPg0KPiA+ID4NCj4gPiA+ ID4gRnJvbTogV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpDQo+ID4gPiA+IFNlbnQ6IDI0IEph bnVhcnkgMjAxNCAwNTowMA0KPiA+ID4gPiBUbzogWHV4aWFvaHU7IGN1cnRpc0BpcHY2Lm9jY25j LmNvbQ0KPiA+ID4gPiBDYzogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNA bmV0YXBwLmNvbTsNCj4gPiA+ID4gam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ ID4gPiBTdWJqZWN0OiBSRTogW21wbHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbXBscy1pbi11 ZHAtMDQudHh0Pg0KPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9z ZWQgU3RhbmRhcmQNCj4gPiA+ID4NCj4gPiA+ID4gSSB3b3VsZCBiZSBnb29kIHdpdGg6DQo+ID4g PiA+DQo+ID4gPiA+ICJHZW5lcmFsbHkgc3BlYWtpbmcsIGEgVURQIGNoZWNrc3VtIFNIT1VMRCBi ZSB1c2VkLiBUaGUNCj4gPiA+ID4gY29uc2lkZXJhdGlvbnMNCj4gPiA+IGRlc2NyaWJlZCBpbiBb UkZDNjkzNV0gW1JGQzY5MzZdIFNIT1VMRCBiZSBleGFtaW5lZCBpZiBVRFAgY2hlY2tzdW1zDQo+ ID4gPiBuZWVkIHRvIGJlIGRpc2FibGVkIGZvciBwZXJmb3JtYW5jZSBvciBpbXBsZW1lbnRhdGlv biByZWFzb25zIGZvcg0KPiA+ID4gdHJhZmZpYyBhY3Jvc3MgcHJpdmF0ZSBuZXR3b3Jrcy4gVGhl IHVzZSBvZiBhIHplcm8gVURQIGNoZWNrc3VtIGlzDQo+ID4gPiBOT1QgUkVDT01NRU5ERUQuIg0K PiA+ID4gPg0KPiA+ID4gPiBJIHdvdWxkbid0IG1ha2UgdGhpcyBJUHY2IHNwZWNpZmljIC0gSVB2 NCBzdGlsbCBoYXMgcHJvYmxlbXMgKFVEUA0KPiA+ID4gPiBwb3J0IGRlbXV4KSwNCj4gPiA+IElQ djYncyBwcm9ibGVtcyBhcmUganVzdCB3b3JzZS4NCj4gPiA+ID4NCj4gPiA+ID4gTGxveWQgV29v ZA0KPiA+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ID4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRnJvbTogWHV4aWFvaHUgW3h1 eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiA+IFNlbnQ6IDI0IEphbnVhcnkgMjAxNCAwNDowMA0K PiA+ID4gPiBUbzogY3VydGlzQGlwdjYub2NjbmMuY29tOyBXb29kIEwgIERyIChFbGVjdHJvbmlj IEVuZykNCj4gPiA+ID4gQ2M6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBsYXJz QG5ldGFwcC5jb207DQo+ID4gPiA+IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4g PiA+ID4gU3ViamVjdDogcmU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtaW4t dWRwLTA0LnR4dD4NCj4gPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bv c2VkIFN0YW5kYXJkDQo+ID4gPiA+DQo+ID4gPiA+IEhpLA0KPiA+ID4gPg0KPiA+ID4gPiBQbGVh c2UgY2hlY2sgd2hldGhlciB0aGUgZm9sbG93aW5nIHRleHQgaXMgT0suDQo+ID4gPiA+DQo+ID4g PiA+IEluIHRoZSBJUHY2IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2UsIGFzIGZvciB3aGV0aGVyIG9y IG5vdCBpdCBpcw0KPiA+ID4gPiBzdWl0YWJsZSB0byB1c2UNCj4gPiA+IHRoZSB6ZXJvLWNoZWNr c3VtIG5vZGUsIHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbiBbUkZDNjkzNV0NCj4gPiA+IFtS RkM2OTM2XSBTSE9VTEQgYmUgc3RyaWN0bHkgZm9sbG93ZWQuIEdlbmVyYWxseSBzcGVha2luZywg dGhlIHVzZQ0KPiA+ID4gb2YgYSB6ZXJvIFVEUCBjaGVja3N1bSBpcyBOT1QgUkVDT01NRU5ERUQu IE5vdGUgdGhhdCBvdGhlciBJUA0KPiA+ID4gZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMgZG8gbm90 IGhhdmUgYSBjaGVja3N1bSBpbiB0aGUgdHVubmVsIGhlYWRlci4NCj4gPiA+ID4NCj4gPiA+ID4g QmVzdCByZWdhcmRzLA0KPiA+ID4gPiBYaWFvaHUNCj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLdPK vP7Urbz+LS0tLS0NCj4gPiA+ID4gPiC3orz+yMs6IEN1cnRpcyBWaWxsYW1pemFyIFttYWlsdG86 Y3VydGlzQGlwdjYub2NjbmMuY29tXQ0KPiA+ID4gPiA+ILeiy83KsbzkOiAyMDE0xOox1MIyNMjV IDExOjUzDQo+ID4gPiA+ID4gytW8/sjLOiBsLndvb2RAc3VycmV5LmFjLnVrDQo+ID4gPiA+ID4g s63LzTogWHV4aWFvaHU7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tOyBsYXJzQG5l dGFwcC5jb207DQo+ID4gPiA+ID4gam9lbGphQGJvZ3VzLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ ID4gPiA+INb3zOI6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVk cC0wNC50eHQ+DQo+ID4gPiA+ID4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFApIHRvIFByb3Bv c2VkIFN0YW5kYXJkDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEluIG1lc3NhZ2UN Cj4gPiA+ID4gPg0KPiA+ID4NCj4gPDI5MEUyMEI0NTVDNjY3NDNCRTE3OEM1Qzg0RjEyNDA4NDdF NjMzNDZFM0BFWE1CMDFDTVMuc3VycmV5LmENCj4gPiA+ID4gPiBjLnVrPg0KPiA+ID4gPiA+IGwu d29vZEBzdXJyZXkuYWMudWsgd3JpdGVzOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiB0aGUgdGV4 dCBpcyBub3Qgc2F0aXNmYWN0b3J5LiBuZXZlciByZWNvbW1lbmQgc2V0dGluZyB0byB6ZXJvLA0K PiA+ID4gPiA+ID4gYXMgdGhhdCBwb3NlcyBhIHJpc2sgdG8geW91ciBhbmQgdG8gb3RoZXIgdHJh ZmZpYy4gU3VnZ2VzdGVkIHRleHQ6DQo+ID4gPiA+ID4gPiAqKioNCj4gPiA+ID4gPiA+IFRoZSBV RFAgY2hlY2tzdW0gU0hPVUxEIGJlIHVzZWQgdG8gcHJvdGVjdCB0aGUgcGF5bG9hZCBhbmQNCj4g PiA+ID4gPiA+IGVuc3VyZSBjb3JyZWN0IGRlbXVsdGlwbGV4aW5nIGFuZCBkZWxpdmVyeSB0byB0 aGUgdHVubmVsLCBhbmQNCj4gPiA+ID4gPiA+IG5vdCB0byBvdGhlciBVRFAgZGVzdGluYXRpb25z LCBieSBwcm90ZWN0aW5nIHRoZSBVRFAgcHNldWRvaGVhZGVyLg0KPiA+ID4gPiA+ID4gVXNlIG9m IGEgemVybyBVRFAgY2hlY2tzdW0gaXMgTk9UIFJFQ09NTUVOREVELCBldmVuIHdoZW4NCj4gPiA+ ID4gPiA+IGRlc2lyZWQgZm9yIHBlcmZvcm1hbmNlIG9yIG5lY2Vzc2l0YXRlZCBieSBpbXBsZW1l bnRhdGlvbg0KPiA+ID4gPiA+ID4gcmVhc29ucywgZm9yIHRoZSByZWFzb25zIG91dGxpbmVkIGlu IFtSRkM2OTM2XSBzZWN0aW9uIDMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGFncmVlIHRoYXQg VURQIGNoZWNrc3VtcyBTSE9VTEQgYmUgdXNlZCAoaWU6IFNIT1VMRCBOT1QgYmUgc2V0DQo+ID4g PiA+ID4gdG8NCj4gPiA+IHplcm8pLg0KPiA+ID4gPiA+IFRoZXJlIGFyZSBjYXNlcyB3aGVyZSBp dCBpcyBpbXBvc3NpYmxlIHNvIGl0IGNhbid0IGJlIE1VU1QuDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiA+IFVEUC1MaXRlIFtSRkMzODI4XSBjYW4gcHJvdmlkZSBhIGRlbXVsdGlwbGV4aW5nIGNoZWNr IGFuZCBNUExTDQo+ID4gPiA+ID4gPiBzdGFjayBpbnRlZ3JpdHkgY2hlY2sgd2hpbGUgYXZvaWRp bmcgdGhlIG92ZXJoZWFkIG9mIGNvbXB1dGluZw0KPiA+ID4gPiA+ID4gYW4gaW50ZWdyaXR5IGNo ZWNrIG92ZXIgYSB0dW5uZWxsZWQgZnJhbWUgdGhhdCBoYXMgaXRzIG93biBpbnRlZ3JpdHkNCj4g Y2hlY2suDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBVRFAtTGlzdCBkb2Vzbid0IHNvbHZlIHRoZSBF Q01QIHByb2JsZW1zIGJlY2F1c2UgbW9zdCBvZiB0aGUNCj4gPiA+ID4gPiBvbGRlciBMU1IgdGhh dCBhcmUgZm9yY2luZyB0aGUgdXNlIG9mIE1QTFMgb3ZlciBVRFAgdG8gZ2V0IEVDTVANCj4gPiA+ ID4gPiBkb24ndCBsb29rIGF0IHRoZSBwb3J0IG51bWJlcnMgaWYgdGhlIHByb3RvY29sIGlzIG5v dCA2IG9yIDE3Lg0KPiA+ID4gPiA+IEJ1dCB0aGlzIGhhcyBvbmx5IGJlZW4gc2FpZCB0aHJlZSBv ciBmb3VyIHRpbWVzIHNvIG1heWJlIHlvdSBtaXNzZWQgaXQuDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ICoqKg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IExsb3lkIFdvb2QNCj4gPiA+ID4gPiA+ IGh0dHA6Ly9hYm91dC5tZS9sbG95ZHdvb2QNCj4gPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+IEZyb206IFh1eGlhb2h1IFt4dXhp YW9odUBodWF3ZWkuY29tXQ0KPiA+ID4gPiA+ID4gU2VudDogMjMgSmFudWFyeSAyMDE0IDEyOjM1 DQo+ID4gPiA+ID4gPiBUbzogV29vZCBMICBEciAoRWxlY3Ryb25pYyBFbmcpOw0KPiA+ID4gPiA+ ID4gQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IGxhcnNAbmV0YXBwLmNvbQ0KPiA+ ID4gPiA+ID4gQ2M6IGpvZWxqYUBib2d1cy5jb207IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ IFN1YmplY3Q6IHJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0w NC50eHQ+DQo+ID4gPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUCkgdG8gUHJvcG9z ZWQgU3RhbmRhcmQNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0t LQ0KPiA+ID4gPiA+ID4gPiC3orz+yMs6IGwud29vZEBzdXJyZXkuYWMudWsgW21haWx0bzpsLndv b2RAc3VycmV5LmFjLnVrXQ0KPiA+ID4gPiA+ID4gPiC3osvNyrG85DogMjAxNMTqMdTCMjPI1SAx Mjo0NA0KPiA+ID4gPiA+ID4gPiDK1bz+yMs6IFh1eGlhb2h1OyBBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTsNCj4gPiA+IGxhcnNAbmV0YXBwLmNvbQ0KPiA+ID4gPiA+ID4gPiCzrcvN OiBqb2VsamFAYm9ndXMuY29tOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gPiA+INb3zOI6IFJF OiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+DQo+ID4g PiA+ID4gPiA+IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFy ZA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBTYXNoYQ0KPiA+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gPiA+IC0gVURQIGNoZWNrc3VtcyAob3IgbGFjayB0aGVyZW9mKSBpcyBhIG5vbi1p c3N1ZSBiZWNhdXNlDQo+ID4gPiA+ID4gPiA+ID4gbmF0aXZlIE1QTFMgZG9lcyBub3QgaGF2ZSBh bnl0aGluZyBsaWtlIHRoYXQuIEFuZCB5ZXMsDQo+ID4gPiA+ID4gPiA+ID4gdGhlcmUgYXJlIGNh c2VzIHdoZXJlIHBhY2tldHMgYXJlIGNvcnJ1cHRlZCB3aXRoaW4gdGhlDQo+ID4gPiA+ID4gPiA+ ID4gcm91dGVycykNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gU28geW91IGFkbWl0IHRo YXQgcGFja2V0cyBjYW4gYmUgY29ycnVwdGVkIHdpdGhpbiB0aGUNCj4gPiA+ID4gPiA+ID4gcm91 dGVycyAtIGEgY2hlY2sgdGhhdCBjYW4gb25seSBiZSBjYXVnaHQgYnkgYW4gZW5kLXRvLWVuZA0K PiA+ID4gPiA+ID4gPiBjaGVjaywgYSBjb3JydXB0aW9uIHRoYXQgY2FuIGxlYWQgdG8gdGhlIHBy b2JsZW1zIGRldGFpbGVkDQo+ID4gPiA+ID4gPiA+IGluIFJGQyA2OTM2IHNlY3Rpb24gMyAtIGFu ZCB0aGVuIHlvdSBzYXkgaXQncyBhIG5vbi1pc3N1ZQ0KPiA+ID4gPiA+ID4gPiBiZWNhdXNlIHRo aXMgZG9lc24ndCBhZmZlY3QgbmF0aXZlIE1QTFMuIEJ1dA0KPiA+ID4gPiA+IHdlJ3JlIG5vdCBk b2luZyBuYXRpdmUgTVBMUyBoZXJlLg0KPiA+ID4gPiA+ID4gPiBXZSdyZSBkb2luZyBNUExTIG92 ZXIgVURQLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBkcmFmdC1pZXRmLW1wbHMtaW4t dWRwLTA0LnR4dCBpcyBhYm91dCB0dW5uZWxsaW5nIE1QTFMgaW4NCj4gPiA+ID4gPiA+ID4gVURQ LiBJdCdzIGFuDQo+ID4gPiBpc3N1ZS4NCj4gPiA+ID4gPiA+ID4gUGxlYXNlIHJlYWQgdGhlIG90 aGVyIDE1MCBtZXNzYWdlcyB0aGF0IHlvdSByZWZlciB0by4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiBIaSBMbG95ZCwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGUgZHJhZnQgZG9lc24n dCByZXF1aXJlIHRoZSBJUHY2IFVEUCBjaGVja3N1bSB0byBiZSBzZXQgdG8NCj4gPiA+ID4gPiA+ IHplcm8NCj4gPiA+IHJlZ2FyZGxlc3MuDQo+ID4gPiA+ID4gU2VlIHRoZSBmb2xsb3dpbmcgdGV4 dCBxdW90ZWQgZnJvbSB0aGF0IGRyYWZ0Og0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFVEUCBD aGVja3N1bQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoZSB1c2FnZSBvZiB0aGlzIGZpZWxk IGlzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgY3VycmVudCBVRFANCj4gPiA+ID4gPiA+IHNwZWNp ZmljYXRpb24NCj4gPiA+ID4gPiBbUkZDNzY4XS4gVG8gc2ltcGxpZnkgdGhlIG9wZXJhdGlvbiBv biB0aGUgZGVjYXBzdWxhdG9yLCB0aGlzDQo+ID4gPiA+ID4gZmllbGQgaXMgUkVDT01NRU5ERUQg dG8gYmUgc2V0IHRvIHplcm8gaW4gSVB2NCBVRFAgZW5jYXBzdWxhdGlvbg0KPiA+ID4gPiA+IGNh c2UuIEluIHRoZSBJUHY2IFVEUCBlbmNhcHN1bGF0aW9uIGNhc2UsIGlmIGFwcHJvcHJpYXRlDQo+ ID4gPiA+ID4gYWNjb3JkaW5nIHRvIHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbiBbUkZDNjkz NV0gW1JGQzY5MzZdLA0KPiA+ID4gPiA+IHRoaXMgZmllbGQgaXMgYWxzbw0KPiA+ID4gUkVDT01N RU5ERUQgdG8gYmUgc2V0IHRvIHplcm8uDQo+ID4gPiA+ID4gU3BlY2lmaWNhbGx5LCBpZiB0aGUg TVBMUyBwYXlsb2FkIGlzIEludGVybmV0IFByb3RvY29sIChJUHY0IG9yDQo+ID4gPiA+ID4gSVB2 NikgcGFja2V0cywgaXQgaXMgUkVDT01NRU5ERUQgdG8gYmUgc2V0IHRvIHplcm8gd2hlbiB0aGUN Cj4gPiA+ID4gPiBpbm5lciBwYWNrZXQgaW50ZWdyaXR5IGNoZWNrcyBpcyBhdmFpbGFibGUuIElu IGFkZGl0aW9uLCBpZiB0aGUNCj4gPiA+ID4gPiBNUExTIHBheWxvYWQgaXMgbm9uLUlQIHBhY2tl dCB3aGljaCBpcyBzcGVjaWZpY2FsbHkgZGVzaWduZWQgZm9yDQo+ID4gPiA+ID4gdHJhbnNtaXNz aW9uIG92ZXIgYSBsb3dlciBsYXllciB0aGF0IGRvZXMgbm90IHByb3ZpZGUgYSBwYWNrZXQNCj4g PiA+ID4gPiBpbnRlZ3JpdHkgZ3VhcmFudGVlLCBpdCBpcyBSRUNPTU1FTkRFRCB0byBiZSBzZXQg dG8gemVybyBhcyB3ZWxsLg0KPiA+ID4gPiA+IE90aGVyd2lzZSwgdXNpbmcgemVybyBjaGVja3N1 bSBpcyBOT1QgUkVDT01NRU5ERUQuIE5vdGUgdGhhdA0KPiA+ID4gPiA+IG90aGVyIElQDQo+ID4g PiBlbmNhcHN1bGF0aW9ucyBmb3IgTVBMUyBkbyBub3QgaGF2ZSBhIGNoZWNrc3VtIGluIHRoZSB0 dW5uZWwgaGVhZGVyLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IElmIHlvdSBzdGlsbCBiZWxp ZXZlIHRoZSBhYm92ZSB0ZXh0IGlzIG5vdCBzYXRpc2ZhY3RvcnksDQo+ID4gPiA+ID4gPiBwbGVh c2UgcHJvdmlkZSB5b3VyDQo+ID4gPiB0ZXh0Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEJl c3QgcmVnYXJkcywNCj4gPiA+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gTGxveWQgV29vZA0KPiA+ID4gPiA+ID4gPiBodHRwOi8vYWJvdXQubWUvbGxveWR3b29kDQo+ ID4gPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+ID4gPiA+ID4gRnJvbTogbXBscyBbbXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgWHV4aWFvaHUNCj4gPiA+ID4gPiA+ID4gW3h1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4gPiA+ ID4gPiA+IFNlbnQ6IDIzIEphbnVhcnkgMjAxNCAwMzoxNg0KPiA+ID4gPiA+ID4gPiBUbzogQWxl eGFuZGVyIFZhaW5zaHRlaW47IEVnZ2VydCwgTGFycw0KPiA+ID4gPiA+ID4gPiBDYzogSm9lbCBK YWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10g TGFzdCBDYWxsOg0KPiA+ID4gPiA+ID4gPiA8ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNC50eHQ+ IChFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQKQ0KPiA+ID4gPiA+ID4gPiB0byBQcm9wb3NlZCBT dGFuZGFyZA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBIaQ0KPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ID4gPiA+ID4gPiA+ILeivP7I yzogQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4gPiA+ID4gPiA+ID4gPiBbbWFpbHRvOkFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KPiA+ID4gPiA+ID4gPiA+ILeiy83KsbzkOiAyMDE0 xOox1MIyMsjVIDE5OjA1DQo+ID4gPiA+ID4gPiA+ID4gytW8/sjLOiBFZ2dlcnQsIExhcnMNCj4g PiA+ID4gPiA+ID4gPiCzrcvNOiBKb2VsIEphZWdnbGk7IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1 DQo+ID4gPiA+ID4gPiA+ID4g1vfM4jogUkU6IFttcGxzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRm LW1wbHMtaW4tdWRwLTA0LnR4dD4NCj4gPiA+ID4gPiA+ID4gPiAoRW5jYXBzdWxhdGluZyBNUExT IGluIFVEUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiA+IExhcnMgYW5kIGFsbCwNCj4gPiA+ID4gPiA+ID4gPiBMYXN0IHRpbWUgSSd2ZSBjb3Vu dGVkIHRoZSBJRVRGIExDIHRocmVhZCBvbiB0aGlzIGRyYWZ0DQo+ID4gPiA+ID4gPiA+ID4gaGFz IG1vcmUgdGhhbg0KPiA+ID4gPiA+ID4gPiA+IDE1MCBtZXNzYWdlcyBpbiBpdCwgYW5kIGl0IHNl ZW1zIHRoYXQgb24gc29tZSBpc3N1ZXMNCj4gPiA+ID4gPiA+ID4gPiAoY29uZ2VzdGlvbiBjb250 cm9sIGFuZCBVRFANCj4gPiA+ID4gPiA+ID4gPiBjaGVja3N1bXMpIHdlIGFyZSBnb2luZyByb3Vu ZCB0aGUgbXVsYmVycnkgYnVzaC4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IElN SE8gYW5kIEZXSVc6DQo+ID4gPiA+ID4gPiA+ID4gLSBVRFAgY2hlY2tzdW1zIChvciBsYWNrIHRo ZXJlb2YpIGlzIGEgbm9uLWlzc3VlIGJlY2F1c2UNCj4gPiA+ID4gPiA+ID4gPiBuYXRpdmUgTVBM UyBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIGxpa2UgdGhhdC4gQW5kIHllcywNCj4gPiA+ID4gPiA+ ID4gPiB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgcGFja2V0cyBhcmUgY29ycnVwdGVkIHdpdGhpbiB0 aGUNCj4gPiA+ID4gPiA+ID4gPiByb3V0ZXJzKSwgYnV0IHNvIGZhciBpdCBkaWQgbm90IHByZXZl bnQgTVBMUyBkZXBsb3ltZW50Lg0KPiA+ID4gPiA+ID4gPiA+IFRoZXJlIGlzLCBlLmcuLCBSRkMN Cj4gPiA+ID4gPiA+ID4gPiA0NzIwIGZvciBGQ1MgcmV0ZW50aW9uIGluIFBXcywgYnV0IEkgZG91 YnQgaXQgaXMgd2lkZWx5DQo+ID4gPiA+ID4gPiA+ID4gaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVk ICh3b3VsZCBiZSBuaWNlIHRvDQo+ID4gPiA+ID4gPiA+IGtub3cpLg0KPiA+ID4gPiA+ID4gPiA+ IC0gRTJFIGNvbmdlc3Rpb24gY29udHJvbCAocmVnYXJkbGVzcyBvZiBpdHMgaW1wbGljYXRpb25z KQ0KPiA+ID4gPiA+ID4gPiA+IHNpbXBseSBjYW5ub3QgYmUgYWRkZWQgdG8gdGhpcyBwcm90b2Nv bCB3aXRob3V0IHNvbWUgbWFqb3INCj4gPiA+ID4gPiA+ID4gPiBjaGFuZ2VzLiBBIHNob3J0IGFw cGxpY2FiaWxpdHkgc3RhdGVtZW50IGV4cGxhaW5pbmcgdGhhdA0KPiA+ID4gPiA+ID4gPiA+IHNo b3VsZCBzdWZmaWNlDQo+ID4gPiBJTU8uDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEhp IFNhc2hhLA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBJIGZ1bGx5IGFncmVlIHdpdGgg eW91ciBwb2ludHMuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEJlc3QgcmVnYXJkcywN Cj4gPiA+ID4gPiA+ID4gWGlhb2h1DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gTXkg MmMsDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgIFNhc2hhDQo+ID4gPiA+ID4gPiA+ID4gRW1haWw6 IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+ID4gPiA+ID4gPiA+ID4gTW9iaWxl OiAwNTQtOTI2NjMwMg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gPiA+ID4gRnJvbTogbXBscyBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gPiA+ID4gPiA+ID4gPiBF Z2dlcnQsIExhcnMNCj4gPiA+ID4gPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAy MiwgMjAxNCAxMjoyMyBQTQ0KPiA+ID4gPiA+ID4gPiA+ID4gVG86IFh1eGlhb2h1DQo+ID4gPiA+ ID4gPiA+ID4gPiBDYzogSm9lbCBKYWVnZ2xpOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gPiA+ ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIExhc3QgQ2FsbDoNCj4gPiA+ID4gPiA+ID4gPiA+IDxk cmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA0LnR4dD4gKEVuY2Fwc3VsYXRpbmcgTVBMUyBpbg0KPiA+ ID4gPiA+ID4gPiA+ID4gVURQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+ID4gPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ID4gPiA+IEhpLA0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gPiA+IE9uIDIwMTQtMS0yMiwgYXQgMTE6MTIsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWku Y29tPg0KPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPiA+ID4gSSB3b25kZXIgd2hldGhlciB0aGUg Zm9sbG93aW5nIHRleHQgaXMgT0sgdG8geW91Og0KPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPiA+ID4gPiBTaW5jZSB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiBjYXVzZXMg TVBMUw0KPiA+ID4gPiA+ID4gPiA+ID4gPiBwYWNrZXRzIHRvIGJlDQo+ID4gPiA+ID4gPiA+ID4g PiBmb3J3YXJkZWQgdGhyb3VnaCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250cm9s DQo+ID4gPiA+ID4gPiA+ID4gPiBndWlkZWxpbmVzIGZvciBVRFAgdHVubmVscyBhcyBkZWZpbmVk IGluIFNlY3Rpb24gMy4xLjMNCj4gPiA+ID4gPiA+ID4gPiA+IG9mIFtSRkM1NDA1XSBTSE9VTEQg YmUNCj4gPiA+ID4gPiA+ID4gZm9sbG93ZWQuDQo+ID4gPiA+ID4gPiA+ID4gPiBTcGVjaWZpY2Fs bHksIE1QTFMgY2FuIGNhcnJ5IGEgbnVtYmVyIG9mIGRpZmZlcmVudA0KPiA+ID4gPiA+ID4gPiA+ ID4gcHJvdG9jb2xzIGFzDQo+ID4gPiBwYXlsb2Fkcy4NCj4gPiA+ID4gPiA+ID4gPiA+IFdoZW4g YW4gVURQIHR1bm5lbCBpcyB1c2VkIGZvciBNUExTIHBheWxvYWQgdHJhZmZpYyB0aGF0DQo+ID4g PiA+ID4gPiA+ID4gPiBpcyBrbm93biBhdCBjb25maWd1cmF0aW9uIHRpbWUgdG8gYmUgSVAtYmFz ZWQgYW5kDQo+ID4gPiA+ID4gPiA+ID4gPiBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIHRoZSBVRFAg dHVubmVsIFNIT1VMRCBOT1QgZW1wbG95DQo+ID4gPiA+ID4gPiA+ID4gPiBpdHMgb3duIGNvbmdl c3Rpb24gY29udHJvbCBtZWNoYW5pc20sIGJlY2F1c2UgY29uZ2VzdGlvbg0KPiA+ID4gPiA+ID4g PiA+ID4gbG9zc2VzIG9mIHR1bm5lbGVkIHRyYWZmaWMgd2lsbCB0cmlnZ2VyIGFuIGNvbmdlc3Rp b24NCj4gPiA+ID4gPiA+ID4gPiA+IHJlc3BvbnNlIGF0IHRoZSBvcmlnaW5hbA0KPiA+ID4gPiA+ IHNlbmRlcnMgb2YgdGhlIHR1bm5lbGVkIHRyYWZmaWMuDQo+ID4gPiA+ID4gPiA+ID4gPiBXaGVu IGFuIFVEUCB0dW5uZWwgaXMgdXNlZCBmb3IgTVBMUyBwYXlsb2FkIHRyYWZmaWMgdGhhdA0KPiA+ ID4gPiA+ID4gPiA+ID4gaXMga25vd24gYXQgY29uZmlndXJhdGlvbiB0aW1lIG5vdCB0byBiZSBJ UC1iYXNlZCBhbmQNCj4gPiA+ID4gPiA+ID4gPiA+IGNvbmdlc3Rpb24tY29udHJvbGxlZCwgdGhl IFVEUCB0dW5uZWwgU0hPVUxEIGVtcGxveSBhbg0KPiA+ID4gPiA+ID4gPiA+ID4gYXBwcm9wcmlh dGUgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSBhcyBkZXNjcmliZWQgaW4NCj4gPiA+ID4g PiA+ID4gPiA+IFtSRkMzOTg1XS4gTm90ZSB0aGF0IGl0IFNUUk9OR0xZIFJFQ09NTUVOREVEIHRv IGRlcGxveQ0KPiA+ID4gPiA+ID4gPiA+ID4gc3VjaCBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kg b25seSB3aXRoaW4gYSBTUCBuZXR3b3JrDQo+ID4gPiA+ID4gPiA+ID4gPiBvciBuZXR3b3JrcyBv ZiBhbiBhZGphY2VudCBzZXQgb2YgY28tb3BlcmF0aW5nIFNQcywNCj4gPiA+ID4gPiA+ID4gPiA+ IHJhdGhlciB0aGFuIG92ZXIgdGhlDQo+ID4gPiA+ID4gPiA+IEludGVybmV0Lg0KPiA+ID4gPiA+ ID4gPiA+ID4gRnVydGhlcm1vcmUsIHBhY2tldCBmaWx0ZXJzIHNob3VsZCBiZSBhZGRlZCB0byBi bG9jaw0KPiA+ID4gPiA+ID4gPiA+ID4gdHJhZmZpYyB3aXRoIHRoZSBVRFAgcG9ydCBudW1iZXIg Zm9yIE1QTFMgb3ZlciBVRFAgdG8NCj4gPiA+ID4gPiA+ID4gPiA+IHByZXZlbnQgTVBMUyBvdmVy IFVEUCBwYWNrZXRzIHRvIGVzY2FwZSBmcm9tIHRoZSBzZXJ2aWNlDQo+ID4gPiA+ID4gPiA+ID4g PiBwcm92aWRlciBuZXR3b3JrcyBkdWUgdG8gbWlzY29uZmlndWF0aW9uIG9yIHBhY2tldA0KPiA+ ID4gPiA+ID4gPiA+IGVycm9ycy4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g PiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBkZXNjcmliZSB0aGUgT0FNIGNvbnRyb2wN Cj4gPiA+ID4gPiA+ID4gPiA+IGxvb3AgaW4NCj4gPiA+ID4gPiA+ID4gPiA+IChzb21lKSBtb3Jl IGRldGFpbCwgcmF0aGVyIHRoYW4gcG9pbnRpbmcgdG8gUkZDMzk4NSwNCj4gPiA+ID4gPiA+ID4g PiA+IHdoaWNoIGRvZXNuJ3QgaGF2ZSBhIHdob2xlIGxvdCBvZiBkZXRhaWwgZWl0aGVyLiBBbHNv DQo+ID4gPiA+ID4gPiA+ID4gPiBiZWNhdXNlIHRoZSBhZGRpbmcgb2YgZmlyZXdhbGwgcnVsZXMg cmVxdWlyZXMgYW4gT0FNIGhvb2suDQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ ID4gU2luY2UgU1RST05HTFkgUkVDT01NRU5ERUQgaXMgbm90IGFuIFJGQzIxMTkgdGVybSBhbmQN Cj4gPiA+ID4gPiA+ID4gPiBSRUNPTU1FTkRFRCBpcw0KPiA+ID4gPiA+ID4gPiA+ID4gdG9vIHdl YWssIEknZCBzdWdnZXN0IHRvIGNoYW5nZSB0aGlzIHRvIE1VU1QuDQo+ID4gPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiA+ID4gRmluYWxseSwgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50 IHNob3VsZCBiZQ0KPiA+ID4gPiA+ID4gPiA+ID4gcHJvbWluZW50bHkgbWFkZSBpbiB0aGUgYWJz dHJhY3QsIGludHJvZHVjdGlvbiwgZXRjLg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gPiA+IExhcnMNCg0K From curtis@ipv6.occnc.com Sun Jan 26 20:58:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13BE1A01AB for ; Sun, 26 Jan 2014 20:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 AEdEi8WvrPum for ; Sun, 26 Jan 2014 20:58:54 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 129ED1A01A4 for ; Sun, 26 Jan 2014 20:58:53 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0R4woWw074790; Sun, 26 Jan 2014 23:58:50 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401270458.s0R4woWw074790@maildrop2.v6ds.occnc.com> To: adrian@olddog.co.uk From: Curtis Villamizar In-reply-to: Your message of "Sun, 26 Jan 2014 18:02:08 +0000." <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk> Date: Sun, 26 Jan 2014 23:58:50 -0500 Cc: mpls@ietf.org, draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 04:58:58 -0000 In message <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk> "Adrian Farrel" writes: > > Hi, > > Thank you for a really thorough and clear document. > > I have done my usual AD review upon receiving the publication request > for this document. The purpose of the review is to catch any issues that > might otherwise show up in IETF last call and IESG evaluation. In this > case it is also an extra pair of eyes on what is a very detailed > document. > > I have a number of comments below. A few are editorial nits (sorry) and > some are questions for clarification of the text. There is very little > where I come even remotely close to saying "wrong" or missing". > > It looks to me that a new revision would be useful just to mop up these > comments, so I have put the document into "Revised I-D Needed" state and > will wait to see the next revision before starting the IETF last call. > Please debate any issues where you disagree with me or think that no > document change is needed. > > Thanks for the work, > Adrian Adrian, Thanks for the review. Better to get the changes in now than later. There are a few dicussion points below before coming out with a new revision of document. > === > > idnits notes that... > > == Outdated reference: draft-ietf-pwe3-vccv-impl-survey-results has been > published as RFC 7079 Got it. > --- > > Andy may want to update his coordinates. Approximate coordinates updated as per Andy's most recent request. > --- > > Your acronym list is commendably thorough, but a little enthusiastic. > > AC is only used once and then only at the point of expansion. > CE doesn't appear to be used at all > FEC only seems to be used in this document in the context of > Forwarding Equivalence Classes (LDP) If I provide a section with a list of acronyms, do I still have to expand on first use. If so, AC, NSP, OAM, and a few others appear before that section. AC is used in "Specific pseudowire AC and NSP are out of scope." I included CE since PE and P are included. > The following are all well-known acronyms according to > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > so they don't need to be included > BGP > CPU > DDoS > DoS > GMPLS > IANA > IP > IPv4 > IPv6 > LDP > MPLS > NTP > QoS > RTP > TCP > UDP > WG Given that this takes up only 17 lines in a 50 page document I'd rather be thorough. The audience here is assumed to include but not be limited to people who are not quite as familiar with MPLS, and are somehow involved in chips, systems, or eval, and need guidance regarding MPLS forwarding (though it might be a deep dive into the guide book and I pitty the MPLS newbie starting here or anywhere). > I think Curtis may have heard this before :-) > The "preferred" (by the RFC editor) expansion of ECMP is > "Equal-Cost Multipath" The form without the hyphen is more common, even among recent documents. I prefer to keep it without the hyphen. > Several acronyms are qualified with (LDP) (CE, FEC, P, PE). I haven't > checked the usage in this document, but it seems to me that the terms > might have wider applicability. Indeed, a quick search revealed > "RSVP-TE PE". I will change this to "(LDP, RSVP-TE, other protocols)" in P, PE, CE. > The third expansion of PSC could have a reference to RFC 6378. I think > that to avoid confusion, you need to expand this in the text when you > use it. You do this well everywhere except in Section 4.7 T#32, and in > this acronym list itself at E-LSP and L-LSP. Reference to RFC 6378 added. In T#32, the context MPLS-TP AIS/RDI and PSC should make the choice of which PSC is meant sufficiently obvious. I'll expand it anyway and in the one other case where not expanded on first use in a section. It should be obvious in E-LSP and L-LSP from the context plus the EXP-Inferred-PSC is the official expansion of E-LSP. If not obvious, the reader can look at RFC3270 since that is in the same line of text. > --- > > Section 1.3 bullet 5 > > 5. The implementer and system designer MUST support pseudowire > control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is > being used on a pseudowire. > > The wording is a bit odd. "The implementation and system design..."? > > Ditto bullets 6 and 7 Target audience is explained in Section 1.4. If you like I can flip Section 1.3 and 1.4 so target audience is first, then use of the roles called for in the target audience section won't seem quite so odd. > --- > > Section 1.3 > > While there is not wrong with the statements made in the bullets, some > of the later ones refer to recent additions to the MPLS suite. Yet the > list is presented as "there were some misconceptions." Clearly the > early silicon did not have misconceptions about the inclusion of entropy > labels. > > Just tweak the words at the top of the list? I'd like to keep that as is and split into two lists. The second list would have the last two items (fat-pw and EL). The first list would end with "implement CW" (sic). OLD 6. The implementer and system designer SHOULD support adding a pseudowire Flow Label [RFC6391]. Deployments MAY enable this feature for appropriate pseudowire types. See Section 2.4.3. 7. The implementer and system designer SHOULD support adding an MPLS entropy label [RFC6790]. Deployments MAY enable this feature. See Section 2.4.4. NEW The following statements provide clarification regarding more recent requirements that are often missed. 1. The implementer and system designer SHOULD support adding a pseudowire Flow Label [RFC6391]. Deployments MAY enable this feature for appropriate pseudowire types. See Section 2.4.3. 2. The implementer and system designer SHOULD support adding an MPLS entropy label [RFC6790]. Deployments MAY enable this feature. See Section 2.4.4. I've made this change. Let me know if this is not OK. > --- > > Section 2.1 > > Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, > L2TP, or LDP, are out of scope. > > I think s/LDP/UDP/ Yes. Thanks. > --- > > 2.1.1 > > Maybe the first paragraph should clarify "special purpose labels at > the top of the label stack" That phrase doesn't appear anywhere in the document. Exactly what am I clarifying? What to do with unknown special purpose labels is in the last paragraph of this subsection. > --- > > 2.1.1 > > I think that this section should note that labels 0-15 were commonly > referred to as "reserved labels" and are only renamed to "special > purpose labels" by [I-D.ietf-mpls-special-purpose-labels]. OLD [RFC3032] specifies that label values 0-15 are special purpose labels with special meanings. NEW [RFC3032] specifies that label values 0-15 are special purpose labels with special meanings. + [I-D.ietf-mpls-special-purpose-labels] renamed these from the term + "reserved labels" used in [RFC3032] "special purpose labels". BTW - draft-ietf-mpls-special-purpose-labels is also waiting for WG chair go-ahead. Hopefully since it is a short document (and I think non-controversial) it will go through smoothly and quickly so we can change this to an RFC reference. > --- > > 2.1.4 > > MPLS hierarchy as described in [RFC4206] can in principle add up to > four additional labels. MPLS hierarchy is discussed in > Section 2.1.6. > > Similar text in 2.1.6 > > I wonder whether the choice of "four" here is because RFC 4203 defines > 1 Packet-Switch Capable-1 (PSC-1) > 2 Packet-Switch Capable-2 (PSC-2) > 3 Packet-Switch Capable-3 (PSC-3) > 4 Packet-Switch Capable-4 (PSC-4) > If that is the case, we should note that RFC 7074 deprecates PSC-2 > through 4 recognising that different switching levels within the PSC > world were not applied and that LSP nesting was arbitrary and not > limited to four levels. > > On the other hand, if "four" comes from somewhere else, perhaps you > could give a clue in the text. OK. Missed this in CCAMP otherwise I would have objected to making this change without changing the SCSI for the PSC type to includes a level of hierarchy. Though perhaps a 4 byte drop in MTU is a hint. I'll change this from "add up to four additional labels" to "at least one additional label" and cite RFC 7074. The PSC-2 and up were needed if you wanted more than one level of nesting and needed to know whether your PSC-1 LSPs could make use of other PSC FA. Can be kludged with admin attributes though. > --- > > While per platform label space is mentioned in 2.1.7 I wonder whether > more information on per platform and per interface label spaces is > needed. I recall early implementations that got very confused when > parallel interfaces used the same label for different purposes. > > I guess the point there is that you cannot assume that your neighbor > is or is not using the per platform label space. > > Upstream label allocation may also come into this. The only mention of label allocation is that MPLS FRR bypass method (more formally known as facilitles backup) uses platform label space. The only reason platform label space is of any significance in a document about forwarding is "The use of platform label space impacts the size of the LSR ILM for LSR with a very large number of interfaces." Label allocation, per platform or per interface and upstream or downstream, is not a forwarding issue. It is a software issue and a matter of getting the protocol bits right. Therefore I think expanding any further on label allocation should be out of scope. But yes ... it is something that can trip up vendors. > --- > > 2.1.8.1 > > 1. The most common case is where reordering occurs is rare, > > One too many instances of "is" yeah or something like that. NEW 1. The most common case is where reordering is rare, > --- > > 2.1.8.1 > > 3. If the edge is not using pseudowire control word (CW) and the > core is using multipath, reordering will be far more common. If > this is occurring, the best solution is to use CW on the edge, > rather than try to fix the reordering using resequencing. > > Completely agree, but isn't the sequence number contained in a control > word meaning that the resequencing could, in any case, not be done > without using a control word? I suppose you can't fix reordering caused by not using CW without the sequence number in the CW. That is going to require fixing the text. OLD 3. If the edge is not using pseudowire control word (CW) and the core is using multipath, reordering will be far more common. If this is occurring, the best solution is to use CW on the edge, rather than try to fix the reordering using resequencing. NEW 3. If the edge is not using pseudowire control word (CW) and the core is using multipath, reordering will be far more common. If this is occurring, using CW on the edge will solve the problem. Without CW, resequencing is not possible since the sequence number is contained in the CW. That was a big oops on our part. > --- > > 2.1.8.1 > > 4. Another avoidable case is where some core equipment has multipath > and for some reason insists on periodically installing a new > random number as the multipath hash seed. If supporting MPLS-TP, > equipment MUST provide a means to disable periodic hash reseeding > and deployments MUST disable periodic hash reseeding. Even if > not supporting MPLS-TP, equipment should provide a means to > disable periodic hash reseeding and deployments should disable > periodic hash reseeding. > > Are those two "should" really "SHOULD"? "No" at this point because of the way we stated we would use the RFC 2119 keywords in Section 1.2. Since no existing RFC calls for this it has to be lower case. I could (and did so far) change the last sentence: OLD Even if not supporting MPLS-TP, equipment should provide a means to disable periodic hash reseeding and deployments should disable periodic hash reseeding. NEW Operator experience dictates that even if not supporting MPLS-TP, equipment SHOULD provide a means to disable periodic hash reseeding and deployments SHOULD disable periodic hash reseeding. This would be consistent with the use of RFC 2119 terms in this document, explicitly calling out any requirement not already stated in an existing RFC. The prior MUSTs in the paragraph are upper case becausse you would violate MPLS-TP requirements by not doing something. > --- > > Should 2.2 distinguish the order of magnitude of replication at branch > nodes? This impacts the replication method used (some devices make a > copy and cycle around, some devices can do multiple copies at once). On > the whole is no different from IP multicast processing except (as you > note) that each outgoing packet may be different by its label value. Is it possible to quantify the fanout? YMMV? The only thing I could say is that an implementation may need to make lots of copies in some roles (access routers for example). Making a copy and cycling yields poor performance but for low multicast traffic volumes might be OK. But you are right - some mostly low-end-ish chips to this. I'm not sure I can describe how multicast with high fanout is done without wading into implementation details of specific vendors. Perhaps the best I can do is add this: Careful consideration should be given to the performance characteristics of high fanout multicast for equipment that is intended to be used in such a role. I'll add this before the last paragraph in the section. > --- > > 2.4 > > So obvious you didn't say it? > > In order to support an adequately balanced load distribution across > multiple links, IP header information must be used. Common practice > today is to reinspect the IP headers at each LSR and use the label > stack and IP header information in a hash performed at each LSR. > Further details are provided in Section 2.4.5. > > Missing is the statement that a single "flow" must not be distributed > across multiple paths because of the implication for potentially > significant packet misordering. And feeding that is a common requirement > that such packet misordering must not occur because applications and > transport protocol implementations cannot survive such misordering. Yes. That requirement was missed. Add new second paragraph to this subsection. The Differentiated Services requirements for good reasons dictate that packets within a common microflow SHOULD NOT be reordered [RFC2474]. Service providers generally impose stronger requirements, commonly requiring that packets within a microflow MUST NOT be reordered except in rare circumstances such as load balancing across multiple links or path change for load balancing or path change for other reason. Another SP requirement is stated here and I'm quite sure this requirement is well accepted. > --- > > 2.4.2 uses "composite link" and "component link". I suggest picking just > one term. They are two different things. Two or more component links make up a composite link. Knowing that, give it another read please. I'd rather not cite draft-ietf-rtgwg-cl-requirements as an informational reference just for this one term. In favor of citing it, draft-ietf-rtgwg-cl-requirements is moving along. Against citing it is there is far less than a ground swell of providers calling for the full set of things asked for in draft-ietf-rtgwg-cl-requirements. > --- > > 2.4.5.1 notes that special purpose and extended special purpose labels > need to be excluded from the hash. Good. > But it seems that some special purpose labels will indicate that the > next label stack entry contains a label with special meaning. (ELI is > an example that we specifically don't have to worry about.) > How do we handle that? > Should we be dividing up the extended special purpose label space to > have one set of code points meaning "just this label is special" and > another set meaning "this label is special and the next label stack > entry is magic"? I did list ELI (bullet 2) before the more general rule of not useing special purpose labels. The ELI is not used, just the EL, so the text could be considered correct as-is. So far the only special purpose label that is not just ignored and skipped over is ELI. Regarding this being magic -- All of this is somewhat programable specialized silicon magic. The silicon generally has some form of very fast, very light weight parsing engine at the front of the pipeline. One thing it does is pick out fields for load balance. The better silicon hashes as it goes rather that pick out a set of fields and then hashes that set of fields when its done. When it sees 13 it skips and hashes the next thing and stops hashing completely. If it sees 0-12,14 it skips and continues. If it sees 15 it skips two labels and continues. Its should be programable enough that if someone defines a new ELI like label it is likely to be able to deal with it. The not so good silicon has this all so hard wired that it won't be able to do ELI without at least a respin. At most I could add "If a new special purpose label or extended special purpose label is defined which requires special load balance processing then, as is the case for the ELI label, a spacial action may be needed rather than skipping the special purpose label or extended special purpose label." I really don't think this is needed. > --- > > An issue that arises from the multipath support (2.4.5.1) is that > hardware assumes that after a label stack entry with the S-bit set, > there are only three possible next bytes... > - a control word (indicated by b0000 or b0001) > - an IPv4 header > - an IPv6 header > This is the case regardless of how the LSP was set up, and the next > bytes cannot ever be further MPLS stack entries. Right. Note that in (5) is says that some SP will require IP headers and some will require an ability to disable IP headers. The rule is really look for 4, 6, or anything else in the first nibble. If 4 or 6 assume IP. If anything else stop. And yes if the payload is MPLS after a S-bit you have a screwed up MPLS implementation to start with and you won't get load balance on any set of MPLS labels after the first S-bit. This is a fact of life in the field and is as it should be. > While this comes up 2.4.5.1 it may merit further discussion in an > earlier section of the document. This text is part of 2.4. ("MPLS Multipath Techniques"). The third paragraph contains "Further details are provided in Section 2.4.5." Section 2.4.5. is "Fields Used for Multipath Load Balance". > I note that discussion of support of PWs without the CW drives you > to say that hashing beyond the S-bit should be a configurable option > which would (of course) support any payload including MPLS in MPLS > with repeated bottom of stack. However, you might want to specifically > preclude that. It says the same thing here in bullet 5 regarding being configurable. The wording "ability to disable" is same as "configurable option". At no point in this document do we imply that looking beyond the S-bit means looking at anything beyond the S-bit other than looking for IP. This is very clear in [RFC4385] and [RFC4928] which is cited in the text about PW CW. All it says in the places discusing PW is that without CW the traffic might get reordered. If you feel that we at any point imply that lack of PW CW allows looking at anything past the S-bit rather than just looking for an IP header please point to where and we will have to correct that. I looked at all occurances of CW and did not find anything. Bullet 5 is very clear that a 4 or 6 has to be found in the first nibble of payload. > --- > > Q#7 introduces the terms "short-pipe" and "uniform model". It provides > a pointer to 2.1.6, but that section does not mention these terms (and > doesn't refer to RFC 3270). It really should say "See Section 2.1.6 regarding MPLS hierarchy. See [RFC3443] regarding PHP, UHP, and pipe, short-pipe, and uniform models." It does now. > --- > > Section 7 could usefully point back at Section 2.6.1 I'll add: Some advice on hardware and other equipment hardenning against Denial-of-Service attack can be found in Section 2.6.1. The security ADs will have fun with that. They'll love the comments about crypto auth being the last line of defense not the first and only line of defense. I'll plan on discussing this in greater detail when SecDir review comes along. I thik the security AD will want to reword the prior paragraph as well as they seem to have some very precise preferred wording. Curtis From loa@pi.nu Mon Jan 27 02:38:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423801A01EC for ; Mon, 27 Jan 2014 02:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 FDlkijiD90Rl for ; Mon, 27 Jan 2014 02:38:02 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 394AD1A01EB for ; Mon, 27 Jan 2014 02:38:02 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.117.160]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4666E1802A16; Mon, 27 Jan 2014 11:37:57 +0100 (CET) Message-ID: <52E63702.20102@pi.nu> Date: Mon, 27 Jan 2014 18:37:54 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , draft-ietf-mpls-psc-updates@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [mpls] working group last call on draft-ietf-mpls-psc-updates-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 10:38:04 -0000 Working Group, This is to initiate a working group last call on draft-ietf-mpls-psc-updates. One reason for the timing, other than that the author thinks is ready for wglc, is that this document is normatively referenced in draft-ietf-mpls-tp-psc-itu which also is in wglc. There are no IPR disclosures against this document. Please send your comments to the mpls wg mailing list (mpls@ietf.org). This working group last call ends Feb 19´0, 2014. /Loa for the MPLS wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Mon Jan 27 03:32:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B331A01E4 for ; Mon, 27 Jan 2014 03:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 j7kZaPXdAoFl for ; Mon, 27 Jan 2014 03:32:54 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id A2C1C1A01EB for ; Mon, 27 Jan 2014 03:32:52 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.117.160]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5B5261802A16; Mon, 27 Jan 2014 12:32:48 +0100 (CET) Message-ID: <52E643DC.4070906@pi.nu> Date: Mon, 27 Jan 2014 19:32:44 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <52DC89C3.3030003@pi.nu> In-Reply-To: <52DC89C3.3030003@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: [mpls] Additional Information - Re: working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 11:32:56 -0000 Working Group, When this wglc were started we did not know of any IPR disclosures against this document. Now we have an IPR disclosure: http://www.ietf.org/mail-archive/web/mpls/current/msg11469.html I will also start an IPR poll on this document. /Loa mpls wg co-chair On 2014-01-20 10:28, Loa Andersson wrote: > Working Group, > > This is to start a two week working group last call on > draft-ietf-mpls-tp-psc-itu. > > Please find the document at: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ > > The document editors has also supplied a "diff-list" between > version -00 and -01 at: > http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html > > ITU-T SG15 has advised us that this document is a necessary reference > for documents that is planned to go into the ITU-T approval process > from the SG15 meeting end of March / beginning of April. Editors, > authors and chairs has put in quite an effort to make this document > ready. The schedule is very tight. > > We are now doing several review steps in parallel > > - the normal working group last call, please send your comments to the > mpls working group mailing list (mpls@ietf.org) > - the working group chairs reviewed this document as part of the > mpls-rt review, normally we do a wg chair review before starting the > wglc, this review will now take place in parallel > - after the wglc and publication request there is an AD evaluation, > this will now also take place in parallel with the wglc > > The editors and authors are advised to try to resolve as many of the > comments as possible (on the mailing list) as they come in, but not to > post the new version of the draft until the wglc is closed and the > comments are resolved. > > This working group last call ends February 3rd. > > /Loa > for the MPLS WG co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Mon Jan 27 03:43:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4C1A01FA for ; Mon, 27 Jan 2014 03:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 3YErxyscIs6Z for ; Mon, 27 Jan 2014 03:43:35 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6361A01F8 for ; Mon, 27 Jan 2014 03:43:35 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.117.160]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id AD83C1802A16; Mon, 27 Jan 2014 12:43:31 +0100 (CET) Message-ID: <52E64660.2090900@pi.nu> Date: Mon, 27 Jan 2014 19:43:28 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: [mpls] IPR poll draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 11:43:37 -0000 Working Group, draft-ietf-mpls-tp-psc-itu is in working group last call, we have just received an IPR disclosure: http://www.ietf.org/mail-archive/web/mpls/current/msg11469.html This gives us reason to start an IPR poll on the document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-tp-psc-itu? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there is the one IPR disclosure, mentioned above, that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From cpignata@cisco.com Mon Jan 27 04:45:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AF81A0201 for ; Mon, 27 Jan 2014 04:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 swshd4hAX5e2 for ; Mon, 27 Jan 2014 04:45:14 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1FA1A01FA for ; Mon, 27 Jan 2014 04:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55555; q=dns/txt; s=iport; t=1390826712; x=1392036312; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6O27rxKx0ox9Bg1g4dVoYfwGJJtiol15afwlqmpaOhI=; b=AFz00S/r6w5tSemv+bIPrsT37MaXTRQ+NF+Yw6RqVZSmdKv3Qi5LcsNr lfTMUX/66b8eDcdaUH81Uvas9BTHOHqgs0OM2YqDdZsBaUHwbahqBdbq6 M7W4JmHEBUxv3TStIlahducvsOVD3EPQYNbyN9KuCSe9pbDGdS1p65H/I c=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAEtU5lKtJV2a/2dsb2JhbABZgkhEOFaqE5JCgQ0WdIIlAQEBAwEBAQELCgIBAkgJCxACAQg4AQ0nCyUCBA4FDgsCh2IIDcg6F44iE1QEB4MkgRQEkD2BMoJQg2iSHoMtgWhC X-IronPort-AV: E=Sophos;i="4.95,728,1384300800"; d="asc'?scan'208,217";a="299999991" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jan 2014 12:45:10 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0RCjAUT019372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jan 2014 12:45:10 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 27 Jan 2014 06:45:10 -0600 From: "Carlos Pignataro (cpignata)" To: "" Thread-Topic: [mpls] AD review of draft-ietf-mpls-forwarding Thread-Index: AQHPGxyFjS/uX4Lbv0ORQoMPNhcQYJqY6ZEA Date: Mon, 27 Jan 2014 12:45:09 +0000 Message-ID: <67516608-AAA0-49A1-B1E2-3DF146190D2C@cisco.com> References: <201401270458.s0R4woWw074790@maildrop2.v6ds.occnc.com> In-Reply-To: <201401270458.s0R4woWw074790@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.229.159] Content-Type: multipart/signed; boundary="Apple-Mail=_D39CCBFF-AA22-4D51-A836-0F52A1CA9C04"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "draft-ietf-mpls-forwarding.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 12:45:22 -0000 --Apple-Mail=_D39CCBFF-AA22-4D51-A836-0F52A1CA9C04 Content-Type: multipart/alternative; boundary="Apple-Mail=_3681EDCE-9D17-4BCC-9F9E-037139BD72FC" --Apple-Mail=_3681EDCE-9D17-4BCC-9F9E-037139BD72FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Curtis, Many thanks for these! Ack to all. Reading through your proposed changes, please find one small request = inline: On Jan 26, 2014, at 11:58 PM, Curtis Villamizar = wrote: >=20 > In message <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk> > "Adrian Farrel" writes: >>=20 >> Hi, >>=20 >> Thank you for a really thorough and clear document. >>=20 >> I have done my usual AD review upon receiving the publication request=20= >> for this document. The purpose of the review is to catch any issues = that >> might otherwise show up in IETF last call and IESG evaluation. In = this >> case it is also an extra pair of eyes on what is a very detailed=20 >> document. >>=20 >> I have a number of comments below. A few are editorial nits (sorry) = and >> some are questions for clarification of the text. There is very = little=20 >> where I come even remotely close to saying "wrong" or missing". >>=20 >> It looks to me that a new revision would be useful just to mop up = these >> comments, so I have put the document into "Revised I-D Needed" state = and >> will wait to see the next revision before starting the IETF last = call. >> Please debate any issues where you disagree with me or think that no >> document change is needed. >>=20 >> Thanks for the work, >> Adrian >=20 >=20 > Adrian, >=20 > Thanks for the review. Better to get the changes in now than later. >=20 > There are a few dicussion points below before coming out with a new > revision of document. >=20 >> =3D=3D=3D >>=20 >> idnits notes that... >>=20 >> =3D=3D Outdated reference: draft-ietf-pwe3-vccv-impl-survey-results = has been >> published as RFC 7079 >=20 > Got it. >=20 >> --- >>=20 >> Andy may want to update his coordinates. >=20 > Approximate coordinates updated as per Andy's most recent request. >=20 >> --- >>=20 >> Your acronym list is commendably thorough, but a little enthusiastic. >>=20 >> AC is only used once and then only at the point of expansion. >> CE doesn't appear to be used at all >> FEC only seems to be used in this document in the context of=20 >> Forwarding Equivalence Classes (LDP) >=20 > If I provide a section with a list of acronyms, do I still have to > expand on first use. If so, AC, NSP, OAM, and a few others appear > before that section. >=20 > AC is used in "Specific pseudowire AC and NSP are out of scope." >=20 > I included CE since PE and P are included. >=20 >> The following are all well-known acronyms according to >> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt >> so they don't need to be included >> BGP >> CPU >> DDoS >> DoS >> GMPLS >> IANA >> IP >> IPv4 >> IPv6 >> LDP >> MPLS >> NTP >> QoS >> RTP >> TCP >> UDP >> WG >=20 > Given that this takes up only 17 lines in a 50 page document I'd > rather be thorough. The audience here is assumed to include but not > be limited to people who are not quite as familiar with MPLS, and are > somehow involved in chips, systems, or eval, and need guidance > regarding MPLS forwarding (though it might be a deep dive into the > guide book and I pitty the MPLS newbie starting here or anywhere). >=20 >> I think Curtis may have heard this before :-) >> The "preferred" (by the RFC editor) expansion of ECMP is >> "Equal-Cost Multipath" >=20 > The form without the hyphen is more common, even among recent > documents. I prefer to keep it without the hyphen. >=20 >> Several acronyms are qualified with (LDP) (CE, FEC, P, PE). I haven't >> checked the usage in this document, but it seems to me that the terms >> might have wider applicability. Indeed, a quick search revealed=20 >> "RSVP-TE PE". >=20 > I will change this to "(LDP, RSVP-TE, other protocols)" in P, PE, CE. >=20 >> The third expansion of PSC could have a reference to RFC 6378. I = think >> that to avoid confusion, you need to expand this in the text when you=20= >> use it. You do this well everywhere except in Section 4.7 T#32, and = in >> this acronym list itself at E-LSP and L-LSP. >=20 > Reference to RFC 6378 added. >=20 > In T#32, the context MPLS-TP AIS/RDI and PSC should make the choice of > which PSC is meant sufficiently obvious. I'll expand it anyway and in > the one other case where not expanded on first use in a section. >=20 > It should be obvious in E-LSP and L-LSP from the context plus the > EXP-Inferred-PSC is the official expansion of E-LSP. If not obvious, > the reader can look at RFC3270 since that is in the same line of text. >=20 >> --- >>=20 >> Section 1.3 bullet 5 >>=20 >> 5. The implementer and system designer MUST support pseudowire >> control word (CW) if MPLS-TP is supported or if ACH [RFC5586] = is >> being used on a pseudowire. >>=20 >> The wording is a bit odd. "The implementation and system design..."? >>=20 >> Ditto bullets 6 and 7 >=20 > Target audience is explained in Section 1.4. If you like I can flip > Section 1.3 and 1.4 so target audience is first, then use of the roles > called for in the target audience section won't seem quite so odd. >=20 >> --- >>=20 >> Section 1.3 >>=20 >> While there is not wrong with the statements made in the bullets, = some >> of the later ones refer to recent additions to the MPLS suite. Yet = the >> list is presented as "there were some misconceptions." Clearly the >> early silicon did not have misconceptions about the inclusion of = entropy >> labels.=20 >>=20 >> Just tweak the words at the top of the list? >=20 > I'd like to keep that as is and split into two lists. The second list > would have the last two items (fat-pw and EL). The first list would > end with "implement CW" (sic). >=20 > OLD >=20 > 6. The implementer and system designer SHOULD support adding a > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > feature for appropriate pseudowire types. See Section 2.4.3. >=20 > 7. The implementer and system designer SHOULD support adding an = MPLS > entropy label [RFC6790]. Deployments MAY enable this feature. > See Section 2.4.4. >=20 > NEW >=20 > The following statements provide clarification regarding more > recent requirements that are often missed. >=20 > 1. The implementer and system designer SHOULD support adding a > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > feature for appropriate pseudowire types. See Section 2.4.3. >=20 > 2. The implementer and system designer SHOULD support adding an = MPLS > entropy label [RFC6790]. Deployments MAY enable this feature. > See Section 2.4.4. >=20 > I've made this change. Let me know if this is not OK. >=20 >> --- >>=20 >> Section 2.1 >>=20 >> Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, >> L2TP, or LDP, are out of scope. >>=20 >> I think s/LDP/UDP/ >=20 > Yes. Thanks. Could this be reworded as follows? NEW: Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC = 4023],=20 MPLS in GRE [RFC 4023], MPLS in L2TPv3 [RFC 4817], or MPLS in UDP [draft-ietf-mpls-in-udp], are out of scope. And then for consistency below: OLD: 7. Some IP encapsulations support tunneling, such as IP-in-IP, GRE, L2TPv3, and IPSEC. These provide a greater source of entropy which some provider networks carrying large amounts of tunneled traffic may need. The use of tunneling header information is out of scope for this document. NEW: 7. Some IP encapsulations support tunneling, such as IP-in-IP, GRE, L2TPv3, and IPSEC. These provide a greater source of entropy which some provider networks carrying large amounts of tunneled traffic may need (e.g., as used in [RFC 5640] for GRE and = L2TPv3). The use of tunneling header information is out of scope for this = document. Thanks! Carlos. >=20 >> --- >>=20 >> 2.1.1 >>=20 >> Maybe the first paragraph should clarify "special purpose labels at=20= >> the top of the label stack" >=20 > That phrase doesn't appear anywhere in the document. Exactly what am > I clarifying? What to do with unknown special purpose labels is in > the last paragraph of this subsection. >=20 >> --- >>=20 >> 2.1.1 >>=20 >> I think that this section should note that labels 0-15 were commonly >> referred to as "reserved labels" and are only renamed to "special >> purpose labels" by [I-D.ietf-mpls-special-purpose-labels]. >=20 > OLD >=20 > [RFC3032] specifies that label values 0-15 are special purpose > labels with special meanings. >=20 > NEW >=20 > [RFC3032] specifies that label values 0-15 are special purpose > labels with special meanings. > + [I-D.ietf-mpls-special-purpose-labels] renamed these from the term > + "reserved labels" used in [RFC3032] "special purpose labels". >=20 > BTW - draft-ietf-mpls-special-purpose-labels is also waiting for WG > chair go-ahead. Hopefully since it is a short document (and I think > non-controversial) it will go through smoothly and quickly so we can > change this to an RFC reference. >=20 >> --- >>=20 >> 2.1.4 >>=20 >> MPLS hierarchy as described in [RFC4206] can in principle add up to >> four additional labels. MPLS hierarchy is discussed in >> Section 2.1.6. >>=20 >> Similar text in 2.1.6 >>=20 >> I wonder whether the choice of "four" here is because RFC 4203 = defines >> 1 Packet-Switch Capable-1 (PSC-1) >> 2 Packet-Switch Capable-2 (PSC-2) >> 3 Packet-Switch Capable-3 (PSC-3) >> 4 Packet-Switch Capable-4 (PSC-4) >> If that is the case, we should note that RFC 7074 deprecates PSC-2=20 >> through 4 recognising that different switching levels within the PSC >> world were not applied and that LSP nesting was arbitrary and not=20 >> limited to four levels. >>=20 >> On the other hand, if "four" comes from somewhere else, perhaps you=20= >> could give a clue in the text. >=20 > OK. Missed this in CCAMP otherwise I would have objected to making > this change without changing the SCSI for the PSC type to includes a > level of hierarchy. Though perhaps a 4 byte drop in MTU is a hint. >=20 > I'll change this from "add up to four additional labels" to "at least > one additional label" and cite RFC 7074. >=20 > The PSC-2 and up were needed if you wanted more than one level of > nesting and needed to know whether your PSC-1 LSPs could make use of > other PSC FA. Can be kludged with admin attributes though. >=20 >> --- >>=20 >> While per platform label space is mentioned in 2.1.7 I wonder whether >> more information on per platform and per interface label spaces is=20 >> needed. I recall early implementations that got very confused when >> parallel interfaces used the same label for different purposes. >>=20 >> I guess the point there is that you cannot assume that your neighbor >> is or is not using the per platform label space. >>=20 >> Upstream label allocation may also come into this. >=20 > The only mention of label allocation is that MPLS FRR bypass method > (more formally known as facilitles backup) uses platform label space. >=20 > The only reason platform label space is of any significance in a > document about forwarding is "The use of platform label space impacts > the size of the LSR ILM for LSR with a very large number of > interfaces." >=20 > Label allocation, per platform or per interface and upstream or > downstream, is not a forwarding issue. It is a software issue > and a matter of getting the protocol bits right. Therefore I think > expanding any further on label allocation should be out of scope. >=20 > But yes ... it is something that can trip up vendors. >=20 >> --- >>=20 >> 2.1.8.1 >>=20 >> 1. The most common case is where reordering occurs is rare, >>=20 >> One too many instances of "is" >=20 > yeah or something like that. >=20 > NEW >=20 > 1. The most common case is where reordering is rare, >=20 >> --- >>=20 >> 2.1.8.1 >>=20 >> 3. If the edge is not using pseudowire control word (CW) and the >> core is using multipath, reordering will be far more common. = If >> this is occurring, the best solution is to use CW on the edge, >> rather than try to fix the reordering using resequencing. >>=20 >> Completely agree, but isn't the sequence number contained in a = control >> word meaning that the resequencing could, in any case, not be done=20 >> without using a control word? >=20 > I suppose you can't fix reordering caused by not using CW without the > sequence number in the CW. That is going to require fixing the text. >=20 > OLD >=20 > 3. If the edge is not using pseudowire control word (CW) and the > core is using multipath, reordering will be far more common. > If this is occurring, the best solution is to use CW on the > edge, rather than try to fix the reordering using resequencing. >=20 > NEW >=20 > 3. If the edge is not using pseudowire control word (CW) and the > core is using multipath, reordering will be far more common. > If this is occurring, using CW on the edge will solve the > problem. Without CW, resequencing is not possible since the > sequence number is contained in the CW. >=20 > That was a big oops on our part. >=20 >> --- >>=20 >> 2.1.8.1 >>=20 >> 4. Another avoidable case is where some core equipment has = multipath >> and for some reason insists on periodically installing a new >> random number as the multipath hash seed. If supporting = MPLS-TP, >> equipment MUST provide a means to disable periodic hash = reseeding >> and deployments MUST disable periodic hash reseeding. Even if >> not supporting MPLS-TP, equipment should provide a means to >> disable periodic hash reseeding and deployments should disable >> periodic hash reseeding. >>=20 >> Are those two "should" really "SHOULD"? >=20 > "No" at this point because of the way we stated we would use the RFC > 2119 keywords in Section 1.2. >=20 > Since no existing RFC calls for this it has to be lower case. >=20 > I could (and did so far) change the last sentence: >=20 > OLD >=20 > Even if not supporting MPLS-TP, equipment should provide a means to > disable periodic hash reseeding and deployments should disable > periodic hash reseeding. >=20 > NEW >=20 > Operator experience dictates that even if not supporting MPLS-TP, > equipment SHOULD provide a means to disable periodic hash reseeding > and deployments SHOULD disable periodic hash reseeding. >=20 > This would be consistent with the use of RFC 2119 terms in this > document, explicitly calling out any requirement not already stated in > an existing RFC. >=20 > The prior MUSTs in the paragraph are upper case becausse you would > violate MPLS-TP requirements by not doing something. >=20 >> --- >>=20 >> Should 2.2 distinguish the order of magnitude of replication at = branch >> nodes? This impacts the replication method used (some devices make a >> copy and cycle around, some devices can do multiple copies at once). = On >> the whole is no different from IP multicast processing except (as you >> note) that each outgoing packet may be different by its label value. >=20 > Is it possible to quantify the fanout? YMMV? >=20 > The only thing I could say is that an implementation may need to make > lots of copies in some roles (access routers for example). >=20 > Making a copy and cycling yields poor performance but for low > multicast traffic volumes might be OK. But you are right - some > mostly low-end-ish chips to this. >=20 > I'm not sure I can describe how multicast with high fanout is done > without wading into implementation details of specific vendors. >=20 > Perhaps the best I can do is add this: >=20 > Careful consideration should be given to the performance > characteristics of high fanout multicast for equipment that is > intended to be used in such a role. >=20 > I'll add this before the last paragraph in the section. >=20 >> --- >>=20 >> 2.4 >>=20 >> So obvious you didn't say it? >>=20 >> In order to support an adequately balanced load distribution across >> multiple links, IP header information must be used. Common = practice >> today is to reinspect the IP headers at each LSR and use the label >> stack and IP header information in a hash performed at each LSR. >> Further details are provided in Section 2.4.5. >>=20 >> Missing is the statement that a single "flow" must not be distributed=20= >> across multiple paths because of the implication for potentially >> significant packet misordering. And feeding that is a common = requirement >> that such packet misordering must not occur because applications and >> transport protocol implementations cannot survive such misordering. >=20 > Yes. That requirement was missed. Add new second paragraph to this > subsection. >=20 > The Differentiated Services requirements for good reasons dictate > that packets within a common microflow SHOULD NOT be reordered > [RFC2474]. Service providers generally impose stronger > requirements, commonly requiring that packets within a microflow > MUST NOT be reordered except in rare circumstances such as load > balancing across multiple links or path change for load balancing > or path change for other reason. >=20 > Another SP requirement is stated here and I'm quite sure this > requirement is well accepted. >=20 >> --- >>=20 >> 2.4.2 uses "composite link" and "component link". I suggest picking = just >> one term. >=20 > They are two different things. Two or more component links make up a > composite link. Knowing that, give it another read please. >=20 > I'd rather not cite draft-ietf-rtgwg-cl-requirements as an > informational reference just for this one term. In favor of citing > it, draft-ietf-rtgwg-cl-requirements is moving along. Against citing > it is there is far less than a ground swell of providers calling for > the full set of things asked for in draft-ietf-rtgwg-cl-requirements. >=20 >> --- >>=20 >> 2.4.5.1 notes that special purpose and extended special purpose = labels=20 >> need to be excluded from the hash. Good. >> But it seems that some special purpose labels will indicate that the=20= >> next label stack entry contains a label with special meaning. (ELI is >> an example that we specifically don't have to worry about.) >> How do we handle that? >> Should we be dividing up the extended special purpose label space to >> have one set of code points meaning "just this label is special" and >> another set meaning "this label is special and the next label stack >> entry is magic"? >=20 > I did list ELI (bullet 2) before the more general rule of not useing > special purpose labels. The ELI is not used, just the EL, so the text > could be considered correct as-is. >=20 > So far the only special purpose label that is not just ignored and > skipped over is ELI. >=20 > Regarding this being magic -- All of this is somewhat programable > specialized silicon magic. The silicon generally has some form of > very fast, very light weight parsing engine at the front of the > pipeline. One thing it does is pick out fields for load balance. >=20 > The better silicon hashes as it goes rather that pick out a set of > fields and then hashes that set of fields when its done. When it sees > 13 it skips and hashes the next thing and stops hashing completely. > If it sees 0-12,14 it skips and continues. If it sees 15 it skips two > labels and continues. Its should be programable enough that if > someone defines a new ELI like label it is likely to be able to deal > with it. >=20 > The not so good silicon has this all so hard wired that it won't be > able to do ELI without at least a respin. >=20 > At most I could add "If a new special purpose label or extended > special purpose label is defined which requires special load balance > processing then, as is the case for the ELI label, a spacial action > may be needed rather than skipping the special purpose label or > extended special purpose label." I really don't think this is needed. >=20 >> --- >>=20 >> An issue that arises from the multipath support (2.4.5.1) is that >> hardware assumes that after a label stack entry with the S-bit set, >> there are only three possible next bytes... >> - a control word (indicated by b0000 or b0001) >> - an IPv4 header >> - an IPv6 header >> This is the case regardless of how the LSP was set up, and the next >> bytes cannot ever be further MPLS stack entries. >=20 > Right. Note that in (5) is says that some SP will require IP headers > and some will require an ability to disable IP headers. >=20 > The rule is really look for 4, 6, or anything else in the first > nibble. If 4 or 6 assume IP. If anything else stop. >=20 > And yes if the payload is MPLS after a S-bit you have a screwed up > MPLS implementation to start with and you won't get load balance on > any set of MPLS labels after the first S-bit. This is a fact of life > in the field and is as it should be. >=20 >> While this comes up 2.4.5.1 it may merit further discussion in an >> earlier section of the document. >=20 > This text is part of 2.4. ("MPLS Multipath Techniques"). The third > paragraph contains "Further details are provided in Section 2.4.5." > Section 2.4.5. is "Fields Used for Multipath Load Balance". >=20 >> I note that discussion of support of PWs without the CW drives you >> to say that hashing beyond the S-bit should be a configurable option >> which would (of course) support any payload including MPLS in MPLS >> with repeated bottom of stack. However, you might want to = specifically >> preclude that. >=20 > It says the same thing here in bullet 5 regarding being configurable. > The wording "ability to disable" is same as "configurable option". >=20 > At no point in this document do we imply that looking beyond the S-bit > means looking at anything beyond the S-bit other than looking for IP. > This is very clear in [RFC4385] and [RFC4928] which is cited in the > text about PW CW. >=20 > All it says in the places discusing PW is that without CW the traffic > might get reordered. >=20 > If you feel that we at any point imply that lack of PW CW allows > looking at anything past the S-bit rather than just looking for an IP > header please point to where and we will have to correct that. I > looked at all occurances of CW and did not find anything. >=20 > Bullet 5 is very clear that a 4 or 6 has to be found in the first > nibble of payload. >=20 >> --- >>=20 >> Q#7 introduces the terms "short-pipe" and "uniform model". It = provides >> a pointer to 2.1.6, but that section does not mention these terms = (and >> doesn't refer to RFC 3270). >=20 > It really should say "See Section 2.1.6 regarding MPLS hierarchy. See > [RFC3443] regarding PHP, UHP, and pipe, short-pipe, and uniform = models." >=20 > It does now. >=20 >> --- >>=20 >> Section 7 could usefully point back at Section 2.6.1 >=20 > I'll add: >=20 > Some advice on hardware and other equipment hardenning against > Denial-of-Service attack can be found in Section 2.6.1. >=20 > The security ADs will have fun with that. They'll love the comments > about crypto auth being the last line of defense not the first and > only line of defense. I'll plan on discussing this in greater detail > when SecDir review comes along. >=20 > I thik the security AD will want to reword the prior paragraph as well > as they seem to have some very precise preferred wording. >=20 > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_3681EDCE-9D17-4BCC-9F9E-037139BD72FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Curtis,

Many thanks for these! Ack to = all.

Reading through your proposed changes, = please find one small request inline:

On Jan 26, = 2014, at 11:58 PM, Curtis Villamizar <curtis@ipv6.occnc.com> = wrote:


In message <005601cf1ac0$= bc2ea410$348bec30$@olddog.co.uk>
"Adrian Farrel" = writes:

Hi,

Thank you for a = really thorough and clear document.

I have done my usual AD = review upon receiving the publication request 
for this document. The = purpose of the review is to catch any issues that
might otherwise = show up in IETF last call and IESG evaluation. In this
case it is = also an extra pair of eyes on what is a very detailed 
document.

I have = a number of comments below. A few are editorial nits (sorry) and
some = are questions for clarification of the text. There is very little 
where I come even = remotely close to saying "wrong" or missing".

It looks to me that = a new revision would be useful just to mop up these
comments, so I = have put the document into "Revised I-D Needed" state and
will wait = to see the next revision before starting the IETF last call.
Please = debate any issues where you disagree with me or think that = no
document change is needed.

Thanks for the = work,
Adrian


Adrian,

Thanks for the = review.  Better to get the changes in now than later.

There = are a few dicussion points below before coming out with a = new
revision of document.

=3D=3D=3D

idnits notes that...

 =3D=3D = Outdated reference: draft-ietf-pwe3-vccv-impl-survey-results has = been
    published as RFC = 7079

Got it.

---

Andy may want to update his = coordinates.

Approximate coordinates updated as per = Andy's most recent request.

---

Your acronym list is commendably thorough, but = a little enthusiastic.

AC is only used once and then only at the = point of expansion.
CE doesn't appear to be used at all
FEC only = seems to be used in this document in the context of 
 Forwarding = Equivalence Classes (LDP)

If I provide a section = with a list of acronyms, do I still have to
expand on first use. =  If so, AC, NSP, OAM, and a few others appear
before that = section.

AC is used in "Specific pseudowire AC and NSP are out of = scope."

I included CE since PE and P are = included.

The following are all = well-known acronyms according to
 ht= tp://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
 = so they don't need to be = included
BGP
CPU
DDoS
DoS
GMPLS
IANA
IP
IPv4
IP= v6
LDP
MPLS
NTP
QoS
RTP
TCP
UDP
WG

Given that this takes up only 17 lines in a 50 page document = I'd
rather be thorough.  The audience here is assumed to include = but not
be limited to people who are not quite as familiar with MPLS, = and are
somehow involved in chips, systems, or eval, and need = guidance
regarding MPLS forwarding (though it might be a deep dive = into the
guide book and I pitty the MPLS newbie starting here or = anywhere).

I think Curtis may have = heard this before :-)
The "preferred" (by the RFC editor) expansion = of ECMP is
"Equal-Cost Multipath"

The form = without the hyphen is more common, even among recent
documents. =  I prefer to keep it without the hyphen.

Several acronyms are qualified with (LDP) (CE, FEC, P, = PE). I haven't
checked the usage in this document, but it seems to me = that the terms
might have wider applicability. Indeed, a quick search = revealed 
"RSVP-TE = PE".

I will change this to "(LDP, RSVP-TE, other = protocols)" in P, PE, CE.

The third = expansion of PSC could have a reference to RFC 6378. I think
that to = avoid confusion, you need to expand this in the text when you 
use it. You do this = well everywhere except in Section 4.7 T#32, and in
this acronym list = itself at E-LSP and L-LSP.

Reference to RFC 6378 = added.

In T#32, the context MPLS-TP AIS/RDI and PSC should make = the choice of
which PSC is meant sufficiently obvious.  I'll = expand it anyway and in
the one other case where not expanded on = first use in a section.

It should be obvious in E-LSP and L-LSP = from the context plus the
EXP-Inferred-PSC is the official expansion = of E-LSP.  If not obvious,
the reader can look at RFC3270 since = that is in the same line of text.

---

Section 1.3 bullet 5

  5. =  The implementer and system designer MUST support = pseudowire
      control word (CW) if = MPLS-TP is supported or if ACH [RFC5586] = is
      being used on a = pseudowire.

The wording is a bit odd. "The implementation and = system design..."?

Ditto bullets 6 and = 7

Target audience is explained in Section 1.4. =  If you like I can flip
Section 1.3 and 1.4 so target audience = is first, then use of the roles
called for in the target audience = section won't seem quite so odd.

---

Section 1.3

While there is not wrong = with the statements made in the bullets, some
of the later ones refer = to recent additions to the MPLS suite. Yet the
list is presented as = "there were some misconceptions." Clearly the
early silicon did not = have misconceptions about the inclusion of entropy
labels. 

Just tweak the = words at the top of the list?

I'd like to keep that = as is and split into two lists.  The second list
would have the = last two items (fat-pw and EL).  The first list would
end with = "implement CW" (sic).

OLD

  6.  The = implementer and system designer SHOULD support adding = a
      pseudowire Flow Label = [RFC6391].  Deployments MAY enable = this
      feature for appropriate = pseudowire types.  See Section 2.4.3.

  7. =  The implementer and system designer SHOULD support adding an = MPLS
      entropy label [RFC6790]. =  Deployments MAY enable this = feature.
      See Section = 2.4.4.

NEW

  The following statements provide = clarification regarding more
  recent requirements that are = often missed.

  1.  The implementer and system = designer SHOULD support adding = a
      pseudowire Flow Label = [RFC6391].  Deployments MAY enable = this
      feature for appropriate = pseudowire types.  See Section 2.4.3.

  2. =  The implementer and system designer SHOULD support adding an = MPLS
      entropy label [RFC6790]. =  Deployments MAY enable this = feature.
      See Section = 2.4.4.

I've made this change.  Let me know if this is not = OK.

---

Section = 2.1

  Tunneling encapsulations which may carry MPLS, = such as MPLS in GRE,
  L2TP, or LDP, are out of = scope.

I think s/LDP/UDP/

Yes. =  Thanks.

Could this be = reworded as follows?

NEW:
  =  Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC = 4023], 
   MPLS in GRE [RFC 4023], MPLS in = L2TPv3 [RFC 4817], or MPLS in UDP
  =  [draft-ietf-mpls-in-udp], are out of = scope.

And then for consistency = below:

OLD:
   7. =  Some IP encapsulations support tunneling, such as IP-in-IP, = GRE,
       L2TPv3, and IPSEC.  These = provide a greater source of entropy
      =  which some provider networks carrying large amounts of = tunneled
       traffic may need. =  The use of tunneling header information is out
  =      of scope for this = document.
NEW:
   7.  Some IP = encapsulations support tunneling, such as IP-in-IP, = GRE,
       L2TPv3, and IPSEC.  These = provide a greater source of entropy
      =  which some provider networks carrying large amounts of = tunneled
       traffic may need (e.g., as = used in [RFC 5640] for GRE and L2TPv3).
      =  The use of tunneling header information is out of scope for this = document.


Thanks!
=
Carlos.


---

2.1.1

Maybe the first paragraph should = clarify "special purpose labels at 
the top of the label = stack"

That phrase doesn't appear anywhere in the = document.  Exactly what am
I clarifying?  What to do with = unknown special purpose labels is in
the last paragraph of this = subsection.

---

2.1.1

I = think that this section should note that labels 0-15 were = commonly
referred to as "reserved labels" and are only renamed to = "special
purpose labels" by = [I-D.ietf-mpls-special-purpose-labels].

OLD

&nb= sp; [RFC3032] specifies that label values 0-15 are special = purpose
  labels with special = meanings.

NEW

  [RFC3032] specifies that label = values 0-15 are special purpose
  labels with special = meanings.
+   [I-D.ietf-mpls-special-purpose-labels] = renamed these from the term
+   "reserved labels" used in = [RFC3032] "special purpose labels".

BTW - = draft-ietf-mpls-special-purpose-labels is also waiting for WG
chair = go-ahead.  Hopefully since it is a short document (and I = think
non-controversial) it will go through smoothly and quickly so = we can
change this to an RFC reference.

---

2.1.4

  MPLS hierarchy as = described in [RFC4206] can in principle add up to
  four = additional labels.  MPLS hierarchy is discussed = in
  Section 2.1.6.

Similar text in 2.1.6

I = wonder whether the choice of "four" here is because RFC 4203 = defines
     1 =     Packet-Switch Capable-1 = (PSC-1)
     2 =     Packet-Switch Capable-2 = (PSC-2)
     3 =     Packet-Switch Capable-3 = (PSC-3)
     4 =     Packet-Switch Capable-4 (PSC-4)
If that is = the case, we should note that RFC 7074 deprecates PSC-2 
through 4 recognising = that different switching levels within the PSC
world were not applied = and that LSP nesting was arbitrary and not 
limited to four = levels.

On the other hand, if "four" comes from somewhere else, = perhaps you 
could = give a clue in the text.

OK.  Missed this in = CCAMP otherwise I would have objected to making
this change without = changing the SCSI for the PSC type to includes a
level of hierarchy. =  Though perhaps a 4 byte drop in MTU is a hint.

I'll change = this from "add up to four additional labels" to "at least
one = additional label" and cite RFC 7074.

The PSC-2 and up were needed = if you wanted more than one level of
nesting and needed to know = whether your PSC-1 LSPs could make use of
other PSC FA.  Can be = kludged with admin attributes though.

---

While per platform label space is mentioned in = 2.1.7 I wonder whether
more information on per platform and per = interface label spaces is 
needed. I recall early = implementations that got very confused when
parallel interfaces used = the same label for different purposes.

I guess the point there is = that you cannot assume that your neighbor
is or is not using the per = platform label space.

Upstream label allocation may also come = into this.

The only mention of label allocation is = that MPLS FRR bypass method
(more formally known as facilitles = backup) uses platform label space.

The only reason platform label = space is of any significance in a
document about forwarding is "The = use of platform label space impacts
the size of the LSR ILM for LSR = with a very large number of
interfaces."

Label allocation, per = platform or per interface and upstream or
downstream, is not a = forwarding issue.  It is a software issue
and a matter of = getting the protocol bits right.  Therefore I think
expanding = any further on label allocation should be out of scope.

But yes = ... it is something that can trip up vendors.

---

2.1.8.1

  1.  The most = common case is where reordering occurs is rare,

One too many = instances of "is"

yeah or something like = that.

NEW

  1.  The most common case is = where reordering is rare,

---

2.1.8.1

  3.  If the edge = is not using pseudowire control word (CW) and = the
      core is using multipath, = reordering will be far more common. =  If
      this is occurring, the = best solution is to use CW on the = edge,
      rather than try to fix the = reordering using resequencing.

Completely agree, but isn't the = sequence number contained in a control
word meaning that the = resequencing could, in any case, not be done 
without using a control = word?

I suppose you can't fix reordering caused by = not using CW without the
sequence number in the CW.  That is = going to require fixing the text.

OLD

  3. =  If the edge is not using pseudowire control word (CW) and = the
      core is using multipath, = reordering will be far more = common.
      If this is occurring, the = best solution is to use CW on = the
      edge, rather than try to fix = the reordering using resequencing.

NEW

  3. =  If the edge is not using pseudowire control word (CW) and = the
      core is using multipath, = reordering will be far more = common.
      If this is occurring, = using CW on the edge will solve = the
      problem.  Without CW, = resequencing is not possible since = the
      sequence number is contained = in the CW.

That was a big oops on our part.

---

2.1.8.1

  4.  Another = avoidable case is where some core equipment has = multipath
      and for some reason = insists on periodically installing a = new
      random number as the = multipath hash seed.  If supporting = MPLS-TP,
      equipment MUST provide a = means to disable periodic hash = reseeding
      and deployments MUST = disable periodic hash reseeding.  Even = if
      not supporting MPLS-TP, = equipment should provide a means = to
      disable periodic hash = reseeding and deployments should = disable
      periodic hash = reseeding.

Are those two "should" really = "SHOULD"?

"No" at this point because of the way we = stated we would use the RFC
2119 keywords in Section = 1.2.

Since no existing RFC calls for this it has to be lower = case.

I could (and did so far) change the last = sentence:

OLD

  Even if not supporting MPLS-TP, = equipment should provide a means to
  disable periodic hash = reseeding and deployments should disable
  periodic hash = reseeding.

NEW

  Operator experience dictates = that even if not supporting MPLS-TP,
  equipment SHOULD = provide a means to disable periodic hash reseeding
  and = deployments SHOULD disable periodic hash reseeding.

This would be = consistent with the use of RFC 2119 terms in this
document, = explicitly calling out any requirement not already stated in
an = existing RFC.

The prior MUSTs in the paragraph are upper case = becausse you would
violate MPLS-TP requirements by not doing = something.

---

Should 2.2 = distinguish the order of magnitude of replication at branch
nodes? = This impacts the replication method used (some devices make a
copy = and cycle around, some devices can do multiple copies at once). = On
the whole is no different from IP multicast processing except (as = you
note) that each outgoing packet may be different by its label = value.

Is it possible to quantify the fanout? =  YMMV?

The only thing I could say is that an implementation = may need to make
lots of copies in some roles (access routers for = example).

Making a copy and cycling yields poor performance but = for low
multicast traffic volumes might be OK.  But you are = right - some
mostly low-end-ish chips to this.

I'm not sure I = can describe how multicast with high fanout is done
without wading = into implementation details of specific vendors.

Perhaps the best = I can do is add this:

  Careful consideration should be = given to the performance
  characteristics of high fanout = multicast for equipment that is
  intended to be used in = such a role.

I'll add this before the last paragraph in the = section.

---

2.4

So = obvious you didn't say it?

  In order to support an = adequately balanced load distribution across
  multiple = links, IP header information must be used.  Common = practice
  today is to reinspect the IP headers at each LSR = and use the label
  stack and IP header information in a = hash performed at each LSR.
  Further details are provided = in Section 2.4.5.

Missing is the statement that a single "flow" = must not be distributed 
across multiple paths = because of the implication for potentially
significant packet = misordering. And feeding that is a common requirement
that such = packet misordering must not occur because applications and
transport = protocol implementations cannot survive such = misordering.

Yes.  That requirement was missed. =  Add new second paragraph to = this
subsection.

  The Differentiated Services = requirements for good reasons dictate
  that packets within = a common microflow SHOULD NOT be reordered
  [RFC2474]. =  Service providers generally impose = stronger
  requirements, commonly requiring that packets = within a microflow
  MUST NOT be reordered except in rare = circumstances such as load
  balancing across multiple = links or path change for load balancing
  or path change = for other reason.

Another SP requirement is stated here and I'm = quite sure this
requirement is well accepted.

---

2.4.2 uses "composite link" and "component = link". I suggest picking just
one term.

They are = two different things.  Two or more component links make up = a
composite link.  Knowing that, give it another read = please.

I'd rather not cite draft-ietf-rtgwg-cl-requirements as = an
informational reference just for this one term.  In favor of = citing
it, draft-ietf-rtgwg-cl-requirements is moving along. =  Against citing
it is there is far less than a ground swell of = providers calling for
the full set of things asked for in = draft-ietf-rtgwg-cl-requirements.

---

2.4.5.1 notes that special purpose and extended = special purpose labels 
need to be excluded = from the hash. Good.
But it seems that some special purpose labels = will indicate that the 
next label stack entry = contains a label with special meaning. (ELI is
an example that we = specifically don't have to worry about.)
How do we handle = that?
Should we be dividing up the extended special purpose label = space to
have one set of code points meaning "just this label is = special" and
another set meaning "this label is special and the next = label stack
entry is magic"?

I did list ELI = (bullet 2) before the more general rule of not useing
special purpose = labels.  The ELI is not used, just the EL, so the text
could be = considered correct as-is.

So far the only special purpose label = that is not just ignored and
skipped over is ELI.

Regarding = this being magic -- All of this is somewhat programable
specialized = silicon magic.  The silicon generally has some form of
very = fast, very light weight parsing engine at the front of the
pipeline. =  One thing it does is pick out fields for load balance.

The = better silicon hashes as it goes rather that pick out a set of
fields = and then hashes that set of fields when its done.  When it = sees
13 it skips and hashes the next thing and stops hashing = completely.
If it sees 0-12,14 it skips and continues.  If it = sees 15 it skips two
labels and continues.  Its should be = programable enough that if
someone defines a new ELI like label it is = likely to be able to deal
with it.

The not so good silicon has = this all so hard wired that it won't be
able to do ELI without at = least a respin.

At most I could add "If a new special purpose = label or extended
special purpose label is defined which requires = special load balance
processing then, as is the case for the ELI = label, a spacial action
may be needed rather than skipping the = special purpose label or
extended special purpose label."  I = really don't think this is needed.

---

An issue that arises from the multipath support = (2.4.5.1) is that
hardware assumes that after a label stack entry = with the S-bit set,
there are only three possible next bytes...
- = a control word (indicated by b0000 or b0001)
- an IPv4 header
- an = IPv6 header
This is the case regardless of how the LSP was set up, = and the next
bytes cannot ever be further MPLS stack = entries.

Right.  Note that in (5) is says that = some SP will require IP headers
and some will require an ability to = disable IP headers.

The rule is really look for 4, 6, or anything = else in the first
nibble.  If 4 or 6 assume IP.  If = anything else stop.

And yes if the payload is MPLS after a S-bit = you have a screwed up
MPLS implementation to start with and you won't = get load balance on
any set of MPLS labels after the first S-bit. =  This is a fact of life
in the field and is as it should = be.

While this comes up 2.4.5.1 it may = merit further discussion in an
earlier section of the = document.

This text is part of 2.4. ("MPLS Multipath = Techniques").  The third
paragraph contains "Further details are = provided in Section 2.4.5."
Section 2.4.5. is "Fields Used for = Multipath Load Balance".

I note that = discussion of support of PWs without the CW drives you
to say that = hashing beyond the S-bit should be a configurable option
which would = (of course) support any payload including MPLS in MPLS
with repeated = bottom of stack. However, you might want to specifically
preclude = that.

It says the same thing here in bullet 5 = regarding being configurable.
The wording "ability to disable" is = same as "configurable option".

At no point in this document do we = imply that looking beyond the S-bit
means looking at anything beyond = the S-bit other than looking for IP.
This is very clear in [RFC4385] = and [RFC4928] which is cited in the
text about PW CW.

All it = says in the places discusing PW is that without CW the traffic
might = get reordered.

If you feel that we at any point imply that lack = of PW CW allows
looking at anything past the S-bit rather than just = looking for an IP
header please point to where and we will have to = correct that.  I
looked at all occurances of CW and did not find = anything.

Bullet 5 is very clear that a 4 or 6 has to be found in = the first
nibble of payload.

---

Q#7 introduces the terms "short-pipe" and = "uniform model". It provides
a pointer to 2.1.6, but that section = does not mention these terms (and
doesn't refer to RFC = 3270).

It really should say "See Section 2.1.6 = regarding MPLS hierarchy.  See
[RFC3443] regarding PHP, UHP, and = pipe, short-pipe, and uniform models."

It does = now.

---

Section 7 could = usefully point back at Section 2.6.1

I'll = add:

  Some advice on hardware and other equipment = hardenning against
  Denial-of-Service attack can be found = in Section 2.6.1.

The security ADs will have fun with that. =  They'll love the comments
about crypto auth being the last line = of defense not the first and
only line of defense.  I'll plan on = discussing this in greater detail
when SecDir review comes = along.

I thik the security AD will want to reword the prior = paragraph as well
as they seem to have some very precise preferred = wording.

Curtis
_______________________________________________<= br>mpls mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls

= --Apple-Mail=_3681EDCE-9D17-4BCC-9F9E-037139BD72FC-- --Apple-Mail=_D39CCBFF-AA22-4D51-A836-0F52A1CA9C04 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLmVNIACgkQtfDPGTp3USxlqACfZv+I2MVldONxiiwyHI8XERyd xgoAn3Hv/0p634jYelLo8GZjFxgF9Loj =AoSq -----END PGP SIGNATURE----- --Apple-Mail=_D39CCBFF-AA22-4D51-A836-0F52A1CA9C04-- From huubatwork@gmail.com Mon Jan 27 04:52:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A561A0213 for ; Mon, 27 Jan 2014 04:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T2bh3mEqtWP for ; Mon, 27 Jan 2014 04:52:23 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CA1FC1A0209 for ; Mon, 27 Jan 2014 04:52:22 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id y10so5526366wgg.10 for ; Mon, 27 Jan 2014 04:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yIs3uGUWplpSBE6xmGMtVpa6WNT7U4cN5TO57fVOT10=; b=J/sDhXBNYGrzjVsWUWX2AtRHJ/XPBZGxblzKmurws70Thnz8SsiIhgOyEnDq0aURT1 02vx9lmlF37eTqSmVpIE9qj4y93Qfxpq3sEDgSxFo3Q8Rh8RujXOUHZFkfXb9+wAfnyn MH7oB+sTkLyFD0l1ZARk8CT48+vY0ofs3OTlYzHg/skzmRh963ViGYuioVKV4yV5xlNp HLqvWwuAChSB9Q77L8sHjx6FckDfEGQ+sbEqPIxOb3oLe5ixgpyu8DOvpOiXRVkxrpdH InPlGMdfNpHoVrj60swr7r59QRWRmoeJJvClNxhi7AA730v4frmLjIrp3FO92HiiYYcE KmFA== X-Received: by 10.194.87.104 with SMTP id w8mr137165wjz.90.1390827140266; Mon, 27 Jan 2014 04:52:20 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id e5sm25011253wja.15.2014.01.27.04.52.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 04:52:19 -0800 (PST) Message-ID: <52E65681.3080104@gmail.com> Date: Mon, 27 Jan 2014 13:52:17 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Loa Andersson , "mpls@ietf.org" References: <52E64660.2090900@pi.nu> In-Reply-To: <52E64660.2090900@pi.nu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] IPR poll draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 12:52:24 -0000 WG-chairs, Apart from the IPR mentioned below I am not aware of any other IPR. Best regards, Huub. ==== > draft-ietf-mpls-tp-psc-itu is in working group last call, we have just > received an IPR disclosure: > > http://www.ietf.org/mail-archive/web/mpls/current/msg11469.html > > This gives us reason to start an IPR poll on the document. > > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-tp-psc-itu? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there is the one IPR disclosure, mentioned above, that > relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From curtis@ipv6.occnc.com Mon Jan 27 07:47:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CF01A0251 for ; Mon, 27 Jan 2014 07:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 vDKnGqssyVDl for ; Mon, 27 Jan 2014 07:47:52 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEEF1A021B for ; Mon, 27 Jan 2014 07:47:52 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0RFlhJ9087183; Mon, 27 Jan 2014 10:47:43 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401271547.s0RFlhJ9087183@maildrop2.v6ds.occnc.com> To: "Carlos Pignataro (cpignata)" From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 12:45:09 +0000." <67516608-AAA0-49A1-B1E2-3DF146190D2C@cisco.com> Date: Mon, 27 Jan 2014 10:47:43 -0500 Cc: "mpls@ietf.org" , "draft-ietf-mpls-forwarding.all@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 15:47:55 -0000 Carlos, Since your apple mailer setting scrambled the plain text version a bit, I'm going to just snip out the relevent parts and reply inline. In message <67516608-AAA0-49A1-B1E2-3DF146190D2C@cisco.com> "Carlos Pignataro (cpignata)" writes: > Hi Curtis, > > Many thanks for these! Ack to all. > > Reading through your proposed changes, please find one small request = > inline: > > On Jan 26, 2014, at 11:58 PM, Curtis Villamizar = > wrote: > > >=20 > > In message <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk> > > "Adrian Farrel" writes: > >>=20 [... big snip ...] > >> --- > >> > >> Section 2.1 > >> > >> Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, > >> L2TP, or LDP, are out of scope. > >> > >> I think s/LDP/UDP/ > > > > Yes. Thanks. > > Could this be reworded as follows? > > NEW: > Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC 4023], > MPLS in GRE [RFC 4023], MPLS in L2TPv3 [RFC 4817], or MPLS in UDP > [draft-ietf-mpls-in-udp], are out of scope. I don't cite documents that define things that are declared out of scope. For example, I don't cite documents defining the various flavors of PW AC that are declared out of scope. In this case I listed a few examples so that the phrase "Tunneling encapsulations carrying MPLS" was a bit more clear. The references section is already quite large. > And then for consistency below: > > OLD: > 7. Some IP encapsulations support tunneling, such as IP-in-IP, GRE, > L2TPv3, and IPSEC. These provide a greater source of entropy > which some provider networks carrying large amounts of tunneled > traffic may need. The use of tunneling header information is out > of scope for this document. > NEW: > 7. Some IP encapsulations support tunneling, such as IP-in-IP, GRE, > L2TPv3, and IPSEC. These provide a greater source of entropy > which some provider networks carrying large amounts of tunneled > traffic may need (e.g., as used in [RFC 5640] for GRE and = > L2TPv3). > The use of tunneling header information is out of scope for this = > document. Same reasoning. If we declare something out of scope we shouldn't then describe it further and provide citations. At one point Andy floated the idea of a PWE3 forwarding draft in the relevant WG. If you want to do a GRE forwarding draft, have at it, but it might be in another WG with MPLS being only one of the things that GRE can carry that might need entropy. > Thanks! > > Carlos. Good suggestions if we hadn't declared these things out of scope. We do have to limit the scope to avoid turning this into a complete "how to build a router" document and I've tried to avoid scope creep into realms outside of MPLS. One place were we don't do similar citations but maybe we should is: Support for other protocols that share a common Layer-4 header such as RTP, UDP-lite, SCTP and DCCP SHOULD be provided, particularly for edge or access equipment where additional entropy may be needed. Equipment SHOULD also use RTP, UDP-lite, SCTP and DCCP headers when creating an entropy label. I didn't add citations to each of these protocols to avoid further reference section bloat and because they are well known and easy to find in the rfc-index file. This is creeping to the edge of the defined document scope, but the WG raging discussion of UDP checksums indicates that we really need the SHOULD for at least UDP-Lite and probably for the others as well. Curtis [... big snip ...] From stbryant@cisco.com Mon Jan 27 08:40:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B911A0276; Mon, 27 Jan 2014 08:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 MUYC7CJ9KC9D; Mon, 27 Jan 2014 08:40:56 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id C017E1A029C; Mon, 27 Jan 2014 08:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=822; q=dns/txt; s=iport; t=1390840854; x=1392050454; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iaxdndm+s+9xAew4nIrH3Gjx/fIspLkrns2aB9rsCwM=; b=Hpug268PCSHkRhvtUcpntgjdTLXFk18GSvKLCfh88PMtvRi8DhV3YCHA DxKmvlRkLlsQoGdjV2dgZ90TtHo3r3STD1dXNMICmstmf4BWy6H5JEqYN jKM9psrBv3cSNHW3pBfk4g1syqnwbvuSrZXQd16X+3/FF5f6n4/ScUr2L E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAPyK5lKQ/khR/2dsb2JhbABZDoJ+OL0vgRUWdIIlAQEBBDhAARALGAkWBAsJAwIBAgFFBgEMAQcBAQWHfA3HEReOPAEBTweEOAEDmCeSHoFvfz+BcQ X-IronPort-AV: E=Sophos;i="4.95,729,1384300800"; d="scan'208";a="4256365" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 27 Jan 2014 16:40:53 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0RGeq4x018651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jan 2014 16:40:52 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0RGeou7025359; Mon, 27 Jan 2014 16:40:51 GMT Message-ID: <52E68C12.2050308@cisco.com> Date: Mon, 27 Jan 2014 16:40:50 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joe Touch , curtis@ipv6.occnc.com References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> In-Reply-To: <52E2BBC0.2030203@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 16:40:58 -0000 On 24/01/2014 19:15, Joe Touch wrote: > >> This eliminates the "expands the reach of MPLS argument". >> >> First UDP checksums: >> >> The UDP checksum is at the beginning of the payload. Please see >> http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html >> This makes filling in a new UDP checksum infeasible on most high end >> hardware. > > That argument would make sense if most hardware wasn't > store-and-forward on a per-packet basis. They may be store and forward, but most of the high end designs use multiple grades of memory putting the packet in "slow memory" and providing a snapshot of the header in "fast memory" to the forwarder. Thus although the whole packet is in the system, it it is not accessible to the engine that would need to calculate the c/s. Stewart From touch@isi.edu Mon Jan 27 08:49:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37611A035C; Mon, 27 Jan 2014 08:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 2QEZEbwtpVby; Mon, 27 Jan 2014 08:49:48 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6F61A0250; Mon, 27 Jan 2014 08:49:48 -0800 (PST) Received: from [192.168.1.97] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s0RGmZJH003804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Jan 2014 08:48:39 -0800 (PST) References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> In-Reply-To: <52E68C12.2050308@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> X-Mailer: iPhone Mail (11B554a) From: Joe Touch Date: Mon, 27 Jan 2014 08:48:35 -0800 To: "stbryant@cisco.com" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 16:49:50 -0000 Those same mechanisms have provided hardware checksum support for a very lon= g time.=20 Joe > On Jan 27, 2014, at 8:40 AM, Stewart Bryant wrote: >=20 >> On 24/01/2014 19:15, Joe Touch wrote: >>=20 >>> This eliminates the "expands the reach of MPLS argument". >>>=20 >>> First UDP checksums: >>>=20 >>> The UDP checksum is at the beginning of the payload. Please see >>> http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html >>> This makes filling in a new UDP checksum infeasible on most high end >>> hardware. >>=20 >> That argument would make sense if most hardware wasn't store-and-forward o= n a per-packet basis. > They may be store and forward, but most of the high end designs > use multiple grades of memory putting the packet in "slow memory" > and providing a snapshot of the header in "fast memory" to the > forwarder. Thus although the whole packet is in the system, it > it is not accessible to the engine that would need to calculate the > c/s. >=20 > Stewart From stbryant@cisco.com Mon Jan 27 09:16:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCB21A02CF; Mon, 27 Jan 2014 09:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 bQ6KE1u2kuej; Mon, 27 Jan 2014 09:16:23 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6581A024C; Mon, 27 Jan 2014 09:16:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1314; q=dns/txt; s=iport; t=1390842981; x=1392052581; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=AmzRjME8C6wrg13eGk7lsXy7FVA02Is8vaR249QsW0Y=; b=bX8bEa3bxD1wrMP1CkKAq9b7UnBWu6+6OWtQ25MXglUiTqAA5lGOiGxr LiZlO8OgeiWLg4iGo1MLYxxZGg1dZtfcJRXjO3NnaubQSWGaviEfdf/zK Q8+Ftv3A0+yj9DF/YwQVlaelBe5CL5IDSgmU964Zu0T0cnq9LQ7AQuH01 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgSAOWT5lKQ/khM/2dsb2JhbABaDoFkAgGBFzi9L4EWFnSCJQEBAQQ4QAEQCxgJFgQLCQMCAQIBRQYNAQUCAQEFh3wNxxQXjjwBAU8HhDgBA5gnkh6Bb38/gXE X-IronPort-AV: E=Sophos;i="4.95,730,1384300800"; d="scan'208";a="3589030" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 27 Jan 2014 17:16:20 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0RHGKMJ006581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jan 2014 17:16:20 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0RHGIAV027530; Mon, 27 Jan 2014 17:16:19 GMT Message-ID: <52E69462.9030703@cisco.com> Date: Mon, 27 Jan 2014 17:16:18 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joe Touch References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> In-Reply-To: <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 17:16:26 -0000 Sorry, are you talking the same h/w that does IP c/s? That h/w can only see the IP header. S On 27/01/2014 16:48, Joe Touch wrote: > Those same mechanisms have provided hardware checksum support for a very long time. > > Joe > >> On Jan 27, 2014, at 8:40 AM, Stewart Bryant wrote: >> >>> On 24/01/2014 19:15, Joe Touch wrote: >>> >>>> This eliminates the "expands the reach of MPLS argument". >>>> >>>> First UDP checksums: >>>> >>>> The UDP checksum is at the beginning of the payload. Please see >>>> http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html >>>> This makes filling in a new UDP checksum infeasible on most high end >>>> hardware. >>> That argument would make sense if most hardware wasn't store-and-forward on a per-packet basis. >> They may be store and forward, but most of the high end designs >> use multiple grades of memory putting the packet in "slow memory" >> and providing a snapshot of the header in "fast memory" to the >> forwarder. Thus although the whole packet is in the system, it >> it is not accessible to the engine that would need to calculate the >> c/s. >> >> Stewart > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From touch@isi.edu Mon Jan 27 10:01:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8DD1A001E; Mon, 27 Jan 2014 10:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 rWy0CR_VzjB3; Mon, 27 Jan 2014 10:01:17 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id AC1D41A0256; Mon, 27 Jan 2014 10:01:17 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0RI0olq024489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jan 2014 10:00:53 -0800 (PST) Message-ID: <52E69ED3.1060005@isi.edu> Date: Mon, 27 Jan 2014 10:00:51 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: stbryant@cisco.com References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E69462.9030703@cisco.com> In-Reply-To: <52E69462.9030703@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 18:01:20 -0000 On 1/27/2014 9:16 AM, Stewart Bryant wrote: > > Sorry, are you talking the same h/w that does IP c/s? It's been trivial to implement this for TCP checksums for a long time. 18 years ago I showed how to do it for what was then $40 at 1Gbps (RFC 1936). They're done in hardware in many network interface cards on end systems, and it's been necessary for routers that use TCP tunnels as well. Splitting headers from packet body for high-throughput routing has been known and done for a long time too (e.g., S. Walton, A. Hutton, and J. Touch, “High-Speed Data Paths in Host-Based Routers,” IEEE Computer, Nov. 1998, pp. 46-52.); during body transfer, the contents can easily be summed, and that sum can be combined with the header sum easily too. Joe > That h/w can only see the IP header. > > S > > > On 27/01/2014 16:48, Joe Touch wrote: >> Those same mechanisms have provided hardware checksum support for a >> very long time. >> >> Joe >> >>> On Jan 27, 2014, at 8:40 AM, Stewart Bryant wrote: >>> >>>> On 24/01/2014 19:15, Joe Touch wrote: >>>> >>>>> This eliminates the "expands the reach of MPLS argument". >>>>> >>>>> First UDP checksums: >>>>> >>>>> The UDP checksum is at the beginning of the payload. Please see >>>>> http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html >>>>> This makes filling in a new UDP checksum infeasible on most high >>>>> end >>>>> hardware. >>>> That argument would make sense if most hardware wasn't >>>> store-and-forward on a per-packet basis. >>> They may be store and forward, but most of the high end designs >>> use multiple grades of memory putting the packet in "slow memory" >>> and providing a snapshot of the header in "fast memory" to the >>> forwarder. Thus although the whole packet is in the system, it >>> it is not accessible to the engine that would need to calculate the >>> c/s. >>> >>> Stewart >> . >> > > From rgandhi@cisco.com Mon Jan 27 10:04:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D131A02D6 for ; Mon, 27 Jan 2014 10:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 nWo3LigWPNbZ for ; Mon, 27 Jan 2014 10:04:04 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7D01A001E for ; Mon, 27 Jan 2014 10:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1712; q=dns/txt; s=iport; t=1390845842; x=1392055442; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5AAsziPELbmbkJjXYTzcgWG/0CDUHDldCZhY4vnY4nk=; b=gMqxZH+tbR0fdxupF/PManYgpar0KQ7OERJsgij1h+B7WaSHu2gnokqS j9YDGrfryDjv/ohv4CJMJVorfArJVuMQu8GcUsj89Jp7aSKJELDo+Jooo HlGUV7OWPC1EhJMCNG3fkt9wgCKR/2P16N35ePFJqYnICENZHL1DZmEYh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAK+e5lKtJXG+/2dsb2JhbABagww4VrxagRYWdIIsOj0CEgEIDihCJQIEAQ0FCYd8DccCF48NB4Q4BJgngTKQbIMtgio X-IronPort-AV: E=Sophos;i="4.95,730,1384300800"; d="scan'208";a="299985851" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jan 2014 18:04:01 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0RI41aK014776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jan 2014 18:04:01 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.197]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Mon, 27 Jan 2014 12:04:01 -0600 From: "Rakesh Gandhi (rgandhi)" To: Yuji Kamite , "Tarek Saad (tsaad)" , "Zafar Ali (zali)" , "Robert H. Venator" , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-tsaad-mpls-p2mp-loose-path-reopt-00.txt Thread-Index: AQHPGQGYQ5Ldzb4KhESvDKgBl3UBa5qY8w0A Date: Mon, 27 Jan 2014 18:04:00 +0000 Message-ID: In-Reply-To: <20140124124120.28917.21823.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.3.5.130515 x-originating-ip: [10.86.242.201] Content-Type: text/plain; charset="us-ascii" Content-ID: <32FF5D2ADEB1D24182EC8C9FF4E897BC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] New Version Notification for draft-tsaad-mpls-p2mp-loose-path-reopt-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 18:04:05 -0000 Hi MPLS WG, We have uploaded an ID for the Inter-area P2MP-TE RSVP signalling extensions, specifically for the Preferred Path Query and Notification for LSP Tree re-optimization. http://www.ietf.org/internet-drafts/draft-tsaad-mpls-p2mp-loose-path-reopt- 00.txt We like to request the WG for feedbacks and comments. Many Thanks, Rakesh On 2014-01-24 7:41 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-tsaad-mpls-p2mp-loose-path-reopt-00.txt >has been successfully submitted by Rakesh Gandhi and posted to the >IETF repository. > >Name: draft-tsaad-mpls-p2mp-loose-path-reopt >Revision: 00 >Title: Reoptimization of Point-to-Multipoint Traffic Engineering Loosely >Routed LSPs >Document date: 2014-01-24 >Group: Individual Submission >Pages: 8 >URL: =20 >http://www.ietf.org/internet-drafts/draft-tsaad-mpls-p2mp-loose-path-reopt >-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-tsaad-mpls-p2mp-loose-path-reopt/ >Htmlized: =20 >http://tools.ietf.org/html/draft-tsaad-mpls-p2mp-loose-path-reopt-00 > > >Abstract: > This document defines signaling extensions to Resource > Reservation Protocol - Traffic Engineering (RSVP-TE) for reoptimizing > loosely routed point-to-multipoint (P2MP) Traffic Engineered (TE) > Label Switched Path (LSP) in an Multi-Protocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) networks. > > > =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 joelja@bogus.com Mon Jan 27 10:49:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05131A0276; Mon, 27 Jan 2014 10:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 UpBZmwrp5IkO; Mon, 27 Jan 2014 10:49:00 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 775C81A0264; Mon, 27 Jan 2014 10:49:00 -0800 (PST) Received: from 02351a-maguilar.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0RImiKS042439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jan 2014 18:48:44 GMT (envelope-from joelja@bogus.com) Message-ID: <52E6AA0B.1050600@bogus.com> Date: Mon, 27 Jan 2014 10:48:43 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Joe Touch , "stbryant@cisco.com" References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> In-Reply-To: <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OriKbApKhGlWr638DuclAaA0Sme6Slsso" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 27 Jan 2014 18:48:45 +0000 (UTC) Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 18:49:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OriKbApKhGlWr638DuclAaA0Sme6Slsso Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/27/14, 8:48 AM, Joe Touch wrote: > Those same mechanisms have provided hardware checksum support for a ver= y long time.=20 The new header and the payload are actually in different parts of the forwarding complex until they hit the output queue, you can't checksum data you don't have. > Joe >=20 >> On Jan 27, 2014, at 8:40 AM, Stewart Bryant wrote= : >> >>> On 24/01/2014 19:15, Joe Touch wrote: >>> >>>> This eliminates the "expands the reach of MPLS argument". >>>> >>>> First UDP checksums: >>>> >>>> The UDP checksum is at the beginning of the payload. Please see >>>> http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html >>>> This makes filling in a new UDP checksum infeasible on most high e= nd >>>> hardware. >>> >>> That argument would make sense if most hardware wasn't store-and-forw= ard on a per-packet basis. >> They may be store and forward, but most of the high end designs >> use multiple grades of memory putting the packet in "slow memory" >> and providing a snapshot of the header in "fast memory" to the >> forwarder. Thus although the whole packet is in the system, it >> it is not accessible to the engine that would need to calculate the >> c/s. >> >> Stewart >=20 --OriKbApKhGlWr638DuclAaA0Sme6Slsso Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmqgwACgkQ8AA1q7Z/VrJ0zACeJrp+2AtldVjwugnNSUZYioX3 sX0An3nU4rW8YFZ58lK3lkrH/mGl7oX2 =6qzZ -----END PGP SIGNATURE----- --OriKbApKhGlWr638DuclAaA0Sme6Slsso-- From touch@isi.edu Mon Jan 27 10:53:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD461A02A4; Mon, 27 Jan 2014 10:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 r85c620Ak3Vp; Mon, 27 Jan 2014 10:53:53 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF461A0239; Mon, 27 Jan 2014 10:53:53 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0RIr9lx006196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jan 2014 10:53:09 -0800 (PST) Message-ID: <52E6AB15.2080907@isi.edu> Date: Mon, 27 Jan 2014 10:53:09 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: joel jaeggli , "stbryant@cisco.com" References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> In-Reply-To: <52E6AA0B.1050600@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 18:53:54 -0000 On 1/27/2014 10:48 AM, joel jaeggli wrote: > On 1/27/14, 8:48 AM, Joe Touch wrote: >> Those same mechanisms have provided hardware checksum support for a very long time. > > The new header and the payload are actually in different parts of the > forwarding complex until they hit the output queue, you can't checksum > data you don't have. You can (and some do) the checksum component parts when things go into memory; the partial sums can be added as the parts are combined in the output queue. I appreciate that we're all taking about what might be done, but the reality is that there are many 'transparent TCP proxies' that have to do this, so there's clearly a solution, and it clearly runs fast enough. Joe From cpignata@cisco.com Mon Jan 27 10:59:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B41A027B for ; Mon, 27 Jan 2014 10:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 l000R1FjoY1H for ; Mon, 27 Jan 2014 10:59:42 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id AD4B41A0256 for ; Mon, 27 Jan 2014 10:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6356; q=dns/txt; s=iport; t=1390849180; x=1392058780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=usRd7E+yCD45yvO5apfR1bPXOaRAJxgzwMrKnkFRGtY=; b=HLLxvUOTuUkdvDrdR3/c0+4mq1Qzyf6l+hnOhTiEE0Jyut7o4yjSRDxp BqhneY42KDNs0a3PQmlLYiFpFFtH4eRRZGTim4AjEOzgZKQI3ZPuPSroi 2l9RaAiZKe7/W/g3GCsxUP00xaST0rzC8xLyNXysr0b6jHtFGaKQmlsDJ A=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJKr5lKtJXG8/2dsb2JhbABagwyBDqoYkkOBFhZ0giUBAQEDASdSBQsCAQgYLjIlAgQOBQ6HbwjHCBeOKgxXB4MkgRQEkD2BMoY4kh6DLYFpQQ X-IronPort-AV: E=Sophos;i="4.95,730,1384300800"; d="asc'?scan'208";a="15872740" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 27 Jan 2014 18:59:40 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0RIxefr024206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jan 2014 18:59:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 27 Jan 2014 12:59:39 -0600 From: "Carlos Pignataro (cpignata)" To: "" Thread-Topic: [mpls] AD review of draft-ietf-mpls-forwarding Thread-Index: AQHPG3cdjS/uX4Lbv0ORQoMPNhcQYJqZUYEA Date: Mon, 27 Jan 2014 18:59:39 +0000 Message-ID: <628D8298-6C81-474A-A5A5-8237E0A3A89A@cisco.com> References: <201401271547.s0RFlhJ9087183@maildrop2.v6ds.occnc.com> In-Reply-To: <201401271547.s0RFlhJ9087183@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.54] Content-Type: multipart/signed; boundary="Apple-Mail=_318A0E35-B081-497F-A422-85535AF062D4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "draft-ietf-mpls-forwarding.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 18:59:44 -0000 --Apple-Mail=_318A0E35-B081-497F-A422-85535AF062D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Curtis, On Jan 27, 2014, at 10:47 AM, Curtis Villamizar = wrote: >=20 > Carlos, >=20 > Since your apple mailer setting scrambled the plain text version a > bit, I'm going to just snip out the relevent parts and reply inline. Thanks :-) >=20 > In message <67516608-AAA0-49A1-B1E2-3DF146190D2C@cisco.com> > "Carlos Pignataro (cpignata)" writes: >=20 >> Hi Curtis, >>=20 >> Many thanks for these! Ack to all. >>=20 >> Reading through your proposed changes, please find one small request = =3D >> inline: >>=20 >> On Jan 26, 2014, at 11:58 PM, Curtis Villamizar = =3D >> wrote: >>=20 >>> =3D20 >>> In message <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk> >>> "Adrian Farrel" writes: >>>> =3D20 >=20 > [... big snip ...] >=20 >>>> --- >>>>=20 >>>> Section 2.1 >>>>=20 >>>> Tunneling encapsulations which may carry MPLS, such as MPLS in = GRE, >>>> L2TP, or LDP, are out of scope. >>>>=20 >>>> I think s/LDP/UDP/ >>>=20 >>> Yes. Thanks. >>=20 >> Could this be reworded as follows? >>=20 >> NEW: >> Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC = 4023], >> MPLS in GRE [RFC 4023], MPLS in L2TPv3 [RFC 4817], or MPLS in UDP >> [draft-ietf-mpls-in-udp], are out of scope. >=20 > I don't cite documents that define things that are declared out of > scope. For example, I don't cite documents defining the various > flavors of PW AC that are declared out of scope. >=20 > In this case I listed a few examples so that the phrase "Tunneling > encapsulations carrying MPLS" was a bit more clear. >=20 OK. Please note that there are a couple of (very small) changes besides = the citations: * Tunneling encapsulations which may carry MPLS -> Tunneling = encapsulations carrying MPLS * such as MPLS in GRE, L2TP, or LDP -> such as MPLS in IP, MPLS in GRE, = MPLS in L2TPv3, or MPLS in UDP > The references section is already quite large. The document is not short :-) Looking at it right now, the "Normative References" section is actually = not large for this document. The "Informative References" is large, but I do not see that as an = issue. As you know, informative references only provide additional = contextual non-normative information. Only readers that are interested = in a specific tangent will go there. I see that adding these informative = references has no draw-back, but can help readers that would like to = understand more about "Tunneling encapsulations carrying MPLS". I;d = really add them. That said, if you believe that the document gets worst (e.g., too large = and distractive) by adding these, or that it is inconsistent with other = references, it's OK. >=20 >> And then for consistency below: >>=20 >> OLD: >> 7. Some IP encapsulations support tunneling, such as IP-in-IP, = GRE, >> L2TPv3, and IPSEC. These provide a greater source of entropy >> which some provider networks carrying large amounts of tunneled >> traffic may need. The use of tunneling header information is = out >> of scope for this document. >> NEW: >> 7. Some IP encapsulations support tunneling, such as IP-in-IP, = GRE, >> L2TPv3, and IPSEC. These provide a greater source of entropy >> which some provider networks carrying large amounts of tunneled >> traffic may need (e.g., as used in [RFC 5640] for GRE and =3D >> L2TPv3). >> The use of tunneling header information is out of scope for = this =3D >> document. >=20 > Same reasoning. If we declare something out of scope we shouldn't > then describe it further and provide citations. >=20 It definitely is out of scope for the document. But if a reader's scope = is interested, it would help to be informational about it. As per above, either way is fine. Thanks for considering it. > At one point Andy floated the idea of a PWE3 forwarding draft in the > relevant WG. If you want to do a GRE forwarding draft, have at it, > but it might be in another WG with MPLS being only one of the things > that GRE can carry that might need entropy. >=20 Ack. >> Thanks! >>=20 >> Carlos. >=20 > Good suggestions if we hadn't declared these things out of scope. We > do have to limit the scope to avoid turning this into a complete "how > to build a router" document and I've tried to avoid scope creep into > realms outside of MPLS. >=20 > One place were we don't do similar citations but maybe we should is: >=20 > Support for other protocols that share a common Layer-4 header such > as RTP, UDP-lite, SCTP and DCCP SHOULD be provided, particularly > for edge or access equipment where additional entropy may be > needed. Equipment SHOULD also use RTP, UDP-lite, SCTP and DCCP > headers when creating an entropy label. >=20 > I didn't add citations to each of these protocols to avoid further > reference section bloat and because they are well known and easy to > find in the rfc-index file. This is creeping to the edge of the > defined document scope, but the WG raging discussion of UDP checksums > indicates that we really need the SHOULD for at least UDP-Lite and > probably for the others as well. >=20 :-) To me, the line is drawn at areas that directly touch MPLS. For example, = the UDP one is a good one to add, as we saw that discussion. Similarly, = encapsulating MPLS in other tunnels is of interest to folks, even if out = of scope for the doc (and hence, not Normative, as opposed to not = "Citable/Referenceable"). Thanks, -- Carlos. > Curtis >=20 >=20 > [... big snip ...] --Apple-Mail=_318A0E35-B081-497F-A422-85535AF062D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLmrJoACgkQtfDPGTp3USxRRQCg1Fwlgi2Je34m6DWKWsd3j6fb PAoAoNtV/C3e3LTO1pz0BVCrKUPNmZoI =7ZRi -----END PGP SIGNATURE----- --Apple-Mail=_318A0E35-B081-497F-A422-85535AF062D4-- From jmh@joelhalpern.com Mon Jan 27 11:19:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02DD1A034B; Mon, 27 Jan 2014 11:19:10 -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 sYqcEwHlF2be; Mon, 27 Jan 2014 11:19:09 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 27A8B1A0264; Mon, 27 Jan 2014 11:19:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 096EF102BF0; Mon, 27 Jan 2014 11:19:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 087C3102B42; Mon, 27 Jan 2014 11:19:05 -0800 (PST) Message-ID: <52E6B128.8060306@joelhalpern.com> Date: Mon, 27 Jan 2014 14:19:04 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joe Touch , joel jaeggli , "stbryant@cisco.com" References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu> In-Reply-To: <52E6AB15.2080907@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:19:11 -0000 Yes Joe, routers could ahve been built to do those calcualtions at that performance scale. There are however two major problems: 1) That is not how routers are built. 2) The target performance scale is rather higher. So could someone build an ASIC to do what you want? Probably. Is there any reason in the world to expect operators to pay the significant extra cost for such? Not that I can see. And even if we could and they would, that is not the world into which we are deploying these tunnels. Yours, Joel On 1/27/14 1:53 PM, Joe Touch wrote: > > > On 1/27/2014 10:48 AM, joel jaeggli wrote: >> On 1/27/14, 8:48 AM, Joe Touch wrote: >>> Those same mechanisms have provided hardware checksum support for a >>> very long time. >> >> The new header and the payload are actually in different parts of the >> forwarding complex until they hit the output queue, you can't checksum >> data you don't have. > > You can (and some do) the checksum component parts when things go into > memory; the partial sums can be added as the parts are combined in the > output queue. > > I appreciate that we're all taking about what might be done, but the > reality is that there are many 'transparent TCP proxies' that have to do > this, so there's clearly a solution, and it clearly runs fast enough. > > Joe > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From iesg-secretary@ietf.org Mon Jan 27 11:19:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A70F1A0264; Mon, 27 Jan 2014 11:19:54 -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 JKMXtaraHWi9; Mon, 27 Jan 2014 11:19:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C13CE1A03B6; Mon, 27 Jan 2014 11:19:45 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127191945.14438.77752.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 11:19:45 -0800 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry' to Proposed Standard (draft-ietf-mpls-moving-iana-registries-04.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:19:54 -0000 The IESG has approved the following document: - 'Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry' (draft-ietf-mpls-moving-iana-registries-04.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-moving-iana-registries/ Technical Summary RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-Ach. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh)" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This document updates RFC 5586. This document also updates RFC 6374, RFC 6428, RFC 6378, RFC 6427, RFC-ietf-mpls-gach-adv, and RFC-ietf-mpls-tp-ethernet-addressing. Working Group Summary There is solid WG consensus to progress this document. Document Quality This document has been carefully reviewed by the MPLS WG. It does not define a protocol and thus cannot be implemented, other than by creating a well organized IANA registry. Personnel Ross Callon is the Document Shepherd. Adrian Farrel is the Responsible Area Director. RFC Editor Note Please coordinate with IANA on the changes introduced by this document. Two documents currently in the RFC Editor's Queue make allocations from the registries being restructured. RFC-ietf-mpls-gach-adv RFC-ietf-mpls-tp-ethernet-addressing IANA Note Please coordinate with the RFC Editor on the changes introduced by this document. Two documents currently in the RFC Editor's Queue make allocations from the registries being restructured. RFC-ietf-mpls-gach-adv RFC-ietf-mpls-tp-ethernet-addressing From touch@isi.edu Mon Jan 27 11:25:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A2E1A03C6; Mon, 27 Jan 2014 11:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 PKG8HIMZy2Wj; Mon, 27 Jan 2014 11:25:04 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 445B71A03AD; Mon, 27 Jan 2014 11:25:04 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0RJOYXQ011992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jan 2014 11:24:34 -0800 (PST) Message-ID: <52E6B272.4030703@isi.edu> Date: Mon, 27 Jan 2014 11:24:34 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Joel M. Halpern" , joel jaeggli , "stbryant@cisco.com" References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu> <52E6B128.8060306@joelhalpern.com> In-Reply-To: <52E6B128.8060306@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:25:07 -0000 On 1/27/2014 11:19 AM, Joel M. Halpern wrote: > Yes Joe, routers could ahve been built to do those calcualtions at that > performance scale. > There are however two major problems: > > 1) That is not how routers are built. > 2) The target performance scale is rather higher. > > So could someone build an ASIC to do what you want? Has. It's already part of nearly every DMA ASIC in a network interface already. > Probably. Is there > any reason in the world to expect operators to pay the significant extra > cost for such?Not that I can see. We're talking about a ring of full adders, the specs for which are given in an RFC that's 18 years old, and that is already implemented in nearly every host interface, including 10Gps NICs. And we're talking about "routers", many variants of which operate at very high speeds and transparently proxy TCP already. So this is a solved problem. > And even if we could and they would, that is not the world into which we > are deploying these tunnels. We're back to "that's not what they do now", at least in some devices. Well, they don't use MPLS in UDP (since no spec exists), so clearly if they're limited to doing what they already do, this is an exercise in futility. Joe > > Yours, > Joel > > On 1/27/14 1:53 PM, Joe Touch wrote: >> >> >> On 1/27/2014 10:48 AM, joel jaeggli wrote: >>> On 1/27/14, 8:48 AM, Joe Touch wrote: >>>> Those same mechanisms have provided hardware checksum support for a >>>> very long time. >>> >>> The new header and the payload are actually in different parts of the >>> forwarding complex until they hit the output queue, you can't checksum >>> data you don't have. >> >> You can (and some do) the checksum component parts when things go into >> memory; the partial sums can be added as the parts are combined in the >> output queue. >> >> I appreciate that we're all taking about what might be done, but the >> reality is that there are many 'transparent TCP proxies' that have to do >> this, so there's clearly a solution, and it clearly runs fast enough. >> >> Joe >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> From mark.tinka@seacom.mu Mon Jan 27 11:30:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619821A007C; Mon, 27 Jan 2014 11:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 yZ3l3WXINhEd; Mon, 27 Jan 2014 11:30:21 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-mba.ke.seacomnet.com [41.87.100.230]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC111A001E; Mon, 27 Jan 2014 11:30:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1W7rsc-0008LP-8h; Mon, 27 Jan 2014 21:29:58 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org, curtis@ipv6.occnc.com Date: Mon, 27 Jan 2014 21:29:54 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <201401252047.s0PKlmgS048899@maildrop2.v6ds.occnc.com> In-Reply-To: <201401252047.s0PKlmgS048899@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1477944.eXu6q19VvR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401272129.55230.mark.tinka@seacom.mu> Cc: Noel Chiappa , Greg Daley , IETF discussion list , Joe Touch Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:30:23 -0000 --nextPart1477944.eXu6q19VvR Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Saturday, January 25, 2014 10:47:48 PM Curtis Villamizar=20 wrote: > Reality check time. >=20 > To get the PW over MPLS drafts past the TSV AD there is a > SHOULD regarding congestion control. >=20 > AFAIK: No service providers ask for it. No one > implements it. If they did implement it no one would > deploy it. >=20 > PW over MPLS is generally carrying relatively low volumes > of high priority traffic. The TC bits (MPLS flavor of > Diffserv DSCP) are used to enforce the higher priority.=20 > If congestion occurs other traffic on that > infrastructure (typically plain old Internet) sees loss. > That is intended. This is the reality of how PW over > MPLS is deployed. >=20 > Anyone who knows of implementation or deployment of > congestion control for PW over MPLS can correct me. And this is what I mentioned several weeks ago. As=20 operators, we police traffic on ingress and egress (some=20 operators shape on egress, but the result is the same), and=20 this is how we control admission to the network. I have never used intrinsic congestion mechanisms in=20 protocols (outside of lab fun-time when I'm really bored),=20 and don't know anyone that has either. Of course, the risk=20 is that router/switch vendors have all sorts of=20 implementation as regards policing/shaping; but I can say=20 that in the past 7x years or so (and especially in the past=20 year for switches), this is reasonably mature, and no vendor=20 worth their salt is shipping product that can't police or=20 shape properly. Just one point to make, not all traffic being carried over=20 MPLS is "high priority". Some of it really isn't, and is=20 treated on a best-effort basis. But, this is all specific to=20 operators and their customers. General traffic admission=20 rules still apply all the same. Personally, if there was congestion mechanisms proposed as=20 part of the MPLS-in-UDP spec., I would never run them as an=20 operator. I'd rely on policing at the edge, as usual. Cheers, Mark. --nextPart1477944.eXu6q19VvR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS5rOzAAoJEGcZuYTeKm+GQfkP/2V/hyPrib+UGVANMxoYiXSh XHEzlRDf34NLcNZO8C3xqysiL7pb3HJR6a3HMPXwfHu0oDFoUwTQJ/PcSRWLyfrH MXiQIwsZMLczNo1472uVuybibevLVNCQf5wu3HMHVKSXLfb1ABLN11/VibINJiZO qKeEHu5YW048nZuaYekLDwHehye8whaM3ABdIvZ/mrEATbnIaOZ4ghEfs2lMl4Qb 1aD6DjLN1C/giozplbljqiyspk/T0oXeC9J/7M1u6m6u82cNeG3elrjKl013ABOy DlypgIW0dedK9mPzOkfURhhgN98/HIVpukWS07OOAdyA15f4uuRV5KkokKk+V4pY zvMtDI5S8aE85G5GLTrEGxSjGxAY6EgG3HjTbqrKrLlk2Ba/fZWMC04A65MgKiaO LMACgUl+Omab91UnSW74PPUGNV3LBEzrg2VVdTYLqyfprm6NvHSu/K+9rNWvDCKM FWH3kqFKIh76q2tC11jF1g8hof+9G6o2oLtINhLhGIL6PrxyxwU3WGZqCx1g1EbH MY6KX9u5/qNxbQoubmd5cxCb1/HrqT3ehOS3bEsVwwnW1YAzv+kRQ8Ri7sv26KCB u2bTbQTaX6pmy5Yd3ea/TbEkZjKrHP+TscdvVL+aAOsu35pF7+CFjo+JvCzoNOov p4ojTcfKlzo2d4KO0PVZ =JywG -----END PGP SIGNATURE----- --nextPart1477944.eXu6q19VvR-- From wyaacov@gmail.com Mon Jan 27 12:12:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD621A02B7 for ; Mon, 27 Jan 2014 12:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QoWcuy-Vsoi for ; Mon, 27 Jan 2014 12:12:03 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id B55B41A001E for ; Mon, 27 Jan 2014 12:12:02 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id n12so4652569wgh.0 for ; Mon, 27 Jan 2014 12:11:59 -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=XNzgzz/IVzQafAKcpWJMXdCFdqmaXv8882w4Lz60WyI=; b=duU/uQVv+1M0eWhIi21PSPD8NzopW8tVO/XapjEl3IqWH1gf3w7HTxN2ICvQDhvMyx HaxUuEN+ABPZrPTJuOHVHIDNHUcDSG/OE7ckS4qnZhPZTSs1gKmqHc3hjIWQpQZdoolA nuFhMJhtRBDxV83w7fKnDbtvCJhjmB+B2M4gGxrRrGEXyoW5yCU35Mqv0KuZNXRmKp/+ mxlLERoMPIhAURdh64xlm4j8jk1lPL0Hz6LtdIEvE3ylLmL7m4r0QeGgJos3On0H9vQz 5t5nVooclGWK6BJ+njH4JJlN1w0P+tMJtSvCvxjASm2XaCgcxQCW1MWW5hQf2rb9BA5X fsXg== MIME-Version: 1.0 X-Received: by 10.180.189.169 with SMTP id gj9mr72954wic.17.1390853519822; Mon, 27 Jan 2014 12:11:59 -0800 (PST) Received: by 10.194.152.202 with HTTP; Mon, 27 Jan 2014 12:11:59 -0800 (PST) In-Reply-To: <52DC89C3.3030003@pi.nu> References: <52DC89C3.3030003@pi.nu> Date: Mon, 27 Jan 2014 22:11:59 +0200 Message-ID: From: Yaacov Weingarten To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11c34a62fbd51304f0f9510e Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "" Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 20:12:07 -0000 --001a11c34a62fbd51304f0f9510e Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have read through the latest version of this draft and have a number of comments and questions regarding this document. While, in general, I feel that the extensions to the behavior of RFC6378 are appropriate, I find that this document is still in need of refinement in its language and clarity of the functionality. While some of the additional functionality is described, there are different cases of the functionality that is either not described or is rather confusing. One basic question is - Considering that this draft is proposing changes to the basic operation of the PSC protocol, Local Request Logic, and the PSC Control Logic, I would have thought that the PSC Version number should change! Why then, is there no mention of changing the version to allow networks that support the functionality described in RFC6378 to continue to operate? Regarding the functionality proposed in the draft, I have the following questions and comments - 1. (for clarification) Regarding the functionality of MS-W, what is the functionality if the data-traffic is currently on the working path? Since the purpose of the command is to move the traffic to the working path, shouldn't it be ignored? However, according to the State Transition Table in section 11.1 - if the MS-W is received by a LER in Normal State it transfers to Switching Administrative State! The main effect seems to be to cause the LER to ignore incoming MS and EXER requests (that are not ignored in Normal State). 2. Regarding the SD functionality - after a previous discussion on the mailing list the functionality when protecting for SD situations (described in Section 7.3) was changed to essentially switch over to the LER transmitting the packets on both the working and protection paths (essentially 1+1 transmission). However, there is very little discussion of how the receiving LER is supposed to select the incoming packets while avoiding duplication of data. Could please elaborate on this? 3. Regarding the SD functionality - as mentioned in the previous point, when protecting for SD, the transmitting LER duplicates the packets on both W & P and the receiving LER, presumably, reads the data from either path, and may choose differently for different packets. However, later in section 7.4 (and again in section 10.2) you introduce a new concept of "standby path" as "the path from which the selector does not select the user data traffic" in regard to determining the priority of "conflicting" SD-W and SD-P triggers. Can you clarify which of the two paths that are both carrying user data is the standby path? 4. Further regarding the point of "conflicting" SD triggers - since the protection functionality of SD is to duplicate the data on both W & P - why is this considered a conflict, since the action for both will be identical - continue transmitting on both W & P. Some more clarification would help. 5. Regarding the APS mode and sub-capabilities - You describe in section 9.1 how an LER can declare itself to support only some of the capabilities introduced in the draft, and then describe the APS "mode" (Section 9.2.2) as declaration of support for all of the capabilities, i.e. Flags = 0xF8000000. From this point on (in particular section 11), you describe the functionality for LER that declare Flags= either 0x0, or 0xF8000000, however, there is no explanation for paths that declare some other value of Flags (for example, 0x8000000 - supporting only the EXER functionality). Is there a reason for this? Are we assuming that all paths will either support PSC or APS modes only? If so, why not just have two values for Flags rather than this extensible bit map value? 6. Regarding "PSC sessions" - In section 9.3 you introduce a new concept of PSC session, without any definition of when this session begins or ends. Could you elaborate on what is meant by the "life of a PSC session"? Until now, I was under the impression that linear protection started with the creation of the protection domain and continued until the paths were torn down. Is this incorrect? 7. There is a statement in the second paragraph of section 9.3 that states "RFC6378 does not define how to handle an unrecognized TLV." Actually, what RFC6378 defines is "there are no TLV units defined for the basic PSC operation" and therefore the TLVs are ignored. Another reason, IMO, to change the version number of the protocol in this draft. 8. It is unclear to me - why when receiving a SD-P indication in Normal why you consider this to be "Unavaiable" since the action taken for an SD situation is to possibly transmit on both W & P. I plan on submitting some editorial comments in a future post, but would like to get some clarification on these points before the draft advances to acceptance. Thanx, yaacov On Mon, Jan 20, 2014 at 4:28 AM, Loa Andersson wrote: > Working Group, > > This is to start a two week working group last call on > draft-ietf-mpls-tp-psc-itu. > > Please find the document at: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ > > The document editors has also supplied a "diff-list" between > version -00 and -01 at: > http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html > > ITU-T SG15 has advised us that this document is a necessary reference > for documents that is planned to go into the ITU-T approval process > from the SG15 meeting end of March / beginning of April. Editors, > authors and chairs has put in quite an effort to make this document > ready. The schedule is very tight. > > We are now doing several review steps in parallel > > - the normal working group last call, please send your comments to the > mpls working group mailing list (mpls@ietf.org) > - the working group chairs reviewed this document as part of the > mpls-rt review, normally we do a wg chair review before starting the > wglc, this review will now take place in parallel > - after the wglc and publication request there is an AD evaluation, > this will now also take place in parallel with the wglc > > The editors and authors are advised to try to resolve as many of the > comments as possible (on the mailing list) as they come in, but not to > post the new version of the draft until the wglc is closed and the > comments are resolved. > > This working group last call ends February 3rd. > > /Loa > for the MPLS WG co-chairs > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Thanx and BR, yaacov *Still looking for new opportunity* --001a11c34a62fbd51304f0f9510e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I have read through the latest = version of this draft and have a number of comments and questions regarding= this document. While, in general, I feel that the extensions to the behavi= or of RFC6378 are appropriate, I find that this document is still in need o= f refinement in its language and clarity of the functionality. While some o= f the additional functionality is described, there are different cases of t= he functionality that is either not described or is rather confusing.

One basic question is - Considering that this draft is = proposing changes to the basic operation of the PSC protocol, Local Request= Logic, and the PSC Control Logic, I would have thought that the PSC Versio= n number should change! Why then, is there no mention of changing the versi= on to allow networks that support the functionality described in RFC6378 to= continue to operate?

Regarding the functionality proposed in the draft, I ha= ve the following questions and comments -
  1. (for clarificat= ion) Regarding the functionality of MS-W, what is the functionality if the = data-traffic is currently on the working path? Since the purpose of the com= mand is to move the traffic to the working path, shouldn't it be ignore= d? However, according to the State Transition Table in section 11.1 - if th= e MS-W is received by a LER in Normal State it transfers to Switching Admin= istrative State! The main effect seems to be to cause the LER to ignore inc= oming MS and EXER requests (that are not ignored in Normal State).
  2. Regarding the SD functionality - after a previous discussion on the mai= ling list the functionality when protecting for SD situations (described in= Section 7.3) was changed to essentially switch over to the LER transmittin= g the packets on both the working and protection paths (essentially 1+1 tra= nsmission). However, there is very little discussion of how the receiving L= ER is supposed to select the incoming packets while avoiding duplication of= data. Could please elaborate on this?
  3. Regarding the SD functionality - as mentioned in the previous point, wh= en protecting for SD, the transmitting LER duplicates the packets on both W= & P and the receiving LER, presumably, reads the data from either path= , and may choose differently for different packets. However, later in secti= on 7.4 (and again in section 10.2) you introduce a new concept of "sta= ndby path" as "the path from which the selector does not select t= he user data traffic" in regard to determining the priority of "c= onflicting" SD-W and SD-P triggers. Can you clarify which of the two p= aths that are both carrying user data is the standby path?
  4. Further regarding the point of "conflicting" SD triggers - si= nce the protection functionality of SD is to duplicate the data on both W &= amp; P - why is this considered a conflict, since the action for both will = be identical - continue transmitting on both W & P. Some more clarifica= tion would help.
  5. Regarding the APS mode and sub-capabilities - You describe in section 9= .1 how an LER can declare itself to support only some of the capabilities i= ntroduced in the draft, and then describe the APS "mode" (Section= 9.2.2) as declaration of support for all of the capabilities, i.e. Flags = =3D 0xF8000000. From this point on (in particular section 11), you describe= the functionality for LER that declare Flags=3D either 0x0, or 0xF8000000,= however, there is no explanation for paths that declare some other value o= f Flags (for example, 0x8000000 - supporting only the EXER functionality). = Is there a reason for this? Are we assuming that all paths will either supp= ort PSC or APS modes only? If so, why not just have two values for Flags ra= ther than this extensible bit map value?
  6. Regarding "PSC sessions" - In section 9.3 you introduce a new= concept of PSC session, without any definition of when this session begins= or ends. Could you elaborate on what is meant by the "life of a PSC s= ession"? Until now, I was under the impression that linear protection = started with the creation of the protection domain and continued until the = paths were torn down. Is this incorrect?
  7. There is a statement in the second paragraph of section 9.3 that states= "RFC6378 does not define how to handle an unrecognized TLV." Act= ually, what RFC6378 defines is "there are no TLV units defined for the= basic PSC operation" and therefore the TLVs are ignored. Another reas= on, IMO, to change the version number of the protocol in this draft.
  8. It is unclear to me - why when receiving a SD-P indication in Normal wh= y you consider this to be "Unavaiable" since the action taken for= an SD situation is to possibly transmit on both W & P.

I plan on submitting some editorial comments in a futu= re post, but would like to get some clarification on these points before th= e draft advances to acceptance.

Thanx,
yaacov


On Mon, Jan 20, 2014 at 4:28 AM, Loa Andersson <<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu> wrot= e:
Working Group,

This is to start a two week working group last call on
draft-ietf-mpls-tp-psc-itu.

Please find the document at:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-= psc-itu/

The document editors has also supplied a "diff-list" between
version -00 and -01 at:
http://www.ietf.org/mail-archive/web/mpls/current= /msg11338.html

ITU-T SG15 has advised us that this document is a necessary reference
for documents that is planned to go into the ITU-T approval process
from the SG15 meeting end of March / beginning of April. Editors,
authors and chairs has put in quite an effort to make this document
ready. The schedule is very tight.

We are now doing several review steps in parallel

- the normal working group last call, please send your comments to the
=A0 mpls working group mailing list (mpls@ietf.org)
- the working group chairs reviewed this document as part of the
=A0 mpls-rt review, normally we do a wg chair review before starting the =A0 wglc, this review will now take place in parallel
- after the wglc and publication request there is an AD evaluation,
=A0 this will now also take place in parallel with the wglc

The editors and authors are advised to try to resolve as many of the
comments as possible (on the mailing list) as they come in, but not to
post the new version of the draft until the wglc is closed and the
comments are resolved.

This working group last call ends February 3rd.

/Loa
for the MPLS WG co-chairs --


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
Thanx and BR,
yaacov

Sti= ll looking for new opportunity
--001a11c34a62fbd51304f0f9510e-- From iesg-secretary@ietf.org Mon Jan 27 13:50:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B0C1A035C; Mon, 27 Jan 2014 13:50:11 -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 Zmew0xD0rdkF; Mon, 27 Jan 2014 13:50:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F2B1A0368; Mon, 27 Jan 2014 13:50:07 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127215007.17546.5421.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 13:50:07 -0800 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Document Action: 'A Framework for Point-to-Multipoint MPLS in Transport Networks' to Informational RFC (draft-ietf-mpls-tp-p2mp-framework-06.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 21:50:11 -0000 The IESG has approved the following document: - 'A Framework for Point-to-Multipoint MPLS in Transport Networks' (draft-ietf-mpls-tp-p2mp-framework-06.txt) as Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-p2mp-framework/ Technical Summary MPLS-TP is the common set of MPLS protocol functions defined to enable establishment and operation of packet transport networks transport LSPs. MPLS-TP supports both point-to-point and point-to-multipoint transport paths (LSPs). This document defines the elements and functions of the MPLS architecture applicable specifically to the support point-to- multipoint transport paths. Working Group Summary No concerns. Document Quality This document is an Informational framework, and as such we will see no direct implementations of the document, though we are aware of intentions to implement protocols for establishing P2MP MPLS-TP LSPs. Personnel Loa Andersson is the Document Shepherd. Adrian Farrel is the Responsible Area Director. From vlim@cisco.com Mon Jan 27 14:13:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A971A0093 for ; Mon, 27 Jan 2014 14:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 d8u60FSH4Hli for ; Mon, 27 Jan 2014 14:13:01 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8D50D1A0068 for ; Mon, 27 Jan 2014 14:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1023; q=dns/txt; s=iport; t=1390860779; x=1392070379; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=37c0t6SE2Yax7RkDYlGHZFvZ59KMPfpuoOlde1LBgFo=; b=hwP6ZxoVNPpVm6VAbYek3tar9xuMLjPqptWOawNyjI/nE3rUyEStDVM+ oNY+4NGun+BmLeeGubIYwLppm2LLMUpHiP7cDRnRRCTqVxh0lEZjqEsmV UNuf7wcpkrk+aOsPADkSfZkihor5L7O3StkG7+O6SEw5liWVdHFUEa5nB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAITZ5lKtJV2a/2dsb2JhbABagwy9aoEdFnSCJQEBAQQ4NgoBEAsYCRYPCQMCAQIBRQYBDAEFAgEBiAHHExeOKxEBUAeEOAEDiUiOX4ZHi1eDSx6BNQ X-IronPort-AV: E=Sophos;i="4.95,731,1384300800"; d="scan'208";a="300019109" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jan 2014 22:12:59 +0000 Received: from [10.98.73.149] (bxb-vlim-8814.cisco.com [10.98.73.149]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0RMCwjX032165; Mon, 27 Jan 2014 22:12:58 GMT Message-ID: <52E6D9EA.9000409@cisco.com> Date: Mon, 27 Jan 2014 17:12:58 -0500 From: Vanson Lim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Loa Andersson , "mpls@ietf.org" References: <52C795FE.7060801@pi.nu> <52DE32F0.3050005@pi.nu> In-Reply-To: <52DE32F0.3050005@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org Subject: Re: [mpls] Closed: Working group last call on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 22:13:03 -0000 Loa, Just wanted to acknowledge the receipt of this email. Sam/George and I will meet this week to work on addressing comments. -Vanson On 1/21/14, 3:42 AM, Loa Andersson wrote: > Working Group, > > This working group last call is closed. There has been comments, > could the authors please address the comments and re-post a new > version of the document as necessary. Please make sure that the > reviewers are comfortable with how the comments are resolved. > > /Loa > mpls wg co-chair > > On 2014-01-04 13:02, Loa Andersson wrote: >> Working Group, >> >> this is to start a two week working group last call on >> draft-ietf-mpls-proxy-lsp-ping-01.txt >> >> Please send your comments to working group mailing lists >> (mpls@ietf.org). >> >> We will do an IPR poll on this document in parallel thee wglc. >> >> There are three IPRs disclosures that relates to this document. >> >> The working group last call will end Friday January 20, 2914. >> >> /Loa >> mpls wg co-chair >> > From gdaley@au.logicalis.com Mon Jan 27 14:18:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AA91A0366; Mon, 27 Jan 2014 14:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.535, 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 9C45GdneVQvu; Mon, 27 Jan 2014 14:18:14 -0800 (PST) Received: from smtp2.au.logicalis.com (smtp2.au.logicalis.com [203.8.7.133]) by ietfa.amsl.com (Postfix) with ESMTP id 77AFB1A0093; Mon, 27 Jan 2014 14:18:13 -0800 (PST) Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp2.au.logicalis.com with ESMTP; 28 Jan 2014 09:18:10 +1100 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0347.000; Tue, 28 Jan 2014 09:18:09 +1100 From: Greg Daley To: "'curtis@ipv6.occnc.com'" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGg60ZzPPQlRcgk6ua2U45NfiYJqZJKag Date: Mon, 27 Jan 2014 22:18:08 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D992817FD63D0@sdcexchms.au.logicalis.com> References: Your message of "Fri, 24 Jan 2014 03:38:44 +0000." <72381AF1F18BAE4F890A0813768D992817FD35E1@sdcexchms.au.logicalis.com> <201401252047.s0PKlmgS048899@maildrop2.v6ds.occnc.com> In-Reply-To: <201401252047.s0PKlmgS048899@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , IETF discussion list , Joe Touch , Noel Chiappa Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 22:18:17 -0000 Hi Curtis,=20 > -----Original Message----- [my post chopped] >=20 >=20 > Reality check time. >=20 > To get the PW over MPLS drafts past the TSV AD there is a SHOULD regardin= g > congestion control. >=20 > AFAIK: No service providers ask for it. No one implements it. If they d= id > implement it no one would deploy it. >=20 > PW over MPLS is generally carrying relatively low volumes of high priorit= y > traffic. The TC bits (MPLS flavor of Diffserv DSCP) are used to enforce = the > higher priority. If congestion occurs other traffic on that infrastructu= re > (typically plain old Internet) sees loss. That is intended. This is the= reality of > how PW over MPLS is deployed. >=20 > Anyone who knows of implementation or deployment of congestion control fo= r > PW over MPLS can correct me. >=20 > I don't know about the "over GRE" or "over L2TP" tunneling. Essentially, my point is that with traditional carriage environments there = is an underlying medium which it may be possible to traffic engineer. The value of a SHOULD is that it isn't necessary to there is a valid reason= not to follow it (i.e. you control the medium and/or the ingress traffic f= lows and the traffic remains private). The onus remains on the implementer= and deployer not to mess up the Internet. I think that similar guidance may be applicable in this case (as in GRE and= L2TP encapsulations), where the next label switch could be across paths sh= ared with other Internet traffic that has congestion avoidance, mitigation = or control. Sincerely,=20 Greg Daley From adrian@olddog.co.uk Mon Jan 27 15:04:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E40B1A03E9 for ; Mon, 27 Jan 2014 15:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 nr7Ct9tGpJaD for ; Mon, 27 Jan 2014 15:04:16 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id A2F4F1A03DE for ; Mon, 27 Jan 2014 15:04:15 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0RN4BNS020492; Mon, 27 Jan 2014 23:04:12 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0RN48Qc020472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jan 2014 23:04:10 GMT From: "Adrian Farrel" To: References: Your message of "Sun, 26 Jan 2014 18:02:08 +0000." <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk> <201401270458.s0R4woWw074790@maildrop2.v6ds.occnc.com> In-Reply-To: <201401270458.s0R4woWw074790@maildrop2.v6ds.occnc.com> Date: Mon, 27 Jan 2014 23:04:06 -0000 Message-ID: <022d01cf1bb4$1624fde0$426ef9a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF2A4GEka3MiGnMKW0OtjuBIpWsOZtLWGfA Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 23:04:19 -0000 Hello Curtis, These replies modulo the conversation with Carlos. I find I can't read that conversation and back apply the results here :-( [snip] > > Your acronym list is commendably thorough, but a little enthusiastic. > > If I provide a section with a list of acronyms, do I still have to > expand on first use. If so, AC, NSP, OAM, and a few others appear > before that section. Afraid so :-( > Given that this takes up only 17 lines in a 50 page document I'd > rather be thorough. Yup. OK. Go for it. [snip] > > I think Curtis may have heard this before :-) > > The "preferred" (by the RFC editor) expansion of ECMP is > > "Equal-Cost Multipath" > > The form without the hyphen is more common, even among recent > documents. I prefer to keep it without the hyphen. A discussion for a rainy day with the RFC Editor. Leave as is. > > Section 1.3 bullet 5 > > > > 5. The implementer and system designer MUST support pseudowire > > control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is > > being used on a pseudowire. > > > > The wording is a bit odd. "The implementation and system design..."? > > > > Ditto bullets 6 and 7 > > Target audience is explained in Section 1.4. If you like I can flip > Section 1.3 and 1.4 so target audience is first, then use of the roles > called for in the target audience section won't seem quite so odd. No issue with the section order. Just puzzled by "the implementer MUST support" when I (pedantically) thought that the implementer supporting something might not be the same as the implementation supporting it. Not a big deal. > > Section 1.3 > > > > While there is not wrong with the statements made in the bullets, some > > of the later ones refer to recent additions to the MPLS suite. Yet the > > list is presented as "there were some misconceptions." Clearly the > > early silicon did not have misconceptions about the inclusion of entropy > > labels. > > > > Just tweak the words at the top of the list? > > I'd like to keep that as is and split into two lists. The second list > would have the last two items (fat-pw and EL). The first list would > end with "implement CW" (sic). > > OLD > > 6. The implementer and system designer SHOULD support adding a > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > feature for appropriate pseudowire types. See Section 2.4.3. > > 7. The implementer and system designer SHOULD support adding an MPLS > entropy label [RFC6790]. Deployments MAY enable this feature. > See Section 2.4.4. > > NEW > > The following statements provide clarification regarding more > recent requirements that are often missed. > > 1. The implementer and system designer SHOULD support adding a > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > feature for appropriate pseudowire types. See Section 2.4.3. > > 2. The implementer and system designer SHOULD support adding an MPLS > entropy label [RFC6790]. Deployments MAY enable this feature. > See Section 2.4.4. > > I've made this change. Let me know if this is not OK. That's fine. > > 2.1.1 > > > > Maybe the first paragraph should clarify "special purpose labels at > > the top of the label stack" > > That phrase doesn't appear anywhere in the document. Exactly what am > I clarifying? What to do with unknown special purpose labels is in > the last paragraph of this subsection. WTF? You have to wonder where these senile ADs get their ideas. Complete brain fart. Sorry. [snip] > > While per platform label space is mentioned in 2.1.7 I wonder whether > > more information on per platform and per interface label spaces is > > needed. I recall early implementations that got very confused when > > parallel interfaces used the same label for different purposes. > > > > I guess the point there is that you cannot assume that your neighbor > > is or is not using the per platform label space. > > > > Upstream label allocation may also come into this. > > The only mention of label allocation is that MPLS FRR bypass method > (more formally known as facilitles backup) uses platform label space. > > The only reason platform label space is of any significance in a > document about forwarding is "The use of platform label space impacts > the size of the LSR ILM for LSR with a very large number of > interfaces." > > Label allocation, per platform or per interface and upstream or > downstream, is not a forwarding issue. It is a software issue > and a matter of getting the protocol bits right. Therefore I think > expanding any further on label allocation should be out of scope. OK. I'm convinced. > > 2.1.8.1 > > > > 3. If the edge is not using pseudowire control word (CW) and the > > core is using multipath, reordering will be far more common. If > > this is occurring, the best solution is to use CW on the edge, > > rather than try to fix the reordering using resequencing. > > > > Completely agree, but isn't the sequence number contained in a control > > word meaning that the resequencing could, in any case, not be done > > without using a control word? > > I suppose you can't fix reordering caused by not using CW without the > sequence number in the CW. That is going to require fixing the text. > > OLD > > 3. If the edge is not using pseudowire control word (CW) and the > core is using multipath, reordering will be far more common. > If this is occurring, the best solution is to use CW on the > edge, rather than try to fix the reordering using resequencing. > > NEW > > 3. If the edge is not using pseudowire control word (CW) and the > core is using multipath, reordering will be far more common. > If this is occurring, using CW on the edge will solve the > problem. Without CW, resequencing is not possible since the > sequence number is contained in the CW. > > That was a big oops on our part. Well, on the scale of IETF oopsies, I don't think you score too high. Maybe Narten could run a weekly script? [snip] > > Should 2.2 distinguish the order of magnitude of replication at branch > > nodes? This impacts the replication method used (some devices make a > > copy and cycle around, some devices can do multiple copies at once). On > > the whole is no different from IP multicast processing except (as you > > note) that each outgoing packet may be different by its label value. > > Is it possible to quantify the fanout? YMMV? > > The only thing I could say is that an implementation may need to make > lots of copies in some roles (access routers for example). > > Making a copy and cycling yields poor performance but for low > multicast traffic volumes might be OK. But you are right - some > mostly low-end-ish chips to this. > > I'm not sure I can describe how multicast with high fanout is done > without wading into implementation details of specific vendors. > > Perhaps the best I can do is add this: > > Careful consideration should be given to the performance > characteristics of high fanout multicast for equipment that is > intended to be used in such a role. > > I'll add this before the last paragraph in the section. That works. > > 2.4 > > > > So obvious you didn't say it? > > > > In order to support an adequately balanced load distribution across > > multiple links, IP header information must be used. Common practice > > today is to reinspect the IP headers at each LSR and use the label > > stack and IP header information in a hash performed at each LSR. > > Further details are provided in Section 2.4.5. > > > > Missing is the statement that a single "flow" must not be distributed > > across multiple paths because of the implication for potentially > > significant packet misordering. And feeding that is a common requirement > > that such packet misordering must not occur because applications and > > transport protocol implementations cannot survive such misordering. > > Yes. That requirement was missed. Add new second paragraph to this > subsection. > > The Differentiated Services requirements for good reasons dictate > that packets within a common microflow SHOULD NOT be reordered > [RFC2474]. Service providers generally impose stronger > requirements, commonly requiring that packets within a microflow > MUST NOT be reordered except in rare circumstances such as load > balancing across multiple links or path change for load balancing > or path change for other reason. > > Another SP requirement is stated here and I'm quite sure this > requirement is well accepted. Looks good. > > 2.4.2 uses "composite link" and "component link". I suggest picking just > > one term. > > They are two different things. Two or more component links make up a > composite link. Knowing that, give it another read please. > > I'd rather not cite draft-ietf-rtgwg-cl-requirements as an > informational reference just for this one term. In favor of citing > it, draft-ietf-rtgwg-cl-requirements is moving along. Against citing > it is there is far less than a ground swell of providers calling for > the full set of things asked for in draft-ietf-rtgwg-cl-requirements. Yes. Sorry. It has been a looooooooong time since I had a pass on the CL document. Atrophy. > > 2.4.5.1 notes that special purpose and extended special purpose labels > > need to be excluded from the hash. Good. > > But it seems that some special purpose labels will indicate that the > > next label stack entry contains a label with special meaning. (ELI is > > an example that we specifically don't have to worry about.) > > How do we handle that? > > Should we be dividing up the extended special purpose label space to > > have one set of code points meaning "just this label is special" and > > another set meaning "this label is special and the next label stack > > entry is magic"? > > I did list ELI (bullet 2) before the more general rule of not useing > special purpose labels. The ELI is not used, just the EL, so the text > could be considered correct as-is. > > So far the only special purpose label that is not just ignored and > skipped over is ELI. > > Regarding this being magic -- All of this is somewhat programable > specialized silicon magic. The silicon generally has some form of > very fast, very light weight parsing engine at the front of the > pipeline. One thing it does is pick out fields for load balance. > > The better silicon hashes as it goes rather that pick out a set of > fields and then hashes that set of fields when its done. When it sees > 13 it skips and hashes the next thing and stops hashing completely. > If it sees 0-12,14 it skips and continues. If it sees 15 it skips two > labels and continues. Its should be programable enough that if > someone defines a new ELI like label it is likely to be able to deal > with it. > > The not so good silicon has this all so hard wired that it won't be > able to do ELI without at least a respin. > > At most I could add "If a new special purpose label or extended > special purpose label is defined which requires special load balance > processing then, as is the case for the ELI label, a spacial action > may be needed rather than skipping the special purpose label or > extended special purpose label." I really don't think this is needed. You're right, and my worry is more about the special-purpose draft and the consequences of possibly adding other special purpose labels that have child labels associated. We certainly don't want to have to retrain the silicon at transit LSRs to specially know what to do for each new special-purpose label. Currently we propose that you don't hash on a special purpose label, but you can carry on hashing immediately after. If I introduce the foo-label, your silicon will recognise it as special purpose, but it I say the label after the foo-label is magic you won't know that. A way to fix this is to have (just punting here) the top bit of the extended special purpose label range set mean "magic label follows". > > An issue that arises from the multipath support (2.4.5.1) is that > > hardware assumes that after a label stack entry with the S-bit set, > > there are only three possible next bytes... > > - a control word (indicated by b0000 or b0001) > > - an IPv4 header > > - an IPv6 header > > This is the case regardless of how the LSP was set up, and the next > > bytes cannot ever be further MPLS stack entries. > > Right. Note that in (5) is says that some SP will require IP headers > and some will require an ability to disable IP headers. > > The rule is really look for 4, 6, or anything else in the first > nibble. If 4 or 6 assume IP. If anything else stop. > > And yes if the payload is MPLS after a S-bit you have a screwed up > MPLS implementation to start with and you won't get load balance on > any set of MPLS labels after the first S-bit. This is a fact of life > in the field and is as it should be. > > > While this comes up 2.4.5.1 it may merit further discussion in an > > earlier section of the document. > > This text is part of 2.4. ("MPLS Multipath Techniques"). The third > paragraph contains "Further details are provided in Section 2.4.5." > Section 2.4.5. is "Fields Used for Multipath Load Balance". > > > I note that discussion of support of PWs without the CW drives you > > to say that hashing beyond the S-bit should be a configurable option > > which would (of course) support any payload including MPLS in MPLS > > with repeated bottom of stack. However, you might want to specifically > > preclude that. > > It says the same thing here in bullet 5 regarding being configurable. > The wording "ability to disable" is same as "configurable option". > > At no point in this document do we imply that looking beyond the S-bit > means looking at anything beyond the S-bit other than looking for IP. > This is very clear in [RFC4385] and [RFC4928] which is cited in the > text about PW CW. > > All it says in the places discusing PW is that without CW the traffic > might get reordered. > > If you feel that we at any point imply that lack of PW CW allows > looking at anything past the S-bit rather than just looking for an IP > header please point to where and we will have to correct that. I > looked at all occurances of CW and did not find anything. > > Bullet 5 is very clear that a 4 or 6 has to be found in the first > nibble of payload. OK. I misread bullet 5. [snip] Thanks. Adrian From curtis@ipv6.occnc.com Mon Jan 27 15:05:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829D11A03F7 for ; Mon, 27 Jan 2014 15:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 84ulf4lqSWlh for ; Mon, 27 Jan 2014 15:05:41 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id B65941A03ED for ; Mon, 27 Jan 2014 15:05:41 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0RN5Zxx095713; Mon, 27 Jan 2014 18:05:35 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401272305.s0RN5Zxx095713@maildrop2.v6ds.occnc.com> To: Loa Andersson From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 18:37:54 +0800." <52E63702.20102@pi.nu> Date: Mon, 27 Jan 2014 18:05:35 -0500 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-psc-updates@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-psc-updates-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 23:05:43 -0000 In message <52E63702.20102@pi.nu> Loa Andersson writes: > Working Group, > > This is to initiate a working group last call on > draft-ietf-mpls-psc-updates. > > One reason for the timing, other than that the author thinks is ready > for wglc, is that this document is normatively referenced in > draft-ietf-mpls-tp-psc-itu which also is in wglc. > > There are no IPR disclosures against this document. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > This working group last call ends Feb 19´0, 2014. > > /Loa > for the MPLS wg chairs The title needs to spell out PSC since there are three interpretations of the acronym in IETF, the other two predating this one by many years. Otherwise looks good. Curtis From l.wood@surrey.ac.uk Mon Jan 27 15:09:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342BA1A03F5 for ; Mon, 27 Jan 2014 15:09:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 pI2084_4Ms5C for ; Mon, 27 Jan 2014 15:09:06 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) by ietfa.amsl.com (Postfix) with ESMTP id 033291A03E9 for ; Mon, 27 Jan 2014 15:09:05 -0800 (PST) Received: from [85.158.136.51:27597] by server-6.bemta-5.messagelabs.com id 77/D0-16310-F07E6E25; Mon, 27 Jan 2014 23:09:03 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-10.tower-49.messagelabs.com!1390864142!25118999!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29713 invoked from network); 27 Jan 2014 23:09:02 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-10.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 27 Jan 2014 23:09:02 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Mon, 27 Jan 2014 23:09:01 +0000 From: To: , Date: Mon, 27 Jan 2014 23:07:17 +0000 Thread-Topic: [mpls] AD review of draft-ietf-mpls-forwarding Thread-Index: AQF2A4GEka3MiGnMKW0OtjuBIpWsOZtLWGfAgAAJoUI= Message-ID: <290E20B455C66743BE178C5C84F1240847E63346F5@EXMB01CMS.surrey.ac.uk> References: Your message of "Sun, 26 Jan 2014 18:02:08 +0000." <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk> <201401270458.s0R4woWw074790@maildrop2.v6ds.occnc.com>, <022d01cf1bb4$1624fde0$426ef9a0$@olddog.co.uk> In-Reply-To: <022d01cf1bb4$1624fde0$426ef9a0$@olddog.co.uk> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 23:09:11 -0000 >> > I think Curtis may have heard this before :-) >> > The "preferred" (by the RFC editor) expansion of ECMP is >> > "Equal-Cost Multipath" >> >> The form without the hyphen is more common, even among recent >> documents. I prefer to keep it without the hyphen. >> A discussion for a rainy day with the RFC Editor. >> Leave as is. Basic English grammar. Hyphenate related adjectives. http://www.grammar-monster.com/lessons/hyphens_in_compound_adjectives.htm Lloyd Wood http://about.me/lloydwood ________________________________________ From: mpls [mpls-bounces@ietf.org] On Behalf Of Adrian Farrel [adrian@olddo= g.co.uk] Sent: 27 January 2014 23:04 To: curtis@ipv6.occnc.com Cc: mpls@ietf.org; draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding Hello Curtis, These replies modulo the conversation with Carlos. I find I can't read that conversation and back apply the results here :-( [snip] > > Your acronym list is commendably thorough, but a little enthusiastic. > > If I provide a section with a list of acronyms, do I still have to > expand on first use. If so, AC, NSP, OAM, and a few others appear > before that section. Afraid so :-( > Given that this takes up only 17 lines in a 50 page document I'd > rather be thorough. Yup. OK. Go for it. [snip] > > I think Curtis may have heard this before :-) > > The "preferred" (by the RFC editor) expansion of ECMP is > > "Equal-Cost Multipath" > > The form without the hyphen is more common, even among recent > documents. I prefer to keep it without the hyphen. A discussion for a rainy day with the RFC Editor. Leave as is. > > Section 1.3 bullet 5 > > > > 5. The implementer and system designer MUST support pseudowire > > control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is > > being used on a pseudowire. > > > > The wording is a bit odd. "The implementation and system design..."? > > > > Ditto bullets 6 and 7 > > Target audience is explained in Section 1.4. If you like I can flip > Section 1.3 and 1.4 so target audience is first, then use of the roles > called for in the target audience section won't seem quite so odd. No issue with the section order. Just puzzled by "the implementer MUST support" when I (pedantically) though= t that the implementer supporting something might not be the same as the implementation supporting it. Not a big deal. > > Section 1.3 > > > > While there is not wrong with the statements made in the bullets, some > > of the later ones refer to recent additions to the MPLS suite. Yet the > > list is presented as "there were some misconceptions." Clearly the > > early silicon did not have misconceptions about the inclusion of entrop= y > > labels. > > > > Just tweak the words at the top of the list? > > I'd like to keep that as is and split into two lists. The second list > would have the last two items (fat-pw and EL). The first list would > end with "implement CW" (sic). > > OLD > > 6. The implementer and system designer SHOULD support adding a > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > feature for appropriate pseudowire types. See Section 2.4.3. > > 7. The implementer and system designer SHOULD support adding an MPLS > entropy label [RFC6790]. Deployments MAY enable this feature. > See Section 2.4.4. > > NEW > > The following statements provide clarification regarding more > recent requirements that are often missed. > > 1. The implementer and system designer SHOULD support adding a > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > feature for appropriate pseudowire types. See Section 2.4.3. > > 2. The implementer and system designer SHOULD support adding an MPLS > entropy label [RFC6790]. Deployments MAY enable this feature. > See Section 2.4.4. > > I've made this change. Let me know if this is not OK. That's fine. > > 2.1.1 > > > > Maybe the first paragraph should clarify "special purpose labels at > > the top of the label stack" > > That phrase doesn't appear anywhere in the document. Exactly what am > I clarifying? What to do with unknown special purpose labels is in > the last paragraph of this subsection. WTF? You have to wonder where these senile ADs get their ideas. Complete brain fart. Sorry. [snip] > > While per platform label space is mentioned in 2.1.7 I wonder whether > > more information on per platform and per interface label spaces is > > needed. I recall early implementations that got very confused when > > parallel interfaces used the same label for different purposes. > > > > I guess the point there is that you cannot assume that your neighbor > > is or is not using the per platform label space. > > > > Upstream label allocation may also come into this. > > The only mention of label allocation is that MPLS FRR bypass method > (more formally known as facilitles backup) uses platform label space. > > The only reason platform label space is of any significance in a > document about forwarding is "The use of platform label space impacts > the size of the LSR ILM for LSR with a very large number of > interfaces." > > Label allocation, per platform or per interface and upstream or > downstream, is not a forwarding issue. It is a software issue > and a matter of getting the protocol bits right. Therefore I think > expanding any further on label allocation should be out of scope. OK. I'm convinced. > > 2.1.8.1 > > > > 3. If the edge is not using pseudowire control word (CW) and the > > core is using multipath, reordering will be far more common. If > > this is occurring, the best solution is to use CW on the edge, > > rather than try to fix the reordering using resequencing. > > > > Completely agree, but isn't the sequence number contained in a control > > word meaning that the resequencing could, in any case, not be done > > without using a control word? > > I suppose you can't fix reordering caused by not using CW without the > sequence number in the CW. That is going to require fixing the text. > > OLD > > 3. If the edge is not using pseudowire control word (CW) and the > core is using multipath, reordering will be far more common. > If this is occurring, the best solution is to use CW on the > edge, rather than try to fix the reordering using resequencing. > > NEW > > 3. If the edge is not using pseudowire control word (CW) and the > core is using multipath, reordering will be far more common. > If this is occurring, using CW on the edge will solve the > problem. Without CW, resequencing is not possible since the > sequence number is contained in the CW. > > That was a big oops on our part. Well, on the scale of IETF oopsies, I don't think you score too high. Maybe Narten could run a weekly script? [snip] > > Should 2.2 distinguish the order of magnitude of replication at branch > > nodes? This impacts the replication method used (some devices make a > > copy and cycle around, some devices can do multiple copies at once). On > > the whole is no different from IP multicast processing except (as you > > note) that each outgoing packet may be different by its label value. > > Is it possible to quantify the fanout? YMMV? > > The only thing I could say is that an implementation may need to make > lots of copies in some roles (access routers for example). > > Making a copy and cycling yields poor performance but for low > multicast traffic volumes might be OK. But you are right - some > mostly low-end-ish chips to this. > > I'm not sure I can describe how multicast with high fanout is done > without wading into implementation details of specific vendors. > > Perhaps the best I can do is add this: > > Careful consideration should be given to the performance > characteristics of high fanout multicast for equipment that is > intended to be used in such a role. > > I'll add this before the last paragraph in the section. That works. > > 2.4 > > > > So obvious you didn't say it? > > > > In order to support an adequately balanced load distribution across > > multiple links, IP header information must be used. Common practice > > today is to reinspect the IP headers at each LSR and use the label > > stack and IP header information in a hash performed at each LSR. > > Further details are provided in Section 2.4.5. > > > > Missing is the statement that a single "flow" must not be distributed > > across multiple paths because of the implication for potentially > > significant packet misordering. And feeding that is a common requiremen= t > > that such packet misordering must not occur because applications and > > transport protocol implementations cannot survive such misordering. > > Yes. That requirement was missed. Add new second paragraph to this > subsection. > > The Differentiated Services requirements for good reasons dictate > that packets within a common microflow SHOULD NOT be reordered > [RFC2474]. Service providers generally impose stronger > requirements, commonly requiring that packets within a microflow > MUST NOT be reordered except in rare circumstances such as load > balancing across multiple links or path change for load balancing > or path change for other reason. > > Another SP requirement is stated here and I'm quite sure this > requirement is well accepted. Looks good. > > 2.4.2 uses "composite link" and "component link". I suggest picking jus= t > > one term. > > They are two different things. Two or more component links make up a > composite link. Knowing that, give it another read please. > > I'd rather not cite draft-ietf-rtgwg-cl-requirements as an > informational reference just for this one term. In favor of citing > it, draft-ietf-rtgwg-cl-requirements is moving along. Against citing > it is there is far less than a ground swell of providers calling for > the full set of things asked for in draft-ietf-rtgwg-cl-requirements. Yes. Sorry. It has been a looooooooong time since I had a pass on the CL document. Atrophy. > > 2.4.5.1 notes that special purpose and extended special purpose labels > > need to be excluded from the hash. Good. > > But it seems that some special purpose labels will indicate that the > > next label stack entry contains a label with special meaning. (ELI is > > an example that we specifically don't have to worry about.) > > How do we handle that? > > Should we be dividing up the extended special purpose label space to > > have one set of code points meaning "just this label is special" and > > another set meaning "this label is special and the next label stack > > entry is magic"? > > I did list ELI (bullet 2) before the more general rule of not useing > special purpose labels. The ELI is not used, just the EL, so the text > could be considered correct as-is. > > So far the only special purpose label that is not just ignored and > skipped over is ELI. > > Regarding this being magic -- All of this is somewhat programable > specialized silicon magic. The silicon generally has some form of > very fast, very light weight parsing engine at the front of the > pipeline. One thing it does is pick out fields for load balance. > > The better silicon hashes as it goes rather that pick out a set of > fields and then hashes that set of fields when its done. When it sees > 13 it skips and hashes the next thing and stops hashing completely. > If it sees 0-12,14 it skips and continues. If it sees 15 it skips two > labels and continues. Its should be programable enough that if > someone defines a new ELI like label it is likely to be able to deal > with it. > > The not so good silicon has this all so hard wired that it won't be > able to do ELI without at least a respin. > > At most I could add "If a new special purpose label or extended > special purpose label is defined which requires special load balance > processing then, as is the case for the ELI label, a spacial action > may be needed rather than skipping the special purpose label or > extended special purpose label." I really don't think this is needed. You're right, and my worry is more about the special-purpose draft and the consequences of possibly adding other special purpose labels that have chil= d labels associated. We certainly don't want to have to retrain the silicon a= t transit LSRs to specially know what to do for each new special-purpose labe= l. Currently we propose that you don't hash on a special purpose label, but yo= u can carry on hashing immediately after. If I introduce the foo-label, your silicon will recognise it as special pur= pose, but it I say the label after the foo-label is magic you won't know that. A way to fix this is to have (just punting here) the top bit of the extende= d special purpose label range set mean "magic label follows". > > An issue that arises from the multipath support (2.4.5.1) is that > > hardware assumes that after a label stack entry with the S-bit set, > > there are only three possible next bytes... > > - a control word (indicated by b0000 or b0001) > > - an IPv4 header > > - an IPv6 header > > This is the case regardless of how the LSP was set up, and the next > > bytes cannot ever be further MPLS stack entries. > > Right. Note that in (5) is says that some SP will require IP headers > and some will require an ability to disable IP headers. > > The rule is really look for 4, 6, or anything else in the first > nibble. If 4 or 6 assume IP. If anything else stop. > > And yes if the payload is MPLS after a S-bit you have a screwed up > MPLS implementation to start with and you won't get load balance on > any set of MPLS labels after the first S-bit. This is a fact of life > in the field and is as it should be. > > > While this comes up 2.4.5.1 it may merit further discussion in an > > earlier section of the document. > > This text is part of 2.4. ("MPLS Multipath Techniques"). The third > paragraph contains "Further details are provided in Section 2.4.5." > Section 2.4.5. is "Fields Used for Multipath Load Balance". > > > I note that discussion of support of PWs without the CW drives you > > to say that hashing beyond the S-bit should be a configurable option > > which would (of course) support any payload including MPLS in MPLS > > with repeated bottom of stack. However, you might want to specifically > > preclude that. > > It says the same thing here in bullet 5 regarding being configurable. > The wording "ability to disable" is same as "configurable option". > > At no point in this document do we imply that looking beyond the S-bit > means looking at anything beyond the S-bit other than looking for IP. > This is very clear in [RFC4385] and [RFC4928] which is cited in the > text about PW CW. > > All it says in the places discusing PW is that without CW the traffic > might get reordered. > > If you feel that we at any point imply that lack of PW CW allows > looking at anything past the S-bit rather than just looking for an IP > header please point to where and we will have to correct that. I > looked at all occurances of CW and did not find anything. > > Bullet 5 is very clear that a 4 or 6 has to be found in the first > nibble of payload. OK. I misread bullet 5. [snip] Thanks. Adrian _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From l.wood@surrey.ac.uk Mon Jan 27 15:18:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A842B1A03F5; Mon, 27 Jan 2014 15:18:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 HRYjlQSwBXdA; Mon, 27 Jan 2014 15:18:23 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.138]) by ietfa.amsl.com (Postfix) with ESMTP id 440351A03F4; Mon, 27 Jan 2014 15:18:23 -0800 (PST) Received: from [195.245.231.67:50896] by server-2.bemta-5.messagelabs.com id F8/1A-29392-C39E6E25; Mon, 27 Jan 2014 23:18:20 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-82.messagelabs.com!1390864700!16172229!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27996 invoked from network); 27 Jan 2014 23:18:20 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-15.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 27 Jan 2014 23:18:20 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Mon, 27 Jan 2014 23:18:19 +0000 From: To: , Date: Mon, 27 Jan 2014 23:17:24 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8bf94zJtt9BjXcSyehmYkUhwCIgwANhGc2 Message-ID: <290E20B455C66743BE178C5C84F1240847E63346F6@EXMB01CMS.surrey.ac.uk> References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com>,<98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> In-Reply-To: <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 23:18:25 -0000 ...and UDP Lite just covering the L3 and L4 headers, but not the full paylo= ad a la UDP, is still possible when the full payload is not visible. Lloyd Wood http://about.me/lloydwood ________________________________________ From: ietf [ietf-bounces@ietf.org] On Behalf Of Joe Touch [touch@isi.edu] Sent: 27 January 2014 16:48 To: stbryant@cisco.com Cc: mpls@ietf.org; IETF discussion list; curtis@ipv6.occnc.com Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Those same mechanisms have provided hardware checksum support for a very lo= ng time. Joe > On Jan 27, 2014, at 8:40 AM, Stewart Bryant wrote: > >> On 24/01/2014 19:15, Joe Touch wrote: >> >>> This eliminates the "expands the reach of MPLS argument". >>> >>> First UDP checksums: >>> >>> The UDP checksum is at the beginning of the payload. Please see >>> http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html >>> This makes filling in a new UDP checksum infeasible on most high end >>> hardware. >> >> That argument would make sense if most hardware wasn't store-and-forward= on a per-packet basis. > They may be store and forward, but most of the high end designs > use multiple grades of memory putting the packet in "slow memory" > and providing a snapshot of the header in "fast memory" to the > forwarder. Thus although the whole packet is in the system, it > it is not accessible to the engine that would need to calculate the > c/s. > > Stewart From l.wood@surrey.ac.uk Mon Jan 27 15:20:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06821A0403; Mon, 27 Jan 2014 15:20:44 -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, 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 qpFspQ5__ypV; Mon, 27 Jan 2014 15:20:42 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21CD11A03E5; Mon, 27 Jan 2014 15:20:41 -0800 (PST) Received: from [85.158.137.99:12055] by server-12.bemta-3.messagelabs.com id E7/CE-20055-6C9E6E25; Mon, 27 Jan 2014 23:20:38 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-217.messagelabs.com!1390864837!20311613!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20075 invoked from network); 27 Jan 2014 23:20:38 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 27 Jan 2014 23:20:38 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Mon, 27 Jan 2014 23:20:37 +0000 From: To: , , , Date: Mon, 27 Jan 2014 23:18:56 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8blZc5hdQm73++Ro+O4zq8V8TTqQAII9Om Message-ID: <290E20B455C66743BE178C5C84F1240847E63346F7@EXMB01CMS.surrey.ac.uk> References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu> <52E6B128.8060306@joelhalpern.com>,<52E6B272.4030703@isi.edu> In-Reply-To: <52E6B272.4030703@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 23:20:44 -0000 "ASICs can't do IPv6 in hardware! IPv6 can only be done with slow software forwarding! We're stuck with v4!" I think we've been here before. Lloyd Wood http://about.me/lloydwood ________________________________________ From: mpls [mpls-bounces@ietf.org] On Behalf Of Joe Touch [touch@isi.edu] Sent: 27 January 2014 19:24 To: Joel M. Halpern; joel jaeggli; stbryant@cisco.com Cc: mpls@ietf.org; IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard On 1/27/2014 11:19 AM, Joel M. Halpern wrote: > Yes Joe, routers could ahve been built to do those calcualtions at that > performance scale. > There are however two major problems: > > 1) That is not how routers are built. > 2) The target performance scale is rather higher. > > So could someone build an ASIC to do what you want? Has. It's already part of nearly every DMA ASIC in a network interface already. > Probably. Is there > any reason in the world to expect operators to pay the significant extra > cost for such?Not that I can see. We're talking about a ring of full adders, the specs for which are given in an RFC that's 18 years old, and that is already implemented in nearly every host interface, including 10Gps NICs. And we're talking about "routers", many variants of which operate at very high speeds and transparently proxy TCP already. So this is a solved problem. > And even if we could and they would, that is not the world into which we > are deploying these tunnels. We're back to "that's not what they do now", at least in some devices. Well, they don't use MPLS in UDP (since no spec exists), so clearly if they're limited to doing what they already do, this is an exercise in futility. Joe > > Yours, > Joel > > On 1/27/14 1:53 PM, Joe Touch wrote: >> >> >> On 1/27/2014 10:48 AM, joel jaeggli wrote: >>> On 1/27/14, 8:48 AM, Joe Touch wrote: >>>> Those same mechanisms have provided hardware checksum support for a >>>> very long time. >>> >>> The new header and the payload are actually in different parts of the >>> forwarding complex until they hit the output queue, you can't checksum >>> data you don't have. >> >> You can (and some do) the checksum component parts when things go into >> memory; the partial sums can be added as the parts are combined in the >> output queue. >> >> I appreciate that we're all taking about what might be done, but the >> reality is that there are many 'transparent TCP proxies' that have to do >> this, so there's clearly a solution, and it clearly runs fast enough. >> >> Joe >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From l.wood@surrey.ac.uk Mon Jan 27 15:35:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34521A008F for ; Mon, 27 Jan 2014 15:35:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 N7INlg34-cvU for ; Mon, 27 Jan 2014 15:35:00 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.148]) by ietfa.amsl.com (Postfix) with ESMTP id 15C251A026F for ; Mon, 27 Jan 2014 15:34:59 -0800 (PST) Received: from [85.158.136.51:35513] by server-12.bemta-5.messagelabs.com id 9E/70-30017-12DE6E25; Mon, 27 Jan 2014 23:34:57 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-2.tower-49.messagelabs.com!1390865696!18129058!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11903 invoked from network); 27 Jan 2014 23:34:57 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-2.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 27 Jan 2014 23:34:57 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Mon, 27 Jan 2014 23:34:56 +0000 From: To: , Date: Mon, 27 Jan 2014 23:34:09 +0000 Thread-Topic: [mpls] working group last call on draft-ietf-mpls-psc-updates-01 Thread-Index: Ac8btfntZk7XEl0eTgSYKhUIjd2ynAAAk0CS Message-ID: <290E20B455C66743BE178C5C84F1240847E63346F8@EXMB01CMS.surrey.ac.uk> References: Your message of "Mon, 27 Jan 2014 18:37:54 +0800." <52E63702.20102@pi.nu>, <201401272305.s0RN5Zxx095713@maildrop2.v6ds.occnc.com> In-Reply-To: <201401272305.s0RN5Zxx095713@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-psc-updates@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-psc-updates-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 23:35:04 -0000 abbreviation, not acronym http://en.wikipedia.org/wiki/Acronym Lloyd Wood http://about.me/lloydwood ________________________________________ From: mpls [mpls-bounces@ietf.org] On Behalf Of Curtis Villamizar [curtis@i= pv6.occnc.com] Sent: 27 January 2014 23:05 To: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-psc-updates@= tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-psc-updates-= 01 In message <52E63702.20102@pi.nu> Loa Andersson writes: > Working Group, > > This is to initiate a working group last call on > draft-ietf-mpls-psc-updates. > > One reason for the timing, other than that the author thinks is ready > for wglc, is that this document is normatively referenced in > draft-ietf-mpls-tp-psc-itu which also is in wglc. > > There are no IPR disclosures against this document. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > This working group last call ends Feb 19=B40, 2014. > > /Loa > for the MPLS wg chairs The title needs to spell out PSC since there are three interpretations of the acronym in IETF, the other two predating this one by many years. Otherwise looks good. Curtis From curtis@ipv6.occnc.com Mon Jan 27 16:09:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDC11A0164 for ; Mon, 27 Jan 2014 16:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 9UhM4D-dqv8c for ; Mon, 27 Jan 2014 16:09:56 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id DC49D1A015B for ; Mon, 27 Jan 2014 16:09:55 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S09orR096459; Mon, 27 Jan 2014 19:09:50 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280009.s0S09orR096459@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 23:07:17 +0000." <290E20B455C66743BE178C5C84F1240847E63346F5@EXMB01CMS.surrey.ac.uk> Date: Mon, 27 Jan 2014 19:09:50 -0500 Cc: mpls@ietf.org, draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 00:09:57 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346F5@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > >> > I think Curtis may have heard this before :-) > >> > The "preferred" (by the RFC editor) expansion of ECMP is > >> > "Equal-Cost Multipath" > >> > >> The form without the hyphen is more common, even among recent > >> documents. I prefer to keep it without the hyphen. > > >> A discussion for a rainy day with the RFC Editor. > >> Leave as is. > > Basic English grammar. Hyphenate related adjectives. > http://www.grammar-monster.com/lessons/hyphens_in_compound_adjectives.htm > > Lloyd Wood > http://about.me/lloydwood Hi Lloyd, Monster.com lists this as a "should". They don't seem to be using RFC 2119 keywords since its lower case. :-) In the UK, your readers will expect you to use hyphens in compound adjectives. Americans are more lenient. The US ruling is: Use a hyphen if it eliminates ambiguity or helps your reader, else don't bother. If you're unsure, use hyphens. You won't be marked down for using hyphens. Good thing we use US English in IETF and don't have to stick with those pesky British rules. They don't even know how to pronounce router over there. :-) There is no ambiguity caused by leaving out the hyphen. My reasoning is that The form without the hyphen is more common, even among recent documents - and it looks better to a US English reader. We have given the matter due consideration and are going against the monster.com "should". Curtis From edc@google.com Mon Jan 27 16:26:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223621A029C for ; Mon, 27 Jan 2014 16:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCgdurwwYbAx for ; Mon, 27 Jan 2014 16:26:35 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 16FBB1A0251 for ; Mon, 27 Jan 2014 16:26:34 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id l18so6607934wgh.35 for ; Mon, 27 Jan 2014 16:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IOHvugfO/57La6Ot5vPqMuy1EOm7psOq5pGD5jVMrz8=; b=EFspGDVbZpSMlCKBvFKvfUPmCIZZgKOdMt/T+/i3dw+BrP4M93uGVETf+QQuEyyV3C fZfhg1tdHyGcH0FlQwmAIsyLBQJOYQQhVJfklvldqp4tqvM4/4mw5NXmn5xOxTU/tOHl q8+ovqWxPy/r1+0IkfkjKsuzcx+fzI58hopa74t4CAFRfNjivlKLT17LB4rnIYO/9pSP B1XEtnjolZ+Nw0pIreZDndoXLh563f8WCcgLfHQ9hKt8mhHJ+rn4Q9OQerLJfz6K7r17 8YXftZtvcvEFHoB7bp+r0ygLoFEDvMtv4HZUR/to0BjBbbhp42hw5wHD/EDt5yazr3M3 AP5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IOHvugfO/57La6Ot5vPqMuy1EOm7psOq5pGD5jVMrz8=; b=lzLWsModlgPaCPQQWnCRn88ZyPDOfyPiCXjIg/KUILi7b6jMABgzIA7NzWCuS9y+lI wN0pF3nYl/ZL+13wQM0SA5hUbXQ2VFWmb6n3NiQIqo2YcWJ7SWkxj5S3DODsl8+c5Pdm U4S2aC3nyRFU9lTOba+DTLPwZyMqszc4Qjk2MsYmqL9NRfKUb7zaoYzinKDuE2sDJYs8 52PyzRwCXX0KcHH3WcMQ90aGAGwL01LX5L8ACzclEA5kZQKLvbBQ6mRs/Ar/6LBx8uE1 XVwW+6MNjfyJ7bjaU8JeliJoSkMiz6YDphWWmwzt1hn+5NqIeaqsGlZNE96L1FZ+sGpY zB6w== X-Gm-Message-State: ALoCoQmKR9FdPOby7nkeOvdqXApj02MNC0ELELy3N7mBjCrpV/dazLrPCPveMjhdXyedyQ3i90juvrrQKqmwAdYMoaoB18dkJGkNOOxyOa4mSeBCC2QTB3YUWcYI1KO2sDhVB1f3/C5R7rt8aw2dOZ01MmvlIsD86+gEuDRXVE1rJedIPbBTpa+JzKhV4GAB2Rl8llN3gLrJ X-Received: by 10.180.165.174 with SMTP id yz14mr9953139wib.34.1390868792119; Mon, 27 Jan 2014 16:26:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Mon, 27 Jan 2014 16:25:51 -0800 (PST) In-Reply-To: <52E6B272.4030703@isi.edu> References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu> <52E6B128.8060306@joelhalpern.com> <52E6B272.4030703@isi.edu> From: Edward Crabbe Date: Mon, 27 Jan 2014 16:25:51 -0800 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=90e6ba30982448c77504f0fce00f Cc: joel jaeggli , "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 00:26:38 -0000 --90e6ba30982448c77504f0fce00f Content-Type: text/plain; charset=ISO-8859-1 I assume we're talking about the chksum issue here. If this is the case, please go fix IPv6 by adding a hop by hop checksum extension header and getting it implemented by vendors. ^_^ If by 'this' we mean stateful congestion control of multiple terabits of tunnel traffic, then it is *most certainly* not a solved problem, and definitely not something I'm interested in paying for. cheers, -ed On Mon, Jan 27, 2014 at 11:24 AM, Joe Touch wrote: > > > On 1/27/2014 11:19 AM, Joel M. Halpern wrote: > >> Yes Joe, routers could ahve been built to do those calcualtions at that >> performance scale. >> There are however two major problems: >> >> 1) That is not how routers are built. >> 2) The target performance scale is rather higher. >> >> So could someone build an ASIC to do what you want? >> > > Has. It's already part of nearly every DMA ASIC in a network interface > already. > > > > Probably. Is there > >> any reason in the world to expect operators to pay the significant extra >> cost for such?Not that I can see. >> > > We're talking about a ring of full adders, the specs for which are given > in an RFC that's 18 years old, and that is already implemented in nearly > every host interface, including 10Gps NICs. > > And we're talking about "routers", many variants of which operate at very > high speeds and transparently proxy TCP already. So this is a solved > problem. > > > And even if we could and they would, that is not the world into which we >> are deploying these tunnels. >> > > We're back to "that's not what they do now", at least in some devices. > > Well, they don't use MPLS in UDP (since no spec exists), so clearly if > they're limited to doing what they already do, this is an exercise in > futility. > > Joe > > > >> Yours, >> Joel >> >> On 1/27/14 1:53 PM, Joe Touch wrote: >> >>> >>> >>> On 1/27/2014 10:48 AM, joel jaeggli wrote: >>> >>>> On 1/27/14, 8:48 AM, Joe Touch wrote: >>>> >>>>> Those same mechanisms have provided hardware checksum support for a >>>>> very long time. >>>>> >>>> >>>> The new header and the payload are actually in different parts of the >>>> forwarding complex until they hit the output queue, you can't checksum >>>> data you don't have. >>>> >>> >>> You can (and some do) the checksum component parts when things go into >>> memory; the partial sums can be added as the parts are combined in the >>> output queue. >>> >>> I appreciate that we're all taking about what might be done, but the >>> reality is that there are many 'transparent TCP proxies' that have to do >>> this, so there's clearly a solution, and it clearly runs fast enough. >>> >>> Joe >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --90e6ba30982448c77504f0fce00f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I assume we're talking about the chksum issue here. = =A0If this is the case, please go fix IPv6 by adding a hop by hop checksum = extension header and getting it implemented by vendors. =A0^_^

If by 'this' we mean stateful congestion control of multiple terabi= ts of tunnel traffic, then it is *most certainly* not a solved problem, and= definitely not something I'm interested in paying for. =A0

cheers,
=A0 =A0-ed


On Mon, Jan 27, 2014 at 11:24 AM,= Joe Touch <touch@isi.edu> wrote:


On 1/27/2014 11:19 AM, Joel M. Halpern wrote:
Yes Joe, routers could ahve been built to do those calcualtions at that
performance scale.
There are however two major problems:

1) That is not how routers are built.
2) The target performance scale is rather higher.

So could someone build an ASIC to do what you want?

Has. It's already part of nearly every DMA ASIC in a network interface = already.


> Probably. =A0Is there
any reason in the world to expect operators to pay the significant extra cost for such?Not that I can see.

We're talking about a ring of full adders, the specs for which are give= n in an RFC that's 18 years old, and that is already implemented in nea= rly every host interface, including 10Gps NICs.

And we're talking about "routers", many variants of which ope= rate at very high speeds and transparently proxy TCP already. So this is a = solved problem.


And even if we could and they would, that is not the world into which we are deploying these tunnels.

We're back to "that's not what they do now", at least in = some devices.

Well, they don't use MPLS in UDP (since no spec exists), so clearly if = they're limited to doing what they already do, this is an exercise in f= utility.

Joe



Yours,
Joel

On 1/27/14 1:53 PM, Joe Touch wrote:


On 1/27/2014 10:48 AM, joel jaeggli wrote:
On 1/27/14, 8:48 AM, Joe Touch wrote:
Those same mechanisms have provided hardware checksum support for a
very long time.

The new header and the payload are actually in different parts of the
forwarding complex until they hit the output queue, you can't checksum<= br> data you don't have.

You can (and some do) the checksum component parts when things go into
memory; the partial sums can be added as the parts are combined in the
output queue.

I appreciate that we're all taking about what might be done, but the reality is that there are many 'transparent TCP proxies' that have = to do
this, so there's clearly a solution, and it clearly runs fast enough.
Joe
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--90e6ba30982448c77504f0fce00f-- From curtis@ipv6.occnc.com Mon Jan 27 17:00:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E9E1A037E; Mon, 27 Jan 2014 17:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 a5mtqxYZ2gB0; Mon, 27 Jan 2014 17:00:56 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8391A0377; Mon, 27 Jan 2014 17:00:56 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S10jhO097154; Mon, 27 Jan 2014 20:00:45 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280100.s0S10jhO097154@maildrop2.v6ds.occnc.com> To: Joe Touch From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 10:53:09 -0800." <52E6AB15.2080907@isi.edu> Date: Mon, 27 Jan 2014 20:00:45 -0500 Cc: joel jaeggli , "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 01:00:58 -0000 In message <52E6AB15.2080907@isi.edu> Joe Touch writes: > On 1/27/2014 10:48 AM, joel jaeggli wrote: > > On 1/27/14, 8:48 AM, Joe Touch wrote: > >> Those same mechanisms have provided hardware checksum support for a very long time. > > > > The new header and the payload are actually in different parts of the > > forwarding complex until they hit the output queue, you can't checksum > > data you don't have. > > You can (and some do) the checksum component parts when things go into > memory; the partial sums can be added as the parts are combined in the > output queue. > > I appreciate that we're all taking about what might be done, but the > reality is that there are many 'transparent TCP proxies' that have to > do this, so there's clearly a solution, and it clearly runs fast > enough. > > Joe Joe, Chips that did 4 x 10 Gb/s are old stuff now but in their day they pushed silicon limites. Chips now do N x 100 Gb/s. Stewart is describing how these chips (both the prior generation and current) are architected and you are going back to some idea that there is a common memory where this all resides and its just a matter of looking at it. This is not software on a general purpose processor. If a queue forms, the headers are in SRAM and the body of the packet is off chip in DRAM. There isn't enough memory bandwidth to pull the packet back until its time to send it out. At that point the header and body are joined but the header processing has been completed long ago. If there is not much of a queue the packet may go into SRAM cache for the buffer DRAM and go right out of that SRAM. If there is no queue at all cut-through can happen. The header gets transmitted before the entire packet arrives at the input of the chip. (And if FCS fails a runt with bad FCS goes out). At the very least this can't work if cut-through is used to reduce latency. When the two are joined, about the only processing is in the MAC, its mostly loading a shift register and serializing but it also does the FCS and sticks that *at the end*. The MAC is quite inflexible as it is mostly silicon gates designed to do some minimal processing for a layer-2 such as Ethernet or GFP/OTN. Think for a moment what N x 100 Gb/s means. For small packets 150 Mpps per interface with Ethernet overhead (large overhead). That is 20 clock cycles per packet for a 3 GHz clock rate. Divide that by N. This has to be done in specialized hardware and if you also think about the memory bandwidth needed, you need very wide and very fast DRAM and get one write when the packet arrives and one read before it leaves and even then have to play tricks in the SRAM cache like concatonating short packets going out the same queue. BTW - "transparent TCP proxies" don't need to look at the payload for the purpose of updating a checksum. Whenever a header modification is made you only need to know the old checksum, the old information and the new information replacing it. That is why IP checksum modification can be done quickly. Typically only TTL changes. These are also running at least a decimal order of magnitude or two slower. Curtis From l.wood@surrey.ac.uk Mon Jan 27 17:11:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32F41A00BC for ; Mon, 27 Jan 2014 17:11: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, RCVD_IN_DNSWL_MED=-2.3, 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 jLa4SJJeNiAL for ; Mon, 27 Jan 2014 17:11:33 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.113]) by ietfa.amsl.com (Postfix) with ESMTP id 396F31A00A7 for ; Mon, 27 Jan 2014 17:11:33 -0800 (PST) Received: from [193.109.255.147:12952] by server-9.bemta-14.messagelabs.com id F8/C9-13957-1C307E25; Tue, 28 Jan 2014 01:11:29 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-7.tower-72.messagelabs.com!1390871488!5816459!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5728 invoked from network); 28 Jan 2014 01:11:28 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-7.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 28 Jan 2014 01:11:28 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Tue, 28 Jan 2014 01:11:27 +0000 From: To: Date: Tue, 28 Jan 2014 01:11:27 +0000 Thread-Topic: [mpls] AD review of draft-ietf-mpls-forwarding Thread-Index: Ac8bvxCMqxhFtGsKTCqaY5bWJaclDwABf5Bm Message-ID: <290E20B455C66743BE178C5C84F1240847E63346F9@EXMB01CMS.surrey.ac.uk> References: Your message of "Mon, 27 Jan 2014 23:07:17 +0000." <290E20B455C66743BE178C5C84F1240847E63346F5@EXMB01CMS.surrey.ac.uk>, <201401280009.s0S09orR096459@maildrop2.v6ds.occnc.com> In-Reply-To: <201401280009.s0S09orR096459@maildrop2.v6ds.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: draft-ietf-mpls-forwarding.all@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 01:11:39 -0000 Curtis, my mistake. I hadn't realised that RFCs and internet-drafts were written solely for an American audience, and that the preferences of US readers tak= es priority over the ease of reading of the other 6.5 billion+ people on the planet. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com] Sent: 28 January 2014 00:09 To: Wood L Dr (Electronic Eng) Cc: adrian@olddog.co.uk; curtis@ipv6.occnc.com; mpls@ietf.org; draft-ietf-m= pls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding In message <290E20B455C66743BE178C5C84F1240847E63346F5@EXMB01CMS.surrey.ac.= uk> l.wood@surrey.ac.uk writes: > >> > I think Curtis may have heard this before :-) > >> > The "preferred" (by the RFC editor) expansion of ECMP is > >> > "Equal-Cost Multipath" > >> > >> The form without the hyphen is more common, even among recent > >> documents. I prefer to keep it without the hyphen. > > >> A discussion for a rainy day with the RFC Editor. > >> Leave as is. > > Basic English grammar. Hyphenate related adjectives. > http://www.grammar-monster.com/lessons/hyphens_in_compound_adjectives.htm > > Lloyd Wood > http://about.me/lloydwood Hi Lloyd, Monster.com lists this as a "should". They don't seem to be using RFC 2119 keywords since its lower case. :-) In the UK, your readers will expect you to use hyphens in compound adjectives. Americans are more lenient. The US ruling is: Use a hyphen if it eliminates ambiguity or helps your reader, else don't bother. If you're unsure, use hyphens. You won't be marked down for using hyphens. Good thing we use US English in IETF and don't have to stick with those pesky British rules. They don't even know how to pronounce router over there. :-) There is no ambiguity caused by leaving out the hyphen. My reasoning is that The form without the hyphen is more common, even among recent documents - and it looks better to a US English reader. We have given the matter due consideration and are going against the monster.com "should". Curtis From curtis@ipv6.occnc.com Mon Jan 27 17:29:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E7F1A0345; Mon, 27 Jan 2014 17:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 BMkI_-i-Yuax; Mon, 27 Jan 2014 17:29:21 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC941A00A7; Mon, 27 Jan 2014 17:29:21 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S1TGY5099912; Mon, 27 Jan 2014 20:29:16 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280129.s0S1TGY5099912@maildrop2.v6ds.occnc.com> To: Joe Touch From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 11:24:34 -0800." <52E6B272.4030703@isi.edu> Date: Mon, 27 Jan 2014 20:29:16 -0500 Cc: joel jaeggli , "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 01:29:24 -0000 In message <52E6B272.4030703@isi.edu> Joe Touch writes: > On 1/27/2014 11:19 AM, Joel M. Halpern wrote: > > Yes Joe, routers could ahve been built to do those calcualtions at that > > performance scale. > > There are however two major problems: > > > > 1) That is not how routers are built. > > 2) The target performance scale is rather higher. > > > > So could someone build an ASIC to do what you want? > > Has. It's already part of nearly every DMA ASIC in a network interface > already. There is no DMA ASIC in these designs. There is no shared memory to DMA from. A router is not a specialized PC. At any one point in time the best DMA ASICs run at a fraction of the speed of forwarding ASICs of that same era. Some forwarding ASICs through parallelism or pipelining (or both) can forward a packet in under ten clock ticks of the ASIC. [The best forwarding chips today are technically not ASICs but custom silicon though they are still often called forwarding ASICs.] BTW - the PCIe FCS is at the end of the transmission not the front so the DMA ASIC doesn't have to read memory twice, the first time to compute a checksum to put at the front. > > Probably. Is there > > any reason in the world to expect operators to pay the significant extra > > cost for such?Not that I can see. > > We're talking about a ring of full adders, the specs for which are > given in an RFC that's 18 years old, and that is already implemented > in nearly every host interface, including 10Gps NICs. > > And we're talking about "routers", many variants of which operate at > very high speeds and transparently proxy TCP already. So this is a > solved problem. See prior email. They don't need to look at the payload to modify IP or TCP headers and then update the checksum. > > And even if we could and they would, that is not the world into which we > > are deploying these tunnels. > > We're back to "that's not what they do now", at least in some devices. > > Well, they don't use MPLS in UDP (since no spec exists), so clearly if > they're limited to doing what they already do, this is an exercise in > futility. > > Joe You seem to be missing the point that MPLS over UDP is not considered a good solution going forward on which to base the design of new hardware, but rather an interim solution to accomodate old hardware that doesn't load split MPLS traffic. In any case, two passes, one to compute a checksum and put it on the front, would increase latency. If anything UDP-Heavy with an FCS at the end would be used, even though two FCS is considered bad form. Curtis > > Yours, > > Joel > > > > On 1/27/14 1:53 PM, Joe Touch wrote: > >> > >> > >> On 1/27/2014 10:48 AM, joel jaeggli wrote: > >>> On 1/27/14, 8:48 AM, Joe Touch wrote: > >>>> Those same mechanisms have provided hardware checksum support for a > >>>> very long time. > >>> > >>> The new header and the payload are actually in different parts of the > >>> forwarding complex until they hit the output queue, you can't checksum > >>> data you don't have. > >> > >> You can (and some do) the checksum component parts when things go into > >> memory; the partial sums can be added as the parts are combined in the > >> output queue. > >> > >> I appreciate that we're all taking about what might be done, but the > >> reality is that there are many 'transparent TCP proxies' that have to do > >> this, so there's clearly a solution, and it clearly runs fast enough. > >> > >> Joe From curtis@ipv6.occnc.com Mon Jan 27 17:56:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1631A00BE; Mon, 27 Jan 2014 17:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 8M7-DlnmQ_Z5; Mon, 27 Jan 2014 17:56:26 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 60D351A008F; Mon, 27 Jan 2014 17:56:26 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S1uKJA000384; Mon, 27 Jan 2014 20:56:20 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280156.s0S1uKJA000384@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 23:17:24 +0000." <290E20B455C66743BE178C5C84F1240847E63346F6@EXMB01CMS.surrey.ac.uk> Date: Mon, 27 Jan 2014 20:56:20 -0500 Cc: mpls@ietf.org, ietf@ietf.org, touch@isi.edu Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 01:56:28 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346F6@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > ...and UDP Lite just covering the L3 and L4 headers, but not the full > payload a la UDP, is still possible when the full payload is not > visible. > > Lloyd Wood > http://about.me/lloydwood ... but doesn't solve the problem of ECMP using old routers so UDP-Lite is a non-starter. Curtis > ________________________________________ > From: ietf [ietf-bounces@ietf.org] On Behalf Of Joe Touch [touch@isi.edu] > Sent: 27 January 2014 16:48 > To: stbryant@cisco.com > Cc: mpls@ietf.org; IETF discussion list; curtis@ipv6.occnc.com > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > Those same mechanisms have provided hardware checksum support for a very long time. > > Joe > > > On Jan 27, 2014, at 8:40 AM, Stewart Bryant wrote: > > > >> On 24/01/2014 19:15, Joe Touch wrote: > >> > >>> This eliminates the "expands the reach of MPLS argument". > >>> > >>> First UDP checksums: > >>> > >>> The UDP checksum is at the beginning of the payload. Please see > >>> http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html > >>> This makes filling in a new UDP checksum infeasible on most high end > >>> hardware. > >> > >> That argument would make sense if most hardware wasn't store-and-forward on a per-packet basis. > > They may be store and forward, but most of the high end designs > > use multiple grades of memory putting the packet in "slow memory" > > and providing a snapshot of the header in "fast memory" to the > > forwarder. Thus although the whole packet is in the system, it > > it is not accessible to the engine that would need to calculate the > > c/s. > > > > Stewart From curtis@ipv6.occnc.com Mon Jan 27 18:01:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002951A0171 for ; Mon, 27 Jan 2014 18:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 v8Ag9zChtw3M for ; Mon, 27 Jan 2014 18:01:42 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC91A0176 for ; Mon, 27 Jan 2014 18:01:42 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S21d2K000505; Mon, 27 Jan 2014 21:01:39 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280201.s0S21d2K000505@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 23:34:09 +0000." <290E20B455C66743BE178C5C84F1240847E63346F8@EXMB01CMS.surrey.ac.uk> Date: Mon, 27 Jan 2014 21:01:39 -0500 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-psc-updates@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-psc-updates-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 02:01:44 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346F8@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > abbreviation, not acronym > > http://en.wikipedia.org/wiki/Acronym > > Lloyd Wood > http://about.me/lloydwood Lloyd, Thank you for the substantive correction. Loa, Eric - please consider my comment ammended appropriately. Curtis > ________________________________________ > From: mpls [mpls-bounces@ietf.org] On Behalf Of Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 27 January 2014 23:05 > To: Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-psc-updates@tools.ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-psc-updates-01 > > In message <52E63702.20102@pi.nu> > Loa Andersson writes: > > > Working Group, > > > > This is to initiate a working group last call on > > draft-ietf-mpls-psc-updates. > > > > One reason for the timing, other than that the author thinks is ready > > for wglc, is that this document is normatively referenced in > > draft-ietf-mpls-tp-psc-itu which also is in wglc. > > > > There are no IPR disclosures against this document. > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > > > This working group last call ends Feb 19´0, 2014. > > > > /Loa > > for the MPLS wg chairs > > > The title needs to spell out PSC since there are three interpretations > of the acronym in IETF, the other two predating this one by many > years. > > Otherwise looks good. > > Curtis From curtis@ipv6.occnc.com Mon Jan 27 18:17:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1B61A0176 for ; Mon, 27 Jan 2014 18:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 mjEWPxK-Mela for ; Mon, 27 Jan 2014 18:17:07 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id E58401A00A7 for ; Mon, 27 Jan 2014 18:17:06 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S2H151000639; Mon, 27 Jan 2014 21:17:01 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280217.s0S2H151000639@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Tue, 28 Jan 2014 01:11:27 +0000." <290E20B455C66743BE178C5C84F1240847E63346F9@EXMB01CMS.surrey.ac.uk> Date: Mon, 27 Jan 2014 21:17:01 -0500 Cc: mpls@ietf.org, draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 02:17:10 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346F9@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > Curtis, > > my mistake. I hadn't realised that RFCs and internet-drafts were > written solely for an American audience, and that the preferences of > US readers takes priority over the ease of reading of the other 6.5 > billion+ people on the planet. > > Lloyd Wood > http://about.me/lloydwood Well now you know. :-) See for example RFC-Editor's FAQ #40. 40. I used British English. Why did you change it to American English? If there is a mix of British and American English within the Internet-Draft, the document is updated to use American English for consistency. The default has always been American English. Perhaps since a DARPA funded project started the RFC series and Jon Postel was not a Brit. Even though RFC 6949 says "The official language of the RFC Series is English" and otherwise stays out of the fight. :-) Cherio old chap, Curtis > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com] > Sent: 28 January 2014 00:09 > To: Wood L Dr (Electronic Eng) > Cc: adrian@olddog.co.uk; curtis@ipv6.occnc.com; mpls@ietf.org; draft-ietf-mpls-forwarding.all@tools.ietf.org > Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding > > In message <290E20B455C66743BE178C5C84F1240847E63346F5@EXMB01CMS.surrey.ac.uk> > l.wood@surrey.ac.uk writes: > > > >> > I think Curtis may have heard this before :-) > > >> > The "preferred" (by the RFC editor) expansion of ECMP is > > >> > "Equal-Cost Multipath" > > >> > > >> The form without the hyphen is more common, even among recent > > >> documents. I prefer to keep it without the hyphen. > > > > >> A discussion for a rainy day with the RFC Editor. > > >> Leave as is. > > > > Basic English grammar. Hyphenate related adjectives. > > http://www.grammar-monster.com/lessons/hyphens_in_compound_adjectives.htm > > > > Lloyd Wood > > http://about.me/lloydwood > > > Hi Lloyd, > > Monster.com lists this as a "should". They don't seem to be using RFC > 2119 keywords since its lower case. :-) > > In the UK, your readers will expect you to use hyphens in compound > adjectives. > > Americans are more lenient. The US ruling is: Use a hyphen if it > eliminates ambiguity or helps your reader, else don't bother. If > you're unsure, use hyphens. You won't be marked down for using > hyphens. > > Good thing we use US English in IETF and don't have to stick with > those pesky British rules. They don't even know how to pronounce > router over there. :-) > > There is no ambiguity caused by leaving out the hyphen. My reasoning > is that The form without the hyphen is more common, even among recent > documents - and it looks better to a US English reader. We have given > the matter due consideration and are going against the monster.com > "should". > > Curtis From ryoo@etri.re.kr Mon Jan 27 18:17:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D184D1A00A7 for ; Mon, 27 Jan 2014 18:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 Lbqth2j2yxLR for ; Mon, 27 Jan 2014 18:17:28 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 47C1D1A008F for ; Mon, 27 Jan 2014 18:17:27 -0800 (PST) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 28 Jan 2014 11:17:26 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Tue, 28 Jan 2014 11:17:21 +0900 From: "Ryoo, Jeong-dong" To: Yaacov Weingarten , Loa Andersson Thread-Topic: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 Thread-Index: AQHPFYdUrouQjghEKkymdYiVWJN87pqYdiKAgADkFwY= Date: Tue, 28 Jan 2014 02:17:20 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3C3A@SMTP2.etri.info> References: <52DC89C3.3030003@pi.nu>, In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3C3ASMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 02:17:32 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3C3ASMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFhY292LA0KDQpUaGFuayB5b3Ugc28gbXVjaCBmb3IgeW91ciByZXZpZXcuDQpCZWZvcmUgSSBn byB0aHJvdWdoIHlvdXIgY29tbWVudHMsIHdoaWNoIG1heSB0YWtlIHNvbWUgdGltZSwNCkkgd291 bGQgbGlrZSB0byByZXNwb25kIHRvIHRoZSBiYXNpYyBxdWVzdGlvbiByZWdhcmRpbmcgdGhlIHZl cnNpb24gbnVtYmVyIGluIHRoaXMgZW1haWwuDQoNCllvdSBoYXZlIGV4YWN0bHkgdGhlIHNhbWUg dGhvdWdodCBvbiB0aGUgdmVyc2lvbiBudW1iZXIgYXMgSSBoYXZlLg0KQWxzbywgY2hhbmdpbmcg dGhlIHZlcnNpb24gbnVtYmVyIGNhbiBlbGltaW5hdGUgYWxsIHRoZSBoYXNzbGVzIHdpdGggdGhl IENhcGFiaWxpdGllcyBUTFZzIGluIFNlY3Rpb24gOS4NCg0KSW4gdGhlIGVhcmx5IHN0YWdlIG9m IHRoaXMgd29yaywgdGhlcmUgd2FzIGFuIGFyZ3VtZW50IHRvIHRyZWF0IGVhY2ggb2YgdGhvc2Ug Zml2ZSBjYXBhYmlsaXRpZXMgaW5kaXZpZHVhbGx5LA0Kc28gdGhhdCBhbnkgY2hhbmdlcyBpbiBS RkM2Mzc4IGNhbiBiZSBzZWVuIGFzIG9waW9uYWwgZmVhdHVyZXMsDQpUaGlzIG1heSBzb3VuZCBv ayBpbiBnZW5lcmFsLA0KYnV0IGNvbnNpZGVyaW5nIHRoZSBuYXR1cmUgb2YgdGhlIHByb3RlY3Rp b24gc3dpdGNoaW5nLCBpdCBkb2VzIG5vdCBtYWtlIGFueSBzZW5zZS4NCkV2ZW4gdGhvdWdoIHRo ZSBpZGVhIG9mIHRyZWF0aW5nIHRoZW0gYXMgaW5kaXZpZHVhbHMgaXMgcmVmbGVjdGVkIGluIGN1 cnJlbnQgZHJhZnQuDQpJIHN0aWxsIGJlbGlldmUgdGhhdCB0aGUgY2hhbmdlIG9mIHZlcnNpb24g bnVtYmVyIGlzIGEgZmFyLWJldHRlciBzb2x1dGlvbi4NCg0KSWYgc29tZWJvZHkgd2FudHMgYW55 IG9uZSBvZiBwcmlvcml0eSBtb2RpZmljYXRpb24gY2FwYWJpbGl0eSBhbmQgbm9uLXJldmVydGl2 ZSBiZWhhdmlvciBjYXBhYmlsaXR5LA0KYSB0b3RhbGx5IGRpZmZlcmVudCBwcm90b2NvbCBpbXBs ZW1lbnRhdGlvbiAocHJpb3JpdHkgbG9naWMgYW5kIHN0YXRlIG1hY2hpbmUpIHNob3VsZCBiZSBk ZXZpc2VkLg0KVGhlcmUgaXMgbm8gd2F5IHlvdSBjYW4gY2hhbmdlIHRoZSBDYXBhYmlsaXRpZXMg c2V0IHVubGVzcyB5b3UgaGF2ZSBhIGRpZmZlcmVudCBzZXQgb2YgcHJpb3JpdHkgZXZhbHVhdGlv biBhbmQgc3RhdGUgbWFjaGluZSwNCmkuZS4sIGEgZGlmZmVyZW50IFBTQyBwcm9jZXNzLg0KSW4g dGhlIGNhc2UgYW4gb3BlcmF0b3IgZG9lc24ndCB3YW50IHRvIHVzZSBhbnkgb2YgU0QsIE1TLVcg YW5kIEVYRVIgY2FwYWJpbGl0aWVzLA0Kd2hhdCB0aGUgb3BlcmF0b3IgY2FuIHNpbXBseSBkbyBp cyBqdXN0IGRpc2FibGluZyB0aGUgaW5wdXQgdHJpZ2dlci4NCkkgZG9uJ3Qgc2VlIGFueSB2YWx1 ZSBvZiBpbnRyb2R1Y2luZyB0aGUgQ2FwYWJpbGl0aWVzIFRMViwgd2hpY2gganVzdCBjb21wbGlj YXRlcyB0aGUgcHJvdG9jb2wgb3BlcmF0aW9uLg0KDQpJZiB3ZSBkZWNpZGUgdG8gY2hhbmdlIHRo ZSB2ZXJzaW9uIG51bWJlciBhbmQgZWxpbWluYXRlIENhcGFiaWxpdGllcyBUTFYsDQp0aGVyZSBt YXkgYmUgc29tZSBlZGl0aW5nIGpvYi4gQnV0LCBpdCBpcyB3ZWxsIHdvcnRoIHRoZSBjaGFuZ2Uu DQoNCkJlc3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkZyb20gOiAiWWFhY292IFdlaW5nYXJ0ZW4iIDx3eWFhY292QGdtYWls LmNvbT4NClNlbnQgOiAyMDE0LTAxLTI4IDA1OjEyOjE2ICggKzA5OjAwICkNClRvIDogTG9hIEFu ZGVyc3NvbiA8bG9hQHBpLm51Pg0KQ2MgOiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPiwg bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgPG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPiwg ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcgPGRyYWZ0LWlldGYtbXBs cy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPiwgPG1wbHMtYWRzQHRvb2xzLmlldGYub3JnPg0K U3ViamVjdCA6IFJlOiBbbXBsc10gd29ya2luZyBncm91cCBsYXN0IGNhbGwgZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHUtMDENCg0KSGkgYWxsLA0KDQpJIGhhdmUgcmVhZCB0aHJvdWdoIHRoZSBs YXRlc3QgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IGFuZCBoYXZlIGEgbnVtYmVyIG9mIGNvbW1lbnRz IGFuZCBxdWVzdGlvbnMgcmVnYXJkaW5nIHRoaXMgZG9jdW1lbnQuIFdoaWxlLCBpbiBnZW5lcmFs LCBJIGZlZWwgdGhhdCB0aGUgZXh0ZW5zaW9ucyB0byB0aGUgYmVoYXZpb3Igb2YgUkZDNjM3OCBh cmUgYXBwcm9wcmlhdGUsIEkgZmluZCB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgc3RpbGwgaW4gbmVl ZCBvZiByZWZpbmVtZW50IGluIGl0cyBsYW5ndWFnZSBhbmQgY2xhcml0eSBvZiB0aGUgZnVuY3Rp b25hbGl0eS4gV2hpbGUgc29tZSBvZiB0aGUgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGlzIGRl c2NyaWJlZCwgdGhlcmUgYXJlIGRpZmZlcmVudCBjYXNlcyBvZiB0aGUgZnVuY3Rpb25hbGl0eSB0 aGF0IGlzIGVpdGhlciBub3QgZGVzY3JpYmVkIG9yIGlzIHJhdGhlciBjb25mdXNpbmcuDQoNCk9u ZSBiYXNpYyBxdWVzdGlvbiBpcyAtIENvbnNpZGVyaW5nIHRoYXQgdGhpcyBkcmFmdCBpcyBwcm9w b3NpbmcgY2hhbmdlcyB0byB0aGUgYmFzaWMgb3BlcmF0aW9uIG9mIHRoZSBQU0MgcHJvdG9jb2ws IExvY2FsIFJlcXVlc3QgTG9naWMsIGFuZCB0aGUgUFNDIENvbnRyb2wgTG9naWMsIEkgd291bGQg aGF2ZSB0aG91Z2h0IHRoYXQgdGhlIFBTQyBWZXJzaW9uIG51bWJlciBzaG91bGQgY2hhbmdlISBX aHkgdGhlbiwgaXMgdGhlcmUgbm8gbWVudGlvbiBvZiBjaGFuZ2luZyB0aGUgdmVyc2lvbiB0byBh bGxvdyBuZXR3b3JrcyB0aGF0IHN1cHBvcnQgdGhlIGZ1bmN0aW9uYWxpdHkgZGVzY3JpYmVkIGlu IFJGQzYzNzggdG8gY29udGludWUgdG8gb3BlcmF0ZT8NCg0KUmVnYXJkaW5nIHRoZSBmdW5jdGlv bmFsaXR5IHByb3Bvc2VkIGluIHRoZSBkcmFmdCwgSSBoYXZlIHRoZSBmb2xsb3dpbmcgcXVlc3Rp b25zIGFuZCBjb21tZW50cyAtDQoNCiAgMS4gIChmb3IgY2xhcmlmaWNhdGlvbikgUmVnYXJkaW5n IHRoZSBmdW5jdGlvbmFsaXR5IG9mIE1TLVcsIHdoYXQgaXMgdGhlIGZ1bmN0aW9uYWxpdHkgaWYg dGhlIGRhdGEtdHJhZmZpYyBpcyBjdXJyZW50bHkgb24gdGhlIHdvcmtpbmcgcGF0aD8gU2luY2Ug dGhlIHB1cnBvc2Ugb2YgdGhlIGNvbW1hbmQgaXMgdG8gbW92ZSB0aGUgdHJhZmZpYyB0byB0aGUg d29ya2luZyBwYXRoLCBzaG91bGRuJ3QgaXQgYmUgaWdub3JlZD8gSG93ZXZlciwgYWNjb3JkaW5n IHRvIHRoZSBTdGF0ZSBUcmFuc2l0aW9uIFRhYmxlIGluIHNlY3Rpb24gMTEuMSAtIGlmIHRoZSBN Uy1XIGlzIHJlY2VpdmVkIGJ5IGEgTEVSIGluIE5vcm1hbCBTdGF0ZSBpdCB0cmFuc2ZlcnMgdG8g U3dpdGNoaW5nIEFkbWluaXN0cmF0aXZlIFN0YXRlISBUaGUgbWFpbiBlZmZlY3Qgc2VlbXMgdG8g YmUgdG8gY2F1c2UgdGhlIExFUiB0byBpZ25vcmUgaW5jb21pbmcgTVMgYW5kIEVYRVIgcmVxdWVz dHMgKHRoYXQgYXJlIG5vdCBpZ25vcmVkIGluIE5vcm1hbCBTdGF0ZSkuDQogIDIuICBSZWdhcmRp bmcgdGhlIFNEIGZ1bmN0aW9uYWxpdHkgLSBhZnRlciBhIHByZXZpb3VzIGRpc2N1c3Npb24gb24g dGhlIG1haWxpbmcgbGlzdCB0aGUgZnVuY3Rpb25hbGl0eSB3aGVuIHByb3RlY3RpbmcgZm9yIFNE IHNpdHVhdGlvbnMgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMykgd2FzIGNoYW5nZWQgdG8gZXNz ZW50aWFsbHkgc3dpdGNoIG92ZXIgdG8gdGhlIExFUiB0cmFuc21pdHRpbmcgdGhlIHBhY2tldHMg b24gYm90aCB0aGUgd29ya2luZyBhbmQgcHJvdGVjdGlvbiBwYXRocyAoZXNzZW50aWFsbHkgMSsx IHRyYW5zbWlzc2lvbikuIEhvd2V2ZXIsIHRoZXJlIGlzIHZlcnkgbGl0dGxlIGRpc2N1c3Npb24g b2YgaG93IHRoZSByZWNlaXZpbmcgTEVSIGlzIHN1cHBvc2VkIHRvIHNlbGVjdCB0aGUgaW5jb21p bmcgcGFja2V0cyB3aGlsZSBhdm9pZGluZyBkdXBsaWNhdGlvbiBvZiBkYXRhLiBDb3VsZCBwbGVh c2UgZWxhYm9yYXRlIG9uIHRoaXM/DQogIDMuICBSZWdhcmRpbmcgdGhlIFNEIGZ1bmN0aW9uYWxp dHkgLSBhcyBtZW50aW9uZWQgaW4gdGhlIHByZXZpb3VzIHBvaW50LCB3aGVuIHByb3RlY3Rpbmcg Zm9yIFNELCB0aGUgdHJhbnNtaXR0aW5nIExFUiBkdXBsaWNhdGVzIHRoZSBwYWNrZXRzIG9uIGJv dGggVyAmIFAgYW5kIHRoZSByZWNlaXZpbmcgTEVSLCBwcmVzdW1hYmx5LCByZWFkcyB0aGUgZGF0 YSBmcm9tIGVpdGhlciBwYXRoLCBhbmQgbWF5IGNob29zZSBkaWZmZXJlbnRseSBmb3IgZGlmZmVy ZW50IHBhY2tldHMuIEhvd2V2ZXIsIGxhdGVyIGluIHNlY3Rpb24gNy40IChhbmQgYWdhaW4gaW4g c2VjdGlvbiAxMC4yKSB5b3UgaW50cm9kdWNlIGEgbmV3IGNvbmNlcHQgb2YgInN0YW5kYnkgcGF0 aCIgYXMgInRoZSBwYXRoIGZyb20gd2hpY2ggdGhlIHNlbGVjdG9yIGRvZXMgbm90IHNlbGVjdCB0 aGUgdXNlciBkYXRhIHRyYWZmaWMiIGluIHJlZ2FyZCB0byBkZXRlcm1pbmluZyB0aGUgcHJpb3Jp dHkgb2YgImNvbmZsaWN0aW5nIiBTRC1XIGFuZCBTRC1QIHRyaWdnZXJzLiBDYW4geW91IGNsYXJp Znkgd2hpY2ggb2YgdGhlIHR3byBwYXRocyB0aGF0IGFyZSBib3RoIGNhcnJ5aW5nIHVzZXIgZGF0 YSBpcyB0aGUgc3RhbmRieSBwYXRoPw0KICA0LiAgRnVydGhlciByZWdhcmRpbmcgdGhlIHBvaW50 IG9mICJjb25mbGljdGluZyIgU0QgdHJpZ2dlcnMgLSBzaW5jZSB0aGUgcHJvdGVjdGlvbiBmdW5j dGlvbmFsaXR5IG9mIFNEIGlzIHRvIGR1cGxpY2F0ZSB0aGUgZGF0YSBvbiBib3RoIFcgJiBQIC0g d2h5IGlzIHRoaXMgY29uc2lkZXJlZCBhIGNvbmZsaWN0LCBzaW5jZSB0aGUgYWN0aW9uIGZvciBi b3RoIHdpbGwgYmUgaWRlbnRpY2FsIC0gY29udGludWUgdHJhbnNtaXR0aW5nIG9uIGJvdGggVyAm IFAuIFNvbWUgbW9yZSBjbGFyaWZpY2F0aW9uIHdvdWxkIGhlbHAuDQogIDUuICBSZWdhcmRpbmcg dGhlIEFQUyBtb2RlIGFuZCBzdWItY2FwYWJpbGl0aWVzIC0gWW91IGRlc2NyaWJlIGluIHNlY3Rp b24gOS4xIGhvdyBhbiBMRVIgY2FuIGRlY2xhcmUgaXRzZWxmIHRvIHN1cHBvcnQgb25seSBzb21l IG9mIHRoZSBjYXBhYmlsaXRpZXMgaW50cm9kdWNlZCBpbiB0aGUgZHJhZnQsIGFuZCB0aGVuIGRl c2NyaWJlIHRoZSBBUFMgIm1vZGUiIChTZWN0aW9uIDkuMi4yKSBhcyBkZWNsYXJhdGlvbiBvZiBz dXBwb3J0IGZvciBhbGwgb2YgdGhlIGNhcGFiaWxpdGllcywgaS5lLiBGbGFncyA9IDB4RjgwMDAw MDAuIEZyb20gdGhpcyBwb2ludCBvbiAoaW4gcGFydGljdWxhciBzZWN0aW9uIDExKSwgeW91IGRl c2NyaWJlIHRoZSBmdW5jdGlvbmFsaXR5IGZvciBMRVIgdGhhdCBkZWNsYXJlIEZsYWdzPSBlaXRo ZXIgMHgwLCBvciAweEY4MDAwMDAwLCBob3dldmVyLCB0aGVyZSBpcyBubyBleHBsYW5hdGlvbiBm b3IgcGF0aHMgdGhhdCBkZWNsYXJlIHNvbWUgb3RoZXIgdmFsdWUgb2YgRmxhZ3MgKGZvciBleGFt cGxlLCAweDgwMDAwMDAgLSBzdXBwb3J0aW5nIG9ubHkgdGhlIEVYRVIgZnVuY3Rpb25hbGl0eSku IElzIHRoZXJlIGEgcmVhc29uIGZvciB0aGlzPyBBcmUgd2UgYXNzdW1pbmcgdGhhdCBhbGwgcGF0 aHMgd2lsbCBlaXRoZXIgc3VwcG9ydCBQU0Mgb3IgQVBTIG1vZGVzIG9ubHk/IElmIHNvLCB3aHkg bm90IGp1c3QgaGF2ZSB0d28gdmFsdWVzIGZvciBGbGFncyByYXRoZXIgdGhhbiB0aGlzIGV4dGVu c2libGUgYml0IG1hcCB2YWx1ZT8NCiAgNi4gIFJlZ2FyZGluZyAiUFNDIHNlc3Npb25zIiAtIElu IHNlY3Rpb24gOS4zIHlvdSBpbnRyb2R1Y2UgYSBuZXcgY29uY2VwdCBvZiBQU0Mgc2Vzc2lvbiwg d2l0aG91dCBhbnkgZGVmaW5pdGlvbiBvZiB3aGVuIHRoaXMgc2Vzc2lvbiBiZWdpbnMgb3IgZW5k cy4gQ291bGQgeW91IGVsYWJvcmF0ZSBvbiB3aGF0IGlzIG1lYW50IGJ5IHRoZSAibGlmZSBvZiBh IFBTQyBzZXNzaW9uIj8gVW50aWwgbm93LCBJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0 IGxpbmVhciBwcm90ZWN0aW9uIHN0YXJ0ZWQgd2l0aCB0aGUgY3JlYXRpb24gb2YgdGhlIHByb3Rl Y3Rpb24gZG9tYWluIGFuZCBjb250aW51ZWQgdW50aWwgdGhlIHBhdGhzIHdlcmUgdG9ybiBkb3du LiBJcyB0aGlzIGluY29ycmVjdD8NCiAgNy4gIFRoZXJlIGlzIGEgc3RhdGVtZW50IGluIHRoZSBz ZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gOS4zIHRoYXQgc3RhdGVzICJSRkM2Mzc4IGRvZXMg bm90IGRlZmluZSBob3cgdG8gaGFuZGxlIGFuIHVucmVjb2duaXplZCBUTFYuIiBBY3R1YWxseSwg d2hhdCBSRkM2Mzc4IGRlZmluZXMgaXMgInRoZXJlIGFyZSBubyBUTFYgdW5pdHMgZGVmaW5lZCBm b3IgdGhlIGJhc2ljIFBTQyBvcGVyYXRpb24iIGFuZCB0aGVyZWZvcmUgdGhlIFRMVnMgYXJlIGln bm9yZWQuIEFub3RoZXIgcmVhc29uLCBJTU8sIHRvIGNoYW5nZSB0aGUgdmVyc2lvbiBudW1iZXIg b2YgdGhlIHByb3RvY29sIGluIHRoaXMgZHJhZnQuDQogIDguICBJdCBpcyB1bmNsZWFyIHRvIG1l IC0gd2h5IHdoZW4gcmVjZWl2aW5nIGEgU0QtUCBpbmRpY2F0aW9uIGluIE5vcm1hbCB3aHkgeW91 IGNvbnNpZGVyIHRoaXMgdG8gYmUgIlVuYXZhaWFibGUiIHNpbmNlIHRoZSBhY3Rpb24gdGFrZW4g Zm9yIGFuIFNEIHNpdHVhdGlvbiBpcyB0byBwb3NzaWJseSB0cmFuc21pdCBvbiBib3RoIFcgJiBQ Lg0KDQpJIHBsYW4gb24gc3VibWl0dGluZyBzb21lIGVkaXRvcmlhbCBjb21tZW50cyBpbiBhIGZ1 dHVyZSBwb3N0LCBidXQgd291bGQgbGlrZSB0byBnZXQgc29tZSBjbGFyaWZpY2F0aW9uIG9uIHRo ZXNlIHBvaW50cyBiZWZvcmUgdGhlIGRyYWZ0IGFkdmFuY2VzIHRvIGFjY2VwdGFuY2UuDQoNClRo YW54LA0KeWFhY292DQoNCg0KT24gTW9uLCBKYW4gMjAsIDIwMTQgYXQgNDoyOCBBTSwgTG9hIEFu ZGVyc3NvbiA8bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+PiB3cm90ZToNCldvcmtpbmcgR3Jv dXAsDQoNClRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBvbg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUuDQoNClBsZWFzZSBmaW5kIHRoZSBkb2N1 bWVudCBhdDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBs cy10cC1wc2MtaXR1Lw0KDQpUaGUgZG9jdW1lbnQgZWRpdG9ycyBoYXMgYWxzbyBzdXBwbGllZCBh ICJkaWZmLWxpc3QiIGJldHdlZW4NCnZlcnNpb24gLTAwIGFuZCAtMDEgYXQ6DQpodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzExMzM4Lmh0bWwNCg0K SVRVLVQgU0cxNSBoYXMgYWR2aXNlZCB1cyB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgYSBuZWNlc3Nh cnkgcmVmZXJlbmNlDQpmb3IgZG9jdW1lbnRzIHRoYXQgaXMgcGxhbm5lZCB0byBnbyBpbnRvIHRo ZSBJVFUtVCBhcHByb3ZhbCBwcm9jZXNzDQpmcm9tIHRoZSBTRzE1IG1lZXRpbmcgZW5kIG9mIE1h cmNoIC8gYmVnaW5uaW5nIG9mIEFwcmlsLiBFZGl0b3JzLA0KYXV0aG9ycyBhbmQgY2hhaXJzIGhh cyBwdXQgaW4gcXVpdGUgYW4gZWZmb3J0IHRvIG1ha2UgdGhpcyBkb2N1bWVudA0KcmVhZHkuIFRo ZSBzY2hlZHVsZSBpcyB2ZXJ5IHRpZ2h0Lg0KDQpXZSBhcmUgbm93IGRvaW5nIHNldmVyYWwgcmV2 aWV3IHN0ZXBzIGluIHBhcmFsbGVsDQoNCi0gdGhlIG5vcm1hbCB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCwgcGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUNCiAgbXBscyB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pDQot IHRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQg b2YgdGhlDQogIG1wbHMtcnQgcmV2aWV3LCBub3JtYWxseSB3ZSBkbyBhIHdnIGNoYWlyIHJldmll dyBiZWZvcmUgc3RhcnRpbmcgdGhlDQogIHdnbGMsIHRoaXMgcmV2aWV3IHdpbGwgbm93IHRha2Ug cGxhY2UgaW4gcGFyYWxsZWwNCi0gYWZ0ZXIgdGhlIHdnbGMgYW5kIHB1YmxpY2F0aW9uIHJlcXVl c3QgdGhlcmUgaXMgYW4gQUQgZXZhbHVhdGlvbiwNCiAgdGhpcyB3aWxsIG5vdyBhbHNvIHRha2Ug cGxhY2UgaW4gcGFyYWxsZWwgd2l0aCB0aGUgd2dsYw0KDQpUaGUgZWRpdG9ycyBhbmQgYXV0aG9y cyBhcmUgYWR2aXNlZCB0byB0cnkgdG8gcmVzb2x2ZSBhcyBtYW55IG9mIHRoZQ0KY29tbWVudHMg YXMgcG9zc2libGUgKG9uIHRoZSBtYWlsaW5nIGxpc3QpIGFzIHRoZXkgY29tZSBpbiwgYnV0IG5v dCB0bw0KcG9zdCB0aGUgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHVudGlsIHRoZSB3Z2xjIGlz IGNsb3NlZCBhbmQgdGhlDQpjb21tZW50cyBhcmUgcmVzb2x2ZWQuDQoNClRoaXMgd29ya2luZyBn cm91cCBsYXN0IGNhbGwgZW5kcyBGZWJydWFyeSAzcmQuDQoNCi9Mb2ENCmZvciB0aGUgTVBMUyBX RyBjby1jaGFpcnMNCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAg IGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNv bT4NClNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51 PG1haWx0bzpsb2FAcGkubnU+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAg cGhvbmU6ICs0NiA3MzkgODEgMjEgNjQ8dGVsOiUyQjQ2JTIwNzM5JTIwODElMjAyMSUyMDY0Pg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFp bGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQotLQ0KVGhhbnggYW5kIEJS LA0KeWFhY292DQoNClN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eQ0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3C3ASMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5ZYWFjb3YsPC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCI+VGhhbmsgeW91IHNvIG11Y2ggZm9yIHlvdXIgcmV2aWV3LjwvZGl2Pg0KPGRpdiBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiPkJlZm9yZSBJIGdvIHRocm91Z2ggeW91ciBjb21tZW50cywg d2hpY2ggbWF5IHRha2Ugc29tZSB0aW1lLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPkkgd291bGQgbGlrZSB0byByZXNwb25kIHRvIHRoZSBiYXNpYyBxdWVzdGlvbiByZWdh cmRpbmcgdGhlIHZlcnNpb24gbnVtYmVyIGluIHRoaXMgZW1haWwuPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCI+WW91IGhhdmUgZXhhY3RseSB0aGUgc2FtZSB0aG91Z2h0IG9uIHRoZSB2ZXJzaW9u IG51bWJlciZuYnNwO2FzIEkgaGF2ZS4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPkFsc28sIGNoYW5naW5nIHRoZSB2ZXJzaW9uIG51bWJlciBjYW4gZWxpbWluYXRlIGFs bCZuYnNwO3RoZSBoYXNzbGVzIHdpdGggdGhlIENhcGFiaWxpdGllcyBUTFZzIGluIFNlY3Rpb24g OS48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5JbiB0aGUgZWFybHkgc3RhZ2UmbmJzcDtvZiB0 aGlzIHdvcmssIHRoZXJlIHdhcyZuYnNwO2FuIGFyZ3VtZW50IHRvIHRyZWF0Jm5ic3A7ZWFjaCBv ZiB0aG9zZSBmaXZlIGNhcGFiaWxpdGllcyBpbmRpdmlkdWFsbHksPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+c28gdGhhdCBhbnkgY2hhbmdlcyZuYnNwO2luIFJGQzYzNzgm bmJzcDtjYW4gYmUgc2VlbiBhcyBvcGlvbmFsIGZlYXR1cmVzLA0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+VGhpcyBtYXkgc291bmQgb2sgaW4gZ2VuZXJhbCwgPC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+YnV0IGNvbnNpZGVyaW5nIHRoZSBuYXR1 cmUgb2YgdGhlJm5ic3A7cHJvdGVjdGlvbiBzd2l0Y2hpbmcsIGl0IGRvZXMgbm90IG1ha2UgYW55 IHNlbnNlLg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+RXZlbiB0aG91 Z2ggdGhlIGlkZWEgb2YgdHJlYXRpbmcgdGhlbSBhcyBpbmRpdmlkdWFscyZuYnNwO2lzIHJlZmxl Y3RlZCBpbiBjdXJyZW50IGRyYWZ0LiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiPkkgc3RpbGwgYmVsaWV2ZSB0aGF0IHRoZSBjaGFuZ2UmbmJzcDtvZiB2ZXJzaW9u IG51bWJlciBpcyZuYnNwO2EgZmFyLWJldHRlciBzb2x1dGlvbi48L2Rpdj4NCjxkaXYgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0Ij5JZiZuYnNwO3NvbWVib2R5IHdhbnRzJm5ic3A7YW55IG9uZSBvZiBwcmlvcml0eSBt b2RpZmljYXRpb24gY2FwYWJpbGl0eSZuYnNwO2FuZCBub24tcmV2ZXJ0aXZlJm5ic3A7YmVoYXZp b3IgY2FwYWJpbGl0eSwmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0 Ij5hIHRvdGFsbHkgZGlmZmVyZW50Jm5ic3A7cHJvdG9jb2wgaW1wbGVtZW50YXRpb24gKHByaW9y aXR5IGxvZ2ljIGFuZCBzdGF0ZSBtYWNoaW5lKSBzaG91bGQgYmUgZGV2aXNlZC4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPlRoZXJlIGlzIG5vIHdheSB5b3UgY2FuIGNo YW5nZSB0aGUgQ2FwYWJpbGl0aWVzIHNldCB1bmxlc3MgeW91IGhhdmUgYSZuYnNwO2RpZmZlcmVu dCBzZXQgb2YgcHJpb3JpdHkgZXZhbHVhdGlvbiBhbmQmbmJzcDtzdGF0ZSBtYWNoaW5lLA0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+aS5lLiwgYSBkaWZmZXJlbnQgUFND IHByb2Nlc3MuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SW4gdGhlIGNh c2UgYW4gb3BlcmF0b3IgZG9lc24ndCB3YW50IHRvIHVzZSBhbnkgb2YmbmJzcDtTRCwgTVMtVyZu YnNwO2FuZCBFWEVSIGNhcGFiaWxpdGllcywmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij53aGF0Jm5ic3A7dGhlIG9wZXJhdG9yIGNhbiZuYnNwO3NpbXBseSBkbyZu YnNwO2lzIGp1c3QmbmJzcDtkaXNhYmxpbmcgdGhlIGlucHV0IHRyaWdnZXIuJm5ic3A7PC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SSBkb24ndCBzZWUgYW55IHZhbHVlIG9m IGludHJvZHVjaW5nIHRoZSBDYXBhYmlsaXRpZXMgVExWLCB3aGljaCBqdXN0IGNvbXBsaWNhdGVz IHRoZSBwcm90b2NvbCBvcGVyYXRpb24uPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SWYgd2Ug ZGVjaWRlIHRvJm5ic3A7Y2hhbmdlIHRoZSB2ZXJzaW9uIG51bWJlciZuYnNwO2FuZCBlbGltaW5h dGUgQ2FwYWJpbGl0aWVzIFRMViwNCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPnRoZXJlIG1heSBiZSBzb21lJm5ic3A7ZWRpdGluZyBqb2IuIEJ1dCwmbmJzcDtpdCBpcyB3 ZWxsIHdvcnRoIHRoZSBjaGFuZ2UuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+QmVzdCByZWdh cmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRvbmc8L2Rpdj4NCjxkaXYgc3R5 bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDsmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0IiBpZD0iTWFpbFNpZ24iPjxicj4NCiZuYnNwOzwvZGl2Pg0KPGRpdiBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48Yj5Gcm9tIDogPC9iPiZxdW90O1lhYWNvdiBX ZWluZ2FydGVuJnF1b3Q7ICZsdDt3eWFhY292QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TZW50IDog PC9iPjIwMTQtMDEtMjggMDU6MTI6MTYgKCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5M b2EgQW5kZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7PGJyPg0KPGI+Q2MgOiA8L2I+bXBsc0BpZXRm Lm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssIG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnICZs dDttcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyZndDssIGRyYWZ0LWlldGYtbXBscy10cC1wc2Mt aXR1QHRvb2xzLmlldGYub3JnICZsdDtkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5p ZXRmLm9yZyZndDssDQo8TVBMUy1BRFNAVE9PTFMuSUVURi5PUkc+Jmx0O21wbHMtYWRzQHRvb2xz LmlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3QgOiA8L2I+UmU6IFttcGxzXSB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMTxicj4NCjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGRpcj0ibHRyIj5IaSBhbGwsDQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGhhdmUgcmVhZCB0aHJvdWdoIHRoZSBsYXRlc3QgdmVy c2lvbiBvZiB0aGlzIGRyYWZ0IGFuZCBoYXZlIGEgbnVtYmVyIG9mIGNvbW1lbnRzIGFuZCBxdWVz dGlvbnMgcmVnYXJkaW5nIHRoaXMgZG9jdW1lbnQuIFdoaWxlLCBpbiBnZW5lcmFsLCBJIGZlZWwg dGhhdCB0aGUgZXh0ZW5zaW9ucyB0byB0aGUgYmVoYXZpb3Igb2YgUkZDNjM3OCBhcmUgYXBwcm9w cmlhdGUsIEkgZmluZCB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgc3RpbGwgaW4gbmVlZA0KIG9mIHJl ZmluZW1lbnQgaW4gaXRzIGxhbmd1YWdlIGFuZCBjbGFyaXR5IG9mIHRoZSBmdW5jdGlvbmFsaXR5 LiBXaGlsZSBzb21lIG9mIHRoZSBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgaXMgZGVzY3JpYmVk LCB0aGVyZSBhcmUgZGlmZmVyZW50IGNhc2VzIG9mIHRoZSBmdW5jdGlvbmFsaXR5IHRoYXQgaXMg ZWl0aGVyIG5vdCBkZXNjcmliZWQgb3IgaXMgcmF0aGVyIGNvbmZ1c2luZy48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pk9uZSBiYXNpYyBxdWVzdGlvbiBpcyAtIENvbnNpZGVyaW5nIHRo YXQgdGhpcyBkcmFmdCBpcyBwcm9wb3NpbmcgY2hhbmdlcyB0byB0aGUgYmFzaWMgb3BlcmF0aW9u IG9mIHRoZSBQU0MgcHJvdG9jb2wsIExvY2FsIFJlcXVlc3QgTG9naWMsIGFuZCB0aGUgUFNDIENv bnRyb2wgTG9naWMsIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgdGhlIFBTQyBWZXJzaW9uIG51 bWJlciBzaG91bGQgY2hhbmdlISBXaHkgdGhlbiwgaXMgdGhlcmUgbm8gbWVudGlvbg0KIG9mIGNo YW5naW5nIHRoZSB2ZXJzaW9uIHRvIGFsbG93IG5ldHdvcmtzIHRoYXQgc3VwcG9ydCB0aGUgZnVu Y3Rpb25hbGl0eSBkZXNjcmliZWQgaW4gUkZDNjM3OCB0byBjb250aW51ZSB0byBvcGVyYXRlPzwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkaW5nIHRoZSBmdW5jdGlvbmFsaXR5 IHByb3Bvc2VkIGluIHRoZSBkcmFmdCwgSSBoYXZlIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zIGFu ZCBjb21tZW50cyAtPC9kaXY+DQo8ZGl2Pg0KPG9sPg0KPGxpPihmb3IgY2xhcmlmaWNhdGlvbikg UmVnYXJkaW5nIHRoZSBmdW5jdGlvbmFsaXR5IG9mIE1TLVcsIHdoYXQgaXMgdGhlIGZ1bmN0aW9u YWxpdHkgaWYgdGhlIGRhdGEtdHJhZmZpYyBpcyBjdXJyZW50bHkgb24gdGhlIHdvcmtpbmcgcGF0 aD8gU2luY2UgdGhlIHB1cnBvc2Ugb2YgdGhlIGNvbW1hbmQgaXMgdG8gbW92ZSB0aGUgdHJhZmZp YyB0byB0aGUgd29ya2luZyBwYXRoLCBzaG91bGRuJ3QgaXQgYmUgaWdub3JlZD8gSG93ZXZlciwg YWNjb3JkaW5nDQogdG8gdGhlIFN0YXRlIFRyYW5zaXRpb24gVGFibGUgaW4gc2VjdGlvbiAxMS4x IC0gaWYgdGhlIE1TLVcgaXMgcmVjZWl2ZWQgYnkgYSBMRVIgaW4gTm9ybWFsIFN0YXRlIGl0IHRy YW5zZmVycyB0byBTd2l0Y2hpbmcgQWRtaW5pc3RyYXRpdmUgU3RhdGUhIFRoZSBtYWluIGVmZmVj dCBzZWVtcyB0byBiZSB0byBjYXVzZSB0aGUgTEVSIHRvIGlnbm9yZSBpbmNvbWluZyBNUyBhbmQg RVhFUiByZXF1ZXN0cyAodGhhdCBhcmUgbm90IGlnbm9yZWQgaW4gTm9ybWFsDQogU3RhdGUpLiA8 L2xpPjxsaT5SZWdhcmRpbmcgdGhlIFNEIGZ1bmN0aW9uYWxpdHkgLSBhZnRlciBhIHByZXZpb3Vz IGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCB0aGUgZnVuY3Rpb25hbGl0eSB3aGVuIHBy b3RlY3RpbmcgZm9yIFNEIHNpdHVhdGlvbnMgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMykgd2Fz IGNoYW5nZWQgdG8gZXNzZW50aWFsbHkgc3dpdGNoIG92ZXIgdG8gdGhlIExFUiB0cmFuc21pdHRp bmcgdGhlIHBhY2tldHMgb24gYm90aCB0aGUgd29ya2luZw0KIGFuZCBwcm90ZWN0aW9uIHBhdGhz IChlc3NlbnRpYWxseSAxJiM0MzsxIHRyYW5zbWlzc2lvbikuIEhvd2V2ZXIsIHRoZXJlIGlzIHZl cnkgbGl0dGxlIGRpc2N1c3Npb24gb2YgaG93IHRoZSByZWNlaXZpbmcgTEVSIGlzIHN1cHBvc2Vk IHRvIHNlbGVjdCB0aGUgaW5jb21pbmcgcGFja2V0cyB3aGlsZSBhdm9pZGluZyBkdXBsaWNhdGlv biBvZiBkYXRhLiBDb3VsZCBwbGVhc2UgZWxhYm9yYXRlIG9uIHRoaXM/DQo8L2xpPjxsaT5SZWdh cmRpbmcgdGhlIFNEIGZ1bmN0aW9uYWxpdHkgLSBhcyBtZW50aW9uZWQgaW4gdGhlIHByZXZpb3Vz IHBvaW50LCB3aGVuIHByb3RlY3RpbmcgZm9yIFNELCB0aGUgdHJhbnNtaXR0aW5nIExFUiBkdXBs aWNhdGVzIHRoZSBwYWNrZXRzIG9uIGJvdGggVyAmYW1wOyBQIGFuZCB0aGUgcmVjZWl2aW5nIExF UiwgcHJlc3VtYWJseSwgcmVhZHMgdGhlIGRhdGEgZnJvbSBlaXRoZXIgcGF0aCwgYW5kIG1heSBj aG9vc2UgZGlmZmVyZW50bHkgZm9yIGRpZmZlcmVudA0KIHBhY2tldHMuIEhvd2V2ZXIsIGxhdGVy IGluIHNlY3Rpb24gNy40IChhbmQgYWdhaW4gaW4gc2VjdGlvbiAxMC4yKSB5b3UgaW50cm9kdWNl IGEgbmV3IGNvbmNlcHQgb2YgJnF1b3Q7c3RhbmRieSBwYXRoJnF1b3Q7IGFzICZxdW90O3RoZSBw YXRoIGZyb20gd2hpY2ggdGhlIHNlbGVjdG9yIGRvZXMgbm90IHNlbGVjdCB0aGUgdXNlciBkYXRh IHRyYWZmaWMmcXVvdDsgaW4gcmVnYXJkIHRvIGRldGVybWluaW5nIHRoZSBwcmlvcml0eSBvZiAm cXVvdDtjb25mbGljdGluZyZxdW90OyBTRC1XIGFuZCBTRC1QDQogdHJpZ2dlcnMuIENhbiB5b3Ug Y2xhcmlmeSB3aGljaCBvZiB0aGUgdHdvIHBhdGhzIHRoYXQgYXJlIGJvdGggY2FycnlpbmcgdXNl ciBkYXRhIGlzIHRoZSBzdGFuZGJ5IHBhdGg/DQo8L2xpPjxsaT5GdXJ0aGVyIHJlZ2FyZGluZyB0 aGUgcG9pbnQgb2YgJnF1b3Q7Y29uZmxpY3RpbmcmcXVvdDsgU0QgdHJpZ2dlcnMgLSBzaW5jZSB0 aGUgcHJvdGVjdGlvbiBmdW5jdGlvbmFsaXR5IG9mIFNEIGlzIHRvIGR1cGxpY2F0ZSB0aGUgZGF0 YSBvbiBib3RoIFcgJmFtcDsgUCAtIHdoeSBpcyB0aGlzIGNvbnNpZGVyZWQgYSBjb25mbGljdCwg c2luY2UgdGhlIGFjdGlvbiBmb3IgYm90aCB3aWxsIGJlIGlkZW50aWNhbCAtIGNvbnRpbnVlIHRy YW5zbWl0dGluZyBvbiBib3RoIFcNCiAmYW1wOyBQLiBTb21lIG1vcmUgY2xhcmlmaWNhdGlvbiB3 b3VsZCBoZWxwLiA8L2xpPjxsaT5SZWdhcmRpbmcgdGhlIEFQUyBtb2RlIGFuZCBzdWItY2FwYWJp bGl0aWVzIC0gWW91IGRlc2NyaWJlIGluIHNlY3Rpb24gOS4xIGhvdyBhbiBMRVIgY2FuIGRlY2xh cmUgaXRzZWxmIHRvIHN1cHBvcnQgb25seSBzb21lIG9mIHRoZSBjYXBhYmlsaXRpZXMgaW50cm9k dWNlZCBpbiB0aGUgZHJhZnQsIGFuZCB0aGVuIGRlc2NyaWJlIHRoZSBBUFMgJnF1b3Q7bW9kZSZx dW90OyAoU2VjdGlvbiA5LjIuMikgYXMgZGVjbGFyYXRpb24gb2Ygc3VwcG9ydCBmb3IgYWxsDQog b2YgdGhlIGNhcGFiaWxpdGllcywgaS5lLiBGbGFncyA9IDB4RjgwMDAwMDAuIEZyb20gdGhpcyBw b2ludCBvbiAoaW4gcGFydGljdWxhciBzZWN0aW9uIDExKSwgeW91IGRlc2NyaWJlIHRoZSBmdW5j dGlvbmFsaXR5IGZvciBMRVIgdGhhdCBkZWNsYXJlIEZsYWdzPSBlaXRoZXIgMHgwLCBvciAweEY4 MDAwMDAwLCBob3dldmVyLCB0aGVyZSBpcyBubyBleHBsYW5hdGlvbiBmb3IgcGF0aHMgdGhhdCBk ZWNsYXJlIHNvbWUgb3RoZXIgdmFsdWUgb2YgRmxhZ3MNCiAoZm9yIGV4YW1wbGUsIDB4ODAwMDAw MCAtIHN1cHBvcnRpbmcgb25seSB0aGUgRVhFUiBmdW5jdGlvbmFsaXR5KS4gSXMgdGhlcmUgYSBy ZWFzb24gZm9yIHRoaXM/IEFyZSB3ZSBhc3N1bWluZyB0aGF0IGFsbCBwYXRocyB3aWxsIGVpdGhl ciBzdXBwb3J0IFBTQyBvciBBUFMgbW9kZXMgb25seT8gSWYgc28sIHdoeSBub3QganVzdCBoYXZl IHR3byB2YWx1ZXMgZm9yIEZsYWdzIHJhdGhlciB0aGFuIHRoaXMgZXh0ZW5zaWJsZSBiaXQgbWFw IHZhbHVlPw0KPC9saT48bGk+UmVnYXJkaW5nICZxdW90O1BTQyBzZXNzaW9ucyZxdW90OyAtIElu IHNlY3Rpb24gOS4zIHlvdSBpbnRyb2R1Y2UgYSBuZXcgY29uY2VwdCBvZiBQU0Mgc2Vzc2lvbiwg d2l0aG91dCBhbnkgZGVmaW5pdGlvbiBvZiB3aGVuIHRoaXMgc2Vzc2lvbiBiZWdpbnMgb3IgZW5k cy4gQ291bGQgeW91IGVsYWJvcmF0ZSBvbiB3aGF0IGlzIG1lYW50IGJ5IHRoZSAmcXVvdDtsaWZl IG9mIGEgUFNDIHNlc3Npb24mcXVvdDs/IFVudGlsIG5vdywgSSB3YXMgdW5kZXIgdGhlIGltcHJl c3Npb24NCiB0aGF0IGxpbmVhciBwcm90ZWN0aW9uIHN0YXJ0ZWQgd2l0aCB0aGUgY3JlYXRpb24g b2YgdGhlIHByb3RlY3Rpb24gZG9tYWluIGFuZCBjb250aW51ZWQgdW50aWwgdGhlIHBhdGhzIHdl cmUgdG9ybiBkb3duLiBJcyB0aGlzIGluY29ycmVjdD8NCjwvbGk+PGxpPlRoZXJlIGlzIGEgc3Rh dGVtZW50IGluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gOS4zIHRoYXQgc3RhdGVz ICZxdW90O1JGQzYzNzggZG9lcyBub3QgZGVmaW5lIGhvdyB0byBoYW5kbGUgYW4gdW5yZWNvZ25p emVkIFRMVi4mcXVvdDsgQWN0dWFsbHksIHdoYXQgUkZDNjM3OCBkZWZpbmVzIGlzICZxdW90O3Ro ZXJlIGFyZSBubyBUTFYgdW5pdHMgZGVmaW5lZCBmb3IgdGhlIGJhc2ljIFBTQyBvcGVyYXRpb24m cXVvdDsgYW5kIHRoZXJlZm9yZSB0aGUgVExWcyBhcmUNCiBpZ25vcmVkLiBBbm90aGVyIHJlYXNv biwgSU1PLCB0byBjaGFuZ2UgdGhlIHZlcnNpb24gbnVtYmVyIG9mIHRoZSBwcm90b2NvbCBpbiB0 aGlzIGRyYWZ0Lg0KPC9saT48bGk+SXQgaXMgdW5jbGVhciB0byBtZSAtIHdoeSB3aGVuIHJlY2Vp dmluZyBhIFNELVAgaW5kaWNhdGlvbiBpbiBOb3JtYWwgd2h5IHlvdSBjb25zaWRlciB0aGlzIHRv IGJlICZxdW90O1VuYXZhaWFibGUmcXVvdDsgc2luY2UgdGhlIGFjdGlvbiB0YWtlbiBmb3IgYW4g U0Qgc2l0dWF0aW9uIGlzIHRvIHBvc3NpYmx5IHRyYW5zbWl0IG9uIGJvdGggVyAmYW1wOyBQLjwv bGk+PC9vbD4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+SSBwbGFuIG9uIHN1Ym1p dHRpbmcgc29tZSBlZGl0b3JpYWwgY29tbWVudHMgaW4gYSBmdXR1cmUgcG9zdCwgYnV0IHdvdWxk IGxpa2UgdG8gZ2V0IHNvbWUgY2xhcmlmaWNhdGlvbiBvbiB0aGVzZSBwb2ludHMgYmVmb3JlIHRo ZSBkcmFmdCBhZHZhbmNlcyB0byBhY2NlcHRhbmNlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+VGhhbngsPC9kaXY+DQo8ZGl2PnlhYWNvdjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8YnI+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBKYW4gMjAsIDIwMTQgYXQgNDoyOCBBTSwgTG9h IEFuZGVyc3NvbiA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5u dSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8 YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkOyBNQVJHSU46IDBw eCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4N CldvcmtpbmcgR3JvdXAsPGJyPg0KPGJyPg0KVGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPGJyPg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUu PGJyPg0KPGJyPg0KUGxlYXNlIGZpbmQgdGhlIGRvY3VtZW50IGF0Ojxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1 LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHU+PC91PmRv Yy9kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLTx1PjwvdT5pdHUvPC9hPjxicj4NCjxicj4NClRoZSBk b2N1bWVudCBlZGl0b3JzIGhhcyBhbHNvIHN1cHBsaWVkIGEgJnF1b3Q7ZGlmZi1saXN0JnF1b3Q7 IGJldHdlZW48YnI+DQp2ZXJzaW9uIC0wMCBhbmQgLTAxIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMTEzMzguaHRt bCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC08dT48L3U+YXJjaGl2 ZS93ZWIvbXBscy9jdXJyZW50Lzx1PjwvdT5tc2cxMTMzOC5odG1sPC9hPjxicj4NCjxicj4NCklU VS1UIFNHMTUgaGFzIGFkdmlzZWQgdXMgdGhhdCB0aGlzIGRvY3VtZW50IGlzIGEgbmVjZXNzYXJ5 IHJlZmVyZW5jZTxicj4NCmZvciBkb2N1bWVudHMgdGhhdCBpcyBwbGFubmVkIHRvIGdvIGludG8g dGhlIElUVS1UIGFwcHJvdmFsIHByb2Nlc3M8YnI+DQpmcm9tIHRoZSBTRzE1IG1lZXRpbmcgZW5k IG9mIE1hcmNoIC8gYmVnaW5uaW5nIG9mIEFwcmlsLiBFZGl0b3JzLDxicj4NCmF1dGhvcnMgYW5k IGNoYWlycyBoYXMgcHV0IGluIHF1aXRlIGFuIGVmZm9ydCB0byBtYWtlIHRoaXMgZG9jdW1lbnQ8 YnI+DQpyZWFkeS4gVGhlIHNjaGVkdWxlIGlzIHZlcnkgdGlnaHQuPGJyPg0KPGJyPg0KV2UgYXJl IG5vdyBkb2luZyBzZXZlcmFsIHJldmlldyBzdGVwcyBpbiBwYXJhbGxlbDxicj4NCjxicj4NCi0g dGhlIG5vcm1hbCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCwgcGxlYXNlIHNlbmQgeW91ciBjb21t ZW50cyB0byB0aGU8YnI+DQombmJzcDsgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCAo PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYu b3JnPC9hPik8YnI+DQotIHRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyByZXZpZXdlZCB0aGlzIGRv Y3VtZW50IGFzIHBhcnQgb2YgdGhlPGJyPg0KJm5ic3A7IG1wbHMtcnQgcmV2aWV3LCBub3JtYWxs eSB3ZSBkbyBhIHdnIGNoYWlyIHJldmlldyBiZWZvcmUgc3RhcnRpbmcgdGhlPGJyPg0KJm5ic3A7 IHdnbGMsIHRoaXMgcmV2aWV3IHdpbGwgbm93IHRha2UgcGxhY2UgaW4gcGFyYWxsZWw8YnI+DQot IGFmdGVyIHRoZSB3Z2xjIGFuZCBwdWJsaWNhdGlvbiByZXF1ZXN0IHRoZXJlIGlzIGFuIEFEIGV2 YWx1YXRpb24sPGJyPg0KJm5ic3A7IHRoaXMgd2lsbCBub3cgYWxzbyB0YWtlIHBsYWNlIGluIHBh cmFsbGVsIHdpdGggdGhlIHdnbGM8YnI+DQo8YnI+DQpUaGUgZWRpdG9ycyBhbmQgYXV0aG9ycyBh cmUgYWR2aXNlZCB0byB0cnkgdG8gcmVzb2x2ZSBhcyBtYW55IG9mIHRoZTxicj4NCmNvbW1lbnRz IGFzIHBvc3NpYmxlIChvbiB0aGUgbWFpbGluZyBsaXN0KSBhcyB0aGV5IGNvbWUgaW4sIGJ1dCBu b3QgdG88YnI+DQpwb3N0IHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgdW50aWwgdGhlIHdn bGMgaXMgY2xvc2VkIGFuZCB0aGU8YnI+DQpjb21tZW50cyBhcmUgcmVzb2x2ZWQuPGJyPg0KPGJy Pg0KVGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIEZlYnJ1YXJ5IDNyZC48YnI+DQo8 YnI+DQovTG9hPGJyPg0KZm9yIHRoZSBNUExTIFdHIGNvLWNoYWlyczxzcGFuIGNsYXNzPSJIT0Vu WmIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij48YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2Eg QW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZW1haWw6IDxhIGhyZWY9Im1haWx0 bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmxvYUBtYWlsMDEuaHVh d2VpLmNvbTwvYT48YnI+DQpTZW5pb3IgTVBMUyBFeHBlcnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxv YUBwaS5udTwvYT48YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAmbmJzcDsg Jm5ic3A7IHBob25lOiA8YSBocmVmPSJ0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHRh cmdldD0iX2JsYW5rIiB2YWx1ZT0iJiM0Mzs0NjczOTgxMjE2NCI+DQomIzQzOzQ2IDczOSA4MSAy MSA2NDwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188dT48L3U+X19fX19f X19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpt cGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx1PjwvdT5saXN0aW5mby9tcGxz PC9hPjxicj4NCjwvZm9udD48L3NwYW4+PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnIg Y2xlYXI9ImFsbCI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KLS0gPGJyPg0KPGRpdiBkaXI9Imx0ciI+ VGhhbnggYW5kIEJSLA0KPGRpdj55YWFjb3Y8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PjxpPlN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eTwvaT48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3C3ASMTP2etriinfo_-- From curtis@ipv6.occnc.com Mon Jan 27 18:23:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036621A008F for ; Mon, 27 Jan 2014 18:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkkYDBgbJK_j for ; Mon, 27 Jan 2014 18:23:50 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEB61A0171 for ; Mon, 27 Jan 2014 18:23:50 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S2NgVH000747; Mon, 27 Jan 2014 21:23:42 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280223.s0S2NgVH000747@maildrop2.v6ds.occnc.com> To: l.wood@surrey.ac.uk From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 23:18:56 +0000." <290E20B455C66743BE178C5C84F1240847E63346F7@EXMB01CMS.surrey.ac.uk> Date: Mon, 27 Jan 2014 21:23:42 -0500 Cc: mpls@ietf.org, ietf@ietf.org, touch@isi.edu, joelja@bogus.com Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 02:23:52 -0000 In message <290E20B455C66743BE178C5C84F1240847E63346F7@EXMB01CMS.surrey.ac.uk> l.wood@surrey.ac.uk writes: > > "ASICs can't do IPv6 in hardware! IPv6 can only be done with slow > software forwarding! We're stuck with v4!" > > I think we've been here before. > > Lloyd Wood > http://about.me/lloydwood At what point does this discussion no longer have any relevance at all to draft-ietf-mpls-in-udp? The draft is going to say SHOULD wrt UDP checksums. If you have an issue with the wording of the draft, please comment on the draft. Curtis > ________________________________________ > From: mpls [mpls-bounces@ietf.org] On Behalf Of Joe Touch [touch@isi.edu] > Sent: 27 January 2014 19:24 > To: Joel M. Halpern; joel jaeggli; stbryant@cisco.com > Cc: mpls@ietf.org; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > On 1/27/2014 11:19 AM, Joel M. Halpern wrote: > > Yes Joe, routers could ahve been built to do those calcualtions at that > > performance scale. > > There are however two major problems: > > > > 1) That is not how routers are built. > > 2) The target performance scale is rather higher. > > > > So could someone build an ASIC to do what you want? > > Has. It's already part of nearly every DMA ASIC in a network interface > already. > > > Probably. Is there > > any reason in the world to expect operators to pay the significant extra > > cost for such?Not that I can see. > > We're talking about a ring of full adders, the specs for which are given > in an RFC that's 18 years old, and that is already implemented in nearly > every host interface, including 10Gps NICs. > > And we're talking about "routers", many variants of which operate at > very high speeds and transparently proxy TCP already. So this is a > solved problem. > > > And even if we could and they would, that is not the world into which we > > are deploying these tunnels. > > We're back to "that's not what they do now", at least in some devices. > > Well, they don't use MPLS in UDP (since no spec exists), so clearly if > they're limited to doing what they already do, this is an exercise in > futility. > > Joe > > > > > Yours, > > Joel > > > > On 1/27/14 1:53 PM, Joe Touch wrote: > >> > >> > >> On 1/27/2014 10:48 AM, joel jaeggli wrote: > >>> On 1/27/14, 8:48 AM, Joe Touch wrote: > >>>> Those same mechanisms have provided hardware checksum support for a > >>>> very long time. > >>> > >>> The new header and the payload are actually in different parts of the > >>> forwarding complex until they hit the output queue, you can't checksum > >>> data you don't have. > >> > >> You can (and some do) the checksum component parts when things go into > >> memory; the partial sums can be added as the parts are combined in the > >> output queue. > >> > >> I appreciate that we're all taking about what might be done, but the > >> reality is that there are many 'transparent TCP proxies' that have to do > >> this, so there's clearly a solution, and it clearly runs fast enough. > >> > >> Joe From curtis@ipv6.occnc.com Mon Jan 27 19:05:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF4E1A017F for ; Mon, 27 Jan 2014 19:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 rZm2vYllTNH6 for ; Mon, 27 Jan 2014 19:05:41 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 342A91A0176 for ; Mon, 27 Jan 2014 19:05:41 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S35X9n001250; Mon, 27 Jan 2014 22:05:33 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280305.s0S35X9n001250@maildrop2.v6ds.occnc.com> To: "Carlos Pignataro (cpignata)" From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 18:59:39 +0000." <628D8298-6C81-474A-A5A5-8237E0A3A89A@cisco.com> Date: Mon, 27 Jan 2014 22:05:33 -0500 Cc: "mpls@ietf.org" , "draft-ietf-mpls-forwarding.all@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 03:05:43 -0000 Carlos, I gave this some thought and perhaps we should add citations. I got your change below. I also took another look at the normative vs informational references and promoted quite a few to normative. The bad news is we now have a dependency on a draft. See inline ... but I am going to summarize in my reply to Adrian so that we can maintain one thread on this with Adrian's full set of comments. So please reply on that thread if you need to. Curtis In message <628D8298-6C81-474A-A5A5-8237E0A3A89A@cisco.com> "Carlos Pignataro (cpignata)" writes: > > Hi Curtis, > > On Jan 27, 2014, at 10:47 AM, Curtis Villamizar = > wrote: > > >=20 > > Carlos, > >=20 > > Since your apple mailer setting scrambled the plain text version a > > bit, I'm going to just snip out the relevent parts and reply inline. > > Thanks :-) > > >=20 > > In message <67516608-AAA0-49A1-B1E2-3DF146190D2C@cisco.com> > > "Carlos Pignataro (cpignata)" writes: > >=20 > >> Hi Curtis, > >>=20 > >> Many thanks for these! Ack to all. > >>=20 > >> Reading through your proposed changes, please find one small request = > =3D > >> inline: > >>=20 > >> On Jan 26, 2014, at 11:58 PM, Curtis Villamizar = > =3D > >> wrote: > >>=20 > >>> =3D20 > >>> In message <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk> > >>> "Adrian Farrel" writes: > >>>> =3D20 > >=20 > > [... big snip ...] > >=20 > >>>> --- > >>>>=20 > >>>> Section 2.1 > >>>>=20 > >>>> Tunneling encapsulations which may carry MPLS, such as MPLS in = > GRE, > >>>> L2TP, or LDP, are out of scope. > >>>>=20 > >>>> I think s/LDP/UDP/ > >>>=20 > >>> Yes. Thanks. > >>=20 > >> Could this be reworded as follows? > >>=20 > >> NEW: > >> Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC = > 4023], > >> MPLS in GRE [RFC 4023], MPLS in L2TPv3 [RFC 4817], or MPLS in UDP > >> [draft-ietf-mpls-in-udp], are out of scope. > >=20 > > I don't cite documents that define things that are declared out of > > scope. For example, I don't cite documents defining the various > > flavors of PW AC that are declared out of scope. > >=20 > > In this case I listed a few examples so that the phrase "Tunneling > > encapsulations carrying MPLS" was a bit more clear. > >=20 > > OK. Please note that there are a couple of (very small) changes besides = > the citations: > * Tunneling encapsulations which may carry MPLS -> Tunneling = > encapsulations carrying MPLS > * such as MPLS in GRE, L2TP, or LDP -> such as MPLS in IP, MPLS in GRE, = > MPLS in L2TPv3, or MPLS in UDP Got it. With citations. > > The references section is already quite large. > > The document is not short :-) > > Looking at it right now, the "Normative References" section is actually = > not large for this document. > > The "Informative References" is large, but I do not see that as an = > issue. As you know, informative references only provide additional = > contextual non-normative information. Only readers that are interested = > in a specific tangent will go there. I see that adding these informative = > references has no draw-back, but can help readers that would like to = > understand more about "Tunneling encapsulations carrying MPLS". I;d = > really add them. > > That said, if you believe that the document gets worst (e.g., too large = > and distractive) by adding these, or that it is inconsistent with other = > references, it's OK. > > >=20 > >> And then for consistency below: > >>=20 > >> OLD: > >> 7. Some IP encapsulations support tunneling, such as IP-in-IP, = > GRE, > >> L2TPv3, and IPSEC. These provide a greater source of entropy > >> which some provider networks carrying large amounts of tunneled > >> traffic may need. The use of tunneling header information is = > out > >> of scope for this document. > >> NEW: > >> 7. Some IP encapsulations support tunneling, such as IP-in-IP, = > GRE, > >> L2TPv3, and IPSEC. These provide a greater source of entropy > >> which some provider networks carrying large amounts of tunneled > >> traffic may need (e.g., as used in [RFC 5640] for GRE and =3D > >> L2TPv3). > >> The use of tunneling header information is out of scope for = > this =3D > >> document. > >=20 > > Same reasoning. If we declare something out of scope we shouldn't > > then describe it further and provide citations. > >=20 > > It definitely is out of scope for the document. But if a reader's scope = > is interested, it would help to be informational about it. > > As per above, either way is fine. Thanks for considering it. OK, With citation as requested. > > At one point Andy floated the idea of a PWE3 forwarding draft in the > > relevant WG. If you want to do a GRE forwarding draft, have at it, > > but it might be in another WG with MPLS being only one of the things > > that GRE can carry that might need entropy. > >=20 > > Ack. > > >> Thanks! > >>=20 > >> Carlos. > >=20 > > Good suggestions if we hadn't declared these things out of scope. We > > do have to limit the scope to avoid turning this into a complete "how > > to build a router" document and I've tried to avoid scope creep into > > realms outside of MPLS. > >=20 > > One place were we don't do similar citations but maybe we should is: > >=20 > > Support for other protocols that share a common Layer-4 header such > > as RTP, UDP-lite, SCTP and DCCP SHOULD be provided, particularly > > for edge or access equipment where additional entropy may be > > needed. Equipment SHOULD also use RTP, UDP-lite, SCTP and DCCP > > headers when creating an entropy label. > >=20 > > I didn't add citations to each of these protocols to avoid further > > reference section bloat and because they are well known and easy to > > find in the rfc-index file. This is creeping to the edge of the > > defined document scope, but the WG raging discussion of UDP checksums > > indicates that we really need the SHOULD for at least UDP-Lite and > > probably for the others as well. > >=20 > > :-) Might as well add citations to RTP, UDP-lite, SCTP and DCCP. > To me, the line is drawn at areas that directly touch MPLS. For example, = > the UDP one is a good one to add, as we saw that discussion. Similarly, = > encapsulating MPLS in other tunnels is of interest to folks, even if out = > of scope for the doc (and hence, not Normative, as opposed to not = > "Citable/Referenceable"). > > Thanks, > > -- Carlos. > > > Curtis > >=20 > >=20 > > [... big snip ...] From loa@pi.nu Mon Jan 27 19:14:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A821A1A026F for ; Mon, 27 Jan 2014 19:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 YvSFHWJljRvU for ; Mon, 27 Jan 2014 19:14:39 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4011A017F for ; Mon, 27 Jan 2014 19:14:39 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.65.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F10AD180145E; Tue, 28 Jan 2014 04:14:34 +0100 (CET) Message-ID: <52E72097.6000604@pi.nu> Date: Tue, 28 Jan 2014 11:14:31 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Vanson Lim , "mpls@ietf.org" References: <52C795FE.7060801@pi.nu> <52DE32F0.3050005@pi.nu> <52E6D9EA.9000409@cisco.com> In-Reply-To: <52E6D9EA.9000409@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org Subject: Re: [mpls] Closed: Working group last call on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 03:14:42 -0000 Vansom, OK - please ping me when you post the new version. /Loa On 2014-01-28 06:12, Vanson Lim wrote: > Loa, > > Just wanted to acknowledge the receipt of this email. Sam/George and I > will meet this week to work on addressing comments. > > -Vanson > > > On 1/21/14, 3:42 AM, Loa Andersson wrote: >> Working Group, >> >> This working group last call is closed. There has been comments, >> could the authors please address the comments and re-post a new >> version of the document as necessary. Please make sure that the >> reviewers are comfortable with how the comments are resolved. >> >> /Loa >> mpls wg co-chair >> >> On 2014-01-04 13:02, Loa Andersson wrote: >>> Working Group, >>> >>> this is to start a two week working group last call on >>> draft-ietf-mpls-proxy-lsp-ping-01.txt >>> >>> Please send your comments to working group mailing lists >>> (mpls@ietf.org). >>> >>> We will do an IPR poll on this document in parallel thee wglc. >>> >>> There are three IPRs disclosures that relates to this document. >>> >>> The working group last call will end Friday January 20, 2914. >>> >>> /Loa >>> mpls wg co-chair >>> >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From xuxiaohu@huawei.com Mon Jan 27 19:55:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8541A028A; Mon, 27 Jan 2014 19:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 ZyAUdQ-ACmA6; Mon, 27 Jan 2014 19:55:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6492F1A017F; Mon, 27 Jan 2014 19:55:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCZ73375; Tue, 28 Jan 2014 03:55:29 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 03:55:12 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 03:55:28 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 11:55:23 +0800 From: Xuxiaohu To: "isis-wg@ietf.org list" , "ospf@ietf.org" Thread-Topic: Solicit Comments on draft-xu-isis-mpls-elc-00 and draft-xu-ospf-mpls-elc-00 Thread-Index: Ac8b3MSLiehkrqKoR5y6oot2scoh6g== Date: Tue, 28 Jan 2014 03:55:22 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08248850@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: [mpls] Solicit Comments on draft-xu-isis-mpls-elc-00 and draft-xu-ospf-mpls-elc-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 03:55:34 -0000 Hi all, The SPRING SR use case draft (http://tools.ietf.org/html/draft-filsfils-rtg= wg-segment-routing-use-cases-02) has explicitly expressed the need for load= -balancing MPLS traffic in the SPRING domain. [RFC6790] has defined a method to load balance MPLS traffic flows using Ent= ropy Labels (EL). According to the specification as defined in [RFC6790], a= n ingress LSR cannot insert ELs for packets going into a given tunnel unles= s an egress LSR has indicated via signaling that it can process ELs on that= tunnel. Therefore [RFC6790] defines the signaling of this capability (a.k= .a Entropy Label Capability - ELC) via existing label distribution protocol= s( i.e., LDP, RSVP and BGP). However, in the SPRING domain, the above signa= ling mechanisms are inadequate since label distribution would be done via l= ink state Interior Gateway Protocols (IGP) (i.e., IS-IS and OSPF) instead o= f the existing label distribution protocols( i.e., LDP, RSVP and BGP). This draft (http://tools.ietf.org/html/draft-xu-mpls-el-capability-signalin= g-igp-00) describing mechanisms to signal the ELC using OSPF and ISIS has b= een presented at SPRING and MPLS WG during the last IETF meeting. According= to SPRING co-chairs' suggestions, this draft has been separated into two d= rafts: one is IS-IS specific (http://tools.ietf.org/html/draft-xu-isis-mpls= -elc-00), the other is OSPF specific (http://tools.ietf.org/html/draft-xu-o= spf-mpls-elc-00). Any comments on these two drafts are welcome. Best regards, Xiaohu From curtis@ipv6.occnc.com Mon Jan 27 20:08:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DACA1A036F for ; Mon, 27 Jan 2014 20:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 o0qdzYMp0NB5 for ; Mon, 27 Jan 2014 20:08:40 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 763781A036D for ; Mon, 27 Jan 2014 20:08:40 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0S48bot002466; Mon, 27 Jan 2014 23:08:37 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401280408.s0S48bot002466@maildrop2.v6ds.occnc.com> To: adrian@olddog.co.uk From: Curtis Villamizar In-reply-to: Your message of "Mon, 27 Jan 2014 23:04:06 +0000." <022d01cf1bb4$1624fde0$426ef9a0$@olddog.co.uk> Date: Mon, 27 Jan 2014 23:08:37 -0500 Cc: mpls@ietf.org, draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 04:08:44 -0000 In message <022d01cf1bb4$1624fde0$426ef9a0$@olddog.co.uk> "Adrian Farrel" writes: > > Hello Curtis, > > These replies modulo the conversation with Carlos. I find I can't read that > conversation and back apply the results here :-( I'll summarize the outcome of that conversation with Carlo at the bottom so we can have one thread. > [snip] > > > > Your acronym list is commendably thorough, but a little enthusiastic. > > > > If I provide a section with a list of acronyms, do I still have to > > expand on first use. If so, AC, NSP, OAM, and a few others appear > > before that section. > > Afraid so :-( OK. Expanded except RFC-Editor listed well known abbreviations. > > Given that this takes up only 17 lines in a 50 page document I'd > > rather be thorough. > > Yup. OK. Go for it. > > [snip] > > > > I think Curtis may have heard this before :-) > > > The "preferred" (by the RFC editor) expansion of ECMP is > > > "Equal-Cost Multipath" > > > > The form without the hyphen is more common, even among recent > > documents. I prefer to keep it without the hyphen. > > A discussion for a rainy day with the RFC Editor. > Leave as is. Cheers. > > > Section 1.3 bullet 5 > > > > > > 5. The implementer and system designer MUST support pseudowire > > > control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is > > > being used on a pseudowire. > > > > > > The wording is a bit odd. "The implementation and system design..."? > > > > > > Ditto bullets 6 and 7 > > > > Target audience is explained in Section 1.4. If you like I can flip > > Section 1.3 and 1.4 so target audience is first, then use of the roles > > called for in the target audience section won't seem quite so odd. > > No issue with the section order. > Just puzzled by "the implementer MUST support" when I (pedantically) thought > that the implementer supporting something might not be the same as the > implementation supporting it. > > Not a big deal. Good point. Its changed. > > > Section 1.3 > > > > > > While there is not wrong with the statements made in the bullets, some > > > of the later ones refer to recent additions to the MPLS suite. Yet the > > > list is presented as "there were some misconceptions." Clearly the > > > early silicon did not have misconceptions about the inclusion of entropy > > > labels. > > > > > > Just tweak the words at the top of the list? > > > > I'd like to keep that as is and split into two lists. The second list > > would have the last two items (fat-pw and EL). The first list would > > end with "implement CW" (sic). > > > > OLD > > > > 6. The implementer and system designer SHOULD support adding a > > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > > feature for appropriate pseudowire types. See Section 2.4.3. > > > > 7. The implementer and system designer SHOULD support adding an MPLS > > entropy label [RFC6790]. Deployments MAY enable this feature. > > See Section 2.4.4. > > > > NEW > > > > The following statements provide clarification regarding more > > recent requirements that are often missed. > > > > 1. The implementer and system designer SHOULD support adding a > > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > > feature for appropriate pseudowire types. See Section 2.4.3. > > > > 2. The implementer and system designer SHOULD support adding an MPLS > > entropy label [RFC6790]. Deployments MAY enable this feature. > > See Section 2.4.4. > > > > I've made this change. Let me know if this is not OK. > > That's fine. > > > > 2.1.1 > > > > > > Maybe the first paragraph should clarify "special purpose labels at > > > the top of the label stack" > > > > That phrase doesn't appear anywhere in the document. Exactly what am > > I clarifying? What to do with unknown special purpose labels is in > > the last paragraph of this subsection. > > WTF? > You have to wonder where these senile ADs get their ideas. > > Complete brain fart. Sorry. > > [snip] > > > > While per platform label space is mentioned in 2.1.7 I wonder whether > > > more information on per platform and per interface label spaces is > > > needed. I recall early implementations that got very confused when > > > parallel interfaces used the same label for different purposes. > > > > > > I guess the point there is that you cannot assume that your neighbor > > > is or is not using the per platform label space. > > > > > > Upstream label allocation may also come into this. > > > > The only mention of label allocation is that MPLS FRR bypass method > > (more formally known as facilitles backup) uses platform label space. > > > > The only reason platform label space is of any significance in a > > document about forwarding is "The use of platform label space impacts > > the size of the LSR ILM for LSR with a very large number of > > interfaces." > > > > Label allocation, per platform or per interface and upstream or > > downstream, is not a forwarding issue. It is a software issue > > and a matter of getting the protocol bits right. Therefore I think > > expanding any further on label allocation should be out of scope. > > OK. I'm convinced. > > > > 2.1.8.1 > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > core is using multipath, reordering will be far more common. If > > > this is occurring, the best solution is to use CW on the edge, > > > rather than try to fix the reordering using resequencing. > > > > > > Completely agree, but isn't the sequence number contained in a control > > > word meaning that the resequencing could, in any case, not be done > > > without using a control word? > > > > I suppose you can't fix reordering caused by not using CW without the > > sequence number in the CW. That is going to require fixing the text. > > > > OLD > > > > 3. If the edge is not using pseudowire control word (CW) and the > > core is using multipath, reordering will be far more common. > > If this is occurring, the best solution is to use CW on the > > edge, rather than try to fix the reordering using resequencing. > > > > NEW > > > > 3. If the edge is not using pseudowire control word (CW) and the > > core is using multipath, reordering will be far more common. > > If this is occurring, using CW on the edge will solve the > > problem. Without CW, resequencing is not possible since the > > sequence number is contained in the CW. > > > > That was a big oops on our part. > > Well, on the scale of IETF oopsies, I don't think you score too high. Maybe > Narten could run a weekly script? > > [snip] > > > > Should 2.2 distinguish the order of magnitude of replication at branch > > > nodes? This impacts the replication method used (some devices make a > > > copy and cycle around, some devices can do multiple copies at once). On > > > the whole is no different from IP multicast processing except (as you > > > note) that each outgoing packet may be different by its label value. > > > > Is it possible to quantify the fanout? YMMV? > > > > The only thing I could say is that an implementation may need to make > > lots of copies in some roles (access routers for example). > > > > Making a copy and cycling yields poor performance but for low > > multicast traffic volumes might be OK. But you are right - some > > mostly low-end-ish chips to this. > > > > I'm not sure I can describe how multicast with high fanout is done > > without wading into implementation details of specific vendors. > > > > Perhaps the best I can do is add this: > > > > Careful consideration should be given to the performance > > characteristics of high fanout multicast for equipment that is > > intended to be used in such a role. > > > > I'll add this before the last paragraph in the section. > > That works. > > > > 2.4 > > > > > > So obvious you didn't say it? > > > > > > In order to support an adequately balanced load distribution across > > > multiple links, IP header information must be used. Common practice > > > today is to reinspect the IP headers at each LSR and use the label > > > stack and IP header information in a hash performed at each LSR. > > > Further details are provided in Section 2.4.5. > > > > > > Missing is the statement that a single "flow" must not be distributed > > > across multiple paths because of the implication for potentially > > > significant packet misordering. And feeding that is a common requirement > > > that such packet misordering must not occur because applications and > > > transport protocol implementations cannot survive such misordering. > > > > Yes. That requirement was missed. Add new second paragraph to this > > subsection. > > > > The Differentiated Services requirements for good reasons dictate > > that packets within a common microflow SHOULD NOT be reordered > > [RFC2474]. Service providers generally impose stronger > > requirements, commonly requiring that packets within a microflow > > MUST NOT be reordered except in rare circumstances such as load > > balancing across multiple links or path change for load balancing > > or path change for other reason. > > > > Another SP requirement is stated here and I'm quite sure this > > requirement is well accepted. > > Looks good. > > > > 2.4.2 uses "composite link" and "component link". I suggest picking just > > > one term. > > > > They are two different things. Two or more component links make up a > > composite link. Knowing that, give it another read please. > > > > I'd rather not cite draft-ietf-rtgwg-cl-requirements as an > > informational reference just for this one term. In favor of citing > > it, draft-ietf-rtgwg-cl-requirements is moving along. Against citing > > it is there is far less than a ground swell of providers calling for > > the full set of things asked for in draft-ietf-rtgwg-cl-requirements. > > Yes. Sorry. It has been a looooooooong time since I had a pass on the CL > document. Atrophy. Its also in Gwiz.8080 or something like that. > > > 2.4.5.1 notes that special purpose and extended special purpose labels > > > need to be excluded from the hash. Good. > > > But it seems that some special purpose labels will indicate that the > > > next label stack entry contains a label with special meaning. (ELI is > > > an example that we specifically don't have to worry about.) > > > How do we handle that? > > > Should we be dividing up the extended special purpose label space to > > > have one set of code points meaning "just this label is special" and > > > another set meaning "this label is special and the next label stack > > > entry is magic"? > > > > I did list ELI (bullet 2) before the more general rule of not useing > > special purpose labels. The ELI is not used, just the EL, so the text > > could be considered correct as-is. > > > > So far the only special purpose label that is not just ignored and > > skipped over is ELI. > > > > Regarding this being magic -- All of this is somewhat programable > > specialized silicon magic. The silicon generally has some form of > > very fast, very light weight parsing engine at the front of the > > pipeline. One thing it does is pick out fields for load balance. > > > > The better silicon hashes as it goes rather that pick out a set of > > fields and then hashes that set of fields when its done. When it sees > > 13 it skips and hashes the next thing and stops hashing completely. > > If it sees 0-12,14 it skips and continues. If it sees 15 it skips two > > labels and continues. Its should be programable enough that if > > someone defines a new ELI like label it is likely to be able to deal > > with it. > > > > The not so good silicon has this all so hard wired that it won't be > > able to do ELI without at least a respin. > > > > At most I could add "If a new special purpose label or extended > > special purpose label is defined which requires special load balance > > processing then, as is the case for the ELI label, a spacial action > > may be needed rather than skipping the special purpose label or > > extended special purpose label." I really don't think this is needed. > > You're right, and my worry is more about the special-purpose draft and the > consequences of possibly adding other special purpose labels that have child > labels associated. We certainly don't want to have to retrain the silicon at > transit LSRs to specially know what to do for each new special-purpose label. > Currently we propose that you don't hash on a special purpose label, but you can > carry on hashing immediately after. > > If I introduce the foo-label, your silicon will recognise it as special purpose, > but it I say the label after the foo-label is magic you won't know that. > > A way to fix this is to have (just punting here) the top bit of the extended > special purpose label range set mean "magic label follows". I added this: 4. If a new special purpose label or extended special purpose label is defined which requires special load balance processing, then, as is the case for the ELI label, a spacial action may be needed rather than skipping the special purpose label or extended special purpose label. This will be the new bullet 4, bumping down the old 4 and 5. > > > An issue that arises from the multipath support (2.4.5.1) is that > > > hardware assumes that after a label stack entry with the S-bit set, > > > there are only three possible next bytes... > > > - a control word (indicated by b0000 or b0001) > > > - an IPv4 header > > > - an IPv6 header > > > This is the case regardless of how the LSP was set up, and the next > > > bytes cannot ever be further MPLS stack entries. > > > > Right. Note that in (5) is says that some SP will require IP headers > > and some will require an ability to disable IP headers. > > > > The rule is really look for 4, 6, or anything else in the first > > nibble. If 4 or 6 assume IP. If anything else stop. > > > > And yes if the payload is MPLS after a S-bit you have a screwed up > > MPLS implementation to start with and you won't get load balance on > > any set of MPLS labels after the first S-bit. This is a fact of life > > in the field and is as it should be. > > > > > While this comes up 2.4.5.1 it may merit further discussion in an > > > earlier section of the document. > > > > This text is part of 2.4. ("MPLS Multipath Techniques"). The third > > paragraph contains "Further details are provided in Section 2.4.5." > > Section 2.4.5. is "Fields Used for Multipath Load Balance". > > > > > I note that discussion of support of PWs without the CW drives you > > > to say that hashing beyond the S-bit should be a configurable option > > > which would (of course) support any payload including MPLS in MPLS > > > with repeated bottom of stack. However, you might want to specifically > > > preclude that. > > > > It says the same thing here in bullet 5 regarding being configurable. > > The wording "ability to disable" is same as "configurable option". > > > > At no point in this document do we imply that looking beyond the S-bit > > means looking at anything beyond the S-bit other than looking for IP. > > This is very clear in [RFC4385] and [RFC4928] which is cited in the > > text about PW CW. > > > > All it says in the places discusing PW is that without CW the traffic > > might get reordered. > > > > If you feel that we at any point imply that lack of PW CW allows > > looking at anything past the S-bit rather than just looking for an IP > > header please point to where and we will have to correct that. I > > looked at all occurances of CW and did not find anything. > > > > Bullet 5 is very clear that a 4 or 6 has to be found in the first > > nibble of payload. > > OK. I misread bullet 5. OK > [snip] > > Thanks. > Adrian Summary of conversation with Carlos: Adrian wrote: >> Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, >> L2TP, or LDP, are out of scope. >> >> I think s/LDP/UDP/ Carlos noted some wording issues in this sentence and suggested adding citations for each. After some discussion: OLD (original) Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, L2TP, or LDP, are out of scope. NEW Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC4023], MPLS in GRE [RFC4023], MPLS in L2TPv3 [RFC4817], or MPLS in UDP [I-D.ietf-mpls-in-udp], are out of scope. He also suggested the following. OLD Some IP encapsulations support tunneling, such as IP-in-IP, GRE, L2TPv3, and IPSEC. These provide a greater source of entropy which some provider networks carrying large amounts of tunneled traffic - may need. The use of tunneling header information is out of scope for this document. NEW Some IP encapsulations support tunneling, such as IP-in-IP, GRE, L2TPv3, and IPSEC. These provide a greater source of entropy which some provider networks carrying large amounts of tunneled traffic + may need, for example as used in [RFC5640] for GRE and L2TPv3. The use of tunneling header information is out of scope for this document. As part of that conversation it was noted that the following also had no citations. OLD Support for other protocols that share a common Layer-4 header such - as RTP, UDP-lite, SCTP and DCCP SHOULD be provided, particularly for edge or access equipment where additional entropy may be needed. NEW Support for other protocols that share a common Layer-4 header such + as RTP [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960] and DCCP + [RFC4340] SHOULD be provided, particularly for edge or access equipment where additional entropy may be needed. btw- this is wrt fields used in load balancing and is saying in effect "use more than just port 6 and 17 (UDP and TCP)". Other than that, I looked at the list of informational references and found the following do affect MPLS forwarding and therefore should be promoted to normative. [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011. [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011. [RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., and D. Ward, "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011. [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011. [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)", RFC 6720, August 2012. [I-D.ietf-mpls-psc-updates] Osborne, E., "Updates to PSC", draft-ietf-mpls-psc- updates-00 (work in progress), October 2013. Upgrades were mostly due to BFD and MPLS-TP OAM. For example, direct LM needs to be in hardware and most things related to protection. Note that "Updates to PSC" affects MPLS-TP protection state machine which needs hardware assist if not direct support in hardware in order to be fast. The race condition may be the most severe problem with RFC 6378 state machine. If you think any of the above should be put back into informative, please let me know. Curtis From ryoo@etri.re.kr Tue Jan 28 01:41:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E261A014C for ; Tue, 28 Jan 2014 01:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.454 X-Spam-Level: X-Spam-Status: No, score=-101.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 Juy0gyuFjNNq for ; Tue, 28 Jan 2014 01:41:07 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 739CB1A01BC for ; Tue, 28 Jan 2014 01:41:06 -0800 (PST) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 28 Jan 2014 18:41:05 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP3.etri.info ([169.254.157.203]) with mapi id 14.01.0355.002; Tue, 28 Jan 2014 18:41:01 +0900 From: "Ryoo, Jeong-dong" To: Yaacov Weingarten , Loa Andersson Thread-Topic: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 Thread-Index: AQHPFYdUrouQjghEKkymdYiVWJN87pqYdiKAgAF3azk= Date: Tue, 28 Jan 2014 09:41:01 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3DCC@SMTP2.etri.info> References: <52DC89C3.3030003@pi.nu>, In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3DCCSMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 09:41:12 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3DCCSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFhY292LA0KQWdhaW4sIHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLg0KSSByZWFsbHkgYXBwcmVj aWF0ZSB5b3VyIGhlbHAgb24gdGhpcyBkb2N1bWVudC4NClRoZSBmb2xsb3dpbmdzIGFyZSBteSBy ZXNwb25zZXMgdG8geW91ciBjb21tZW50czoNCj09PT09PT09DQojMS4gWWVzLCB5b3UgZGVzY3Jp YmVkIHRoZSBjb3JyZWN0IGJlaGF2aW9yIG9mIE1TLVcuIEFzIHlvdSBpbmRpY2F0ZWQsIE1TIGFu ZCBFWEVSIGFyZSBzdXBwb3NlZCB0byBiZSBpZ25vcmVkIHdoaWxlIE1TLVcgaXMgaW4gZWZmZWN0 Lg0KIzIuIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbW9kaWZ5IHRoZSBvcGVyYXRpb24gb2YgdGhl IHNlbGVjdG9yIGRlc2NyaWJlZCBpbiBSRkM2Mzc4LiBBY2NvcmRpbmcgdG8gUkZDNjM3OCwgdGhl IHNlbGVjdG9yIHNlbGVjdHMgdGhlIHRyYWZmaWMgZnJvbSBvbmx5IG9uZSBvZiB0aGUgcGF0aHMg bm8gbWF0dGVyIGlmIHRoZSBwcm90ZWN0aW9uIGFyY2hpdGVjdHVyZSBpcyAxOjEgb3IgMSsxLiBJ ZiB5b3UgdGhpbmsgaXQgaXMgYXBwcm9wcmlhdGUgdG8gbWFrZSB0aGlzIGNsZWFyLCB0aGVuIHdl IGNhbiBhZGQgc29tZXRoaW5nIGxpa2U6DQrigJxUaGlzIGRvY3VtZW50IGRvZXMgbm90IG1vZGlm eSB0aGUgb3BlcmF0aW9uIG9mIHRoZSBzZWxlY3RvciBhdCB0aGUgc2luayBMRVIgZGVzY3JpYmVk IGluIFJGQyA2Mzc4LiBUaGUgc2VsZWN0b3IgYXQgdGhlIHNpbmsgTEVSIGNob29zZXMgZWl0aGVy IHRoZSB3b3JraW5nIG9yIHByb3RlY3Rpb24gcGF0aCBmcm9tIHdoaWNoIHRvIHJlY2VpdmUgdGhl IG5vcm1hbCB0cmFmZmljIGluIGJvdGggMToxIGFuZCAxKzEgYXJjaGl0ZWN0dXJlcy4gVGhlIHBv c2l0aW9uIG9mIHRoZSBzZWxlY3RvciwgaS5lLiwgd2hpY2ggcGF0aCB0byByZWNlaXZlIHRoZSB0 cmFmZmljLCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBQU0MgcHJvdG9jb2wgaW4gYmlkaXJlY3Rpb25h bCBzd2l0Y2hpbmcgb3IgYnkgdGhlIGxvY2FsIGlucHV0IGluIHVuaWRpcmVjdGlvbmFsIHN3aXRj aGluZy7igJ0NCkFzIGEgbWF0dGVyIG9mIGZhY3QsIGFjY29yZGluZyB0byBSRkMgNDQyNyAoYW5k IGFsbCB0aGUgSVRVLVQgcHJvdGVjdGlvbiBkb2N1bWVudHMpLCBhIHNlbGVjdG9yIHJlZmVycyB0 byB0aGUgZW50aXR5IGF0IHRoZSBzaW5rIG5vZGUgb25seS4gRm9yIHRoZSBzb3VyY2Ugbm9kZSwg YSBicmlkZ2UgaXMgdXNlZCB0byBjaG9vc2Ugd2hpY2ggcGF0aCAob25lIG9mIHR3byBwYXRocyBp biAxOjEsIG9yIGJvdGggcGF0aHMgaW4gMSsxKSB0byB0cmFuc21pdCB0aGUgdHJhZmZpYy4gVGhl cmVmb3JlLCDigJx0aGUgc2VsZWN0b3IgaW4gdGhlIHNpbmsgTEVS4oCdIGlzIHJlZHVuZGFudCBh bmQgc2hvdWxkIGhhdmUgYmVlbiByZXBsYWNlZCB3aXRoIGp1c3Qg4oCcdGhlIHNlbGVjdG9y4oCd LiBCdXQsIHRoZSBkZXNjcmlwdGlvbnMgb2YgdGhlIHNlbGVjdG9yIGFuZCBicmlkZ2UgaW4gUkZD IDYzNzggYXJlIHNvbWV3aGF0IGRpZmZlcmVudC4gSW4gUkZDIDYzNzgsIHRoZSBzZWxlY3RvciBp cyB1c2VkIGZvciBib3RoIHRyYW5zbWl0dGluZyBhbmQgcmVjZWl2aW5nIHRoZSB0cmFmZmljLCB3 aGlsZSB0aGUgYnJpZGdlIGlzIHVzZWQgZm9yIHRyYW5zbWl0dGluZyBvbmx5LiBUaGUgZGVzY3Jp cHRpb25zIGluIFJGQyA2Mzc4IGFyZSBub3QgcXVpdGUgYWxpZ25lZCB3aXRoIFJGQyA0NDI3IChh bmQgb3RoZXIgSVRVLVQgZG9jcykuDQojMy4gQWdhaW4sIHRoaXMgaXMgZHVlIHRvIHRoZSBkaWZm ZXJlbnQgdW5kZXJzdGFuZGluZyBvbiB0aGUgc2VsZWN0b3IuIElmIHlvdSBzdGljayB0byB0aGUg dGVybWlub2xvZ3kgZGVmaW5lZCBpbiBSRkMgNDQyNyBhbmQgSVRVLVQsIHRoZW4geW91IG1heSBu b3QgaGF2ZSB0aGUgaXNzdWUgd2l0aCBjdXJyZW50IHNlbnRlbmNlcy4gSW4gdGhlIG1lYW50aW1l LCBhcyBJIGRpZCBpbiAjMiwgSSBjYW4gYWRkIOKAnGluIHRoZSBzaW5rIExFUuKAnSBhZnRlciBl dmVyeSDigJx0aGUgc2VsZWN0b3LigJ0uIEluIG90aGVyIHdvcmRzLCAidGhlIHBhdGggZnJvbSB3 aGljaCB0aGUgc2VsZWN0b3IgZG9lcyBub3Qgc2VsZWN0IHRoZSB1c2VyIGRhdGEgdHJhZmZpYyIg Y2FuIGJlIHJlcGxhY2VkIHdpdGgg4oCcInRoZSBwYXRoIGZyb20gd2hpY2ggdGhlIHNlbGVjdG9y IGF0IHRoZSBzaW5rIExFUiBkb2VzIG5vdCBzZWxlY3QgdGhlIHVzZXIgZGF0YSB0cmFmZmljIg0K IzQuIFRoZSBhY3Rpb24gb24gd2hpY2ggcGF0aCB0aGUgTEVSIHNob3VsZCBzZW5kIHRoZSB0cmFm ZmljIGlzIHRoZSBzYW1lLCBidXQgdGhlIHNpbmsgbm9kZSBzaG91bGQgZGV0ZXJtaW5lIGZyb20g d2hpY2ggcGF0aCB0aGUgdHJhZmZpYyBzaG91bGQgYmUgcmVjZWl2ZWQuIEluIG9yZGVyIHRvIGRl dGVybWluZSB0aGUgcG9zaXRpb24gb2YgdGhlIHNlbGVjdG9yICphdCB0aGUgc2luayBub2RlKiwg d2UgbmVlZCB0byByZXNvbHZlIHRoZSBjb25mbGljdC4NCiM1LiBJIHRvdGFsbHkgYWdyZWUgd2l0 aCB5b3UuIFBsZWFzZSBzZWUgbXkgZWFybGllciBlbWFpbCBvbiB2ZXJzaW9uIG51bWJlci4NCiM2 LiBZb3VyIGltcHJlc3Npb24gb24gdGhlIGxpbmVhciBwcm90ZWN0aW9uIGlzIHRoZSBzYW1lIGFz IG1pbmUuIFRoaXMgc2VjdGlvbiBuZWVkcyB0byBiZSByZXdyaXR0ZW4uIEluIG15IG9waW5pb24s IHdlIHNob3VsZCBub3QgdXNlIHRoZSB0ZXJtLCB0aGUgbGlmZSBvZiBQU0Mgc2Vzc2lvbi4gQXMg SSBtZW50aW9uZWQgaW4gbXkgZW1haWwgcmVzcG9uZGluZyB0byB0aGUgQUQgUmV2aWV3IGNvbW1l bnRzLCBTZWN0aW9uIDkgc2hvdWxkIGJlIHJld3JpdHRlbiAob3IgcmVtb3ZlZCBpZiB3ZSBjYW4g Y2hhbmdlIHRoZSB2ZXJzaW9uIG51bWJlcikuIEluIG15IG9waW5pb24sIHlvdXIgc3VnZ2VzdGlv biBpbiAjNSBpcyBhbHNvIGJldHRlciB0aGFuIGFzIGlzIG5vdy4NCiM3LiBJIHRvdGFsbHkgYWdy ZWUgd2l0aCB5b3Ugb24gY2hhbmdpbmcgdGhlIHZlcnNpb24gbnVtYmVyLg0KIzguIFdlIGZvbGxv d2VkIHRoZSBzYW1lIGdyb3VwaW5nIGFzIGluIFJGQyA2Mzc4LiBJbiBTZWN0aW9uIDQuMy4zLjIg b2YgUkZDIDYzNzgsIHRoZSBzZWNvbmQgcGFyYWdyYXBoIHNheXM6DQpUaGUgcHJvdGVjdGlvbiBk b21haW4gd2lsbCBleGl0IHRoZSBVbmF2YWlsYWJsZSBzdGF0ZSBhbmQgcmV2ZXJ0IHRvDQp0aGUg Tm9ybWFsIHN0YXRlIHdoZW4gZWl0aGVyIHRoZSBvcGVyYXRvciBjbGVhcnMgdGhlIExvY2tvdXQg Y29tbWFuZA0Kb3IgdGhlIHByb3RlY3Rpb24gcGF0aCByZWNvdmVycyBmcm9tIHRoZSBzaWduYWwg ZmFpbCBvciBkZWdyYWRlZA0Kc2l0dWF0aW9uLg0KQmFzZWQgdXBvbiB0aGlzLCB3ZSBwdXQgU0Qt UCBpbiBVbmF2YWlsYWJsZSBzdGF0ZS4gQXMgeW91IGtub3csIHRoZSBuYW1lIG9mIHRoZSBzdGF0 ZSBkb2VzIG5vdCBhZmZlY3QgdGhlIGFjdGlvbiB0YWtlbiBieSB0aGUgUFNDIHByb2Nlc3MuIFdo YXQgYWZmZWN0cyB0aGUgYWN0aW9uIGlzIHRoZSBleHRlbmRlZCBzdGF0ZSwgd2hpY2ggc2hvd3Mg dGhlIHJlcXVlc3QgYW5kIHRoZSBzb3VyY2Ugb2YgdGhlIHJlcXVlc3QuIElmIHlvdSB3YW50IHRv IHN1Z2dlc3QgYW55IG90aGVyIGFwcHJvcHJpYXRlIHN0YXRlLCBJIGFtIHJlYWR5IHRvIGhlYXIu DQo9PT09PT09PT09PQ0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbSA6ICJZYWFjb3YgV2VpbmdhcnRlbiIgPHd5 YWFjb3ZAZ21haWwuY29tPg0KU2VudCA6IDIwMTQtMDEtMjggMDU6MTI6MTYgKCArMDk6MDAgKQ0K VG8gOiBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+DQpDYyA6IG1wbHNAaWV0Zi5vcmcgPG1wbHNA aWV0Zi5vcmc+LCBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyA8bXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc+LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyA8ZHJh ZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+LCA8bXBscy1hZHNAdG9vbHMu aWV0Zi5vcmc+DQpTdWJqZWN0IDogUmU6IFttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMQ0KDQpIaSBhbGwsDQoNCkkgaGF2ZSByZWFkIHRo cm91Z2ggdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgYW5kIGhhdmUgYSBudW1iZXIg b2YgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyByZWdhcmRpbmcgdGhpcyBkb2N1bWVudC4gV2hpbGUs IGluIGdlbmVyYWwsIEkgZmVlbCB0aGF0IHRoZSBleHRlbnNpb25zIHRvIHRoZSBiZWhhdmlvciBv ZiBSRkM2Mzc4IGFyZSBhcHByb3ByaWF0ZSwgSSBmaW5kIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBz dGlsbCBpbiBuZWVkIG9mIHJlZmluZW1lbnQgaW4gaXRzIGxhbmd1YWdlIGFuZCBjbGFyaXR5IG9m IHRoZSBmdW5jdGlvbmFsaXR5LiBXaGlsZSBzb21lIG9mIHRoZSBhZGRpdGlvbmFsIGZ1bmN0aW9u YWxpdHkgaXMgZGVzY3JpYmVkLCB0aGVyZSBhcmUgZGlmZmVyZW50IGNhc2VzIG9mIHRoZSBmdW5j dGlvbmFsaXR5IHRoYXQgaXMgZWl0aGVyIG5vdCBkZXNjcmliZWQgb3IgaXMgcmF0aGVyIGNvbmZ1 c2luZy4NCg0KT25lIGJhc2ljIHF1ZXN0aW9uIGlzIC0gQ29uc2lkZXJpbmcgdGhhdCB0aGlzIGRy YWZ0IGlzIHByb3Bvc2luZyBjaGFuZ2VzIHRvIHRoZSBiYXNpYyBvcGVyYXRpb24gb2YgdGhlIFBT QyBwcm90b2NvbCwgTG9jYWwgUmVxdWVzdCBMb2dpYywgYW5kIHRoZSBQU0MgQ29udHJvbCBMb2dp YywgSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhhdCB0aGUgUFNDIFZlcnNpb24gbnVtYmVyIHNob3Vs ZCBjaGFuZ2UhIFdoeSB0aGVuLCBpcyB0aGVyZSBubyBtZW50aW9uIG9mIGNoYW5naW5nIHRoZSB2 ZXJzaW9uIHRvIGFsbG93IG5ldHdvcmtzIHRoYXQgc3VwcG9ydCB0aGUgZnVuY3Rpb25hbGl0eSBk ZXNjcmliZWQgaW4gUkZDNjM3OCB0byBjb250aW51ZSB0byBvcGVyYXRlPw0KDQpSZWdhcmRpbmcg dGhlIGZ1bmN0aW9uYWxpdHkgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0LCBJIGhhdmUgdGhlIGZvbGxv d2luZyBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzIC0NCg0KICAxLiAgKGZvciBjbGFyaWZpY2F0aW9u KSBSZWdhcmRpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgTVMtVywgd2hhdCBpcyB0aGUgZnVuY3Rp b25hbGl0eSBpZiB0aGUgZGF0YS10cmFmZmljIGlzIGN1cnJlbnRseSBvbiB0aGUgd29ya2luZyBw YXRoPyBTaW5jZSB0aGUgcHVycG9zZSBvZiB0aGUgY29tbWFuZCBpcyB0byBtb3ZlIHRoZSB0cmFm ZmljIHRvIHRoZSB3b3JraW5nIHBhdGgsIHNob3VsZG4ndCBpdCBiZSBpZ25vcmVkPyBIb3dldmVy LCBhY2NvcmRpbmcgdG8gdGhlIFN0YXRlIFRyYW5zaXRpb24gVGFibGUgaW4gc2VjdGlvbiAxMS4x IC0gaWYgdGhlIE1TLVcgaXMgcmVjZWl2ZWQgYnkgYSBMRVIgaW4gTm9ybWFsIFN0YXRlIGl0IHRy YW5zZmVycyB0byBTd2l0Y2hpbmcgQWRtaW5pc3RyYXRpdmUgU3RhdGUhIFRoZSBtYWluIGVmZmVj dCBzZWVtcyB0byBiZSB0byBjYXVzZSB0aGUgTEVSIHRvIGlnbm9yZSBpbmNvbWluZyBNUyBhbmQg RVhFUiByZXF1ZXN0cyAodGhhdCBhcmUgbm90IGlnbm9yZWQgaW4gTm9ybWFsIFN0YXRlKS4NCiAg Mi4gIFJlZ2FyZGluZyB0aGUgU0QgZnVuY3Rpb25hbGl0eSAtIGFmdGVyIGEgcHJldmlvdXMgZGlz Y3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IHRoZSBmdW5jdGlvbmFsaXR5IHdoZW4gcHJvdGVj dGluZyBmb3IgU0Qgc2l0dWF0aW9ucyAoZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4zKSB3YXMgY2hh bmdlZCB0byBlc3NlbnRpYWxseSBzd2l0Y2ggb3ZlciB0byB0aGUgTEVSIHRyYW5zbWl0dGluZyB0 aGUgcGFja2V0cyBvbiBib3RoIHRoZSB3b3JraW5nIGFuZCBwcm90ZWN0aW9uIHBhdGhzIChlc3Nl bnRpYWxseSAxKzEgdHJhbnNtaXNzaW9uKS4gSG93ZXZlciwgdGhlcmUgaXMgdmVyeSBsaXR0bGUg ZGlzY3Vzc2lvbiBvZiBob3cgdGhlIHJlY2VpdmluZyBMRVIgaXMgc3VwcG9zZWQgdG8gc2VsZWN0 IHRoZSBpbmNvbWluZyBwYWNrZXRzIHdoaWxlIGF2b2lkaW5nIGR1cGxpY2F0aW9uIG9mIGRhdGEu IENvdWxkIHBsZWFzZSBlbGFib3JhdGUgb24gdGhpcz8NCiAgMy4gIFJlZ2FyZGluZyB0aGUgU0Qg ZnVuY3Rpb25hbGl0eSAtIGFzIG1lbnRpb25lZCBpbiB0aGUgcHJldmlvdXMgcG9pbnQsIHdoZW4g cHJvdGVjdGluZyBmb3IgU0QsIHRoZSB0cmFuc21pdHRpbmcgTEVSIGR1cGxpY2F0ZXMgdGhlIHBh Y2tldHMgb24gYm90aCBXICYgUCBhbmQgdGhlIHJlY2VpdmluZyBMRVIsIHByZXN1bWFibHksIHJl YWRzIHRoZSBkYXRhIGZyb20gZWl0aGVyIHBhdGgsIGFuZCBtYXkgY2hvb3NlIGRpZmZlcmVudGx5 IGZvciBkaWZmZXJlbnQgcGFja2V0cy4gSG93ZXZlciwgbGF0ZXIgaW4gc2VjdGlvbiA3LjQgKGFu ZCBhZ2FpbiBpbiBzZWN0aW9uIDEwLjIpIHlvdSBpbnRyb2R1Y2UgYSBuZXcgY29uY2VwdCBvZiAi c3RhbmRieSBwYXRoIiBhcyAidGhlIHBhdGggZnJvbSB3aGljaCB0aGUgc2VsZWN0b3IgZG9lcyBu b3Qgc2VsZWN0IHRoZSB1c2VyIGRhdGEgdHJhZmZpYyIgaW4gcmVnYXJkIHRvIGRldGVybWluaW5n IHRoZSBwcmlvcml0eSBvZiAiY29uZmxpY3RpbmciIFNELVcgYW5kIFNELVAgdHJpZ2dlcnMuIENh biB5b3UgY2xhcmlmeSB3aGljaCBvZiB0aGUgdHdvIHBhdGhzIHRoYXQgYXJlIGJvdGggY2Fycnlp bmcgdXNlciBkYXRhIGlzIHRoZSBzdGFuZGJ5IHBhdGg/DQogIDQuICBGdXJ0aGVyIHJlZ2FyZGlu ZyB0aGUgcG9pbnQgb2YgImNvbmZsaWN0aW5nIiBTRCB0cmlnZ2VycyAtIHNpbmNlIHRoZSBwcm90 ZWN0aW9uIGZ1bmN0aW9uYWxpdHkgb2YgU0QgaXMgdG8gZHVwbGljYXRlIHRoZSBkYXRhIG9uIGJv dGggVyAmIFAgLSB3aHkgaXMgdGhpcyBjb25zaWRlcmVkIGEgY29uZmxpY3QsIHNpbmNlIHRoZSBh Y3Rpb24gZm9yIGJvdGggd2lsbCBiZSBpZGVudGljYWwgLSBjb250aW51ZSB0cmFuc21pdHRpbmcg b24gYm90aCBXICYgUC4gU29tZSBtb3JlIGNsYXJpZmljYXRpb24gd291bGQgaGVscC4NCiAgNS4g IFJlZ2FyZGluZyB0aGUgQVBTIG1vZGUgYW5kIHN1Yi1jYXBhYmlsaXRpZXMgLSBZb3UgZGVzY3Jp YmUgaW4gc2VjdGlvbiA5LjEgaG93IGFuIExFUiBjYW4gZGVjbGFyZSBpdHNlbGYgdG8gc3VwcG9y dCBvbmx5IHNvbWUgb2YgdGhlIGNhcGFiaWxpdGllcyBpbnRyb2R1Y2VkIGluIHRoZSBkcmFmdCwg YW5kIHRoZW4gZGVzY3JpYmUgdGhlIEFQUyAibW9kZSIgKFNlY3Rpb24gOS4yLjIpIGFzIGRlY2xh cmF0aW9uIG9mIHN1cHBvcnQgZm9yIGFsbCBvZiB0aGUgY2FwYWJpbGl0aWVzLCBpLmUuIEZsYWdz ID0gMHhGODAwMDAwMC4gRnJvbSB0aGlzIHBvaW50IG9uIChpbiBwYXJ0aWN1bGFyIHNlY3Rpb24g MTEpLCB5b3UgZGVzY3JpYmUgdGhlIGZ1bmN0aW9uYWxpdHkgZm9yIExFUiB0aGF0IGRlY2xhcmUg RmxhZ3M9IGVpdGhlciAweDAsIG9yIDB4RjgwMDAwMDAsIGhvd2V2ZXIsIHRoZXJlIGlzIG5vIGV4 cGxhbmF0aW9uIGZvciBwYXRocyB0aGF0IGRlY2xhcmUgc29tZSBvdGhlciB2YWx1ZSBvZiBGbGFn cyAoZm9yIGV4YW1wbGUsIDB4ODAwMDAwMCAtIHN1cHBvcnRpbmcgb25seSB0aGUgRVhFUiBmdW5j dGlvbmFsaXR5KS4gSXMgdGhlcmUgYSByZWFzb24gZm9yIHRoaXM/IEFyZSB3ZSBhc3N1bWluZyB0 aGF0IGFsbCBwYXRocyB3aWxsIGVpdGhlciBzdXBwb3J0IFBTQyBvciBBUFMgbW9kZXMgb25seT8g SWYgc28sIHdoeSBub3QganVzdCBoYXZlIHR3byB2YWx1ZXMgZm9yIEZsYWdzIHJhdGhlciB0aGFu IHRoaXMgZXh0ZW5zaWJsZSBiaXQgbWFwIHZhbHVlPw0KICA2LiAgUmVnYXJkaW5nICJQU0Mgc2Vz c2lvbnMiIC0gSW4gc2VjdGlvbiA5LjMgeW91IGludHJvZHVjZSBhIG5ldyBjb25jZXB0IG9mIFBT QyBzZXNzaW9uLCB3aXRob3V0IGFueSBkZWZpbml0aW9uIG9mIHdoZW4gdGhpcyBzZXNzaW9uIGJl Z2lucyBvciBlbmRzLiBDb3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgaXMgbWVhbnQgYnkgdGhl ICJsaWZlIG9mIGEgUFNDIHNlc3Npb24iPyBVbnRpbCBub3csIEkgd2FzIHVuZGVyIHRoZSBpbXBy ZXNzaW9uIHRoYXQgbGluZWFyIHByb3RlY3Rpb24gc3RhcnRlZCB3aXRoIHRoZSBjcmVhdGlvbiBv ZiB0aGUgcHJvdGVjdGlvbiBkb21haW4gYW5kIGNvbnRpbnVlZCB1bnRpbCB0aGUgcGF0aHMgd2Vy ZSB0b3JuIGRvd24uIElzIHRoaXMgaW5jb3JyZWN0Pw0KICA3LiAgVGhlcmUgaXMgYSBzdGF0ZW1l bnQgaW4gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA5LjMgdGhhdCBzdGF0ZXMgIlJG QzYzNzggZG9lcyBub3QgZGVmaW5lIGhvdyB0byBoYW5kbGUgYW4gdW5yZWNvZ25pemVkIFRMVi4i IEFjdHVhbGx5LCB3aGF0IFJGQzYzNzggZGVmaW5lcyBpcyAidGhlcmUgYXJlIG5vIFRMViB1bml0 cyBkZWZpbmVkIGZvciB0aGUgYmFzaWMgUFNDIG9wZXJhdGlvbiIgYW5kIHRoZXJlZm9yZSB0aGUg VExWcyBhcmUgaWdub3JlZC4gQW5vdGhlciByZWFzb24sIElNTywgdG8gY2hhbmdlIHRoZSB2ZXJz aW9uIG51bWJlciBvZiB0aGUgcHJvdG9jb2wgaW4gdGhpcyBkcmFmdC4NCiAgOC4gIEl0IGlzIHVu Y2xlYXIgdG8gbWUgLSB3aHkgd2hlbiByZWNlaXZpbmcgYSBTRC1QIGluZGljYXRpb24gaW4gTm9y bWFsIHdoeSB5b3UgY29uc2lkZXIgdGhpcyB0byBiZSAiVW5hdmFpYWJsZSIgc2luY2UgdGhlIGFj dGlvbiB0YWtlbiBmb3IgYW4gU0Qgc2l0dWF0aW9uIGlzIHRvIHBvc3NpYmx5IHRyYW5zbWl0IG9u IGJvdGggVyAmIFAuDQoNCkkgcGxhbiBvbiBzdWJtaXR0aW5nIHNvbWUgZWRpdG9yaWFsIGNvbW1l bnRzIGluIGEgZnV0dXJlIHBvc3QsIGJ1dCB3b3VsZCBsaWtlIHRvIGdldCBzb21lIGNsYXJpZmlj YXRpb24gb24gdGhlc2UgcG9pbnRzIGJlZm9yZSB0aGUgZHJhZnQgYWR2YW5jZXMgdG8gYWNjZXB0 YW5jZS4NCg0KVGhhbngsDQp5YWFjb3YNCg0KDQpPbiBNb24sIEphbiAyMCwgMjAxNCBhdCA0OjI4 IEFNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+IHdyb3RlOg0K V29ya2luZyBHcm91cCwNCg0KVGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIG9uDQpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS4NCg0KUGxlYXNlIGZp bmQgdGhlIGRvY3VtZW50IGF0Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUvDQoNClRoZSBkb2N1bWVudCBlZGl0b3JzIGhhcyBhbHNv IHN1cHBsaWVkIGEgImRpZmYtbGlzdCIgYmV0d2Vlbg0KdmVyc2lvbiAtMDAgYW5kIC0wMSBhdDoN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMTEz MzguaHRtbA0KDQpJVFUtVCBTRzE1IGhhcyBhZHZpc2VkIHVzIHRoYXQgdGhpcyBkb2N1bWVudCBp cyBhIG5lY2Vzc2FyeSByZWZlcmVuY2UNCmZvciBkb2N1bWVudHMgdGhhdCBpcyBwbGFubmVkIHRv IGdvIGludG8gdGhlIElUVS1UIGFwcHJvdmFsIHByb2Nlc3MNCmZyb20gdGhlIFNHMTUgbWVldGlu ZyBlbmQgb2YgTWFyY2ggLyBiZWdpbm5pbmcgb2YgQXByaWwuIEVkaXRvcnMsDQphdXRob3JzIGFu ZCBjaGFpcnMgaGFzIHB1dCBpbiBxdWl0ZSBhbiBlZmZvcnQgdG8gbWFrZSB0aGlzIGRvY3VtZW50 DQpyZWFkeS4gVGhlIHNjaGVkdWxlIGlzIHZlcnkgdGlnaHQuDQoNCldlIGFyZSBub3cgZG9pbmcg c2V2ZXJhbCByZXZpZXcgc3RlcHMgaW4gcGFyYWxsZWwNCg0KLSB0aGUgbm9ybWFsIHdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsLCBwbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZQ0KICBtcGxz IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGll dGYub3JnPikNCi0gdGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIHJldmlld2VkIHRoaXMgZG9jdW1l bnQgYXMgcGFydCBvZiB0aGUNCiAgbXBscy1ydCByZXZpZXcsIG5vcm1hbGx5IHdlIGRvIGEgd2cg Y2hhaXIgcmV2aWV3IGJlZm9yZSBzdGFydGluZyB0aGUNCiAgd2dsYywgdGhpcyByZXZpZXcgd2ls bCBub3cgdGFrZSBwbGFjZSBpbiBwYXJhbGxlbA0KLSBhZnRlciB0aGUgd2dsYyBhbmQgcHVibGlj YXRpb24gcmVxdWVzdCB0aGVyZSBpcyBhbiBBRCBldmFsdWF0aW9uLA0KICB0aGlzIHdpbGwgbm93 IGFsc28gdGFrZSBwbGFjZSBpbiBwYXJhbGxlbCB3aXRoIHRoZSB3Z2xjDQoNClRoZSBlZGl0b3Jz IGFuZCBhdXRob3JzIGFyZSBhZHZpc2VkIHRvIHRyeSB0byByZXNvbHZlIGFzIG1hbnkgb2YgdGhl DQpjb21tZW50cyBhcyBwb3NzaWJsZSAob24gdGhlIG1haWxpbmcgbGlzdCkgYXMgdGhleSBjb21l IGluLCBidXQgbm90IHRvDQpwb3N0IHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgdW50aWwg dGhlIHdnbGMgaXMgY2xvc2VkIGFuZCB0aGUNCmNvbW1lbnRzIGFyZSByZXNvbHZlZC4NCg0KVGhp cyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIEZlYnJ1YXJ5IDNyZC4NCg0KL0xvYQ0KZm9y IHRoZSBNUExTIFdHIGNvLWNoYWlycw0KLS0NCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAg ICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxtYWlsdG86bG9hQG1haWww MS5odWF3ZWkuY29tPg0KU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAg ICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1 bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NDx0ZWw6JTJCNDYlMjA3MzklMjA4MSUy MDIxJTIwNjQ+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQoNCi0tDQpU aGFueCBhbmQgQlIsDQp5YWFjb3YNCg0KU3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5 DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3DCCSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPllhYWNvdiw8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPkFnYWluLCB0aGFua3MgZm9yIHRoZSBjb21tZW50cy4NCjwv Zm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+ SSByZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIGhlbHAgb24gdGhpcyBkb2N1bWVudC48L2ZvbnQ+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPlRoZSBmb2xs b3dpbmdzIGFyZSBteSByZXNwb25zZXMgdG8geW91ciBjb21tZW50czo8L2ZvbnQ+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPj09PT09PT09PC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4jMS4g WWVzLCB5b3UgZGVzY3JpYmVkIHRoZSBjb3JyZWN0IGJlaGF2aW9yIG9mIE1TLVcuIEFzIHlvdSBp bmRpY2F0ZWQsIE1TIGFuZCBFWEVSIGFyZSBzdXBwb3NlZCB0byBiZSBpZ25vcmVkIHdoaWxlIE1T LVcgaXMgaW4gZWZmZWN0LjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+IzIuIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbW9kaWZ5IHRoZSBv cGVyYXRpb24gb2YgdGhlIHNlbGVjdG9yIGRlc2NyaWJlZCBpbiBSRkM2Mzc4LiBBY2NvcmRpbmcg dG8gUkZDNjM3OCwgdGhlIHNlbGVjdG9yIHNlbGVjdHMgdGhlIHRyYWZmaWMgZnJvbSBvbmx5IG9u ZSBvZiB0aGUgcGF0aHMgbm8NCiBtYXR0ZXIgaWYgdGhlIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJl IGlzIDE6MSBvciAxJiM0MzsxLiBJZiB5b3UgdGhpbmsgaXQgaXMgYXBwcm9wcmlhdGUgdG8gbWFr ZSB0aGlzIGNsZWFyLCB0aGVuIHdlIGNhbiBhZGQgc29tZXRoaW5nIGxpa2U6DQo8L2ZvbnQ+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIiBsYW5nPSJFTi1VUyI+ 4oCcVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBtb2RpZnkgdGhlIG9wZXJhdGlvbiBvZiB0aGUgc2Vs ZWN0b3IgYXQgdGhlIHNpbmsgTEVSIGRlc2NyaWJlZCBpbiBSRkMgNjM3OC4gVGhlIHNlbGVjdG9y IGF0IHRoZSBzaW5rIExFUiBjaG9vc2VzIGVpdGhlciB0aGUgd29ya2luZw0KIG9yIHByb3RlY3Rp b24gcGF0aCBmcm9tIHdoaWNoIHRvIHJlY2VpdmUgdGhlIG5vcm1hbCB0cmFmZmljIGluIGJvdGgg MToxIGFuZCAxJiM0MzsxIGFyY2hpdGVjdHVyZXMuIFRoZSBwb3NpdGlvbiBvZiB0aGUgc2VsZWN0 b3IsIGkuZS4sIHdoaWNoIHBhdGggdG8gcmVjZWl2ZSB0aGUgdHJhZmZpYywgaXMgZGV0ZXJtaW5l ZCBieSB0aGUgUFNDIHByb3RvY29sIGluIGJpZGlyZWN0aW9uYWwgc3dpdGNoaW5nIG9yIGJ5IHRo ZSBsb2NhbCBpbnB1dCBpbiB1bmlkaXJlY3Rpb25hbA0KIHN3aXRjaGluZy7igJ08L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+QXMgYSBtYXR0ZXIgb2Yg ZmFjdCwgYWNjb3JkaW5nIHRvIFJGQyA0NDI3IChhbmQgYWxsIHRoZSBJVFUtVCBwcm90ZWN0aW9u IGRvY3VtZW50cyksIGEgc2VsZWN0b3IgcmVmZXJzIHRvIHRoZSBlbnRpdHkgYXQgdGhlIHNpbmsg bm9kZSBvbmx5LiBGb3IgdGhlIHNvdXJjZSBub2RlLCBhIGJyaWRnZQ0KIGlzIHVzZWQgdG8gY2hv b3NlIHdoaWNoIHBhdGggKG9uZSBvZiB0d28gcGF0aHMgaW4gMToxLCBvciBib3RoIHBhdGhzIGlu IDEmIzQzOzEpIHRvIHRyYW5zbWl0IHRoZSB0cmFmZmljLiBUaGVyZWZvcmUsIOKAnHRoZSBzZWxl Y3RvciBpbiB0aGUgc2luayBMRVLigJ0gaXMgcmVkdW5kYW50IGFuZCBzaG91bGQgaGF2ZSBiZWVu IHJlcGxhY2VkIHdpdGgganVzdCDigJx0aGUgc2VsZWN0b3LigJ0uIEJ1dCwgdGhlIGRlc2NyaXB0 aW9ucyBvZiB0aGUgc2VsZWN0b3IgYW5kIGJyaWRnZQ0KIGluIFJGQyA2Mzc4IGFyZSBzb21ld2hh dCBkaWZmZXJlbnQuIEluIFJGQyA2Mzc4LCB0aGUgc2VsZWN0b3IgaXMgdXNlZCBmb3IgYm90aCB0 cmFuc21pdHRpbmcgYW5kIHJlY2VpdmluZyB0aGUgdHJhZmZpYywgd2hpbGUgdGhlIGJyaWRnZSBp cyB1c2VkIGZvciB0cmFuc21pdHRpbmcgb25seS4gVGhlIGRlc2NyaXB0aW9ucyBpbiBSRkMgNjM3 OCBhcmUgbm90IHF1aXRlIGFsaWduZWQgd2l0aCBSRkMgNDQyNyAoYW5kIG90aGVyIElUVS1UIGRv Y3MpLg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQi IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj4jMy4gQWdhaW4sIHRoaXMgaXMgZHVlIHRvIHRoZSBkaWZmZXJlbnQgdW5kZXJzdGFu ZGluZyBvbiB0aGUgc2VsZWN0b3IuIElmIHlvdSBzdGljayB0byB0aGUgdGVybWlub2xvZ3kgZGVm aW5lZCBpbiBSRkMgNDQyNyBhbmQgSVRVLVQsIHRoZW4geW91IG1heSBub3QgaGF2ZSB0aGUgaXNz dWUgd2l0aA0KIGN1cnJlbnQgc2VudGVuY2VzLiBJbiB0aGUgbWVhbnRpbWUsIGFzIEkgZGlkIGlu ICMyLCBJIGNhbiBhZGQg4oCcaW4gdGhlIHNpbmsgTEVS4oCdIGFmdGVyIGV2ZXJ5IOKAnHRoZSBz ZWxlY3RvcuKAnS4gSW4gb3RoZXIgd29yZHMsICZxdW90OzwvZm9udD48L3NwYW4+PHNwYW4gc3R5 bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIiBsYW5nPSJFTi1VUyI+dGhlIHBhdGggZnJv bSB3aGljaCB0aGUgc2VsZWN0b3IgZG9lcyBub3Qgc2VsZWN0IHRoZSB1c2VyIGRhdGENCiB0cmFm ZmljPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4m cXVvdDsgY2FuIGJlIHJlcGxhY2VkIHdpdGgg4oCcJnF1b3Q7PC9mb250Pjwvc3Bhbj48c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciIGxhbmc9IkVOLVVTIj50aGUgcGF0aCBm cm9tIHdoaWNoIHRoZSBzZWxlY3RvciBhdCB0aGUgc2luayBMRVIgZG9lcyBub3Qgc2VsZWN0IHRo ZSB1c2VyIGRhdGEgdHJhZmZpYzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i 66eR7J2AIOqzoOuUlSI+JnF1b3Q7PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj4jNC4gVGhlIGFjdGlvbiBvbiB3aGljaCBwYXRoIHRoZSBM RVIgc2hvdWxkIHNlbmQgdGhlIHRyYWZmaWMgaXMgdGhlIHNhbWUsIGJ1dCB0aGUgc2luayBub2Rl IHNob3VsZCBkZXRlcm1pbmUgZnJvbSB3aGljaCBwYXRoIHRoZSB0cmFmZmljIHNob3VsZCBiZSBy ZWNlaXZlZC4gSW4gb3JkZXIgdG8NCiBkZXRlcm1pbmUgdGhlIHBvc2l0aW9uIG9mIHRoZSBzZWxl Y3RvciAqYXQgdGhlIHNpbmsgbm9kZSosIHdlIG5lZWQgdG8gcmVzb2x2ZSB0aGUgY29uZmxpY3Qu DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPiM1LiBJIHRvdGFsbHkgYWdyZWUgd2l0aCB5b3UuIFBsZWFzZSBzZWUgbXkgZWFybGllciBl bWFpbCBvbiB2ZXJzaW9uIG51bWJlci4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+IzYuIFlvdXIgaW1wcmVzc2lvbiBvbiB0aGUgbGlu ZWFyIHByb3RlY3Rpb24gaXMgdGhlIHNhbWUgYXMgbWluZS4gVGhpcyBzZWN0aW9uIG5lZWRzIHRv IGJlIHJld3JpdHRlbi4gSW4gbXkgb3Bpbmlvbiwgd2Ugc2hvdWxkIG5vdCB1c2UgdGhlIHRlcm0s IHRoZSBsaWZlIG9mIFBTQyBzZXNzaW9uLg0KIEFzIEkgbWVudGlvbmVkIGluIG15IGVtYWlsIHJl c3BvbmRpbmcgdG8gdGhlIEFEIFJldmlldyBjb21tZW50cywgU2VjdGlvbiA5IHNob3VsZCBiZSBy ZXdyaXR0ZW4gKG9yIHJlbW92ZWQgaWYgd2UgY2FuIGNoYW5nZSB0aGUgdmVyc2lvbiBudW1iZXIp LiBJbiBteSBvcGluaW9uLCB5b3VyIHN1Z2dlc3Rpb24gaW4gIzUgaXMgYWxzbyBiZXR0ZXIgdGhh biBhcyBpcyBub3cuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPiM3LiBJIHRvdGFsbHkgYWdyZWUgd2l0aCB5b3Ugb24gY2hhbmdpbmcg dGhlIHZlcnNpb24gbnVtYmVyLjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJ R046IGxlZnQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQt QlJFQUs6IGtlZXAtYWxsOyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj4jOC4gV2UgZm9sbG93ZWQgdGhlIHNhbWUgZ3JvdXBpbmcgYXMgaW4gUkZDIDYz NzguIEluIFNlY3Rpb24gNC4zLjMuMiBvZiBSRkMgNjM3OCwgdGhlIHNlY29uZCBwYXJhZ3JhcGgg c2F5czo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5F LUhFSUdIVDogbm9ybWFsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBXT1JELUJSRUFLOiBrZWVwLWFs bDsgbXNvLWxheW91dC1ncmlkLWFsaWduOiBub25lIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7IG1zby1iaWRpLWZvbnQt c2l6ZTogMTAuMHB0OyBtc28tYmlkaS1mb250LWZhbWlseTogQ291cmllcjsgbXNvLWZvbnQta2Vy bmluZzogMHB0IiBsYW5nPSJFTi1VUyI+VGhlIHByb3RlY3Rpb24gZG9tYWluIHdpbGwgZXhpdCB0 aGUgVW5hdmFpbGFibGUgc3RhdGUgYW5kIHJldmVydCB0bzwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i VEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgTUFSR0lOOiAwY20gMGNtIDBw dDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBD b3VyaWVyOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6 IENvdXJpZXI7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgbGFuZz0iRU4tVVMiPnRoZSBOb3JtYWwg c3RhdGUgd2hlbiBlaXRoZXIgdGhlIG9wZXJhdG9yIGNsZWFycyB0aGUgTG9ja291dCBjb21tYW5k PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogbm9y bWFsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLWxheW91 dC1ncmlkLWFsaWduOiBub25lIiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0 OyBtc28tYmlkaS1mb250LWZhbWlseTogQ291cmllcjsgbXNvLWZvbnQta2VybmluZzogMHB0IiBs YW5nPSJFTi1VUyI+b3IgdGhlIHByb3RlY3Rpb24gcGF0aCByZWNvdmVycyBmcm9tIHRoZSBzaWdu YWwgZmFpbCBvciBkZWdyYWRlZDwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJMSU5FLUhFSUdIVDogMTE1JTsg Rk9OVC1GQU1JTFk6IENvdXJpZXI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYmlk aS1mb250LWZhbWlseTogQ291cmllcjsgbXNvLWZvbnQta2VybmluZzogMHB0IiBsYW5nPSJFTi1V UyI+c2l0dWF0aW9uLjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQi IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5CYXNlZCB1cG9uIHRoaXMsIHdlIHB1dCBTRC1QIGluIFVuYXZhaWxhYmxlIHN0YXRl LiBBcyB5b3Uga25vdywgdGhlIG5hbWUgb2YgdGhlIHN0YXRlIGRvZXMgbm90IGFmZmVjdCB0aGUg YWN0aW9uIHRha2VuIGJ5IHRoZSBQU0MgcHJvY2Vzcy4gV2hhdCBhZmZlY3RzIHRoZSBhY3Rpb24g aXMgdGhlDQogZXh0ZW5kZWQgc3RhdGUsIHdoaWNoIHNob3dzIHRoZSByZXF1ZXN0IGFuZCB0aGUg c291cmNlIG9mIHRoZSByZXF1ZXN0LiBJZiB5b3Ugd2FudCB0byBzdWdnZXN0IGFueSBvdGhlciBh cHByb3ByaWF0ZSBzdGF0ZSwgSSBhbSByZWFkeSB0byBoZWFyLg0KPC9mb250Pjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj49PT09PT09PT09PTwvZm9u dD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+QmVz dCByZWdhcmRzLDwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAx MHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20g MGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj5KZW9uZy1kb25nPC9mb250Pjwvc3Bhbj48L3A+DQo8YnI+DQo8YnI+ DQo8ZGl2IGlkPSJNYWlsU2lnblNlbnQiPjxicj4NCjwvZGl2Pg0KPGhyIHRhYmluZGV4PSItMSI+ DQo8Yj5Gcm9tIDogPC9iPiZxdW90O1lhYWNvdiBXZWluZ2FydGVuJnF1b3Q7ICZsdDt3eWFhY292 QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTQtMDEtMjggMDU6MTI6MTYgKCAm IzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5Mb2EgQW5kZXJzc29uICZsdDtsb2FAcGkubnUm Z3Q7PGJyPg0KPGI+Q2MgOiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDss IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnICZsdDttcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y ZyZndDssIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnICZsdDtkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyZndDssDQo8TVBMUy1BRFNAVE9P TFMuSUVURi5PUkc+Jmx0O21wbHMtYWRzQHRvb2xzLmlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3QgOiA8L2I+UmU6IFttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBkcmFmdC1pZXRmLW1w bHMtdHAtcHNjLWl0dS0wMTxicj4NCjxicj4NCjxkaXYgZGlyPSJsdHIiPkhpIGFsbCwNCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkkgaGF2ZSByZWFkIHRocm91Z2ggdGhlIGxhdGVzdCB2ZXJzaW9u IG9mIHRoaXMgZHJhZnQgYW5kIGhhdmUgYSBudW1iZXIgb2YgY29tbWVudHMgYW5kIHF1ZXN0aW9u cyByZWdhcmRpbmcgdGhpcyBkb2N1bWVudC4gV2hpbGUsIGluIGdlbmVyYWwsIEkgZmVlbCB0aGF0 IHRoZSBleHRlbnNpb25zIHRvIHRoZSBiZWhhdmlvciBvZiBSRkM2Mzc4IGFyZSBhcHByb3ByaWF0 ZSwgSSBmaW5kIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBzdGlsbCBpbiBuZWVkDQogb2YgcmVmaW5l bWVudCBpbiBpdHMgbGFuZ3VhZ2UgYW5kIGNsYXJpdHkgb2YgdGhlIGZ1bmN0aW9uYWxpdHkuIFdo aWxlIHNvbWUgb2YgdGhlIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBpcyBkZXNjcmliZWQsIHRo ZXJlIGFyZSBkaWZmZXJlbnQgY2FzZXMgb2YgdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCBpcyBlaXRo ZXIgbm90IGRlc2NyaWJlZCBvciBpcyByYXRoZXIgY29uZnVzaW5nLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+T25lIGJhc2ljIHF1ZXN0aW9uIGlzIC0gQ29uc2lkZXJpbmcgdGhhdCB0 aGlzIGRyYWZ0IGlzIHByb3Bvc2luZyBjaGFuZ2VzIHRvIHRoZSBiYXNpYyBvcGVyYXRpb24gb2Yg dGhlIFBTQyBwcm90b2NvbCwgTG9jYWwgUmVxdWVzdCBMb2dpYywgYW5kIHRoZSBQU0MgQ29udHJv bCBMb2dpYywgSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhhdCB0aGUgUFNDIFZlcnNpb24gbnVtYmVy IHNob3VsZCBjaGFuZ2UhIFdoeSB0aGVuLCBpcyB0aGVyZSBubyBtZW50aW9uDQogb2YgY2hhbmdp bmcgdGhlIHZlcnNpb24gdG8gYWxsb3cgbmV0d29ya3MgdGhhdCBzdXBwb3J0IHRoZSBmdW5jdGlv bmFsaXR5IGRlc2NyaWJlZCBpbiBSRkM2Mzc4IHRvIGNvbnRpbnVlIHRvIG9wZXJhdGU/PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgcHJv cG9zZWQgaW4gdGhlIGRyYWZ0LCBJIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgYW5kIGNv bW1lbnRzIC08L2Rpdj4NCjxkaXY+DQo8b2w+DQo8bGk+KGZvciBjbGFyaWZpY2F0aW9uKSBSZWdh cmRpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgTVMtVywgd2hhdCBpcyB0aGUgZnVuY3Rpb25hbGl0 eSBpZiB0aGUgZGF0YS10cmFmZmljIGlzIGN1cnJlbnRseSBvbiB0aGUgd29ya2luZyBwYXRoPyBT aW5jZSB0aGUgcHVycG9zZSBvZiB0aGUgY29tbWFuZCBpcyB0byBtb3ZlIHRoZSB0cmFmZmljIHRv IHRoZSB3b3JraW5nIHBhdGgsIHNob3VsZG4ndCBpdCBiZSBpZ25vcmVkPyBIb3dldmVyLCBhY2Nv cmRpbmcNCiB0byB0aGUgU3RhdGUgVHJhbnNpdGlvbiBUYWJsZSBpbiBzZWN0aW9uIDExLjEgLSBp ZiB0aGUgTVMtVyBpcyByZWNlaXZlZCBieSBhIExFUiBpbiBOb3JtYWwgU3RhdGUgaXQgdHJhbnNm ZXJzIHRvIFN3aXRjaGluZyBBZG1pbmlzdHJhdGl2ZSBTdGF0ZSEgVGhlIG1haW4gZWZmZWN0IHNl ZW1zIHRvIGJlIHRvIGNhdXNlIHRoZSBMRVIgdG8gaWdub3JlIGluY29taW5nIE1TIGFuZCBFWEVS IHJlcXVlc3RzICh0aGF0IGFyZSBub3QgaWdub3JlZCBpbiBOb3JtYWwNCiBTdGF0ZSkuIDwvbGk+ PGxpPlJlZ2FyZGluZyB0aGUgU0QgZnVuY3Rpb25hbGl0eSAtIGFmdGVyIGEgcHJldmlvdXMgZGlz Y3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IHRoZSBmdW5jdGlvbmFsaXR5IHdoZW4gcHJvdGVj dGluZyBmb3IgU0Qgc2l0dWF0aW9ucyAoZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4zKSB3YXMgY2hh bmdlZCB0byBlc3NlbnRpYWxseSBzd2l0Y2ggb3ZlciB0byB0aGUgTEVSIHRyYW5zbWl0dGluZyB0 aGUgcGFja2V0cyBvbiBib3RoIHRoZSB3b3JraW5nDQogYW5kIHByb3RlY3Rpb24gcGF0aHMgKGVz c2VudGlhbGx5IDEmIzQzOzEgdHJhbnNtaXNzaW9uKS4gSG93ZXZlciwgdGhlcmUgaXMgdmVyeSBs aXR0bGUgZGlzY3Vzc2lvbiBvZiBob3cgdGhlIHJlY2VpdmluZyBMRVIgaXMgc3VwcG9zZWQgdG8g c2VsZWN0IHRoZSBpbmNvbWluZyBwYWNrZXRzIHdoaWxlIGF2b2lkaW5nIGR1cGxpY2F0aW9uIG9m IGRhdGEuIENvdWxkIHBsZWFzZSBlbGFib3JhdGUgb24gdGhpcz8NCjwvbGk+PGxpPlJlZ2FyZGlu ZyB0aGUgU0QgZnVuY3Rpb25hbGl0eSAtIGFzIG1lbnRpb25lZCBpbiB0aGUgcHJldmlvdXMgcG9p bnQsIHdoZW4gcHJvdGVjdGluZyBmb3IgU0QsIHRoZSB0cmFuc21pdHRpbmcgTEVSIGR1cGxpY2F0 ZXMgdGhlIHBhY2tldHMgb24gYm90aCBXICZhbXA7IFAgYW5kIHRoZSByZWNlaXZpbmcgTEVSLCBw cmVzdW1hYmx5LCByZWFkcyB0aGUgZGF0YSBmcm9tIGVpdGhlciBwYXRoLCBhbmQgbWF5IGNob29z ZSBkaWZmZXJlbnRseSBmb3IgZGlmZmVyZW50DQogcGFja2V0cy4gSG93ZXZlciwgbGF0ZXIgaW4g c2VjdGlvbiA3LjQgKGFuZCBhZ2FpbiBpbiBzZWN0aW9uIDEwLjIpIHlvdSBpbnRyb2R1Y2UgYSBu ZXcgY29uY2VwdCBvZiAmcXVvdDtzdGFuZGJ5IHBhdGgmcXVvdDsgYXMgJnF1b3Q7dGhlIHBhdGgg ZnJvbSB3aGljaCB0aGUgc2VsZWN0b3IgZG9lcyBub3Qgc2VsZWN0IHRoZSB1c2VyIGRhdGEgdHJh ZmZpYyZxdW90OyBpbiByZWdhcmQgdG8gZGV0ZXJtaW5pbmcgdGhlIHByaW9yaXR5IG9mICZxdW90 O2NvbmZsaWN0aW5nJnF1b3Q7IFNELVcgYW5kIFNELVANCiB0cmlnZ2Vycy4gQ2FuIHlvdSBjbGFy aWZ5IHdoaWNoIG9mIHRoZSB0d28gcGF0aHMgdGhhdCBhcmUgYm90aCBjYXJyeWluZyB1c2VyIGRh dGEgaXMgdGhlIHN0YW5kYnkgcGF0aD8NCjwvbGk+PGxpPkZ1cnRoZXIgcmVnYXJkaW5nIHRoZSBw b2ludCBvZiAmcXVvdDtjb25mbGljdGluZyZxdW90OyBTRCB0cmlnZ2VycyAtIHNpbmNlIHRoZSBw cm90ZWN0aW9uIGZ1bmN0aW9uYWxpdHkgb2YgU0QgaXMgdG8gZHVwbGljYXRlIHRoZSBkYXRhIG9u IGJvdGggVyAmYW1wOyBQIC0gd2h5IGlzIHRoaXMgY29uc2lkZXJlZCBhIGNvbmZsaWN0LCBzaW5j ZSB0aGUgYWN0aW9uIGZvciBib3RoIHdpbGwgYmUgaWRlbnRpY2FsIC0gY29udGludWUgdHJhbnNt aXR0aW5nIG9uIGJvdGggVw0KICZhbXA7IFAuIFNvbWUgbW9yZSBjbGFyaWZpY2F0aW9uIHdvdWxk IGhlbHAuIDwvbGk+PGxpPlJlZ2FyZGluZyB0aGUgQVBTIG1vZGUgYW5kIHN1Yi1jYXBhYmlsaXRp ZXMgLSBZb3UgZGVzY3JpYmUgaW4gc2VjdGlvbiA5LjEgaG93IGFuIExFUiBjYW4gZGVjbGFyZSBp dHNlbGYgdG8gc3VwcG9ydCBvbmx5IHNvbWUgb2YgdGhlIGNhcGFiaWxpdGllcyBpbnRyb2R1Y2Vk IGluIHRoZSBkcmFmdCwgYW5kIHRoZW4gZGVzY3JpYmUgdGhlIEFQUyAmcXVvdDttb2RlJnF1b3Q7 IChTZWN0aW9uIDkuMi4yKSBhcyBkZWNsYXJhdGlvbiBvZiBzdXBwb3J0IGZvciBhbGwNCiBvZiB0 aGUgY2FwYWJpbGl0aWVzLCBpLmUuIEZsYWdzID0gMHhGODAwMDAwMC4gRnJvbSB0aGlzIHBvaW50 IG9uIChpbiBwYXJ0aWN1bGFyIHNlY3Rpb24gMTEpLCB5b3UgZGVzY3JpYmUgdGhlIGZ1bmN0aW9u YWxpdHkgZm9yIExFUiB0aGF0IGRlY2xhcmUgRmxhZ3M9IGVpdGhlciAweDAsIG9yIDB4RjgwMDAw MDAsIGhvd2V2ZXIsIHRoZXJlIGlzIG5vIGV4cGxhbmF0aW9uIGZvciBwYXRocyB0aGF0IGRlY2xh cmUgc29tZSBvdGhlciB2YWx1ZSBvZiBGbGFncw0KIChmb3IgZXhhbXBsZSwgMHg4MDAwMDAwIC0g c3VwcG9ydGluZyBvbmx5IHRoZSBFWEVSIGZ1bmN0aW9uYWxpdHkpLiBJcyB0aGVyZSBhIHJlYXNv biBmb3IgdGhpcz8gQXJlIHdlIGFzc3VtaW5nIHRoYXQgYWxsIHBhdGhzIHdpbGwgZWl0aGVyIHN1 cHBvcnQgUFNDIG9yIEFQUyBtb2RlcyBvbmx5PyBJZiBzbywgd2h5IG5vdCBqdXN0IGhhdmUgdHdv IHZhbHVlcyBmb3IgRmxhZ3MgcmF0aGVyIHRoYW4gdGhpcyBleHRlbnNpYmxlIGJpdCBtYXAgdmFs dWU/DQo8L2xpPjxsaT5SZWdhcmRpbmcgJnF1b3Q7UFNDIHNlc3Npb25zJnF1b3Q7IC0gSW4gc2Vj dGlvbiA5LjMgeW91IGludHJvZHVjZSBhIG5ldyBjb25jZXB0IG9mIFBTQyBzZXNzaW9uLCB3aXRo b3V0IGFueSBkZWZpbml0aW9uIG9mIHdoZW4gdGhpcyBzZXNzaW9uIGJlZ2lucyBvciBlbmRzLiBD b3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgaXMgbWVhbnQgYnkgdGhlICZxdW90O2xpZmUgb2Yg YSBQU0Mgc2Vzc2lvbiZxdW90Oz8gVW50aWwgbm93LCBJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lv bg0KIHRoYXQgbGluZWFyIHByb3RlY3Rpb24gc3RhcnRlZCB3aXRoIHRoZSBjcmVhdGlvbiBvZiB0 aGUgcHJvdGVjdGlvbiBkb21haW4gYW5kIGNvbnRpbnVlZCB1bnRpbCB0aGUgcGF0aHMgd2VyZSB0 b3JuIGRvd24uIElzIHRoaXMgaW5jb3JyZWN0Pw0KPC9saT48bGk+VGhlcmUgaXMgYSBzdGF0ZW1l bnQgaW4gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA5LjMgdGhhdCBzdGF0ZXMgJnF1 b3Q7UkZDNjM3OCBkb2VzIG5vdCBkZWZpbmUgaG93IHRvIGhhbmRsZSBhbiB1bnJlY29nbml6ZWQg VExWLiZxdW90OyBBY3R1YWxseSwgd2hhdCBSRkM2Mzc4IGRlZmluZXMgaXMgJnF1b3Q7dGhlcmUg YXJlIG5vIFRMViB1bml0cyBkZWZpbmVkIGZvciB0aGUgYmFzaWMgUFNDIG9wZXJhdGlvbiZxdW90 OyBhbmQgdGhlcmVmb3JlIHRoZSBUTFZzIGFyZQ0KIGlnbm9yZWQuIEFub3RoZXIgcmVhc29uLCBJ TU8sIHRvIGNoYW5nZSB0aGUgdmVyc2lvbiBudW1iZXIgb2YgdGhlIHByb3RvY29sIGluIHRoaXMg ZHJhZnQuDQo8L2xpPjxsaT5JdCBpcyB1bmNsZWFyIHRvIG1lIC0gd2h5IHdoZW4gcmVjZWl2aW5n IGEgU0QtUCBpbmRpY2F0aW9uIGluIE5vcm1hbCB3aHkgeW91IGNvbnNpZGVyIHRoaXMgdG8gYmUg JnF1b3Q7VW5hdmFpYWJsZSZxdW90OyBzaW5jZSB0aGUgYWN0aW9uIHRha2VuIGZvciBhbiBTRCBz aXR1YXRpb24gaXMgdG8gcG9zc2libHkgdHJhbnNtaXQgb24gYm90aCBXICZhbXA7IFAuPC9saT48 L29sPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj5JIHBsYW4gb24gc3VibWl0dGlu ZyBzb21lIGVkaXRvcmlhbCBjb21tZW50cyBpbiBhIGZ1dHVyZSBwb3N0LCBidXQgd291bGQgbGlr ZSB0byBnZXQgc29tZSBjbGFyaWZpY2F0aW9uIG9uIHRoZXNlIHBvaW50cyBiZWZvcmUgdGhlIGRy YWZ0IGFkdmFuY2VzIHRvIGFjY2VwdGFuY2UuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5UaGFueCw8L2Rpdj4NCjxkaXY+eWFhY292PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2V4dHJhIj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBK YW4gMjAsIDIwMTQgYXQgNDoyOCBBTSwgTG9hIEFuZGVyc3NvbiA8c3BhbiBkaXI9Imx0ciI+DQom bHQ7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwv YT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6 ICNjY2MgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6 IDFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCldvcmtpbmcgR3JvdXAsPGJyPg0KPGJyPg0KVGhp cyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPGJyPg0K ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUuPGJyPg0KPGJyPg0KUGxlYXNlIGZpbmQgdGhlIGRv Y3VtZW50IGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvPHU+PC91PmRvYy9kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLTx1Pjwv dT5pdHUvPC9hPjxicj4NCjxicj4NClRoZSBkb2N1bWVudCBlZGl0b3JzIGhhcyBhbHNvIHN1cHBs aWVkIGEgJnF1b3Q7ZGlmZi1saXN0JnF1b3Q7IGJldHdlZW48YnI+DQp2ZXJzaW9uIC0wMCBhbmQg LTAxIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9tcGxzL2N1cnJlbnQvbXNnMTEzMzguaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC08dT48L3U+YXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50Lzx1PjwvdT5tc2cx MTMzOC5odG1sPC9hPjxicj4NCjxicj4NCklUVS1UIFNHMTUgaGFzIGFkdmlzZWQgdXMgdGhhdCB0 aGlzIGRvY3VtZW50IGlzIGEgbmVjZXNzYXJ5IHJlZmVyZW5jZTxicj4NCmZvciBkb2N1bWVudHMg dGhhdCBpcyBwbGFubmVkIHRvIGdvIGludG8gdGhlIElUVS1UIGFwcHJvdmFsIHByb2Nlc3M8YnI+ DQpmcm9tIHRoZSBTRzE1IG1lZXRpbmcgZW5kIG9mIE1hcmNoIC8gYmVnaW5uaW5nIG9mIEFwcmls LiBFZGl0b3JzLDxicj4NCmF1dGhvcnMgYW5kIGNoYWlycyBoYXMgcHV0IGluIHF1aXRlIGFuIGVm Zm9ydCB0byBtYWtlIHRoaXMgZG9jdW1lbnQ8YnI+DQpyZWFkeS4gVGhlIHNjaGVkdWxlIGlzIHZl cnkgdGlnaHQuPGJyPg0KPGJyPg0KV2UgYXJlIG5vdyBkb2luZyBzZXZlcmFsIHJldmlldyBzdGVw cyBpbiBwYXJhbGxlbDxicj4NCjxicj4NCi0gdGhlIG5vcm1hbCB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCwgcGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGU8YnI+DQombmJzcDsgbXBscyB3 b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCAoPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPik8YnI+DQotIHRoZSB3b3JraW5nIGdy b3VwIGNoYWlycyByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlPGJyPg0KJm5i c3A7IG1wbHMtcnQgcmV2aWV3LCBub3JtYWxseSB3ZSBkbyBhIHdnIGNoYWlyIHJldmlldyBiZWZv cmUgc3RhcnRpbmcgdGhlPGJyPg0KJm5ic3A7IHdnbGMsIHRoaXMgcmV2aWV3IHdpbGwgbm93IHRh a2UgcGxhY2UgaW4gcGFyYWxsZWw8YnI+DQotIGFmdGVyIHRoZSB3Z2xjIGFuZCBwdWJsaWNhdGlv biByZXF1ZXN0IHRoZXJlIGlzIGFuIEFEIGV2YWx1YXRpb24sPGJyPg0KJm5ic3A7IHRoaXMgd2ls bCBub3cgYWxzbyB0YWtlIHBsYWNlIGluIHBhcmFsbGVsIHdpdGggdGhlIHdnbGM8YnI+DQo8YnI+ DQpUaGUgZWRpdG9ycyBhbmQgYXV0aG9ycyBhcmUgYWR2aXNlZCB0byB0cnkgdG8gcmVzb2x2ZSBh cyBtYW55IG9mIHRoZTxicj4NCmNvbW1lbnRzIGFzIHBvc3NpYmxlIChvbiB0aGUgbWFpbGluZyBs aXN0KSBhcyB0aGV5IGNvbWUgaW4sIGJ1dCBub3QgdG88YnI+DQpwb3N0IHRoZSBuZXcgdmVyc2lv biBvZiB0aGUgZHJhZnQgdW50aWwgdGhlIHdnbGMgaXMgY2xvc2VkIGFuZCB0aGU8YnI+DQpjb21t ZW50cyBhcmUgcmVzb2x2ZWQuPGJyPg0KPGJyPg0KVGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBlbmRzIEZlYnJ1YXJ5IDNyZC48YnI+DQo8YnI+DQovTG9hPGJyPg0KZm9yIHRoZSBNUExTIFdH IGNvLWNoYWlyczxzcGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij48YnI+ DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ZW1haWw6IDxhIGhyZWY9Im1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20iIHRhcmdl dD0iX2JsYW5rIj4NCmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvYT48YnI+DQpTZW5pb3IgTVBMUyBF eHBlcnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmxv YUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT48YnI+DQpIdWF3ZWkgVGVjaG5v bG9naWVzIChjb25zdWx0YW50KSAmbmJzcDsgJm5ic3A7IHBob25lOiA8YSBocmVmPSJ0ZWw6JTJC NDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHRhcmdldD0iX2JsYW5rIiB2YWx1ZT0iJiM0Mzs0Njcz OTgxMjE2NCI+DQomIzQzOzQ2IDczOSA4MSAyMSA2NDwvYT48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX188dT48L3U+X19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bXBsc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuLzx1PjwvdT5saXN0aW5mby9tcGxzPC9hPjxicj4NCjwvZm9udD48L3NwYW4+PC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KLS0gPGJyPg0KPGRpdiBkaXI9Imx0ciI+VGhhbnggYW5kIEJSLA0KPGRpdj55YWFjb3Y8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxpPlN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBv cnR1bml0eTwvaT48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B3DCCSMTP2etriinfo_-- From adrian@olddog.co.uk Tue Jan 28 03:23:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20511A0360 for ; Tue, 28 Jan 2014 03:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 TGdKeN89zXBP for ; Tue, 28 Jan 2014 03:23:39 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 24CEE1A01D2 for ; Tue, 28 Jan 2014 03:23:38 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0SBNZpI023629; Tue, 28 Jan 2014 11:23:35 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0SBNVua023542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Jan 2014 11:23:32 GMT From: "Adrian Farrel" To: References: Your message of "Mon, 27 Jan 2014 23:04:06 +0000." <022d01cf1bb4$1624fde0$426ef9a0$@olddog.co.uk> <201401280408.s0S48bot002466@maildrop2.v6ds.occnc.com> In-Reply-To: <201401280408.s0S48bot002466@maildrop2.v6ds.occnc.com> Date: Tue, 28 Jan 2014 11:23:30 -0000 Message-ID: <033c01cf1c1b$612c9480$2385bd80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLCmqL8/aJqAVVkXAfqmLyPrUo02ZizARWQ Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 11:23:43 -0000 Curtis, Thanks for all this. I'm good with the changes recorded here. Time to post AFAIK. A > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > Sent: 28 January 2014 04:09 > To: adrian@olddog.co.uk > Cc: curtis@ipv6.occnc.com; draft-ietf-mpls-forwarding.all@tools.ietf.org; > mpls@ietf.org > Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding > > > In message <022d01cf1bb4$1624fde0$426ef9a0$@olddog.co.uk> > "Adrian Farrel" writes: > > > > Hello Curtis, > > > > These replies modulo the conversation with Carlos. I find I can't read that > > conversation and back apply the results here :-( > > I'll summarize the outcome of that conversation with Carlo at the > bottom so we can have one thread. > > > [snip] > > > > > > Your acronym list is commendably thorough, but a little enthusiastic. > > > > > > If I provide a section with a list of acronyms, do I still have to > > > expand on first use. If so, AC, NSP, OAM, and a few others appear > > > before that section. > > > > Afraid so :-( > > OK. Expanded except RFC-Editor listed well known abbreviations. > > > > Given that this takes up only 17 lines in a 50 page document I'd > > > rather be thorough. > > > > Yup. OK. Go for it. > > > > [snip] > > > > > > I think Curtis may have heard this before :-) > > > > The "preferred" (by the RFC editor) expansion of ECMP is > > > > "Equal-Cost Multipath" > > > > > > The form without the hyphen is more common, even among recent > > > documents. I prefer to keep it without the hyphen. > > > > A discussion for a rainy day with the RFC Editor. > > Leave as is. > > Cheers. > > > > > Section 1.3 bullet 5 > > > > > > > > 5. The implementer and system designer MUST support pseudowire > > > > control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is > > > > being used on a pseudowire. > > > > > > > > The wording is a bit odd. "The implementation and system design..."? > > > > > > > > Ditto bullets 6 and 7 > > > > > > Target audience is explained in Section 1.4. If you like I can flip > > > Section 1.3 and 1.4 so target audience is first, then use of the roles > > > called for in the target audience section won't seem quite so odd. > > > > No issue with the section order. > > Just puzzled by "the implementer MUST support" when I (pedantically) thought > > that the implementer supporting something might not be the same as the > > implementation supporting it. > > > > Not a big deal. > > Good point. Its changed. > > > > > Section 1.3 > > > > > > > > While there is not wrong with the statements made in the bullets, some > > > > of the later ones refer to recent additions to the MPLS suite. Yet the > > > > list is presented as "there were some misconceptions." Clearly the > > > > early silicon did not have misconceptions about the inclusion of entropy > > > > labels. > > > > > > > > Just tweak the words at the top of the list? > > > > > > I'd like to keep that as is and split into two lists. The second list > > > would have the last two items (fat-pw and EL). The first list would > > > end with "implement CW" (sic). > > > > > > OLD > > > > > > 6. The implementer and system designer SHOULD support adding a > > > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > > > feature for appropriate pseudowire types. See Section 2.4.3. > > > > > > 7. The implementer and system designer SHOULD support adding an MPLS > > > entropy label [RFC6790]. Deployments MAY enable this feature. > > > See Section 2.4.4. > > > > > > NEW > > > > > > The following statements provide clarification regarding more > > > recent requirements that are often missed. > > > > > > 1. The implementer and system designer SHOULD support adding a > > > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > > > feature for appropriate pseudowire types. See Section 2.4.3. > > > > > > 2. The implementer and system designer SHOULD support adding an MPLS > > > entropy label [RFC6790]. Deployments MAY enable this feature. > > > See Section 2.4.4. > > > > > > I've made this change. Let me know if this is not OK. > > > > That's fine. > > > > > > 2.1.1 > > > > > > > > Maybe the first paragraph should clarify "special purpose labels at > > > > the top of the label stack" > > > > > > That phrase doesn't appear anywhere in the document. Exactly what am > > > I clarifying? What to do with unknown special purpose labels is in > > > the last paragraph of this subsection. > > > > WTF? > > You have to wonder where these senile ADs get their ideas. > > > > Complete brain fart. Sorry. > > > > [snip] > > > > > > While per platform label space is mentioned in 2.1.7 I wonder whether > > > > more information on per platform and per interface label spaces is > > > > needed. I recall early implementations that got very confused when > > > > parallel interfaces used the same label for different purposes. > > > > > > > > I guess the point there is that you cannot assume that your neighbor > > > > is or is not using the per platform label space. > > > > > > > > Upstream label allocation may also come into this. > > > > > > The only mention of label allocation is that MPLS FRR bypass method > > > (more formally known as facilitles backup) uses platform label space. > > > > > > The only reason platform label space is of any significance in a > > > document about forwarding is "The use of platform label space impacts > > > the size of the LSR ILM for LSR with a very large number of > > > interfaces." > > > > > > Label allocation, per platform or per interface and upstream or > > > downstream, is not a forwarding issue. It is a software issue > > > and a matter of getting the protocol bits right. Therefore I think > > > expanding any further on label allocation should be out of scope. > > > > OK. I'm convinced. > > > > > > 2.1.8.1 > > > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > > core is using multipath, reordering will be far more common. If > > > > this is occurring, the best solution is to use CW on the edge, > > > > rather than try to fix the reordering using resequencing. > > > > > > > > Completely agree, but isn't the sequence number contained in a control > > > > word meaning that the resequencing could, in any case, not be done > > > > without using a control word? > > > > > > I suppose you can't fix reordering caused by not using CW without the > > > sequence number in the CW. That is going to require fixing the text. > > > > > > OLD > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > core is using multipath, reordering will be far more common. > > > If this is occurring, the best solution is to use CW on the > > > edge, rather than try to fix the reordering using resequencing. > > > > > > NEW > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > core is using multipath, reordering will be far more common. > > > If this is occurring, using CW on the edge will solve the > > > problem. Without CW, resequencing is not possible since the > > > sequence number is contained in the CW. > > > > > > That was a big oops on our part. > > > > Well, on the scale of IETF oopsies, I don't think you score too high. Maybe > > Narten could run a weekly script? > > > > [snip] > > > > > > Should 2.2 distinguish the order of magnitude of replication at branch > > > > nodes? This impacts the replication method used (some devices make a > > > > copy and cycle around, some devices can do multiple copies at once). On > > > > the whole is no different from IP multicast processing except (as you > > > > note) that each outgoing packet may be different by its label value. > > > > > > Is it possible to quantify the fanout? YMMV? > > > > > > The only thing I could say is that an implementation may need to make > > > lots of copies in some roles (access routers for example). > > > > > > Making a copy and cycling yields poor performance but for low > > > multicast traffic volumes might be OK. But you are right - some > > > mostly low-end-ish chips to this. > > > > > > I'm not sure I can describe how multicast with high fanout is done > > > without wading into implementation details of specific vendors. > > > > > > Perhaps the best I can do is add this: > > > > > > Careful consideration should be given to the performance > > > characteristics of high fanout multicast for equipment that is > > > intended to be used in such a role. > > > > > > I'll add this before the last paragraph in the section. > > > > That works. > > > > > > 2.4 > > > > > > > > So obvious you didn't say it? > > > > > > > > In order to support an adequately balanced load distribution across > > > > multiple links, IP header information must be used. Common practice > > > > today is to reinspect the IP headers at each LSR and use the label > > > > stack and IP header information in a hash performed at each LSR. > > > > Further details are provided in Section 2.4.5. > > > > > > > > Missing is the statement that a single "flow" must not be distributed > > > > across multiple paths because of the implication for potentially > > > > significant packet misordering. And feeding that is a common requirement > > > > that such packet misordering must not occur because applications and > > > > transport protocol implementations cannot survive such misordering. > > > > > > Yes. That requirement was missed. Add new second paragraph to this > > > subsection. > > > > > > The Differentiated Services requirements for good reasons dictate > > > that packets within a common microflow SHOULD NOT be reordered > > > [RFC2474]. Service providers generally impose stronger > > > requirements, commonly requiring that packets within a microflow > > > MUST NOT be reordered except in rare circumstances such as load > > > balancing across multiple links or path change for load balancing > > > or path change for other reason. > > > > > > Another SP requirement is stated here and I'm quite sure this > > > requirement is well accepted. > > > > Looks good. > > > > > > 2.4.2 uses "composite link" and "component link". I suggest picking just > > > > one term. > > > > > > They are two different things. Two or more component links make up a > > > composite link. Knowing that, give it another read please. > > > > > > I'd rather not cite draft-ietf-rtgwg-cl-requirements as an > > > informational reference just for this one term. In favor of citing > > > it, draft-ietf-rtgwg-cl-requirements is moving along. Against citing > > > it is there is far less than a ground swell of providers calling for > > > the full set of things asked for in draft-ietf-rtgwg-cl-requirements. > > > > Yes. Sorry. It has been a looooooooong time since I had a pass on the CL > > document. Atrophy. > > Its also in Gwiz.8080 or something like that. > > > > > 2.4.5.1 notes that special purpose and extended special purpose labels > > > > need to be excluded from the hash. Good. > > > > But it seems that some special purpose labels will indicate that the > > > > next label stack entry contains a label with special meaning. (ELI is > > > > an example that we specifically don't have to worry about.) > > > > How do we handle that? > > > > Should we be dividing up the extended special purpose label space to > > > > have one set of code points meaning "just this label is special" and > > > > another set meaning "this label is special and the next label stack > > > > entry is magic"? > > > > > > I did list ELI (bullet 2) before the more general rule of not useing > > > special purpose labels. The ELI is not used, just the EL, so the text > > > could be considered correct as-is. > > > > > > So far the only special purpose label that is not just ignored and > > > skipped over is ELI. > > > > > > Regarding this being magic -- All of this is somewhat programable > > > specialized silicon magic. The silicon generally has some form of > > > very fast, very light weight parsing engine at the front of the > > > pipeline. One thing it does is pick out fields for load balance. > > > > > > The better silicon hashes as it goes rather that pick out a set of > > > fields and then hashes that set of fields when its done. When it sees > > > 13 it skips and hashes the next thing and stops hashing completely. > > > If it sees 0-12,14 it skips and continues. If it sees 15 it skips two > > > labels and continues. Its should be programable enough that if > > > someone defines a new ELI like label it is likely to be able to deal > > > with it. > > > > > > The not so good silicon has this all so hard wired that it won't be > > > able to do ELI without at least a respin. > > > > > > At most I could add "If a new special purpose label or extended > > > special purpose label is defined which requires special load balance > > > processing then, as is the case for the ELI label, a spacial action > > > may be needed rather than skipping the special purpose label or > > > extended special purpose label." I really don't think this is needed. > > > > You're right, and my worry is more about the special-purpose draft and the > > consequences of possibly adding other special purpose labels that have child > > labels associated. We certainly don't want to have to retrain the silicon at > > transit LSRs to specially know what to do for each new special-purpose label. > > Currently we propose that you don't hash on a special purpose label, but you > can > > carry on hashing immediately after. > > > > If I introduce the foo-label, your silicon will recognise it as special purpose, > > but it I say the label after the foo-label is magic you won't know that. > > > > A way to fix this is to have (just punting here) the top bit of the extended > > special purpose label range set mean "magic label follows". > > I added this: > > 4. If a new special purpose label or extended special purpose > label is defined which requires special load balance > processing, then, as is the case for the ELI label, a spacial > action may be needed rather than skipping the special purpose > label or extended special purpose label. > > This will be the new bullet 4, bumping down the old 4 and 5. > > > > > An issue that arises from the multipath support (2.4.5.1) is that > > > > hardware assumes that after a label stack entry with the S-bit set, > > > > there are only three possible next bytes... > > > > - a control word (indicated by b0000 or b0001) > > > > - an IPv4 header > > > > - an IPv6 header > > > > This is the case regardless of how the LSP was set up, and the next > > > > bytes cannot ever be further MPLS stack entries. > > > > > > Right. Note that in (5) is says that some SP will require IP headers > > > and some will require an ability to disable IP headers. > > > > > > The rule is really look for 4, 6, or anything else in the first > > > nibble. If 4 or 6 assume IP. If anything else stop. > > > > > > And yes if the payload is MPLS after a S-bit you have a screwed up > > > MPLS implementation to start with and you won't get load balance on > > > any set of MPLS labels after the first S-bit. This is a fact of life > > > in the field and is as it should be. > > > > > > > While this comes up 2.4.5.1 it may merit further discussion in an > > > > earlier section of the document. > > > > > > This text is part of 2.4. ("MPLS Multipath Techniques"). The third > > > paragraph contains "Further details are provided in Section 2.4.5." > > > Section 2.4.5. is "Fields Used for Multipath Load Balance". > > > > > > > I note that discussion of support of PWs without the CW drives you > > > > to say that hashing beyond the S-bit should be a configurable option > > > > which would (of course) support any payload including MPLS in MPLS > > > > with repeated bottom of stack. However, you might want to specifically > > > > preclude that. > > > > > > It says the same thing here in bullet 5 regarding being configurable. > > > The wording "ability to disable" is same as "configurable option". > > > > > > At no point in this document do we imply that looking beyond the S-bit > > > means looking at anything beyond the S-bit other than looking for IP. > > > This is very clear in [RFC4385] and [RFC4928] which is cited in the > > > text about PW CW. > > > > > > All it says in the places discusing PW is that without CW the traffic > > > might get reordered. > > > > > > If you feel that we at any point imply that lack of PW CW allows > > > looking at anything past the S-bit rather than just looking for an IP > > > header please point to where and we will have to correct that. I > > > looked at all occurances of CW and did not find anything. > > > > > > Bullet 5 is very clear that a 4 or 6 has to be found in the first > > > nibble of payload. > > > > OK. I misread bullet 5. > > OK > > > [snip] > > > > Thanks. > > Adrian > > Summary of conversation with Carlos: > > Adrian wrote: > >> Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, > >> L2TP, or LDP, are out of scope. > >> > >> I think s/LDP/UDP/ > > Carlos noted some wording issues in this sentence and suggested adding > citations for each. After some discussion: > > OLD (original) > > Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, > L2TP, or LDP, are out of scope. > > NEW > > Tunneling encapsulations carrying MPLS, such as MPLS in IP > [RFC4023], MPLS in GRE [RFC4023], MPLS in L2TPv3 [RFC4817], or MPLS > in UDP [I-D.ietf-mpls-in-udp], are out of scope. > > He also suggested the following. > > OLD > > Some IP encapsulations support tunneling, such as IP-in-IP, GRE, > L2TPv3, and IPSEC. These provide a greater source of entropy which > some provider networks carrying large amounts of tunneled traffic > - may need. > The use of tunneling header information is out of scope for this > document. > > NEW > > Some IP encapsulations support tunneling, such as IP-in-IP, GRE, > L2TPv3, and IPSEC. These provide a greater source of entropy which > some provider networks carrying large amounts of tunneled traffic > + may need, for example as used in [RFC5640] for GRE and L2TPv3. > The use of tunneling header information is out of scope for this > document. > > As part of that conversation it was noted that the following also had > no citations. > > OLD > > Support for other protocols that share a common Layer-4 header such > - as RTP, UDP-lite, SCTP and DCCP > SHOULD be provided, particularly for edge or access equipment where > additional entropy may be needed. > > NEW > > Support for other protocols that share a common Layer-4 header such > + as RTP [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960] and DCCP > + [RFC4340] > SHOULD be provided, particularly for edge or access equipment where > additional entropy may be needed. > > btw- this is wrt fields used in load balancing and is saying in effect > "use more than just port 6 and 17 (UDP and TCP)". > > Other than that, I looked at the list of informational references and > found the following do affect MPLS forwarding and therefore should be > promoted to normative. > > [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP > Extensions for Multiprotocol Label Switching", RFC 4950, > August 2007. > > [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. > Pignataro, "The Generalized TTL Security Mechanism > (GTSM)", RFC 5082, October 2007. > > [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit > Connectivity Verification (VCCV): A Control Channel for > Pseudowires", RFC 5085, December 2007. > > [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS > Multicast Encapsulations", RFC 5332, August 2008. > > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > (BFD)", RFC 5880, June 2010. > > [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, > "Bidirectional Forwarding Detection (BFD) for MPLS Label > Switched Paths (LSPs)", RFC 5884, June 2010. > > [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding > Detection (BFD) for the Pseudowire Virtual Circuit > Connectivity Verification (VCCV)", RFC 5885, June 2010. > > [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay > Measurement for MPLS Networks", RFC 6374, September 2011. > > [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay > Measurement Profile for MPLS-Based Transport Networks", > RFC 6375, September 2011. > > [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and > A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear > Protection", RFC 6378, October 2011. > > [RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., > and D. Ward, "MPLS Fault Management Operations, > Administration, and Maintenance (OAM)", RFC 6427, November > 2011. > > [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive > Connectivity Verification, Continuity Check, and Remote > Defect Indication for the MPLS Transport Profile", RFC > 6428, November 2011. > > [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security > Mechanism (GTSM) for the Label Distribution Protocol > (LDP)", RFC 6720, August 2012. > > [I-D.ietf-mpls-psc-updates] > Osborne, E., "Updates to PSC", draft-ietf-mpls-psc- > updates-00 (work in progress), October 2013. > > Upgrades were mostly due to BFD and MPLS-TP OAM. For example, direct > LM needs to be in hardware and most things related to protection. > > Note that "Updates to PSC" affects MPLS-TP protection state machine > which needs hardware assist if not direct support in hardware in order > to be fast. The race condition may be the most severe problem with > RFC 6378 state machine. > > If you think any of the above should be put back into informative, > please let me know. > > Curtis From loa@pi.nu Tue Jan 28 05:58:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF5D1A022A for ; Tue, 28 Jan 2014 05:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 FU4OIzrRfVOb for ; Tue, 28 Jan 2014 05:58:02 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1DC1A03F9 for ; Tue, 28 Jan 2014 05:58:02 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.65.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id DC64E180150F; Tue, 28 Jan 2014 14:57:56 +0100 (CET) Message-ID: <52E7B75F.6010805@pi.nu> Date: Tue, 28 Jan 2014 21:57:51 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <52DC89C3.3030003@pi.nu> In-Reply-To: <52DC89C3.3030003@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 13:58:05 -0000 Folks, I've reviewed this document (actually fourth or fifth time) and I have very few comments, I think Adrian covered all mine in his review. I had something that I thought were spelling errors, but turns out to be differences between UK and US English. I'm pretty sure that the RFC Editor will set that right (if it isn't already). There is one thing that sometimes makes hard to parse the document, the abbreviation WTR stands for "Wait to restore", the thing is that WTR can be a state, a message or a timer (given that I understand it correctly). When I discussed this earlier the answer has been "Well it is confusing, but that is how it is done!" I think at places where it necessary e.g. WTR are qualified with state, message or timer. I found one place where want to add a clarifying "state", "message" or "timer". page 13 last line - s/WTR expires/WTR timer expires page 20 3rd line from the - s/WTR expires/WTR timer expires page 25 Note 4 s/WTR/WTR state page 25 Note 6 s/WTR/WTR state page 27 Note 11 s/WTR/WTR state DNR may be a state or a message, for clarification page 27 note 11 s/DNR./DNR state. The same exercise maybe be done for EXER [command, message] (actually I think that for EXER this is done correctly), but it might valuable to check for all abbreviations that has double meaning. I don't think it is necessary or even motivated to do more about this, but it might be a good if readers of the document were aware of this. I think the document - modulo addressing comments in wglc - is ready to go. /Loa On 2014-01-20 10:28, Loa Andersson wrote: > Working Group, > > This is to start a two week working group last call on > draft-ietf-mpls-tp-psc-itu. > > Please find the document at: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ > > The document editors has also supplied a "diff-list" between > version -00 and -01 at: > http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html > > ITU-T SG15 has advised us that this document is a necessary reference > for documents that is planned to go into the ITU-T approval process > from the SG15 meeting end of March / beginning of April. Editors, > authors and chairs has put in quite an effort to make this document > ready. The schedule is very tight. > > We are now doing several review steps in parallel > > - the normal working group last call, please send your comments to the > mpls working group mailing list (mpls@ietf.org) > - the working group chairs reviewed this document as part of the > mpls-rt review, normally we do a wg chair review before starting the > wglc, this review will now take place in parallel > - after the wglc and publication request there is an AD evaluation, > this will now also take place in parallel with the wglc > > The editors and authors are advised to try to resolve as many of the > comments as possible (on the mailing list) as they come in, but not to > post the new version of the draft until the wglc is closed and the > comments are resolved. > > This working group last call ends February 3rd. > > /Loa > for the MPLS WG co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From eric.osborne@notcom.com Tue Jan 28 05:59:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AC71A03FE for ; Tue, 28 Jan 2014 05:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 2jVXoYOW3DxF for ; Tue, 28 Jan 2014 05:59:09 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id DF94D1A022A for ; Tue, 28 Jan 2014 05:59:08 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id n16so438699oag.9 for ; Tue, 28 Jan 2014 05:59:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XypHc1YuBHt1bXcDu0Y+lsFs5EAQM8OCtE/wG3KVw0s=; b=XKoyKcm00r/SsXqp06Q8wKeRBdwC0vnSmHVhuaz77Pz3XG8iUdT+fTIqixEHeDnJun 2yRGneNhCV0BmS9Nj51gLwPSvz8gPYiDzlMan8IolGTNUXhQF1TF4L9CiKFOVswC8ysf ziFtoeDra6moomh7X7tPaHgyrj4i9OMEoTAi/7q/osgACBcoByeOc1lgWuqF5qH/vtfc F7C3z4wKCPeTpEieVv7lZFCY0YgD9PAchWKa226YD9Ad5hBMUtIbryDIChZnaWhQXl0q Nm79IccgIFMdWSilylBr3n0ILV7b0q4exdi0+9M6odSTzw1N9iP74G5AO69FM2v0NVVp pHdw== X-Gm-Message-State: ALoCoQmJJpCbp8qObi0ZM9Lm/FhERpdZ5fv4wpb+l/mxIdeKGKNt+1v6bdKS9PwE9MWAzSSddaGt MIME-Version: 1.0 X-Received: by 10.60.157.130 with SMTP id wm2mr1217704oeb.31.1390917546214; Tue, 28 Jan 2014 05:59:06 -0800 (PST) Received: by 10.182.135.229 with HTTP; Tue, 28 Jan 2014 05:59:06 -0800 (PST) In-Reply-To: <201401272305.s0RN5Zxx095713@maildrop2.v6ds.occnc.com> References: <52E63702.20102@pi.nu> <201401272305.s0RN5Zxx095713@maildrop2.v6ds.occnc.com> Date: Tue, 28 Jan 2014 08:59:06 -0500 Message-ID: From: Eric Osborne To: curtis@ipv6.occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 28 Jan 2014 06:01:30 -0800 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-psc-updates@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-psc-updates-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 13:59:13 -0000 Sure, I can make that change, although I think it reads better if I forego expansion in favor of reusing the title from rfc6378. The current title is "Updates to PSC". "Updates to Protection Switching Coordination" looks clunky, IMO. What about "Updates to MPLS Transport Profile Linear Protection"? eric On Mon, Jan 27, 2014 at 6:05 PM, Curtis Villamizar wrote: > > In message <52E63702.20102@pi.nu> > Loa Andersson writes: > >> Working Group, >> >> This is to initiate a working group last call on >> draft-ietf-mpls-psc-updates. >> >> One reason for the timing, other than that the author thinks is ready >> for wglc, is that this document is normatively referenced in >> draft-ietf-mpls-tp-psc-itu which also is in wglc. >> >> There are no IPR disclosures against this document. >> >> Please send your comments to the mpls wg mailing list (mpls@ietf.org). >> >> This working group last call ends Feb 19=B40, 2014. >> >> /Loa >> for the MPLS wg chairs > > > The title needs to spell out PSC since there are three interpretations > of the acronym in IETF, the other two predating this one by many > years. > > Otherwise looks good. > > Curtis From loa@pi.nu Tue Jan 28 08:25:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA12F1A044A for ; Tue, 28 Jan 2014 08:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 5iwdh8RrYIv8 for ; Tue, 28 Jan 2014 08:25:30 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id CD8001A0443 for ; Tue, 28 Jan 2014 08:25:29 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.65.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D5A2E180150F; Tue, 28 Jan 2014 17:25:24 +0100 (CET) Message-ID: <52E7D9F0.7070204@pi.nu> Date: Wed, 29 Jan 2014 00:25:20 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Osborne , curtis@ipv6.occnc.com References: <52E63702.20102@pi.nu> <201401272305.s0RN5Zxx095713@maildrop2.v6ds.occnc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-psc-updates@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-psc-updates-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:25:32 -0000 Eric, This was Curtis' comment, but personally I have no problem changing the title as you have suggested. /Loa On 2014-01-28 21:59, Eric Osborne wrote: > Sure, I can make that change, although I think it reads better if I > forego expansion in favor of reusing the title from rfc6378. > > The current title is "Updates to PSC". > "Updates to Protection Switching Coordination" looks clunky, IMO. > > What about "Updates to MPLS Transport Profile Linear Protection"? > > > > eric > > > On Mon, Jan 27, 2014 at 6:05 PM, Curtis Villamizar > wrote: >> >> In message <52E63702.20102@pi.nu> >> Loa Andersson writes: >> >>> Working Group, >>> >>> This is to initiate a working group last call on >>> draft-ietf-mpls-psc-updates. >>> >>> One reason for the timing, other than that the author thinks is ready >>> for wglc, is that this document is normatively referenced in >>> draft-ietf-mpls-tp-psc-itu which also is in wglc. >>> >>> There are no IPR disclosures against this document. >>> >>> Please send your comments to the mpls wg mailing list (mpls@ietf.org). >>> >>> This working group last call ends Feb 19´0, 2014. >>> >>> /Loa >>> for the MPLS wg chairs >> >> >> The title needs to spell out PSC since there are three interpretations >> of the acronym in IETF, the other two predating this one by many >> years. >> >> Otherwise looks good. >> >> Curtis -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From touch@isi.edu Tue Jan 28 08:41:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D19A1A02EA; Tue, 28 Jan 2014 08:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 GWO1aLhAmlxH; Tue, 28 Jan 2014 08:41:55 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0A61A02D5; Tue, 28 Jan 2014 08:41:55 -0800 (PST) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s0SGecLE029899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jan 2014 08:40:41 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: Date: Tue, 28 Jan 2014 08:40:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu> <52E6B128.8060306@joelhalpern.com> <52E6B272.4030703@isi.edu> To: Edward Crabbe X-Mailer: Apple Mail (2.1827) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: joel jaeggli , "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:41:57 -0000 On Jan 27, 2014, at 4:25 PM, Edward Crabbe wrote: > I assume we're talking about the chksum issue here. If this is the = case, please go fix IPv6 by adding a hop by hop checksum extension = header and getting it implemented by vendors. ^_^ Please don't use UDP as a network layer. See how easy that works? > If by 'this' we mean stateful congestion control of multiple terabits = of tunnel traffic, then it is *most certainly* not a solved problem, and = definitely not something I'm interested in paying for. =20 Oh, nobody wants to pay for anything, including (and especially) = following standards. Fortunately, the IETF isn't an extension of an = industrial company's marketing department (or isn't yet, I should say). Joe >=20 > cheers, > -ed >=20 >=20 > On Mon, Jan 27, 2014 at 11:24 AM, Joe Touch wrote: >=20 >=20 > On 1/27/2014 11:19 AM, Joel M. Halpern wrote: > Yes Joe, routers could ahve been built to do those calcualtions at = that > performance scale. > There are however two major problems: >=20 > 1) That is not how routers are built. > 2) The target performance scale is rather higher. >=20 > So could someone build an ASIC to do what you want? >=20 > Has. It's already part of nearly every DMA ASIC in a network interface = already. >=20 >=20 > > Probably. Is there > any reason in the world to expect operators to pay the significant = extra > cost for such?Not that I can see. >=20 > We're talking about a ring of full adders, the specs for which are = given in an RFC that's 18 years old, and that is already implemented in = nearly every host interface, including 10Gps NICs. >=20 > And we're talking about "routers", many variants of which operate at = very high speeds and transparently proxy TCP already. So this is a = solved problem. >=20 >=20 > And even if we could and they would, that is not the world into which = we > are deploying these tunnels. >=20 > We're back to "that's not what they do now", at least in some devices. >=20 > Well, they don't use MPLS in UDP (since no spec exists), so clearly if = they're limited to doing what they already do, this is an exercise in = futility. >=20 > Joe >=20 >=20 >=20 > Yours, > Joel >=20 > On 1/27/14 1:53 PM, Joe Touch wrote: >=20 >=20 > On 1/27/2014 10:48 AM, joel jaeggli wrote: > On 1/27/14, 8:48 AM, Joe Touch wrote: > Those same mechanisms have provided hardware checksum support for a > very long time. >=20 > The new header and the payload are actually in different parts of the > forwarding complex until they hit the output queue, you can't checksum > data you don't have. >=20 > You can (and some do) the checksum component parts when things go into > memory; the partial sums can be added as the parts are combined in the > output queue. >=20 > I appreciate that we're all taking about what might be done, but the > reality is that there are many 'transparent TCP proxies' that have to = do > this, so there's clearly a solution, and it clearly runs fast enough. >=20 > Joe > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From touch@isi.edu Tue Jan 28 08:50:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708C51A017D; Tue, 28 Jan 2014 08:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 4rP67viUTlQW; Tue, 28 Jan 2014 08:50:53 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 185851A0146; Tue, 28 Jan 2014 08:50:53 -0800 (PST) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s0SGo3c5002940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jan 2014 08:50:07 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <201401280100.s0S10jhO097154@maildrop2.v6ds.occnc.com> Date: Tue, 28 Jan 2014 08:49:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <16B434AA-C151-490D-98C2-DE052F464640@isi.edu> References: <201401280100.s0S10jhO097154@maildrop2.v6ds.occnc.com> To: curtis@ipv6.occnc.com X-Mailer: Apple Mail (2.1827) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: joel jaeggli , "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:50:54 -0000 On Jan 27, 2014, at 5:00 PM, Curtis Villamizar = wrote: >=20 > In message <52E6AB15.2080907@isi.edu> > Joe Touch writes: >=20 >> On 1/27/2014 10:48 AM, joel jaeggli wrote: >>> On 1/27/14, 8:48 AM, Joe Touch wrote: >>>> Those same mechanisms have provided hardware checksum support for a = very long time. >>>=20 >>> The new header and the payload are actually in different parts of = the >>> forwarding complex until they hit the output queue, you can't = checksum >>> data you don't have. >>=20 >> You can (and some do) the checksum component parts when things go = into >> memory; the partial sums can be added as the parts are combined in = the >> output queue. >>=20 >> I appreciate that we're all taking about what might be done, but the >> reality is that there are many 'transparent TCP proxies' that have to >> do this, so there's clearly a solution, and it clearly runs fast >> enough. >>=20 >> Joe >=20 >=20 > Joe, >=20 > Chips that did 4 x 10 Gb/s are old stuff now but in their day they > pushed silicon limites. Chips now do N x 100 Gb/s. Yes, and it's 18 years later.=20 > Stewart is > describing how these chips (both the prior generation and current) are > architected and you are going back to some idea that there is a common > memory where this all resides and its just a matter of looking at it. > This is not software on a general purpose processor. I never said software; I said that the checksum can be computed as the = data moves (which is how we did it in 1996). > If a queue forms, the headers are in SRAM and the body of the packet > is off chip in DRAM. There isn't enough memory bandwidth to pull the > packet back until its time to send it out. At that point the header > and body are joined but the header processing has been completed long > ago. At some point the two come back together, at which point the partial = sums of the header and body can be combined and inserted in the header. ... > If there is no queue at all cut-through can happen. The header gets > transmitted before the entire packet arrives at the input of the > chip. (And if FCS fails a runt with bad FCS goes out). >=20 > At the very least this can't work if cut-through is used to reduce > latency. Latency is a complex function of the bandwidth, propagation, coding, and = processing delays, and there are very rare cases where cut-through = reductions would impact E2E latency.=20 In those cases, there are other good reasons not to use UDP = encapsulation. > When the two are joined, about the only processing is in the > MAC, its mostly loading a shift register and serializing but it also > does the FCS and sticks that *at the end*. The MAC is quite > inflexible as it is mostly silicon gates designed to do some minimal > processing for a layer-2 such as Ethernet or GFP/OTN. >=20 > Think for a moment what N x 100 Gb/s means. For small packets 150 > Mpps per interface with Ethernet overhead (large overhead). That is > 20 clock cycles per packet for a 3 GHz clock rate. Divide that by N. > This has to be done in specialized hardware The hardware required is trivial, and easy to include in the same = transfer mechanism used to move data (as it already has been for many = years in network interfaces). > BTW - "transparent TCP proxies" don't need to look at the payload for > the purpose of updating a checksum. That depends on whether the segments boundaries are preserved. Joe= From touch@isi.edu Tue Jan 28 08:57:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443961A0146; Tue, 28 Jan 2014 08:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 cRrmpIDEjhc4; Tue, 28 Jan 2014 08:57:34 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 00FE91A0240; Tue, 28 Jan 2014 08:57:33 -0800 (PST) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s0SGv15Q005298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jan 2014 08:57:05 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <201401280129.s0S1TGY5099912@maildrop2.v6ds.occnc.com> Date: Tue, 28 Jan 2014 08:57:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4E4D36AF-2CB4-431C-BE01-8560BC46B0A3@isi.edu> References: <201401280129.s0S1TGY5099912@maildrop2.v6ds.occnc.com> To: curtis@ipv6.occnc.com X-Mailer: Apple Mail (2.1827) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: joel jaeggli , "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:57:35 -0000 On Jan 27, 2014, at 5:29 PM, Curtis Villamizar = wrote: >=20 > In message <52E6B272.4030703@isi.edu> > Joe Touch writes: >=20 >> On 1/27/2014 11:19 AM, Joel M. Halpern wrote: >>> Yes Joe, routers could ahve been built to do those calcualtions at = that >>> performance scale. >>> There are however two major problems: >>>=20 >>> 1) That is not how routers are built. >>> 2) The target performance scale is rather higher. >>>=20 >>> So could someone build an ASIC to do what you want? >>=20 >> Has. It's already part of nearly every DMA ASIC in a network = interface >> already. >=20 > There is no DMA ASIC in these designs. There is no shared memory to > DMA from. A router is not a specialized PC. Agreed; the point was that it isn't an ASIC, but a very small function = that can be included in any data transfer mechanism. > BTW - the PCIe FCS is at the end of the transmission not the front so > the DMA ASIC doesn't have to read memory twice, the first time to > compute a checksum to put at the front. Right, and until you modify UDP to have a trailer checksum, or use a = different encapsulation that has one (e.g., via an IPv6 option), then = you need to deal with the fact that the UDP checksum would require a = store-and-forward delay. IMO, if you don't like that, then use another encapsulation. >>> Probably. Is there >>> any reason in the world to expect operators to pay the significant = extra >>> cost for such?Not that I can see. >>=20 >> We're talking about a ring of full adders, the specs for which are >> given in an RFC that's 18 years old, and that is already implemented >> in nearly every host interface, including 10Gps NICs. >>=20 >> And we're talking about "routers", many variants of which operate at >> very high speeds and transparently proxy TCP already. So this is a >> solved problem. >=20 > See prior email. They don't need to look at the payload to modify IP > or TCP headers and then update the checksum. >=20 >>> And even if we could and they would, that is not the world into = which we >>> are deploying these tunnels. >>=20 >> We're back to "that's not what they do now", at least in some = devices. >>=20 >> Well, they don't use MPLS in UDP (since no spec exists), so clearly = if >> they're limited to doing what they already do, this is an exercise in >> futility. >>=20 >> Joe >=20 > You seem to be missing the point that MPLS over UDP is not considered > a good solution going forward on which to base the design of new > hardware, but rather an interim solution to accomodate old hardware > that doesn't load split MPLS traffic. We live with interim solutions for decades. I'd be OK with something that says that the UDP checksum SHOULD be used, = but that legacy deployments MAY ignore it. That solves what happens in the short term, but doesn't saddle us all = with a poor solution if/when it persists. > In any case, two passes, one to compute a checksum and put it on the > front, would increase latency. Again, latency is a complex issue, and store-and-forward delays inside = routers is irrelevant for all but specialty deployments (stock trading = esp.), and in those cases the use of additional encapsulation should be = avoided anyway. Joe > If anything UDP-Heavy with an FCS at > the end would be used, even though two FCS is considered bad form. >=20 > Curtis >=20 >=20 >>> Yours, >>> Joel >>>=20 >>> On 1/27/14 1:53 PM, Joe Touch wrote: >>>>=20 >>>>=20 >>>> On 1/27/2014 10:48 AM, joel jaeggli wrote: >>>>> On 1/27/14, 8:48 AM, Joe Touch wrote: >>>>>> Those same mechanisms have provided hardware checksum support for = a >>>>>> very long time. >>>>>=20 >>>>> The new header and the payload are actually in different parts of = the >>>>> forwarding complex until they hit the output queue, you can't = checksum >>>>> data you don't have. >>>>=20 >>>> You can (and some do) the checksum component parts when things go = into >>>> memory; the partial sums can be added as the parts are combined in = the >>>> output queue. >>>>=20 >>>> I appreciate that we're all taking about what might be done, but = the >>>> reality is that there are many 'transparent TCP proxies' that have = to do >>>> this, so there's clearly a solution, and it clearly runs fast = enough. >>>>=20 >>>> Joe From curtis@ipv6.occnc.com Tue Jan 28 10:14:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC30F1A0232 for ; Tue, 28 Jan 2014 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 8nJfHvpHccMY for ; Tue, 28 Jan 2014 10:14:52 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 804CE1A021A for ; Tue, 28 Jan 2014 10:14:52 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0SIEj7H015626; Tue, 28 Jan 2014 13:14:45 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401281814.s0SIEj7H015626@maildrop2.v6ds.occnc.com> To: Eric Osborne From: Curtis Villamizar In-reply-to: Your message of "Tue, 28 Jan 2014 08:59:06 -0500." Date: Tue, 28 Jan 2014 13:14:45 -0500 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-psc-updates@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-psc-updates-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 18:14:55 -0000 In message Eric Osborne writes: > Sure, I can make that change, although I think it reads better if I > forego expansion in favor of reusing the title from rfc6378. > > The current title is "Updates to PSC". > "Updates to Protection Switching Coordination" looks clunky, IMO. > > What about "Updates to MPLS Transport Profile Linear Protection"? > > eric That works. It is actually better since it includes the title of the RFC you are updating. Curtis > On Mon, Jan 27, 2014 at 6:05 PM, Curtis Villamizar > wrote: > > > > In message <52E63702.20102@pi.nu> > > Loa Andersson writes: > > > >> Working Group, > >> > >> This is to initiate a working group last call on > >> draft-ietf-mpls-psc-updates. > >> > >> One reason for the timing, other than that the author thinks is ready > >> for wglc, is that this document is normatively referenced in > >> draft-ietf-mpls-tp-psc-itu which also is in wglc. > >> > >> There are no IPR disclosures against this document. > >> > >> Please send your comments to the mpls wg mailing list (mpls@ietf.org). > >> > >> This working group last call ends Feb 19´0, 2014. > >> > >> /Loa > >> for the MPLS wg chairs > > > > > > The title needs to spell out PSC since there are three interpretations > > of the acronym in IETF, the other two predating this one by many > > years. > > > > Otherwise looks good. > > > > Curtis From internet-drafts@ietf.org Tue Jan 28 11:20:48 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A5C1A0374; Tue, 28 Jan 2014 11:20: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 rk9sEjPEDryU; Tue, 28 Jan 2014 11:20:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9C51A026C; Tue, 28 Jan 2014 11:20:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140128192045.12291.85886.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2014 11:20:45 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-forwarding-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 19:20:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS Forwarding Compliance and Performance Requir= ements Authors : Curtis Villamizar Kireeti Kompella Shane Amante Andrew Malis Carlos Pignataro Filename : draft-ietf-mpls-forwarding-05.txt Pages : 54 Date : 2014-01-28 Abstract: This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-forwarding/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-forwarding-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-forwarding-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 curtis@ipv6.occnc.com Tue Jan 28 11:54:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233631A034E for ; Tue, 28 Jan 2014 11:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 KbgLCYvGGqru for ; Tue, 28 Jan 2014 11:54:41 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5357C1A026A for ; Tue, 28 Jan 2014 11:54:41 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0SJsaMG016743; Tue, 28 Jan 2014 14:54:36 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401281954.s0SJsaMG016743@maildrop2.v6ds.occnc.com> To: adrian@olddog.co.uk From: Curtis Villamizar In-reply-to: Your message of "Tue, 28 Jan 2014 11:23:30 +0000." <033c01cf1c1b$612c9480$2385bd80$@olddog.co.uk> Date: Tue, 28 Jan 2014 14:54:36 -0500 Cc: mpls@ietf.org, draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 19:54:45 -0000 In message <033c01cf1c1b$612c9480$2385bd80$@olddog.co.uk> "Adrian Farrel" writes: > Curtis, > Thanks for all this. > I'm good with the changes recorded here. > Time to post AFAIK. > > A Adrian, I just checked the diffs after submitting 05 and I want to make two very minor changes. OLD ... renamed these from the term "reserved labels" used in [RFC3032] "special purpose labels". NEW ... renamed these from the term "reserved labels" used in [RFC3032] to "special purpose labels". Added the word "to" as in "rename from X to Y". OLD registry reachable at IANA's pages at [1]. NEW registry reachable at IANA's pages at http://www.iana.org. The above is the return of a xml2rfc eref bug. Need to hand edit the .txt file or fix the python source again. Didn't catch this since there was no change in the xml file. Should I hold off on these or submit a 06 version just to fix this? Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > Sent: 28 January 2014 04:09 > > To: adrian@olddog.co.uk > > Cc: curtis@ipv6.occnc.com; draft-ietf-mpls-forwarding.all@tools.ietf.org; > > mpls@ietf.org > > Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding > > > > > > In message <022d01cf1bb4$1624fde0$426ef9a0$@olddog.co.uk> > > "Adrian Farrel" writes: > > > > > > Hello Curtis, > > > > > > These replies modulo the conversation with Carlos. I find I can't read that > > > conversation and back apply the results here :-( > > > > I'll summarize the outcome of that conversation with Carlo at the > > bottom so we can have one thread. > > > > > [snip] > > > > > > > > Your acronym list is commendably thorough, but a little enthusiastic. > > > > > > > > If I provide a section with a list of acronyms, do I still have to > > > > expand on first use. If so, AC, NSP, OAM, and a few others appear > > > > before that section. > > > > > > Afraid so :-( > > > > OK. Expanded except RFC-Editor listed well known abbreviations. > > > > > > Given that this takes up only 17 lines in a 50 page document I'd > > > > rather be thorough. > > > > > > Yup. OK. Go for it. > > > > > > [snip] > > > > > > > > I think Curtis may have heard this before :-) > > > > > The "preferred" (by the RFC editor) expansion of ECMP is > > > > > "Equal-Cost Multipath" > > > > > > > > The form without the hyphen is more common, even among recent > > > > documents. I prefer to keep it without the hyphen. > > > > > > A discussion for a rainy day with the RFC Editor. > > > Leave as is. > > > > Cheers. > > > > > > > Section 1.3 bullet 5 > > > > > > > > > > 5. The implementer and system designer MUST support pseudowire > > > > > control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is > > > > > being used on a pseudowire. > > > > > > > > > > The wording is a bit odd. "The implementation and system design..."? > > > > > > > > > > Ditto bullets 6 and 7 > > > > > > > > Target audience is explained in Section 1.4. If you like I can flip > > > > Section 1.3 and 1.4 so target audience is first, then use of the roles > > > > called for in the target audience section won't seem quite so odd. > > > > > > No issue with the section order. > > > Just puzzled by "the implementer MUST support" when I (pedantically) thought > > > that the implementer supporting something might not be the same as the > > > implementation supporting it. > > > > > > Not a big deal. > > > > Good point. Its changed. > > > > > > > Section 1.3 > > > > > > > > > > While there is not wrong with the statements made in the bullets, some > > > > > of the later ones refer to recent additions to the MPLS suite. Yet the > > > > > list is presented as "there were some misconceptions." Clearly the > > > > > early silicon did not have misconceptions about the inclusion of entropy > > > > > labels. > > > > > > > > > > Just tweak the words at the top of the list? > > > > > > > > I'd like to keep that as is and split into two lists. The second list > > > > would have the last two items (fat-pw and EL). The first list would > > > > end with "implement CW" (sic). > > > > > > > > OLD > > > > > > > > 6. The implementer and system designer SHOULD support adding a > > > > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > > > > feature for appropriate pseudowire types. See Section 2.4.3. > > > > > > > > 7. The implementer and system designer SHOULD support adding an MPLS > > > > entropy label [RFC6790]. Deployments MAY enable this feature. > > > > See Section 2.4.4. > > > > > > > > NEW > > > > > > > > The following statements provide clarification regarding more > > > > recent requirements that are often missed. > > > > > > > > 1. The implementer and system designer SHOULD support adding a > > > > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > > > > feature for appropriate pseudowire types. See Section 2.4.3. > > > > > > > > 2. The implementer and system designer SHOULD support adding an MPLS > > > > entropy label [RFC6790]. Deployments MAY enable this feature. > > > > See Section 2.4.4. > > > > > > > > I've made this change. Let me know if this is not OK. > > > > > > That's fine. > > > > > > > > 2.1.1 > > > > > > > > > > Maybe the first paragraph should clarify "special purpose labels at > > > > > the top of the label stack" > > > > > > > > That phrase doesn't appear anywhere in the document. Exactly what am > > > > I clarifying? What to do with unknown special purpose labels is in > > > > the last paragraph of this subsection. > > > > > > WTF? > > > You have to wonder where these senile ADs get their ideas. > > > > > > Complete brain fart. Sorry. > > > > > > [snip] > > > > > > > > While per platform label space is mentioned in 2.1.7 I wonder whether > > > > > more information on per platform and per interface label spaces is > > > > > needed. I recall early implementations that got very confused when > > > > > parallel interfaces used the same label for different purposes. > > > > > > > > > > I guess the point there is that you cannot assume that your neighbor > > > > > is or is not using the per platform label space. > > > > > > > > > > Upstream label allocation may also come into this. > > > > > > > > The only mention of label allocation is that MPLS FRR bypass method > > > > (more formally known as facilitles backup) uses platform label space. > > > > > > > > The only reason platform label space is of any significance in a > > > > document about forwarding is "The use of platform label space impacts > > > > the size of the LSR ILM for LSR with a very large number of > > > > interfaces." > > > > > > > > Label allocation, per platform or per interface and upstream or > > > > downstream, is not a forwarding issue. It is a software issue > > > > and a matter of getting the protocol bits right. Therefore I think > > > > expanding any further on label allocation should be out of scope. > > > > > > OK. I'm convinced. > > > > > > > > 2.1.8.1 > > > > > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > > > core is using multipath, reordering will be far more common. If > > > > > this is occurring, the best solution is to use CW on the edge, > > > > > rather than try to fix the reordering using resequencing. > > > > > > > > > > Completely agree, but isn't the sequence number contained in a control > > > > > word meaning that the resequencing could, in any case, not be done > > > > > without using a control word? > > > > > > > > I suppose you can't fix reordering caused by not using CW without the > > > > sequence number in the CW. That is going to require fixing the text. > > > > > > > > OLD > > > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > > core is using multipath, reordering will be far more common. > > > > If this is occurring, the best solution is to use CW on the > > > > edge, rather than try to fix the reordering using resequencing. > > > > > > > > NEW > > > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > > core is using multipath, reordering will be far more common. > > > > If this is occurring, using CW on the edge will solve the > > > > problem. Without CW, resequencing is not possible since the > > > > sequence number is contained in the CW. > > > > > > > > That was a big oops on our part. > > > > > > Well, on the scale of IETF oopsies, I don't think you score too high. Maybe > > > Narten could run a weekly script? > > > > > > [snip] > > > > > > > > Should 2.2 distinguish the order of magnitude of replication at branch > > > > > nodes? This impacts the replication method used (some devices make a > > > > > copy and cycle around, some devices can do multiple copies at once). On > > > > > the whole is no different from IP multicast processing except (as you > > > > > note) that each outgoing packet may be different by its label value. > > > > > > > > Is it possible to quantify the fanout? YMMV? > > > > > > > > The only thing I could say is that an implementation may need to make > > > > lots of copies in some roles (access routers for example). > > > > > > > > Making a copy and cycling yields poor performance but for low > > > > multicast traffic volumes might be OK. But you are right - some > > > > mostly low-end-ish chips to this. > > > > > > > > I'm not sure I can describe how multicast with high fanout is done > > > > without wading into implementation details of specific vendors. > > > > > > > > Perhaps the best I can do is add this: > > > > > > > > Careful consideration should be given to the performance > > > > characteristics of high fanout multicast for equipment that is > > > > intended to be used in such a role. > > > > > > > > I'll add this before the last paragraph in the section. > > > > > > That works. > > > > > > > > 2.4 > > > > > > > > > > So obvious you didn't say it? > > > > > > > > > > In order to support an adequately balanced load distribution across > > > > > multiple links, IP header information must be used. Common practice > > > > > today is to reinspect the IP headers at each LSR and use the label > > > > > stack and IP header information in a hash performed at each LSR. > > > > > Further details are provided in Section 2.4.5. > > > > > > > > > > Missing is the statement that a single "flow" must not be distributed > > > > > across multiple paths because of the implication for potentially > > > > > significant packet misordering. And feeding that is a common requirement > > > > > that such packet misordering must not occur because applications and > > > > > transport protocol implementations cannot survive such misordering. > > > > > > > > Yes. That requirement was missed. Add new second paragraph to this > > > > subsection. > > > > > > > > The Differentiated Services requirements for good reasons dictate > > > > that packets within a common microflow SHOULD NOT be reordered > > > > [RFC2474]. Service providers generally impose stronger > > > > requirements, commonly requiring that packets within a microflow > > > > MUST NOT be reordered except in rare circumstances such as load > > > > balancing across multiple links or path change for load balancing > > > > or path change for other reason. > > > > > > > > Another SP requirement is stated here and I'm quite sure this > > > > requirement is well accepted. > > > > > > Looks good. > > > > > > > > 2.4.2 uses "composite link" and "component link". I suggest picking just > > > > > one term. > > > > > > > > They are two different things. Two or more component links make up a > > > > composite link. Knowing that, give it another read please. > > > > > > > > I'd rather not cite draft-ietf-rtgwg-cl-requirements as an > > > > informational reference just for this one term. In favor of citing > > > > it, draft-ietf-rtgwg-cl-requirements is moving along. Against citing > > > > it is there is far less than a ground swell of providers calling for > > > > the full set of things asked for in draft-ietf-rtgwg-cl-requirements. > > > > > > Yes. Sorry. It has been a looooooooong time since I had a pass on the CL > > > document. Atrophy. > > > > Its also in Gwiz.8080 or something like that. > > > > > > > 2.4.5.1 notes that special purpose and extended special purpose labels > > > > > need to be excluded from the hash. Good. > > > > > But it seems that some special purpose labels will indicate that the > > > > > next label stack entry contains a label with special meaning. (ELI is > > > > > an example that we specifically don't have to worry about.) > > > > > How do we handle that? > > > > > Should we be dividing up the extended special purpose label space to > > > > > have one set of code points meaning "just this label is special" and > > > > > another set meaning "this label is special and the next label stack > > > > > entry is magic"? > > > > > > > > I did list ELI (bullet 2) before the more general rule of not useing > > > > special purpose labels. The ELI is not used, just the EL, so the text > > > > could be considered correct as-is. > > > > > > > > So far the only special purpose label that is not just ignored and > > > > skipped over is ELI. > > > > > > > > Regarding this being magic -- All of this is somewhat programable > > > > specialized silicon magic. The silicon generally has some form of > > > > very fast, very light weight parsing engine at the front of the > > > > pipeline. One thing it does is pick out fields for load balance. > > > > > > > > The better silicon hashes as it goes rather that pick out a set of > > > > fields and then hashes that set of fields when its done. When it sees > > > > 13 it skips and hashes the next thing and stops hashing completely. > > > > If it sees 0-12,14 it skips and continues. If it sees 15 it skips two > > > > labels and continues. Its should be programable enough that if > > > > someone defines a new ELI like label it is likely to be able to deal > > > > with it. > > > > > > > > The not so good silicon has this all so hard wired that it won't be > > > > able to do ELI without at least a respin. > > > > > > > > At most I could add "If a new special purpose label or extended > > > > special purpose label is defined which requires special load balance > > > > processing then, as is the case for the ELI label, a spacial action > > > > may be needed rather than skipping the special purpose label or > > > > extended special purpose label." I really don't think this is needed. > > > > > > You're right, and my worry is more about the special-purpose draft and the > > > consequences of possibly adding other special purpose labels that have child > > > labels associated. We certainly don't want to have to retrain the silicon at > > > transit LSRs to specially know what to do for each new special-purpose > label. > > > Currently we propose that you don't hash on a special purpose label, but you > > can > > > carry on hashing immediately after. > > > > > > If I introduce the foo-label, your silicon will recognise it as special > purpose, > > > but it I say the label after the foo-label is magic you won't know that. > > > > > > A way to fix this is to have (just punting here) the top bit of the extended > > > special purpose label range set mean "magic label follows". > > > > I added this: > > > > 4. If a new special purpose label or extended special purpose > > label is defined which requires special load balance > > processing, then, as is the case for the ELI label, a spacial > > action may be needed rather than skipping the special purpose > > label or extended special purpose label. > > > > This will be the new bullet 4, bumping down the old 4 and 5. > > > > > > > An issue that arises from the multipath support (2.4.5.1) is that > > > > > hardware assumes that after a label stack entry with the S-bit set, > > > > > there are only three possible next bytes... > > > > > - a control word (indicated by b0000 or b0001) > > > > > - an IPv4 header > > > > > - an IPv6 header > > > > > This is the case regardless of how the LSP was set up, and the next > > > > > bytes cannot ever be further MPLS stack entries. > > > > > > > > Right. Note that in (5) is says that some SP will require IP headers > > > > and some will require an ability to disable IP headers. > > > > > > > > The rule is really look for 4, 6, or anything else in the first > > > > nibble. If 4 or 6 assume IP. If anything else stop. > > > > > > > > And yes if the payload is MPLS after a S-bit you have a screwed up > > > > MPLS implementation to start with and you won't get load balance on > > > > any set of MPLS labels after the first S-bit. This is a fact of life > > > > in the field and is as it should be. > > > > > > > > > While this comes up 2.4.5.1 it may merit further discussion in an > > > > > earlier section of the document. > > > > > > > > This text is part of 2.4. ("MPLS Multipath Techniques"). The third > > > > paragraph contains "Further details are provided in Section 2.4.5." > > > > Section 2.4.5. is "Fields Used for Multipath Load Balance". > > > > > > > > > I note that discussion of support of PWs without the CW drives you > > > > > to say that hashing beyond the S-bit should be a configurable option > > > > > which would (of course) support any payload including MPLS in MPLS > > > > > with repeated bottom of stack. However, you might want to specifically > > > > > preclude that. > > > > > > > > It says the same thing here in bullet 5 regarding being configurable. > > > > The wording "ability to disable" is same as "configurable option". > > > > > > > > At no point in this document do we imply that looking beyond the S-bit > > > > means looking at anything beyond the S-bit other than looking for IP. > > > > This is very clear in [RFC4385] and [RFC4928] which is cited in the > > > > text about PW CW. > > > > > > > > All it says in the places discusing PW is that without CW the traffic > > > > might get reordered. > > > > > > > > If you feel that we at any point imply that lack of PW CW allows > > > > looking at anything past the S-bit rather than just looking for an IP > > > > header please point to where and we will have to correct that. I > > > > looked at all occurances of CW and did not find anything. > > > > > > > > Bullet 5 is very clear that a 4 or 6 has to be found in the first > > > > nibble of payload. > > > > > > OK. I misread bullet 5. > > > > OK > > > > > [snip] > > > > > > Thanks. > > > Adrian > > > > Summary of conversation with Carlos: > > > > Adrian wrote: > > >> Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, > > >> L2TP, or LDP, are out of scope. > > >> > > >> I think s/LDP/UDP/ > > > > Carlos noted some wording issues in this sentence and suggested adding > > citations for each. After some discussion: > > > > OLD (original) > > > > Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, > > L2TP, or LDP, are out of scope. > > > > NEW > > > > Tunneling encapsulations carrying MPLS, such as MPLS in IP > > [RFC4023], MPLS in GRE [RFC4023], MPLS in L2TPv3 [RFC4817], or MPLS > > in UDP [I-D.ietf-mpls-in-udp], are out of scope. > > > > He also suggested the following. > > > > OLD > > > > Some IP encapsulations support tunneling, such as IP-in-IP, GRE, > > L2TPv3, and IPSEC. These provide a greater source of entropy which > > some provider networks carrying large amounts of tunneled traffic > > - may need. > > The use of tunneling header information is out of scope for this > > document. > > > > NEW > > > > Some IP encapsulations support tunneling, such as IP-in-IP, GRE, > > L2TPv3, and IPSEC. These provide a greater source of entropy which > > some provider networks carrying large amounts of tunneled traffic > > + may need, for example as used in [RFC5640] for GRE and L2TPv3. > > The use of tunneling header information is out of scope for this > > document. > > > > As part of that conversation it was noted that the following also had > > no citations. > > > > OLD > > > > Support for other protocols that share a common Layer-4 header such > > - as RTP, UDP-lite, SCTP and DCCP > > SHOULD be provided, particularly for edge or access equipment where > > additional entropy may be needed. > > > > NEW > > > > Support for other protocols that share a common Layer-4 header such > > + as RTP [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960] and DCCP > > + [RFC4340] > > SHOULD be provided, particularly for edge or access equipment where > > additional entropy may be needed. > > > > btw- this is wrt fields used in load balancing and is saying in effect > > "use more than just port 6 and 17 (UDP and TCP)". > > > > Other than that, I looked at the list of informational references and > > found the following do affect MPLS forwarding and therefore should be > > promoted to normative. > > > > [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP > > Extensions for Multiprotocol Label Switching", RFC 4950, > > August 2007. > > > > [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. > > Pignataro, "The Generalized TTL Security Mechanism > > (GTSM)", RFC 5082, October 2007. > > > > [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit > > Connectivity Verification (VCCV): A Control Channel for > > Pseudowires", RFC 5085, December 2007. > > > > [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS > > Multicast Encapsulations", RFC 5332, August 2008. > > > > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > > (BFD)", RFC 5880, June 2010. > > > > [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, > > "Bidirectional Forwarding Detection (BFD) for MPLS Label > > Switched Paths (LSPs)", RFC 5884, June 2010. > > > > [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding > > Detection (BFD) for the Pseudowire Virtual Circuit > > Connectivity Verification (VCCV)", RFC 5885, June 2010. > > > > [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay > > Measurement for MPLS Networks", RFC 6374, September 2011. > > > > [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay > > Measurement Profile for MPLS-Based Transport Networks", > > RFC 6375, September 2011. > > > > [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and > > A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear > > Protection", RFC 6378, October 2011. > > > > [RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., > > and D. Ward, "MPLS Fault Management Operations, > > Administration, and Maintenance (OAM)", RFC 6427, November > > 2011. > > > > [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive > > Connectivity Verification, Continuity Check, and Remote > > Defect Indication for the MPLS Transport Profile", RFC > > 6428, November 2011. > > > > [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security > > Mechanism (GTSM) for the Label Distribution Protocol > > (LDP)", RFC 6720, August 2012. > > > > [I-D.ietf-mpls-psc-updates] > > Osborne, E., "Updates to PSC", draft-ietf-mpls-psc- > > updates-00 (work in progress), October 2013. > > > > Upgrades were mostly due to BFD and MPLS-TP OAM. For example, direct > > LM needs to be in hardware and most things related to protection. > > > > Note that "Updates to PSC" affects MPLS-TP protection state machine > > which needs hardware assist if not direct support in hardware in order > > to be fast. The race condition may be the most severe problem with > > RFC 6378 state machine. > > > > If you think any of the above should be put back into informative, > > please let me know. > > > > Curtis From adrian@olddog.co.uk Tue Jan 28 12:35:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369AD1A026C for ; Tue, 28 Jan 2014 12:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 8C2WE3IXGypX for ; Tue, 28 Jan 2014 12:35:21 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA231A024C for ; Tue, 28 Jan 2014 12:35:20 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0SKZGfW030815; Tue, 28 Jan 2014 20:35:16 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0SKZCKm030771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Jan 2014 20:35:13 GMT From: "Adrian Farrel" To: References: Your message of "Tue, 28 Jan 2014 11:23:30 +0000." <033c01cf1c1b$612c9480$2385bd80$@olddog.co.uk> <201401281954.s0SJsaMG016743@maildrop2.v6ds.occnc.com> In-Reply-To: <201401281954.s0SJsaMG016743@maildrop2.v6ds.occnc.com> Date: Tue, 28 Jan 2014 20:35:11 -0000 Message-ID: <04dc01cf1c68$72e042b0$58a0c810$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFaLjop4eTfIQDqAtW5r0AJZaozbJuEcwyQ Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:35:26 -0000 Please post the update. Thanks for checking with me. Adrian > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > Sent: 28 January 2014 19:55 > To: adrian@olddog.co.uk > Cc: curtis@ipv6.occnc.com; draft-ietf-mpls-forwarding.all@tools.ietf.org; > mpls@ietf.org > Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding > > > In message <033c01cf1c1b$612c9480$2385bd80$@olddog.co.uk> > "Adrian Farrel" writes: > > > Curtis, > > Thanks for all this. > > I'm good with the changes recorded here. > > Time to post AFAIK. > > > > A > > > Adrian, > > I just checked the diffs after submitting 05 and I want to make two very > minor changes. > > OLD > > ... renamed these from the term "reserved labels" used in [RFC3032] > "special purpose labels". > > NEW > > ... renamed these from the term "reserved labels" used in [RFC3032] > to "special purpose labels". > > Added the word "to" as in "rename from X to Y". > > OLD > > registry reachable at IANA's pages at [1]. > > NEW > > registry reachable at IANA's pages at http://www.iana.org. > > The above is the return of a xml2rfc eref bug. Need to hand edit the > .txt file or fix the python source again. Didn't catch this since > there was no change in the xml file. > > Should I hold off on these or submit a 06 version just to fix this? > > Curtis > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > Sent: 28 January 2014 04:09 > > > To: adrian@olddog.co.uk > > > Cc: curtis@ipv6.occnc.com; draft-ietf-mpls-forwarding.all@tools.ietf.org; > > > mpls@ietf.org > > > Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding > > > > > > > > > In message <022d01cf1bb4$1624fde0$426ef9a0$@olddog.co.uk> > > > "Adrian Farrel" writes: > > > > > > > > Hello Curtis, > > > > > > > > These replies modulo the conversation with Carlos. I find I can't read that > > > > conversation and back apply the results here :-( > > > > > > I'll summarize the outcome of that conversation with Carlo at the > > > bottom so we can have one thread. > > > > > > > [snip] > > > > > > > > > > Your acronym list is commendably thorough, but a little enthusiastic. > > > > > > > > > > If I provide a section with a list of acronyms, do I still have to > > > > > expand on first use. If so, AC, NSP, OAM, and a few others appear > > > > > before that section. > > > > > > > > Afraid so :-( > > > > > > OK. Expanded except RFC-Editor listed well known abbreviations. > > > > > > > > Given that this takes up only 17 lines in a 50 page document I'd > > > > > rather be thorough. > > > > > > > > Yup. OK. Go for it. > > > > > > > > [snip] > > > > > > > > > > I think Curtis may have heard this before :-) > > > > > > The "preferred" (by the RFC editor) expansion of ECMP is > > > > > > "Equal-Cost Multipath" > > > > > > > > > > The form without the hyphen is more common, even among recent > > > > > documents. I prefer to keep it without the hyphen. > > > > > > > > A discussion for a rainy day with the RFC Editor. > > > > Leave as is. > > > > > > Cheers. > > > > > > > > > Section 1.3 bullet 5 > > > > > > > > > > > > 5. The implementer and system designer MUST support pseudowire > > > > > > control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is > > > > > > being used on a pseudowire. > > > > > > > > > > > > The wording is a bit odd. "The implementation and system design..."? > > > > > > > > > > > > Ditto bullets 6 and 7 > > > > > > > > > > Target audience is explained in Section 1.4. If you like I can flip > > > > > Section 1.3 and 1.4 so target audience is first, then use of the roles > > > > > called for in the target audience section won't seem quite so odd. > > > > > > > > No issue with the section order. > > > > Just puzzled by "the implementer MUST support" when I (pedantically) > thought > > > > that the implementer supporting something might not be the same as the > > > > implementation supporting it. > > > > > > > > Not a big deal. > > > > > > Good point. Its changed. > > > > > > > > > Section 1.3 > > > > > > > > > > > > While there is not wrong with the statements made in the bullets, some > > > > > > of the later ones refer to recent additions to the MPLS suite. Yet the > > > > > > list is presented as "there were some misconceptions." Clearly the > > > > > > early silicon did not have misconceptions about the inclusion of entropy > > > > > > labels. > > > > > > > > > > > > Just tweak the words at the top of the list? > > > > > > > > > > I'd like to keep that as is and split into two lists. The second list > > > > > would have the last two items (fat-pw and EL). The first list would > > > > > end with "implement CW" (sic). > > > > > > > > > > OLD > > > > > > > > > > 6. The implementer and system designer SHOULD support adding a > > > > > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > > > > > feature for appropriate pseudowire types. See Section 2.4.3. > > > > > > > > > > 7. The implementer and system designer SHOULD support adding an > MPLS > > > > > entropy label [RFC6790]. Deployments MAY enable this feature. > > > > > See Section 2.4.4. > > > > > > > > > > NEW > > > > > > > > > > The following statements provide clarification regarding more > > > > > recent requirements that are often missed. > > > > > > > > > > 1. The implementer and system designer SHOULD support adding a > > > > > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > > > > > feature for appropriate pseudowire types. See Section 2.4.3. > > > > > > > > > > 2. The implementer and system designer SHOULD support adding an > MPLS > > > > > entropy label [RFC6790]. Deployments MAY enable this feature. > > > > > See Section 2.4.4. > > > > > > > > > > I've made this change. Let me know if this is not OK. > > > > > > > > That's fine. > > > > > > > > > > 2.1.1 > > > > > > > > > > > > Maybe the first paragraph should clarify "special purpose labels at > > > > > > the top of the label stack" > > > > > > > > > > That phrase doesn't appear anywhere in the document. Exactly what am > > > > > I clarifying? What to do with unknown special purpose labels is in > > > > > the last paragraph of this subsection. > > > > > > > > WTF? > > > > You have to wonder where these senile ADs get their ideas. > > > > > > > > Complete brain fart. Sorry. > > > > > > > > [snip] > > > > > > > > > > While per platform label space is mentioned in 2.1.7 I wonder whether > > > > > > more information on per platform and per interface label spaces is > > > > > > needed. I recall early implementations that got very confused when > > > > > > parallel interfaces used the same label for different purposes. > > > > > > > > > > > > I guess the point there is that you cannot assume that your neighbor > > > > > > is or is not using the per platform label space. > > > > > > > > > > > > Upstream label allocation may also come into this. > > > > > > > > > > The only mention of label allocation is that MPLS FRR bypass method > > > > > (more formally known as facilitles backup) uses platform label space. > > > > > > > > > > The only reason platform label space is of any significance in a > > > > > document about forwarding is "The use of platform label space impacts > > > > > the size of the LSR ILM for LSR with a very large number of > > > > > interfaces." > > > > > > > > > > Label allocation, per platform or per interface and upstream or > > > > > downstream, is not a forwarding issue. It is a software issue > > > > > and a matter of getting the protocol bits right. Therefore I think > > > > > expanding any further on label allocation should be out of scope. > > > > > > > > OK. I'm convinced. > > > > > > > > > > 2.1.8.1 > > > > > > > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > > > > core is using multipath, reordering will be far more common. If > > > > > > this is occurring, the best solution is to use CW on the edge, > > > > > > rather than try to fix the reordering using resequencing. > > > > > > > > > > > > Completely agree, but isn't the sequence number contained in a control > > > > > > word meaning that the resequencing could, in any case, not be done > > > > > > without using a control word? > > > > > > > > > > I suppose you can't fix reordering caused by not using CW without the > > > > > sequence number in the CW. That is going to require fixing the text. > > > > > > > > > > OLD > > > > > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > > > core is using multipath, reordering will be far more common. > > > > > If this is occurring, the best solution is to use CW on the > > > > > edge, rather than try to fix the reordering using resequencing. > > > > > > > > > > NEW > > > > > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > > > core is using multipath, reordering will be far more common. > > > > > If this is occurring, using CW on the edge will solve the > > > > > problem. Without CW, resequencing is not possible since the > > > > > sequence number is contained in the CW. > > > > > > > > > > That was a big oops on our part. > > > > > > > > Well, on the scale of IETF oopsies, I don't think you score too high. Maybe > > > > Narten could run a weekly script? > > > > > > > > [snip] > > > > > > > > > > Should 2.2 distinguish the order of magnitude of replication at branch > > > > > > nodes? This impacts the replication method used (some devices make a > > > > > > copy and cycle around, some devices can do multiple copies at once). On > > > > > > the whole is no different from IP multicast processing except (as you > > > > > > note) that each outgoing packet may be different by its label value. > > > > > > > > > > Is it possible to quantify the fanout? YMMV? > > > > > > > > > > The only thing I could say is that an implementation may need to make > > > > > lots of copies in some roles (access routers for example). > > > > > > > > > > Making a copy and cycling yields poor performance but for low > > > > > multicast traffic volumes might be OK. But you are right - some > > > > > mostly low-end-ish chips to this. > > > > > > > > > > I'm not sure I can describe how multicast with high fanout is done > > > > > without wading into implementation details of specific vendors. > > > > > > > > > > Perhaps the best I can do is add this: > > > > > > > > > > Careful consideration should be given to the performance > > > > > characteristics of high fanout multicast for equipment that is > > > > > intended to be used in such a role. > > > > > > > > > > I'll add this before the last paragraph in the section. > > > > > > > > That works. > > > > > > > > > > 2.4 > > > > > > > > > > > > So obvious you didn't say it? > > > > > > > > > > > > In order to support an adequately balanced load distribution across > > > > > > multiple links, IP header information must be used. Common practice > > > > > > today is to reinspect the IP headers at each LSR and use the label > > > > > > stack and IP header information in a hash performed at each LSR. > > > > > > Further details are provided in Section 2.4.5. > > > > > > > > > > > > Missing is the statement that a single "flow" must not be distributed > > > > > > across multiple paths because of the implication for potentially > > > > > > significant packet misordering. And feeding that is a common > requirement > > > > > > that such packet misordering must not occur because applications and > > > > > > transport protocol implementations cannot survive such misordering. > > > > > > > > > > Yes. That requirement was missed. Add new second paragraph to this > > > > > subsection. > > > > > > > > > > The Differentiated Services requirements for good reasons dictate > > > > > that packets within a common microflow SHOULD NOT be reordered > > > > > [RFC2474]. Service providers generally impose stronger > > > > > requirements, commonly requiring that packets within a microflow > > > > > MUST NOT be reordered except in rare circumstances such as load > > > > > balancing across multiple links or path change for load balancing > > > > > or path change for other reason. > > > > > > > > > > Another SP requirement is stated here and I'm quite sure this > > > > > requirement is well accepted. > > > > > > > > Looks good. > > > > > > > > > > 2.4.2 uses "composite link" and "component link". I suggest picking just > > > > > > one term. > > > > > > > > > > They are two different things. Two or more component links make up a > > > > > composite link. Knowing that, give it another read please. > > > > > > > > > > I'd rather not cite draft-ietf-rtgwg-cl-requirements as an > > > > > informational reference just for this one term. In favor of citing > > > > > it, draft-ietf-rtgwg-cl-requirements is moving along. Against citing > > > > > it is there is far less than a ground swell of providers calling for > > > > > the full set of things asked for in draft-ietf-rtgwg-cl-requirements. > > > > > > > > Yes. Sorry. It has been a looooooooong time since I had a pass on the CL > > > > document. Atrophy. > > > > > > Its also in Gwiz.8080 or something like that. > > > > > > > > > 2.4.5.1 notes that special purpose and extended special purpose labels > > > > > > need to be excluded from the hash. Good. > > > > > > But it seems that some special purpose labels will indicate that the > > > > > > next label stack entry contains a label with special meaning. (ELI is > > > > > > an example that we specifically don't have to worry about.) > > > > > > How do we handle that? > > > > > > Should we be dividing up the extended special purpose label space to > > > > > > have one set of code points meaning "just this label is special" and > > > > > > another set meaning "this label is special and the next label stack > > > > > > entry is magic"? > > > > > > > > > > I did list ELI (bullet 2) before the more general rule of not useing > > > > > special purpose labels. The ELI is not used, just the EL, so the text > > > > > could be considered correct as-is. > > > > > > > > > > So far the only special purpose label that is not just ignored and > > > > > skipped over is ELI. > > > > > > > > > > Regarding this being magic -- All of this is somewhat programable > > > > > specialized silicon magic. The silicon generally has some form of > > > > > very fast, very light weight parsing engine at the front of the > > > > > pipeline. One thing it does is pick out fields for load balance. > > > > > > > > > > The better silicon hashes as it goes rather that pick out a set of > > > > > fields and then hashes that set of fields when its done. When it sees > > > > > 13 it skips and hashes the next thing and stops hashing completely. > > > > > If it sees 0-12,14 it skips and continues. If it sees 15 it skips two > > > > > labels and continues. Its should be programable enough that if > > > > > someone defines a new ELI like label it is likely to be able to deal > > > > > with it. > > > > > > > > > > The not so good silicon has this all so hard wired that it won't be > > > > > able to do ELI without at least a respin. > > > > > > > > > > At most I could add "If a new special purpose label or extended > > > > > special purpose label is defined which requires special load balance > > > > > processing then, as is the case for the ELI label, a spacial action > > > > > may be needed rather than skipping the special purpose label or > > > > > extended special purpose label." I really don't think this is needed. > > > > > > > > You're right, and my worry is more about the special-purpose draft and the > > > > consequences of possibly adding other special purpose labels that have > child > > > > labels associated. We certainly don't want to have to retrain the silicon at > > > > transit LSRs to specially know what to do for each new special-purpose > > label. > > > > Currently we propose that you don't hash on a special purpose label, but > you > > > can > > > > carry on hashing immediately after. > > > > > > > > If I introduce the foo-label, your silicon will recognise it as special > > purpose, > > > > but it I say the label after the foo-label is magic you won't know that. > > > > > > > > A way to fix this is to have (just punting here) the top bit of the extended > > > > special purpose label range set mean "magic label follows". > > > > > > I added this: > > > > > > 4. If a new special purpose label or extended special purpose > > > label is defined which requires special load balance > > > processing, then, as is the case for the ELI label, a spacial > > > action may be needed rather than skipping the special purpose > > > label or extended special purpose label. > > > > > > This will be the new bullet 4, bumping down the old 4 and 5. > > > > > > > > > An issue that arises from the multipath support (2.4.5.1) is that > > > > > > hardware assumes that after a label stack entry with the S-bit set, > > > > > > there are only three possible next bytes... > > > > > > - a control word (indicated by b0000 or b0001) > > > > > > - an IPv4 header > > > > > > - an IPv6 header > > > > > > This is the case regardless of how the LSP was set up, and the next > > > > > > bytes cannot ever be further MPLS stack entries. > > > > > > > > > > Right. Note that in (5) is says that some SP will require IP headers > > > > > and some will require an ability to disable IP headers. > > > > > > > > > > The rule is really look for 4, 6, or anything else in the first > > > > > nibble. If 4 or 6 assume IP. If anything else stop. > > > > > > > > > > And yes if the payload is MPLS after a S-bit you have a screwed up > > > > > MPLS implementation to start with and you won't get load balance on > > > > > any set of MPLS labels after the first S-bit. This is a fact of life > > > > > in the field and is as it should be. > > > > > > > > > > > While this comes up 2.4.5.1 it may merit further discussion in an > > > > > > earlier section of the document. > > > > > > > > > > This text is part of 2.4. ("MPLS Multipath Techniques"). The third > > > > > paragraph contains "Further details are provided in Section 2.4.5." > > > > > Section 2.4.5. is "Fields Used for Multipath Load Balance". > > > > > > > > > > > I note that discussion of support of PWs without the CW drives you > > > > > > to say that hashing beyond the S-bit should be a configurable option > > > > > > which would (of course) support any payload including MPLS in MPLS > > > > > > with repeated bottom of stack. However, you might want to specifically > > > > > > preclude that. > > > > > > > > > > It says the same thing here in bullet 5 regarding being configurable. > > > > > The wording "ability to disable" is same as "configurable option". > > > > > > > > > > At no point in this document do we imply that looking beyond the S-bit > > > > > means looking at anything beyond the S-bit other than looking for IP. > > > > > This is very clear in [RFC4385] and [RFC4928] which is cited in the > > > > > text about PW CW. > > > > > > > > > > All it says in the places discusing PW is that without CW the traffic > > > > > might get reordered. > > > > > > > > > > If you feel that we at any point imply that lack of PW CW allows > > > > > looking at anything past the S-bit rather than just looking for an IP > > > > > header please point to where and we will have to correct that. I > > > > > looked at all occurances of CW and did not find anything. > > > > > > > > > > Bullet 5 is very clear that a 4 or 6 has to be found in the first > > > > > nibble of payload. > > > > > > > > OK. I misread bullet 5. > > > > > > OK > > > > > > > [snip] > > > > > > > > Thanks. > > > > Adrian > > > > > > Summary of conversation with Carlos: > > > > > > Adrian wrote: > > > >> Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, > > > >> L2TP, or LDP, are out of scope. > > > >> > > > >> I think s/LDP/UDP/ > > > > > > Carlos noted some wording issues in this sentence and suggested adding > > > citations for each. After some discussion: > > > > > > OLD (original) > > > > > > Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, > > > L2TP, or LDP, are out of scope. > > > > > > NEW > > > > > > Tunneling encapsulations carrying MPLS, such as MPLS in IP > > > [RFC4023], MPLS in GRE [RFC4023], MPLS in L2TPv3 [RFC4817], or MPLS > > > in UDP [I-D.ietf-mpls-in-udp], are out of scope. > > > > > > He also suggested the following. > > > > > > OLD > > > > > > Some IP encapsulations support tunneling, such as IP-in-IP, GRE, > > > L2TPv3, and IPSEC. These provide a greater source of entropy which > > > some provider networks carrying large amounts of tunneled traffic > > > - may need. > > > The use of tunneling header information is out of scope for this > > > document. > > > > > > NEW > > > > > > Some IP encapsulations support tunneling, such as IP-in-IP, GRE, > > > L2TPv3, and IPSEC. These provide a greater source of entropy which > > > some provider networks carrying large amounts of tunneled traffic > > > + may need, for example as used in [RFC5640] for GRE and L2TPv3. > > > The use of tunneling header information is out of scope for this > > > document. > > > > > > As part of that conversation it was noted that the following also had > > > no citations. > > > > > > OLD > > > > > > Support for other protocols that share a common Layer-4 header such > > > - as RTP, UDP-lite, SCTP and DCCP > > > SHOULD be provided, particularly for edge or access equipment where > > > additional entropy may be needed. > > > > > > NEW > > > > > > Support for other protocols that share a common Layer-4 header such > > > + as RTP [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960] and DCCP > > > + [RFC4340] > > > SHOULD be provided, particularly for edge or access equipment where > > > additional entropy may be needed. > > > > > > btw- this is wrt fields used in load balancing and is saying in effect > > > "use more than just port 6 and 17 (UDP and TCP)". > > > > > > Other than that, I looked at the list of informational references and > > > found the following do affect MPLS forwarding and therefore should be > > > promoted to normative. > > > > > > [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP > > > Extensions for Multiprotocol Label Switching", RFC 4950, > > > August 2007. > > > > > > [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. > > > Pignataro, "The Generalized TTL Security Mechanism > > > (GTSM)", RFC 5082, October 2007. > > > > > > [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit > > > Connectivity Verification (VCCV): A Control Channel for > > > Pseudowires", RFC 5085, December 2007. > > > > > > [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS > > > Multicast Encapsulations", RFC 5332, August 2008. > > > > > > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > > > (BFD)", RFC 5880, June 2010. > > > > > > [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, > > > "Bidirectional Forwarding Detection (BFD) for MPLS Label > > > Switched Paths (LSPs)", RFC 5884, June 2010. > > > > > > [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding > > > Detection (BFD) for the Pseudowire Virtual Circuit > > > Connectivity Verification (VCCV)", RFC 5885, June 2010. > > > > > > [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay > > > Measurement for MPLS Networks", RFC 6374, September 2011. > > > > > > [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay > > > Measurement Profile for MPLS-Based Transport Networks", > > > RFC 6375, September 2011. > > > > > > [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and > > > A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear > > > Protection", RFC 6378, October 2011. > > > > > > [RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., > > > and D. Ward, "MPLS Fault Management Operations, > > > Administration, and Maintenance (OAM)", RFC 6427, November > > > 2011. > > > > > > [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive > > > Connectivity Verification, Continuity Check, and Remote > > > Defect Indication for the MPLS Transport Profile", RFC > > > 6428, November 2011. > > > > > > [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security > > > Mechanism (GTSM) for the Label Distribution Protocol > > > (LDP)", RFC 6720, August 2012. > > > > > > [I-D.ietf-mpls-psc-updates] > > > Osborne, E., "Updates to PSC", draft-ietf-mpls-psc- > > > updates-00 (work in progress), October 2013. > > > > > > Upgrades were mostly due to BFD and MPLS-TP OAM. For example, direct > > > LM needs to be in hardware and most things related to protection. > > > > > > Note that "Updates to PSC" affects MPLS-TP protection state machine > > > which needs hardware assist if not direct support in hardware in order > > > to be fast. The race condition may be the most severe problem with > > > RFC 6378 state machine. > > > > > > If you think any of the above should be put back into informative, > > > please let me know. > > > > > > Curtis From internet-drafts@ietf.org Tue Jan 28 13:54:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581821A03C6; Tue, 28 Jan 2014 13:54: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 XHrN5rJxLPeC; Tue, 28 Jan 2014 13:54:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C951A028B; Tue, 28 Jan 2014 13:54:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140128215440.28400.88024.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2014 13:54:40 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-forwarding-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 21:54:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS Forwarding Compliance and Performance Requir= ements Authors : Curtis Villamizar Kireeti Kompella Shane Amante Andrew Malis Carlos Pignataro Filename : draft-ietf-mpls-forwarding-06.txt Pages : 54 Date : 2014-01-28 Abstract: This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-forwarding/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-forwarding-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-forwarding-06 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 curtis@ipv6.occnc.com Tue Jan 28 13:58:48 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9631A0403 for ; Tue, 28 Jan 2014 13:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 Yo2s6GYxgr0O for ; Tue, 28 Jan 2014 13:58:44 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0B52F1A03AA for ; Tue, 28 Jan 2014 13:58:43 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0SLwe6Y018318; Tue, 28 Jan 2014 16:58:40 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401282158.s0SLwe6Y018318@maildrop2.v6ds.occnc.com> To: adrian@olddog.co.uk From: Curtis Villamizar In-reply-to: Your message of "Tue, 28 Jan 2014 20:35:11 +0000." <04dc01cf1c68$72e042b0$58a0c810$@olddog.co.uk> Date: Tue, 28 Jan 2014 16:58:40 -0500 Cc: mpls@ietf.org, draft-ietf-mpls-forwarding.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 21:58:48 -0000 In message <04dc01cf1c68$72e042b0$58a0c810$@olddog.co.uk> "Adrian Farrel" writes: > Please post the update. > > Thanks for checking with me. > Adrian Adrian, Done. BTW- Also had to hand edit to get draft-ietf-mpls-in-udp-05 and draft-ietf-mpls-psc-updates-01 since http://xml.resource.org/public/rfc/bibxml3 is a few days behind (last updated Jan 13, 2014) and this time I got the dates right in the hand edit (Jan 2014). xml2rfc is great stuff when it works. Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > Sent: 28 January 2014 19:55 > > To: adrian@olddog.co.uk > > Cc: curtis@ipv6.occnc.com; draft-ietf-mpls-forwarding.all@tools.ietf.org; > > mpls@ietf.org > > Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding > > > > > > In message <033c01cf1c1b$612c9480$2385bd80$@olddog.co.uk> > > "Adrian Farrel" writes: > > > > > Curtis, > > > Thanks for all this. > > > I'm good with the changes recorded here. > > > Time to post AFAIK. > > > > > > A > > > > > > Adrian, > > > > I just checked the diffs after submitting 05 and I want to make two very > > minor changes. > > > > OLD > > > > ... renamed these from the term "reserved labels" used in [RFC3032] > > "special purpose labels". > > > > NEW > > > > ... renamed these from the term "reserved labels" used in [RFC3032] > > to "special purpose labels". > > > > Added the word "to" as in "rename from X to Y". > > > > OLD > > > > registry reachable at IANA's pages at [1]. > > > > NEW > > > > registry reachable at IANA's pages at http://www.iana.org. > > > > The above is the return of a xml2rfc eref bug. Need to hand edit the > > .txt file or fix the python source again. Didn't catch this since > > there was no change in the xml file. > > > > Should I hold off on these or submit a 06 version just to fix this? > > > > Curtis > > > > > > > > -----Original Message----- > > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > > Sent: 28 January 2014 04:09 > > > > To: adrian@olddog.co.uk > > > > Cc: curtis@ipv6.occnc.com; draft-ietf-mpls-forwarding.all@tools.ietf.org; > > > > mpls@ietf.org > > > > Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding > > > > > > > > > > > > In message <022d01cf1bb4$1624fde0$426ef9a0$@olddog.co.uk> > > > > "Adrian Farrel" writes: > > > > > > > > > > Hello Curtis, > > > > > > > > > > These replies modulo the conversation with Carlos. I find I can't read > that > > > > > conversation and back apply the results here :-( > > > > > > > > I'll summarize the outcome of that conversation with Carlo at the > > > > bottom so we can have one thread. > > > > > > > > > [snip] > > > > > > > > > > > > Your acronym list is commendably thorough, but a little > enthusiastic. > > > > > > > > > > > > If I provide a section with a list of acronyms, do I still have to > > > > > > expand on first use. If so, AC, NSP, OAM, and a few others appear > > > > > > before that section. > > > > > > > > > > Afraid so :-( > > > > > > > > OK. Expanded except RFC-Editor listed well known abbreviations. > > > > > > > > > > Given that this takes up only 17 lines in a 50 page document I'd > > > > > > rather be thorough. > > > > > > > > > > Yup. OK. Go for it. > > > > > > > > > > [snip] > > > > > > > > > > > > I think Curtis may have heard this before :-) > > > > > > > The "preferred" (by the RFC editor) expansion of ECMP is > > > > > > > "Equal-Cost Multipath" > > > > > > > > > > > > The form without the hyphen is more common, even among recent > > > > > > documents. I prefer to keep it without the hyphen. > > > > > > > > > > A discussion for a rainy day with the RFC Editor. > > > > > Leave as is. > > > > > > > > Cheers. > > > > > > > > > > > Section 1.3 bullet 5 > > > > > > > > > > > > > > 5. The implementer and system designer MUST support pseudowire > > > > > > > control word (CW) if MPLS-TP is supported or if ACH [RFC5586] > is > > > > > > > being used on a pseudowire. > > > > > > > > > > > > > > The wording is a bit odd. "The implementation and system design..."? > > > > > > > > > > > > > > Ditto bullets 6 and 7 > > > > > > > > > > > > Target audience is explained in Section 1.4. If you like I can flip > > > > > > Section 1.3 and 1.4 so target audience is first, then use of the roles > > > > > > called for in the target audience section won't seem quite so odd. > > > > > > > > > > No issue with the section order. > > > > > Just puzzled by "the implementer MUST support" when I (pedantically) > > thought > > > > > that the implementer supporting something might not be the same as the > > > > > implementation supporting it. > > > > > > > > > > Not a big deal. > > > > > > > > Good point. Its changed. > > > > > > > > > > > Section 1.3 > > > > > > > > > > > > > > While there is not wrong with the statements made in the bullets, > some > > > > > > > of the later ones refer to recent additions to the MPLS suite. Yet > the > > > > > > > list is presented as "there were some misconceptions." Clearly the > > > > > > > early silicon did not have misconceptions about the inclusion of > entropy > > > > > > > labels. > > > > > > > > > > > > > > Just tweak the words at the top of the list? > > > > > > > > > > > > I'd like to keep that as is and split into two lists. The second list > > > > > > would have the last two items (fat-pw and EL). The first list would > > > > > > end with "implement CW" (sic). > > > > > > > > > > > > OLD > > > > > > > > > > > > 6. The implementer and system designer SHOULD support adding a > > > > > > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > > > > > > feature for appropriate pseudowire types. See Section 2.4.3. > > > > > > > > > > > > 7. The implementer and system designer SHOULD support adding an > > MPLS > > > > > > entropy label [RFC6790]. Deployments MAY enable this feature. > > > > > > See Section 2.4.4. > > > > > > > > > > > > NEW > > > > > > > > > > > > The following statements provide clarification regarding more > > > > > > recent requirements that are often missed. > > > > > > > > > > > > 1. The implementer and system designer SHOULD support adding a > > > > > > pseudowire Flow Label [RFC6391]. Deployments MAY enable this > > > > > > feature for appropriate pseudowire types. See Section 2.4.3. > > > > > > > > > > > > 2. The implementer and system designer SHOULD support adding an > > MPLS > > > > > > entropy label [RFC6790]. Deployments MAY enable this feature. > > > > > > See Section 2.4.4. > > > > > > > > > > > > I've made this change. Let me know if this is not OK. > > > > > > > > > > That's fine. > > > > > > > > > > > > 2.1.1 > > > > > > > > > > > > > > Maybe the first paragraph should clarify "special purpose labels at > > > > > > > the top of the label stack" > > > > > > > > > > > > That phrase doesn't appear anywhere in the document. Exactly what am > > > > > > I clarifying? What to do with unknown special purpose labels is in > > > > > > the last paragraph of this subsection. > > > > > > > > > > WTF? > > > > > You have to wonder where these senile ADs get their ideas. > > > > > > > > > > Complete brain fart. Sorry. > > > > > > > > > > [snip] > > > > > > > > > > > > While per platform label space is mentioned in 2.1.7 I wonder > whether > > > > > > > more information on per platform and per interface label spaces is > > > > > > > needed. I recall early implementations that got very confused when > > > > > > > parallel interfaces used the same label for different purposes. > > > > > > > > > > > > > > I guess the point there is that you cannot assume that your neighbor > > > > > > > is or is not using the per platform label space. > > > > > > > > > > > > > > Upstream label allocation may also come into this. > > > > > > > > > > > > The only mention of label allocation is that MPLS FRR bypass method > > > > > > (more formally known as facilitles backup) uses platform label space. > > > > > > > > > > > > The only reason platform label space is of any significance in a > > > > > > document about forwarding is "The use of platform label space impacts > > > > > > the size of the LSR ILM for LSR with a very large number of > > > > > > interfaces." > > > > > > > > > > > > Label allocation, per platform or per interface and upstream or > > > > > > downstream, is not a forwarding issue. It is a software issue > > > > > > and a matter of getting the protocol bits right. Therefore I think > > > > > > expanding any further on label allocation should be out of scope. > > > > > > > > > > OK. I'm convinced. > > > > > > > > > > > > 2.1.8.1 > > > > > > > > > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > > > > > core is using multipath, reordering will be far more common. > If > > > > > > > this is occurring, the best solution is to use CW on the > edge, > > > > > > > rather than try to fix the reordering using resequencing. > > > > > > > > > > > > > > Completely agree, but isn't the sequence number contained in a > control > > > > > > > word meaning that the resequencing could, in any case, not be done > > > > > > > without using a control word? > > > > > > > > > > > > I suppose you can't fix reordering caused by not using CW without the > > > > > > sequence number in the CW. That is going to require fixing the text. > > > > > > > > > > > > OLD > > > > > > > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > > > > core is using multipath, reordering will be far more common. > > > > > > If this is occurring, the best solution is to use CW on the > > > > > > edge, rather than try to fix the reordering using resequencing. > > > > > > > > > > > > NEW > > > > > > > > > > > > 3. If the edge is not using pseudowire control word (CW) and the > > > > > > core is using multipath, reordering will be far more common. > > > > > > If this is occurring, using CW on the edge will solve the > > > > > > problem. Without CW, resequencing is not possible since the > > > > > > sequence number is contained in the CW. > > > > > > > > > > > > That was a big oops on our part. > > > > > > > > > > Well, on the scale of IETF oopsies, I don't think you score too high. > Maybe > > > > > Narten could run a weekly script? > > > > > > > > > > [snip] > > > > > > > > > > > > Should 2.2 distinguish the order of magnitude of replication at > branch > > > > > > > nodes? This impacts the replication method used (some devices make a > > > > > > > copy and cycle around, some devices can do multiple copies at once). > On > > > > > > > the whole is no different from IP multicast processing except (as > you > > > > > > > note) that each outgoing packet may be different by its label value. > > > > > > > > > > > > Is it possible to quantify the fanout? YMMV? > > > > > > > > > > > > The only thing I could say is that an implementation may need to make > > > > > > lots of copies in some roles (access routers for example). > > > > > > > > > > > > Making a copy and cycling yields poor performance but for low > > > > > > multicast traffic volumes might be OK. But you are right - some > > > > > > mostly low-end-ish chips to this. > > > > > > > > > > > > I'm not sure I can describe how multicast with high fanout is done > > > > > > without wading into implementation details of specific vendors. > > > > > > > > > > > > Perhaps the best I can do is add this: > > > > > > > > > > > > Careful consideration should be given to the performance > > > > > > characteristics of high fanout multicast for equipment that is > > > > > > intended to be used in such a role. > > > > > > > > > > > > I'll add this before the last paragraph in the section. > > > > > > > > > > That works. > > > > > > > > > > > > 2.4 > > > > > > > > > > > > > > So obvious you didn't say it? > > > > > > > > > > > > > > In order to support an adequately balanced load distribution > across > > > > > > > multiple links, IP header information must be used. Common > practice > > > > > > > today is to reinspect the IP headers at each LSR and use the > label > > > > > > > stack and IP header information in a hash performed at each LSR. > > > > > > > Further details are provided in Section 2.4.5. > > > > > > > > > > > > > > Missing is the statement that a single "flow" must not be > distributed > > > > > > > across multiple paths because of the implication for potentially > > > > > > > significant packet misordering. And feeding that is a common > > requirement > > > > > > > that such packet misordering must not occur because applications and > > > > > > > transport protocol implementations cannot survive such misordering. > > > > > > > > > > > > Yes. That requirement was missed. Add new second paragraph to this > > > > > > subsection. > > > > > > > > > > > > The Differentiated Services requirements for good reasons dictate > > > > > > that packets within a common microflow SHOULD NOT be reordered > > > > > > [RFC2474]. Service providers generally impose stronger > > > > > > requirements, commonly requiring that packets within a microflow > > > > > > MUST NOT be reordered except in rare circumstances such as load > > > > > > balancing across multiple links or path change for load balancing > > > > > > or path change for other reason. > > > > > > > > > > > > Another SP requirement is stated here and I'm quite sure this > > > > > > requirement is well accepted. > > > > > > > > > > Looks good. > > > > > > > > > > > > 2.4.2 uses "composite link" and "component link". I suggest picking > just > > > > > > > one term. > > > > > > > > > > > > They are two different things. Two or more component links make up a > > > > > > composite link. Knowing that, give it another read please. > > > > > > > > > > > > I'd rather not cite draft-ietf-rtgwg-cl-requirements as an > > > > > > informational reference just for this one term. In favor of citing > > > > > > it, draft-ietf-rtgwg-cl-requirements is moving along. Against citing > > > > > > it is there is far less than a ground swell of providers calling for > > > > > > the full set of things asked for in draft-ietf-rtgwg-cl-requirements. > > > > > > > > > > Yes. Sorry. It has been a looooooooong time since I had a pass on the CL > > > > > document. Atrophy. > > > > > > > > Its also in Gwiz.8080 or something like that. > > > > > > > > > > > 2.4.5.1 notes that special purpose and extended special purpose > labels > > > > > > > need to be excluded from the hash. Good. > > > > > > > But it seems that some special purpose labels will indicate that the > > > > > > > next label stack entry contains a label with special meaning. (ELI > is > > > > > > > an example that we specifically don't have to worry about.) > > > > > > > How do we handle that? > > > > > > > Should we be dividing up the extended special purpose label space to > > > > > > > have one set of code points meaning "just this label is special" and > > > > > > > another set meaning "this label is special and the next label stack > > > > > > > entry is magic"? > > > > > > > > > > > > I did list ELI (bullet 2) before the more general rule of not useing > > > > > > special purpose labels. The ELI is not used, just the EL, so the text > > > > > > could be considered correct as-is. > > > > > > > > > > > > So far the only special purpose label that is not just ignored and > > > > > > skipped over is ELI. > > > > > > > > > > > > Regarding this being magic -- All of this is somewhat programable > > > > > > specialized silicon magic. The silicon generally has some form of > > > > > > very fast, very light weight parsing engine at the front of the > > > > > > pipeline. One thing it does is pick out fields for load balance. > > > > > > > > > > > > The better silicon hashes as it goes rather that pick out a set of > > > > > > fields and then hashes that set of fields when its done. When it sees > > > > > > 13 it skips and hashes the next thing and stops hashing completely. > > > > > > If it sees 0-12,14 it skips and continues. If it sees 15 it skips two > > > > > > labels and continues. Its should be programable enough that if > > > > > > someone defines a new ELI like label it is likely to be able to deal > > > > > > with it. > > > > > > > > > > > > The not so good silicon has this all so hard wired that it won't be > > > > > > able to do ELI without at least a respin. > > > > > > > > > > > > At most I could add "If a new special purpose label or extended > > > > > > special purpose label is defined which requires special load balance > > > > > > processing then, as is the case for the ELI label, a spacial action > > > > > > may be needed rather than skipping the special purpose label or > > > > > > extended special purpose label." I really don't think this is needed. > > > > > > > > > > You're right, and my worry is more about the special-purpose draft and > the > > > > > consequences of possibly adding other special purpose labels that have > > child > > > > > labels associated. We certainly don't want to have to retrain the > silicon at > > > > > transit LSRs to specially know what to do for each new special-purpose > > > label. > > > > > Currently we propose that you don't hash on a special purpose label, but > > you > > > > can > > > > > carry on hashing immediately after. > > > > > > > > > > If I introduce the foo-label, your silicon will recognise it as special > > > purpose, > > > > > but it I say the label after the foo-label is magic you won't know that. > > > > > > > > > > A way to fix this is to have (just punting here) the top bit of the > extended > > > > > special purpose label range set mean "magic label follows". > > > > > > > > I added this: > > > > > > > > 4. If a new special purpose label or extended special purpose > > > > label is defined which requires special load balance > > > > processing, then, as is the case for the ELI label, a spacial > > > > action may be needed rather than skipping the special purpose > > > > label or extended special purpose label. > > > > > > > > This will be the new bullet 4, bumping down the old 4 and 5. > > > > > > > > > > > An issue that arises from the multipath support (2.4.5.1) is that > > > > > > > hardware assumes that after a label stack entry with the S-bit set, > > > > > > > there are only three possible next bytes... > > > > > > > - a control word (indicated by b0000 or b0001) > > > > > > > - an IPv4 header > > > > > > > - an IPv6 header > > > > > > > This is the case regardless of how the LSP was set up, and the next > > > > > > > bytes cannot ever be further MPLS stack entries. > > > > > > > > > > > > Right. Note that in (5) is says that some SP will require IP headers > > > > > > and some will require an ability to disable IP headers. > > > > > > > > > > > > The rule is really look for 4, 6, or anything else in the first > > > > > > nibble. If 4 or 6 assume IP. If anything else stop. > > > > > > > > > > > > And yes if the payload is MPLS after a S-bit you have a screwed up > > > > > > MPLS implementation to start with and you won't get load balance on > > > > > > any set of MPLS labels after the first S-bit. This is a fact of life > > > > > > in the field and is as it should be. > > > > > > > > > > > > > While this comes up 2.4.5.1 it may merit further discussion in an > > > > > > > earlier section of the document. > > > > > > > > > > > > This text is part of 2.4. ("MPLS Multipath Techniques"). The third > > > > > > paragraph contains "Further details are provided in Section 2.4.5." > > > > > > Section 2.4.5. is "Fields Used for Multipath Load Balance". > > > > > > > > > > > > > I note that discussion of support of PWs without the CW drives you > > > > > > > to say that hashing beyond the S-bit should be a configurable option > > > > > > > which would (of course) support any payload including MPLS in MPLS > > > > > > > with repeated bottom of stack. However, you might want to > specifically > > > > > > > preclude that. > > > > > > > > > > > > It says the same thing here in bullet 5 regarding being configurable. > > > > > > The wording "ability to disable" is same as "configurable option". > > > > > > > > > > > > At no point in this document do we imply that looking beyond the S-bit > > > > > > means looking at anything beyond the S-bit other than looking for IP. > > > > > > This is very clear in [RFC4385] and [RFC4928] which is cited in the > > > > > > text about PW CW. > > > > > > > > > > > > All it says in the places discusing PW is that without CW the traffic > > > > > > might get reordered. > > > > > > > > > > > > If you feel that we at any point imply that lack of PW CW allows > > > > > > looking at anything past the S-bit rather than just looking for an IP > > > > > > header please point to where and we will have to correct that. I > > > > > > looked at all occurances of CW and did not find anything. > > > > > > > > > > > > Bullet 5 is very clear that a 4 or 6 has to be found in the first > > > > > > nibble of payload. > > > > > > > > > > OK. I misread bullet 5. > > > > > > > > OK > > > > > > > > > [snip] > > > > > > > > > > Thanks. > > > > > Adrian > > > > > > > > Summary of conversation with Carlos: > > > > > > > > Adrian wrote: > > > > >> Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, > > > > >> L2TP, or LDP, are out of scope. > > > > >> > > > > >> I think s/LDP/UDP/ > > > > > > > > Carlos noted some wording issues in this sentence and suggested adding > > > > citations for each. After some discussion: > > > > > > > > OLD (original) > > > > > > > > Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, > > > > L2TP, or LDP, are out of scope. > > > > > > > > NEW > > > > > > > > Tunneling encapsulations carrying MPLS, such as MPLS in IP > > > > [RFC4023], MPLS in GRE [RFC4023], MPLS in L2TPv3 [RFC4817], or MPLS > > > > in UDP [I-D.ietf-mpls-in-udp], are out of scope. > > > > > > > > He also suggested the following. > > > > > > > > OLD > > > > > > > > Some IP encapsulations support tunneling, such as IP-in-IP, GRE, > > > > L2TPv3, and IPSEC. These provide a greater source of entropy which > > > > some provider networks carrying large amounts of tunneled traffic > > > > - may need. > > > > The use of tunneling header information is out of scope for this > > > > document. > > > > > > > > NEW > > > > > > > > Some IP encapsulations support tunneling, such as IP-in-IP, GRE, > > > > L2TPv3, and IPSEC. These provide a greater source of entropy which > > > > some provider networks carrying large amounts of tunneled traffic > > > > + may need, for example as used in [RFC5640] for GRE and L2TPv3. > > > > The use of tunneling header information is out of scope for this > > > > document. > > > > > > > > As part of that conversation it was noted that the following also had > > > > no citations. > > > > > > > > OLD > > > > > > > > Support for other protocols that share a common Layer-4 header such > > > > - as RTP, UDP-lite, SCTP and DCCP > > > > SHOULD be provided, particularly for edge or access equipment where > > > > additional entropy may be needed. > > > > > > > > NEW > > > > > > > > Support for other protocols that share a common Layer-4 header such > > > > + as RTP [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960] and DCCP > > > > + [RFC4340] > > > > SHOULD be provided, particularly for edge or access equipment where > > > > additional entropy may be needed. > > > > > > > > btw- this is wrt fields used in load balancing and is saying in effect > > > > "use more than just port 6 and 17 (UDP and TCP)". > > > > > > > > Other than that, I looked at the list of informational references and > > > > found the following do affect MPLS forwarding and therefore should be > > > > promoted to normative. > > > > > > > > [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP > > > > Extensions for Multiprotocol Label Switching", RFC 4950, > > > > August 2007. > > > > > > > > [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. > > > > Pignataro, "The Generalized TTL Security Mechanism > > > > (GTSM)", RFC 5082, October 2007. > > > > > > > > [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit > > > > Connectivity Verification (VCCV): A Control Channel for > > > > Pseudowires", RFC 5085, December 2007. > > > > > > > > [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS > > > > Multicast Encapsulations", RFC 5332, August 2008. > > > > > > > > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > > > > (BFD)", RFC 5880, June 2010. > > > > > > > > [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, > > > > "Bidirectional Forwarding Detection (BFD) for MPLS Label > > > > Switched Paths (LSPs)", RFC 5884, June 2010. > > > > > > > > [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding > > > > Detection (BFD) for the Pseudowire Virtual Circuit > > > > Connectivity Verification (VCCV)", RFC 5885, June 2010. > > > > > > > > [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay > > > > Measurement for MPLS Networks", RFC 6374, September 2011. > > > > > > > > [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay > > > > Measurement Profile for MPLS-Based Transport Networks", > > > > RFC 6375, September 2011. > > > > > > > > [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and > > > > A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear > > > > Protection", RFC 6378, October 2011. > > > > > > > > [RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., > > > > and D. Ward, "MPLS Fault Management Operations, > > > > Administration, and Maintenance (OAM)", RFC 6427, November > > > > 2011. > > > > > > > > [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive > > > > Connectivity Verification, Continuity Check, and Remote > > > > Defect Indication for the MPLS Transport Profile", RFC > > > > 6428, November 2011. > > > > > > > > [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security > > > > Mechanism (GTSM) for the Label Distribution Protocol > > > > (LDP)", RFC 6720, August 2012. > > > > > > > > [I-D.ietf-mpls-psc-updates] > > > > Osborne, E., "Updates to PSC", draft-ietf-mpls-psc- > > > > updates-00 (work in progress), October 2013. > > > > > > > > Upgrades were mostly due to BFD and MPLS-TP OAM. For example, direct > > > > LM needs to be in hardware and most things related to protection. > > > > > > > > Note that "Updates to PSC" affects MPLS-TP protection state machine > > > > which needs hardware assist if not direct support in hardware in order > > > > to be fast. The race condition may be the most severe problem with > > > > RFC 6378 state machine. > > > > > > > > If you think any of the above should be put back into informative, > > > > please let me know. > > > > > > > > Curtis From internet-drafts@ietf.org Tue Jan 28 14:39:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970611A0485; Tue, 28 Jan 2014 14:39:18 -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 f-jR0uFGtOpO; Tue, 28 Jan 2014 14:39:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDEC1A03EB; Tue, 28 Jan 2014 14:39:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140128223916.5677.6663.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2014 14:39:16 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-multipath-use-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 22:39:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Use of Multipath with MPLS and MPLS-TP Author : Curtis Villamizar Filename : draft-ietf-mpls-multipath-use-04.txt Pages : 15 Date : 2014-01-28 Abstract: Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy Labels (RFC6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-multipath-use/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-multipath-use-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-multipath-use-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ryoo@etri.re.kr Tue Jan 28 18:42:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA67F1A033C for ; Tue, 28 Jan 2014 18:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 Byeu7FBdIHm7 for ; Tue, 28 Jan 2014 18:41:59 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 24DFF1A02E8 for ; Tue, 28 Jan 2014 18:41:59 -0800 (PST) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 29 Jan 2014 11:41:54 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Wed, 29 Jan 2014 11:41:53 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll draft-ietf-mpls-tp-psc-itu Thread-Index: AQHPG1UEm/rMfbO7l0OJNE4m3XD8+5qbAD4K Date: Wed, 29 Jan 2014 02:41:52 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B4003@SMTP2.etri.info> References: <52E64660.2090900@pi.nu> In-Reply-To: <52E64660.2090900@pi.nu> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B4003SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] IPR poll draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 02:42:03 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B4003SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vLCBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlz IGRvY3VtZW50Lg0KDQpKZW9uZy1kb25nDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbSA6ICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51Pg0KU2VudCA6IDIwMTQt MDEtMjcgMjA6NDM6MzcgKCArMDk6MDAgKQ0KVG8gOiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYu b3JnPg0KQ2MgOiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyA8bXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc+LCBWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKSA8bWFydGluLnZpZ291cmV1eEBh bGNhdGVsLWx1Y2VudC5jb20+LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRm Lm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0 IDogSVBSIHBvbGwgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCg0KV29ya2luZyBHcm91cCwN Cg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUgaXMgaW4gd29ya2luZyBncm91cCBsYXN0IGNh bGwsIHdlIGhhdmUganVzdA0KcmVjZWl2ZWQgYW4gSVBSIGRpc2Nsb3N1cmU6DQoNCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMTE0NjkuaHRtbA0K DQpUaGlzIGdpdmVzIHVzIHJlYXNvbiB0byBzdGFydCBhbiBJUFIgcG9sbCBvbiB0aGUgZG9jdW1l bnQuDQoNCg0KVGhpcyBtYWlsIHN0YXJ0cyB0aGF0IElQUiBwb2xsLg0KDQpBcmUgeW91IGF3YXJl IG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1Pw0K DQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJ RVRGIElQUiBydWxlcw0KKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1v cmUgZGV0YWlscykuDQoNCkN1cnJlbnRseSB0aGVyZSBpcyB0aGUgb25lIElQUiBkaXNjbG9zdXJl LCBtZW50aW9uZWQgYWJvdmUsIHRoYXQNCnJlbGF0ZXMgdG8gdGhpcyBkb2N1bWVudC4NCg0KSWYg eW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNl IHJlc3BvbmQgdG8NCnRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3Ug YXJlIGF3YXJlIG9mIGFueSByZWxldmFudA0KSVBSLiAqVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJl IHNlbnQgdG8gdGhlIE1QTFMgd2cgbWFpbGluZyBsaXN0LiogVGhlDQpkb2N1bWVudCB3aWxsIG5v dCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4NCnJl Y2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG9u IHRoZSBNUExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBv cg0KY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlv dSBhcmUgYXdhcmUgb2YgYW55DQpJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBp biBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRoYW5rcywgTG9hDQooYXMgTVBMUyBX RyBjby1jaGFpcikNCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3 ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVz IChjb25zdWx0YW50KSBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B4003SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5IaSw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0 Ij5ObywgSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkb2N1 bWVudC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4N CjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5KZW9uZy1kb25nPC9kaXY+DQo8ZGl2IHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCIgaWQ9Ik1haWxTaWduIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGI+RnJvbSA6IDwvYj4mcXVvdDtMb2EgQW5kZXJzc29u JnF1b3Q7ICZsdDtsb2FAcGkubnUmZ3Q7PGJyPg0KPGI+U2VudCA6IDwvYj4yMDE0LTAxLTI3IDIw OjQzOjM3ICggJiM0MzswOTowMCApPGJyPg0KPGI+VG8gOiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7 bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYyA6IDwvYj5tcGxzLWNoYWlyc0B0b29scy5pZXRm Lm9yZyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7LCBWSUdPVVJFVVgsIE1BUlRJ TiAoTUFSVElOKSAmbHQ7bWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7LCBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5J UFIgcG9sbCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxicj4NCjxicj4NCldvcmtpbmcgR3Jv dXAsPGJyPg0KPGJyPg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUgaXMgaW4gd29ya2luZyBn cm91cCBsYXN0IGNhbGwsIHdlIGhhdmUganVzdDxicj4NCnJlY2VpdmVkIGFuIElQUiBkaXNjbG9z dXJlOjxicj4NCjxicj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxz L2N1cnJlbnQvbXNnMTE0NjkuaHRtbDxicj4NCjxicj4NClRoaXMgZ2l2ZXMgdXMgcmVhc29uIHRv IHN0YXJ0IGFuIElQUiBwb2xsIG9uIHRoZSBkb2N1bWVudC48YnI+DQo8YnI+DQo8YnI+DQpUaGlz IG1haWwgc3RhcnRzIHRoYXQgSVBSIHBvbGwuPGJyPg0KPGJyPg0KQXJlIHlvdSBhd2FyZSBvZiBh bnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dT88YnI+DQo8 YnI+DQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0 aCBJRVRGIElQUiBydWxlczxicj4NCihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4 IGZvciBtb3JlIGRldGFpbHMpLjxicj4NCjxicj4NCkN1cnJlbnRseSB0aGVyZSBpcyB0aGUgb25l IElQUiBkaXNjbG9zdXJlLCBtZW50aW9uZWQgYWJvdmUsIHRoYXQ8YnI+DQpyZWxhdGVzIHRvIHRo aXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBh dXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG88YnI+DQp0aGlzIGVtYWlsIHJl Z2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQ8 YnI+DQpJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTVBMUyB3ZyBt YWlsaW5nIGxpc3QuKiBUaGUgPGJyPg0KZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUg bmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuPGJyPg0KcmVjZWl2ZWQgZnJvbSBl YWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBvbiB0aGUg TVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3I8YnI+ DQpjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91 IGFyZSBhd2FyZSBvZiBhbnk8YnI+DQpJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3Nl ZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuPGJyPg0KPGJyPg0KVGhhbmtzLCBMb2E8 YnI+DQooYXMgTVBMUyBXRyBjby1jaGFpcik8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2Eg QW5kZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208YnI+DQpTZW5pb3IgTVBMUyBF eHBlcnQgbG9hQHBpLm51PGJyPg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhv bmU6ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B4003SMTP2etriinfo_-- From ryoo@etri.re.kr Tue Jan 28 20:24:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9B1A017F for ; Tue, 28 Jan 2014 20:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 NQGOzhRK3C4O for ; Tue, 28 Jan 2014 20:24:46 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 552F01A015E for ; Tue, 28 Jan 2014 20:24:46 -0800 (PST) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 29 Jan 2014 13:24:41 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Wed, 29 Jan 2014 13:24:39 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: working group last call draft-ietf-mpls-tp-psc-itu-01 Thread-Index: AQHPHDD6PxX4EfDenE+JJCp9uCTk/JqbAWPi Date: Wed, 29 Jan 2014 04:24:38 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B401B@SMTP2.etri.info> References: <52DC89C3.3030003@pi.nu>,<52E7B75F.6010805@pi.nu> In-Reply-To: <52E7B75F.6010805@pi.nu> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B401BSMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 04:24:49 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B401BSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLCB0aGFua3MgZm9yIHRoZSBjb21tZW50cy4NCg0KWWVzLCB3ZSBuZWVkIHRvIGNsYXJpZnkg c3RhdGUvbWVzc2FnZSgvdGltZXIpIGZvciBXVFIgYW5kIG90aGVycy4NCg0KT25lIG1pbm9yIGNv bmNlcm4gaXMgdGhhdCAiV1RSIEV4cGlyZXMiIGlzIHVzZWQgYXMgdGhlIG5hbWUgb2YgYSBsb2Nh bCByZXF1ZXN0IGluIFJGQyA2Mzc4Lg0KSSBhbSBub3Qgc3VyZSBpZiBpdCB3b3VsZCBiZSBvayB0 byBjaGFuZ2UgaXQgdG8gIldUUiBUaW1lciBFeHBpcmVzIiBpbiB0aGlzIGRvY3VtZW50Lg0KTW9y ZSBzcGVjaWZpY2FsbHksIHRoZSBwcm9wb3NhbCBvZiB0aGUgZm9sbG93aW5nIHR3byBpdGVtcyBu ZWVkcyB0aGUgY2hhbmdlIG9mICJXVFIgRXhwaXJlcyIgdG8gIldUUiB0aW1lciBleHBpcmVzIiBp biB0aGUgcHJpb3JpdHkgbGlzdA0KaW4gcGFnZSAxOToNCi0gcGFnZSAxMyBsYXN0IGxpbmUgLSBz L1dUUiBleHBpcmVzL1dUUiB0aW1lciBleHBpcmVzIChUaGlzIGl0ZW0gd291bGQgZGlzYXBwcmVh ciBvbmNlIHdlIHRha2UgQWRyaWFuJ3MgcHJvcG9zYWwgdG8gY2hhbmdlIHdob2xlIHNlbnRlbmNl LikNCi0gcGFnZSAyMCAzcmQgbGluZSBmcm9tIHRoZSAtIHMvV1RSIGV4cGlyZXMvV1RSIHRpbWVy IGV4cGlyZXMNCg0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRnJvbSA6ICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51 Pg0KU2VudCA6IDIwMTQtMDEtMjggMjI6NTg6MTAgKCArMDk6MDAgKQ0KVG8gOiBtcGxzQGlldGYu b3JnIDxtcGxzQGlldGYub3JnPg0KQ2MgOiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyA8bXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+LCA8bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmc+LCBkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXRw LXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+LCBWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKSA8bWFy dGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20+DQpTdWJqZWN0IDogUmU6IHdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAxDQoNCkZvbGtzLA0K DQpJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgKGFjdHVhbGx5IGZvdXJ0aCBvciBmaWZ0aCB0 aW1lKSBhbmQgSSBoYXZlDQp2ZXJ5IGZldyBjb21tZW50cywgSSB0aGluayBBZHJpYW4gY292ZXJl ZCBhbGwgbWluZSBpbiBoaXMgcmV2aWV3Lg0KDQpJIGhhZCBzb21ldGhpbmcgdGhhdCBJIHRob3Vn aHQgd2VyZSBzcGVsbGluZyBlcnJvcnMsIGJ1dCB0dXJucyBvdXQgdG8NCmJlIGRpZmZlcmVuY2Vz IGJldHdlZW4gVUsgYW5kIFVTIEVuZ2xpc2guIEknbSBwcmV0dHkgc3VyZSB0aGF0IHRoZQ0KUkZD IEVkaXRvciB3aWxsIHNldCB0aGF0IHJpZ2h0IChpZiBpdCBpc24ndCBhbHJlYWR5KS4NCg0KVGhl cmUgaXMgb25lIHRoaW5nIHRoYXQgc29tZXRpbWVzIG1ha2VzIGhhcmQgdG8gcGFyc2UgdGhlIGRv Y3VtZW50LA0KdGhlIGFiYnJldmlhdGlvbiBXVFIgc3RhbmRzIGZvciAiV2FpdCB0byByZXN0b3Jl IiwgdGhlIHRoaW5nIGlzIHRoYXQNCldUUiBjYW4gYmUgYSBzdGF0ZSwgYSBtZXNzYWdlIG9yIGEg dGltZXIgKGdpdmVuIHRoYXQgSSB1bmRlcnN0YW5kIGl0DQpjb3JyZWN0bHkpLiBXaGVuIEkgZGlz Y3Vzc2VkIHRoaXMgZWFybGllciB0aGUgYW5zd2VyIGhhcyBiZWVuICJXZWxsDQppdCBpcyBjb25m dXNpbmcsIGJ1dCB0aGF0IGlzIGhvdyBpdCBpcyBkb25lISINCg0KSSB0aGluayBhdCBwbGFjZXMg d2hlcmUgaXQgbmVjZXNzYXJ5IGUuZy4gV1RSIGFyZSBxdWFsaWZpZWQgd2l0aA0Kc3RhdGUsIG1l c3NhZ2Ugb3IgdGltZXIuIEkgZm91bmQgb25lIHBsYWNlIHdoZXJlIHdhbnQgdG8gYWRkIGENCmNs YXJpZnlpbmcgInN0YXRlIiwgIm1lc3NhZ2UiIG9yICJ0aW1lciIuDQoNCnBhZ2UgMTMgbGFzdCBs aW5lIC0gcy9XVFIgZXhwaXJlcy9XVFIgdGltZXIgZXhwaXJlcw0KDQpwYWdlIDIwIDNyZCBsaW5l IGZyb20gdGhlIC0gcy9XVFIgZXhwaXJlcy9XVFIgdGltZXIgZXhwaXJlcw0KDQpwYWdlIDI1IE5v dGUgNCBzL1dUUi9XVFIgc3RhdGUNCg0KcGFnZSAyNSBOb3RlIDYgcy9XVFIvV1RSIHN0YXRlDQoN CnBhZ2UgMjcgTm90ZSAxMSBzL1dUUi9XVFIgc3RhdGUNCg0KRE5SIG1heSBiZSBhIHN0YXRlIG9y IGEgbWVzc2FnZSwgZm9yIGNsYXJpZmljYXRpb24NCg0KcGFnZSAyNyBub3RlIDExIHMvRE5SLi9E TlIgc3RhdGUuDQoNClRoZSBzYW1lIGV4ZXJjaXNlIG1heWJlIGJlIGRvbmUgZm9yIEVYRVIgW2Nv bW1hbmQsIG1lc3NhZ2VdIChhY3R1YWxseQ0KSSB0aGluayB0aGF0IGZvciBFWEVSIHRoaXMgaXMg ZG9uZSBjb3JyZWN0bHkpLCBidXQgaXQgbWlnaHQgdmFsdWFibGUNCnRvIGNoZWNrIGZvciBhbGwg YWJicmV2aWF0aW9ucyB0aGF0IGhhcyBkb3VibGUgbWVhbmluZy4NCg0KSSBkb24ndCB0aGluayBp dCBpcyBuZWNlc3Nhcnkgb3IgZXZlbiBtb3RpdmF0ZWQgdG8gZG8gbW9yZSBhYm91dA0KdGhpcywg YnV0IGl0IG1pZ2h0IGJlIGEgZ29vZCBpZiByZWFkZXJzIG9mIHRoZSBkb2N1bWVudCB3ZXJlIGF3 YXJlIG9mDQp0aGlzLg0KDQpJIHRoaW5rIHRoZSBkb2N1bWVudCAtIG1vZHVsbyBhZGRyZXNzaW5n IGNvbW1lbnRzIGluIHdnbGMgLSBpcyByZWFkeQ0KdG8gZ28uDQoNCi9Mb2ENCg0KT24gMjAxNC0w MS0yMCAxMDoyOCwgTG9hIEFuZGVyc3NvbiB3cm90ZToNCj4gV29ya2luZyBHcm91cCwNCj4NCj4g VGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQo+ IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1Lg0KPg0KPiBQbGVhc2UgZmluZCB0aGUgZG9jdW1l bnQgYXQ6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBs cy10cC1wc2MtaXR1Lw0KPg0KPiBUaGUgZG9jdW1lbnQgZWRpdG9ycyBoYXMgYWxzbyBzdXBwbGll ZCBhICJkaWZmLWxpc3QiIGJldHdlZW4NCj4gdmVyc2lvbiAtMDAgYW5kIC0wMSBhdDoNCj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxMTMzOC5o dG1sDQo+DQo+IElUVS1UIFNHMTUgaGFzIGFkdmlzZWQgdXMgdGhhdCB0aGlzIGRvY3VtZW50IGlz IGEgbmVjZXNzYXJ5IHJlZmVyZW5jZQ0KPiBmb3IgZG9jdW1lbnRzIHRoYXQgaXMgcGxhbm5lZCB0 byBnbyBpbnRvIHRoZSBJVFUtVCBhcHByb3ZhbCBwcm9jZXNzDQo+IGZyb20gdGhlIFNHMTUgbWVl dGluZyBlbmQgb2YgTWFyY2ggLyBiZWdpbm5pbmcgb2YgQXByaWwuIEVkaXRvcnMsDQo+IGF1dGhv cnMgYW5kIGNoYWlycyBoYXMgcHV0IGluIHF1aXRlIGFuIGVmZm9ydCB0byBtYWtlIHRoaXMgZG9j dW1lbnQNCj4gcmVhZHkuIFRoZSBzY2hlZHVsZSBpcyB2ZXJ5IHRpZ2h0Lg0KPg0KPiBXZSBhcmUg bm93IGRvaW5nIHNldmVyYWwgcmV2aWV3IHN0ZXBzIGluIHBhcmFsbGVsDQo+DQo+IC0gdGhlIG5v cm1hbCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCwgcGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0 byB0aGUNCj4gbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZykN Cj4gLSB0aGUgd29ya2luZyBncm91cCBjaGFpcnMgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoZQ0KPiBtcGxzLXJ0IHJldmlldywgbm9ybWFsbHkgd2UgZG8gYSB3ZyBjaGFpciBy ZXZpZXcgYmVmb3JlIHN0YXJ0aW5nIHRoZQ0KPiB3Z2xjLCB0aGlzIHJldmlldyB3aWxsIG5vdyB0 YWtlIHBsYWNlIGluIHBhcmFsbGVsDQo+IC0gYWZ0ZXIgdGhlIHdnbGMgYW5kIHB1YmxpY2F0aW9u IHJlcXVlc3QgdGhlcmUgaXMgYW4gQUQgZXZhbHVhdGlvbiwNCj4gdGhpcyB3aWxsIG5vdyBhbHNv IHRha2UgcGxhY2UgaW4gcGFyYWxsZWwgd2l0aCB0aGUgd2dsYw0KPg0KPiBUaGUgZWRpdG9ycyBh bmQgYXV0aG9ycyBhcmUgYWR2aXNlZCB0byB0cnkgdG8gcmVzb2x2ZSBhcyBtYW55IG9mIHRoZQ0K PiBjb21tZW50cyBhcyBwb3NzaWJsZSAob24gdGhlIG1haWxpbmcgbGlzdCkgYXMgdGhleSBjb21l IGluLCBidXQgbm90IHRvDQo+IHBvc3QgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB1bnRp bCB0aGUgd2dsYyBpcyBjbG9zZWQgYW5kIHRoZQ0KPiBjb21tZW50cyBhcmUgcmVzb2x2ZWQuDQo+ DQo+IFRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBGZWJydWFyeSAzcmQuDQo+DQo+ IC9Mb2ENCj4gZm9yIHRoZSBNUExTIFdHIGNvLWNoYWlycw0KDQotLQ0KDQoNCkxvYSBBbmRlcnNz b24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KU2VuaW9yIE1QTFMgRXhwZXJ0IGxvYUBw aS5udQ0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICs0NiA3MzkgODEg MjEgNjQNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B401BSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsIHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRz LjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPlllcywgd2UgbmVlZCB0byBjbGFyaWZ5Jm5ic3A7 c3RhdGUvbWVzc2FnZSgvdGltZXIpIGZvciBXVFIgYW5kIG90aGVycy48L2Rpdj4NCjxkaXYgc3R5 bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij5PbmUgbWlub3IgY29uY2VybiBpcyB0aGF0ICZxdW90O1dUUiBFeHBpcmVzJnF1 b3Q7IGlzIHVzZWQgYXMgdGhlIG5hbWUgb2YgYSBsb2NhbCByZXF1ZXN0IGluIFJGQyA2Mzc4Ljwv ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkkgYW0gbm90IHN1cmUgaWYgaXQg d291bGQgYmUgb2smbmJzcDt0byBjaGFuZ2UgaXQgdG8gJnF1b3Q7V1RSIFRpbWVyIEV4cGlyZXMm cXVvdDsgaW4gdGhpcyBkb2N1bWVudC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0Ij5Nb3JlIHNwZWNpZmljYWxseSwmbmJzcDt0aGUgcHJvcG9zYWwgb2YgdGhlJm5ic3A7Zm9s bG93aW5nIHR3byBpdGVtcyZuYnNwO25lZWRzIHRoZSBjaGFuZ2Ugb2YgJnF1b3Q7V1RSIEV4cGly ZXMmcXVvdDsgdG8gJnF1b3Q7V1RSIHRpbWVyIGV4cGlyZXMmcXVvdDsgaW4gdGhlIHByaW9yaXR5 IGxpc3Q8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5pbiBwYWdlJm5ic3A7 MTk6PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+LSBwYWdlIDEzIGxhc3Qg bGluZSAtIHMvV1RSIGV4cGlyZXMvV1RSIHRpbWVyIGV4cGlyZXMgKFRoaXMgaXRlbSZuYnNwO3dv dWxkIGRpc2FwcHJlYXIgb25jZSB3ZSB0YWtlIEFkcmlhbidzJm5ic3A7cHJvcG9zYWwgdG8gY2hh bmdlIHdob2xlIHNlbnRlbmNlLikmbmJzcDs8YnI+DQotIHBhZ2UgMjAgM3JkIGxpbmUgZnJvbSB0 aGUgLSBzL1dUUiBleHBpcmVzL1dUUiB0aW1lciBleHBpcmVzPGJyPg0KPGJyPg0KQmVzdCByZWdh cmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRvbmc8L2Rpdj4NCjxkaXYgc3R5 bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4N CjxkaXYgaWQ9Ik1haWxTaWduU2VudCI+PGJyPg0KPC9kaXY+DQo8aHIgdGFiaW5kZXg9Ii0xIj4N CjxiPkZyb20gOiA8L2I+JnF1b3Q7TG9hIEFuZGVyc3NvbiZxdW90OyAmbHQ7bG9hQHBpLm51Jmd0 Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAxNC0wMS0yOCAyMjo1ODoxMCAoICYjNDM7MDk6MDAgKTxi cj4NCjxiPlRvIDogPC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+Q2MgOiA8L2I+bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgJmx0O21wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnJmd0OywgPE1QTFMtQURTQFRPT0xTLklFVEYuT1JHPg0KJmx0O21wbHMtYWRz QHRvb2xzLmlldGYub3JnJmd0OywgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0 Zi5vcmcgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnJmd0Oywg VklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTikgJmx0O21hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1s dWNlbnQuY29tJmd0Ozxicj4NCjxiPlN1YmplY3QgOiA8L2I+UmU6IHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAxPGJyPg0KPGJyPg0KRm9sa3MsPGJy Pg0KPGJyPg0KSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IChhY3R1YWxseSBmb3VydGggb3Ig ZmlmdGggdGltZSkgYW5kIEkgaGF2ZTxicj4NCnZlcnkgZmV3IGNvbW1lbnRzLCBJIHRoaW5rIEFk cmlhbiBjb3ZlcmVkIGFsbCBtaW5lIGluIGhpcyByZXZpZXcuPGJyPg0KPGJyPg0KSSBoYWQgc29t ZXRoaW5nIHRoYXQgSSB0aG91Z2h0IHdlcmUgc3BlbGxpbmcgZXJyb3JzLCBidXQgdHVybnMgb3V0 IHRvPGJyPg0KYmUgZGlmZmVyZW5jZXMgYmV0d2VlbiBVSyBhbmQgVVMgRW5nbGlzaC4gSSdtIHBy ZXR0eSBzdXJlIHRoYXQgdGhlPGJyPg0KUkZDIEVkaXRvciB3aWxsIHNldCB0aGF0IHJpZ2h0IChp ZiBpdCBpc24ndCBhbHJlYWR5KS48YnI+DQo8YnI+DQpUaGVyZSBpcyBvbmUgdGhpbmcgdGhhdCBz b21ldGltZXMgbWFrZXMgaGFyZCB0byBwYXJzZSB0aGUgZG9jdW1lbnQsPGJyPg0KdGhlIGFiYnJl dmlhdGlvbiBXVFIgc3RhbmRzIGZvciAmcXVvdDtXYWl0IHRvIHJlc3RvcmUmcXVvdDssIHRoZSB0 aGluZyBpcyB0aGF0PGJyPg0KV1RSIGNhbiBiZSBhIHN0YXRlLCBhIG1lc3NhZ2Ugb3IgYSB0aW1l ciAoZ2l2ZW4gdGhhdCBJIHVuZGVyc3RhbmQgaXQ8YnI+DQpjb3JyZWN0bHkpLiBXaGVuIEkgZGlz Y3Vzc2VkIHRoaXMgZWFybGllciB0aGUgYW5zd2VyIGhhcyBiZWVuICZxdW90O1dlbGw8YnI+DQpp dCBpcyBjb25mdXNpbmcsIGJ1dCB0aGF0IGlzIGhvdyBpdCBpcyBkb25lISZxdW90Ozxicj4NCjxi cj4NCkkgdGhpbmsgYXQgcGxhY2VzIHdoZXJlIGl0IG5lY2Vzc2FyeSBlLmcuIFdUUiBhcmUgcXVh bGlmaWVkIHdpdGg8YnI+DQpzdGF0ZSwgbWVzc2FnZSBvciB0aW1lci4gSSBmb3VuZCBvbmUgcGxh Y2Ugd2hlcmUgd2FudCB0byBhZGQgYTxicj4NCmNsYXJpZnlpbmcgJnF1b3Q7c3RhdGUmcXVvdDss ICZxdW90O21lc3NhZ2UmcXVvdDsgb3IgJnF1b3Q7dGltZXImcXVvdDsuPGJyPg0KPGJyPg0KcGFn ZSAxMyBsYXN0IGxpbmUgLSBzL1dUUiBleHBpcmVzL1dUUiB0aW1lciBleHBpcmVzPGJyPg0KPGJy Pg0KcGFnZSAyMCAzcmQgbGluZSBmcm9tIHRoZSAtIHMvV1RSIGV4cGlyZXMvV1RSIHRpbWVyIGV4 cGlyZXM8YnI+DQo8YnI+DQpwYWdlIDI1IE5vdGUgNCBzL1dUUi9XVFIgc3RhdGU8YnI+DQo8YnI+ DQpwYWdlIDI1IE5vdGUgNiBzL1dUUi9XVFIgc3RhdGU8YnI+DQo8YnI+DQpwYWdlIDI3IE5vdGUg MTEgcy9XVFIvV1RSIHN0YXRlPGJyPg0KPGJyPg0KRE5SIG1heSBiZSBhIHN0YXRlIG9yIGEgbWVz c2FnZSwgZm9yIGNsYXJpZmljYXRpb248YnI+DQo8YnI+DQpwYWdlIDI3IG5vdGUgMTEgcy9ETlIu L0ROUiBzdGF0ZS48YnI+DQo8YnI+DQpUaGUgc2FtZSBleGVyY2lzZSBtYXliZSBiZSBkb25lIGZv ciBFWEVSIFtjb21tYW5kLCBtZXNzYWdlXSAoYWN0dWFsbHk8YnI+DQpJIHRoaW5rIHRoYXQgZm9y IEVYRVIgdGhpcyBpcyBkb25lIGNvcnJlY3RseSksIGJ1dCBpdCBtaWdodCB2YWx1YWJsZTxicj4N CnRvIGNoZWNrIGZvciBhbGwgYWJicmV2aWF0aW9ucyB0aGF0IGhhcyBkb3VibGUgbWVhbmluZy48 YnI+DQo8YnI+DQpJIGRvbid0IHRoaW5rIGl0IGlzIG5lY2Vzc2FyeSBvciBldmVuIG1vdGl2YXRl ZCB0byBkbyBtb3JlIGFib3V0PGJyPg0KdGhpcywgYnV0IGl0IG1pZ2h0IGJlIGEgZ29vZCBpZiBy ZWFkZXJzIG9mIHRoZSBkb2N1bWVudCB3ZXJlIGF3YXJlIG9mPGJyPg0KdGhpcy48YnI+DQo8YnI+ DQpJIHRoaW5rIHRoZSBkb2N1bWVudCAtIG1vZHVsbyBhZGRyZXNzaW5nIGNvbW1lbnRzIGluIHdn bGMgLSBpcyByZWFkeTxicj4NCnRvIGdvLjxicj4NCjxicj4NCi9Mb2E8YnI+DQo8YnI+DQpPbiAy MDE0LTAxLTIwIDEwOjI4LCBMb2EgQW5kZXJzc29uIHdyb3RlOjxicj4NCiZndDsgV29ya2luZyBH cm91cCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29y a2luZyBncm91cCBsYXN0IGNhbGwgb248YnI+DQomZ3Q7IGRyYWZ0LWlldGYtbXBscy10cC1wc2Mt aXR1Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFBsZWFzZSBmaW5kIHRoZSBkb2N1bWVudCBhdDo8YnI+ DQomZ3Q7IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy10 cC1wc2MtaXR1Lzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBkb2N1bWVudCBlZGl0b3JzIGhhcyBh bHNvIHN1cHBsaWVkIGEgJnF1b3Q7ZGlmZi1saXN0JnF1b3Q7IGJldHdlZW48YnI+DQomZ3Q7IHZl cnNpb24gLTAwIGFuZCAtMDEgYXQ6PGJyPg0KJmd0OyBodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzExMzM4Lmh0bWw8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJVFUtVCBTRzE1IGhhcyBhZHZpc2VkIHVzIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBhIG5lY2Vz c2FyeSByZWZlcmVuY2U8YnI+DQomZ3Q7IGZvciBkb2N1bWVudHMgdGhhdCBpcyBwbGFubmVkIHRv IGdvIGludG8gdGhlIElUVS1UIGFwcHJvdmFsIHByb2Nlc3M8YnI+DQomZ3Q7IGZyb20gdGhlIFNH MTUgbWVldGluZyBlbmQgb2YgTWFyY2ggLyBiZWdpbm5pbmcgb2YgQXByaWwuIEVkaXRvcnMsPGJy Pg0KJmd0OyBhdXRob3JzIGFuZCBjaGFpcnMgaGFzIHB1dCBpbiBxdWl0ZSBhbiBlZmZvcnQgdG8g bWFrZSB0aGlzIGRvY3VtZW50PGJyPg0KJmd0OyByZWFkeS4gVGhlIHNjaGVkdWxlIGlzIHZlcnkg dGlnaHQuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2UgYXJlIG5vdyBkb2luZyBzZXZlcmFsIHJldmll dyBzdGVwcyBpbiBwYXJhbGxlbDxicj4NCiZndDs8YnI+DQomZ3Q7IC0gdGhlIG5vcm1hbCB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCwgcGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGU8YnI+ DQomZ3Q7IG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmcpPGJy Pg0KJmd0OyAtIHRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyByZXZpZXdlZCB0aGlzIGRvY3VtZW50 IGFzIHBhcnQgb2YgdGhlPGJyPg0KJmd0OyBtcGxzLXJ0IHJldmlldywgbm9ybWFsbHkgd2UgZG8g YSB3ZyBjaGFpciByZXZpZXcgYmVmb3JlIHN0YXJ0aW5nIHRoZTxicj4NCiZndDsgd2dsYywgdGhp cyByZXZpZXcgd2lsbCBub3cgdGFrZSBwbGFjZSBpbiBwYXJhbGxlbDxicj4NCiZndDsgLSBhZnRl ciB0aGUgd2dsYyBhbmQgcHVibGljYXRpb24gcmVxdWVzdCB0aGVyZSBpcyBhbiBBRCBldmFsdWF0 aW9uLDxicj4NCiZndDsgdGhpcyB3aWxsIG5vdyBhbHNvIHRha2UgcGxhY2UgaW4gcGFyYWxsZWwg d2l0aCB0aGUgd2dsYzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBlZGl0b3JzIGFuZCBhdXRob3Jz IGFyZSBhZHZpc2VkIHRvIHRyeSB0byByZXNvbHZlIGFzIG1hbnkgb2YgdGhlPGJyPg0KJmd0OyBj b21tZW50cyBhcyBwb3NzaWJsZSAob24gdGhlIG1haWxpbmcgbGlzdCkgYXMgdGhleSBjb21lIGlu LCBidXQgbm90IHRvPGJyPg0KJmd0OyBwb3N0IHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQg dW50aWwgdGhlIHdnbGMgaXMgY2xvc2VkIGFuZCB0aGU8YnI+DQomZ3Q7IGNvbW1lbnRzIGFyZSBy ZXNvbHZlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IGVuZHMgRmVicnVhcnkgM3JkLjxicj4NCiZndDs8YnI+DQomZ3Q7IC9Mb2E8YnI+DQomZ3Q7IGZv ciB0aGUgTVBMUyBXRyBjby1jaGFpcnM8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpM b2EgQW5kZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208YnI+DQpTZW5pb3IgTVBM UyBFeHBlcnQgbG9hQHBpLm51PGJyPg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkg cGhvbmU6ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B401BSMTP2etriinfo_-- From cts@etri.re.kr Tue Jan 28 21:38:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A0F1A0198 for ; Tue, 28 Jan 2014 21:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.936 X-Spam-Level: X-Spam-Status: No, score=-98.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535, 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 sff3vvSu1jpd for ; Tue, 28 Jan 2014 21:38:04 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 406471A0193 for ; Tue, 28 Jan 2014 21:38:04 -0800 (PST) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 29 Jan 2014 14:38:02 +0900 Received: from SMTP4.etri.info ([169.254.3.218]) by SMTP3.etri.info ([169.254.157.203]) with mapi id 14.01.0355.002; Wed, 29 Jan 2014 14:37:59 +0900 From: =?ks_c_5601-1987?B?waTFwr3E?= To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll draft-ietf-mpls-tp-psc-itu Thread-Index: AQHPG1UEq+sy4bdcrE6ixlggxqdZvZqbMNLw Date: Wed, 29 Jan 2014 05:37:59 +0000 Message-ID: References: <52E64660.2090900@pi.nu> In-Reply-To: <52E64660.2090900@pi.nu> Accept-Language: en-US, ko-KR Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.73.86] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] IPR poll draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 05:38:06 -0000 RGVhciBhbGwsDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgb24gdGhpcyBkb2N1bWVudC4N Cg0KQmVzdCByZWdhcmRzLA0KVGFlc2lrDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzpsb2FAcGkubnVdIA0KU2VudDogTW9uZGF5LCBK YW51YXJ5IDI3LCAyMDE0IDg6NDMgUE0NClRvOiBtcGxzQGlldGYub3JnDQpDYzogbXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc7IFZJR09VUkVVWCwgTUFSVElOIChNQVJUSU4pOyBkcmFmdC1pZXRm LW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogSVBSIHBvbGwgZHJhZnQt aWV0Zi1tcGxzLXRwLXBzYy1pdHUNCg0KV29ya2luZyBHcm91cCwNCg0KZHJhZnQtaWV0Zi1tcGxz LXRwLXBzYy1pdHUgaXMgaW4gd29ya2luZyBncm91cCBsYXN0IGNhbGwsIHdlIGhhdmUganVzdCBy ZWNlaXZlZCBhbiBJUFIgZGlzY2xvc3VyZToNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxMTQ2OS5odG1sDQoNClRoaXMgZ2l2ZXMgdXMgcmVh c29uIHRvIHN0YXJ0IGFuIElQUiBwb2xsIG9uIHRoZSBkb2N1bWVudC4NCg0KDQpUaGlzIG1haWwg c3RhcnRzIHRoYXQgSVBSIHBvbGwuDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFw cGxpZXMgdG8gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHU/DQoNCklmIHNvLCBoYXMgdGhpcyBJ UFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUg UkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQpDdXJy ZW50bHkgdGhlcmUgaXMgdGhlIG9uZSBJUFIgZGlzY2xvc3VyZSwgbWVudGlvbmVkIGFib3ZlLCB0 aGF0IHJlbGF0ZXMgdG8gdGhpcyBkb2N1bWVudC4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBk b2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFp bCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2 YW50IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIHdnIG1h aWxpbmcgbGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0 YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBh bmQgY29udHJpYnV0b3IuDQoNCklmIHlvdSBhcmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBi dXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFz ZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhh dCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVs ZXMuDQoNClRoYW5rcywgTG9hDQooYXMgTVBMUyBXRyBjby1jaGFpcikNCi0tIA0KDQoNCkxvYSBB bmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWku Y29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5u dQ0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgx IDIxIDY0DQo= From loa@pi.nu Tue Jan 28 22:50:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B051A0373 for ; Tue, 28 Jan 2014 22:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 oW3FJgevoiBk for ; Tue, 28 Jan 2014 22:50:08 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 322FD1A03F7 for ; Tue, 28 Jan 2014 22:50:08 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.65.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1AD43180150F; Wed, 29 Jan 2014 07:50:02 +0100 (CET) Message-ID: <52E8A495.1050501@pi.nu> Date: Wed, 29 Jan 2014 14:49:57 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Ryoo, Jeong-dong" , "mpls@ietf.org" References: <52DC89C3.3030003@pi.nu>, <52E7B75F.6010805@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286B401B@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B401B@SMTP2.etri.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 06:50:11 -0000 Jeong-dong, I think we are in agreement. For "WTR Expires" I think you understand my concern, do what you think is useful and necessary. Maybe there is Adrian's comment on the page 13 last line could be used to clarify page 20 3rd line also. /Loa On 2014-01-29 12:24, Ryoo, Jeong-dong wrote: > Loa, thanks for the comments. > Yes, we need to clarify state/message(/timer) for WTR and others. > One minor concern is that "WTR Expires" is used as the name of a local > request in RFC 6378. > I am not sure if it would be ok to change it to "WTR Timer Expires" in > this document. > More specifically, the proposal of the following two items needs the > change of "WTR Expires" to "WTR timer expires" in the priority list > in page 19: > - page 13 last line - s/WTR expires/WTR timer expires (This item would > disapprear once we take Adrian's proposal to change whole sentence.) > - page 20 3rd line from the - s/WTR expires/WTR timer expires > > Best regards, > Jeong-dong > > ------------------------------------------------------------------------ > *From : *"Loa Andersson" > *Sent : *2014-01-28 22:58:10 ( +09:00 ) > *To : *mpls@ietf.org > *Cc : *mpls-chairs@tools.ietf.org , > , draft-ietf-mpls-tp-psc-itu@tools.ietf.org > , VIGOUREUX, MARTIN (MARTIN) > > *Subject : *Re: working group last call draft-ietf-mpls-tp-psc-itu-01 > > Folks, > > I've reviewed this document (actually fourth or fifth time) and I have > very few comments, I think Adrian covered all mine in his review. > > I had something that I thought were spelling errors, but turns out to > be differences between UK and US English. I'm pretty sure that the > RFC Editor will set that right (if it isn't already). > > There is one thing that sometimes makes hard to parse the document, > the abbreviation WTR stands for "Wait to restore", the thing is that > WTR can be a state, a message or a timer (given that I understand it > correctly). When I discussed this earlier the answer has been "Well > it is confusing, but that is how it is done!" > > I think at places where it necessary e.g. WTR are qualified with > state, message or timer. I found one place where want to add a > clarifying "state", "message" or "timer". > > page 13 last line - s/WTR expires/WTR timer expires > > page 20 3rd line from the - s/WTR expires/WTR timer expires > > page 25 Note 4 s/WTR/WTR state > > page 25 Note 6 s/WTR/WTR state > > page 27 Note 11 s/WTR/WTR state > > DNR may be a state or a message, for clarification > > page 27 note 11 s/DNR./DNR state. > > The same exercise maybe be done for EXER [command, message] (actually > I think that for EXER this is done correctly), but it might valuable > to check for all abbreviations that has double meaning. > > I don't think it is necessary or even motivated to do more about > this, but it might be a good if readers of the document were aware of > this. > > I think the document - modulo addressing comments in wglc - is ready > to go. > > /Loa > > On 2014-01-20 10:28, Loa Andersson wrote: > > Working Group, > > > > This is to start a two week working group last call on > > draft-ietf-mpls-tp-psc-itu. > > > > Please find the document at: > > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ > > > > The document editors has also supplied a "diff-list" between > > version -00 and -01 at: > > http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html > > > > ITU-T SG15 has advised us that this document is a necessary reference > > for documents that is planned to go into the ITU-T approval process > > from the SG15 meeting end of March / beginning of April. Editors, > > authors and chairs has put in quite an effort to make this document > > ready. The schedule is very tight. > > > > We are now doing several review steps in parallel > > > > - the normal working group last call, please send your comments to the > > mpls working group mailing list (mpls@ietf.org) > > - the working group chairs reviewed this document as part of the > > mpls-rt review, normally we do a wg chair review before starting the > > wglc, this review will now take place in parallel > > - after the wglc and publication request there is an AD evaluation, > > this will now also take place in parallel with the wglc > > > > The editors and authors are advised to try to resolve as many of the > > comments as possible (on the mailing list) as they come in, but not to > > post the new version of the draft until the wglc is closed and the > > comments are resolved. > > > > This working group last call ends February 3rd. > > > > /Loa > > for the MPLS WG co-chairs > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Tue Jan 28 23:11:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E3B1A0437 for ; Tue, 28 Jan 2014 23:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 aFcXVLJpwJxn for ; Tue, 28 Jan 2014 23:11:50 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 74CFE1A0420 for ; Tue, 28 Jan 2014 23:11:50 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.65.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 7AD34180150F; Wed, 29 Jan 2014 08:11:45 +0100 (CET) Message-ID: <52E8A9AC.3080102@pi.nu> Date: Wed, 29 Jan 2014 15:11:40 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" , Adrian Farrel References: <52DE4BB7.80408@pi.nu> In-Reply-To: <52DE4BB7.80408@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org" Subject: [mpls] Closed - Re: Short working group last call on draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 07:11:52 -0000 Working Group, This short working group last call has been closed. The only comments we had support going ahead with the publication request. We will update the shepherd write-up and inform the responsible AD that the working group support that this document is progressed. /Loa for the mpls wg co-chairs On 2014-01-21 18:28, Loa Andersson wrote: > Working Group, > > We did a working group last call on draft-ietf-mpls-ldp-applicability- > label-adv in March 2013. The draft was updated according to the wglc > comments and Publication Requested. > > The AD evaluation and the discussion with the authors resultetd in > changes that makes it reasonable to verify that the working group are > comfortable with the changes that has been doen. > > Please send your comments to the working group mailing list > (mpls@ietf.org). In this case silence will be interpreted as > agreement. > > This working group last call ends January 28th, 2014. > > /Loa > mpls wg co-chair > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From ryoo@etri.re.kr Tue Jan 28 23:18:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126EE1A0437 for ; Tue, 28 Jan 2014 23:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RP_MATCHES_RCVD=-0.535, 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 3Bqk-SjZjpuc for ; Tue, 28 Jan 2014 23:18:21 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2E13F1A0420 for ; Tue, 28 Jan 2014 23:18:21 -0800 (PST) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 29 Jan 2014 16:18:16 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Wed, 29 Jan 2014 16:18:15 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: working group last call draft-ietf-mpls-tp-psc-itu-01 Thread-Index: AQHPHDD6PxX4EfDenE+JJCp9uCTk/JqbAWPi//+sAICAAJ6sqw== Date: Wed, 29 Jan 2014 07:18:15 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B4092@SMTP2.etri.info> References: <52DC89C3.3030003@pi.nu>,<52E7B75F.6010805@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286B401B@SMTP2.etri.info>, <52E8A495.1050501@pi.nu> In-Reply-To: <52E8A495.1050501@pi.nu> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B4092SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 07:18:26 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B4092SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLCB0aGFua3MuDQoNCkplb25nLWRvbmcNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbSA6ICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51Pg0KU2VudCA6IDIwMTQt MDEtMjkgMTU6NTA6MDcgKCArMDk6MDAgKQ0KVG8gOiBSeW9vLCBKZW9uZy1kb25nIDxyeW9vQGV0 cmkucmUua3I+LCBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPg0KQ2MgOiBtcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZyA8bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+LCBkcmFmdC1pZXRm LW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1p dHVAdG9vbHMuaWV0Zi5vcmc+LCBWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKSA8bWFydGluLnZp Z291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20+DQpTdWJqZWN0IDogUmU6IHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAxDQoNCkplb25nLWRvbmcsDQoN CkkgdGhpbmsgd2UgYXJlIGluIGFncmVlbWVudC4gRm9yICJXVFIgRXhwaXJlcyIgSSB0aGluayB5 b3UgdW5kZXJzdGFuZA0KbXkgY29uY2VybiwgZG8gd2hhdCB5b3UgdGhpbmsgaXMgdXNlZnVsIGFu ZCBuZWNlc3NhcnkuIE1heWJlIHRoZXJlIGlzDQpBZHJpYW4ncyBjb21tZW50IG9uIHRoZSBwYWdl IDEzIGxhc3QgbGluZSBjb3VsZCBiZSB1c2VkIHRvIGNsYXJpZnkNCnBhZ2UgMjAgM3JkIGxpbmUg YWxzby4NCg0KL0xvYQ0KDQoNCk9uIDIwMTQtMDEtMjkgMTI6MjQsIFJ5b28sIEplb25nLWRvbmcg d3JvdGU6DQo+IExvYSwgdGhhbmtzIGZvciB0aGUgY29tbWVudHMuDQo+IFllcywgd2UgbmVlZCB0 byBjbGFyaWZ5IHN0YXRlL21lc3NhZ2UoL3RpbWVyKSBmb3IgV1RSIGFuZCBvdGhlcnMuDQo+IE9u ZSBtaW5vciBjb25jZXJuIGlzIHRoYXQgIldUUiBFeHBpcmVzIiBpcyB1c2VkIGFzIHRoZSBuYW1l IG9mIGEgbG9jYWwNCj4gcmVxdWVzdCBpbiBSRkMgNjM3OC4NCj4gSSBhbSBub3Qgc3VyZSBpZiBp dCB3b3VsZCBiZSBvayB0byBjaGFuZ2UgaXQgdG8gIldUUiBUaW1lciBFeHBpcmVzIiBpbg0KPiB0 aGlzIGRvY3VtZW50Lg0KPiBNb3JlIHNwZWNpZmljYWxseSwgdGhlIHByb3Bvc2FsIG9mIHRoZSBm b2xsb3dpbmcgdHdvIGl0ZW1zIG5lZWRzIHRoZQ0KPiBjaGFuZ2Ugb2YgIldUUiBFeHBpcmVzIiB0 byAiV1RSIHRpbWVyIGV4cGlyZXMiIGluIHRoZSBwcmlvcml0eSBsaXN0DQo+IGluIHBhZ2UgMTk6 DQo+IC0gcGFnZSAxMyBsYXN0IGxpbmUgLSBzL1dUUiBleHBpcmVzL1dUUiB0aW1lciBleHBpcmVz IChUaGlzIGl0ZW0gd291bGQNCj4gZGlzYXBwcmVhciBvbmNlIHdlIHRha2UgQWRyaWFuJ3MgcHJv cG9zYWwgdG8gY2hhbmdlIHdob2xlIHNlbnRlbmNlLikNCj4gLSBwYWdlIDIwIDNyZCBsaW5lIGZy b20gdGhlIC0gcy9XVFIgZXhwaXJlcy9XVFIgdGltZXIgZXhwaXJlcw0KPg0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IEplb25nLWRvbmcNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICpGcm9tIDogKiJMb2Eg QW5kZXJzc29uIg0KPiAqU2VudCA6ICoyMDE0LTAxLTI4IDIyOjU4OjEwICggKzA5OjAwICkNCj4g KlRvIDogKm1wbHNAaWV0Zi5vcmcNCj4gKkNjIDogKm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn ICwNCj4gLCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZw0KPiAsIFZJ R09VUkVVWCwgTUFSVElOIChNQVJUSU4pDQo+DQo+ICpTdWJqZWN0IDogKlJlOiB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMQ0KPg0KPiBGb2xrcywN Cj4NCj4gSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IChhY3R1YWxseSBmb3VydGggb3IgZmlm dGggdGltZSkgYW5kIEkgaGF2ZQ0KPiB2ZXJ5IGZldyBjb21tZW50cywgSSB0aGluayBBZHJpYW4g Y292ZXJlZCBhbGwgbWluZSBpbiBoaXMgcmV2aWV3Lg0KPg0KPiBJIGhhZCBzb21ldGhpbmcgdGhh dCBJIHRob3VnaHQgd2VyZSBzcGVsbGluZyBlcnJvcnMsIGJ1dCB0dXJucyBvdXQgdG8NCj4gYmUg ZGlmZmVyZW5jZXMgYmV0d2VlbiBVSyBhbmQgVVMgRW5nbGlzaC4gSSdtIHByZXR0eSBzdXJlIHRo YXQgdGhlDQo+IFJGQyBFZGl0b3Igd2lsbCBzZXQgdGhhdCByaWdodCAoaWYgaXQgaXNuJ3QgYWxy ZWFkeSkuDQo+DQo+IFRoZXJlIGlzIG9uZSB0aGluZyB0aGF0IHNvbWV0aW1lcyBtYWtlcyBoYXJk IHRvIHBhcnNlIHRoZSBkb2N1bWVudCwNCj4gdGhlIGFiYnJldmlhdGlvbiBXVFIgc3RhbmRzIGZv ciAiV2FpdCB0byByZXN0b3JlIiwgdGhlIHRoaW5nIGlzIHRoYXQNCj4gV1RSIGNhbiBiZSBhIHN0 YXRlLCBhIG1lc3NhZ2Ugb3IgYSB0aW1lciAoZ2l2ZW4gdGhhdCBJIHVuZGVyc3RhbmQgaXQNCj4g Y29ycmVjdGx5KS4gV2hlbiBJIGRpc2N1c3NlZCB0aGlzIGVhcmxpZXIgdGhlIGFuc3dlciBoYXMg YmVlbiAiV2VsbA0KPiBpdCBpcyBjb25mdXNpbmcsIGJ1dCB0aGF0IGlzIGhvdyBpdCBpcyBkb25l ISINCj4NCj4gSSB0aGluayBhdCBwbGFjZXMgd2hlcmUgaXQgbmVjZXNzYXJ5IGUuZy4gV1RSIGFy ZSBxdWFsaWZpZWQgd2l0aA0KPiBzdGF0ZSwgbWVzc2FnZSBvciB0aW1lci4gSSBmb3VuZCBvbmUg cGxhY2Ugd2hlcmUgd2FudCB0byBhZGQgYQ0KPiBjbGFyaWZ5aW5nICJzdGF0ZSIsICJtZXNzYWdl IiBvciAidGltZXIiLg0KPg0KPiBwYWdlIDEzIGxhc3QgbGluZSAtIHMvV1RSIGV4cGlyZXMvV1RS IHRpbWVyIGV4cGlyZXMNCj4NCj4gcGFnZSAyMCAzcmQgbGluZSBmcm9tIHRoZSAtIHMvV1RSIGV4 cGlyZXMvV1RSIHRpbWVyIGV4cGlyZXMNCj4NCj4gcGFnZSAyNSBOb3RlIDQgcy9XVFIvV1RSIHN0 YXRlDQo+DQo+IHBhZ2UgMjUgTm90ZSA2IHMvV1RSL1dUUiBzdGF0ZQ0KPg0KPiBwYWdlIDI3IE5v dGUgMTEgcy9XVFIvV1RSIHN0YXRlDQo+DQo+IEROUiBtYXkgYmUgYSBzdGF0ZSBvciBhIG1lc3Nh Z2UsIGZvciBjbGFyaWZpY2F0aW9uDQo+DQo+IHBhZ2UgMjcgbm90ZSAxMSBzL0ROUi4vRE5SIHN0 YXRlLg0KPg0KPiBUaGUgc2FtZSBleGVyY2lzZSBtYXliZSBiZSBkb25lIGZvciBFWEVSIFtjb21t YW5kLCBtZXNzYWdlXSAoYWN0dWFsbHkNCj4gSSB0aGluayB0aGF0IGZvciBFWEVSIHRoaXMgaXMg ZG9uZSBjb3JyZWN0bHkpLCBidXQgaXQgbWlnaHQgdmFsdWFibGUNCj4gdG8gY2hlY2sgZm9yIGFs bCBhYmJyZXZpYXRpb25zIHRoYXQgaGFzIGRvdWJsZSBtZWFuaW5nLg0KPg0KPiBJIGRvbid0IHRo aW5rIGl0IGlzIG5lY2Vzc2FyeSBvciBldmVuIG1vdGl2YXRlZCB0byBkbyBtb3JlIGFib3V0DQo+ IHRoaXMsIGJ1dCBpdCBtaWdodCBiZSBhIGdvb2QgaWYgcmVhZGVycyBvZiB0aGUgZG9jdW1lbnQg d2VyZSBhd2FyZSBvZg0KPiB0aGlzLg0KPg0KPiBJIHRoaW5rIHRoZSBkb2N1bWVudCAtIG1vZHVs byBhZGRyZXNzaW5nIGNvbW1lbnRzIGluIHdnbGMgLSBpcyByZWFkeQ0KPiB0byBnby4NCj4NCj4g L0xvYQ0KPg0KPiBPbiAyMDE0LTAxLTIwIDEwOjI4LCBMb2EgQW5kZXJzc29uIHdyb3RlOg0KPiA+ IFdvcmtpbmcgR3JvdXAsDQo+ID4NCj4gPiBUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29y a2luZyBncm91cCBsYXN0IGNhbGwgb24NCj4gPiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS4N Cj4gPg0KPiA+IFBsZWFzZSBmaW5kIHRoZSBkb2N1bWVudCBhdDoNCj4gPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS8NCj4gPg0KPiA+ IFRoZSBkb2N1bWVudCBlZGl0b3JzIGhhcyBhbHNvIHN1cHBsaWVkIGEgImRpZmYtbGlzdCIgYmV0 d2Vlbg0KPiA+IHZlcnNpb24gLTAwIGFuZCAtMDEgYXQ6DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxMTMzOC5odG1sDQo+ID4NCj4gPiBJ VFUtVCBTRzE1IGhhcyBhZHZpc2VkIHVzIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBhIG5lY2Vzc2Fy eSByZWZlcmVuY2UNCj4gPiBmb3IgZG9jdW1lbnRzIHRoYXQgaXMgcGxhbm5lZCB0byBnbyBpbnRv IHRoZSBJVFUtVCBhcHByb3ZhbCBwcm9jZXNzDQo+ID4gZnJvbSB0aGUgU0cxNSBtZWV0aW5nIGVu ZCBvZiBNYXJjaCAvIGJlZ2lubmluZyBvZiBBcHJpbC4gRWRpdG9ycywNCj4gPiBhdXRob3JzIGFu ZCBjaGFpcnMgaGFzIHB1dCBpbiBxdWl0ZSBhbiBlZmZvcnQgdG8gbWFrZSB0aGlzIGRvY3VtZW50 DQo+ID4gcmVhZHkuIFRoZSBzY2hlZHVsZSBpcyB2ZXJ5IHRpZ2h0Lg0KPiA+DQo+ID4gV2UgYXJl IG5vdyBkb2luZyBzZXZlcmFsIHJldmlldyBzdGVwcyBpbiBwYXJhbGxlbA0KPiA+DQo+ID4gLSB0 aGUgbm9ybWFsIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLCBwbGVhc2Ugc2VuZCB5b3VyIGNvbW1l bnRzIHRvIHRoZQ0KPiA+IG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0 Zi5vcmcpDQo+ID4gLSB0aGUgd29ya2luZyBncm91cCBjaGFpcnMgcmV2aWV3ZWQgdGhpcyBkb2N1 bWVudCBhcyBwYXJ0IG9mIHRoZQ0KPiA+IG1wbHMtcnQgcmV2aWV3LCBub3JtYWxseSB3ZSBkbyBh IHdnIGNoYWlyIHJldmlldyBiZWZvcmUgc3RhcnRpbmcgdGhlDQo+ID4gd2dsYywgdGhpcyByZXZp ZXcgd2lsbCBub3cgdGFrZSBwbGFjZSBpbiBwYXJhbGxlbA0KPiA+IC0gYWZ0ZXIgdGhlIHdnbGMg YW5kIHB1YmxpY2F0aW9uIHJlcXVlc3QgdGhlcmUgaXMgYW4gQUQgZXZhbHVhdGlvbiwNCj4gPiB0 aGlzIHdpbGwgbm93IGFsc28gdGFrZSBwbGFjZSBpbiBwYXJhbGxlbCB3aXRoIHRoZSB3Z2xjDQo+ ID4NCj4gPiBUaGUgZWRpdG9ycyBhbmQgYXV0aG9ycyBhcmUgYWR2aXNlZCB0byB0cnkgdG8gcmVz b2x2ZSBhcyBtYW55IG9mIHRoZQ0KPiA+IGNvbW1lbnRzIGFzIHBvc3NpYmxlIChvbiB0aGUgbWFp bGluZyBsaXN0KSBhcyB0aGV5IGNvbWUgaW4sIGJ1dCBub3QgdG8NCj4gPiBwb3N0IHRoZSBuZXcg dmVyc2lvbiBvZiB0aGUgZHJhZnQgdW50aWwgdGhlIHdnbGMgaXMgY2xvc2VkIGFuZCB0aGUNCj4g PiBjb21tZW50cyBhcmUgcmVzb2x2ZWQuDQo+ID4NCj4gPiBUaGlzIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIGVuZHMgRmVicnVhcnkgM3JkLg0KPiA+DQo+ID4gL0xvYQ0KPiA+IGZvciB0aGUgTVBM UyBXRyBjby1jaGFpcnMNCj4NCj4gLS0NCj4NCj4NCj4gTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9h QG1haWwwMS5odWF3ZWkuY29tDQo+IFNlbmlvciBNUExTIEV4cGVydCBsb2FAcGkubnUNCj4gSHVh d2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg0K LS0NCg0KDQpMb2EgQW5kZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NClNlbmlv ciBNUExTIEV4cGVydCBsb2FAcGkubnUNCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQp IHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B4092SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsIHRoYW5rcy48L2Rpdj4NCjxkaXYgc3R5 bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij5KZW9uZy1kb25nPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgaWQ9Ik1haWxT aWduIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxociB0 YWJpbmRleD0iLTEiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGI+ RnJvbSA6IDwvYj4mcXVvdDtMb2EgQW5kZXJzc29uJnF1b3Q7ICZsdDtsb2FAcGkubnUmZ3Q7PGJy Pg0KPGI+U2VudCA6IDwvYj4yMDE0LTAxLTI5IDE1OjUwOjA3ICggJiM0MzswOTowMCApPGJyPg0K PGI+VG8gOiA8L2I+UnlvbywgSmVvbmctZG9uZyAmbHQ7cnlvb0BldHJpLnJlLmtyJmd0OywgbXBs c0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYyA6IDwvYj5tcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7LCBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmZ3Q7LCBWSUdPVVJFVVgsIE1BUlRJTiAoTUFS VElOKSAmbHQ7bWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7PGJyPg0KPGI+ U3ViamVjdCA6IDwvYj5SZTogd29ya2luZyBncm91cCBsYXN0IGNhbGwgZHJhZnQtaWV0Zi1tcGxz LXRwLXBzYy1pdHUtMDE8YnI+DQo8YnI+DQpKZW9uZy1kb25nLDxicj4NCjxicj4NCkkgdGhpbmsg d2UgYXJlIGluIGFncmVlbWVudC4gRm9yICZxdW90O1dUUiBFeHBpcmVzJnF1b3Q7IEkgdGhpbmsg eW91IHVuZGVyc3RhbmQ8YnI+DQpteSBjb25jZXJuLCBkbyB3aGF0IHlvdSB0aGluayBpcyB1c2Vm dWwgYW5kIG5lY2Vzc2FyeS4gTWF5YmUgdGhlcmUgaXM8YnI+DQpBZHJpYW4ncyBjb21tZW50IG9u IHRoZSBwYWdlIDEzIGxhc3QgbGluZSBjb3VsZCBiZSB1c2VkIHRvIGNsYXJpZnk8YnI+DQpwYWdl IDIwIDNyZCBsaW5lIGFsc28uPGJyPg0KPGJyPg0KL0xvYTxicj4NCjxicj4NCjxicj4NCk9uIDIw MTQtMDEtMjkgMTI6MjQsIFJ5b28sIEplb25nLWRvbmcgd3JvdGU6PGJyPg0KJmd0OyBMb2EsIHRo YW5rcyBmb3IgdGhlIGNvbW1lbnRzLjxicj4NCiZndDsgWWVzLCB3ZSBuZWVkIHRvIGNsYXJpZnkg c3RhdGUvbWVzc2FnZSgvdGltZXIpIGZvciBXVFIgYW5kIG90aGVycy48YnI+DQomZ3Q7IE9uZSBt aW5vciBjb25jZXJuIGlzIHRoYXQgJnF1b3Q7V1RSIEV4cGlyZXMmcXVvdDsgaXMgdXNlZCBhcyB0 aGUgbmFtZSBvZiBhIGxvY2FsPGJyPg0KJmd0OyByZXF1ZXN0IGluIFJGQyA2Mzc4Ljxicj4NCiZn dDsgSSBhbSBub3Qgc3VyZSBpZiBpdCB3b3VsZCBiZSBvayB0byBjaGFuZ2UgaXQgdG8gJnF1b3Q7 V1RSIFRpbWVyIEV4cGlyZXMmcXVvdDsgaW48YnI+DQomZ3Q7IHRoaXMgZG9jdW1lbnQuPGJyPg0K Jmd0OyBNb3JlIHNwZWNpZmljYWxseSwgdGhlIHByb3Bvc2FsIG9mIHRoZSBmb2xsb3dpbmcgdHdv IGl0ZW1zIG5lZWRzIHRoZTxicj4NCiZndDsgY2hhbmdlIG9mICZxdW90O1dUUiBFeHBpcmVzJnF1 b3Q7IHRvICZxdW90O1dUUiB0aW1lciBleHBpcmVzJnF1b3Q7IGluIHRoZSBwcmlvcml0eSBsaXN0 PGJyPg0KJmd0OyBpbiBwYWdlIDE5Ojxicj4NCiZndDsgLSBwYWdlIDEzIGxhc3QgbGluZSAtIHMv V1RSIGV4cGlyZXMvV1RSIHRpbWVyIGV4cGlyZXMgKFRoaXMgaXRlbSB3b3VsZDxicj4NCiZndDsg ZGlzYXBwcmVhciBvbmNlIHdlIHRha2UgQWRyaWFuJ3MgcHJvcG9zYWwgdG8gY2hhbmdlIHdob2xl IHNlbnRlbmNlLik8YnI+DQomZ3Q7IC0gcGFnZSAyMCAzcmQgbGluZSBmcm9tIHRoZSAtIHMvV1RS IGV4cGlyZXMvV1RSIHRpbWVyIGV4cGlyZXM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBCZXN0IHJlZ2Fy ZHMsPGJyPg0KJmd0OyBKZW9uZy1kb25nPGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KJmd0OyAqRnJvbSA6IComcXVvdDtMb2EgQW5kZXJzc29uJnF1b3Q7IDxMT0FAUEku TlU+PGJyPg0KJmd0OyAqU2VudCA6ICoyMDE0LTAxLTI4IDIyOjU4OjEwICggJiM0MzswOTowMCAp PGJyPg0KJmd0OyAqVG8gOiAqbXBsc0BpZXRmLm9yZyA8TVBMU0BJRVRGLk9SRz48YnI+DQomZ3Q7 ICpDYyA6ICptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyA8TVBMUy1DSEFJUlNAVE9PTFMuSUVU Ri5PUkc+LDxicj4NCiZndDsgPE1QTFMtQURTQFRPT0xTLklFVEYuT1JHPiwgZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc8YnI+DQomZ3Q7IDxEUkFGVC1JRVRGLU1QTFMt VFAtUFNDLUlUVUBUT09MUy5JRVRGLk9SRz4sIFZJR09VUkVVWCwgTUFSVElOIChNQVJUSU4pPGJy Pg0KJmd0OyA8TUFSVElOLlZJR09VUkVVWEBBTENBVEVMLUxVQ0VOVC5DT00+PGJyPg0KJmd0OyAq U3ViamVjdCA6ICpSZTogd29ya2luZyBncm91cCBsYXN0IGNhbGwgZHJhZnQtaWV0Zi1tcGxzLXRw LXBzYy1pdHUtMDE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGb2xrcyw8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgKGFjdHVhbGx5IGZvdXJ0aCBvciBmaWZ0aCB0 aW1lKSBhbmQgSSBoYXZlPGJyPg0KJmd0OyB2ZXJ5IGZldyBjb21tZW50cywgSSB0aGluayBBZHJp YW4gY292ZXJlZCBhbGwgbWluZSBpbiBoaXMgcmV2aWV3Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEkg aGFkIHNvbWV0aGluZyB0aGF0IEkgdGhvdWdodCB3ZXJlIHNwZWxsaW5nIGVycm9ycywgYnV0IHR1 cm5zIG91dCB0bzxicj4NCiZndDsgYmUgZGlmZmVyZW5jZXMgYmV0d2VlbiBVSyBhbmQgVVMgRW5n bGlzaC4gSSdtIHByZXR0eSBzdXJlIHRoYXQgdGhlPGJyPg0KJmd0OyBSRkMgRWRpdG9yIHdpbGwg c2V0IHRoYXQgcmlnaHQgKGlmIGl0IGlzbid0IGFscmVhZHkpLjxicj4NCiZndDs8YnI+DQomZ3Q7 IFRoZXJlIGlzIG9uZSB0aGluZyB0aGF0IHNvbWV0aW1lcyBtYWtlcyBoYXJkIHRvIHBhcnNlIHRo ZSBkb2N1bWVudCw8YnI+DQomZ3Q7IHRoZSBhYmJyZXZpYXRpb24gV1RSIHN0YW5kcyBmb3IgJnF1 b3Q7V2FpdCB0byByZXN0b3JlJnF1b3Q7LCB0aGUgdGhpbmcgaXMgdGhhdDxicj4NCiZndDsgV1RS IGNhbiBiZSBhIHN0YXRlLCBhIG1lc3NhZ2Ugb3IgYSB0aW1lciAoZ2l2ZW4gdGhhdCBJIHVuZGVy c3RhbmQgaXQ8YnI+DQomZ3Q7IGNvcnJlY3RseSkuIFdoZW4gSSBkaXNjdXNzZWQgdGhpcyBlYXJs aWVyIHRoZSBhbnN3ZXIgaGFzIGJlZW4gJnF1b3Q7V2VsbDxicj4NCiZndDsgaXQgaXMgY29uZnVz aW5nLCBidXQgdGhhdCBpcyBob3cgaXQgaXMgZG9uZSEmcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJIHRoaW5rIGF0IHBsYWNlcyB3aGVyZSBpdCBuZWNlc3NhcnkgZS5nLiBXVFIgYXJlIHF1YWxp ZmllZCB3aXRoPGJyPg0KJmd0OyBzdGF0ZSwgbWVzc2FnZSBvciB0aW1lci4gSSBmb3VuZCBvbmUg cGxhY2Ugd2hlcmUgd2FudCB0byBhZGQgYTxicj4NCiZndDsgY2xhcmlmeWluZyAmcXVvdDtzdGF0 ZSZxdW90OywgJnF1b3Q7bWVzc2FnZSZxdW90OyBvciAmcXVvdDt0aW1lciZxdW90Oy48YnI+DQom Z3Q7PGJyPg0KJmd0OyBwYWdlIDEzIGxhc3QgbGluZSAtIHMvV1RSIGV4cGlyZXMvV1RSIHRpbWVy IGV4cGlyZXM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBwYWdlIDIwIDNyZCBsaW5lIGZyb20gdGhlIC0g cy9XVFIgZXhwaXJlcy9XVFIgdGltZXIgZXhwaXJlczxicj4NCiZndDs8YnI+DQomZ3Q7IHBhZ2Ug MjUgTm90ZSA0IHMvV1RSL1dUUiBzdGF0ZTxicj4NCiZndDs8YnI+DQomZ3Q7IHBhZ2UgMjUgTm90 ZSA2IHMvV1RSL1dUUiBzdGF0ZTxicj4NCiZndDs8YnI+DQomZ3Q7IHBhZ2UgMjcgTm90ZSAxMSBz L1dUUi9XVFIgc3RhdGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyBETlIgbWF5IGJlIGEgc3RhdGUgb3Ig YSBtZXNzYWdlLCBmb3IgY2xhcmlmaWNhdGlvbjxicj4NCiZndDs8YnI+DQomZ3Q7IHBhZ2UgMjcg bm90ZSAxMSBzL0ROUi4vRE5SIHN0YXRlLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBzYW1lIGV4 ZXJjaXNlIG1heWJlIGJlIGRvbmUgZm9yIEVYRVIgW2NvbW1hbmQsIG1lc3NhZ2VdIChhY3R1YWxs eTxicj4NCiZndDsgSSB0aGluayB0aGF0IGZvciBFWEVSIHRoaXMgaXMgZG9uZSBjb3JyZWN0bHkp LCBidXQgaXQgbWlnaHQgdmFsdWFibGU8YnI+DQomZ3Q7IHRvIGNoZWNrIGZvciBhbGwgYWJicmV2 aWF0aW9ucyB0aGF0IGhhcyBkb3VibGUgbWVhbmluZy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGRv bid0IHRoaW5rIGl0IGlzIG5lY2Vzc2FyeSBvciBldmVuIG1vdGl2YXRlZCB0byBkbyBtb3JlIGFi b3V0PGJyPg0KJmd0OyB0aGlzLCBidXQgaXQgbWlnaHQgYmUgYSBnb29kIGlmIHJlYWRlcnMgb2Yg dGhlIGRvY3VtZW50IHdlcmUgYXdhcmUgb2Y8YnI+DQomZ3Q7IHRoaXMuPGJyPg0KJmd0Ozxicj4N CiZndDsgSSB0aGluayB0aGUgZG9jdW1lbnQgLSBtb2R1bG8gYWRkcmVzc2luZyBjb21tZW50cyBp biB3Z2xjIC0gaXMgcmVhZHk8YnI+DQomZ3Q7IHRvIGdvLjxicj4NCiZndDs8YnI+DQomZ3Q7IC9M b2E8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAyMDE0LTAxLTIwIDEwOjI4LCBMb2EgQW5kZXJzc29u IHdyb3RlOjxicj4NCiZndDsgJmd0OyBXb3JraW5nIEdyb3VwLDxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyBUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgb248YnI+DQomZ3Q7ICZndDsgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUuPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFBsZWFzZSBmaW5kIHRoZSBkb2N1bWVudCBhdDo8YnI+ DQomZ3Q7ICZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHUvPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoZSBkb2N1bWVu dCBlZGl0b3JzIGhhcyBhbHNvIHN1cHBsaWVkIGEgJnF1b3Q7ZGlmZi1saXN0JnF1b3Q7IGJldHdl ZW48YnI+DQomZ3Q7ICZndDsgdmVyc2lvbiAtMDAgYW5kIC0wMSBhdDo8YnI+DQomZ3Q7ICZndDsg aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxMTMz OC5odG1sPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IElUVS1UIFNHMTUgaGFzIGFkdmlz ZWQgdXMgdGhhdCB0aGlzIGRvY3VtZW50IGlzIGEgbmVjZXNzYXJ5IHJlZmVyZW5jZTxicj4NCiZn dDsgJmd0OyBmb3IgZG9jdW1lbnRzIHRoYXQgaXMgcGxhbm5lZCB0byBnbyBpbnRvIHRoZSBJVFUt VCBhcHByb3ZhbCBwcm9jZXNzPGJyPg0KJmd0OyAmZ3Q7IGZyb20gdGhlIFNHMTUgbWVldGluZyBl bmQgb2YgTWFyY2ggLyBiZWdpbm5pbmcgb2YgQXByaWwuIEVkaXRvcnMsPGJyPg0KJmd0OyAmZ3Q7 IGF1dGhvcnMgYW5kIGNoYWlycyBoYXMgcHV0IGluIHF1aXRlIGFuIGVmZm9ydCB0byBtYWtlIHRo aXMgZG9jdW1lbnQ8YnI+DQomZ3Q7ICZndDsgcmVhZHkuIFRoZSBzY2hlZHVsZSBpcyB2ZXJ5IHRp Z2h0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBXZSBhcmUgbm93IGRvaW5nIHNldmVy YWwgcmV2aWV3IHN0ZXBzIGluIHBhcmFsbGVsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IC0gdGhlIG5vcm1hbCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCwgcGxlYXNlIHNlbmQgeW91ciBj b21tZW50cyB0byB0aGU8YnI+DQomZ3Q7ICZndDsgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdCAobXBsc0BpZXRmLm9yZyk8YnI+DQomZ3Q7ICZndDsgLSB0aGUgd29ya2luZyBncm91cCBj aGFpcnMgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZTxicj4NCiZndDsgJmd0 OyBtcGxzLXJ0IHJldmlldywgbm9ybWFsbHkgd2UgZG8gYSB3ZyBjaGFpciByZXZpZXcgYmVmb3Jl IHN0YXJ0aW5nIHRoZTxicj4NCiZndDsgJmd0OyB3Z2xjLCB0aGlzIHJldmlldyB3aWxsIG5vdyB0 YWtlIHBsYWNlIGluIHBhcmFsbGVsPGJyPg0KJmd0OyAmZ3Q7IC0gYWZ0ZXIgdGhlIHdnbGMgYW5k IHB1YmxpY2F0aW9uIHJlcXVlc3QgdGhlcmUgaXMgYW4gQUQgZXZhbHVhdGlvbiw8YnI+DQomZ3Q7 ICZndDsgdGhpcyB3aWxsIG5vdyBhbHNvIHRha2UgcGxhY2UgaW4gcGFyYWxsZWwgd2l0aCB0aGUg d2dsYzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgZWRpdG9ycyBhbmQgYXV0aG9y cyBhcmUgYWR2aXNlZCB0byB0cnkgdG8gcmVzb2x2ZSBhcyBtYW55IG9mIHRoZTxicj4NCiZndDsg Jmd0OyBjb21tZW50cyBhcyBwb3NzaWJsZSAob24gdGhlIG1haWxpbmcgbGlzdCkgYXMgdGhleSBj b21lIGluLCBidXQgbm90IHRvPGJyPg0KJmd0OyAmZ3Q7IHBvc3QgdGhlIG5ldyB2ZXJzaW9uIG9m IHRoZSBkcmFmdCB1bnRpbCB0aGUgd2dsYyBpcyBjbG9zZWQgYW5kIHRoZTxicj4NCiZndDsgJmd0 OyBjb21tZW50cyBhcmUgcmVzb2x2ZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRo aXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBGZWJydWFyeSAzcmQuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IC9Mb2E8YnI+DQomZ3Q7ICZndDsgZm9yIHRoZSBNUExTIFdHIGNv LWNoYWlyczxicj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IExvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxicj4NCiZndDsg U2VuaW9yIE1QTFMgRXhwZXJ0IGxvYUBwaS5udTxicj4NCiZndDsgSHVhd2VpIFRlY2hub2xvZ2ll cyAoY29uc3VsdGFudCkgcGhvbmU6ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJyPg0KPGJyPg0KLS0g PGJyPg0KPGJyPg0KPGJyPg0KTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWku Y29tPGJyPg0KU2VuaW9yIE1QTFMgRXhwZXJ0IGxvYUBwaS5udTxicj4NCkh1YXdlaSBUZWNobm9s b2dpZXMgKGNvbnN1bHRhbnQpIHBob25lOiAmIzQzOzQ2IDczOSA4MSAyMSA2NDxicj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B4092SMTP2etriinfo_-- From loa@pi.nu Tue Jan 28 23:33:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1523C1A03DC for ; Tue, 28 Jan 2014 23:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 wcqQypEHH4bG for ; Tue, 28 Jan 2014 23:33:05 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 635691A0239 for ; Tue, 28 Jan 2014 23:33:05 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.65.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 73DA6180150F; Wed, 29 Jan 2014 08:33:00 +0100 (CET) Message-ID: <52E8AEA7.4050402@pi.nu> Date: Wed, 29 Jan 2014 15:32:55 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org" Subject: [mpls] please proceed the publication process for draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 07:33:08 -0000 Adrian, The short working group last call on draft-ietf-mpls-ldp-applicability- label-adv has been closed. We have support to progress the document with the changes that were made during the AD evaluation. The document shepherd write-up has been updated to reflect this. Please re-start the publication process. /Loa document shepherd -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From zhang.xian@huawei.com Wed Jan 29 01:36:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECF81A0437 for ; Wed, 29 Jan 2014 01:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 HO-8WhT0ntJd for ; Wed, 29 Jan 2014 01:36:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF5731A0372 for ; Wed, 29 Jan 2014 01:36:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDB00923; Wed, 29 Jan 2014 09:36:30 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 09:35:55 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 09:36:28 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.167]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 17:36:24 +0800 From: "Zhangxian (Xian)" To: "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Thread-Topic: working group last call draft-ietf-mpls-tp-psc-itu-01 Thread-Index: AQHPFYhnjajyoaWwzEy884b8kNXxwpqbfWRA Date: Wed, 29 Jan 2014 09:36:24 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] FW: working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 09:36:37 -0000 I've reviewed the document and only found minor grammatical issues. Thus, I= believe that the document is ready for publication. Due to Chinese New Year break, please expect my grammatical suggestions/com= ments come after the WG LC (after I transcript my notes from the hard-copy = version to an electronic one). Regards, Xian -------- Original Message -------- From: Loa Andersson To: mpls@ietf.org CC: mpls-chairs@tools.ietf.org ,=20 ,=20 draft-ietf-mpls-tp-psc-itu@tools.ietf.org=20 , VIGOUREUX, MARTIN (MARTIN)=20 Working Group, This is to start a two week working group last call on draft-ietf-mpls-tp-psc-itu. Please find the document at: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ The document editors has also supplied a "diff-list" between version -00 and -01 at: http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html ITU-T SG15 has advised us that this document is a necessary reference for documents that is planned to go into the ITU-T approval process from the SG15 meeting end of March / beginning of April. Editors, authors and chairs has put in quite an effort to make this document ready. The schedule is very tight. We are now doing several review steps in parallel - the normal working group last call, please send your comments to the mpls working group mailing list (mpls@ietf.org) - the working group chairs reviewed this document as part of the mpls-rt review, normally we do a wg chair review before starting the wglc, this review will now take place in parallel - after the wglc and publication request there is an AD evaluation, this will now also take place in parallel with the wglc The editors and authors are advised to try to resolve as many of the comments as possible (on the mailing list) as they come in, but not to post the new version of the draft until the wglc is closed and the comments are resolved. This working group last call ends February 3rd. /Loa for the MPLS WG co-chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Wed Jan 29 02:12:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0751A02B7 for ; Wed, 29 Jan 2014 02:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 uTQvas1LvKTR for ; Wed, 29 Jan 2014 02:12:31 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5224F1A019D for ; Wed, 29 Jan 2014 02:12:31 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0TACOmu002519; Wed, 29 Jan 2014 10:12:24 GMT Received: from 950129200 (110.26.90.92.rev.sfr.net [92.90.26.110]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0TACLLV002491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jan 2014 10:12:23 GMT From: "Adrian Farrel" To: "'Loa Andersson'" References: <52E8AEA7.4050402@pi.nu> In-Reply-To: <52E8AEA7.4050402@pi.nu> Date: Wed, 29 Jan 2014 10:12:21 -0000 Message-ID: <062101cf1cda$9a66a460$cf33ed20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEIcVB8EZsegoh/QvbocsA2kzYffZwo0gzw Content-Language: en-gb X-TM-AS-MML: No Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org Subject: Re: [mpls] please proceed the publication process for draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 10:12:33 -0000 Received and processing. Thanks, Adrian > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 29 January 2014 07:33 > To: Adrian Farrel > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); > draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org > Subject: please proceed the publication process for draft-ietf-mpls-ldp- > applicability-label-adv > > Adrian, > > The short working group last call on draft-ietf-mpls-ldp-applicability- > label-adv has been closed. > > We have support to progress the document with the changes that were > made during the AD evaluation. The document shepherd write-up has been > updated to reflect this. > > Please re-start the publication process. > > /Loa > document shepherd > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From wyaacov@gmail.com Wed Jan 29 04:47:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC4B1A044F for ; Wed, 29 Jan 2014 04:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oalpZKZ-ZwQx for ; Wed, 29 Jan 2014 04:47:07 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id D1A151A0375 for ; Wed, 29 Jan 2014 04:47:06 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id z12so3348001wgg.6 for ; Wed, 29 Jan 2014 04:47: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=9SeY/qkZoI35GdTHycYFpbU/ZjbgoDDMjNj+kRVxHP4=; b=Pw4SqWEVuNKPvxMMnD9qQIm1s3D2bMXqltQMXqToFMaI8NKklbaaewLRwNpGvgFEPu TMqd35+FIfl+oWhunU8/tYlW7MPg8aBStjI5LFYc3Qvb7DyuHgJUz0fXF9nFb4di5LE+ LecjgqjBYEgJjUckG6RXsH7SZqgdAQgUFwbSwvDqEv16+xWcIftE+KHb5Obn2B92tKj0 9+kp4KspQSgQIFrgFQBvQ9joch7sMIMrkKVn7SJueDv6J1WrNLsxzlmxeD1betQk1yFy hrauc5Cxq2aj6p3zDXa1ML8QnkMxvXNzPGICdQ+R4sp5liplyMOL0rkdAAVyGLQXK3Lj vy/g== MIME-Version: 1.0 X-Received: by 10.194.192.233 with SMTP id hj9mr21660wjc.78.1390999623509; Wed, 29 Jan 2014 04:47:03 -0800 (PST) Received: by 10.194.118.229 with HTTP; Wed, 29 Jan 2014 04:47:03 -0800 (PST) In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3DCC@SMTP2.etri.info> References: <52DC89C3.3030003@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3DCC@SMTP2.etri.info> Date: Wed, 29 Jan 2014 14:47:03 +0200 Message-ID: From: Yaacov Weingarten To: "Ryoo, Jeong-dong" Content-Type: multipart/alternative; boundary=047d7bb70b2e712aed04f11b5649 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 12:47:11 -0000 --047d7bb70b2e712aed04f11b5649 Content-Type: text/plain; charset=ISO-8859-1 Jeong-dong, hi Thank you for your detailed reply to my comments - some counter comments appear below prefixed by "yw>>". In addition, I would like to add the following comment - regarding the notes on the State tables and especially note #1. In this note you state"Re-evaluate to determine final state as if the LER is in the Normal state." This needs more clarification, IMO, since this could be read as stating that if there is no currently active trigger then remain in the current state! Therefore I think that you should explicitly state "Re-evaluate to determine final state as if the LER is in the Normal state. If there are no active triggers, the LER enters Normal State." (On the assumption that this is the intention!) Similar corrections should be considered for notes 2,3,5. Thanx, yaacov On Tue, Jan 28, 2014 at 11:41 AM, Ryoo, Jeong-dong wrote: > Yaacov, > > Again, thanks for the comments. > > I really appreciate your help on this document. > > The followings are my responses to your comments: > > ======== > > #1. Yes, you described the correct behavior of MS-W. As you indicated, MS > and EXER are supposed to be ignored while MS-W is in effect. > yw>> I think that if this is the case that it be explicitly stated in the text. > #2. This document does not modify the operation of the selector described > in RFC6378. According to RFC6378, the selector selects the traffic from > only one of the paths no matter if the protection architecture is 1:1 or > 1+1. If you think it is appropriate to make this clear, then we can add > something like: > > "This document does not modify the operation of the selector at the sink > LER described in RFC 6378. The selector at the sink LER chooses either the > working or protection path from which to receive the normal traffic in both > 1:1 and 1+1 architectures. The position of the selector, i.e., which path > to receive the traffic, is determined by the PSC protocol in bidirectional > switching or by the local input in unidirectional switching." > > As a matter of fact, according to RFC 4427 (and all the ITU-T protection > documents), a selector refers to the entity at the sink node only. For the > source node, a bridge is used to choose which path (one of two paths in > 1:1, or both paths in 1+1) to transmit the traffic. Therefore, "the > selector in the sink LER" is redundant and should have been replaced with > just "the selector". But, the descriptions of the selector and bridge in > RFC 6378 are somewhat different. In RFC 6378, the selector is used for both > transmitting and receiving the traffic, while the bridge is used for > transmitting only. The descriptions in RFC 6378 are not quite aligned with > RFC 4427 (and other ITU-T docs). > #3. Again, this is due to the different understanding on the selector. If > you stick to the terminology defined in RFC 4427 and ITU-T, then you may > not have the issue with current sentences. In the meantime, as I did in #2, > I can add "in the sink LER" after every "the selector". In other words, "the > path from which the selector does not select the user data traffic" can > be replaced with ""the path from which the selector at the sink LER does > not select the user data traffic" > yw>> I did not have a problem with the "selector" terminology my problem was with the description of the SD protection behavior in section 7.3. You state there that the protection is provided by "a selector bridge duplicating user data traffic" then later "the LER SHALL duplicate user data traffic and SHALL feed to both..." However, there is no description of what the selector at the receiving end is doing. Therefore, my conclusion is that the receiving end selects incoming data traffic form either the working or protection path on a per-packet basis, i.e. packet#1-5 may be selected from the working path, while packet#6-7 may be selected from the protection path, and packet#8-10 from working, and so on. Is this correct? And if it is not correct could you please provide text that precludes this behavior. The next step to my question is then - if this description is correct then there is no "standby" path since the selector (at the sink LER) may switch intermittently (based on the quality of the transmission at that point in time) between the two paths. So can you please clarify the definition? #4. The action on which path the LER should send the traffic is the same, > but the sink node should determine from which path the traffic should be > received. In order to determine the position of the selector *at the sink > node*, we need to resolve the conflict. > yw>> The problem with this is that it is only the receiving LER that can determine and generate the SD since the judgement of a degrade in the recption not in the transmission, isn't this true? And again this is related to the incomplete description of the behavior of the sink LER in the protection from SD behavior. > #5. I totally agree with you. Please see my earlier email on version > number. > > #6. Your impression on the linear protection is the same as mine. This > section needs to be rewritten. In my opinion, we should not use the term, > the life of PSC session. As I mentioned in my email responding to the AD > Review comments, Section 9 should be rewritten (or removed if we can change > the version number). In my opinion, your suggestion in #5 is also better > than as is now. > > #7. I totally agree with you on changing the version number. > > #8. We followed the same grouping as in RFC 6378. In Section 4.3.3.2 of > RFC 6378, the second paragraph says: > > The protection domain will exit the Unavailable state and revert to > > the Normal state when either the operator clears the Lockout command > > or the protection path recovers from the signal fail or degraded > > situation. > > Based upon this, we put SD-P in Unavailable state. As you know, the name > of the state does not affect the action taken by the PSC process. What > affects the action is the extended state, which shows the request and the > source of the request. If you want to suggest any other appropriate state, > I am ready to hear. > > =========== > > Best regards, > > > > Jeong-dong > > > > ------------------------------ > *From : *"Yaacov Weingarten" > *Sent : *2014-01-28 05:12:16 ( +09:00 ) > *To : *Loa Andersson > *Cc : *mpls@ietf.org , mpls-chairs@tools.ietf.org < > mpls-chairs@tools.ietf.org>, draft-ietf-mpls-tp-psc-itu@tools.ietf.org < > draft-ietf-mpls-tp-psc-itu@tools.ietf.org>, > *Subject : *Re: [mpls] working group last call > draft-ietf-mpls-tp-psc-itu-01 > > Hi all, > > I have read through the latest version of this draft and have a number > of comments and questions regarding this document. While, in general, I > feel that the extensions to the behavior of RFC6378 are appropriate, I find > that this document is still in need of refinement in its language and > clarity of the functionality. While some of the additional functionality is > described, there are different cases of the functionality that is either > not described or is rather confusing. > > One basic question is - Considering that this draft is proposing changes > to the basic operation of the PSC protocol, Local Request Logic, and the > PSC Control Logic, I would have thought that the PSC Version number should > change! Why then, is there no mention of changing the version to allow > networks that support the functionality described in RFC6378 to continue to > operate? > > Regarding the functionality proposed in the draft, I have the following > questions and comments - > > 1. (for clarification) Regarding the functionality of MS-W, what is > the functionality if the data-traffic is currently on the working path? > Since the purpose of the command is to move the traffic to the working > path, shouldn't it be ignored? However, according to the State Transition > Table in section 11.1 - if the MS-W is received by a LER in Normal State it > transfers to Switching Administrative State! The main effect seems to be to > cause the LER to ignore incoming MS and EXER requests (that are not ignored > in Normal State). > 2. Regarding the SD functionality - after a previous discussion on the > mailing list the functionality when protecting for SD situations (described > in Section 7.3) was changed to essentially switch over to the LER > transmitting the packets on both the working and protection paths > (essentially 1+1 transmission). However, there is very little discussion of > how the receiving LER is supposed to select the incoming packets while > avoiding duplication of data. Could please elaborate on this? > 3. Regarding the SD functionality - as mentioned in the previous > point, when protecting for SD, the transmitting LER duplicates the packets > on both W & P and the receiving LER, presumably, reads the data from either > path, and may choose differently for different packets. However, later in > section 7.4 (and again in section 10.2) you introduce a new concept of > "standby path" as "the path from which the selector does not select the > user data traffic" in regard to determining the priority of "conflicting" > SD-W and SD-P triggers. Can you clarify which of the two paths that are > both carrying user data is the standby path? > 4. Further regarding the point of "conflicting" SD triggers - since > the protection functionality of SD is to duplicate the data on both W & P - > why is this considered a conflict, since the action for both will be > identical - continue transmitting on both W & P. Some more clarification > would help. > 5. Regarding the APS mode and sub-capabilities - You describe in > section 9.1 how an LER can declare itself to support only some of the > capabilities introduced in the draft, and then describe the APS "mode" > (Section 9.2.2) as declaration of support for all of the capabilities, i.e. > Flags = 0xF8000000. From this point on (in particular section 11), you > describe the functionality for LER that declare Flags= either 0x0, or > 0xF8000000, however, there is no explanation for paths that declare some > other value of Flags (for example, 0x8000000 - supporting only the EXER > functionality). Is there a reason for this? Are we assuming that all paths > will either support PSC or APS modes only? If so, why not just have two > values for Flags rather than this extensible bit map value? > 6. Regarding "PSC sessions" - In section 9.3 you introduce a new > concept of PSC session, without any definition of when this session begins > or ends. Could you elaborate on what is meant by the "life of a PSC > session"? Until now, I was under the impression that linear protection > started with the creation of the protection domain and continued until the > paths were torn down. Is this incorrect? > 7. There is a statement in the second paragraph of section 9.3 that > states "RFC6378 does not define how to handle an unrecognized TLV." > Actually, what RFC6378 defines is "there are no TLV units defined for the > basic PSC operation" and therefore the TLVs are ignored. Another reason, > IMO, to change the version number of the protocol in this draft. > 8. It is unclear to me - why when receiving a SD-P indication in > Normal why you consider this to be "Unavaiable" since the action taken for > an SD situation is to possibly transmit on both W & P. > > > I plan on submitting some editorial comments in a future post, but would > like to get some clarification on these points before the draft advances to > acceptance. > > Thanx, > yaacov > > > On Mon, Jan 20, 2014 at 4:28 AM, Loa Andersson wrote: > >> Working Group, >> >> This is to start a two week working group last call on >> draft-ietf-mpls-tp-psc-itu. >> >> Please find the document at: >> https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ >> >> The document editors has also supplied a "diff-list" between >> version -00 and -01 at: >> http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html >> >> ITU-T SG15 has advised us that this document is a necessary reference >> for documents that is planned to go into the ITU-T approval process >> from the SG15 meeting end of March / beginning of April. Editors, >> authors and chairs has put in quite an effort to make this document >> ready. The schedule is very tight. >> >> We are now doing several review steps in parallel >> >> - the normal working group last call, please send your comments to the >> mpls working group mailing list (mpls@ietf.org) >> - the working group chairs reviewed this document as part of the >> mpls-rt review, normally we do a wg chair review before starting the >> wglc, this review will now take place in parallel >> - after the wglc and publication request there is an AD evaluation, >> this will now also take place in parallel with the wglc >> >> The editors and authors are advised to try to resolve as many of the >> comments as possible (on the mailing list) as they come in, but not to >> post the new version of the draft until the wglc is closed and the >> comments are resolved. >> >> This working group last call ends February 3rd. >> >> /Loa >> for the MPLS WG co-chairs >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > > > -- > Thanx and BR, > yaacov > > *Still looking for new opportunity* > -- Thanx and BR, yaacov *Still looking for new opportunity* --047d7bb70b2e712aed04f11b5649 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeong-dong, hi

Thank you for your detai= led reply to my comments - some counter comments appear below prefixed by &= quot;yw>>".

In addition, I would like t= o add the following comment - regarding the notes on the State tables and e= specially note #1. In this note you state"Re-evaluate to determine fin= al state as if the LER is in the Normal state." This needs more clarif= ication, IMO, since this could be read as stating that if there is no curre= ntly active trigger then remain in the current state!=C2=A0
Therefore I think that you should explicitly state "Re-evaluate t= o determine final state as if the LER is in the Normal state. If there are = no active triggers, the LER enters Normal State." (On the assumption t= hat this is the intention!) Similar corrections should be considered for no= tes 2,3,5.

Thanx,
yaacov


On Tue, Jan 28, 2014 at 11:41 AM, = Ryoo, Jeong-dong <ryoo@etri.re.kr> wrote:

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">Yaacov,

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">Again, thanks for the c= omments.

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">I really appreciate you= r help on this document.

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">The followings are my r= esponses to your comments:

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">=3D=3D=3D=3D=3D=3D=3D= =3D

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">#1. Yes, you described = the correct behavior of MS-W. As you indicated, MS and EXER are supposed to= be ignored while MS-W is in effect.

yw>> I think that if = this is the case that it be explicitly stated in the text.
=C2=A0=

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">#2. This document does = not modify the operation of the selector described in RFC6378. According to= RFC6378, the selector selects the traffic from only one of the paths no matter if the protection architecture is 1:1 or 1+1. If you think it is ap= propriate to make this clear, then we can add something like:

=E2=80=9CThis document does not = modify the operation of the selector at the sink LER described in RFC 6378.= The selector at the sink LER chooses either the working or protection path from which to receive the normal traffic in both 1:1 an= d 1+1 architectures. The position of the selector, i.e., which path to rece= ive the traffic, is determined by the PSC protocol in bidirectional switchi= ng or by the local input in unidirectional switching.=E2=80=9D

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">As a matter of fact, ac= cording to RFC 4427 (and all the ITU-T protection documents), a selector re= fers to the entity at the sink node only. For the source node, a bridge is used to choose which path (one of two paths in 1:1, or both paths in 1+= 1) to transmit the traffic. Therefore, =E2=80=9Cthe selector in the sink LE= R=E2=80=9D is redundant and should have been replaced with just =E2=80=9Cth= e selector=E2=80=9D. But, the descriptions of the selector and bridge in RFC 6378 are somewhat different. In RFC 6378, the selector is used for = both transmitting and receiving the traffic, while the bridge is used for t= ransmitting only. The descriptions in RFC 6378 are not quite aligned with R= FC 4427 (and other ITU-T docs).

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">#3. Again, this is due = to the different understanding on the selector. If you stick to the termino= logy defined in RFC 4427 and ITU-T, then you may not have the issue with current sentences. In the meantime, as I did in #2, I can add =E2=80=9Cin = the sink LER=E2=80=9D after every =E2=80=9Cthe selector=E2=80=9D. In other = words, "the path from which the selector does not select the user = data traffic" can be replaced with =E2=80=9C"the path from = which the selector at the sink LER does not select the user data traffic"

yw>> I did not have a= problem with the "selector" terminology my problem was with the = description of the SD protection behavior in section 7.3. You state there t= hat the protection is provided by "a selector bridge duplicating user = data traffic" =C2=A0then later "the LER SHALL duplicate user data= traffic and SHALL feed to both..." However, there is no description o= f what the selector at the receiving end is doing.
Therefore, my conclusion is that the receiving end selects incoming da= ta traffic form either the working or protection path on a per-packet basis= , i.e. packet#1-5 may be selected from the working path, while packet#6-7 m= ay be selected from the protection path, and packet#8-10 from working, and = so on. Is this correct? And if it is not correct could you please provide t= ext that precludes this behavior.
The next step to my question is then - if this description is correct = then there is no "standby" path since the selector (at the sink L= ER) may switch intermittently (based on the quality of the transmission at = that point in time) between the two paths. So can you please clarify the de= finition?

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">#4. The action on which= path the LER should send the traffic is the same, but the sink node should= determine from which path the traffic should be received. In order to determine the position of the selector *at the sink node*, we need to reso= lve the conflict.

yw>> The problem with this is that it is only the receiving L= ER that can determine and generate the SD since the judgement of a degrade = in the recption not in the transmission, isn't this true? And again thi= s is related to the incomplete description of the behavior of the sink LER = in the protection from SD behavior.=C2=A0

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">#5. I totally agree wit= h you. Please see my earlier email on version number.

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">#6. Your impression on = the linear protection is the same as mine. This section needs to be rewritt= en. In my opinion, we should not use the term, the life of PSC session. As I mentioned in my email responding to the AD Review comments, Section 9= should be rewritten (or removed if we can change the version number). In m= y opinion, your suggestion in #5 is also better than as is now.

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">#7. I totally agree wit= h you on changing the version number.

#= 8. We followed the same grouping as in RFC 6378. In Section 4.3.3.2 of RFC = 6378, the second paragraph says:

The protection domain wi= ll exit the Unavailable state and revert to

the Normal state when ei= ther the operator clears the Lockout command

or the protection path r= ecovers from the signal fail or degraded

situation.

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">Based upon this, we put= SD-P in Unavailable state. As you know, the name of the state does not aff= ect the action taken by the PSC process. What affects the action is the extended state, which shows the request and the source of the request. If = you want to suggest any other appropriate state, I am ready to hear.

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">Best regards,

=C2=A0

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">Jeong-dong




From : "Yaacov Weingarten" <wyaacov@gmail.com>
Sent : 2014-01-28 05:12:16 ( +09:00 )
To : Loa Andersson <loa@pi.nu>
Cc : mpls@ietf.or= g <mpls@ietf.org<= /a>>, mp= ls-chairs@tools.ietf.org <mpls-chairs@tools.ietf.org>, draft-ietf-mp= ls-tp-psc-itu@tools.ietf.org <draft-ietf-mpls-tp-psc-itu@tools.i= etf.org>, <mpl= s-ads@tools.ietf.org>
Subject : Re: [mpls] working group last call draft-ietf-mpls-tp-psc-= itu-01

Hi all,

I have read through the latest version of this draft and have a number= of comments and questions regarding this document. While, in general, I fe= el that the extensions to the behavior of RFC6378 are appropriate, I find t= hat this document is still in need of refinement in its language and clarity of the functionality. While some= of the additional functionality is described, there are different cases of= the functionality that is either not described or is rather confusing.

One basic question is - Considering that this draft is proposing chang= es to the basic operation of the PSC protocol, Local Request Logic, and the= PSC Control Logic, I would have thought that the PSC Version number should= change! Why then, is there no mention of changing the version to allow networks that support the functionality d= escribed in RFC6378 to continue to operate?

Regarding the functionality proposed in the draft, I have the followin= g questions and comments -
  1. (for clarification) Regarding the functionality of MS-W, what is the fu= nctionality if the data-traffic is currently on the working path? Since the= purpose of the command is to move the traffic to the working path, shouldn= 't it be ignored? However, according to the State Transition Table in section 11.1 - if the MS-W is received by= a LER in Normal State it transfers to Switching Administrative State! The = main effect seems to be to cause the LER to ignore incoming MS and EXER req= uests (that are not ignored in Normal State).
  2. Regarding the SD functionality - after a previous discuss= ion on the mailing list the functionality when protecting for SD situations= (described in Section 7.3) was changed to essentially switch over to the L= ER transmitting the packets on both the working and protection paths (essentially 1+1 transmission). However, there is ver= y little discussion of how the receiving LER is supposed to select the inco= ming packets while avoiding duplication of data. Could please elaborate on = this?
  3. Regarding the SD functionality - as mentioned in the previous poin= t, when protecting for SD, the transmitting LER duplicates the packets on b= oth W & P and the receiving LER, presumably, reads the data from either= path, and may choose differently for different packets. However, later in section 7.4 (and again in section 10.2) you int= roduce a new concept of "standby path" as "the path from whi= ch the selector does not select the user data traffic" in regard to de= termining the priority of "conflicting" SD-W and SD-P triggers. Can you clarify which of the two paths that are both carrying us= er data is the standby path?
  4. Further regarding the point of "conflicting" SD triggers= - since the protection functionality of SD is to duplicate the data on bot= h W & P - why is this considered a conflict, since the action for both = will be identical - continue transmitting on both W & P. Some more clarification would help.
  5. Regarding the APS mo= de and sub-capabilities - You describe in section 9.1 how an LER can declar= e itself to support only some of the capabilities introduced in the draft, = and then describe the APS "mode" (Section 9.2.2) as declaration o= f support for all of the capabilities, i.e. Flags =3D 0xF8000000. From this point on (in par= ticular section 11), you describe the functionality for LER that declare Fl= ags=3D either 0x0, or 0xF8000000, however, there is no explanation for path= s that declare some other value of Flags (for example, 0x8000000 - supporting only the EXER functionality). Is ther= e a reason for this? Are we assuming that all paths will either support PSC= or APS modes only? If so, why not just have two values for Flags rather th= an this extensible bit map value?
  6. Regarding "PSC sessions" - In section 9.3 you introduce = a new concept of PSC session, without any definition of when this session b= egins or ends. Could you elaborate on what is meant by the "life of a = PSC session"? Until now, I was under the impression that linear protection started with the creation of the protection domain = and continued until the paths were torn down. Is this incorrect?
  7. There is a statement in the second paragraph of section 9.3 that s= tates "RFC6378 does not define how to handle an unrecognized TLV."= ; Actually, what RFC6378 defines is "there are no TLV units defined fo= r the basic PSC operation" and therefore the TLVs are ignored. Another reason, IMO, to change the version number of the protocol= in this draft.
  8. It is unclear to me - why when receiving a SD-P indication in Norm= al why you consider this to be "Unavaiable" since the action take= n for an SD situation is to possibly transmit on both W & P.

I plan on submitting some editorial comments in a future post, but wou= ld like to get some clarification on these points before the draft advances= to acceptance.

Thanx,
yaacov


On Mon, Jan 20, 2014 at 4:28 AM, Loa Andersson <= span dir=3D"ltr"> <loa@pi.nu>= wrote:
Working Group,

This is to start a two week working group last call on
draft-ietf-mpls-tp-psc-itu.

Please find the document at:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-= psc-itu/

The document editors has also supplied a "diff-list" between
version -00 and -01 at:
http://www.ietf.org/mail-archive/web/mpls/current= /msg11338.html

ITU-T SG15 has advised us that this document is a necessary reference
for documents that is planned to go into the ITU-T approval process
from the SG15 meeting end of March / beginning of April. Editors,
authors and chairs has put in quite an effort to make this document
ready. The schedule is very tight.

We are now doing several review steps in parallel

- the normal working group last call, please send your comments to the
=C2=A0 mpls working group mailing list (mpls@ietf.org)
- the working group chairs reviewed this document as part of the
=C2=A0 mpls-rt review, normally we do a wg chair review before starting the=
=C2=A0 wglc, this review will now take place in parallel
- after the wglc and publication request there is an AD evaluation,
=C2=A0 this will now also take place in parallel with the wglc

The editors and authors are advised to try to resolve as many of the
comments as possible (on the mailing list) as they come in, but not to
post the new version of the draft until the wglc is closed and the
comments are resolved.

This working group last call ends February 3rd.

/Loa
for the MPLS WG co-chairs
--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =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=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
Thanx and BR,
yaacov

Still looking for new opportunity



--
Thanx and BR,
yaacov

Still looking for= new opportunity
--047d7bb70b2e712aed04f11b5649-- From alessandro.dalessandro@telecomitalia.it Wed Jan 29 09:50:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6E71A0372 for ; Wed, 29 Jan 2014 09:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.979 X-Spam-Level: X-Spam-Status: No, score=0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 c5so9U0Pjyzg for ; Wed, 29 Jan 2014 09:50:40 -0800 (PST) Received: from TELEDG001RM001.telecomitalia.it (unknown [217.169.121.18]) by ietfa.amsl.com (Postfix) with ESMTP id E1ECD1A0370 for ; Wed, 29 Jan 2014 09:50:34 -0800 (PST) Content-Type: multipart/mixed; boundary="_71427b7a-f186-45aa-ba79-07e8a33d37c5_" Received: from TELCAH003RM001.telecomitalia.local (10.19.10.106) by TELEDG001RM001.telecomitalia.it (10.19.3.111) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 29 Jan 2014 18:50:28 +0100 Received: from TELMBA002RM001.telecomitalia.local ([169.254.1.178]) by TELCAH003RM001.telecomitalia.local ([10.19.10.106]) with mapi id 14.03.0174.001; Wed, 29 Jan 2014 18:50:29 +0100 From: D'Alessandro Alessandro Gerardo To: "mpls@ietf.org" Thread-Topic: IPR poll draft-ietf-mpls-tp-psc-itu Thread-Index: Ac8dGpfmZGR3p2yXg0mklLc6u1JP+Q== Date: Wed, 29 Jan 2014 17:50:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: [mpls] R: IPR poll draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 17:50:43 -0000 --_71427b7a-f186-45aa-ba79-07e8a33d37c5_ Content-Type: multipart/alternative; boundary="_000_h8afvo3sbt6f2kumuef6lqh91391017848050emailandroidcom_" --_000_h8afvo3sbt6f2kumuef6lqh91391017848050emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ZGVhciBhbGwsDQpJJ20gbm90IGF3YXJlIG9mIGFueSByZWxldmFudCBpcHIgcmVsYXRlZCB0byB0 aGUgZHJhZnQgaW4gdGhlIG9iamVjdC4NCnRoYXQgaGFzIGJlZW4gZGlzY2xvc2VkIGFjY29yZGlu Z2x5IHRvIElFVEYgaXByIHJ1bGVzLg0KQmVzdCByZWdhcmRzDQpBbGVzc2FuZHJvDQoNCg0KDQot LS0tLS0tLSBNZXNzYWdnaW8gb3JpZ2luYWxlIC0tLS0tLS0tDQpPZ2dldHRvOklQUiBwb2xsIGRy YWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQpEYTpMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+DQpB OiJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4NCkNjOiJtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZyIgPG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPiwiVklHT1VSRVVYLCBNQVJUSU4g KE1BUlRJTikiIDxtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbT4sImRyYWZ0LWll dGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXBz Yy1pdHVAdG9vbHMuaWV0Zi5vcmc+DQoNCg0KV29ya2luZyBHcm91cCwNCg0KZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHUgaXMgaW4gd29ya2luZyBncm91cCBsYXN0IGNhbGwsIHdlIGhhdmUganVz dA0KcmVjZWl2ZWQgYW4gSVBSIGRpc2Nsb3N1cmU6DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMTE0NjkuaHRtbA0KDQpUaGlzIGdpdmVzIHVz IHJlYXNvbiB0byBzdGFydCBhbiBJUFIgcG9sbCBvbiB0aGUgZG9jdW1lbnQuDQoNCg0KVGhpcyBt YWlsIHN0YXJ0cyB0aGF0IElQUiBwb2xsLg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhh dCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1Pw0KDQpJZiBzbywgaGFzIHRo aXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0K KHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoN CkN1cnJlbnRseSB0aGVyZSBpcyB0aGUgb25lIElQUiBkaXNjbG9zdXJlLCBtZW50aW9uZWQgYWJv dmUsIHRoYXQNCnJlbGF0ZXMgdG8gdGhpcyBkb2N1bWVudC4NCg0KSWYgeW91IGFyZSBsaXN0ZWQg YXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8NCnRo aXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFu eSByZWxldmFudA0KSVBSLiAqVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIE1Q TFMgd2cgbWFpbGluZyBsaXN0LiogVGhlDQpkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRo ZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4NCnJlY2VpdmVkIGZyb20gZWFj aCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVt YWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvcg0KY29udHJpYnV0b3Is IHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2Yg YW55DQpJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3 aXRoIElFVEYgcnVsZXMuDQoNClRoYW5rcywgTG9hDQooYXMgTVBMUyBXRyBjby1jaGFpcikNCi0t DQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFp bDAxLmh1YXdlaS5jb20NClNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAg ICAgbG9hQHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6 ICs0NiA3MzkgODEgMjEgNjQNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29u byBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRp ZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEg Y29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0 YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3Jl IHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXpp b25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jh emllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBh bmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFk ZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2Ug YnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpb cmlzcGV0dGEgbCdhbWJpZW50ZV1SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVl c3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQoNCg== --_000_h8afvo3sbt6f2kumuef6lqh91391017848050emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KZGVhciBhbGwsDQo8 ZGl2PkknbSBub3QgYXdhcmUgb2YgYW55IHJlbGV2YW50IGlwciByZWxhdGVkIHRvIHRoZSBkcmFm dCBpbiB0aGUgb2JqZWN0LjwvZGl2Pg0KPGRpdj50aGF0IGhhcyBiZWVuIGRpc2Nsb3NlZCBhY2Nv cmRpbmdseSB0byBJRVRGIGlwciBydWxlcy48L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzPC9kaXY+ DQo8ZGl2PkFsZXNzYW5kcm88L2Rpdj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tIE1lc3Nh Z2dpbyBvcmlnaW5hbGUgLS0tLS0tLS08YnI+DQpPZ2dldHRvOklQUiBwb2xsIGRyYWZ0LWlldGYt bXBscy10cC1wc2MtaXR1PGJyPg0KRGE6TG9hIEFuZGVyc3NvbiAmbHQ7bG9hQHBpLm51Jmd0Ozxi cj4NCkE6JnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+ DQpDYzomcXVvdDttcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyZxdW90OyAmbHQ7bXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7LCZxdW90O1ZJR09VUkVVWCwgTUFSVElOIChNQVJUSU4pJnF1 b3Q7ICZsdDttYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbSZndDssJnF1b3Q7ZHJh ZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWll dGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnJmd0Ozxicj4NCjxicj4NCjxicj4NCjxm b250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPg0KPGRpdiBjbGFzcz0i UGxhaW5UZXh0Ij5Xb3JraW5nIEdyb3VwLDxicj4NCjxicj4NCmRyYWZ0LWlldGYtbXBscy10cC1w c2MtaXR1IGlzIGluIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLCB3ZSBoYXZlIGp1c3Q8YnI+DQpy ZWNlaXZlZCBhbiBJUFIgZGlzY2xvc3VyZTo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzExNDY5Lmh0bWwiIHRh cmdldD0iX0JMQU5LIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9j dXJyZW50L21zZzExNDY5Lmh0bWw8L2E+PGJyPg0KPGJyPg0KVGhpcyBnaXZlcyB1cyByZWFzb24g dG8gc3RhcnQgYW4gSVBSIHBvbGwgb24gdGhlIGRvY3VtZW50Ljxicj4NCjxicj4NCjxicj4NClRo aXMgbWFpbCBzdGFydHMgdGhhdCBJUFIgcG9sbC48YnI+DQo8YnI+DQpBcmUgeW91IGF3YXJlIG9m IGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1Pzxicj4N Cjxicj4NCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3 aXRoIElFVEYgSVBSIHJ1bGVzPGJyPg0KKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUz NzggZm9yIG1vcmUgZGV0YWlscykuPGJyPg0KPGJyPg0KQ3VycmVudGx5IHRoZXJlIGlzIHRoZSBv bmUgSVBSIGRpc2Nsb3N1cmUsIG1lbnRpb25lZCBhYm92ZSwgdGhhdDxicj4NCnJlbGF0ZXMgdG8g dGhpcyBkb2N1bWVudC48YnI+DQo8YnI+DQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50 IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0bzxicj4NCnRoaXMgZW1haWwg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFu dDxicj4NCklQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIHdn IG1haWxpbmcgbGlzdC4qIFRoZSA8YnI+DQpkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRo ZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW48YnI+DQpyZWNlaXZlZCBmcm9t IGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci48YnI+DQo8YnI+DQpJZiB5b3UgYXJlIG9uIHRo ZSBNUExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvcjxi cj4NCmNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5 b3UgYXJlIGF3YXJlIG9mIGFueTxicj4NCklQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xv c2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy48YnI+DQo8YnI+DQpUaGFua3MsIExv YTxicj4NCihhcyBNUExTIFdHIGNvLWNoYWlyKTxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxv YSBBbmRlcnNzb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW1haWw6IGxvYUBtYWlsMDEuaHVh d2VpLmNvbTxicj4NClNlbmlvciBNUExTIEV4cGVydCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBsb2FAcGkubnU8YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50 KSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwaG9uZTogJiM0Mzs0NiA3MzkgODEgMjEgNjQ8YnI+ DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCnNw YW4uR3JhbUUge21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1ncmFtLWU6eWVzO30NCi0tPg0KPC9z dHlsZT4NCjx0YWJsZSBzdHlsZT0id2lkdGg6NjAwcHg7Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBz dHlsZT0id2lkdGg6NTg1cHg7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBBcmlhbDsgZm9udC1zaXpl OjEycHg7IGNvbG9yOiMwMDA7IHRleHQtYWxpZ246IGp1c3RpZnkiIHdpZHRoPSIzOTUiPg0KPGRp diBhbGlnbj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxp Z246anVzdGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmEiPlF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdh dGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUu IExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpDQogYWx0cmEgYXppb25lIGRlcml2YW50 ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1l bnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBl ciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNv bXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXpp b25lLCBHcmF6aWUuDQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPHAgYWxpZ249Imp1c3RpZnkiPjxz cGFuIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVp Z2h0Om5vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6VmVyZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+VGhpcyBlLW1haWwg YW5kIGFueSBhdHRhY2htZW50czwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6DQogIDcuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6VmVyZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7PHNwYW4gY2xhc3M9Ikdy YW1FIj5pczwvc3Bhbj4mbmJzcDs8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOg0KICA3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1 YWdlOkVOLUdCIj5jb25maWRlbnRpYWwNCiBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9u LCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXINCiBi eSByZXR1cm4gZS1tYWlsLCBUaGFua3MuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4NCjwvc3Bhbj48L3NwYW4+PC9wPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDsNCiAgZm9udC1mYW1pbHk6VmVyZGFuYSI+PGltZyBz cmM9ImNpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyIiBh bHQ9InJpc3BldHRhIGwnYW1iaWVudGUiIHdpZHRoPSIyNiIgaGVpZ2h0PSI0MCI+UmlzcGV0dGEg bCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3Nhcmlv Ljwvc3Bhbj48L2I+DQo8cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_h8afvo3sbt6f2kumuef6lqh91391017848050emailandroidcom_-- --_71427b7a-f186-45aa-ba79-07e8a33d37c5_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_71427b7a-f186-45aa-ba79-07e8a33d37c5_-- From eric.osborne@notcom.com Wed Jan 29 12:03:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C36A1A0362 for ; Wed, 29 Jan 2014 12:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 tWJs5-qLYWXH for ; Wed, 29 Jan 2014 12:03:26 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id D80E71A0248 for ; Wed, 29 Jan 2014 12:03:25 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wo20so2527829obc.28 for ; Wed, 29 Jan 2014 12:03:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WZfeP8NpwRBsbECq0kfsNP5kCeGbVF6aMOg+y6TPN08=; b=OYMdQLbZrbJuay/LBPiLHgq27gkC8VUumwTkYQG0KSBLBHpBWD4m9pjLeP6uPWoHHM BQtHg3Vt6hCNOyiMRn/jwBOainxEtrjS1aGu+xbdzxWNUTIVi2ghrxIq1mYgowdTD5q4 lpWgZPVcfOClV14FJkpXlSVy00RAN9qmWCY84FMYsiAqHl6x3LM4XtECfEp0HuTGaDHy GzyC4ikHMpmPMkoogo2xdgqCVqmtXCUhyM68H96v2bcfZztUK1xUopzvavA8oq5Arj8l 5G7ovrT1iYV5rLb68qhj6pNzocQ2qt78219KTgYTCMv3UwWfV18dyqfHI9TgC9QUxP7c eCkQ== X-Gm-Message-State: ALoCoQnJiEnharD/bZxA33ibrzWMT6PCVLRBlbfuAiAa1UAkkAf8XBCMjqquVo59OUAL5quqUtxN MIME-Version: 1.0 X-Received: by 10.60.228.135 with SMTP id si7mr7881353oec.4.1391025802762; Wed, 29 Jan 2014 12:03:22 -0800 (PST) Received: by 10.182.135.229 with HTTP; Wed, 29 Jan 2014 12:03:22 -0800 (PST) In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B4003@SMTP2.etri.info> References: <52E64660.2090900@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286B4003@SMTP2.etri.info> Date: Wed, 29 Jan 2014 15:03:22 -0500 Message-ID: From: Eric Osborne To: "Ryoo, Jeong-dong" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] IPR poll draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 20:03:27 -0000 I too am not aware of any IPR that applies to this draft. eric On Tue, Jan 28, 2014 at 9:41 PM, Ryoo, Jeong-dong wrote: > Hi, > > No, I am not aware of any IPR that applies to this document. > > Jeong-dong > > > > ________________________________ > From : "Loa Andersson" > Sent : 2014-01-27 20:43:37 ( +09:00 ) > To : mpls@ietf.org > Cc : mpls-chairs@tools.ietf.org , VIGOUREUX, > MARTIN (MARTIN) , > draft-ietf-mpls-tp-psc-itu@tools.ietf.org > > Subject : IPR poll draft-ietf-mpls-tp-psc-itu > > Working Group, > > draft-ietf-mpls-tp-psc-itu is in working group last call, we have just > received an IPR disclosure: > > http://www.ietf.org/mail-archive/web/mpls/current/msg11469.html > > This gives us reason to start an IPR poll on the document. > > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-tp-psc-itu? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there is the one IPR disclosure, mentioned above, that > relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From iesg-secretary@ietf.org Wed Jan 29 12:56:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DC51A0425; Wed, 29 Jan 2014 12:56:58 -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 lAwBTqZiSuwp; Wed, 29 Jan 2014 12:56:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E0E1A027B; Wed, 29 Jan 2014 12:56:56 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140129205656.27956.60966.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2014 12:56:56 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (MPLS Forwarding Compliance and Performance Requirements) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 20:56:58 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS Forwarding Compliance and Performance Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-02-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-forwarding/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-forwarding/ballot/ No IPR declarations have been submitted directly on this I-D. From loa@pi.nu Wed Jan 29 21:04:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04811A048B for ; Wed, 29 Jan 2014 21:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 F51vuuXeaipg for ; Wed, 29 Jan 2014 21:04:42 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E464C1A0487 for ; Wed, 29 Jan 2014 21:04:41 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.101.14]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 0983418029FB; Thu, 30 Jan 2014 06:04:36 +0100 (CET) Message-ID: <52E9DD5F.9020604@pi.nu> Date: Thu, 30 Jan 2014 13:04:31 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: huubatwork@gmail.com, "mpls-chairs@tools.ietf.org" References: <20140125073602.3234.76134.idtracker@ietfa.amsl.com> <52E3A424.209@gmail.com> In-Reply-To: <52E3A424.209@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 05:04:44 -0000 Working Group, authors, The authors of draft-zulr-mpls-tp-linear-protection-switching (http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection- switching) are looking to publish their document as an Independent Stream RFC. The MPLS Working Group was informed about this on the MPLS working group mailing (see below). The MPLS Working Group decided to progress a Proposed Standard RFC for MPLS-TP Linear protection Switching (RFC 6378). This is still the Working Group consensus. Further there is work-in-progress to update RFC 6378 to match the functionality of APS. However it is a long standing tradition to publish documents that were not progressed as working group RFCs, particularly if they have been implemented and deployed. This for example is done for the historic record and due to the value of documenting deployed solutions. This is the case with draft-zulr-mpls-tp-linear-protection-switching. The document clearly states that IETF Standard Track MPLS-TP Linear Protection is specified in RFC 6378. It also states that the protocol specified in the draft is a non-IETF pre-standard protocol. The MPLS working group chairs are therefore not opposed to the publication of the document as an RFC on the Independent Stream. The Working Group chairs invite the working group to comment on this, please send comments to the working group mailing list (mpls@ietf.org). The MPLS Working Group Chairs Loa, Ross and George On 2014-01-25 19:46, Huub van Helvoort wrote: > Dear WG chairs, > > The authors of draft-zulr-mpls-tp-linear-protection-switching > have decided to publish the document on the independent stream > as an informational RFC. > > Because it documents the pre-standard implementation of MPLS-TP > linear protection that has been deployed by several network > operators using equipment from multiple vendors. > At the time of publication these pre-standard implementations > were still in operation carrying live traffic. > > Best regards, Huub van Helvoort. > > > -------- Original Message -------- > Subject: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt > Date: Fri, 24 Jan 2014 23:36:02 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Pre-standard Linear Protection Switching in > MPLS-TP > Authors : Huub van Helvoort > Jeong-dong Ryoo > Haiyan Zhang > Feng Huang > Han Li > Alessandro D'Alessandro > Filename : > draft-zulr-mpls-tp-linear-protection-switching-09.txt > Pages : 27 > Date : 2014-01-24 > > Abstract: > The IETF Standards Track solution for MPLS Transport Profile (MPLS- > TP) Linear Protection is provided in RFC 6378, draft-ietf-mpls-psc- > updates and draft-ietf- mpls-tp-psc-itu. > > This document describes the pre-standard implementation of MPLS-TP > Linear Protection that has been deployed by several network operators > using equipment from multiple vendors. At the time of publication > these pre-standard implementations were still in operation carrying > live traffic." > > The specified mechanism supports 1+1 unidirectional/bidirectional > protection switching and 1:1 bidirectional protection switching. It > is purely supported by MPLS-TP data plane, and can work without any > control plane. > > This document is a product of a joint Internet Engineering Task Force > (IETF) / International Telecommunications Union Telecommunications > Standardization Sector (ITU-T) effort to include an MPLS Transport > Profile within the IETF MPLS and PWE3 architectures to support the > capabilities and functionalities of a packet transport network as > defined by the ITU-T. > > [Editor's note] To be included in "Status of Memo": This document is > not an Internet Standards Track specification; it is published for > informational purposes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-zulr-mpls-tp-linear-protection-switching/ > > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection-switching-09 > > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-zulr-mpls-tp-linear-protection-switching-09 > > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From iesg-secretary@ietf.org Thu Jan 30 06:50:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E148F1A036B; Thu, 30 Jan 2014 06:50:24 -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 hRHzrpJgNJ-0; Thu, 30 Jan 2014 06:50:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3841A039C; Thu, 30 Jan 2014 06:50:21 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140130145021.29174.34567.idtracker@ietfa.amsl.com> Date: Thu, 30 Jan 2014 06:50:21 -0800 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Document Action: 'Use of Multipath with MPLS and MPLS-TP' to Informational RFC (draft-ietf-mpls-multipath-use-04.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 14:50:25 -0000 The IESG has approved the following document: - 'Use of Multipath with MPLS and MPLS-TP' (draft-ietf-mpls-multipath-use-04.txt) as Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-multipath-use/ Technical Summary Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy label, MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed. Working Group Summary Nothing in particular to note, no controversies and the working is solidly behind this document. Document Quality This is an Informational document that has been well reviewed in the working, but not external reviews have been necessary. As part of the working group reviews it has also been reviewed by the MPLS review team (MPLS-RT) prior to adoption as a working group document. No specific implementation review has been done on this document since we don't expect any direct vendor implementations of the document; instead the document discusses how the mechanisms that have been implemented can be use. We know of operators that has deployed the techniques discussed in the document. The MPLS-RT reviewers has been Mach Chen, Markus Jork, David Allan and Carlos Pignataro. Personnel Loa Andersson is the Document Shepherd Adrian Farrel is the Responsible Area Director From ietfc@btconnect.com Thu Jan 30 09:58:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD131A0417 for ; Thu, 30 Jan 2014 09:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 6bdYtL01yobO for ; Thu, 30 Jan 2014 09:58:55 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id DFF521A03E0 for ; Thu, 30 Jan 2014 09:58:54 -0800 (PST) Received: from mail240-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.22; Thu, 30 Jan 2014 17:58:51 +0000 Received: from mail240-tx2 (localhost [127.0.0.1]) by mail240-tx2-R.bigfish.com (Postfix) with ESMTP id 0415F80513; Thu, 30 Jan 2014 17:58:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -13 X-BigFish: PS-13(zz9371I542Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h304l1d11m1155h) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(13464003)(377454003)(74876001)(56816005)(89996001)(74366001)(90146001)(77982001)(47776003)(92566001)(69226001)(80976001)(93916002)(86362001)(19580405001)(14496001)(74706001)(50466002)(88136002)(85852003)(65816001)(4396001)(83072002)(59766001)(66066001)(50986001)(19580395003)(47976001)(79102001)(80022001)(83322001)(94316002)(42186004)(44716002)(62236002)(47736001)(63696002)(47446002)(93516002)(31966008)(49866001)(50226001)(33646001)(44736004)(62966002)(56776001)(54316002)(77096001)(76786001)(76796001)(87976001)(46102001)(77156001)(85306002)(74502001)(53806001)(61296002)(81542001)(92726001)(81342001)(74662001)(23756003)(84392001)(76482001)(94946001)(87286001)(87266001)(51856001)(93136001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:AMXPRD0111HT004.eurprd01.prod.exchangelabs.com; CLIP:157.56.250.117; FPR:; InfoNoRecordsMX:1; A:0; LANG:en; Received: from mail240-tx2 (localhost.localdomain [127.0.0.1]) by mail240-tx2 (MessageSwitch) id 1391104728840674_24155; Thu, 30 Jan 2014 17:58:48 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.227]) by mail240-tx2.bigfish.com (Postfix) with ESMTP id C4DB0400B5; Thu, 30 Jan 2014 17:58:48 +0000 (UTC) Received: from AM2PRD0710HT004.eurprd07.prod.outlook.com (157.56.249.213) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 30 Jan 2014 17:58:43 +0000 Received: from DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) by AM2PRD0710HT004.eurprd07.prod.outlook.com (10.255.165.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 30 Jan 2014 17:58:34 +0000 Received: from AMXPRD0111HT004.eurprd01.prod.exchangelabs.com (157.56.250.117) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.859.15; Thu, 30 Jan 2014 17:58:32 +0000 Message-ID: <00ce01cf1de4$45fb9ba0$4001a8c0@gateway.2wire.net> From: t.petch To: References: <201401270458.s0R4woWw074790@maildrop2.v6ds.occnc.com> Date: Thu, 30 Jan 2014 17:53:15 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-ClientProxiedBy: AM3PR07CA004.eurprd07.prod.outlook.com (10.242.16.44) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 0107098B6C X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 17:58:56 -0000 Curtis MP2MP Multipoint to Point ? I would like the first sentence of the Abstract to start the Introduction - otherwise there is no intended audience (and I tend to skip Abstracts when I know I am going to be interested in a document). And is that second clause for Operators eg a basis for operators to evaluate forwarding implementations. (more to follow - the I-D is big and my reading is slow:-( Tom Petch ----- Original Message ----- From: "Curtis Villamizar" To: Cc: ; Sent: Monday, January 27, 2014 4:58 AM From rcallon@juniper.net Thu Jan 30 10:27:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6271A0260; Thu, 30 Jan 2014 10:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 69tFcQ6bpdi4; Thu, 30 Jan 2014 10:27:21 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0B37B1A0054; Thu, 30 Jan 2014 10:27:19 -0800 (PST) Received: from mail111-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE040.bigfish.com (10.236.130.103) with Microsoft SMTP Server id 14.1.225.22; Thu, 30 Jan 2014 18:27:16 +0000 Received: from mail111-co9 (localhost [127.0.0.1]) by mail111-co9-R.bigfish.com (Postfix) with ESMTP id 3F772740321; Thu, 30 Jan 2014 18:27:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(z579ehzbb2dI98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h9a9j1155h) Received-SPF: pass (mail111-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(479174003)(13464003)(24454002)(377454003)(51704005)(199002)(189002)(49866001)(87266001)(74316001)(81342001)(80022001)(66066001)(90146001)(33646001)(85852003)(85306002)(59766001)(77982001)(31966008)(47976001)(47446002)(50986001)(87936001)(2656002)(94316002)(65816001)(74366001)(56816005)(4396001)(74876001)(94946001)(63696002)(93136001)(86362001)(2171001)(74706001)(74502001)(51856001)(81542001)(76796001)(54316002)(81686001)(81816001)(53806001)(56776001)(80976001)(76482001)(19580405001)(54356001)(46102001)(69226001)(15975445006)(19580395003)(76576001)(76786001)(83072002)(47736001)(79102001)(74662001)(83322001)(92566001)(93516002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail111-co9 (localhost.localdomain [127.0.0.1]) by mail111-co9 (MessageSwitch) id 1391106434111587_17146; Thu, 30 Jan 2014 18:27:14 +0000 (UTC) Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.240]) by mail111-co9.bigfish.com (Postfix) with ESMTP id 164ABA00046; Thu, 30 Jan 2014 18:27:14 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 30 Jan 2014 18:27:14 +0000 Received: from CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 30 Jan 2014 18:27:12 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) with Microsoft SMTP Server (TLS) id 15.0.859.15; Thu, 30 Jan 2014 18:27:10 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0859.020; Thu, 30 Jan 2014 18:27:09 +0000 From: Ross Callon To: "Joel M. Halpern" , Joe Touch , "EXT - joelja@bogus.com" , "stbryant@cisco.com" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPGTj803Ue20svMUem0bxV/kZZIZqYyqAAgAACKoCAACGRgIAAAT2AgAAHPgCABKMSEA== Date: Thu, 30 Jan 2014 18:27:09 +0000 Message-ID: <47d85636e70c4d6f86f199a274bcdcb0@CO2PR05MB636.namprd05.prod.outlook.com> References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu> <52E6B128.8060306@joelhalpern.com> In-Reply-To: <52E6B128.8060306@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0107098B6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 18:27:23 -0000 +1 to what Joel said. It is clear that Joe's view of "fast enough" for a ho= st interface is not the same as my customer's view of "fast enough" for a c= ore router (nor should it be the same -- routers have to be faster than hos= t interfaces).=20 More important is the issue of what can we get vendors to implement, which = is probably better worded as what can we get network operators to push vend= ors to implement. If you are talking about fundamentally changing the inter= nal data path for packets within a router or changing the data path into an= d out of specific chips to carry significantly more information, then we ar= e talking about at least hundreds of millions and probably billions of doll= ars of equipment that needs to be replaced. This needs a very compelling ju= stification before it is actually going to happen.=20 Ross -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, January 27, 2014 2:19 PM To: Joe Touch; EXT - joelja@bogus.com; stbryant@cisco.com Cc: mpls@ietf.org; IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard Yes Joe, routers could ahve been built to do those calcualtions at that=20 performance scale. There are however two major problems: 1) That is not how routers are built. 2) The target performance scale is rather higher. So could someone build an ASIC to do what you want? Probably. Is there=20 any reason in the world to expect operators to pay the significant extra=20 cost for such? Not that I can see. And even if we could and they would, that is not the world into which we=20 are deploying these tunnels. Yours, Joel On 1/27/14 1:53 PM, Joe Touch wrote: > > > On 1/27/2014 10:48 AM, joel jaeggli wrote: >> On 1/27/14, 8:48 AM, Joe Touch wrote: >>> Those same mechanisms have provided hardware checksum support for a >>> very long time. >> >> The new header and the payload are actually in different parts of the >> forwarding complex until they hit the output queue, you can't checksum >> data you don't have. > > You can (and some do) the checksum component parts when things go into > memory; the partial sums can be added as the parts are combined in the > output queue. > > I appreciate that we're all taking about what might be done, but the > reality is that there are many 'transparent TCP proxies' that have to do > this, so there's clearly a solution, and it clearly runs fast enough. > > Joe > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From touch@isi.edu Thu Jan 30 11:29:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46A61A044E; Thu, 30 Jan 2014 11:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 dEkV6TGX2E2N; Thu, 30 Jan 2014 11:29:56 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D67B51A0296; Thu, 30 Jan 2014 11:29:56 -0800 (PST) Received: from [10.120.113.83] (guest-wireless-upc-nat-206-117-88-007.usc.edu [206.117.88.7]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s0UJStth025549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jan 2014 11:28:57 -0800 (PST) Message-ID: <52EAA7F7.1010502@isi.edu> Date: Thu, 30 Jan 2014 11:28:55 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ross Callon , "Joel M. Halpern" , "EXT - joelja@bogus.com" , "stbryant@cisco.com" References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu> <52E6B128.8060306@joelhalpern.com> <47d85636e70c4d6f86f199a274bcdcb0@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <47d85636e70c4d6f86f199a274bcdcb0@CO2PR05MB636.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 19:29:58 -0000 I think we agree that if the router needs faster, then the router gets faster. Where we disagree is whether the "bull in the china shop" gets to ignore the rules of the road to get what it wants. I.e., I won't disagree on what router vendors want or what they're willing to support (though I will disagree on what hardware can do, based on experience). I will disagree that routers get to run roughshod over the rest of us to do it. Simple solution -- don't use UDP. Joe On 1/30/2014 10:27 AM, Ross Callon wrote: > +1 to what Joel said. It is clear that Joe's view of "fast enough" for a host interface is not the same as my customer's view of "fast enough" for a core router (nor should it be the same -- routers have to be faster than host interfaces). > > More important is the issue of what can we get vendors to implement, which is probably better worded as what can we get network operators to push vendors to implement. If you are talking about fundamentally changing the internal data path for packets within a router or changing the data path into and out of specific chips to carry significantly more information, then we are talking about at least hundreds of millions and probably billions of dollars of equipment that needs to be replaced. This needs a very compelling justification before it is actually going to happen. > > Ross > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Monday, January 27, 2014 2:19 PM > To: Joe Touch; EXT - joelja@bogus.com; stbryant@cisco.com > Cc: mpls@ietf.org; IETF discussion list > Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard > > Yes Joe, routers could ahve been built to do those calcualtions at that > performance scale. > There are however two major problems: > > 1) That is not how routers are built. > 2) The target performance scale is rather higher. > > So could someone build an ASIC to do what you want? Probably. Is there > any reason in the world to expect operators to pay the significant extra > cost for such? Not that I can see. > And even if we could and they would, that is not the world into which we > are deploying these tunnels. > > Yours, > Joel > > On 1/27/14 1:53 PM, Joe Touch wrote: >> >> >> On 1/27/2014 10:48 AM, joel jaeggli wrote: >>> On 1/27/14, 8:48 AM, Joe Touch wrote: >>>> Those same mechanisms have provided hardware checksum support for a >>>> very long time. >>> >>> The new header and the payload are actually in different parts of the >>> forwarding complex until they hit the output queue, you can't checksum >>> data you don't have. >> >> You can (and some do) the checksum component parts when things go into >> memory; the partial sums can be added as the parts are combined in the >> output queue. >> >> I appreciate that we're all taking about what might be done, but the >> reality is that there are many 'transparent TCP proxies' that have to do >> this, so there's clearly a solution, and it clearly runs fast enough. >> >> Joe >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > From jnc@mercury.lcs.mit.edu Thu Jan 30 11:32:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4651A0451; Thu, 30 Jan 2014 11:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 4XVv_hmBleDt; Thu, 30 Jan 2014 11:32:04 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1527C1A044E; Thu, 30 Jan 2014 11:32:03 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7BBD018C1C1; Thu, 30 Jan 2014 14:32:00 -0500 (EST) To: ietf@ietf.org, mpls@ietf.org Message-Id: <20140130193200.7BBD018C1C1@mercury.lcs.mit.edu> Date: Thu, 30 Jan 2014 14:32:00 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 19:32:05 -0000 > From: Joe Touch > Simple solution -- don't use UDP. Yes, because if we use a different protocol, any potential congestion will magically disappear! Noel From scott.brim@gmail.com Thu Jan 30 12:21:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D901A046D; Thu, 30 Jan 2014 12:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKI4IW1gk-B3; Thu, 30 Jan 2014 12:21:12 -0800 (PST) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 976B01A044E; Thu, 30 Jan 2014 12:21:12 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id g12so4241019oah.3 for ; Thu, 30 Jan 2014 12:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lX84fSBDCsmb1d6Cc5ErFgVjr8He8AVteXkOmKgaEr4=; b=dy4yoH1CHUGeSiqy4bxUXkDrZItbCs18n159xckfq4j67CUxAll6cne9TbexjT5M3k mQofUY5fJyUT9bwhXe41xyHEn/dTBIpoIQLjGcs1zvt3TAvGv6iYlgG3tJ+VYbYl+p73 VTC6jw7rz8BkEofJ+SuzXyHfgUMRhlX9sHVy5rZMzCdcswdqtTxPYL9vby7nea6woIA6 shuhhZYZsAS9DI6ahxX+W0CQ1DDlG/1HUM10rpi3Q6DzDhgO6DNtFwXifO4LOMPzErmY aA8ViboiyjKWEjd26zdHxM9yC3B8NeETl/4B/G6soRgLi+shm6M/UAZlptvpUjY34XQA /Cdg== X-Received: by 10.60.56.200 with SMTP id c8mr1922947oeq.80.1391113269117; Thu, 30 Jan 2014 12:21:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Thu, 30 Jan 2014 12:20:47 -0800 (PST) In-Reply-To: <52EAA7F7.1010502@isi.edu> References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu> <52E6B128.8060306@joelhalpern.com> <47d85636e70c4d6f86f199a274bcdcb0@CO2PR05MB636.namprd05.prod.outlook.com> <52EAA7F7.1010502@isi.edu> From: Scott Brim Date: Thu, 30 Jan 2014 15:20:47 -0500 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=089e015370943f8b6904f135ccb0 Cc: "mpls@ietf.org" , IETF discussion list , "EXT - joelja@bogus.com" , Ross Callon Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 20:21:14 -0000 --089e015370943f8b6904f135ccb0 Content-Type: text/plain; charset=ISO-8859-1 There are two topics that should be separate: checksums and congestion control. On Thu, Jan 30, 2014 at 2:28 PM, Joe Touch wrote: > I think we agree that if the router needs faster, then the router gets > faster. > That's in response to Ross, about checksums. > Where we disagree is whether the "bull in the china shop" gets to ignore > the rules of the road to get what it wants. > congestion > I.e., I won't disagree on what router vendors want or what they're willing > to support (though I will disagree on what hardware can do, based on > experience). > checksums > I will disagree that routers get to run roughshod over the rest of us to > do it. > > Simple solution -- don't use UDP. congestion. Joe, do I understand correctly that you've conceded about checksums and now you want to talk about congestion again? swb --089e015370943f8b6904f135ccb0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are two topics that should be separate: checksums an= d congestion control.

On Thu, Jan 30, 2014 at 2:28 PM, Joe Touch <touch@isi.edu> w= rote:
I think we agree that if the router needs fa= ster, then the router gets faster.

That= 's in response to Ross, about checksums.
=A0
Where we disagree is whether t= he "bull in the china shop" gets to ignore the rules of the road = to get what it wants.

congestion
=A0
I.e., I won't disagree on what router vendors want o= r what they're willing to support (though I will disagree on what hardw= are can do, based on experience).

checksums
=A0
I will disagree that routers get to run roughshod over the rest of us to do= it.

Simple solution -- don't use UDP.

conge= stion.

Joe, do I understand correctly that you'= ;ve conceded about checksums and now you want to talk about congestion agai= n?=A0

swb
--089e015370943f8b6904f135ccb0-- From touch@isi.edu Thu Jan 30 12:30:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13F21A0467; Thu, 30 Jan 2014 12:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 EQQlbbMCkwTs; Thu, 30 Jan 2014 12:30:26 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5C89D1A046D; Thu, 30 Jan 2014 12:30:26 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0UKTLZH022449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jan 2014 12:29:21 -0800 (PST) Message-ID: <52EAB621.5010403@isi.edu> Date: Thu, 30 Jan 2014 12:29:21 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Scott Brim References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu> <52E6B128.8060306@joelhalpern.com> <47d85636e70c4d6f86f199a274bcdcb0@CO2PR05MB636.namprd05.prod.outlook.com> <52EAA7F7.1010502@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "mpls@ietf.org" , IETF discussion list , "EXT - joelja@bogus.com" , Ross Callon Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 20:30:28 -0000 On 1/30/2014 12:20 PM, Scott Brim wrote: > There are two topics that should be separate: checksums and congestion > control. Agreed. > On Thu, Jan 30, 2014 at 2:28 PM, Joe Touch > wrote: > > I think we agree that if the router needs faster, then the router > gets faster. > > That's in response to Ross, about checksums. Also about the complaint that routers run to fast to run any sort of congestion algorithm, including circuit breakers (which is clearly false). > Where we disagree is whether the "bull in the china shop" gets to > ignore the rules of the road to get what it wants. > > congestion Yes, in the sense that incorrect checksums should be checked at the egress only anyway, and thus ignoring them would only impact the network after the egress. No, in the sense that anything that peeks inside a UDP header has the right to want to check whether that data is uncorrupted - that includes things like NATs. > I.e., I won't disagree on what router vendors want or what they're > willing to support (though I will disagree on what hardware can do, > based on experience). > > checksums Both, as per above. > I will disagree that routers get to run roughshod over the rest of > us to do it. > > Simple solution -- don't use UDP. > > congestion. Both. If you want the benefits of UDP, pay the penalty. If you don't want the penalty, don't use UDP. I don't buy the claims that there's a need here to eat cake and have it too. > Joe, do I understand correctly that you've conceded about checksums and > now you want to talk about congestion again? I'm talking about the overall argument, which has circled back to "we need to do what vendors are willing to do", rather than "vendors need to play nice in the Internet that they're making money off of". Joe From curtis@ipv6.occnc.com Thu Jan 30 13:07:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE12C1A04CC for ; Thu, 30 Jan 2014 13:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 47nXfm9PhUlj for ; Thu, 30 Jan 2014 13:07:05 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 242101A0489 for ; Thu, 30 Jan 2014 13:07:05 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0UL6tln065171; Thu, 30 Jan 2014 16:06:56 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401302106.s0UL6tln065171@maildrop2.v6ds.occnc.com> To: "t.petch" From: Curtis Villamizar In-reply-to: Your message of "Thu, 30 Jan 2014 17:53:15 +0000." <00ce01cf1de4$45fb9ba0$4001a8c0@gateway.2wire.net> Date: Thu, 30 Jan 2014 16:06:55 -0500 Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 21:07:07 -0000 In message <00ce01cf1de4$45fb9ba0$4001a8c0@gateway.2wire.net> "t.petch" writes: > Curtis > > MP2MP Multipoint to Point ? Multipoint to multipoint. Ie: capable of supporting <*,G> though possibly for a policy constrained value of "*". Some chips can do it but I'm not sure what routers can do (whether software supports it) and if so if anyone deploys MP2MP. At least some P2MP for distribution of stuff like video, maybe a lot but I don't know. Plenty of MP2P since LDP is inherently MP2P. > I would like the first sentence of the Abstract to start the > Introduction - otherwise there is no intended audience (and I tend to > skip Abstracts when I know I am going to be interested in a document). The intended audience is in the intro later on in Section 1.4 ("Target Audience"). > And is that second clause for Operators eg > a basis for operators to evaluate forwarding implementations. It is meant for both operators and system designers. System designers (ie: people working for router vendors that buy off the shelf silicon) need to pick a forwarding chip long before operators are evaluating. See Section 1.4. In the case of forwarding the "implementor" is designing a chip. The "system designer" is using it in a product. The operator is (we hope) trying to find out what if any bad decisions were made in an evaluation to determine what effect any shortcomings would have before deploying and finding out the hard way. > (more to follow - the I-D is big and my reading is slow:-( No problem. Thanks for taking a look. > Tom Petch Curtis From gdaley@au.logicalis.com Thu Jan 30 14:45:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95611A04DD; Thu, 30 Jan 2014 14:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.535, 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 iRSOL6yHGQeQ; Thu, 30 Jan 2014 14:45:01 -0800 (PST) Received: from smtp2.au.logicalis.com (smtp2.au.logicalis.com [203.8.7.133]) by ietfa.amsl.com (Postfix) with ESMTP id 44D5C1A04DA; Thu, 30 Jan 2014 14:45:00 -0800 (PST) Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp2.au.logicalis.com with ESMTP; 31 Jan 2014 09:44:57 +1100 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0347.000; Fri, 31 Jan 2014 09:44:54 +1100 From: Greg Daley To: 'Noel Chiappa' , "ietf@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPHfHxZzPPQlRcgk6ua2U45NfiYJqd1tSw Date: Thu, 30 Jan 2014 22:44:54 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D992817FDAB19@sdcexchms.au.logicalis.com> References: <20140130193200.7BBD018C1C1@mercury.lcs.mit.edu> In-Reply-To: <20140130193200.7BBD018C1C1@mercury.lcs.mit.edu> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:45:03 -0000 > > From: Joe Touch >=20 > > Simple solution -- don't use UDP. >=20 > Yes, because if we use a different protocol, any potential congestion wil= l > magically disappear! Isn't that protocol called DCCP? (per RFC 4340 and 5348) It would be interesting and potentially feasible to outline MPLS over DCCP = (given a solid use case), but it would be one of the few (9) named applicat= ion bindings for this protocol today: http://www.iana.org/assignments/service-names-port-numbers/service-names-po= rt-numbers.txt Of course, in order to get the protocols to pass legacy firewall inspection= , UDP encapsulation may be required, and companies would have to actually i= mplement the protocol... Greg Daley gdaley@au.logicalis.com From curtis@ipv6.occnc.com Thu Jan 30 17:38:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC311A051A for ; Thu, 30 Jan 2014 17:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 TThF7PT3Hcgw for ; Thu, 30 Jan 2014 17:38:38 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id AA3031A0517 for ; Thu, 30 Jan 2014 17:38:38 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0V1cT4c068414; Thu, 30 Jan 2014 20:38:30 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401310138.s0V1cT4c068414@maildrop2.v6ds.occnc.com> To: Xuxiaohu From: Curtis Villamizar In-reply-to: Your message of "Fri, 24 Jan 2014 08:33:49 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247A2B@NKGEML512-MBS.china.huawei.com> Date: Thu, 30 Jan 2014 20:38:29 -0500 Cc: "mpls@ietf.org" Subject: Re: [mpls] fwd: New Version Notification - draft-ietf-mpls-in-udp-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 01:38:42 -0000 In message <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247A2B@NKGEML512-MBS.china.huawei.com> Xuxiaohu writes: > Hi all, > > A new version (-05) has been submitted for draft-ietf-mpls-in-udp: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-udp-05.txt > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-05 > > The comments and suggestions received during the Last Call has been > incorporated in this revision, especially the rough consensus on > congestion control and checksum. Thanks a lot for those people who > have contributed their time and energy to review and help improving > this doc. > > Best regards, > Xiaohu (on behalf of all co-authors) Xiaohu, It looks like I get to be the first to comment on the new version of this draft, though there has been considerable noise^H^H^H^H^H discussion tangentially related to this draft. Substantive (though perhaps not major): Please consider this change to "UDP Checksum" in Section 3: OLD The usage of this field is in accordance with the current UDP specification [RFC768]. In the IPv4 UDP encapsulation case, this field is RECOMMENDED to be set to zero. In the IPv6 UDP encapsulation case, this field SHOULD NOT be set to zero. If the UDP checksum needs to be disabled for performance or implementation reasons, the considerations described in [RFC6935] [RFC6936] MUST be examined. NEW The usage of this field is as defined in the current UDP specification [RFC768]. UDP allows the UDP checksum to be set to zero indicating that no checksum was computed. Except in extroidinary cases, non-zero UDP checksum SHOULD be used. The considerations described in detail in [RFC6935] [RFC6936] MUST be examined if UDP checksums need to be disabled for performance or implementation reasons. UDP checksum should only be disabled on private networks or where MPLS in UDP encapsualation is added by a service provider with MPLS in UDP traffic entirely confined to the network of that service provider or within cooperating service providers with explicit permission. Where it is not possible to use full UDP checksum, and if using UDP-Lite [RFC3828] is feasible, UDP-Lite SHOULD be used rather than UDP with disabled checksums. The above is more palatable to some people who object to not using checksums but allows zero checksums if there is no other option. Also please change the "Congestion Considerations" wording. The deletions and additions are highlighted with beginning of line markings similar to unified diffs. OLD - Since the MPLS-in-UDP encapsulation causes MPLS packets to be - forwarded through "UDP tunnels", the congestion control guidelines for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically, as stated in Section 3.1.3 of [RFC5405], "some bulk transfer applications may choose not to implement any congestion control mechanism and instead rely on transmitting across reserved path capacity. This might be an acceptable choice for a subset of restricted networking environments, but is by no means a safe practice for operation in the Internet." - Given the fact that the MPLS-in-GRE and MPLS-in-IP [RFC4023] - encapsulation technologies have been successfully deployed - within a SP network or networks of an adjacent set of - co-operating SPs which is a restricted network environment without any congestion control mechanism - and the fact that the current MPLS technology couldn't provide - congestion control without major changes, the MPLS-in-UDP - encapsulation MUST only be deployed within a SP network or - networks of an adjacent set of co-operating SPs as well. NEW + MPLS-in-UDP is applicable in limited circumstances (See Section + 1.3). If deployed in a manner consistent with this + applicability statement, then guidelines for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically, as stated in Section 3.1.3 of [RFC5405]: "some bulk transfer applications may choose not to implement any congestion control mechanism and instead rely on transmitting across reserved path capacity. This might be an acceptable choice for a subset of restricted networking environments, but is by no means a safe practice for operation in the Internet." + This usage is consistent with MPLS-in-GRE and MPLS-in-IP [RFC4023] + which have been successfully deployed + in deployments consistent with the applicability of MPLS-in-UDP + defined in Section 1.3 and have been deployed without any congestion control mechanism. If MPLS-in-UDP is deployed in a manner that is not consistent with the applicability of MPLS-in-UDP defined in Section 1.3, then one of the following conditions SHOULD be met: 1. The traffic within the encapsulated MPLS payload is known to be predominantly either TCP dominated IP traffic which supports end-to-end congestion control, or another type of traffic which supports end-to-end congestion control. -- OR -- 2. DCCP [RFC4340] SHOULD be used in place of UDP. CCID 3 as defined in RFC 4340 is RECOMMENDED since it will provde better performance if the MPLS encapsulated payload is TCP dominated or is TCP-like in its response to congestion. The above text makes a recommendation for the type of congestion control to be used if the applicability statement is not adhered to. This may be more palatable to those who have objected to the current statements on congestion in this document. The change to the original text is mostly wording changes, but essetially says the same thing, but with an emphasis on meeting the applicability. May be significant: This (in "Processing Procedures") doesn't make sense to me: OLD As for whether the top label in the MPLS label stack is downstream-assigned or upstream-assigned, it SHOULD be determined based on the tunnel destination IP address. That is to say, if the destination IP address is a multicast address, the top label SHOULD be upstream-assigned, otherwise if the destination IP address is a unicast address, it SHOULD be downstream-assigned. The encapsulator as an LSR (not LER) should be receiving MPLS packets with a MPLS label stack. It should do a label operation, such as a label swap, and then put a IP and UDP encapsulation in front of the packet. What MPLS operation to apply should be out of scope for this document since it will be the result of either 1) a long-distand LDP (T-LDP) session, or 2) a long distance RSVP-TE (no special name, just TTL>1) session, or some form of management magic that directly programs a label operation for a given inbound label. I suggest that you change this text to this and start a new paragraph. The encapsulator acting in an LSR role for some set of LSP is assumed to receive MPLS encapsulated traffic, perform some label operation, and forward the packet with MPLS-in-UDP IP and UDP encapsulation added. The encapsulator acting in the LER role for some set of LSP is assumed to receive non-MPLS traffic, push MPLS labels and forward the packet with MPLS-in-UDP IP and UDP encapsulation added. How the label operations to be carried out are determined is out of scope for this document but is expected to be most often determined through LDP or RSVP-TE signaling, or through management plane actions. Nit: Then in next paragraph s/As such, intermediate/Intermediate/ Nit: Next paragraph s/As for other/For other/ Minor: There are two cases for setting the source port. OLD In the case where the tunnel does not need entropy, this field of all packets belonging to a given flow SHOULD be set to a randomly selected constant value so as to avoid packet reordering. NEW Where the tunnel needs entropy, the source port for all packets belonging to a given flow SHOULD be set to the same value to avoid reordering within a microflow. Where the tunnel does not need entropy, the source port for all packets belonging to a given MPLS LSP SHOULD be set to a randomly selected per LSP constant value so as to avoid packet reordering within any given LSP. The above two sentences should probably start a new paragraph. Nit: Drop "Note that" in the begginging of the second sentence of the abstract, but keep the sentence. s/the congestion control/congestion control/ s/[RFC 6830]/[RFC6830]/ Remove redundancy: /Currently, most existing routers/Currently, most routers/ or /Currently, most existing routers/Most existing routers/ s/where the congestion control is a must. /where the congestion control is required./ s/so as to/to/ Idnits will get you on a long line in "MPLS Label Stack" ending in lots of spaces and [RFC3032]. Don't use ms-word for RFCs and you'll have less of this sort of headache. Drop "as well" in the sentence that starts with "What algorithm is actually used " in "Source Port of UDP". Idnits will get you on a long line in RFC768 in references, also RFC3032, RFC6347, RFC6438, RFC6830. You should check Idnits when you submit so you can pick up small easy to fix stuff like this. Other: Security ADs will likely reword "Security Considerations". Please reply and indicate whether you agree with the "substantive changes" above so the WG can discuss this. With any luck there will be no objection simply because everyone already has mpls-in-udp in their procmail filters. :-) Regards, Curtis From stbryant@cisco.com Fri Jan 31 02:51:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA4A1A058B; Fri, 31 Jan 2014 02:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, 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 odH1GPIMrj2I; Fri, 31 Jan 2014 02:51:01 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 72D3C1A058A; Fri, 31 Jan 2014 02:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=297; q=dns/txt; s=iport; t=1391165458; x=1392375058; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=WLw1m40bAC4ADWAux+tfJOfXLMXnpv01Y7nByMDXTVs=; b=NNMLL+H7waam64l/J6PltDoG3LcnJoNtMhpn1x0ODr7Uf2ac5LrcIYA0 zZGwJ/2YRJ98jl+GnlJVYPdXPmkjvAz5uYwM4vkRDVN9rqNyJr7YFbvY+ F9/xPilQuqSdkRcKzDMcxuHqTspuvy1hxC7WXW8fgexP+wXsQKYa/rNKG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABZ/61KQ/khM/2dsb2JhbABZDoJ+vkWBBRZ0giUBAQEEOEARCw4KCRYECwkDAgECAUUGAQwGAgEBiAHNBBePCYQ4AQOUQoNohkiLWYFvfz8 X-IronPort-AV: E=Sophos;i="4.95,757,1384300800"; d="scan'208";a="4468290" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 31 Jan 2014 10:50:57 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0VAouVv014647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jan 2014 10:50:56 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0VAosI7009570; Fri, 31 Jan 2014 10:50:55 GMT Message-ID: <52EB800E.2090102@cisco.com> Date: Fri, 31 Jan 2014 10:50:54 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Greg Daley , "'Noel Chiappa'" , "ietf@ietf.org" , "mpls@ietf.org" References: <20140130193200.7BBD018C1C1@mercury.lcs.mit.edu> <72381AF1F18BAE4F890A0813768D992817FDAB19@sdcexchms.au.logicalis.com> In-Reply-To: <72381AF1F18BAE4F890A0813768D992817FDAB19@sdcexchms.au.logicalis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 10:51:03 -0000 On 30/01/2014 22:44, Greg Daley wrote: > Of course, in order to get the protocols to pass legacy firewall > inspection, UDP encapsulation may be required, and companies would > have to actually implement the protocol... Greg Daley > gdaley@au.logicalis.com So UDP/DCCP/MPLS ? Stewart From l.wood@surrey.ac.uk Fri Jan 31 03:34:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FCE1A057D; Fri, 31 Jan 2014 03:34:28 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 6jVwg-BqMVcg; Fri, 31 Jan 2014 03:34:26 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.141]) by ietfa.amsl.com (Postfix) with ESMTP id 11FFB1A0590; Fri, 31 Jan 2014 03:34:25 -0800 (PST) Received: from [85.158.136.51:7852] by server-5.bemta-5.messagelabs.com id 44/0D-32749-D3A8BE25; Fri, 31 Jan 2014 11:34:21 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-11.tower-49.messagelabs.com!1391168061!19463993!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24193 invoked from network); 31 Jan 2014 11:34:21 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-11.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 31 Jan 2014 11:34:21 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 31 Jan 2014 11:34:20 +0000 From: To: , , , , Date: Fri, 31 Jan 2014 11:32:31 +0000 Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: Ac8ecmlbdUqQeAUTQQSU8IsB6dbYxwABbdgM Message-ID: <290E20B455C66743BE178C5C84F1240847E63346FE@EXMB01CMS.surrey.ac.uk> References: <20140130193200.7BBD018C1C1@mercury.lcs.mit.edu> <72381AF1F18BAE4F890A0813768D992817FDAB19@sdcexchms.au.logicalis.com>, <52EB800E.2090102@cisco.com> In-Reply-To: <52EB800E.2090102@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 11:34:28 -0000 RFC 6773. which requires a full udp checksum for nat traversal. Lloyd Wood http://about.me/lloydwood ________________________________________ From: ietf [ietf-bounces@ietf.org] On Behalf Of Stewart Bryant [stbryant@ci= sco.com] Sent: 31 January 2014 10:50 To: Greg Daley; 'Noel Chiappa'; ietf@ietf.org; mpls@ietf.org Subject: Re: [mpls] Last Call: (Encapsulati= ng MPLS in UDP) to Proposed Standard On 30/01/2014 22:44, Greg Daley wrote: > Of course, in order to get the protocols to pass legacy firewall > inspection, UDP encapsulation may be required, and companies would > have to actually implement the protocol... Greg Daley > gdaley@au.logicalis.com So UDP/DCCP/MPLS ? Stewart From internet-drafts@ietf.org Fri Jan 31 04:18:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5191A1DBD; Fri, 31 Jan 2014 04:18:22 -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 P2CYo31-Gm6J; Fri, 31 Jan 2014 04:18:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBC21A05BE; Fri, 31 Jan 2014 04:18:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140131121810.4547.20104.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 04:18:10 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-temporal-hitless-psm-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 12:18:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Temporal and hitless path segment monitoring Authors : Alessandro D'Alessandro Manuel Paul Satoshi Ueno Kaoru Arai Yoshinori Koike Filename : draft-ietf-mpls-tp-temporal-hitless-psm-05.txt Pages : 18 Date : 2014-01-31 Abstract: The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport and complement converged packet network deployments. Among the most attractive features of MPLS-TP are OAM functions, which enable network operators or service providers to provide various maintenance characteristics, such as fault location, survivability, performance monitoring, and preliminary or in-service measurements. One of the most important mechanisms which is common for transport network operation is fault location. A segment monitoring function of a transport path is effective in terms of extension of the maintenance work and indispensable particularly when the OAM function is effective only between end points. However, the current approach defined for MPLS-TP for the segment monitoring (SPME) has some fatal drawbacks. This document elaborates on the problem statement for the Sub-path Maintenance Elements (SPMEs) which provides monitoring of a portion of a set of transport paths (LSPs or MS-PWs). Based on the problems, this document specifies new requirements to consider a new improved mechanism of hitless transport path segment monitoring. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-temporal-hitless-psm/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-temporal-hitless-psm-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-temporal-hitless-psm-= 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 stephane.litkowski@orange.com Fri Jan 31 06:11:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53D41A1F1F for ; Fri, 31 Jan 2014 06:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 dm2U0iO_6vqj for ; Fri, 31 Jan 2014 06:11:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id B77D51A0064 for ; Fri, 31 Jan 2014 06:11:51 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 658732AC5E9; Fri, 31 Jan 2014 15:11:47 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 3A513158086; Fri, 31 Jan 2014 15:11:47 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 31 Jan 2014 15:11:45 +0100 From: To: "draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org" Date: Fri, 31 Jan 2014 15:11:45 +0100 Thread-Topic: draft-kini-mpls-entropy-label-src-stacked-tunnels Thread-Index: Ac8eiGlrtXECT+cBRj6dlLARCPe0TA== Message-ID: <11094_1391177507_52EBAF23_11094_2718_1_EEE55384044474429A926C625D0FCC8109A301097D@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC8109A301097DPUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.31.93314 Cc: "mpls@ietf.org" Subject: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 14:11:56 -0000 --_000_EEE55384044474429A926C625D0FCC8109A301097DPUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Authors, I would like to know if you are progressing on this draft ? Entropy label support for stacked tunnels would be mandatory for us, so I w= ould like to support the work on this topic to have a working solution as s= oon as possible. Regarding the solutions you are proposing in the current version, there is = none perfect one, and unfortunately all have drawbacks. The compatibility (on LSR) with current generation of hardwares may be "goo= d" (mandatory ?) for the target solution. In your document , solution =A73.3 "re-usable EL for a stack of tunnels" so= unds for me to be the best base idea. I'm just wondering what would be the = hardware impact of doing the reinsertion of ELI at tunnel end . Could this = be done in one pass ? (IMHO, this may be possible, as today we are able to = pop or swap + push FRR headers) As you are three different vendors as co-au= thor, did you already evaluate such impact on your hardwares ? (I'm not exp= ecting details on the mailing list, but I would be interested by details un= icast to me and just yes/no on the the list) To be exhaustive in listing solutions, did you think about leaving the EL/E= LI at top of the stack ? I think there is already a case where a special la= bel may be kept at top of the stack (MPLS Router alert). What would be needed : - each hop need to advertise is ability to process EL, if nexthop = cannot process EL, it should be removed when forwarded to nexthop (there sh= ould be the same requirement for re-usable EL) I don't think this is really different from re-usable EL in the concept : - reusable EL : process top level forwarding label, if popped and = next label is EL, pop ELI/EL and next label L, push pack ELI/EL and then L = (we need to swap positions between ELI/EL and L) if nexthop is able to proc= ess EL. - top level EL : process top level ELI, ELI is recognized, ELI/EL = is removed, forwarding is done on forwarding label, ELI/EL is pushed back i= n nexthop is able to process EL. In term of operations, I think that top level EL may be simpler , but as I'= m not hardware coder, may be I'm wrong ... moreover it may be similar to MP= LS Router alert processing. Your thoughts ? Stephane ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC8109A301097DPUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Authors,

 

 

I would like to kn= ow if you are progressing on this draft ?

Entropy label support for stacked tunnels = would be mandatory for us, so I would like to support the work on this topi= c to have a working solution as soon as possible.

 

 

Regarding the solutions you are proposing in the curr= ent version, there is none perfect one, and unfortunately all have drawback= s.

The compati= bility (on LSR) with current generation of hardwares may be “goodR= 21; (mandatory ?) for the target solution.

 

In your document , solution =A73.3 “re-usable E= L for a stack of tunnels” sounds for me to be the best base idea. I&#= 8217;m just wondering what would be the hardware impact of doing the reinse= rtion of ELI at tunnel end . Could this be done in one pass ? (IMHO, this m= ay be possible, as today we are able to pop or swap + push FRR headers) As = you are three different vendors as co-author, did you already evaluate such= impact on your hardwares ? (I’m not expecting details on the mailing= list, but I would be interested by details unicast to me and just yes/no o= n the the list)

 

To be= exhaustive in listing solutions, did you think about leaving the EL/ELI at= top of the stack ? I think there is already a case where a special label m= ay be kept at top of the stack (MPLS Router alert).

What would be needed :

-   = ;       each hop need to advertise is ability to process EL, if nextho= p cannot process EL, it should be removed when forwarded to nexthop (there = should be the same requirement for re-usable EL)

I don’t think this is really diffe= rent from re-usable EL in the concept :

-      &nb= sp;   reusable = EL : process top level forwarding label, if popped and next label is EL, po= p ELI/EL and next label L, push pack ELI/EL and then L (we need to swap pos= itions between ELI/EL and L) if nexthop is able to process EL.

-  &nbs= p;       top level EL : process top level ELI, ELI is recognized, ELI/= EL is removed, forwarding is done on forwarding label, ELI/EL is pushed bac= k in nexthop is able to process EL.

 

In term of operations, I think that top level EL may be simp= ler , but as I’m not hardware coder, may be I’m wrong … m= oreover it may be similar to MPLS Router alert processing.

 

 

Your thoughts ?

 

 

Stephane

 

 

 

________________________________________=
___________________________________________________________________________=
______

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC8109A301097DPUEXCB2Fnante_-- From eric.gray@ericsson.com Fri Jan 31 08:23:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148D71A1F56 for ; Fri, 31 Jan 2014 08:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3DZ06DAGixX for ; Fri, 31 Jan 2014 08:23:50 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E070F1A1F48 for ; Fri, 31 Jan 2014 08:23:49 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-2d-52ebce07a082 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FB.BC.12743.70ECBE25; Fri, 31 Jan 2014 17:23:36 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Fri, 31 Jan 2014 11:23:38 -0500 From: Eric Gray To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll draft-ietf-mpls-tp-psc-itu Thread-Index: AQHPG1UEQOJe/QhYCEGecqXnt2as3JqfB4DQ Date: Fri, 31 Jan 2014 16:23:38 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632A03DD6@eusaamb107.ericsson.se> References: <52E64660.2090900@pi.nu> In-Reply-To: <52E64660.2090900@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/mixed; boundary="_002_48E1A67CB9CA044EADFEAB87D814BFF632A03DD6eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Sa0iTURjHOXsvezWM07R8ygtqGqFpKlILTLwEziIqI4QiatWLSUtkpmRF NMnEC2RpiK/OC05jmTmtlffIUlDLa5iYmNqFzIouM3XRanvPPkjffv/z/Hmuh6NkTewGLin5 HK9OVqp8WEe6MK39aCA3MB8frHlCyZeah1i5RVtGySdbTYx8cURHyydq9Ewko8j60MEodLpl iUIovsYqTKM/2f30YcfwU7wqKZ1Xb4047nh6tmdTiinsfO5QLbqCZoNykQMHOAzeZ+awhNfB 0FSDlR05GX6GQPNMj4i4jaB2oVRic7F4M/RM1iMbu+AIaPxkEZnC0wjyjdtt7IyDocXwiCae EHhv/s0QDoVxzYiVOY7GfmDRR9qenfBeeP2xUbTIsC/MvTJIbexgtZT+tYhpkLW5xb67ElLK FSbeVUhI0y4wM9xvH2AtzL21MIS9ofN6sZT4k6Bj4TtFaq2B3pJ3dAFaK6xIJaywCSts5H0L VLb9YAkHQG3VPEXYHe7fykGCdUUUzkJg/F0nChl+gGDgxyOaiEYEM3nfpES0IJgoy7FHihAs dLRRRDxEUNn/1Z6gEIEps14syWJ/yP/TwtoCLtgogb81uRSpWS2Baa1RdDnjdBgzVYnsgi/C zf6rFOEguKEdZwRxnxjM2YI4FGAnKNL2Sm1sO4Vwz2hdAmcdPAqa6g78vxvAO2Gw2EgRxqBr H7SzB3yuKGcIr4dsY4GdySkE8XSe0LpssOcJg4YsjTg/4E4pXO3uYyqR3x3EpaXy6WcTQ4Ob kPXf9wAb2Iza53Z0ITeO9nF1Mn2JiZfhROU5/gzPp/DqY+o0FZ/ahSScw4YryEmq8k5URLtl uA8LhntHnC1G8/Wxk6qh0JKDuzon41qev9yXEKXMWmW+bM54HJ0TEFj+60JUfWtMf96ebehp 3JZR2mtJfyLRy72kIn91955V4fMbd+sOXlSn+cR6plsuGfxKRxtfeFT7vjDFF8Kbqbjm2JlT kfruQ0c0CdqgyeA5Hzr1tDLEn1KnKv8BhRAm48UDAAA= Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] IPR poll draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 16:23:52 -0000 --_002_48E1A67CB9CA044EADFEAB87D814BFF632A03DD6eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Other than the IPR statement posted by Huawei on 24 January (see attached),= I am not=20 aware of any IPR that may apply to this draft. -- Eric Gray -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Monday, January 27, 2014 6:43 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); draft-ietf-mpls= -tp-psc-itu@tools.ietf.org Subject: IPR poll draft-ietf-mpls-tp-psc-itu Working Group, draft-ietf-mpls-tp-psc-itu is in working group last call, we have just received an IPR disclosure: http://www.ietf.org/mail-archive/web/mpls/current/msg11469.html This gives us reason to start an IPR poll on the document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-tp-psc-itu? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there is the one IPR disclosure, mentioned above, that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The=20 document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --_002_48E1A67CB9CA044EADFEAB87D814BFF632A03DD6eusaamb107erics_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 31 Jan 2014 16:23:37 GMT"; modification-date="Fri, 31 Jan 2014 16:23:37 GMT" Received: from ESESSHC010.ericsson.se (153.88.183.48) by EUSAAHC006.ericsson.se (147.117.188.90) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 24 Jan 2014 11:37:20 -0500 Received: from sessmg11.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.49) with Microsoft SMTP Server id 14.2.347.0; Fri, 24 Jan 2014 17:37:17 +0100 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by sessmg11.ericsson.net (Symantec Mail Security) with SMTP id 74.47.03971.DB692E25; Fri, 24 Jan 2014 17:37:17 +0100 (CET) Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD3B1A04C9; Fri, 24 Jan 2014 08:37:17 -0800 (PST) Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-KqbpLZYNwv; Fri, 24 Jan 2014 08:37:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B776E1A04CF; Fri, 24 Jan 2014 08:37:15 -0800 (PST) From: IETF Secretariat To: "ryoo@etri.re.kr" , Eric Gray , "huub.van.helvoort@huawei.com" , "alessandro.dalessandro@telecomitalia.it" , "cts@etri.re.kr" , "eosborne@cisco.com" CC: "stbryant@cisco.com" , "adrian@olddog.co.uk" , "loa@pi.nu" , "swallow@cisco.com" , "rcallon@juniper.net" , "mpls@ietf.org" , "ipr-announce@ietf.org" Subject: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-tp-psc-itu-01 Thread-Topic: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-tp-psc-itu-01 Thread-Index: AQHPGSKNVeMr8b8SPUeebTB5kJXo8Q== Importance: high X-Priority: 1 Date: Fri, 24 Jan 2014 16:37:15 +0000 Message-ID: <20140124163715.30234.75519.idtracker@ietfa.amsl.com> Content-Language: en-US X-MS-Exchange-Organization-AuthSource: ESESSHC010.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-Message-Flag: Follow up X-MS-TNEF-Correlator: auto-submitted: auto-generated x-auditid: c1b4fb3d-b7ef88e000000f83-52-52e296bcf07b x-brightmail-tracker: H4sIAAAAAAAAA+NgFvrFIsWRWlGSWpSXmKPExsXCIn9MR3fvtEdBBtsvalvsvrae3YHR49fX q2wBjFFcNimpOZllqUX6dglcGTN6n7AVHGateLRMvIHxMksXIyeHhICJxN3zU5ggbDGJC/fW s4HYQgLbGSX23nTuYuQCsqcxSnT0/WGFKNKQmLHyAiNEYhujROe1rewQzlRGiU0vd4ON4hUQ lDg58wnQCg4OZgFNifW79EHCzALaEssWvmYGsdkEtCR6/u5kA+kVEZjBKHGpZy3YVGaBNkaJ LbOvg90nLFAmseDwPzaI1SIS764+ZAYZKiEgKbF5njBImFFATuLHscdgewUEBCT+TboAtpdX wFFi0+pAkDCLgKrE+6VbmSYwisxCct0shOtmIbluASPzKkbR4tTi4tx0Q0O91KLM5OLi/Dy9 vNSSTYzAAD+45bftDsYT68wPMUpyMCmJ8l6a8ihIiC8pP6UyI7E4I76oNCe1+BCjNAeLkjiv EMvDICGB9MSS1OzU1ILUIpisDAeHkgSv7lSgTsGi1PTUirTMnBKENBMH5yFGCQ4eJRFeLpAa 3uKCxNzizHSI/ClGRSlx3k8gawVAEhmleXC9sCRxiVFWSpiXkYGBQYgHaG9uZgmq/CtGcQ5G JWFedZDxPJl5JXDTXwEtZgJavOLsA5DFJYkIKakGxubdLy0Db8d75U0KtMutOPrJ59GxWas5 LlW9EzBKXLf/rhvLV3fZCvVT07QWTKyavIL/t+nC8Fnyu41fWx+2Sd/MdtbDRP/cPq+kNXlX dEUs1O5yuai/MWNcUZPAz5S94ObzOyuuPM85v7jr37u18jURCYrZXrWHQxLm1hz7G/nwaNx/ 37vP/yixFGckGmoxFxUnAgC0Ee1rDQMAAA== x-virus-scanned: amavisd-new at amsl.com Content-Type: text/plain; charset="utf-8" Content-ID: <2DE797039428AD4996AF3232AC711D53@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 DQpEZWFyIEplb25nLWRvbmcgUnlvbywgRXJpYyBHcmF5LCBIdXViIHZhbiBIZWx2b29ydCwgQWxl c3NhbmRybyBEJ0FsZXNzYW5kcm8sIFRhZS1zaWsgQ2hldW5nLCBFcmljIE9zYm9ybmU6DQoNCiBB biBJUFIgZGlzY2xvc3VyZSB0aGF0IHBlcnRhaW5zIHRvIHlvdXIgSW50ZXJuZXQtRHJhZnQgZW50 aXRsZWQgIk1QTFMgVHJhbnNwb3J0DQpQcm9maWxlIChNUExTLVRQKSBMaW5lYXIgUHJvdGVjdGlv biB0byBNYXRjaCB0aGUgT3BlcmF0aW9uYWwgRXhwZWN0YXRpb25zIG9mDQpTREgsIE9UTiBhbmQg RXRoZXJuZXQgVHJhbnNwb3J0IE5ldHdvcmsgT3BlcmF0b3JzIiAoZHJhZnQtaWV0Zi1tcGxzLXRw LXBzYy1pdHUpDQp3YXMgc3VibWl0dGVkIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IG9uIDIwMTQt MDEtMjQgYW5kIGhhcyBiZWVuIHBvc3RlZCBvbiB0aGUNCiJJRVRGIFBhZ2Ugb2YgSW50ZWxsZWN0 dWFsIFByb3BlcnR5IFJpZ2h0cyBEaXNjbG9zdXJlcyINCihodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2lwci8yMzA2LykuIFRoZSB0aXRsZSBvZiB0aGUgSVBSIGRpc2Nsb3N1cmUgaXMNCiJI dWF3ZWkgVGVjaG5vbG9naWVzIENvLixMdGQncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQg dG8gZHJhZnQtaWV0Zi1tcGxzLQ0KdHAtcHNjLWl0dS0wMS4iIik7DQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== --_002_48E1A67CB9CA044EADFEAB87D814BFF632A03DD6eusaamb107erics_-- From eric.gray@ericsson.com Fri Jan 31 08:49:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB0D1A1F48 for ; Fri, 31 Jan 2014 08:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 29n9C8S3tS3l for ; Fri, 31 Jan 2014 08:49:24 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 170BA1A035D for ; Fri, 31 Jan 2014 08:49:24 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-28-52ebd4102684 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 2F.1F.11484.014DBE25; Fri, 31 Jan 2014 17:49:21 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Fri, 31 Jan 2014 11:49:19 -0500 From: Eric Gray To: Loa Andersson , "huubatwork@gmail.com" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt Thread-Index: AQHPGcMme00ddFIG5Em6E39ftvIY1JqdEc+AgAIApoA= Date: Fri, 31 Jan 2014 16:49:19 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632A03E8D@eusaamb107.ericsson.se> References: <20140125073602.3234.76134.idtracker@ietfa.amsl.com> <52E3A424.209@gmail.com> <52E9DD5F.9020604@pi.nu> In-Reply-To: <52E9DD5F.9020604@pi.nu> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPuK7glddBBt/6eCxmzL7MavFv7hxm i++XlrBY3Fq6ktWBxWPnrLvsHkuW/GTymDW9jc3jy+XPbAEsUVw2Kak5mWWpRfp2CVwZ//81 MRdcMKu4s/csUwPje60uRk4OCQETif6DKxkhbDGJC/fWs3UxcnEICRxhlLi+9AMLhLOcUeL0 9MksIFVsAhoSx+6sZQRJiAh0Mkr8brzN3MXIwcEsoCxx6q4MiCksECNxar0iSLmIQKzEz96V YBUiAlYSl+8UgIRZBFQlznbNApvIK+Ar0bH/CxuILSRQIrHm/h6wOCdQzZNFO8BuYwS67fup NUwgNrOAuMStJ/OZIG4WkFiy5zwzhC0q8fLxP1YIW1FiX/90doh6HYkFuz+xQdjaEssWvmaG 2CsocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGLkKC1OLctNNzLcxAiMpWMSbI47GBd8sjzE KM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxsQX7VwtU9d/r+SYbnCrdXNX caC6oFfy4xbu97fPSAZouuxYuKxDNjFuYaDJu/Mvgz9sfWw7o7XpoLZvzdHLv7/3vzexDrpQ wf73VTPjCgXevXIMF27+bW06Mn/fTibtVzbSDj7c1XMLjb8eEnoZvdDRc6bKQvnn7L+OmWbL 70qUPr79bZZJshJLcUaioRZzUXEiAAJ+F5pzAgAA Cc: "mpls@ietf.org" Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 16:49:26 -0000 Loa, As I understand it, when an Internet Draft is published as an Independent Stream RFC, the publication notice will explicitly state that the document = is not an IETF working group product. I think it might be a good idea to offer the WG a chance to try to improve= =20 the quality of the draft prior to its publication, but I also think it is i= mportant for=20 folks to realize two things: 1) Because the proposal is to publish the draft as Independent, the Authors= aren't expected to respond to or address any detailed comments on the draft i= tself; 2) There is no implicit working group endorsement to be imputed by any lack= of=20 comments on the draft itself. Hence I believe - just to be clear - you are asking only for comments on t= he decision to allow publication of the draft as an Independent Stream RFC. Is that correct? Presumably, if anyone has detailed or editorial comments on the draft, it is probably preferable for those comments to be addressed to the authors of= the draft privately... -- Eric -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, January 30, 2014 12:05 AM To: huubatwork@gmail.com; mpls-chairs@tools.ietf.org Cc: mpls@ietf.org Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-s= witching-09.txt Working Group, authors, The authors of draft-zulr-mpls-tp-linear-protection-switching (http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection- switching) are looking to publish their document as an Independent Stream RFC. The MPLS Working Group was informed about this on the MPLS working group mailing (see below). The MPLS Working Group decided to progress a Proposed Standard RFC for MPLS-TP Linear protection Switching (RFC 6378). This is still the Working Group consensus. Further there is work-in-progress to update RFC 6378 to match the functionality of APS. However it is a long standing tradition to publish documents that were not progressed as working group RFCs, particularly if they have been implemented and deployed. This for example is done for the historic record and due to the value of documenting deployed solutions. This is the case with draft-zulr-mpls-tp-linear-protection-switching. The document clearly states that IETF Standard Track MPLS-TP Linear Protection is specified in RFC 6378. It also states that the protocol specified in the draft is a non-IETF pre-standard protocol. The MPLS working group chairs are therefore not opposed to the publication of the document as an RFC on the Independent Stream. The Working Group chairs invite the working group to comment on this, please send comments to the working group mailing list (mpls@ietf.org). The MPLS Working Group Chairs Loa, Ross and George On 2014-01-25 19:46, Huub van Helvoort wrote: > Dear WG chairs, > > The authors of draft-zulr-mpls-tp-linear-protection-switching > have decided to publish the document on the independent stream > as an informational RFC. > > Because it documents the pre-standard implementation of MPLS-TP > linear protection that has been deployed by several network > operators using equipment from multiple vendors. > At the time of publication these pre-standard implementations > were still in operation carrying live traffic. > > Best regards, Huub van Helvoort. > > > -------- Original Message -------- > Subject: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.tx= t > Date: Fri, 24 Jan 2014 23:36:02 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Pre-standard Linear Protection Switching in > MPLS-TP > Authors : Huub van Helvoort > Jeong-dong Ryoo > Haiyan Zhang > Feng Huang > Han Li > Alessandro D'Alessandro > Filename : > draft-zulr-mpls-tp-linear-protection-switching-09.txt > Pages : 27 > Date : 2014-01-24 > > Abstract: > The IETF Standards Track solution for MPLS Transport Profile (MPLS- > TP) Linear Protection is provided in RFC 6378, draft-ietf-mpls-psc- > updates and draft-ietf- mpls-tp-psc-itu. > > This document describes the pre-standard implementation of MPLS-TP > Linear Protection that has been deployed by several network operators > using equipment from multiple vendors. At the time of publication > these pre-standard implementations were still in operation carrying > live traffic." > > The specified mechanism supports 1+1 unidirectional/bidirectional > protection switching and 1:1 bidirectional protection switching. It > is purely supported by MPLS-TP data plane, and can work without any > control plane. > > This document is a product of a joint Internet Engineering Task Force > (IETF) / International Telecommunications Union Telecommunications > Standardization Sector (ITU-T) effort to include an MPLS Transport > Profile within the IETF MPLS and PWE3 architectures to support the > capabilities and functionalities of a packet transport network as > defined by the ITU-T. > > [Editor's note] To be included in "Status of Memo": This document is > not an Internet Standards Track specification; it is published for > informational purposes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-zulr-mpls-tp-linear-protection-swi= tching/ > > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection-switching= -09 > > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-zulr-mpls-tp-linear-protection-s= witching-09 > > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Fri Jan 31 09:34:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161821A03EC for ; Fri, 31 Jan 2014 09:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 7xp0btiGZ7zG for ; Fri, 31 Jan 2014 09:34:20 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6D46B1A03E7 for ; Fri, 31 Jan 2014 09:34:20 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0VHY8U5082068; Fri, 31 Jan 2014 12:34:09 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401311734.s0VHY8U5082068@maildrop2.v6ds.occnc.com> To: Eric Gray From: Curtis Villamizar In-reply-to: Your message of "Fri, 31 Jan 2014 16:49:19 +0000." <48E1A67CB9CA044EADFEAB87D814BFF632A03E8D@eusaamb107.ericsson.se> Date: Fri, 31 Jan 2014 12:34:08 -0500 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "huubatwork@gmail.com" Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:34:23 -0000 See inline. In message <48E1A67CB9CA044EADFEAB87D814BFF632A03E8D@eusaamb107.ericsson.se> Eric Gray writes: > > Loa, > > As I understand it, when an Internet Draft is published as an > Independent Stream RFC, the publication notice will explicitly state > that the document is not an IETF working group product. > > I think it might be a good idea to offer the WG a chance to > try to improve the quality of the draft prior to its publication, but > I also think it is important for folks to realize two things: > > 1) Because the proposal is to publish the draft as Independent, the > Authors aren't expected to respond to or address any detailed > comments on the draft itself; 2) There is no implicit working > group endorsement to be imputed by any lack of comments on the > draft itself. > > Hence I believe - just to be clear - you are asking only for > comments on the decision to allow publication of the draft as an > Independent Stream RFC. > > Is that correct? > > Presumably, if anyone has detailed or editorial comments on > the draft, it is probably preferable for those comments to be > addressed to the authors of the draft privately... > > -- > Eric > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, January 30, 2014 12:05 AM > To: huubatwork@gmail.com; mpls-chairs@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt > > Working Group, authors, > > The authors of draft-zulr-mpls-tp-linear-protection-switching > (http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection- > switching) are looking to publish their document as an Independent > Stream RFC. The MPLS Working Group was informed about this on the > MPLS working group mailing (see below). > > > The MPLS Working Group decided to progress a Proposed Standard RFC for > MPLS-TP Linear protection Switching (RFC 6378). This is still the > Working Group consensus. Further there is work-in-progress to update > RFC 6378 to match the functionality of APS. > > However it is a long standing tradition to publish documents that were > not progressed as working group RFCs, particularly if they have been > implemented and deployed. This for example is done for the historic > record and due to the value of documenting deployed solutions. > > This is the case with draft-zulr-mpls-tp-linear-protection-switching. > The document clearly states that IETF Standard Track MPLS-TP Linear > Protection is specified in RFC 6378. It also states that the protocol > specified in the draft is a non-IETF pre-standard protocol. > > The MPLS working group chairs are therefore not opposed to the > publication of the document as an RFC on the Independent Stream. > > The Working Group chairs invite the working group to comment on this, > please send comments to the working group mailing list (mpls@ietf.org). > > The MPLS Working Group Chairs > Loa, Ross and George > > > On 2014-01-25 19:46, Huub van Helvoort wrote: > > Dear WG chairs, > > > > The authors of draft-zulr-mpls-tp-linear-protection-switching > > have decided to publish the document on the independent stream > > as an informational RFC. > > > > Because it documents the pre-standard implementation of MPLS-TP > > linear protection that has been deployed by several network > > operators using equipment from multiple vendors. > > At the time of publication these pre-standard implementations > > were still in operation carrying live traffic. > > > > Best regards, Huub van Helvoort. > > > > > > -------- Original Message -------- > > Subject: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt > > Date: Fri, 24 Jan 2014 23:36:02 -0800 > > From: internet-drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Pre-standard Linear Protection Switching in > > MPLS-TP > > Authors : Huub van Helvoort > > Jeong-dong Ryoo > > Haiyan Zhang > > Feng Huang > > Han Li > > Alessandro D'Alessandro > > Filename : > > draft-zulr-mpls-tp-linear-protection-switching-09.txt > > Pages : 27 > > Date : 2014-01-24 > > > > Abstract: > > The IETF Standards Track solution for MPLS Transport Profile (MPLS- > > TP) Linear Protection is provided in RFC 6378, draft-ietf-mpls-psc- > > updates and draft-ietf- mpls-tp-psc-itu. > > > > This document describes the pre-standard implementation of MPLS-TP > > Linear Protection that has been deployed by several network operators > > using equipment from multiple vendors. At the time of publication > > these pre-standard implementations were still in operation carrying > > live traffic." > > > > The specified mechanism supports 1+1 unidirectional/bidirectional > > protection switching and 1:1 bidirectional protection switching. It > > is purely supported by MPLS-TP data plane, and can work without any > > control plane. > > > > This document is a product of a joint Internet Engineering Task Force > > (IETF) / International Telecommunications Union Telecommunications > > Standardization Sector (ITU-T) effort to include an MPLS Transport > > Profile within the IETF MPLS and PWE3 architectures to support the > > capabilities and functionalities of a packet transport network as > > defined by the ITU-T. The above paragraph is not true since this is not a product of an IETF WG nor is it related to the agreed upon process between ITU-T and IETF. Therefore the paragraph should be removed. > > [Editor's note] To be included in "Status of Memo": This document is > > not an Internet Standards Track specification; it is published for > > informational purposes. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-zulr-mpls-tp-linear-protection-switching/ > > > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection-switching-09 > > > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-zulr-mpls-tp-linear-protection-switching-09 > > > > > > > > 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.vorg. From eric.gray@ericsson.com Fri Jan 31 09:48:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039F41A1F5F for ; Fri, 31 Jan 2014 09:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALmXYW90Piop for ; Fri, 31 Jan 2014 09:48:49 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4690E1A1F5E for ; Fri, 31 Jan 2014 09:48:49 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-de-52ebe1fd2715 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C1.82.11484.EF1EBE25; Fri, 31 Jan 2014 18:48:46 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0387.000; Fri, 31 Jan 2014 12:48:45 -0500 From: Eric Gray To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt Thread-Index: AQHPHqqvoaWUGqo4PkejRIdwqdGLkJqfG/Zw Date: Fri, 31 Jan 2014 17:48:44 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632A03F7D@eusaamb107.ericsson.se> References: Your message of "Fri, 31 Jan 2014 16:49:19 +0000." <48E1A67CB9CA044EADFEAB87D814BFF632A03E8D@eusaamb107.ericsson.se> <201401311734.s0VHY8U5082068@maildrop2.v6ds.occnc.com> In-Reply-To: <201401311734.s0VHY8U5082068@maildrop2.v6ds.occnc.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPlO6/h6+DDCb8EbGYPOsMm8WM2ZdZ Lf7NncNs8f3SEhaLW0tXsjqweuycdZfdY8mSn0wey+5fZPOYNb2NzePL5c9sAaxRXDYpqTmZ ZalF+nYJXBndR1vZC1ZZVhx818zewLhPp4uRk0NCwETi/4KF7BC2mMSFe+vZuhi5OIQEjjBK 7Dy5ghEkISSwnFFi/31NEJtNQEPi2J21YHERAWOJv213wRqYBdYwSizf+gpskrBAjMSnp7eg imIlLr9uY4KwjST2P54KFmcRUJVYfPE2UDMHB6+Ar8Tr55YQi48zSrRfuwBWwyngLPH5yQQ2 EJsR6Lrvp9aAzWEWEJe49WQ+E8TVAhJL9pxnhrBFJV4+/scKYStK7Oufzg5RryOxYPcnNghb W2LZwtdg9bwCghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRo7S4tSy3HQjw02MwBg7JsHm uINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamA06/ZeFtbe9JdN /Mo9ix5mD8dHRY3BsefyqmL+2Jz8e+SCov/3M3tPNbzhsFk5je0jd8FDhZoCW93V1XtqdecG Xi1qLzD2MWxTd39t167AOv/B8h61kFec7MYXHr82+v9j92vb1pbIKZ1VM3qWtB7eylT+pWm5 narwu12ro758r/K81v6J84cSS3FGoqEWc1FxIgDBb9rjfwIAAA== Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "huubatwork@gmail.com" Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:48:52 -0000 Good catch, Curtis! -- Eric -----Original Message----- From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]=20 Sent: Friday, January 31, 2014 12:34 PM To: Eric Gray Cc: Loa Andersson; huubatwork@gmail.com; mpls-chairs@tools.ietf.org; mpls@i= etf.org Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-s= witching-09.txt Importance: High See inline. In message <48E1A67CB9CA044EADFEAB87D814BFF632A03E8D@eusaamb107.ericsson.se= > Eric Gray writes: >=20 > Loa, > =20 > As I understand it, when an Internet Draft is published as an > Independent Stream RFC, the publication notice will explicitly state > that the document is not an IETF working group product. > =20 > I think it might be a good idea to offer the WG a chance to > try to improve the quality of the draft prior to its publication, but > I also think it is important for folks to realize two things: > =20 > 1) Because the proposal is to publish the draft as Independent, the > Authors aren't expected to respond to or address any detailed > comments on the draft itself; 2) There is no implicit working > group endorsement to be imputed by any lack of comments on the > draft itself. > =20 > Hence I believe - just to be clear - you are asking only for > comments on the decision to allow publication of the draft as an > Independent Stream RFC. > =20 > Is that correct? > =20 > Presumably, if anyone has detailed or editorial comments on > the draft, it is probably preferable for those comments to be > addressed to the authors of the draft privately... > =20 > -- > Eric > =20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, January 30, 2014 12:05 AM > To: huubatwork@gmail.com; mpls-chairs@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection= -switching-09.txt > =20 > Working Group, authors, > =20 > The authors of draft-zulr-mpls-tp-linear-protection-switching > (http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection- > switching) are looking to publish their document as an Independent > Stream RFC. The MPLS Working Group was informed about this on the > MPLS working group mailing (see below). > =20 > =20 > The MPLS Working Group decided to progress a Proposed Standard RFC for > MPLS-TP Linear protection Switching (RFC 6378). This is still the > Working Group consensus. Further there is work-in-progress to update > RFC 6378 to match the functionality of APS. > =20 > However it is a long standing tradition to publish documents that were > not progressed as working group RFCs, particularly if they have been > implemented and deployed. This for example is done for the historic > record and due to the value of documenting deployed solutions. > =20 > This is the case with draft-zulr-mpls-tp-linear-protection-switching. > The document clearly states that IETF Standard Track MPLS-TP Linear > Protection is specified in RFC 6378. It also states that the protocol > specified in the draft is a non-IETF pre-standard protocol. > =20 > The MPLS working group chairs are therefore not opposed to the > publication of the document as an RFC on the Independent Stream. > =20 > The Working Group chairs invite the working group to comment on this, > please send comments to the working group mailing list (mpls@ietf.org). > =20 > The MPLS Working Group Chairs > Loa, Ross and George > =20 > =20 > On 2014-01-25 19:46, Huub van Helvoort wrote: > > Dear WG chairs, > > > > The authors of draft-zulr-mpls-tp-linear-protection-switching > > have decided to publish the document on the independent stream > > as an informational RFC. > > > > Because it documents the pre-standard implementation of MPLS-TP > > linear protection that has been deployed by several network > > operators using equipment from multiple vendors. > > At the time of publication these pre-standard implementations > > were still in operation carrying live traffic. > > > > Best regards, Huub van Helvoort. > > > > > > -------- Original Message -------- > > Subject: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.= txt > > Date: Fri, 24 Jan 2014 23:36:02 -0800 > > From: internet-drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Pre-standard Linear Protection Switching in > > MPLS-TP > > Authors : Huub van Helvoort > > Jeong-dong Ryoo > > Haiyan Zhang > > Feng Huang > > Han Li > > Alessandro D'Alessandro > > Filename : > > draft-zulr-mpls-tp-linear-protection-switching-09.txt > > Pages : 27 > > Date : 2014-01-24 > > > > Abstract: > > The IETF Standards Track solution for MPLS Transport Profile (MPLS- > > TP) Linear Protection is provided in RFC 6378, draft-ietf-mpls-psc- > > updates and draft-ietf- mpls-tp-psc-itu. > > > > This document describes the pre-standard implementation of MPLS-TP > > Linear Protection that has been deployed by several network operato= rs > > using equipment from multiple vendors. At the time of publication > > these pre-standard implementations were still in operation carrying > > live traffic." > > > > The specified mechanism supports 1+1 unidirectional/bidirectional > > protection switching and 1:1 bidirectional protection switching. I= t > > is purely supported by MPLS-TP data plane, and can work without any > > control plane. > > > > This document is a product of a joint Internet Engineering Task For= ce > > (IETF) / International Telecommunications Union Telecommunications > > Standardization Sector (ITU-T) effort to include an MPLS Transport > > Profile within the IETF MPLS and PWE3 architectures to support the > > capabilities and functionalities of a packet transport network as > > defined by the ITU-T. The above paragraph is not true since this is not a product of an IETF WG nor is it related to the agreed upon process between ITU-T and IETF. Therefore the paragraph should be removed. > > [Editor's note] To be included in "Status of Memo": This document i= s > > not an Internet Standards Track specification; it is published for > > informational purposes. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-zulr-mpls-tp-linear-protection-s= witching/ > > > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection-switchi= ng-09 > > > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-zulr-mpls-tp-linear-protection= -switching-09 > > > > > > > > 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.vorg. From huubatwork@gmail.com Fri Jan 31 09:54:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74091A1F48 for ; Fri, 31 Jan 2014 09:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 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, MISSING_HEADERS=1.021, 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 MX2yjnMfE_2J for ; Fri, 31 Jan 2014 09:54:51 -0800 (PST) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5EED81A043A for ; Fri, 31 Jan 2014 09:54:51 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id z10so2481065ead.6 for ; Fri, 31 Jan 2014 09:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=zNzTNlQEgKDarAAzqSiFytYe4aosyuApgao/SEnWtqo=; b=Arv8uzU5m2XOCwid4jzp0qf+cMmbUeE5GKazBd7hiCmW8pJCd6JCsO9MvOM7FoBljl wPx+RHo5UJbHRo7U2g7xyUx03ja8eK12NhrlGoR+3h+tajbTyOh4z5Y7LMf16NowGK3I Cqqni4CjUtPZYe03kjU1pQUoi5nEim1+Mrwbqv+uYOOeTaYjlym1UcBcZ4Di3YkHrVYv Z8/OpY55OmG+J1L82TRqbTjKXeSiaPr+d3baMSFuUFDNVaXfqTyO8QbbLIkUWO8GzRLT rkEr1efWd0YsDUgUpdccDERrCONrAS78ThBzrkAivxo+BHAWRPjT2ZQ4jP+CiFKOivRK teTw== X-Received: by 10.15.42.136 with SMTP id u8mr20779801eev.52.1391190887159; Fri, 31 Jan 2014 09:54:47 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id 8sm33933181eef.1.2014.01.31.09.54.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 09:54:46 -0800 (PST) Message-ID: <52EBE365.8000504@gmail.com> Date: Fri, 31 Jan 2014 18:54:45 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 References: <201401311734.s0VHY8U5082068@maildrop2.v6ds.occnc.com> In-Reply-To: <201401311734.s0VHY8U5082068@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:54:52 -0000 Curtis, You wrote: ---8<--- >>> This document is a product of a joint Internet Engineering Task Force >>> (IETF) / International Telecommunications Union Telecommunications >>> Standardization Sector (ITU-T) effort to include an MPLS Transport >>> Profile within the IETF MPLS and PWE3 architectures to support the >>> capabilities and functionalities of a packet transport network as >>> defined by the ITU-T. > > The above paragraph is not true since this is not a product of an IETF > WG nor is it related to the agreed upon process between ITU-T and > IETF. Therefore the paragraph should be removed. The authors have already noticed this. The paragraph will have been removed in the next version. Regards, Huub. From loa@pi.nu Fri Jan 31 10:35:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415AB1A1F5F for ; Fri, 31 Jan 2014 10:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 0hKg7muzX_3a for ; Fri, 31 Jan 2014 10:35:03 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id DF3271A046F for ; Fri, 31 Jan 2014 10:35:02 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.101.14]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 7009C180150F; Fri, 31 Jan 2014 19:34:57 +0100 (CET) Message-ID: <52EBECCB.5030705@pi.nu> Date: Sat, 01 Feb 2014 02:34:51 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Gray , "huubatwork@gmail.com" , "mpls-chairs@tools.ietf.org" References: <20140125073602.3234.76134.idtracker@ietfa.amsl.com> <52E3A424.209@gmail.com> <52E9DD5F.9020604@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF632A03E8D@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632A03E8D@eusaamb107.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 18:35:07 -0000 Eric, The working group chairs has discussed the information we had from the document authors. We found that we have no reason to try to stop the publication of the document as an Independent Stream RFC. We also say that if any want to comment on that they are welcome to do so on the mpls wg mailing list. If anyone have technical or other comments on the draft they definitely should send them to the authors, and as for that this is of interest for the working group also copy the list. However since the document is reflecting what has been implemented and deployed there is not much idea to discuss technical improvements of the solution as such, it is what it is. /Loa mpls wg co-chair On 2014-02-01 00:49, Eric Gray wrote: > Loa, > > As I understand it, when an Internet Draft is published as an Independent > Stream RFC, the publication notice will explicitly state that the document is not an > IETF working group product. > > I think it might be a good idea to offer the WG a chance to try to improve > the quality of the draft prior to its publication, but I also think it is important for > folks to realize two things: > > 1) Because the proposal is to publish the draft as Independent, the Authors aren't > expected to respond to or address any detailed comments on the draft itself; > 2) There is no implicit working group endorsement to be imputed by any lack of > comments on the draft itself. > > Hence I believe - just to be clear - you are asking only for comments on the > decision to allow publication of the draft as an Independent Stream RFC. > > Is that correct? > > Presumably, if anyone has detailed or editorial comments on the draft, it > is probably preferable for those comments to be addressed to the authors of the > draft privately... > > -- > Eric > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, January 30, 2014 12:05 AM > To: huubatwork@gmail.com; mpls-chairs@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt > > Working Group, authors, > > The authors of draft-zulr-mpls-tp-linear-protection-switching > (http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection- > switching) are looking to publish their document as an Independent > Stream RFC. The MPLS Working Group was informed about this on the > MPLS working group mailing (see below). > > > The MPLS Working Group decided to progress a Proposed Standard RFC for > MPLS-TP Linear protection Switching (RFC 6378). This is still the > Working Group consensus. Further there is work-in-progress to update > RFC 6378 to match the functionality of APS. > > However it is a long standing tradition to publish documents that were > not progressed as working group RFCs, particularly if they have been > implemented and deployed. This for example is done for the historic > record and due to the value of documenting deployed solutions. > > This is the case with draft-zulr-mpls-tp-linear-protection-switching. > The document clearly states that IETF Standard Track MPLS-TP Linear > Protection is specified in RFC 6378. It also states that the protocol > specified in the draft is a non-IETF pre-standard protocol. > > The MPLS working group chairs are therefore not opposed to the > publication of the document as an RFC on the Independent Stream. > > The Working Group chairs invite the working group to comment on this, > please send comments to the working group mailing list (mpls@ietf.org). > > The MPLS Working Group Chairs > Loa, Ross and George > > > On 2014-01-25 19:46, Huub van Helvoort wrote: >> Dear WG chairs, >> >> The authors of draft-zulr-mpls-tp-linear-protection-switching >> have decided to publish the document on the independent stream >> as an informational RFC. >> >> Because it documents the pre-standard implementation of MPLS-TP >> linear protection that has been deployed by several network >> operators using equipment from multiple vendors. >> At the time of publication these pre-standard implementations >> were still in operation carrying live traffic. >> >> Best regards, Huub van Helvoort. >> >> >> -------- Original Message -------- >> Subject: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt >> Date: Fri, 24 Jan 2014 23:36:02 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Pre-standard Linear Protection Switching in >> MPLS-TP >> Authors : Huub van Helvoort >> Jeong-dong Ryoo >> Haiyan Zhang >> Feng Huang >> Han Li >> Alessandro D'Alessandro >> Filename : >> draft-zulr-mpls-tp-linear-protection-switching-09.txt >> Pages : 27 >> Date : 2014-01-24 >> >> Abstract: >> The IETF Standards Track solution for MPLS Transport Profile (MPLS- >> TP) Linear Protection is provided in RFC 6378, draft-ietf-mpls-psc- >> updates and draft-ietf- mpls-tp-psc-itu. >> >> This document describes the pre-standard implementation of MPLS-TP >> Linear Protection that has been deployed by several network operators >> using equipment from multiple vendors. At the time of publication >> these pre-standard implementations were still in operation carrying >> live traffic." >> >> The specified mechanism supports 1+1 unidirectional/bidirectional >> protection switching and 1:1 bidirectional protection switching. It >> is purely supported by MPLS-TP data plane, and can work without any >> control plane. >> >> This document is a product of a joint Internet Engineering Task Force >> (IETF) / International Telecommunications Union Telecommunications >> Standardization Sector (ITU-T) effort to include an MPLS Transport >> Profile within the IETF MPLS and PWE3 architectures to support the >> capabilities and functionalities of a packet transport network as >> defined by the ITU-T. >> >> [Editor's note] To be included in "Status of Memo": This document is >> not an Internet Standards Track specification; it is published for >> informational purposes. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-zulr-mpls-tp-linear-protection-switching/ >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-zulr-mpls-tp-linear-protection-switching-09 >> >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-zulr-mpls-tp-linear-protection-switching-09 >> >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Fri Jan 31 11:14:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498381A1F78; Fri, 31 Jan 2014 11:14:08 -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 NY8uCHrNCP6D; Fri, 31 Jan 2014 11:14:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D142E1A1F5F; Fri, 31 Jan 2014 11:14:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140131191406.9155.36365.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 11:14:06 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 19:14:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Requirements for MPLS Shared Mesh Protection Authors : Yaacov Weingarten Sam Aldrin Ping Pan Jeong-dong Ryoo Greg Mirsky Filename : draft-ietf-mpls-smp-requirements-03.txt Pages : 13 Date : 2014-01-31 Abstract: This document presents the basic network objectives for the behavior of shared mesh protection (SMP) not based on control-plane support. This is an expansion of the basic requirements presented in the MPLS Transport Profile Requirements (RFC5654) and MPLS Transport Profile Survivability Framework (RFC6372) documents. This document is to be used as a basis for the definition of any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate executive action for resiliency to the data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-smp-requirements-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-smp-requirements-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 kishoret@juniper.net Fri Jan 31 18:06:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A31F1ACCE9 for ; Fri, 31 Jan 2014 18:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 dW2ZOArWRiDI for ; Fri, 31 Jan 2014 18:06:07 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 48ADC1ACCE3 for ; Fri, 31 Jan 2014 18:06:07 -0800 (PST) Received: from mail163-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Sat, 1 Feb 2014 02:06:03 +0000 Received: from mail163-tx2 (localhost [127.0.0.1]) by mail163-tx2-R.bigfish.com (Postfix) with ESMTP id 2952F401C1 for ; Sat, 1 Feb 2014 02:06:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -12 X-BigFish: VPS-12(z579ehz9371I936eI542I4015Iddf5rzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h9a9j1155h) Received-SPF: pass (mail163-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kishoret@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(189002)(199002)(377424004)(377454003)(13464003)(74366001)(74876001)(74316001)(15202345003)(92566001)(79102001)(93516002)(47976001)(63696002)(19580395003)(4396001)(65816001)(66066001)(46102001)(2656002)(80976001)(15975445006)(19580405001)(33646001)(74662001)(83322001)(81542001)(87936001)(93136001)(74706001)(77982001)(69226001)(54356001)(86362001)(76482001)(56776001)(53806001)(51856001)(94316002)(54316002)(76786001)(50986001)(81342001)(83072002)(81686001)(90146001)(76576001)(85852003)(76796001)(81816001)(56816005)(85306002)(49866001)(47736001)(94946001)(59766001)(47446002)(87266001)(74502001)(31966008)(80022001)(568214004)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB685; H:DM2PR05MB686.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail163-tx2 (localhost.localdomain [127.0.0.1]) by mail163-tx2 (MessageSwitch) id 1391220360816569_28370; Sat, 1 Feb 2014 02:06:00 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.242]) by mail163-tx2.bigfish.com (Postfix) with ESMTP id B049AE006F for ; Sat, 1 Feb 2014 02:06:00 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 1 Feb 2014 02:05:54 +0000 Received: from DM2PR05MB685.namprd05.prod.outlook.com (10.141.176.145) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Sat, 1 Feb 2014 02:05:52 +0000 Received: from DM2PR05MB686.namprd05.prod.outlook.com (10.141.176.147) by DM2PR05MB685.namprd05.prod.outlook.com (10.141.176.145) with Microsoft SMTP Server (TLS) id 15.0.859.15; Sat, 1 Feb 2014 02:05:51 +0000 Received: from DM2PR05MB686.namprd05.prod.outlook.com ([10.141.176.147]) by DM2PR05MB686.namprd05.prod.outlook.com ([10.141.176.147]) with mapi id 15.00.0859.020; Sat, 1 Feb 2014 02:05:50 +0000 From: Kishore Tiruveedhula To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-tiruveedhula-mpls-mldp-mib-01.txt Thread-Index: AQHPHtHD1nJ62n3k4kKscxF9YbBGgpqfoAtg Date: Sat, 1 Feb 2014 02:05:50 +0000 Message-ID: <1e2e69a298fd4dcc89e6e547b2f0f7ae@DM2PR05MB686.namprd05.prod.outlook.com> References: <20140131221359.10614.89852.idtracker@ietfa.amsl.com> In-Reply-To: <20140131221359.10614.89852.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 0109D382B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Kishore Tiruveedhula Subject: [mpls] FW: New Version Notification for draft-tiruveedhula-mpls-mldp-mib-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 02:06:09 -0000 SGksDQogIFdlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IChodHRwOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LXRpcnV2ZWVkaHVsYS1tcGxzLW1sZHAtbWliLTAxLnR4dCkgdGhhdCBkZXNjcmli ZXMgdGhlIG1MRFAgTUlCLg0KV2Ugd291bGQgYXBwcmVjaWF0ZSB5b3VyIGZlZWRiYWNrIGFuZCBh bnkgY29tbWVudHMgb24gdGhpcyBkcmFmdC4NCg0KVGhhbmtzLA0KS2lzaG9yZQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgSmFudWFyeSAzMSwg MjAxNCA1OjE0IFBNDQpUbzogS2lzaG9yZSBUaXJ1dmVlZGh1bGE7IEV4dCAtIFV3ZS5Kb29yZGVA dGVsZWtvbS5kZTsgRXh0IC0gVXdlLkpvb3JkZUB0ZWxla29tLmRlOyBLaXNob3JlIFRpcnV2ZWVk aHVsYQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10aXJ1dmVl ZGh1bGEtbXBscy1tbGRwLW1pYi0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtdGlydXZlZWRodWxhLW1wbHMtbWxkcC1taWItMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEtpc2hvcmUgVGlydXZlZWRodWxhIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXRpcnV2ZWVkaHVsYS1tcGxzLW1sZHAtbWli DQpSZXZpc2lvbjoJMDENClRpdGxlOgkJRGVmaW5pdGlvbnMgb2YgTWFuYWdlZCBPYmplY3RzIGZv ciB0aGUgTERQIFBvaW50LXRvLU11bHRpcG9pbnQgYW5kIE11bHRpcG9pbnQtdG8tTXVsdGlwb2lu dCBMYWJlbCBTd2l0Y2hlZCBQYXRocw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wMS0zMQ0KR3JvdXA6 CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJNDANClVSTDogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10aXJ1dmVlZGh1bGEtbXBscy1t bGRwLW1pYi0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC10aXJ1dmVlZGh1bGEtbXBscy1tbGRwLW1pYi8NCkh0bWxpemVkOiAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aXJ1dmVlZGh1bGEtbXBscy1tbGRw LW1pYi0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LXRpcnV2ZWVkaHVsYS1tcGxzLW1sZHAtbWliLTAxDQoNCkFic3RyYWN0Og0KICAgVGhp cyBtZW1vIGRlZmluZXMgYSBwb3J0aW9uIG9mIHRoZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJh c2UgKE1JQikNCiAgIGZvciB1c2Ugd2l0aCBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xzLiAg SW4gcGFydGljdWxhciBpdCBkZWZpbmVzDQogICBvYmplY3RzIGZvciBtYW5hZ2luZyBtdWx0aWNh c3QgTERQIHBvaW50LXRvLW11bHRpcG9pbnQgKFAyTVApIGFuZA0KICAgbXVsdGlwb2ludC10by1t dWx0aXBvaW50IChNUDJNUCkgTGFiZWwgU3dpdGNoZWQgUGF0aHMuICBUaGUgTUlCDQogICBtb2R1 bGUgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIGV4dGVuc2lvbiBvZiBMRFAgTUlCIGRlZmlu ZWQgaW4NCiAgIFJGQzM4MTUgd2hpY2ggc3VwcG9ydHMgb25seSBmb3IgTERQIHBvaW50LXRvLXBv aW50IExTUHMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQo= From ietf-secretariat-reply@ietf.org Fri Jan 31 20:55:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82ED1A052D for ; Fri, 31 Jan 2014 20:55:14 -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 WzYlp492G3GU for ; Fri, 31 Jan 2014 20:55:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9981A052F for ; Fri, 31 Jan 2014 20:55:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140201045513.11650.41980.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 20:55:13 -0800 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 04:55:14 -0000 Changed milestone "Submit draft-ietf-mpls-seamless-mpls for publication", set due date to March 2014 from January 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Fri Jan 31 21:10:15 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD611A04E0 for ; Fri, 31 Jan 2014 21:10: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 TVu_u5bmnf7u for ; Fri, 31 Jan 2014 21:10:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8731A0530 for ; Fri, 31 Jan 2014 21:10:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140201051013.17027.5937.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 21:10:13 -0800 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 05:10:15 -0000 Changed milestone "Submit draft-ietf-mpls-tp-te-mib for publication", set due date to April 2014 from January 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Fri Jan 31 21:15:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490AB1A0530 for ; Fri, 31 Jan 2014 21:15:59 -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 1GzwIzCakxdA for ; Fri, 31 Jan 2014 21:15:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9391A0534 for ; Fri, 31 Jan 2014 21:15:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140201051557.14717.30613.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 21:15:57 -0800 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 05:15:59 -0000 Changed milestone "Submit draft-ietf-mpls-ldp-dod for publication", resolved as "Done". Changed milestone "Submit draft-ietf-mpls-tp-oam-id-mib for publication", set due date to May 2014 from January 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Fri Jan 31 21:21:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE121A045A for ; Fri, 31 Jan 2014 21:21: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] 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 CA4I_HuCTMRv for ; Fri, 31 Jan 2014 21:21:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A09431A0530 for ; Fri, 31 Jan 2014 21:21:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140201052154.12664.10312.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 21:21:54 -0800 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 05:21:57 -0000 Changed milestone "Submit draft-ietf-mpls-ldp-ipv6 for publication", set due date to May 2014 from December 2013. URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Fri Jan 31 21:27:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4381A0459 for ; Fri, 31 Jan 2014 21:27:37 -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 YB_xZkeW0tdQ for ; Fri, 31 Jan 2014 21:27:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 235431A052F for ; Fri, 31 Jan 2014 21:27:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140201052735.9977.16996.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 21:27:35 -0800 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 05:27:38 -0000 Changed milestone "Submit draft-ietf-mpls-smp-requirements for publication", set due date to April 2014 from January 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/