From ryoo@etri.re.kr Sun Dec 1 17:42:24 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 EEF791ADF72 for ; Sun, 1 Dec 2013 17:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWsYnPrj9J2H for ; Sun, 1 Dec 2013 17:42:20 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3781ADF60 for ; Sun, 1 Dec 2013 17:42:20 -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; Mon, 2 Dec 2013 10:42:13 +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, 2 Dec 2013 10:42:07 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] "opertor" in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHO7MG5MoNo5Ie5+EqGd7NBQarCh5pAI/6+ Date: Mon, 2 Dec 2013 01:42:06 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB368@SMTP2.etri.info> References: <52982260.2020304@pi.nu> In-Reply-To: <52982260.2020304@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_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB368SMTP2etriinfo_" MIME-Version: 1.0 Subject: Re: [mpls] "opertor" 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: Mon, 02 Dec 2013 01:42:24 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB368SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLCB0aGFua3MgZm9yIHRoZSBjb21tZW50cywNCg0KV2hpbGUgSSBhZ3JlZSB3aXRoIHlvdXIg cG9pbnRzLCBJIGRvbid0IHRoaW5rIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgbmV0d29yayBv cGVyYXRpb24gcHJvY2VkdXJlcyBmb3IgTVBMUy1UUCBuZXR3b3Jrcy4NClRoZXJlZm9yZSwgSSB3 b3VsZCBsaWtlIHRvIHByb3Bvc2UgdG8gY2hhbmdlIHRoZSBsYXN0IHNlbnRlbmNlIG9mIHlvdXIg c3VnZ2VzdGVkIG5ldyB0ZXh0IGFzIGZvbGxvd3M6DQoiRm9yIHRyYW5zcG9ydCBuZXR3b3JrIG9w ZXJhdG9ycyBhY2N1c3RvbWVkDQp0byB0aGUgb3BlcmF0aW9uYWwgcHJvY2VkdXJlcyBmb3IgT3B0 aWNhbCBhbmQgRXRoZXJuZXQgdHJhbnNwb3J0DQpuZXR3b3JrcyB0aGlzIGRvY3VtZW50IGRlZmlu ZXMgdGhlIHByb3RvY29sIG9wZXJhdGlvbnMgYW5kIG1lY2hhbmlzbXMNCnRoYXQgcmVzdWx0IGlu IHRoZSBzYW1lIG5ldHdvcmsgb3BlcmF0aW9uIHByb2NlZHVyZXMgZm9yIE1QTFMtVFAgbmV0d29y a3MuIg0KVGhlIG90aGVyIHNlbnRlbmNlcyBhcmUgb2sgd2l0aCBtZS4NCg0KQmVzdCByZWdhcmRz LA0KDQpKZW9uZy1kb25nDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbSA6ICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51Pg0KU2VudCA6IDIwMTMtMTEtMjkgMTQ6 MTM6MjEgKCArMDk6MDAgKQ0KVG8gOiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPiwgZHJh ZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcgPGRyYWZ0LWlldGYtbXBscy10 cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPiwgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgPG1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KQ2MgOg0KU3ViamVjdCA6IFttcGxzXSAib3BlcnRv ciIgaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCg0KDQpBdXRob3JzL0VkaXRvcnMsDQoN ClNlY3Rpb24gNC4xIG9mIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAwIHVzZXMgdGhlIHRl cm0gIm5ldHdvcmsNCm9wZXJhdG9yIiBpbiBhIHdheSB0aGF0IG1ha2VzIHRoZSByZWFkZXIgdGhp bmsgdGhhdCB0aGlzIGlzIHRydWUgZm9yDQpldmVyeSBuZXR3b3JrIG9wZXJhdG9yLg0KDQoiLi4u LCBmb3IgbmV0d29yayBvcGVyYXRvcnMgaXQgaXMNCmltcG9ydGFudCB0aGF0IHRoZSBNUExTLVRQ IHByb3RlY3Rpb24gc3dpdGNoaW5nIHByZXNlcnZlcyB0aGUgbmV0d29yaw0Kb3BlcmF0aW9uIGJl aGF2aW9yIHRvIHdoaWNoIG5ldHdvcmsgb3BlcmF0b3JzIGhhdmUgYmVjb21lIGFjY3VzdG9tZWQu Ig0KDQpBZG1pdHRlZGx5ICJ0cmFuc3BvcnQgbmV0d29yayBvcGVyYXRvcnMiIGFyZSBhIHN1ZmZp Y2llbnRseSBsYXJnZSBncm91cCwNCmJ1dCBmYXIgZnJvbSB0aGUgb25seSBvbmNlIHRoYXQgdGhp bmsgb2YgdGhlbXNlbHZlcyBhcyAibmV0d29yaw0Kb3BlcmF0b3JzIiwgbGlrZWx5IHRoZSBtYWpv cml0eSBvZiAibmV0d29yayBvcGVyYXRvcnMiIGFyZSBub3QgZm9yIHRoZWlyDQpvcGVyYXRpb25h bCBhY3Rpdml0aWVzIGludGVyZXN0ZWQgb3IgZXZlbiBhd2FyZSBvZiB0aGUgY29tbWFuZHMNCmRl c2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQpNeSBleHBlcmllbmNlIGlzIGFsc28gdGhhdCB0 aGUgSUVURiBzaG91bGQgbm90IHRlbGwgIm5ldHdvcmsgb3BlcmF0b3JzIg0Kd2hhdCBpcyBpbXBv cnRhbnQgZm9yIHRoZW0uDQoNClN1Z2dlc3RlZCBuZXcgdGV4dCAoZnJvbSB0aGUgYmVnaW5uaW5n IG9mIHRoZSBwYXJhZ3JhcGgpOg0KDQoiVHJhbnNwb3J0IG5ldHdvcmsgb3BlcmF0b3JzIHJ1biBu ZXR3b3JrcyBiYXNlZCBvbiBkaWZmZXJlbnQNCnRlY2hub2xvZ2llcywgZS5nLiBvcHRpY2FsIHRy YW5zcG9ydCBuZXR3b3JrcywgRXRoZXJlbnQgdHJhbnNwb3J0DQpuZXR3b3JrcyBhbmQgTVBMUy1U UCBuZXR3b3Jrcy4gQ29tbW9uYWxpdHkgYmV0d2VlbiBvcGVyYXRpb25hbA0KcHJvY2VkdXJlcyBh cmUgaW1wb3J0YW50LiBGb3IgdHJhbnNwb3J0IG5ldHdvcmsgb3BlcmF0b3JzIGFjY3VzdG9tZWQN CnRvIHRoZSBvcGVyYXRpb25hbCBwcm9jZWR1cmVzIGZvciBPcHRpY2FsIGFuZCBFdGhlcm5ldCB0 cmFuc3BvcnQNCm5ldHdvcmtzIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgc2FtZSBwcm9jZWR1 cmVzIGZvciBNUExTLVRQDQpuZXR3b3Jrcy4iDQoNCi9Mb2ENCg0KDQoNCi0tDQoNCg0KTG9hIEFu ZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQg bG9hQHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogKzQ2IDcz OSA4MSAyMSA2NA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB368SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsIHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRz LDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPldoaWxlIEkgYWdyZWUgd2l0aCB5b3VyIHBvaW50 cywgSSBkb24ndCB0aGluayB0aGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIG5ldHdvcmsgb3BlcmF0 aW9uIHByb2NlZHVyZXMgZm9yIE1QTFMtVFAgbmV0d29ya3MuPC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCI+VGhlcmVmb3JlLCBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0byZu YnNwO2NoYW5nZSB0aGUgbGFzdCBzZW50ZW5jZSBvZiB5b3VyJm5ic3A7c3VnZ2VzdGVkIG5ldyB0 ZXh0IGFzIGZvbGxvd3M6PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PHNw YW4gc3R5bGU9IkxJTkUtSEVJR0hUOiAxMTUlOyBGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1z ZXJpZic7IEZPTlQtU0laRTogMTBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg 6rOg65SVJzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWFuc2kt bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSIgbGFuZz0iRU4tVVMiPiZxdW90O0Zvcg0KIHRyYW5zcG9ydCBuZXR3b3JrIG9w ZXJhdG9ycyBhY2N1c3RvbWVkPGJyPg0KdG8gdGhlIG9wZXJhdGlvbmFsIHByb2NlZHVyZXMgZm9y IE9wdGljYWwgYW5kIEV0aGVybmV0IHRyYW5zcG9ydDxicj4NCm5ldHdvcmtzIHRoaXMgZG9jdW1l bnQgZGVmaW5lcyB0aGUgcHJvdG9jb2wgb3BlcmF0aW9ucyBhbmQgbWVjaGFuaXNtcyA8L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PHNwYW4gc3R5bGU9IkxJTkUt SEVJR0hUOiAxMTUlOyBGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0la RTogMTBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZh cmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVT OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgbGFu Zz0iRU4tVVMiPnRoYXQNCiByZXN1bHQgaW4gdGhlIHNhbWUgbmV0d29yayBvcGVyYXRpb24gcHJv Y2VkdXJlcyBmb3IgTVBMUy1UUCBuZXR3b3Jrcy4mcXVvdDs8L3NwYW4+PGJyPg0KVGhlIG90aGVy IHNlbnRlbmNlcyBhcmUgb2sgd2l0aCBtZS48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5CZXN0 IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SmVvbmctZG9uZzwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiIGlkPSJNYWlsU2lnbiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiPjxiPkZyb20gOiA8L2I+JnF1b3Q7TG9hIEFuZGVyc3NvbiZxdW90OyAmbHQ7bG9h QHBpLm51Jmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAxMy0xMS0yOSAxNDoxMzoyMSAoICYjNDM7 MDk6MDAgKTxicj4NCjxiPlRvIDogPC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcm Z3Q7LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQt aWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmZ3Q7LCBtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2Mg OiA8L2I+PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5bbXBsc10gJnF1b3Q7b3BlcnRvciZxdW90OyBp biBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxicj4NCjxicj4NCjxicj4NCkF1dGhvcnMvRWRp dG9ycyw8YnI+DQo8YnI+DQpTZWN0aW9uIDQuMSBvZiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dS0wMCB1c2VzIHRoZSB0ZXJtICZxdW90O25ldHdvcms8YnI+DQpvcGVyYXRvciZxdW90OyBpbiBh IHdheSB0aGF0IG1ha2VzIHRoZSByZWFkZXIgdGhpbmsgdGhhdCB0aGlzIGlzIHRydWUgZm9yPGJy Pg0KZXZlcnkgbmV0d29yayBvcGVyYXRvci48YnI+DQo8YnI+DQomcXVvdDsuLi4sIGZvciBuZXR3 b3JrIG9wZXJhdG9ycyBpdCBpczxicj4NCmltcG9ydGFudCB0aGF0IHRoZSBNUExTLVRQIHByb3Rl Y3Rpb24gc3dpdGNoaW5nIHByZXNlcnZlcyB0aGUgbmV0d29yazxicj4NCm9wZXJhdGlvbiBiZWhh dmlvciB0byB3aGljaCBuZXR3b3JrIG9wZXJhdG9ycyBoYXZlIGJlY29tZSBhY2N1c3RvbWVkLiZx dW90Ozxicj4NCjxicj4NCkFkbWl0dGVkbHkgJnF1b3Q7dHJhbnNwb3J0IG5ldHdvcmsgb3BlcmF0 b3JzJnF1b3Q7IGFyZSBhIHN1ZmZpY2llbnRseSBsYXJnZSBncm91cCw8YnI+DQpidXQgZmFyIGZy b20gdGhlIG9ubHkgb25jZSB0aGF0IHRoaW5rIG9mIHRoZW1zZWx2ZXMgYXMgJnF1b3Q7bmV0d29y azxicj4NCm9wZXJhdG9ycyZxdW90OywgbGlrZWx5IHRoZSBtYWpvcml0eSBvZiAmcXVvdDtuZXR3 b3JrIG9wZXJhdG9ycyZxdW90OyBhcmUgbm90IGZvciB0aGVpcjxicj4NCm9wZXJhdGlvbmFsIGFj dGl2aXRpZXMgaW50ZXJlc3RlZCBvciBldmVuIGF3YXJlIG9mIHRoZSBjb21tYW5kczxicj4NCmRl c2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50Ljxicj4NCjxicj4NCk15IGV4cGVyaWVuY2UgaXMgYWxz byB0aGF0IHRoZSBJRVRGIHNob3VsZCBub3QgdGVsbCAmcXVvdDtuZXR3b3JrIG9wZXJhdG9ycyZx dW90Ozxicj4NCndoYXQgaXMgaW1wb3J0YW50IGZvciB0aGVtLjxicj4NCjxicj4NClN1Z2dlc3Rl ZCBuZXcgdGV4dCAoZnJvbSB0aGUgYmVnaW5uaW5nIG9mIHRoZSBwYXJhZ3JhcGgpOjxicj4NCjxi cj4NCiZxdW90O1RyYW5zcG9ydCBuZXR3b3JrIG9wZXJhdG9ycyBydW4gbmV0d29ya3MgYmFzZWQg b24gZGlmZmVyZW50PGJyPg0KdGVjaG5vbG9naWVzLCBlLmcuIG9wdGljYWwgdHJhbnNwb3J0IG5l dHdvcmtzLCBFdGhlcmVudCB0cmFuc3BvcnQ8YnI+DQpuZXR3b3JrcyBhbmQgTVBMUy1UUCBuZXR3 b3Jrcy4gQ29tbW9uYWxpdHkgYmV0d2VlbiBvcGVyYXRpb25hbDxicj4NCnByb2NlZHVyZXMgYXJl IGltcG9ydGFudC4gRm9yIHRyYW5zcG9ydCBuZXR3b3JrIG9wZXJhdG9ycyBhY2N1c3RvbWVkPGJy Pg0KdG8gdGhlIG9wZXJhdGlvbmFsIHByb2NlZHVyZXMgZm9yIE9wdGljYWwgYW5kIEV0aGVybmV0 IHRyYW5zcG9ydDxicj4NCm5ldHdvcmtzIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgc2FtZSBw cm9jZWR1cmVzIGZvciBNUExTLVRQPGJyPg0KbmV0d29ya3MuJnF1b3Q7PGJyPg0KPGJyPg0KL0xv YTxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNz b24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxicj4NClNlbmlvciBNUExTIEV4cGVydCBs b2FAcGkubnU8YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogJiM0 Mzs0NiA3MzkgODEgMjEgNjQ8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRmLm9yZzxi cj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB368SMTP2etriinfo_-- From loa@pi.nu Sun Dec 1 17:45:30 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 DB3A61AE170 for ; Sun, 1 Dec 2013 17:45: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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmVK2m4JOpJS for ; Sun, 1 Dec 2013 17:45:28 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 30BCA1ADFF5 for ; Sun, 1 Dec 2013 17:45:28 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.94.158]) (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 2200D18015AB; Mon, 2 Dec 2013 02:45:23 +0100 (CET) Message-ID: <529BE62E.2070308@pi.nu> Date: Mon, 02 Dec 2013 09:45:18 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Ryoo, Jeong-dong" , "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" References: <52982260.2020304@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB368@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB368@SMTP2.etri.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] "opertor" 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: Mon, 02 Dec 2013 01:45:31 -0000 Jeong-dong, That works for me! /Loa On 2013-12-02 09:42, Ryoo, Jeong-dong wrote: > Loa, thanks for the comments, > While I agree with your points, I don't think this document defines the > network operation procedures for MPLS-TP networks. > Therefore, I would like to propose to change the last sentence of > your suggested new text as follows: > "For transport network operators accustomed > to the operational procedures for Optical and Ethernet transport > networks this document defines the protocol operations and mechanisms > that result in the same network operation procedures for MPLS-TP networks." > The other sentences are ok with me. > Best regards, > Jeong-dong > > ------------------------------------------------------------------------ > *From : *"Loa Andersson" > *Sent : *2013-11-29 14:13:21 ( +09:00 ) > *To : *mpls@ietf.org , > draft-ietf-mpls-tp-psc-itu@tools.ietf.org > , mpls-chairs@tools.ietf.org > > *Cc : * > *Subject : *[mpls] "opertor" in draft-ietf-mpls-tp-psc-itu > > > Authors/Editors, > > Section 4.1 of draft-ietf-mpls-tp-psc-itu-00 uses the term "network > operator" in a way that makes the reader think that this is true for > every network operator. > > "..., for network operators it is > important that the MPLS-TP protection switching preserves the network > operation behavior to which network operators have become accustomed." > > Admittedly "transport network operators" are a sufficiently large group, > but far from the only once that think of themselves as "network > operators", likely the majority of "network operators" are not for their > operational activities interested or even aware of the commands > described in this document. > > My experience is also that the IETF should not tell "network operators" > what is important for them. > > Suggested new text (from the beginning of the paragraph): > > "Transport network operators run networks based on different > technologies, e.g. optical transport networks, Etherent transport > networks and MPLS-TP networks. Commonality between operational > procedures are important. For transport network operators accustomed > to the operational procedures for Optical and Ethernet transport > networks this document defines the same procedures for MPLS-TP > networks." > > /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 -- 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 Sun Dec 1 18:08:11 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 807CE1AE291 for ; Sun, 1 Dec 2013 18:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4HlVzMY632b for ; Sun, 1 Dec 2013 18:08:08 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 194731ADF60 for ; Sun, 1 Dec 2013 18:08:08 -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; Mon, 2 Dec 2013 11:08:06 +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, 2 Dec 2013 11:08:00 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] "opertor" in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHO7MG5MoNo5Ie5+EqGd7NBQarCh5pAI/6+//9r7QCAAJw0fg== Date: Mon, 2 Dec 2013 02:08:00 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB381@SMTP2.etri.info> References: <52982260.2020304@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB368@SMTP2.etri.info>, <529BE62E.2070308@pi.nu> In-Reply-To: <529BE62E.2070308@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_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB381SMTP2etriinfo_" MIME-Version: 1.0 Subject: Re: [mpls] "opertor" 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: Mon, 02 Dec 2013 02:08:11 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB381SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Ty5LLiwgSSB3aWxsIGluY29ycG9yYXRlIHRoZSB0ZXh0IGluIHRoZSBuZXh0IHZlcnNpb24sIGlm IHRoZXJlIGlzIG5vIGRpZmZlcmVudCB2aWV3IG9uIHRoaXMuDQoNClRoYW5rcy4NCg0KSmVvbmct ZG9uZw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb20gOiAiTG9h IEFuZGVyc3NvbiIgPGxvYUBwaS5udT4NClNlbnQgOiAyMDEzLTEyLTAyIDEwOjQ1OjMxICggKzA5 OjAwICkNClRvIDogUnlvbywgSmVvbmctZG9uZyA8cnlvb0BldHJpLnJlLmtyPiwgbXBsc0BpZXRm Lm9yZyA8bXBsc0BpZXRmLm9yZz4sIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmll dGYub3JnIDxkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz4sIG1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnIDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCkNjIDoN ClN1YmplY3QgOiBSZTogW21wbHNdICJvcGVydG9yIiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNj LWl0dQ0KDQoNCkplb25nLWRvbmcsDQoNClRoYXQgd29ya3MgZm9yIG1lIQ0KDQovTG9hDQoNCk9u IDIwMTMtMTItMDIgMDk6NDIsIFJ5b28sIEplb25nLWRvbmcgd3JvdGU6DQo+IExvYSwgdGhhbmtz IGZvciB0aGUgY29tbWVudHMsDQo+IFdoaWxlIEkgYWdyZWUgd2l0aCB5b3VyIHBvaW50cywgSSBk b24ndCB0aGluayB0aGlzIGRvY3VtZW50IGRlZmluZXMgdGhlDQo+IG5ldHdvcmsgb3BlcmF0aW9u IHByb2NlZHVyZXMgZm9yIE1QTFMtVFAgbmV0d29ya3MuDQo+IFRoZXJlZm9yZSwgSSB3b3VsZCBs aWtlIHRvIHByb3Bvc2UgdG8gY2hhbmdlIHRoZSBsYXN0IHNlbnRlbmNlIG9mDQo+IHlvdXIgc3Vn Z2VzdGVkIG5ldyB0ZXh0IGFzIGZvbGxvd3M6DQo+ICJGb3IgdHJhbnNwb3J0IG5ldHdvcmsgb3Bl cmF0b3JzIGFjY3VzdG9tZWQNCj4gdG8gdGhlIG9wZXJhdGlvbmFsIHByb2NlZHVyZXMgZm9yIE9w dGljYWwgYW5kIEV0aGVybmV0IHRyYW5zcG9ydA0KPiBuZXR3b3JrcyB0aGlzIGRvY3VtZW50IGRl ZmluZXMgdGhlIHByb3RvY29sIG9wZXJhdGlvbnMgYW5kIG1lY2hhbmlzbXMNCj4gdGhhdCByZXN1 bHQgaW4gdGhlIHNhbWUgbmV0d29yayBvcGVyYXRpb24gcHJvY2VkdXJlcyBmb3IgTVBMUy1UUCBu ZXR3b3Jrcy4iDQo+IFRoZSBvdGhlciBzZW50ZW5jZXMgYXJlIG9rIHdpdGggbWUuDQo+IEJlc3Qg cmVnYXJkcywNCj4gSmVvbmctZG9uZw0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gKkZyb20gOiAq IkxvYSBBbmRlcnNzb24iDQo+ICpTZW50IDogKjIwMTMtMTEtMjkgMTQ6MTM6MjEgKCArMDk6MDAg KQ0KPiAqVG8gOiAqbXBsc0BpZXRmLm9yZyAsDQo+IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1 QHRvb2xzLmlldGYub3JnDQo+ICwgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4NCj4gKkNj IDogKg0KPiAqU3ViamVjdCA6ICpbbXBsc10gIm9wZXJ0b3IiIGluIGRyYWZ0LWlldGYtbXBscy10 cC1wc2MtaXR1DQo+DQo+DQo+IEF1dGhvcnMvRWRpdG9ycywNCj4NCj4gU2VjdGlvbiA0LjEgb2Yg ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDAgdXNlcyB0aGUgdGVybSAibmV0d29yaw0KPiBv cGVyYXRvciIgaW4gYSB3YXkgdGhhdCBtYWtlcyB0aGUgcmVhZGVyIHRoaW5rIHRoYXQgdGhpcyBp cyB0cnVlIGZvcg0KPiBldmVyeSBuZXR3b3JrIG9wZXJhdG9yLg0KPg0KPiAiLi4uLCBmb3IgbmV0 d29yayBvcGVyYXRvcnMgaXQgaXMNCj4gaW1wb3J0YW50IHRoYXQgdGhlIE1QTFMtVFAgcHJvdGVj dGlvbiBzd2l0Y2hpbmcgcHJlc2VydmVzIHRoZSBuZXR3b3JrDQo+IG9wZXJhdGlvbiBiZWhhdmlv ciB0byB3aGljaCBuZXR3b3JrIG9wZXJhdG9ycyBoYXZlIGJlY29tZSBhY2N1c3RvbWVkLiINCj4N Cj4gQWRtaXR0ZWRseSAidHJhbnNwb3J0IG5ldHdvcmsgb3BlcmF0b3JzIiBhcmUgYSBzdWZmaWNp ZW50bHkgbGFyZ2UgZ3JvdXAsDQo+IGJ1dCBmYXIgZnJvbSB0aGUgb25seSBvbmNlIHRoYXQgdGhp bmsgb2YgdGhlbXNlbHZlcyBhcyAibmV0d29yaw0KPiBvcGVyYXRvcnMiLCBsaWtlbHkgdGhlIG1h am9yaXR5IG9mICJuZXR3b3JrIG9wZXJhdG9ycyIgYXJlIG5vdCBmb3IgdGhlaXINCj4gb3BlcmF0 aW9uYWwgYWN0aXZpdGllcyBpbnRlcmVzdGVkIG9yIGV2ZW4gYXdhcmUgb2YgdGhlIGNvbW1hbmRz DQo+IGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50Lg0KPg0KPiBNeSBleHBlcmllbmNlIGlzIGFs c28gdGhhdCB0aGUgSUVURiBzaG91bGQgbm90IHRlbGwgIm5ldHdvcmsgb3BlcmF0b3JzIg0KPiB3 aGF0IGlzIGltcG9ydGFudCBmb3IgdGhlbS4NCj4NCj4gU3VnZ2VzdGVkIG5ldyB0ZXh0IChmcm9t IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHBhcmFncmFwaCk6DQo+DQo+ICJUcmFuc3BvcnQgbmV0d29y ayBvcGVyYXRvcnMgcnVuIG5ldHdvcmtzIGJhc2VkIG9uIGRpZmZlcmVudA0KPiB0ZWNobm9sb2dp ZXMsIGUuZy4gb3B0aWNhbCB0cmFuc3BvcnQgbmV0d29ya3MsIEV0aGVyZW50IHRyYW5zcG9ydA0K PiBuZXR3b3JrcyBhbmQgTVBMUy1UUCBuZXR3b3Jrcy4gQ29tbW9uYWxpdHkgYmV0d2VlbiBvcGVy YXRpb25hbA0KPiBwcm9jZWR1cmVzIGFyZSBpbXBvcnRhbnQuIEZvciB0cmFuc3BvcnQgbmV0d29y ayBvcGVyYXRvcnMgYWNjdXN0b21lZA0KPiB0byB0aGUgb3BlcmF0aW9uYWwgcHJvY2VkdXJlcyBm b3IgT3B0aWNhbCBhbmQgRXRoZXJuZXQgdHJhbnNwb3J0DQo+IG5ldHdvcmtzIHRoaXMgZG9jdW1l bnQgZGVmaW5lcyB0aGUgc2FtZSBwcm9jZWR1cmVzIGZvciBNUExTLVRQDQo+IG5ldHdvcmtzLiIN Cj4NCj4gL0xvYQ0KPg0KPg0KPg0KPiAtLQ0KPg0KPg0KPiBMb2EgQW5kZXJzc29uIGVtYWlsOiBs b2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gU2VuaW9yIE1QTFMgRXhwZXJ0IGxvYUBwaS5udQ0KPiBI dWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxz IG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBt YWlsMDEuaHVhd2VpLmNvbQ0KU2VuaW9yIE1QTFMgRXhwZXJ0IGxvYUBwaS5udQ0KSHVhd2VpIFRl Y2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB381SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5PLksuLCBJIHdpbGwgaW5jb3Jwb3JhdGUgdGhl IHRleHQgaW4gdGhlIG5leHQgdmVyc2lvbiwgaWYgdGhlcmUmbmJzcDtpcyBubyBkaWZmZXJlbnQm bmJzcDt2aWV3IG9uIHRoaXMuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+ PGJyPg0KVGhhbmtzLjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNw OzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRvbmc8L2Rpdj4N CjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48YnI+DQombmJzcDs8L2Rpdj4NCjxkaXYg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBpZD0iTWFpbFNpZ24iPjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48Yj5Gcm9tIDogPC9iPiZxdW90O0xvYSBB bmRlcnNzb24mcXVvdDsgJmx0O2xvYUBwaS5udSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMt MTItMDIgMTA6NDU6MzEgKCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5SeW9vLCBKZW9u Zy1kb25nICZsdDtyeW9vQGV0cmkucmUua3ImZ3Q7LCBtcGxzQGlldGYub3JnICZsdDttcGxzQGll dGYub3JnJmd0OywgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcgJmx0 O2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnJmd0OywgbXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcgJmx0O21wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJmd0Ozxicj4N CjxiPkNjIDogPC9iPjxicj4NCjxiPlN1YmplY3QgOiA8L2I+UmU6IFttcGxzXSAmcXVvdDtvcGVy dG9yJnF1b3Q7IGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1PGJyPg0KPGJyPg0KPGJyPg0K SmVvbmctZG9uZyw8YnI+DQo8YnI+DQpUaGF0IHdvcmtzIGZvciBtZSE8YnI+DQo8YnI+DQovTG9h PGJyPg0KPGJyPg0KT24gMjAxMy0xMi0wMiAwOTo0MiwgUnlvbywgSmVvbmctZG9uZyB3cm90ZTo8 YnI+DQomZ3Q7IExvYSwgdGhhbmtzIGZvciB0aGUgY29tbWVudHMsPGJyPg0KJmd0OyBXaGlsZSBJ IGFncmVlIHdpdGggeW91ciBwb2ludHMsIEkgZG9uJ3QgdGhpbmsgdGhpcyBkb2N1bWVudCBkZWZp bmVzIHRoZTxicj4NCiZndDsgbmV0d29yayBvcGVyYXRpb24gcHJvY2VkdXJlcyBmb3IgTVBMUy1U UCBuZXR3b3Jrcy48YnI+DQomZ3Q7IFRoZXJlZm9yZSwgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2Ug dG8gY2hhbmdlIHRoZSBsYXN0IHNlbnRlbmNlIG9mPGJyPg0KJmd0OyB5b3VyIHN1Z2dlc3RlZCBu ZXcgdGV4dCBhcyBmb2xsb3dzOjxicj4NCiZndDsgJnF1b3Q7Rm9yIHRyYW5zcG9ydCBuZXR3b3Jr IG9wZXJhdG9ycyBhY2N1c3RvbWVkPGJyPg0KJmd0OyB0byB0aGUgb3BlcmF0aW9uYWwgcHJvY2Vk dXJlcyBmb3IgT3B0aWNhbCBhbmQgRXRoZXJuZXQgdHJhbnNwb3J0PGJyPg0KJmd0OyBuZXR3b3Jr cyB0aGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHByb3RvY29sIG9wZXJhdGlvbnMgYW5kIG1lY2hh bmlzbXM8YnI+DQomZ3Q7IHRoYXQgcmVzdWx0IGluIHRoZSBzYW1lIG5ldHdvcmsgb3BlcmF0aW9u IHByb2NlZHVyZXMgZm9yIE1QTFMtVFAgbmV0d29ya3MuJnF1b3Q7PGJyPg0KJmd0OyBUaGUgb3Ro ZXIgc2VudGVuY2VzIGFyZSBvayB3aXRoIG1lLjxicj4NCiZndDsgQmVzdCByZWdhcmRzLDxicj4N CiZndDsgSmVvbmctZG9uZzxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CiZndDsgKkZyb20gOiAqJnF1b3Q7TG9hIEFuZGVyc3NvbiZxdW90OyA8TE9BQFBJLk5VPjxicj4N CiZndDsgKlNlbnQgOiAqMjAxMy0xMS0yOSAxNDoxMzoyMSAoICYjNDM7MDk6MDAgKTxicj4NCiZn dDsgKlRvIDogKm1wbHNAaWV0Zi5vcmcgPE1QTFNASUVURi5PUkc+LDxicj4NCiZndDsgZHJhZnQt aWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc8YnI+DQomZ3Q7IDxEUkFGVC1JRVRG LU1QTFMtVFAtUFNDLUlUVUBUT09MUy5JRVRGLk9SRz4sIG1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnPGJyPg0KJmd0OyA8TVBMUy1DSEFJUlNAVE9PTFMuSUVURi5PUkc+PGJyPg0KJmd0OyAqQ2Mg OiAqPGJyPg0KJmd0OyAqU3ViamVjdCA6ICpbbXBsc10gJnF1b3Q7b3BlcnRvciZxdW90OyBpbiBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBB dXRob3JzL0VkaXRvcnMsPGJyPg0KJmd0Ozxicj4NCiZndDsgU2VjdGlvbiA0LjEgb2YgZHJhZnQt aWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDAgdXNlcyB0aGUgdGVybSAmcXVvdDtuZXR3b3JrPGJyPg0K Jmd0OyBvcGVyYXRvciZxdW90OyBpbiBhIHdheSB0aGF0IG1ha2VzIHRoZSByZWFkZXIgdGhpbmsg dGhhdCB0aGlzIGlzIHRydWUgZm9yPGJyPg0KJmd0OyBldmVyeSBuZXR3b3JrIG9wZXJhdG9yLjxi cj4NCiZndDs8YnI+DQomZ3Q7ICZxdW90Oy4uLiwgZm9yIG5ldHdvcmsgb3BlcmF0b3JzIGl0IGlz PGJyPg0KJmd0OyBpbXBvcnRhbnQgdGhhdCB0aGUgTVBMUy1UUCBwcm90ZWN0aW9uIHN3aXRjaGlu ZyBwcmVzZXJ2ZXMgdGhlIG5ldHdvcms8YnI+DQomZ3Q7IG9wZXJhdGlvbiBiZWhhdmlvciB0byB3 aGljaCBuZXR3b3JrIG9wZXJhdG9ycyBoYXZlIGJlY29tZSBhY2N1c3RvbWVkLiZxdW90Ozxicj4N CiZndDs8YnI+DQomZ3Q7IEFkbWl0dGVkbHkgJnF1b3Q7dHJhbnNwb3J0IG5ldHdvcmsgb3BlcmF0 b3JzJnF1b3Q7IGFyZSBhIHN1ZmZpY2llbnRseSBsYXJnZSBncm91cCw8YnI+DQomZ3Q7IGJ1dCBm YXIgZnJvbSB0aGUgb25seSBvbmNlIHRoYXQgdGhpbmsgb2YgdGhlbXNlbHZlcyBhcyAmcXVvdDtu ZXR3b3JrPGJyPg0KJmd0OyBvcGVyYXRvcnMmcXVvdDssIGxpa2VseSB0aGUgbWFqb3JpdHkgb2Yg JnF1b3Q7bmV0d29yayBvcGVyYXRvcnMmcXVvdDsgYXJlIG5vdCBmb3IgdGhlaXI8YnI+DQomZ3Q7 IG9wZXJhdGlvbmFsIGFjdGl2aXRpZXMgaW50ZXJlc3RlZCBvciBldmVuIGF3YXJlIG9mIHRoZSBj b21tYW5kczxicj4NCiZndDsgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuPGJyPg0KJmd0Ozxi cj4NCiZndDsgTXkgZXhwZXJpZW5jZSBpcyBhbHNvIHRoYXQgdGhlIElFVEYgc2hvdWxkIG5vdCB0 ZWxsICZxdW90O25ldHdvcmsgb3BlcmF0b3JzJnF1b3Q7PGJyPg0KJmd0OyB3aGF0IGlzIGltcG9y dGFudCBmb3IgdGhlbS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTdWdnZXN0ZWQgbmV3IHRleHQgKGZy b20gdGhlIGJlZ2lubmluZyBvZiB0aGUgcGFyYWdyYXBoKTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAm cXVvdDtUcmFuc3BvcnQgbmV0d29yayBvcGVyYXRvcnMgcnVuIG5ldHdvcmtzIGJhc2VkIG9uIGRp ZmZlcmVudDxicj4NCiZndDsgdGVjaG5vbG9naWVzLCBlLmcuIG9wdGljYWwgdHJhbnNwb3J0IG5l dHdvcmtzLCBFdGhlcmVudCB0cmFuc3BvcnQ8YnI+DQomZ3Q7IG5ldHdvcmtzIGFuZCBNUExTLVRQ IG5ldHdvcmtzLiBDb21tb25hbGl0eSBiZXR3ZWVuIG9wZXJhdGlvbmFsPGJyPg0KJmd0OyBwcm9j ZWR1cmVzIGFyZSBpbXBvcnRhbnQuIEZvciB0cmFuc3BvcnQgbmV0d29yayBvcGVyYXRvcnMgYWNj dXN0b21lZDxicj4NCiZndDsgdG8gdGhlIG9wZXJhdGlvbmFsIHByb2NlZHVyZXMgZm9yIE9wdGlj YWwgYW5kIEV0aGVybmV0IHRyYW5zcG9ydDxicj4NCiZndDsgbmV0d29ya3MgdGhpcyBkb2N1bWVu dCBkZWZpbmVzIHRoZSBzYW1lIHByb2NlZHVyZXMgZm9yIE1QTFMtVFA8YnI+DQomZ3Q7IG5ldHdv cmtzLiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC9Mb2E8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IExvYSBB bmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxicj4NCiZndDsgU2VuaW9yIE1Q TFMgRXhwZXJ0IGxvYUBwaS5udTxicj4NCiZndDsgSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3Vs dGFudCkgcGhvbmU6ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJyPg0KJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbXBscyBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7IG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4NCjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4N CkxvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxicj4NClNlbmlvciBN UExTIEV4cGVydCBsb2FAcGkubnU8YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50 KSBwaG9uZTogJiM0Mzs0NiA3MzkgODEgMjEgNjQ8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB381SMTP2etriinfo_-- From loa@pi.nu Sun Dec 1 18:54:46 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 65B6E1AE2ED for ; Sun, 1 Dec 2013 18:54: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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rk6nSMvoYnJ for ; Sun, 1 Dec 2013 18:54:45 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 53BB81AE2EB for ; Sun, 1 Dec 2013 18:54:45 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.94.158]) (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 0E3C818015AB; Mon, 2 Dec 2013 03:54:40 +0100 (CET) Message-ID: <529BF66B.50405@pi.nu> Date: Mon, 02 Dec 2013 10:54:35 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] the phrase meets the ITU-T's protection switching requirements 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: Mon, 02 Dec 2013 02:54:46 -0000 Editors/Authors, I've been thinking about draft-ietf-mpls-tp-psc-itu. The document says at several places "meets the ITU-T's protection switching requirements" so I thought I go look these requirements up. To my surprise I found that the only mpls-tp requirement document we actually refer is RFC5654. I don't think we can have an open ended reference to "ITU-T's protection switching requirements" if they are not documented. We could of course find the document that list the "ITU-T's protection switching requirements" and reference that directly. However my preference would be to add text to the introduction the "the ITU-T's protection switching requirements" were incorporated in RFC5654, and then where you now say "meets the ITU-T's protection switching requirements" instead point to RFC5654 and the exact requirement. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From jcucchiara@mindspring.com Mon Dec 2 10:03:25 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 C797A1AD7C2; Mon, 2 Dec 2013 10:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 1Td1NxdBRfk6; Mon, 2 Dec 2013 10:03:22 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 18AEC1AD7C0; Mon, 2 Dec 2013 10:03:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PjFc/sVxh0IkgG5gDkOkSgnG9bAnyl7XxH2CALDJdf1A6T9NTKR/lqaUQPG41OnY; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VnXpu-0003B3-Bn; Mon, 02 Dec 2013 13:03:11 -0500 Message-ID: <0c1f01ceef88$c40ead50$6901a8c0@JoanPC> From: "Joan Cucchiara" To: "Venkatesan Mahalingam" , "venkatesan mahalingam" References: <00fe01ce1ed2$72981ce0$6801a8c0@JoanPC> Date: Mon, 2 Dec 2013 13:03:10 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C1C_01CEEF5E.DA34C9E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654259426b3dcd17839bf757a6e9de274973122699149cfe979350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: mpls , "MIB Doctors \(E-mail\)" , ppan@infinera.com, Sami Boutros , Thomas Nadeau , Kannan Sampath Subject: [mpls] MIB Dr. review of draft-ietf-mpls-tp-oam-id-mib-03.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, 02 Dec 2013 18:03:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0C1C_01CEEF5E.DA34C9E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authors, For this review, I looked over the comments from 02 to see how these = comments were addressed. =20 (Version 02 comments are copied below and comments for Version 03 are = prefaced with JEC.) As you can see most of the Version 02 comments have been addressed, so = thank you for that! A few comments from 02 have not been updated in version 03. The 3 comments which I think needs some attention are: 1) MplsOamPhbTCValue=20 Textual Convention should have a reference within MPLS. Even if the = values have been assigned by the authors, an indication of where BHP Traffic Classes are derived from = within MPLS OAM seems reasonable. =20 2) mplsOamIdMeMpIfIndex The REFERENCE for RFC6371 doesn't seem to refer to this object. Could=20 REFERENCE be checked? (I thought a change here was agreed to but didn't = see an updated REF.) 3) No ReadOnly conformance. Please confirm that WG is agreeable to have a MIB that does not have a ReadOnly Conformance. As you are aware, some operators prefer not to use SNMP=20 for configuration, so if this MIB does not support a ReadOnly = Conformance, then vendors will not be compliant if they support this MIB as it exists now. 4) Security Section (see below). Thanks, -Joan Specific Comments on this version 03 are prefaced with JEC: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 3.3 Acronyms * MIP is specified slightly differently in the referenced docs. Please be consistant. JEC: Updated. Section 6. This example, specifies the mplsOamIdMeMpEntry as a MEP, but why=20 isn't the SourceMepIndex or SinkMepIndex =3D=3D mplsOamIdMeMpIndex? Also, there are at least 2 MEPs in an ME, and at least one ME in a MEG and these relationships are not completely evolved in this example. I think the example should be expanded to agree with what is stated in the first paragraph. JEC: The example was not evolved, but the first text was modified to agree with the example, so I can live with that. MIB Module comments ------------------- * TC: MplsOamPhbTCValue MplsOamPhbTCValue ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is the Per-hop Behavior (PHB) traffic class values for the MPLS OAM operations." SYNTAX INTEGER { be (1), af1 (2), af2 (3), af3 (4), af4 (5), ef (6), cs6 (7), cs7 (8) } Rfc3270, "Multi-Protocol Label Switching (MPLS) Support of=20 Differentiated Services", specifies that MPLS TP will use DSCP as per=20 rfc2474 and other specs. Is that the intent wrt this TC? If not, please explain where these values are defined, otherwise,=20 if these values are as per rfc3270, then please be consistant with the = labels. TC labels should correspond more closely to DiffServ BHB traffic class = values. In other words,=20 http://www.iana.org/assignments/dscp-registry/dscp-registry.xml Name Space Reference CS0 000000 [RFC2474] CS1 001000 [RFC2474] CS2 010000 [RFC2474] CS3 011000 [RFC2474] CS4 100000 [RFC2474] CS5 101000 [RFC2474] CS6 110000 [RFC2474] CS7 111000 [RFC2474] AF11 001010 [RFC2597] AF12 001100 [RFC2597] AF13 001110 [RFC2597] AF21 010010 [RFC2597] AF22 010100 [RFC2597] AF23 010110 [RFC2597] AF31 011010 [RFC2597] AF32 011100 [RFC2597] AF33 011110 [RFC2597] AF41 100010 [RFC2597] AF42 100100 [RFC2597] AF43 100110 [RFC2597] EF PHB 101110 [RFC3246] VOICE-ADMIT 101100 [RFC5865] Continuing with that thought: I believe this TC could (and should) be=20 formalized into an IANA-Maintained MIB if these values are the same as the above IANA-Maintained assignments for DFCPs. =20 (NOTE: this was mentioned also in the LC comments.) Please discuss. Also, this TC should have a REFERENCE clause. JEC: Not done. So, a REF clause to at least explain where MPLS OAM = PHB is=20 described would be helpful. =20 * mplsOamIdMegIndex There is no information about how to employ mplsOamIdMegIndexNext to=20 obtain a value for this index. Please update the DESCRIPTION = accordingly. JEC: Updated. * mplsOamIdMegOperatorType Why does this say "should have valid values...", isn't this a MUST? Also, s/while making/when/ JEC: Updated. * mplsOamIdMegIdCc s/contains non-null ICC/MUST contain a/ s/otherwise null ICC value/otherwise a null ICC value/ s/should be assigned/MUST be assigned/ JEC: Updated. * mplsOamIdMegIdIcc Same comments as above. Please use MUST. JEC: Updated. * mplsOamIdMegIdUmc Same comments as above. Please use MUST. JEC: Updated. * mplsOamIdMegServiceType Could you please specify the service pointer by the object's name? Also, the references are within the DESCRIPTION which is fine, but they should also be in a REFERENCE clause. JEC: Updated. I was asking that actual object names be used in this DESCRIPTION clause. For example, the phrase "the service pointer in the mplsOamIdMeTable" to change to THAT object's name,=20 i.e. mplsOamIdMeServicePointer. Similar comment wrt the paragraph=20 on the pointer in PW. * mplsOamIdMeIndexNext and mplsOamIdMpIndexNext These objects are not referred to by mplsOamIdMeIndex or = mplsOamIdMeMpIndex. There is not enough description to understand how the IndexNext objects are to be used.=20 JEC: Updated. * MplsOamIdMeTable The mplsOamIdMeEntry states "An entry in this table represents MPLS-TP maintenance entity." Yet, looking at the=20 INDEX { mplsOamIdMegIndex, mplsOamIdMeIndex, mplsOamIdMeMpIndex } This is not an ME because an ME by definition has 2 (source/sink)MEPs. An entry in this table represents either a MEP or MIP, not an ME. JEC: okay. *) What is the benefit of combining MEP and MIP (i.e. the objects=20 which contain "Mp" as part of their object name)? Many other objects in this table, need to figure out if the entry is describing a MEP or MIP before the value can be interpreted = correctly. Additionally, there is duplicate info in the form of having a Source and Sink specified for each Mp. Could you elaborate on what the=20 benefit is of having listing MEPs and MIPs in this way? It seems like the original intent may have been to specify an ME as being an entry in this table. However, that would mean the table should probably be indexed by MEG index, a ME index, a source MEP index=20 and a sink MEP index. This would greatly simplify many of the object descriptions. =20 Have you considered specifying MIPs in a 3rd table, such that each ME would have 2 MEPs and zero or more MIPs? Please discuss. =20 JEC: okay. *) mplsOamIdMeMpIfIndex Rfc6370, Section 4.discusses an IF_NUM and an IF_ID and states "Note that IF_Num had no relation with the ifNum object defined in=20 RFC2863. Further, no mapping is mandated between IF_Num and ifIndex in RFC 2863." I don't see any mention of ifIndex in RFC 6371, so could you tell me = what Section? Is this object supposed to represent IF_NUM in rfc6370? JEC: Not updated. I think this is an oversight and you had already = found a correct REFERENCE but couldn't locate that email... *) mplsOamIdMeServicePointer The DESCRIPTION contains wording which is very loose. Could you please use wording which specifies a "SHOULD" or "MUST"? Under what circumstances should this be 0.0? JEC: Updated. Compliance Statement of the MIB *) Compliance (This has been asked before and I have not seen any discussion about it.) There is no read-only compliance. Has it been made clear to the WGs (MPLS and PWE3) that SNMP sets will need to be supported in order to be compliant with the MIB? JEC: Not done. *) question above, about whether the intention is to support ifIndex as per rfc2863 or IF_ID (or IF_NUM) as per rfc6370 may affect this. "MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup" *) mplsOamIdNotificationObjectsGroup OBJECT-GROUP I don't see a need to make a specific group for these objects. They are already specified by mplsOamIdGroups. JEC: Updated. Section 8. Security Section Need to reference specific read-create objects and also read-only which=20 could impact the network. Additionally, the incomplete sentence:=20 "These are the tables and objects and their sensitivity/vulnerability: " needs to be completed. JEC: Not done. Section 9. IANA Considerations s/specified this document/specified in this document/ missing the word "in" JEC: Updated. Section 11.=20 Thank you for the ack! ------=_NextPart_000_0C1C_01CEEF5E.DA34C9E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Authors,
 
For this review, I looked over the  comments from 02 to=20 see how these comments were addressed. 
(Version 02 comments are copied below and comments for Version 03 = are=20 prefaced with JEC.)
 
As you can see most of the Version 02 comments have=20 been addressed, so thank you for that!
 
A few comments from 02 have not been updated in version 03.
The 3 comments which I think needs some attention are:
 
1) MplsOamPhbTCValue 
Textual Convention should have a = reference=20 within MPLS.    Even if the values have been assigned = by
the authors, an indication of where BHP Traffic Classes are derived = from=20 within MPLS OAM seems
reasonable.  

2) mplsOamIdMeMpIfIndex
The REFERENCE for RFC6371 doesn't = seem to=20 refer to this object. Could
REFERENCE be checked?  (I thought a = change=20 here was agreed to but didn't see an updated REF.)
 
3) No ReadOnly conformance.  Please confirm that WG is = agreeable=20 to
have a MIB that does not have a ReadOnly Conformance.
As you = are=20 aware, some operators prefer not to use SNMP
for configuration, = so if=20 this MIB does not support a ReadOnly Conformance,
then vendors will = not be=20 compliant if they support this MIB as it
exists now.
 
4) Security Section (see below).
 

Thanks,
  -Joan
 
 
 
Specific Comments on this version 03 are prefaced with =20 JEC:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Section 3.3 Acronyms
 

* MIP is specified slightly differently in the referenced=20 docs.
Please be consistant.
 
JEC: Updated.
 

Section 6.
 
This example, specifies the mplsOamIdMeMpEntry as a MEP, but why =
isn't=20 the SourceMepIndex or SinkMepIndex =3D=3D mplsOamIdMeMpIndex?
 
Also, there are at least 2 MEPs in an ME, and at least one ME
in = a MEG=20 and these relationships are not completely evolved
in this = example.  I=20 think the example should be expanded
to agree with what is stated in = the=20 first paragraph.
 

JEC:  The example was not evolved, but the first text was=20 modified
to agree with the example, so I can live with that.
 
 
 
MIB Module comments
-------------------
 
* TC:  MplsOamPhbTCValue
 

         = MplsOamPhbTCValue ::=3D=20 TEXTUAL-CONVENTION
        &nb= sp;  =20 STATUS           &= nbsp; =20 current
          &n= bsp;=20 DESCRIPTION
         &nbs= p;     =20 "This is the Per-hop Behavior (PHB) traffic class=20 values
          &nb= sp;     =20 for the MPLS OAM=20 operations."
         &nb= sp; =20 SYNTAX        INTEGER=20 {
           &n= bsp;           &nb= sp;   =20 be=20 (1),
           = ;            =     =20 af1=20 (2),
           = ;            =     =20 af2=20 (3),
           = ;            =     =20 af3=20 (4),
           = ;            =     =20 af4=20 (5),
           = ;            =     =20 ef=20 (6),
           = ;            =     =20 cs6=20 (7),
           = ;            =     =20 cs7=20 (8)
           =             &= nbsp; =20 }
 

Rfc3270, "Multi-Protocol Label Switching (MPLS) Support of=20
Differentiated Services", specifies that MPLS TP will use DSCP as = per=20
rfc2474 and other specs.   Is that the intent wrt this = TC?
 
If not, please explain where these values are defined, otherwise, =
if=20 these values are as per rfc3270, then please be consistant with the=20 labels.
 
TC labels should correspond more closely to DiffServ BHB traffic = class=20 values.
In other words,
 
= http://www.iana.org/assignments/dscp-registry/dscp-registry.xml
=
 
   Name     Space =20 Reference
   = CS0        =20 000000 [RFC2474]
  =20 CS1         001000=20 [RFC2474]
   = CS2        =20 010000 [RFC2474]
  =20 CS3         011000=20 [RFC2474]
   = CS4        =20 100000 [RFC2474]
  =20 CS5         101000=20 [RFC2474]
   = CS6        =20 110000 [RFC2474]
  =20 CS7         111000=20 [RFC2474]
   AF11        = 001010=20 [RFC2597]
   AF12        = 001100=20 [RFC2597]
   AF13        = 001110=20 [RFC2597]
   AF21        = 010010=20 [RFC2597]
   AF22        = 010100=20 [RFC2597]
   AF23        = 010110=20 [RFC2597]
   AF31        = 011010=20 [RFC2597]
   AF32        = 011100=20 [RFC2597]
   AF33        = 011110=20 [RFC2597]
   AF41        = 100010=20 [RFC2597]
   AF42        = 100100=20 [RFC2597]
   AF43        = 100110=20 [RFC2597]
   EF PHB      101110=20 [RFC3246]
   VOICE-ADMIT 101100 [RFC5865]
 

Continuing with that thought: I believe this TC could (and = should) be=20
formalized into an IANA-Maintained MIB if these values are the = same
as=20 the above IANA-Maintained assignments for DFCPs. 
(NOTE: this = was=20 mentioned also in the LC comments.)  Please discuss.
 
Also, this TC should have a REFERENCE clause.
 

JEC:  Not done.   So, a REF clause to at least = explain=20 where MPLS OAM PHB is
described would be helpful. 
 

* mplsOamIdMegIndex
There is no information about how to = employ=20 mplsOamIdMegIndexNext to
obtain a value for this index.   = Please=20 update the DESCRIPTION accordingly.
 
JEC: Updated.
 
 
 
* mplsOamIdMegOperatorType
Why does this say "should have valid=20 values...", isn't this a MUST?
Also, s/while making/when/
 
JEC:  Updated.
 

* mplsOamIdMegIdCc
 
s/contains non-null ICC/MUST contain a/
 
s/otherwise null ICC value/otherwise a null ICC value/
 
s/should be assigned/MUST be assigned/
 

JEC:  Updated.
 

* mplsOamIdMegIdIcc
 
Same comments as above.   Please use MUST.
 
JEC:  Updated.
 

* mplsOamIdMegIdUmc
Same comments as above.  Please use = MUST.
 
JEC:  Updated.
 
 
 
* mplsOamIdMegServiceType
Could you please specify the service = pointer=20 by the object's name?
 
Also, the references are within the DESCRIPTION which is fine, = but
they=20 should also be in a REFERENCE clause.
 
JEC:  Updated.  I was asking that actual object names be = used in=20 this
DESCRIPTION clause.  For example, the phrase "the service=20 pointer
in the mplsOamIdMeTable" to change to THAT object's name, =
i.e.=20 mplsOamIdMeServicePointer.  Similar comment wrt the paragraph =
on the=20 pointer in PW.
 

* mplsOamIdMeIndexNext and mplsOamIdMpIndexNext
These = objects are=20 not referred to by mplsOamIdMeIndex or mplsOamIdMeMpIndex.
There is = not=20 enough description to understand how the IndexNext objects
are to be = used.=20
 
JEC:  Updated.
 

* MplsOamIdMeTable
 
The mplsOamIdMeEntry states "An entry in this table
represents = MPLS-TP=20 maintenance entity."   Yet, looking at the=20
           &nb= sp; =20 INDEX {=20 mplsOamIdMegIndex,
        &nb= sp;           &nbs= p;=20 mplsOamIdMeIndex,
        &nbs= p;            = ;=20 mplsOamIdMeMpIndex
        &nb= sp;          =20 }
 
This is not an ME because an ME by definition has 2=20 (source/sink)MEPs.
An entry in this table represents either a MEP or = MIP, not=20 an ME.
 
JEC: okay.
 

*) What is the benefit of combining MEP and MIP (i.e. the = objects=20
which contain "Mp" as part of their object name)?
Many other = objects in=20 this table, need to figure out if the entry
is describing a MEP or = MIP before=20 the value can be interpreted correctly.
Additionally, there is = duplicate info=20 in the form of having a Source and
Sink specified for each Mp. Could = you=20 elaborate on what the
benefit is of having listing MEPs and MIPs in = this=20 way?
 
It seems like the original intent may have been to specify an = ME
as=20 being an entry in this table.  However, that would mean the = table
should=20 probably be indexed by MEG index, a ME index, a source MEP index
and = a sink=20 MEP index.
 
This would  greatly simplify many of the object = descriptions. =20
 
Have you considered specifying MIPs in a 3rd table, such that = each
ME=20 would have 2 MEPs and zero or more MIPs?
 
Please discuss.  
 

JEC: okay.
 
 
 
*) mplsOamIdMeMpIfIndex
 
Rfc6370, Section 4.discusses an IF_NUM and an IF_ID and = states
"Note=20 that IF_Num had no relation with the ifNum object defined in =
RFC2863. =20 Further, no mapping is mandated between IF_Num and ifIndex in
RFC=20 2863."
 
I don't see any mention of ifIndex in RFC 6371, so could you tell = me=20 what
Section?   Is this object supposed to represent IF_NUM = in=20 rfc6370?
 
JEC: Not updated.   I think this is an oversight and you = had=20 already found
a correct REFERENCE but couldn't locate that email...
 

*) mplsOamIdMeServicePointer
 
The DESCRIPTION contains wording which is very loose.  Could=20 you
please use wording which specifies a "SHOULD" or "MUST"?
Under = what=20 circumstances should this be 0.0?
 
JEC: Updated.
 
Compliance Statement of the MIB
 
*) Compliance (This has been asked before and I have not
seen = any=20 discussion about it.)
 
There is no read-only compliance. Has it been made clear
to the = WGs=20 (MPLS and PWE3) that SNMP sets will need to
be supported in order to = be=20 compliant with the MIB?
 
JEC: Not done.
 

*) question above, about whether the intention is to = support
ifIndex=20 as per rfc2863 or IF_ID (or IF_NUM) as per rfc6370 may
affect = this.
 
      "MODULE IF-MIB -- The Interfaces = Group MIB,=20 RFC 2863.
      MANDATORY-GROUPS=20 {
        =20 ifGeneralInformationGroup,
       &= nbsp;=20 ifCounterDiscontinuityGroup"
 

*)    mplsOamIdNotificationObjectsGroup =20 OBJECT-GROUP
 
I don't see a need to make a specific group for
these = objects. =20 They are already specified by mplsOamIdGroups.
 
JEC:  Updated.
 

Section 8. Security Section
 
Need to reference specific read-create objects and also read-only = which=20
could impact the network.
 
Additionally, the incomplete sentence:
"These are the tables = and=20 objects and their sensitivity/vulnerability: "
needs to be = completed.
 
JEC: Not done.
 

Section 9.  IANA Considerations
 
s/specified this document/specified in this document/
missing = the word=20 "in"
 
JEC: Updated.
 

Section 11.
Thank you for the ack!
 
------=_NextPart_000_0C1C_01CEEF5E.DA34C9E0-- From lsmt@ietf.org Mon Dec 2 11:16:10 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 F0B591ADE89; Mon, 2 Dec 2013 11:16:09 -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 sBwIE9cAybcK; Mon, 2 Dec 2013 11:16:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2A1ACCEE; Mon, 2 Dec 2013 11:16:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: sshew@ciena.com X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131202191607.7758.4326.idtracker@ietfa.amsl.com> Date: Mon, 02 Dec 2013 11:16:07 -0800 Cc: mpls@ietf.org, Pseudowire Emulation Edge to Edge Discussion List , tsbsg15@itu.int, rcallon@juniper.net Subject: [mpls] New Liaison Statement, "Response to Liaison statement on clarifying Point to Multi Point (P2MP) combinations (to IETF PWE3 and MPLS WGs)" 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, 02 Dec 2013 19:16:10 -0000 Title: Response to Liaison statement on clarifying Point to Multi Point (P2= MP) combinations (to IETF PWE3 and MPLS WGs) Submission Date: 2013-11-27 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1295/ From: Pseudowire Emulation Edge to Edge (Matthew Bocci ) To: ITU-T SG15 Q10, Q12 (sshew@ciena.com) Cc: Andrew Malis ,Stewart Bryant ,Ad= rian Farrel ,Pseudowire Emulation Edge to Edge Discuss= ion List ,swallow@cisco.com,rcallon@juniper.net,jdra= ke@juniper.net,Scott.Mansfield@Ericsson.com,tsbsg15@itu.int,db3546@att.com,= mpls@ietf.org Reponse Contact: matthew.bocci@alcatel-lucent.com Technical Contact: matthew.bocci@alcatel-lucent.com Purpose: In response Referenced liaison: Liaison statement on clarifying Point to Multi Point (P= 2MP) combinations (to IETF PWE3 and MPLS WGs) (http://datatracker.ietf.org/= liaison/1274/) Body: Attachments: (none) Body: = Thank you for your liaison of July 2013 inquiring on the valid use of p2mp = pseudowires and LSPs. A new version of the Requirements and Framework for P= oint-to-Multipoint Pseudowires over MPLS PSNs" is available (see http://ww= w.ietf.org/id/draft-ietf-pwe3-p2mp-pw-requirements-06.txt) that should help= to clarify the points in your liaison. Additionally, point-to-point PWs are not intended to be used in conjunction= with P2MP LSPs. There is currently no way for the PEs terminating all of = the P2MP LSP leaves to establish the applicable PW/FEC label mappings. We = do not believe that this case is supported by the PWE3 architecture. The o= nly use case for P2MP PWs described in the draft referenced above is when u= sed with corresponding P2MP LSPs. Other more complex use cases are for furt= her study. If required, participants are encouraged to bring extensions to = this architecture to the PWE3 working group. Best regards, Matthew Bocci Andrew Malis IETF PWE3 Working Group Chairs Attachments: No document has been attached From ryoo@etri.re.kr Mon Dec 2 19:09:38 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 EC3421AD8D5 for ; Mon, 2 Dec 2013 19:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVYtG_CH5kph for ; Mon, 2 Dec 2013 19:09:35 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 703E91AD8CD for ; Mon, 2 Dec 2013 19:09:34 -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; Tue, 3 Dec 2013 12:09:20 +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, 3 Dec 2013 12:09:22 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Thread-Topic: the phrase meets the ITU-T's protection switching requirements in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHO7wng1Z11X3F5B0yH3XxVP1lpxZpBxX+N Date: Tue, 3 Dec 2013 03:09:22 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4@SMTP2.etri.info> References: <529BF66B.50405@pi.nu> In-Reply-To: <529BF66B.50405@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_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] the phrase meets the ITU-T's protection switching requirements 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: Tue, 03 Dec 2013 03:09:38 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLA0KDQpUaGUgSVRVLVQncyByZXF1aXJlbWVudHMgcmVmZXIgdG8gdGhlIHJlcXVpcmVtZW50 cyBzaG93biBpbiB0aGUgbGlhaXNvbiBzdGF0ZW1lbnRzIGZyb20gSVRVLVQNCihodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIwNSBhbmQgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9saWFpc29uLzEyMzQvICkNCg0KVGhvc2UgbGlhaXNvbiBzdGF0ZW1lbnRzIGhhZCBi ZWVuIGxpc3RlZCBhcyBpbmZvcm1hdGl2ZSByZWZlcmVuY2VzIGluIHRoZSBpbml0aWFsIHZlcnNp b25zIG9mIHRoZSBwcmV2aW91cyBkcmFmdHMgdGhhdCB3ZXJlIG1lcmdlZCBpbnRvIHRoZSBjdXJy ZW50IGRyYWZ0LiBEdXJpbmcgdGhlIE1QTFMtUlQgcmV2aWV3IHBlcmZvcm1lZCBmb3IgdGhlIHBy ZXZpb3VzIHNlcGFyYXRlIGRyYWZ0cyBpbiBBdWd1c3QsIGFuIGlzc3VlIHdpdGggcmVmZXJyaW5n IHRvIHRoZSBsaWFpc29uIHN0YXRlbWVudHMgd2FzIHJhaXNlZC4gSW4gb3JkZXIgdG8gcmVzb2x2 ZSB0aGUgaXNzdWUsIHRoZSByZWxhdmFudCBjb250ZW50cyBpbiB0aGUgbGlhaXNvbiBzdGF0ZW1l bnRzIGhhdmUgYmVlbiBtb3ZlZCB0byBBcHBlbmRpeCBhbmQgdGhlIHJlZmVyZW5jZXMgd2VyZSBl cmFzZWQuDQoNCkkgdGhpbmsgeW91ciBwb2ludCBpcyB2ZXJ5IHZhbGlkIGFuZCB0aGUgZG9jdW1l bnQgbmVlZHMgdG8gYmUgY2xlYXIgb24gd2hhdCB0aG9zZSByZXF1aXJlbWVudHMgYXJlLg0KDQpC ZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tIDogIkxvYSBBbmRlcnNzb24iIDxsb2FAcGkubnU+DQpTZW50IDogMjAx My0xMi0wMiAxMTo1NDo1MyAoICswOTowMCApDQpUbyA6IGRyYWZ0LWlldGYtbXBscy10cC1wc2Mt aXR1QHRvb2xzLmlldGYub3JnIDxkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRm Lm9yZz4NCkNjIDogbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4sIG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnIDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4sIFZJR09VUkVVWCwgTUFS VElOIChNQVJUSU4pIDxtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbT4NClN1Ympl Y3QgOiB0aGUgcGhyYXNlIG1lZXRzIHRoZSBJVFUtVCdzIHByb3RlY3Rpb24gc3dpdGNoaW5nIHJl cXVpcmVtZW50cyBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dQ0KDQoNCkVkaXRvcnMvQXV0 aG9ycywNCg0KSSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0IGRyYWZ0LWlldGYtbXBscy10cC1wc2Mt aXR1LiBUaGUgZG9jdW1lbnQgc2F5cw0KYXQgc2V2ZXJhbCBwbGFjZXMgIm1lZXRzIHRoZSBJVFUt VCdzIHByb3RlY3Rpb24gc3dpdGNoaW5nIHJlcXVpcmVtZW50cyINCnNvIEkgdGhvdWdodCBJIGdv IGxvb2sgdGhlc2UgcmVxdWlyZW1lbnRzIHVwLg0KDQpUbyBteSBzdXJwcmlzZSBJIGZvdW5kIHRo YXQgdGhlIG9ubHkgbXBscy10cCByZXF1aXJlbWVudCBkb2N1bWVudCB3ZQ0KYWN0dWFsbHkgcmVm ZXIgaXMgUkZDNTY1NC4NCg0KSSBkb24ndCB0aGluayB3ZSBjYW4gaGF2ZSBhbiBvcGVuIGVuZGVk IHJlZmVyZW5jZSB0byAiSVRVLVQncw0KcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcmVxdWlyZW1lbnRz IiBpZiB0aGV5IGFyZSBub3QgZG9jdW1lbnRlZC4NCg0KV2UgY291bGQgb2YgY291cnNlIGZpbmQg dGhlIGRvY3VtZW50IHRoYXQgbGlzdCB0aGUgIklUVS1UJ3MgcHJvdGVjdGlvbg0Kc3dpdGNoaW5n IHJlcXVpcmVtZW50cyIgYW5kIHJlZmVyZW5jZSB0aGF0IGRpcmVjdGx5Lg0KDQpIb3dldmVyIG15 IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gYWRkIHRleHQgdG8gdGhlIGludHJvZHVjdGlvbiB0aGUN CiJ0aGUgSVRVLVQncyBwcm90ZWN0aW9uIHN3aXRjaGluZyByZXF1aXJlbWVudHMiIHdlcmUgaW5j b3Jwb3JhdGVkIGluDQpSRkM1NjU0LCBhbmQgdGhlbiB3aGVyZSB5b3Ugbm93IHNheSAibWVldHMg dGhlIElUVS1UJ3MgcHJvdGVjdGlvbg0Kc3dpdGNoaW5nIHJlcXVpcmVtZW50cyIgaW5zdGVhZCBw b2ludCB0byBSRkM1NjU0IGFuZCB0aGUgZXhhY3QNCnJlcXVpcmVtZW50Lg0KDQovTG9hDQoNCi0t DQoNCg0KTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpTZW5pb3Ig TVBMUyBFeHBlcnQgbG9hQHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSBw aG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+VGhlIElUVS1UJ3MgcmVxdWlyZW1lbnRzIHJlZmVyIHRvIHRoZSByZXF1aXJlbWVudHMmbmJz cDtzaG93biBpbiB0aGUgbGlhaXNvbiBzdGF0ZW1lbnRzIGZyb20gSVRVLVQmbmJzcDs8YnI+DQoo PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMDUiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIwNTwvYT4g YW5kDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIzNC8i IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIz NC88L2E+Jm5ic3A7KTwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNw OzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPlRob3NlIGxpYWlzb24gc3Rh dGVtZW50cyBoYWQgYmVlbiBsaXN0ZWQgYXMgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcyBpbiB0aGUg aW5pdGlhbCB2ZXJzaW9ucyBvZiB0aGUgcHJldmlvdXMgZHJhZnRzIHRoYXQgd2VyZSBtZXJnZWQg aW50byB0aGUgY3VycmVudCBkcmFmdC4gRHVyaW5nIHRoZSBNUExTLVJUIHJldmlldyBwZXJmb3Jt ZWQgZm9yIHRoZSBwcmV2aW91cyZuYnNwO3NlcGFyYXRlIGRyYWZ0cyZuYnNwO2luDQogQXVndXN0 LCZuYnNwO2FuIGlzc3VlIHdpdGggcmVmZXJyaW5nIHRvIHRoZSBsaWFpc29uIHN0YXRlbWVudHMg d2FzIHJhaXNlZC4gSW4gb3JkZXIgdG8gcmVzb2x2ZSB0aGUgaXNzdWUsJm5ic3A7dGhlIHJlbGF2 YW50IGNvbnRlbnRzIGluIHRoZSBsaWFpc29uIHN0YXRlbWVudHMmbmJzcDtoYXZlIGJlZW4gbW92 ZWQgdG8gQXBwZW5kaXggYW5kIHRoZSZuYnNwO3JlZmVyZW5jZXMmbmJzcDt3ZXJlJm5ic3A7ZXJh c2VkLjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkkgdGhpbmsgeW91ciBwb2ludCBpcyB2ZXJ5 IHZhbGlkIGFuZCZuYnNwO3RoZSZuYnNwO2RvY3VtZW50Jm5ic3A7bmVlZHMgdG8gYmUgY2xlYXIg b24gd2hhdCB0aG9zZSByZXF1aXJlbWVudHMgYXJlLg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZu YnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRvbmc8L2Rp dj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5 bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0IiBpZD0iTWFpbFNpZ24iPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij48Yj5Gcm9tIDogPC9iPiZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsg Jmx0O2xvYUBwaS5udSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMtMTItMDIgMTE6NTQ6NTMg KCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dUB0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2MgOiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9y ZyZndDssIG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnICZsdDttcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZyZndDssIFZJR09VUkVVWCwgTUFSVElOIChNQVJUSU4pICZsdDttYXJ0aW4udmlnb3Vy ZXV4QGFsY2F0ZWwtbHVjZW50LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0IDogPC9iPnRoZSBwaHJh c2UgbWVldHMgdGhlIElUVS1UJ3MgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcmVxdWlyZW1lbnRzIGlu IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1PGJyPg0KPGJyPg0KPGJyPg0KRWRpdG9ycy9BdXRo b3JzLDxicj4NCjxicj4NCkkndmUgYmVlbiB0aGlua2luZyBhYm91dCBkcmFmdC1pZXRmLW1wbHMt dHAtcHNjLWl0dS4gVGhlIGRvY3VtZW50IHNheXM8YnI+DQphdCBzZXZlcmFsIHBsYWNlcyAmcXVv dDttZWV0cyB0aGUgSVRVLVQncyBwcm90ZWN0aW9uIHN3aXRjaGluZyByZXF1aXJlbWVudHMmcXVv dDs8YnI+DQpzbyBJIHRob3VnaHQgSSBnbyBsb29rIHRoZXNlIHJlcXVpcmVtZW50cyB1cC48YnI+ DQo8YnI+DQpUbyBteSBzdXJwcmlzZSBJIGZvdW5kIHRoYXQgdGhlIG9ubHkgbXBscy10cCByZXF1 aXJlbWVudCBkb2N1bWVudCB3ZTxicj4NCmFjdHVhbGx5IHJlZmVyIGlzIFJGQzU2NTQuPGJyPg0K PGJyPg0KSSBkb24ndCB0aGluayB3ZSBjYW4gaGF2ZSBhbiBvcGVuIGVuZGVkIHJlZmVyZW5jZSB0 byAmcXVvdDtJVFUtVCdzPGJyPg0KcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcmVxdWlyZW1lbnRzJnF1 b3Q7IGlmIHRoZXkgYXJlIG5vdCBkb2N1bWVudGVkLjxicj4NCjxicj4NCldlIGNvdWxkIG9mIGNv dXJzZSBmaW5kIHRoZSBkb2N1bWVudCB0aGF0IGxpc3QgdGhlICZxdW90O0lUVS1UJ3MgcHJvdGVj dGlvbjxicj4NCnN3aXRjaGluZyByZXF1aXJlbWVudHMmcXVvdDsgYW5kIHJlZmVyZW5jZSB0aGF0 IGRpcmVjdGx5Ljxicj4NCjxicj4NCkhvd2V2ZXIgbXkgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBh ZGQgdGV4dCB0byB0aGUgaW50cm9kdWN0aW9uIHRoZTxicj4NCiZxdW90O3RoZSBJVFUtVCdzIHBy b3RlY3Rpb24gc3dpdGNoaW5nIHJlcXVpcmVtZW50cyZxdW90OyB3ZXJlIGluY29ycG9yYXRlZCBp bjxicj4NClJGQzU2NTQsIGFuZCB0aGVuIHdoZXJlIHlvdSBub3cgc2F5ICZxdW90O21lZXRzIHRo ZSBJVFUtVCdzIHByb3RlY3Rpb248YnI+DQpzd2l0Y2hpbmcgcmVxdWlyZW1lbnRzJnF1b3Q7IGlu c3RlYWQgcG9pbnQgdG8gUkZDNTY1NCBhbmQgdGhlIGV4YWN0PGJyPg0KcmVxdWlyZW1lbnQuPGJy Pg0KPGJyPg0KL0xvYTxicj4NCjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNz b24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxicj4NClNlbmlvciBNUExTIEV4cGVydCBs b2FAcGkubnU8YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogJiM0 Mzs0NiA3MzkgODEgMjEgNjQ8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4SMTP2etriinfo_-- From rcallon@juniper.net Tue Dec 3 16:40:36 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 264E41AE190 for ; Tue, 3 Dec 2013 16:40:36 -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 Mk3DCQVLqi7y for ; Tue, 3 Dec 2013 16:40:34 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA901ADD02 for ; Tue, 3 Dec 2013 16:40:34 -0800 (PST) Received: from mail63-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 00:40:31 +0000 Received: from mail63-va3 (localhost [127.0.0.1]) by mail63-va3-R.bigfish.com (Postfix) with ESMTP id 07EB54C0274; Wed, 4 Dec 2013 00:40:31 +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: -18 X-BigFish: VPS-18(zzzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail63-va3: 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:(199002)(189002)(49866001)(74662001)(81686001)(83322001)(83072001)(80022001)(81342001)(66066001)(87266001)(47976001)(19580395003)(2656002)(81542001)(65816001)(54356001)(74316001)(4396001)(56776001)(81816001)(85852002)(74502001)(19580405001)(80976001)(69226001)(47446002)(63696002)(50986001)(46102001)(31966008)(76176001)(76576001)(59766001)(33646001)(85306002)(77982001)(53806001)(76482001)(51856001)(74366001)(76786001)(54316002)(79102001)(47736001)(74876001)(76796001)(87936001)(90146001)(74706001)(56816005)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.16; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail63-va3 (localhost.localdomain [127.0.0.1]) by mail63-va3 (MessageSwitch) id 1386117629298328_17299; Wed, 4 Dec 2013 00:40:29 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.226]) by mail63-va3.bigfish.com (Postfix) with ESMTP id 435AE4E0062; Wed, 4 Dec 2013 00:40:29 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 00:40:29 +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.383.1; Wed, 4 Dec 2013 00:40:29 +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.820.5; Wed, 4 Dec 2013 00:40:26 +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.0820.005; Wed, 4 Dec 2013 00:40:26 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO8Ilsdxvw6W4DfkSXFkfIGRLzvg== Date: Wed, 4 Dec 2013 00:40:25 +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.16] x-forefront-prvs: 0050CEFE70 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" , "draft-ietf-mpls-moving-iana-registries@tools.ietf.org" Subject: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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: Wed, 04 Dec 2013 00:40:36 -0000 Working Group; =20 This is to start a two week working group last call on draft-ietf-mpls-moving-iana-registries-00.txt. Please send your comment to the working group mailing list (mpls@ietf.org). We did an IPR poll on this document in September. The authors each responde= d to the=20 IPR poll that they not aware of any IPR relating to this document. There ar= e no IPRs=20 disclosed against this document. The working group last call will end Wednesday December 18, 2013. Ross (as mpls wg co-chair) From loa@pi.nu Wed Dec 4 06:55:40 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 F2F8B1AE281 for ; Wed, 4 Dec 2013 06:55:39 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpG3aprcERwQ for ; Wed, 4 Dec 2013 06:55:37 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 09FE81AE283 for ; Wed, 4 Dec 2013 06:55:37 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.94.158]) (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 42B0618015AB; Wed, 4 Dec 2013 15:55:30 +0100 (CET) Message-ID: <529F425C.1050808@pi.nu> Date: Wed, 04 Dec 2013 22:55:24 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Dec 2013 14:55:40 -0000 Working Group, It has been pointed out that there is overlap between draft-wijnands-mpls-mldp-in-band-wildcard-encoding and draft-rekhter-mpls-pim-sm-over-mldp. Within the overlap there is a critical piece of the protocol specification. Having this specified in two places is likely to result in non-interoperable implementations. The working group chairs have discussed the overlap and propose the following as a means of moving forward. 1. Issue a single poll to adopt both documents together as working group documents 2. Assuming that the drafts are adopted, complete draft-wijnands-mpls-in-band-wildcard-encoding as the normative protocol specification of the piece within the overlap. 3. Where mechanisms in draft-wijnanads are needed in draft-rekhter-mpls-pim-sm-over-mldp have the latter document reference the necessary sections of the former document. MPLS Working Group Chairs Loa, Ross, George -- 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 Wed Dec 4 11:52:47 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 D6F6A1AE17E for ; Wed, 4 Dec 2013 11:52:47 -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 YlHsWQmBZnGD for ; Wed, 4 Dec 2013 11:52:46 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id CEA061AD957 for ; Wed, 4 Dec 2013 11:52:45 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id p61so15511544wes.36 for ; Wed, 04 Dec 2013 11:52:42 -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=a/0bysDVHSnu6tZqPeYamAJBpRCH5aAw8mom1ZnqxqU=; b=MJxkQ5iUbPSLwXVU6QQE4fnMnNrMIXSYYNuWrFvhLWTxqnRy0g5PfLkgQlzIHNA5xa wnypw71fiG1fWlcWEHRpjlYhS4d6O1LllYuWy2DDK3hLrT/MVsC77iCZeyqTQj6CdtCc zsKu058XbJyOD0f/i9BRFPJYIOX0rr8RRuU4srqD2fCcvX1Gt3azjup5Uiopx41idnLQ VkDcGwTyZYaKFMq/FjKyXOjnZ8SuEkbFSv0JQFt0BjIfj/hwLRWUrywYUtBYM66BNue/ LECxl1WLmFXv8qSIbzOQdTDWvrKHlRvp9NLIyKRFMVXKIsf8bFQaHxiNzazCRr+9TyUI dxJA== X-Received: by 10.194.85.75 with SMTP id f11mr13980031wjz.14.1386186762080; Wed, 04 Dec 2013 11:52:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.127.68 with HTTP; Wed, 4 Dec 2013 11:52:21 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Wed, 4 Dec 2013 14:52:21 -0500 Message-ID: To: Ross Callon Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-moving-iana-registries@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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: Wed, 04 Dec 2013 19:52:48 -0000 As I've previously remarked, but bears repeating at this time, this is draft does a very useful cleanup of IANA registries that had been created organically over the years. Cheers, Andy On Tue, Dec 3, 2013 at 7:40 PM, Ross Callon wrote: > Working Group; > > This is to start a two week working group last call on > draft-ietf-mpls-moving-iana-registries-00.txt. > > Please send your comment to the working group mailing list (mpls@ietf.org). > > We did an IPR poll on this document in September. The authors each responded to the > IPR poll that they not aware of any IPR relating to this document. There are no IPRs > disclosed against this document. > > The working group last call will end Wednesday December 18, 2013. > > Ross > (as mpls wg co-chair) > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From iesg-secretary@ietf.org Thu Dec 5 14:19:55 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 082831AE21D; Thu, 5 Dec 2013 14:19:55 -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 jpzz_Bpt7r_B; Thu, 5 Dec 2013 14:19:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 085241AE228; Thu, 5 Dec 2013 14:19:49 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131205221949.25931.15595.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2013 14:19:49 -0800 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Return Path Specified LSP Ping' to Proposed Standard (draft-ietf-mpls-return-path-specified-lsp-ping-15.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, 05 Dec 2013 22:19:55 -0000 The IESG has approved the following document: - 'Return Path Specified LSP Ping' (draft-ietf-mpls-return-path-specified-lsp-ping-15.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-return-path-specified-lsp-ping/ Technical Summary 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 selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. Working Group Summary There has not been anything in the working group process that needs to be mentioned, other than we had a strong support to accept it as a working group draft, after that the discussion on the mailing were low for almost a year, but has pick up lately and we have had a good discussion, where all comments been focused on improving the and no indication that the draft is not needed. The document has support in the working group, and operators has participated in writing it, and has been well reviewed. After improving the IANA section (mostly off-line) the document shepherd now believes we have a stable document ready to be published. A further two months' discussion focused on a discussion of the IANA section of this document. We have earlier made "early allocations" of code points for this document, after discussion we have decided not use them, but reuse (identical) sub-TLVs allocated by RFC4379. A spin-off of the IANA discussion for this document is that we are discussing/thiking of writing an update to the IANA allocation of RFC4379. The AD review raised still further issues with the IANA section and this delayed the document by many months while the working group grappled with an understanding of how the registries were supposed to work. Agreement has finally been reached leading to the latest revision and a new draft in the working group to clarify the registries for future generations. Document Quality This is a very minor update to the LSP-Ping that does not have any affect on the operations of existing LSP Ping implementations and deployments, even if nodes with the new functionality are introduced. The working group mailing list has been polled for existing implementations and intentions to implement this specification. We know of vendors that intend to implement and at least one operator that plans to deploy this functionality. Personnel Loa Andersson (loa@pi.nu) is the document shepherd. Adrian Farrel (adrian@olddog.co.uk) is the responsible AD. RFC Editor Note Section 3.2. OLD The A bit and B bit set MUST NOT both be set NEW The A flag and B flag MUST NOT both be set Section 6.4 OLD The range of 0x0008-0xfffb is not allocated and reserved for future extensions and is allocated via Standard Action, the range of 0xfffc- 0xffff is for Experimental Use. NEW The range of 0x0006-0xfffb is not allocated and reserved for future extensions and is allocated via Standard Action, the range of 0xfffc- 0xffff is for Experimental Use. END === IANA Note IANA, please see the text in the RFC Editor Note From loa@pi.nu Thu Dec 5 23:11:44 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 79F101ADF86 for ; Thu, 5 Dec 2013 23:11:44 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWTopBCc3tz5 for ; Thu, 5 Dec 2013 23:11:40 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7991A1F1A for ; Thu, 5 Dec 2013 23:11:40 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.94.158]) (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 3048618015C4; Fri, 6 Dec 2013 08:11:33 +0100 (CET) Message-ID: <52A178A2.9000309@pi.nu> Date: Fri, 06 Dec 2013 15:11:30 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Ryoo, Jeong-dong" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" References: <529BF66B.50405@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4@SMTP2.etri.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] the phrase "meets the ITU-T's protection switching requirements" 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: Fri, 06 Dec 2013 07:11:44 -0000 Jeong-dong, The requirement text in the two liaisons are weak, most of is not requirements at all. Do you say that RFC5654 is not complete when it comes to linear protection switching and it is not possible to map what is specified in draft-ietf-mpls-tp-psc-itu ot RFC5654. Or do you say that draft-ietf-mpls-tp-psc-itu have alternative ways of meeting the same requirements. If it is the first case, we would need to do an update to RFC5564, I hope that such an update is litmited to a simple additions and not require changes to 5654. If it is the latter case, you should proceed to do the mapping to RFC5654. /Loa On 2013-12-03 11:09, Ryoo, Jeong-dong wrote: > Loa, > The ITU-T's requirements refer to the requirements shown in the liaison > statements from ITU-T > (https://datatracker.ietf.org/liaison/1205 and > https://datatracker.ietf.org/liaison/1234/ ) > Those liaison statements had been listed as informative references in > the initial versions of the previous drafts that were merged into the > current draft. During the MPLS-RT review performed for the > previous separate drafts in August, an issue with referring to the > liaison statements was raised. In order to resolve the issue, the > relavant contents in the liaison statements have been moved to Appendix > and the references were erased. > I think your point is very valid and the document needs to be clear on > what those requirements are. > Best regards, > Jeong-dong > > ------------------------------------------------------------------------ > *From : *"Loa Andersson" > *Sent : *2013-12-02 11:54:53 ( +09:00 ) > *To : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org > > *Cc : *mpls@ietf.org , mpls-chairs@tools.ietf.org > , VIGOUREUX, MARTIN (MARTIN) > > *Subject : *the phrase meets the ITU-T's protection switching > requirements in draft-ietf-mpls-tp-psc-itu > > > Editors/Authors, > > I've been thinking about draft-ietf-mpls-tp-psc-itu. The document says > at several places "meets the ITU-T's protection switching requirements" > so I thought I go look these requirements up. > > To my surprise I found that the only mpls-tp requirement document we > actually refer is RFC5654. > > I don't think we can have an open ended reference to "ITU-T's > protection switching requirements" if they are not documented. > > We could of course find the document that list the "ITU-T's protection > switching requirements" and reference that directly. > > However my preference would be to add text to the introduction the > "the ITU-T's protection switching requirements" were incorporated in > RFC5654, and then where you now say "meets the ITU-T's protection > switching requirements" instead point to RFC5654 and the exact > requirement. > > /Loa > > -- > > > 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 ice@cisco.com Fri Dec 6 02:57:15 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 695961ADE7C for ; Fri, 6 Dec 2013 02:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 OYGELC4sgG0G for ; Fri, 6 Dec 2013 02:57:13 -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 89A731AD9AD for ; Fri, 6 Dec 2013 02:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1483; q=dns/txt; s=iport; t=1386327430; x=1387537030; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tIsleuDPBVIHsxTGZvIb7WvJa84zlSM1EVyVHDIgo7o=; b=lBcfuWhKeJbqm5hIqetshZJm+WasPMCWSEjt+7LhAr309sjCySh4W40k SRxrP28ZLTiuYvMOSwtX/sO5wyZBbZE34sWcSnsRp8fi7AIYf+wEULqp7 69cB0TBG06mLNdkgsmBAuo9k0d4HZaO3UhWTFxw+PiY0JC4s9pPKhRsPE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAECsoVKQ/khM/2dsb2JhbABZgwc4uU+BJBZ0giUBAQEDAQEBATcxAwsOAgtGGwwwBhOHfAYNwHoTBASOGhEBUAeDIIETA5gUkhODKjuBNQ X-IronPort-AV: E=Sophos;i="4.93,840,1378857600"; d="scan'208";a="1778356" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 06 Dec 2013 10:57:09 +0000 Received: from ams-iwijnand-87111.cisco.com (ams-iwijnand-87111.cisco.com [10.55.191.156]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB6Av5PN019589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 10:57:05 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: IJsbrand Wijnands In-Reply-To: <529F425C.1050808@pi.nu> Date: Fri, 6 Dec 2013 11:57:05 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1C5DE0E4-4B11-4098-AF69-C7A01E9D34BF@cisco.com> References: <529F425C.1050808@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1510) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Dec 2013 10:57:15 -0000 Dear Chairs, I agree with the proposed resolution below. Thx, Ice. On 04 Dec 2013, at 15:55, Loa Andersson wrote: > > Working Group, > > It has been pointed out that there is overlap between > draft-wijnands-mpls-mldp-in-band-wildcard-encoding and > draft-rekhter-mpls-pim-sm-over-mldp. Within the overlap > there is a critical piece of the protocol specification. > Having this specified in two places is likely to result > in non-interoperable implementations. > > The working group chairs have discussed the overlap and > propose the following as a means of moving forward. > > 1. Issue a single poll to adopt both documents together as > working group documents > > 2. Assuming that the drafts are adopted, complete > draft-wijnands-mpls-in-band-wildcard-encoding as the > normative protocol specification of the piece within the > overlap. > > 3. Where mechanisms in draft-wijnanads are needed in > draft-rekhter-mpls-pim-sm-over-mldp have the latter document > reference the necessary sections of the former document. > > MPLS Working Group Chairs > Loa, Ross, George > > -- > > > 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 jeff.tantsura@ericsson.com Fri Dec 6 03:00: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 9DEFA1AE331 for ; Fri, 6 Dec 2013 03:00: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 ykxAqzxU1KL1 for ; Fri, 6 Dec 2013 03:00:14 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6A01AE32F for ; Fri, 6 Dec 2013 03:00:14 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-9a-52a1ae38f893 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 22.9E.04556.83EA1A25; Fri, 6 Dec 2013 12:00:08 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0347.000; Fri, 6 Dec 2013 06:00:08 -0500 From: Jeff Tantsura To: Loa Andersson Thread-Topic: [mpls] Way two progress two mldp draft with an technical overlap Thread-Index: AQHO8QDs22/+FaBAR0yv1dxJjMYFnJpHVZyA//96uIA= Date: Fri, 6 Dec 2013 11:00:07 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C748399EC0E2@eusaamb109.ericsson.se> In-Reply-To: <1C5DE0E4-4B11-4098-AF69-C7A01E9D34BF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <2F0E09816D786A4AB1BD7EE2831766A9@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPuK7FuoVBBlfWWlo0f/W2mLr4K6vF v7lzmC2+X1rCYnFr6UpWB1aPJUt+MnnMmt7G5vHl8me2AOYoLpuU1JzMstQifbsErozmK/PY C+bxVhz79pK5gfEyVxcjJ4eEgIlE1/UmZghbTOLCvfVsXYxcHEICRxglrnUvYIFwljFKzFyz mw2kik3AQOL/t+MsILaIgKzEtW0/mUCKmAXuMEkcXneNESQhLOAr0XW0G6ooQOLa251sELaV xKppp8DiLAIqEn+W3mfvYuTg4BXwllg7QQMkzClgK7H//HxWEJsR6KLvp9YwgdjMAuISt57M Z4K4VEBiyZ7zUFeLSrx8/A+sXlRAT6Lt2Bl2iLiyxPc5j1ggenUkFuz+xAZhW0ucO7qOHcLW lli28DXYHF4BQYmTM5+wTGAUn4Vk3Swk7bOQtM9C0j4LSfsCRtZVjBylxalluelGhpsYgdF3 TILNcQfjgk+WhxilOViUxHm/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAo/8J/ZWDf 3f5figFcK2d0Huys3rKlKjX1XqMS/6T3co/v8hc/XSK1ZpIQX7y/1LE1xbyMLju+nVY+XH/T x2vP/2eROQbBiV2NUed5PvXE73b2sPt9u+nnaYPLZ8U36ImuDbmR3PkhRXy/yrR2s9NfVwRv K+D/+f23Uv97XZ+KHxdZM/xeyh1SYinOSDTUYi4qTgQANHbyo4wCAAA= Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Dec 2013 11:00:16 -0000 Dear Chairs, I agree and fully support the solution proposed. Cheers, Jeff > >On 04 Dec 2013, at 15:55, Loa Andersson wrote: > >>=20 >> Working Group, >>=20 >> It has been pointed out that there is overlap between >> draft-wijnands-mpls-mldp-in-band-wildcard-encoding and >> draft-rekhter-mpls-pim-sm-over-mldp. Within the overlap >> there is a critical piece of the protocol specification. >> Having this specified in two places is likely to result >> in non-interoperable implementations. >>=20 >> The working group chairs have discussed the overlap and >> propose the following as a means of moving forward. >>=20 >> 1. Issue a single poll to adopt both documents together as >> working group documents >>=20 >> 2. Assuming that the drafts are adopted, complete >> draft-wijnands-mpls-in-band-wildcard-encoding as the >> normative protocol specification of the piece within the >> overlap. >>=20 >> 3. Where mechanisms in draft-wijnanads are needed in >> draft-rekhter-mpls-pim-sm-over-mldp have the latter document >> reference the necessary sections of the former document. >>=20 >> MPLS Working Group Chairs >> Loa, Ross, George >>=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 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From yakov@juniper.net Fri Dec 6 06:05:50 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 4AA4A1ADFC5 for ; Fri, 6 Dec 2013 06:05:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHpM-zcyKcJg for ; Fri, 6 Dec 2013 06:05:48 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 2741D1ADFB5 for ; Fri, 6 Dec 2013 06:05:48 -0800 (PST) Received: from mail103-db9-R.bigfish.com (10.174.16.242) by DB9EHSOBE036.bigfish.com (10.174.14.99) with Microsoft SMTP Server id 14.1.225.22; Fri, 6 Dec 2013 14:05:43 +0000 Received: from mail103-db9 (localhost [127.0.0.1]) by mail103-db9-R.bigfish.com (Postfix) with ESMTP id 82508C0509; Fri, 6 Dec 2013 14:05:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h1155h) Received-SPF: softfail (mail103-db9: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail103-db9 (localhost.localdomain [127.0.0.1]) by mail103-db9 (MessageSwitch) id 1386338740741965_10364; Fri, 6 Dec 2013 14:05:40 +0000 (UTC) Received: from DB9EHSMHS027.bigfish.com (unknown [10.174.16.252]) by mail103-db9.bigfish.com (Postfix) with ESMTP id AAEBC2A0278; Fri, 6 Dec 2013 14:05:40 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by DB9EHSMHS027.bigfish.com (10.174.14.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 6 Dec 2013 14:05:40 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Dec 2013 06:05:38 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id rB6E5bL25339; Fri, 6 Dec 2013 06:05:37 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201312061405.rB6E5bL25339@magenta.juniper.net> To: Loa Andersson In-Reply-To: <529F425C.1050808@pi.nu> References: <529F425C.1050808@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Wed, 04 Dec 2013 22:55:24 +0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63153.1386338736.1@juniper.net> Date: Fri, 6 Dec 2013 06:05:36 -0800 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Dec 2013 14:05:50 -0000 Loa, > Working Group, > > It has been pointed out that there is overlap between > draft-wijnands-mpls-mldp-in-band-wildcard-encoding and > draft-rekhter-mpls-pim-sm-over-mldp. Within the overlap > there is a critical piece of the protocol specification. > Having this specified in two places is likely to result > in non-interoperable implementations. > > The working group chairs have discussed the overlap and > propose the following as a means of moving forward. > > 1. Issue a single poll to adopt both documents together as > working group documents > > 2. Assuming that the drafts are adopted, complete > draft-wijnands-mpls-in-band-wildcard-encoding as the > normative protocol specification of the piece within the > overlap. > > 3. Where mechanisms in draft-wijnanads are needed in > draft-rekhter-mpls-pim-sm-over-mldp have the latter document > reference the necessary sections of the former document. This would be fine with me, *provided* that draft-wijnands-mpls-in-band-wildcard-encoding will add the encoding of two new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit IPv6 Shared Tree TLV, as these two TLVs are required by the mechanisms defined in draft-rekhter-mpls-pim-sm-over-mldp. Yakov. From internet-drafts@ietf.org Fri Dec 6 08:27:09 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 B5A271AE090; Fri, 6 Dec 2013 08:27:09 -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=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 2iJjErmSc4x8; Fri, 6 Dec 2013 08:26:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 112DB1AE054; Fri, 6 Dec 2013 08:26:57 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206162656.5652.36569.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 08:26:56 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-wijnands-mpls-mldp-in-band-wildcard-encoding-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, 06 Dec 2013 16:27:09 -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 Author(s) : IJsbrand Wijnands Eric Rosen Arkadiy Gulko Uwe Joorde Jeff Tantsura Filename : draft-wijnands-mpls-mldp-in-band-wildcard-encoding-02.txt Pages : 15 Date : 2013-12-06 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-wijnands-mpls-mldp-in-band-wildcar= d-encoding-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 aldrin.ietf@gmail.com Fri Dec 6 08:36:26 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 3D9C01ADFFB; Fri, 6 Dec 2013 08:36:26 -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 b9atDEGsyImz; Fri, 6 Dec 2013 08:36:22 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4697F1AE08D; Fri, 6 Dec 2013 08:36:22 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id z10so1289515pdj.2 for ; Fri, 06 Dec 2013 08:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=63EEgcxpjmRai9C3kC2awt38Bwl1AVjNVlbAXmLmrLQ=; b=ojbIZTkz/R7uI23WEiYl1eufl9apvCsA0pLh3MvFyrrK0MEx31k3HbdfXyA681YMEh Z7nGmGmZyTxL0Wol5LQz2pViUbu3LsnhavHW9AJCrcgJpOz1VfQrZ6LtTs6RlEempmlj UDTDZZsolaKWaEgxadMpSngBqo+t66Y3S84IflQaskSYlPNc7d3jZ6HFZs6mqkzGo1XO MObJwpNVQPCX2pfWJ53591556bGvC3eLHu96JajbGbFLmE88iG1q9w5KNM0FZrS/6fr9 X+c/LxgYywGw8vZ9cVf7QzmrsP17nAJOHQ4NY/Y0HKyRtzdTZuq+D9KLTGrLcLROJsDk Jk9w== X-Received: by 10.66.158.132 with SMTP id wu4mr5264467pab.66.1386347778520; Fri, 06 Dec 2013 08:36:18 -0800 (PST) Received: from [192.168.1.5] (c-107-3-154-8.hsd1.ca.comcast.net. [107.3.154.8]) by mx.google.com with ESMTPSA id bh6sm67391458pad.20.2013.12.06.08.36.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 08:36:17 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D94C6DA-7FA7-4F4E-873B-9A53B7699503" From: Sam Aldrin X-Priority: 3 In-Reply-To: <0c1f01ceef88$c40ead50$6901a8c0@JoanPC> Date: Fri, 6 Dec 2013 08:36:17 -0800 Message-Id: <300E5E7E-97F6-41A1-9EB0-8645D87C7189@gmail.com> References: <00fe01ce1ed2$72981ce0$6801a8c0@JoanPC> <0c1f01ceef88$c40ead50$6901a8c0@JoanPC> To: Joan Cucchiara X-Mailer: Apple Mail (2.1822) Cc: mpls , "MIB Doctors \(E-mail\)" , Ping Pan , Sami Boutros , Thomas Nadeau , Kannan Sampath , Venkatesan Mahalingam Subject: Re: [mpls] MIB Dr. review of draft-ietf-mpls-tp-oam-id-mib-03.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, 06 Dec 2013 16:36:26 -0000 --Apple-Mail=_9D94C6DA-7FA7-4F4E-873B-9A53B7699503 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Joan, Once again, thank you for your review and valuable comments. Will address them at the earliest. thanks again -sam On Dec 2, 2013, at 10:03 AM, Joan Cucchiara = wrote: >=20 > Authors, > =20 > For this review, I looked over the comments from 02 to see how these = comments were addressed.=20 > (Version 02 comments are copied below and comments for Version 03 are = prefaced with JEC.) > =20 > As you can see most of the Version 02 comments have been addressed, so = thank you for that! > =20 > A few comments from 02 have not been updated in version 03. > The 3 comments which I think needs some attention are: > =20 > 1) MplsOamPhbTCValue=20 > Textual Convention should have a reference within MPLS. Even if the = values have been assigned by > the authors, an indication of where BHP Traffic Classes are derived = from within MPLS OAM seems > reasonable. =20 >=20 > 2) mplsOamIdMeMpIfIndex > The REFERENCE for RFC6371 doesn't seem to refer to this object. Could=20= > REFERENCE be checked? (I thought a change here was agreed to but = didn't see an updated REF.) > =20 > 3) No ReadOnly conformance. Please confirm that WG is agreeable to > have a MIB that does not have a ReadOnly Conformance. > As you are aware, some operators prefer not to use SNMP=20 > for configuration, so if this MIB does not support a ReadOnly = Conformance, > then vendors will not be compliant if they support this MIB as it > exists now. > =20 > 4) Security Section (see below). > =20 >=20 > Thanks, > -Joan > =20 > =20 > =20 > Specific Comments on this version 03 are prefaced with JEC: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > Section 3.3 Acronyms > =20 >=20 > * MIP is specified slightly differently in the referenced docs. > Please be consistant. > =20 > JEC: Updated. > =20 >=20 > Section 6. > =20 > This example, specifies the mplsOamIdMeMpEntry as a MEP, but why=20 > isn't the SourceMepIndex or SinkMepIndex =3D=3D mplsOamIdMeMpIndex? > =20 > Also, there are at least 2 MEPs in an ME, and at least one ME > in a MEG and these relationships are not completely evolved > in this example. I think the example should be expanded > to agree with what is stated in the first paragraph. > =20 >=20 > JEC: The example was not evolved, but the first text was modified > to agree with the example, so I can live with that. > =20 > =20 > =20 > MIB Module comments > ------------------- > =20 > * TC: MplsOamPhbTCValue > =20 >=20 > MplsOamPhbTCValue ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This is the Per-hop Behavior (PHB) traffic class = values > for the MPLS OAM operations." > SYNTAX INTEGER { > be (1), > af1 (2), > af2 (3), > af3 (4), > af4 (5), > ef (6), > cs6 (7), > cs7 (8) > } > =20 >=20 > Rfc3270, "Multi-Protocol Label Switching (MPLS) Support of=20 > Differentiated Services", specifies that MPLS TP will use DSCP as per=20= > rfc2474 and other specs. Is that the intent wrt this TC? > =20 > If not, please explain where these values are defined, otherwise,=20 > if these values are as per rfc3270, then please be consistant with the = labels. > =20 > TC labels should correspond more closely to DiffServ BHB traffic class = values. > In other words, > =20 > http://www.iana.org/assignments/dscp-registry/dscp-registry.xml > =20 > Name Space Reference > CS0 000000 [RFC2474] > CS1 001000 [RFC2474] > CS2 010000 [RFC2474] > CS3 011000 [RFC2474] > CS4 100000 [RFC2474] > CS5 101000 [RFC2474] > CS6 110000 [RFC2474] > CS7 111000 [RFC2474] > AF11 001010 [RFC2597] > AF12 001100 [RFC2597] > AF13 001110 [RFC2597] > AF21 010010 [RFC2597] > AF22 010100 [RFC2597] > AF23 010110 [RFC2597] > AF31 011010 [RFC2597] > AF32 011100 [RFC2597] > AF33 011110 [RFC2597] > AF41 100010 [RFC2597] > AF42 100100 [RFC2597] > AF43 100110 [RFC2597] > EF PHB 101110 [RFC3246] > VOICE-ADMIT 101100 [RFC5865] > =20 >=20 > Continuing with that thought: I believe this TC could (and should) be=20= > formalized into an IANA-Maintained MIB if these values are the same > as the above IANA-Maintained assignments for DFCPs. =20 > (NOTE: this was mentioned also in the LC comments.) Please discuss. > =20 > Also, this TC should have a REFERENCE clause. > =20 >=20 > JEC: Not done. So, a REF clause to at least explain where MPLS OAM = PHB is > described would be helpful.=20 > =20 >=20 > * mplsOamIdMegIndex > There is no information about how to employ mplsOamIdMegIndexNext to=20= > obtain a value for this index. Please update the DESCRIPTION = accordingly. > =20 > JEC: Updated. > =20 > =20 > =20 > * mplsOamIdMegOperatorType > Why does this say "should have valid values...", isn't this a MUST? > Also, s/while making/when/ > =20 > JEC: Updated. > =20 >=20 > * mplsOamIdMegIdCc > =20 > s/contains non-null ICC/MUST contain a/ > =20 > s/otherwise null ICC value/otherwise a null ICC value/ > =20 > s/should be assigned/MUST be assigned/ > =20 >=20 > JEC: Updated. > =20 >=20 > * mplsOamIdMegIdIcc > =20 > Same comments as above. Please use MUST. > =20 > JEC: Updated. > =20 >=20 > * mplsOamIdMegIdUmc > Same comments as above. Please use MUST. > =20 > JEC: Updated. > =20 > =20 > =20 > * mplsOamIdMegServiceType > Could you please specify the service pointer by the object's name? > =20 > Also, the references are within the DESCRIPTION which is fine, but > they should also be in a REFERENCE clause. > =20 > JEC: Updated. I was asking that actual object names be used in this > DESCRIPTION clause. For example, the phrase "the service pointer > in the mplsOamIdMeTable" to change to THAT object's name,=20 > i.e. mplsOamIdMeServicePointer. Similar comment wrt the paragraph=20 > on the pointer in PW. > =20 >=20 > * mplsOamIdMeIndexNext and mplsOamIdMpIndexNext > These objects are not referred to by mplsOamIdMeIndex or = mplsOamIdMeMpIndex. > There is not enough description to understand how the IndexNext = objects > are to be used. > =20 > JEC: Updated. > =20 >=20 > * MplsOamIdMeTable > =20 > The mplsOamIdMeEntry states "An entry in this table > represents MPLS-TP maintenance entity." Yet, looking at the=20 > INDEX { mplsOamIdMegIndex, > mplsOamIdMeIndex, > mplsOamIdMeMpIndex > } > =20 > This is not an ME because an ME by definition has 2 (source/sink)MEPs. > An entry in this table represents either a MEP or MIP, not an ME. > =20 > JEC: okay. > =20 >=20 > *) What is the benefit of combining MEP and MIP (i.e. the objects=20 > which contain "Mp" as part of their object name)? > Many other objects in this table, need to figure out if the entry > is describing a MEP or MIP before the value can be interpreted = correctly. > Additionally, there is duplicate info in the form of having a Source = and > Sink specified for each Mp. Could you elaborate on what the=20 > benefit is of having listing MEPs and MIPs in this way? > =20 > It seems like the original intent may have been to specify an ME > as being an entry in this table. However, that would mean the table > should probably be indexed by MEG index, a ME index, a source MEP = index=20 > and a sink MEP index. > =20 > This would greatly simplify many of the object descriptions.=20 > =20 > Have you considered specifying MIPs in a 3rd table, such that each > ME would have 2 MEPs and zero or more MIPs? > =20 > Please discuss. =20 > =20 >=20 > JEC: okay. > =20 > =20 > =20 > *) mplsOamIdMeMpIfIndex > =20 > Rfc6370, Section 4.discusses an IF_NUM and an IF_ID and states > "Note that IF_Num had no relation with the ifNum object defined in=20 > RFC2863. Further, no mapping is mandated between IF_Num and ifIndex = in > RFC 2863." > =20 > I don't see any mention of ifIndex in RFC 6371, so could you tell me = what > Section? Is this object supposed to represent IF_NUM in rfc6370? > =20 > JEC: Not updated. I think this is an oversight and you had already = found > a correct REFERENCE but couldn't locate that email... > =20 >=20 > *) mplsOamIdMeServicePointer > =20 > The DESCRIPTION contains wording which is very loose. Could you > please use wording which specifies a "SHOULD" or "MUST"? > Under what circumstances should this be 0.0? > =20 > JEC: Updated. > =20 > Compliance Statement of the MIB > =20 > *) Compliance (This has been asked before and I have not > seen any discussion about it.) > =20 > There is no read-only compliance. Has it been made clear > to the WGs (MPLS and PWE3) that SNMP sets will need to > be supported in order to be compliant with the MIB? > =20 > JEC: Not done. > =20 >=20 > *) question above, about whether the intention is to support > ifIndex as per rfc2863 or IF_ID (or IF_NUM) as per rfc6370 may > affect this. > =20 > "MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. > MANDATORY-GROUPS { > ifGeneralInformationGroup, > ifCounterDiscontinuityGroup" > =20 >=20 > *) mplsOamIdNotificationObjectsGroup OBJECT-GROUP > =20 > I don't see a need to make a specific group for > these objects. They are already specified by mplsOamIdGroups. > =20 > JEC: Updated. > =20 >=20 > Section 8. Security Section > =20 > Need to reference specific read-create objects and also read-only = which=20 > could impact the network. > =20 > Additionally, the incomplete sentence:=20 > "These are the tables and objects and their sensitivity/vulnerability: = " > needs to be completed. > =20 > JEC: Not done. > =20 >=20 > Section 9. IANA Considerations > =20 > s/specified this document/specified in this document/ > missing the word "in" > =20 > JEC: Updated. > =20 >=20 > Section 11.=20 > Thank you for the ack! > =20 --Apple-Mail=_9D94C6DA-7FA7-4F4E-873B-9A53B7699503 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Joan,

Once again, thank you for your review and = valuable comments.
Will address them at the = earliest.

thanks = again
-sam
On Dec 2, 2013, at 10:03 AM, = Joan Cucchiara <jcucchiara@mindspring.com>= ; wrote:


Authors,
 
For this = review, I looked over the  comments from 02 to see how = these comments were addressed. 
(Version 02 comments are = copied below and comments for Version 03 are prefaced with = JEC.)
 
As you can see most of the Version 02 = comments have been addressed, so thank you for = that!
 
A few comments from 02 have not been = updated in version 03.
The 3 comments which I think needs some = attention are:
 
1) = MplsOamPhbTCValue 
Textual Convention should have a reference = within MPLS.    Even if the values have been assigned = by
the authors, an indication of where BHP Traffic Classes are = derived from within MPLS OAM = seems
reasonable.  

2) = mplsOamIdMeMpIfIndex
The REFERENCE for RFC6371 doesn't seem to refer = to this object. Could 
REFERENCE be = checked?  (I thought a change here was agreed to but didn't see an = updated REF.)
 
3) No ReadOnly = conformance.  Please confirm that WG is agreeable to
have a MIB = that does not have a ReadOnly Conformance.
As you are = aware, some operators prefer not to use SNMP 
for configuration, so = if this MIB does not support a ReadOnly Conformance,
then vendors = will not be compliant if they support this MIB as it
exists = now.
 
4) Security Section (see = below).
 

Thanks,
  = -Joan
 
 
 
Specifi= c Comments on this version 03 are prefaced with  = JEC:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Section 3.3 = Acronyms
 

* MIP is specified slightly = differently in the referenced docs.
Please be = consistant.
 
JEC: = Updated.
 

Section = 6.
 
This example, specifies the = mplsOamIdMeMpEntry as a MEP, but why 
isn't the = SourceMepIndex or SinkMepIndex =3D=3D = mplsOamIdMeMpIndex?
 
Also, there are at least = 2 MEPs in an ME, and at least one ME
in a MEG and these relationships = are not completely evolved
in this example.  I think the example = should be expanded
to agree with what is stated in the first = paragraph.
 

JEC:  The example was not = evolved, but the first text was modified
to agree with the example, = so I can live with = that.
 
 
 
MIB = Module comments
-------------------
 
* = TC:  = MplsOamPhbTCValue
 

    &= nbsp;    MplsOamPhbTCValue ::=3D = TEXTUAL-CONVENTION
        &nbs= p;   = STATUS           &n= bsp;  = current
          &nb= sp; = DESCRIPTION
          = ;      "This is the Per-hop Behavior (PHB) = traffic class = values
          &nbs= p;      for the MPLS OAM = operations."
         &nbs= p;  SYNTAX        INTEGER = {
           &nb= sp;            = ;    be = (1),
           =             &n= bsp;    af1 = (2),
           =             &n= bsp;    af2 = (3),
           =             &n= bsp;    af3 = (4),
           =             &n= bsp;    af4 = (5),
           =             &n= bsp;    ef = (6),
           =             &n= bsp;    cs6 = (7),
           =             &n= bsp;    cs7 = (8)
           &= nbsp;           &nb= sp;  }
 

Rfc3270, "Multi-Protocol = Label Switching (MPLS) Support of 
Differentiated = Services", specifies that MPLS TP will use DSCP as per 
rfc2474 and other = specs.   Is that the intent wrt this = TC?
 
If not, please explain where these values = are defined, otherwise, 
if these values are as = per rfc3270, then please be consistant with the = labels.
 
TC labels should correspond more = closely to DiffServ BHB traffic class values.
In other = words,
 
 
   Name     = Space  Reference
   = CS0         000000 = [RFC2474]
   = CS1         001000 = [RFC2474]
   = CS2         010000 = [RFC2474]
   = CS3         011000 = [RFC2474]
   = CS4         100000 = [RFC2474]
   = CS5         101000 = [RFC2474]
   = CS6         110000 = [RFC2474]
   = CS7         111000 = [RFC2474]
   AF11        = 001010 [RFC2597]
   = AF12        001100 = [RFC2597]
   AF13        = 001110 [RFC2597]
   = AF21        010010 = [RFC2597]
   AF22        = 010100 [RFC2597]
   = AF23        010110 = [RFC2597]
   AF31        = 011010 [RFC2597]
   = AF32        011100 = [RFC2597]
   AF33        = 011110 [RFC2597]
   = AF41        100010 = [RFC2597]
   AF42        = 100100 [RFC2597]
   = AF43        100110 = [RFC2597]
   EF PHB      101110 = [RFC3246]
   VOICE-ADMIT 101100 = [RFC5865]
 

Continuing with that thought: I = believe this TC could (and should) be 
formalized into an = IANA-Maintained MIB if these values are the same
as the above = IANA-Maintained assignments for DFCPs.  
(NOTE: this was = mentioned also in the LC comments.)  Please = discuss.
 
Also, this TC should have a = REFERENCE clause.
 

JEC:  Not = done.   So, a REF clause to at least explain where MPLS OAM = PHB is
described would be = helpful. 
 

* = mplsOamIdMegIndex
There is no information about how to employ = mplsOamIdMegIndexNext to 
obtain a value for this = index.   Please update the DESCRIPTION = accordingly.
 
JEC: = Updated.
 
 
 
* = mplsOamIdMegOperatorType
Why does this say "should have valid = values...", isn't this a MUST?
Also, s/while = making/when/
 
JEC:  = Updated.
 

* = mplsOamIdMegIdCc
 
s/contains non-null ICC/MUST = contain a/
 
s/otherwise null ICC = value/otherwise a null ICC value/
 
s/should be = assigned/MUST be assigned/
 

JEC:  = Updated.
 

* = mplsOamIdMegIdIcc
 
Same comments as = above.   Please use = MUST.
 
JEC:  = Updated.
 

* mplsOamIdMegIdUmc
Same = comments as above.  Please use = MUST.
 
JEC:  = Updated.
 
 
 
* = mplsOamIdMegServiceType
Could you please specify the service pointer = by the object's name?
 
Also, the references = are within the DESCRIPTION which is fine, but
they should also be in = a REFERENCE clause.
 
JEC:  Updated.  = I was asking that actual object names be used in this
DESCRIPTION = clause.  For example, the phrase "the service pointer
in the = mplsOamIdMeTable" to change to THAT object's name, 
i.e. = mplsOamIdMeServicePointer.  Similar comment wrt the paragraph 
on the pointer in = PW.
 

* mplsOamIdMeIndexNext and = mplsOamIdMpIndexNext
These objects are not referred to by = mplsOamIdMeIndex or mplsOamIdMeMpIndex.
There is not enough = description to understand how the IndexNext objects
are to be = used.
 
JEC:  = Updated.
 

* = MplsOamIdMeTable
 
The mplsOamIdMeEntry states = "An entry in this table
represents MPLS-TP maintenance = entity."   Yet, looking at the 
    &= nbsp;         INDEX { = mplsOamIdMegIndex,
        &nbs= p;            = = mplsOamIdMeIndex,
         = ;             = mplsOamIdMeMpIndex
        &nbs= p;           = }
 
This is not an ME because an ME by = definition has 2 (source/sink)MEPs.
An entry in this table represents = either a MEP or MIP, not an ME.
 
JEC: = okay.
 

*) What is the benefit of combining = MEP and MIP (i.e. the objects 
which contain "Mp" as = part of their object name)?
Many other objects in this table, need to = figure out if the entry
is describing a MEP or MIP before the value = can be interpreted correctly.
Additionally, there is duplicate info = in the form of having a Source and
Sink specified for each Mp. Could = you elaborate on what the 
benefit is of having = listing MEPs and MIPs in this way?
 
It seems = like the original intent may have been to specify an ME
as being an = entry in this table.  However, that would mean the table
should = probably be indexed by MEG index, a ME index, a source MEP index 
and a sink MEP = index.
 
This would  greatly simplify many = of the object descriptions. 
 
Have you = considered specifying MIPs in a 3rd table, such that each
ME would = have 2 MEPs and zero or more MIPs?
 
Please = discuss.  
 

JEC: = okay.
 
 
 
*) = mplsOamIdMeMpIfIndex
 
Rfc6370, Section = 4.discusses an IF_NUM and an IF_ID and states
"Note that IF_Num had = no relation with the ifNum object defined in 
RFC2863.  Further, = no mapping is mandated between IF_Num and ifIndex in
RFC = 2863."
 
I don't see any mention of ifIndex in = RFC 6371, so could you tell me what
Section?   Is this = object supposed to represent IF_NUM in = rfc6370?
 
JEC: Not updated.   I = think this is an oversight and you had already = found
a correct REFERENCE but couldn't locate that = email...
 

*) = mplsOamIdMeServicePointer
 
The DESCRIPTION = contains wording which is very loose.  Could you
please use = wording which specifies a "SHOULD" or "MUST"?
Under what = circumstances should this be 0.0?
 
JEC: = Updated.
 
Compliance Statement of the = MIB
 
*) Compliance (This has been asked before = and I have not
seen any discussion about = it.)
 
There is no read-only compliance. Has it = been made clear
to the WGs (MPLS and PWE3) that SNMP sets will need = to
be supported in order to be compliant with the = MIB?
 
JEC: Not = done.
 

*) question above, about whether = the intention is to support
ifIndex as per rfc2863 or IF_ID (or = IF_NUM) as per rfc6370 may
affect = this.
 
      "MODULE = IF-MIB -- The Interfaces Group MIB, RFC = 2863.
      MANDATORY-GROUPS = {
         = ifGeneralInformationGroup,
       &n= bsp; = ifCounterDiscontinuityGroup"
 

*)  =   mplsOamIdNotificationObjectsGroup  = OBJECT-GROUP
 
I don't see a need to make a = specific group for
these objects.  They are already specified by = mplsOamIdGroups.
 
JEC:  = Updated.
 

Section 8. Security = Section
 
Need to reference specific = read-create objects and also read-only which 
could impact the = network.
 
Additionally, the incomplete = sentence: 
"These = are the tables and objects and their sensitivity/vulnerability: = "
needs to be completed.
 
JEC: Not = done.
 

Section 9.  IANA = Considerations
 
s/specified this = document/specified in this document/
missing the word = "in"
 
JEC: = Updated.
 

Section 11. 
Thank you for the = ack!
 
= --Apple-Mail=_9D94C6DA-7FA7-4F4E-873B-9A53B7699503-- From ryoo@etri.re.kr Sat Dec 7 18:00:27 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 E9B601AE479 for ; Sat, 7 Dec 2013 18:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Hov_KoYgtuh for ; Sat, 7 Dec 2013 18:00:24 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA821AE172 for ; Sat, 7 Dec 2013 18:00:23 -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; Sun, 8 Dec 2013 11:00:15 +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; Sun, 8 Dec 2013 11:00:10 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Thread-Topic: the phrase "meets the ITU-T's protection switching requirements" in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHO8lJqFBAmLfCReEKIQ6yq2S6Nm5pJi3Xf Date: Sun, 8 Dec 2013 02:00:09 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD0EF@SMTP2.etri.info> References: <529BF66B.50405@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4@SMTP2.etri.info>, <52A178A2.9000309@pi.nu> In-Reply-To: <52A178A2.9000309@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.44] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AD0EFSMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] the phrase "meets the ITU-T's protection switching requirements" 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: Sun, 08 Dec 2013 02:00:27 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AD0EFSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLA0KDQpJIGhhdmUgYmVlbiB0aGlua2luZyBhYm91dCBob3cgdG8gYW5zd2VyIHlvdXIgcXVl c3Rpb24uDQpUaGlzIGlzIGEgZGlmZmljdWx0IHF1ZXN0aW9uIGZvciBtZS4NCkkgd291bGQgbGlr ZSB0byBoYXZlIG9waW5pb25zIGZyb20gdGhlIG90aGVyIGVkaXRvciBhbmQgYXV0aG9ycy4NCg0K QmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb20gOiAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4NClNlbnQgOiAyMDEz LTEyLTA2IDE2OjExOjQyICggKzA5OjAwICkNClRvIDogUnlvbywgSmVvbmctZG9uZyA8cnlvb0Bl dHJpLnJlLmtyPiwgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcgPGRy YWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPg0KQ2MgOiBtcGxzQGlldGYu b3JnIDxtcGxzQGlldGYub3JnPiwgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgPG1wbHMtY2hh aXJzQHRvb2xzLmlldGYub3JnPiwgVklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTikgPG1hcnRpbi52 aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tPg0KU3ViamVjdCA6IFJlOiB0aGUgcGhyYXNlICJt ZWV0cyB0aGUgSVRVLVQncyBwcm90ZWN0aW9uIHN3aXRjaGluZyByZXF1aXJlbWVudHMiIGluIGRy YWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQoNCg0KSmVvbmctZG9uZywNCg0KVGhlIHJlcXVpcmVt ZW50IHRleHQgaW4gdGhlIHR3byBsaWFpc29ucyBhcmUgd2VhaywgbW9zdCBvZiBpcyBub3QNCnJl cXVpcmVtZW50cyBhdCBhbGwuDQoNCkRvIHlvdSBzYXkgdGhhdCBSRkM1NjU0IGlzIG5vdCBjb21w bGV0ZSB3aGVuIGl0IGNvbWVzIHRvIGxpbmVhcg0KcHJvdGVjdGlvbiBzd2l0Y2hpbmcgYW5kIGl0 IGlzIG5vdCBwb3NzaWJsZSB0byBtYXAgd2hhdCBpcyBzcGVjaWZpZWQgaW4NCmRyYWZ0LWlldGYt bXBscy10cC1wc2MtaXR1IG90IFJGQzU2NTQuDQoNCk9yIGRvIHlvdSBzYXkgdGhhdCBkcmFmdC1p ZXRmLW1wbHMtdHAtcHNjLWl0dSBoYXZlIGFsdGVybmF0aXZlIHdheXMgb2YNCm1lZXRpbmcgdGhl IHNhbWUgcmVxdWlyZW1lbnRzLg0KDQpJZiBpdCBpcyB0aGUgZmlyc3QgY2FzZSwgd2Ugd291bGQg bmVlZCB0byBkbyBhbiB1cGRhdGUgdG8gUkZDNTU2NCwgSQ0KaG9wZSB0aGF0IHN1Y2ggYW4gdXBk YXRlIGlzIGxpdG1pdGVkIHRvIGEgc2ltcGxlIGFkZGl0aW9ucyBhbmQgbm90DQpyZXF1aXJlIGNo YW5nZXMgdG8gNTY1NC4NCg0KSWYgaXQgaXMgdGhlIGxhdHRlciBjYXNlLCB5b3Ugc2hvdWxkIHBy b2NlZWQgdG8gZG8gdGhlIG1hcHBpbmcgdG8NClJGQzU2NTQuDQoNCi9Mb2ENCg0KT24gMjAxMy0x Mi0wMyAxMTowOSwgUnlvbywgSmVvbmctZG9uZyB3cm90ZToNCj4gTG9hLA0KPiBUaGUgSVRVLVQn cyByZXF1aXJlbWVudHMgcmVmZXIgdG8gdGhlIHJlcXVpcmVtZW50cyBzaG93biBpbiB0aGUgbGlh aXNvbg0KPiBzdGF0ZW1lbnRzIGZyb20gSVRVLVQNCj4gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbGlhaXNvbi8xMjA1IGFuZA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xp YWlzb24vMTIzNC8gKQ0KPiBUaG9zZSBsaWFpc29uIHN0YXRlbWVudHMgaGFkIGJlZW4gbGlzdGVk IGFzIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMgaW4NCj4gdGhlIGluaXRpYWwgdmVyc2lvbnMgb2Yg dGhlIHByZXZpb3VzIGRyYWZ0cyB0aGF0IHdlcmUgbWVyZ2VkIGludG8gdGhlDQo+IGN1cnJlbnQg ZHJhZnQuIER1cmluZyB0aGUgTVBMUy1SVCByZXZpZXcgcGVyZm9ybWVkIGZvciB0aGUNCj4gcHJl dmlvdXMgc2VwYXJhdGUgZHJhZnRzIGluIEF1Z3VzdCwgYW4gaXNzdWUgd2l0aCByZWZlcnJpbmcg dG8gdGhlDQo+IGxpYWlzb24gc3RhdGVtZW50cyB3YXMgcmFpc2VkLiBJbiBvcmRlciB0byByZXNv bHZlIHRoZSBpc3N1ZSwgdGhlDQo+IHJlbGF2YW50IGNvbnRlbnRzIGluIHRoZSBsaWFpc29uIHN0 YXRlbWVudHMgaGF2ZSBiZWVuIG1vdmVkIHRvIEFwcGVuZGl4DQo+IGFuZCB0aGUgcmVmZXJlbmNl cyB3ZXJlIGVyYXNlZC4NCj4gSSB0aGluayB5b3VyIHBvaW50IGlzIHZlcnkgdmFsaWQgYW5kIHRo ZSBkb2N1bWVudCBuZWVkcyB0byBiZSBjbGVhciBvbg0KPiB3aGF0IHRob3NlIHJlcXVpcmVtZW50 cyBhcmUuDQo+IEJlc3QgcmVnYXJkcywNCj4gSmVvbmctZG9uZw0KPg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gKkZyb20gOiAqIkxvYSBBbmRlcnNzb24iDQo+ICpTZW50IDogKjIwMTMtMTItMDIgMTE6 NTQ6NTMgKCArMDk6MDAgKQ0KPiAqVG8gOiAqZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9v bHMuaWV0Zi5vcmcNCj4NCj4gKkNjIDogKm1wbHNAaWV0Zi5vcmcgLCBtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZw0KPiAsIFZJR09VUkVVWCwgTUFSVElOIChNQVJUSU4pDQo+DQo+ICpTdWJqZWN0 IDogKnRoZSBwaHJhc2UgbWVldHMgdGhlIElUVS1UJ3MgcHJvdGVjdGlvbiBzd2l0Y2hpbmcNCj4g cmVxdWlyZW1lbnRzIGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQo+DQo+DQo+IEVkaXRv cnMvQXV0aG9ycywNCj4NCj4gSSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0IGRyYWZ0LWlldGYtbXBs cy10cC1wc2MtaXR1LiBUaGUgZG9jdW1lbnQgc2F5cw0KPiBhdCBzZXZlcmFsIHBsYWNlcyAibWVl dHMgdGhlIElUVS1UJ3MgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcmVxdWlyZW1lbnRzIg0KPiBzbyBJ IHRob3VnaHQgSSBnbyBsb29rIHRoZXNlIHJlcXVpcmVtZW50cyB1cC4NCj4NCj4gVG8gbXkgc3Vy cHJpc2UgSSBmb3VuZCB0aGF0IHRoZSBvbmx5IG1wbHMtdHAgcmVxdWlyZW1lbnQgZG9jdW1lbnQg d2UNCj4gYWN0dWFsbHkgcmVmZXIgaXMgUkZDNTY1NC4NCj4NCj4gSSBkb24ndCB0aGluayB3ZSBj YW4gaGF2ZSBhbiBvcGVuIGVuZGVkIHJlZmVyZW5jZSB0byAiSVRVLVQncw0KPiBwcm90ZWN0aW9u IHN3aXRjaGluZyByZXF1aXJlbWVudHMiIGlmIHRoZXkgYXJlIG5vdCBkb2N1bWVudGVkLg0KPg0K PiBXZSBjb3VsZCBvZiBjb3Vyc2UgZmluZCB0aGUgZG9jdW1lbnQgdGhhdCBsaXN0IHRoZSAiSVRV LVQncyBwcm90ZWN0aW9uDQo+IHN3aXRjaGluZyByZXF1aXJlbWVudHMiIGFuZCByZWZlcmVuY2Ug dGhhdCBkaXJlY3RseS4NCj4NCj4gSG93ZXZlciBteSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGFk ZCB0ZXh0IHRvIHRoZSBpbnRyb2R1Y3Rpb24gdGhlDQo+ICJ0aGUgSVRVLVQncyBwcm90ZWN0aW9u IHN3aXRjaGluZyByZXF1aXJlbWVudHMiIHdlcmUgaW5jb3Jwb3JhdGVkIGluDQo+IFJGQzU2NTQs IGFuZCB0aGVuIHdoZXJlIHlvdSBub3cgc2F5ICJtZWV0cyB0aGUgSVRVLVQncyBwcm90ZWN0aW9u DQo+IHN3aXRjaGluZyByZXF1aXJlbWVudHMiIGluc3RlYWQgcG9pbnQgdG8gUkZDNTY1NCBhbmQg dGhlIGV4YWN0DQo+IHJlcXVpcmVtZW50Lg0KPg0KPiAvTG9hDQo+DQo+IC0tDQo+DQo+DQo+IExv YSBBbmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5pb3IgTVBMUyBF eHBlcnQgbG9hQHBpLm51DQo+IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpIHBob25l OiArNDYgNzM5IDgxIDIxIDY0DQoNCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1h aWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51DQpIdWF3ZWkgVGVj aG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AD0EFSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+SSBoYXZlIGJlZW4gdGhpbmtpbmcgYWJvdXQgaG93IHRvIGFuc3dlciB5b3VyIHF1ZXN0aW9u LjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPg0KPGRpdiBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQiPlRoaXMgaXMgYSBkaWZmaWN1bHQgcXVlc3Rpb24gZm9yIG1lLiA8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkkgd291bGQgbGlrZSB0 byBoYXZlJm5ic3A7b3BpbmlvbnMgZnJvbSB0aGUgb3RoZXIgZWRpdG9yIGFuZCBhdXRob3JzLg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0KQmVzdCByZWdhcmRz LDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRvbmc8L2Rpdj4NCjxkaXYgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0IiBpZD0iTWFpbFNpZ24iPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij48Yj5Gcm9tIDogPC9iPiZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgJmx0 O2xvYUBwaS5udSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMtMTItMDYgMTY6MTE6NDIgKCAm IzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5SeW9vLCBKZW9uZy1kb25nICZsdDtyeW9vQGV0 cmkucmUua3ImZ3Q7LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyAm bHQ7ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ Q2MgOiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssIG1wbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnICZsdDttcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyZndDssIFZJR09V UkVVWCwgTUFSVElOIChNQVJUSU4pICZsdDttYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50 LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0IDogPC9iPlJlOiB0aGUgcGhyYXNlICZxdW90O21lZXRz IHRoZSBJVFUtVCdzIHByb3RlY3Rpb24gc3dpdGNoaW5nIHJlcXVpcmVtZW50cyZxdW90OyBpbiBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxicj4NCjxicj4NCjxicj4NCkplb25nLWRvbmcsPGJy Pg0KPGJyPg0KVGhlIHJlcXVpcmVtZW50IHRleHQgaW4gdGhlIHR3byBsaWFpc29ucyBhcmUgd2Vh aywgbW9zdCBvZiBpcyBub3Q8YnI+DQpyZXF1aXJlbWVudHMgYXQgYWxsLjxicj4NCjxicj4NCkRv IHlvdSBzYXkgdGhhdCBSRkM1NjU0IGlzIG5vdCBjb21wbGV0ZSB3aGVuIGl0IGNvbWVzIHRvIGxp bmVhcjxicj4NCnByb3RlY3Rpb24gc3dpdGNoaW5nIGFuZCBpdCBpcyBub3QgcG9zc2libGUgdG8g bWFwIHdoYXQgaXMgc3BlY2lmaWVkIGluPGJyPg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUg b3QgUkZDNTY1NC48YnI+DQo8YnI+DQpPciBkbyB5b3Ugc2F5IHRoYXQgZHJhZnQtaWV0Zi1tcGxz LXRwLXBzYy1pdHUgaGF2ZSBhbHRlcm5hdGl2ZSB3YXlzIG9mPGJyPg0KbWVldGluZyB0aGUgc2Ft ZSByZXF1aXJlbWVudHMuPGJyPg0KPGJyPg0KSWYgaXQgaXMgdGhlIGZpcnN0IGNhc2UsIHdlIHdv dWxkIG5lZWQgdG8gZG8gYW4gdXBkYXRlIHRvIFJGQzU1NjQsIEkgPGJyPg0KaG9wZSB0aGF0IHN1 Y2ggYW4gdXBkYXRlIGlzIGxpdG1pdGVkIHRvIGEgc2ltcGxlIGFkZGl0aW9ucyBhbmQgbm90IDxi cj4NCnJlcXVpcmUgY2hhbmdlcyB0byA1NjU0Ljxicj4NCjxicj4NCklmIGl0IGlzIHRoZSBsYXR0 ZXIgY2FzZSwgeW91IHNob3VsZCBwcm9jZWVkIHRvIGRvIHRoZSBtYXBwaW5nIHRvPGJyPg0KUkZD NTY1NC48YnI+DQo8YnI+DQovTG9hPGJyPg0KPGJyPg0KT24gMjAxMy0xMi0wMyAxMTowOSwgUnlv bywgSmVvbmctZG9uZyB3cm90ZTo8YnI+DQomZ3Q7IExvYSw8YnI+DQomZ3Q7IFRoZSBJVFUtVCdz IHJlcXVpcmVtZW50cyByZWZlciB0byB0aGUgcmVxdWlyZW1lbnRzIHNob3duIGluIHRoZSBsaWFp c29uPGJyPg0KJmd0OyBzdGF0ZW1lbnRzIGZyb20gSVRVLVQ8YnI+DQomZ3Q7IChodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIwNSBhbmQ8YnI+DQomZ3Q7IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjM0LyApPGJyPg0KJmd0OyBUaG9zZSBsaWFpc29u IHN0YXRlbWVudHMgaGFkIGJlZW4gbGlzdGVkIGFzIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMgaW48 YnI+DQomZ3Q7IHRoZSBpbml0aWFsIHZlcnNpb25zIG9mIHRoZSBwcmV2aW91cyBkcmFmdHMgdGhh dCB3ZXJlIG1lcmdlZCBpbnRvIHRoZTxicj4NCiZndDsgY3VycmVudCBkcmFmdC4gRHVyaW5nIHRo ZSBNUExTLVJUIHJldmlldyBwZXJmb3JtZWQgZm9yIHRoZTxicj4NCiZndDsgcHJldmlvdXMgc2Vw YXJhdGUgZHJhZnRzIGluIEF1Z3VzdCwgYW4gaXNzdWUgd2l0aCByZWZlcnJpbmcgdG8gdGhlPGJy Pg0KJmd0OyBsaWFpc29uIHN0YXRlbWVudHMgd2FzIHJhaXNlZC4gSW4gb3JkZXIgdG8gcmVzb2x2 ZSB0aGUgaXNzdWUsIHRoZTxicj4NCiZndDsgcmVsYXZhbnQgY29udGVudHMgaW4gdGhlIGxpYWlz b24gc3RhdGVtZW50cyBoYXZlIGJlZW4gbW92ZWQgdG8gQXBwZW5kaXg8YnI+DQomZ3Q7IGFuZCB0 aGUgcmVmZXJlbmNlcyB3ZXJlIGVyYXNlZC48YnI+DQomZ3Q7IEkgdGhpbmsgeW91ciBwb2ludCBp cyB2ZXJ5IHZhbGlkIGFuZCB0aGUgZG9jdW1lbnQgbmVlZHMgdG8gYmUgY2xlYXIgb248YnI+DQom Z3Q7IHdoYXQgdGhvc2UgcmVxdWlyZW1lbnRzIGFyZS48YnI+DQomZ3Q7IEJlc3QgcmVnYXJkcyw8 YnI+DQomZ3Q7IEplb25nLWRvbmc8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQomZ3Q7ICpGcm9tIDogKiZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgPExPQUBQSS5OVT48 YnI+DQomZ3Q7ICpTZW50IDogKjIwMTMtMTItMDIgMTE6NTQ6NTMgKCAmIzQzOzA5OjAwICk8YnI+ DQomZ3Q7ICpUbyA6ICpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZzxi cj4NCiZndDsgPERSQUZULUlFVEYtTVBMUy1UUC1QU0MtSVRVQFRPT0xTLklFVEYuT1JHPjxicj4N CiZndDsgKkNjIDogKm1wbHNAaWV0Zi5vcmcgPE1QTFNASUVURi5PUkc+LCBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZzxicj4NCiZndDsgPE1QTFMtQ0hBSVJTQFRPT0xTLklFVEYuT1JHPiwgVklH T1VSRVVYLCBNQVJUSU4gKE1BUlRJTik8YnI+DQomZ3Q7IDxNQVJUSU4uVklHT1VSRVVYQEFMQ0FU RUwtTFVDRU5ULkNPTT48YnI+DQomZ3Q7ICpTdWJqZWN0IDogKnRoZSBwaHJhc2UgbWVldHMgdGhl IElUVS1UJ3MgcHJvdGVjdGlvbiBzd2l0Y2hpbmc8YnI+DQomZ3Q7IHJlcXVpcmVtZW50cyBpbiBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBF ZGl0b3JzL0F1dGhvcnMsPGJyPg0KJmd0Ozxicj4NCiZndDsgSSd2ZSBiZWVuIHRoaW5raW5nIGFi b3V0IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LiBUaGUgZG9jdW1lbnQgc2F5czxicj4NCiZn dDsgYXQgc2V2ZXJhbCBwbGFjZXMgJnF1b3Q7bWVldHMgdGhlIElUVS1UJ3MgcHJvdGVjdGlvbiBz d2l0Y2hpbmcgcmVxdWlyZW1lbnRzJnF1b3Q7PGJyPg0KJmd0OyBzbyBJIHRob3VnaHQgSSBnbyBs b29rIHRoZXNlIHJlcXVpcmVtZW50cyB1cC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUbyBteSBzdXJw cmlzZSBJIGZvdW5kIHRoYXQgdGhlIG9ubHkgbXBscy10cCByZXF1aXJlbWVudCBkb2N1bWVudCB3 ZTxicj4NCiZndDsgYWN0dWFsbHkgcmVmZXIgaXMgUkZDNTY1NC48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJIGRvbid0IHRoaW5rIHdlIGNhbiBoYXZlIGFuIG9wZW4gZW5kZWQgcmVmZXJlbmNlIHRvICZx dW90O0lUVS1UJ3M8YnI+DQomZ3Q7IHByb3RlY3Rpb24gc3dpdGNoaW5nIHJlcXVpcmVtZW50cyZx dW90OyBpZiB0aGV5IGFyZSBub3QgZG9jdW1lbnRlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZSBj b3VsZCBvZiBjb3Vyc2UgZmluZCB0aGUgZG9jdW1lbnQgdGhhdCBsaXN0IHRoZSAmcXVvdDtJVFUt VCdzIHByb3RlY3Rpb248YnI+DQomZ3Q7IHN3aXRjaGluZyByZXF1aXJlbWVudHMmcXVvdDsgYW5k IHJlZmVyZW5jZSB0aGF0IGRpcmVjdGx5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEhvd2V2ZXIgbXkg cHJlZmVyZW5jZSB3b3VsZCBiZSB0byBhZGQgdGV4dCB0byB0aGUgaW50cm9kdWN0aW9uIHRoZTxi cj4NCiZndDsgJnF1b3Q7dGhlIElUVS1UJ3MgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgcmVxdWlyZW1l bnRzJnF1b3Q7IHdlcmUgaW5jb3Jwb3JhdGVkIGluPGJyPg0KJmd0OyBSRkM1NjU0LCBhbmQgdGhl biB3aGVyZSB5b3Ugbm93IHNheSAmcXVvdDttZWV0cyB0aGUgSVRVLVQncyBwcm90ZWN0aW9uPGJy Pg0KJmd0OyBzd2l0Y2hpbmcgcmVxdWlyZW1lbnRzJnF1b3Q7IGluc3RlYWQgcG9pbnQgdG8gUkZD NTY1NCBhbmQgdGhlIGV4YWN0PGJyPg0KJmd0OyByZXF1aXJlbWVudC48YnI+DQomZ3Q7PGJyPg0K Jmd0OyAvTG9hPGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPGJyPg0KJmd0 OyBTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51PGJyPg0KJmd0OyBIdWF3ZWkgVGVjaG5vbG9n aWVzIChjb25zdWx0YW50KSBwaG9uZTogJiM0Mzs0NiA3MzkgODEgMjEgNjQ8YnI+DQo8YnI+DQot LSA8YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdl aS5jb208YnI+DQpTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51PGJyPg0KSHVhd2VpIFRlY2hu b2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AD0EFSMTP2etriinfo_-- From wyaacov@gmail.com Sun Dec 8 00:32:23 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 328591ADE84 for ; Sun, 8 Dec 2013 00:32:23 -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 sIINcw1yfupf for ; Sun, 8 Dec 2013 00:32:20 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 42E441ACCE7 for ; Sun, 8 Dec 2013 00:32:20 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id w61so2285670wes.14 for ; Sun, 08 Dec 2013 00:32:15 -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=S1ix9ntfTCRKEKDPmwVXm0EgWblkgQZwt1urshf6SDc=; b=wWOzzbAsm5MpMze/0E5+rXB2KQybhdD8g6NEdWVirba6takJiUS8K9/gf9wq5oNN9Q uuxx+eo5xhQzFUepkFwctgCLn1vTtnlUXSrl+SISvID9ThMcfmOBDagkWNNqubcF0Rpn TuJV+TMWQztLGNi3WUay+OoyEzVouiSIKFMASZaFaJu96OLEn/InOFk6/VtB/IHopnx8 iu1d+VBmeU1UAXrIBpvxPS8+TaT5M4dMyVtV1unGUrZuLlQP0AXGnFpdNjLQvbYlmYzf OW6NCwAjTnFl5ivGwmXDN7q9SLJlugzCtg86mbwI/1bMTANlZ+CKl3aLxv7oB0LrBj9b N5Lw== MIME-Version: 1.0 X-Received: by 10.194.121.133 with SMTP id lk5mr929149wjb.77.1386491535163; Sun, 08 Dec 2013 00:32:15 -0800 (PST) Received: by 10.194.152.202 with HTTP; Sun, 8 Dec 2013 00:32:15 -0800 (PST) In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD0EF@SMTP2.etri.info> References: <529BF66B.50405@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4@SMTP2.etri.info> <52A178A2.9000309@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD0EF@SMTP2.etri.info> Date: Sun, 8 Dec 2013 10:32:15 +0200 Message-ID: From: Yaacov Weingarten To: "Ryoo, Jeong-dong" Content-Type: multipart/alternative; boundary=089e01184e5670080704ed01b79d Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] the phrase "meets the ITU-T's protection switching requirements" 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: Sun, 08 Dec 2013 08:32:23 -0000 --089e01184e5670080704ed01b79d Content-Type: text/plain; charset=ISO-8859-1 Hi, I just want to support Loa on this issue - the "requirements" from the LS are not really requirements - but rather some corner cases that highlight some of the extremes for the requirements that are listed in RFC5654. I think that you should just state that you are trying to cover all of the cases included in the MPLS-TP requirements, including those highlighted in the appendices to the document. just my 2c, yaacov On Sun, Dec 8, 2013 at 4:00 AM, Ryoo, Jeong-dong wrote: > Loa, > > I have been thinking about how to answer your question. > This is a difficult question for me. > I would like to have opinions from the other editor and authors. > > Best regards, > > Jeong-dong > > > ------------------------------ > *From : *"Loa Andersson" > *Sent : *2013-12-06 16:11:42 ( +09:00 ) > *To : *Ryoo, Jeong-dong , > draft-ietf-mpls-tp-psc-itu@tools.ietf.org < > draft-ietf-mpls-tp-psc-itu@tools.ietf.org> > *Cc : *mpls@ietf.org , mpls-chairs@tools.ietf.org < > mpls-chairs@tools.ietf.org>, VIGOUREUX, MARTIN (MARTIN) < > martin.vigoureux@alcatel-lucent.com> > *Subject : *Re: the phrase "meets the ITU-T's protection switching > requirements" in draft-ietf-mpls-tp-psc-itu > > > > Jeong-dong, > > The requirement text in the two liaisons are weak, most of is not > requirements at all. > > Do you say that RFC5654 is not complete when it comes to linear > protection switching and it is not possible to map what is specified in > draft-ietf-mpls-tp-psc-itu ot RFC5654. > > Or do you say that draft-ietf-mpls-tp-psc-itu have alternative ways of > meeting the same requirements. > > If it is the first case, we would need to do an update to RFC5564, I > hope that such an update is litmited to a simple additions and not > require changes to 5654. > > If it is the latter case, you should proceed to do the mapping to > RFC5654. > > /Loa > > On 2013-12-03 11:09, Ryoo, Jeong-dong wrote: > > Loa, > > The ITU-T's requirements refer to the requirements shown in the liaison > > statements from ITU-T > > (https://datatracker.ietf.org/liaison/1205 and > > https://datatracker.ietf.org/liaison/1234/ ) > > Those liaison statements had been listed as informative references in > > the initial versions of the previous drafts that were merged into the > > current draft. During the MPLS-RT review performed for the > > previous separate drafts in August, an issue with referring to the > > liaison statements was raised. In order to resolve the issue, the > > relavant contents in the liaison statements have been moved to Appendix > > and the references were erased. > > I think your point is very valid and the document needs to be clear on > > what those requirements are. > > Best regards, > > Jeong-dong > > > > ------------------------------------------------------------------------ > > *From : *"Loa Andersson" > > *Sent : *2013-12-02 11:54:53 ( +09:00 ) > > *To : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org > > > > *Cc : *mpls@ietf.org , mpls-chairs@tools.ietf.org > > , VIGOUREUX, MARTIN (MARTIN) > > > > *Subject : *the phrase meets the ITU-T's protection switching > > requirements in draft-ietf-mpls-tp-psc-itu > > > > > > Editors/Authors, > > > > I've been thinking about draft-ietf-mpls-tp-psc-itu. The document says > > at several places "meets the ITU-T's protection switching requirements" > > so I thought I go look these requirements up. > > > > To my surprise I found that the only mpls-tp requirement document we > > actually refer is RFC5654. > > > > I don't think we can have an open ended reference to "ITU-T's > > protection switching requirements" if they are not documented. > > > > We could of course find the document that list the "ITU-T's protection > > switching requirements" and reference that directly. > > > > However my preference would be to add text to the introduction the > > "the ITU-T's protection switching requirements" were incorporated in > > RFC5654, and then where you now say "meets the ITU-T's protection > > switching requirements" instead point to RFC5654 and the exact > > requirement. > > > > /Loa > > > > -- > > > > > > 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 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- Thanx and BR, yaacov *Still looking for new opportunity* --089e01184e5670080704ed01b79d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I just want to support Loa on this = issue - the "requirements" from the LS are not really requirement= s - but rather some corner cases that highlight some of the extremes for th= e requirements that are listed in RFC5654. I think that you should just sta= te that you are trying to cover all of the cases included in the MPLS-TP re= quirements, including those highlighted in the appendices to the document.<= /div>

just my 2c,
yaacov


On Sun, Dec 8, 2013 at 4:00 = AM, Ryoo, Jeong-dong <ryoo@etri.re.kr> wrote:
Loa,
=A0
I have been thinking about how to answer yo= ur question.
This is a difficult question for me.
I would like to have=A0opinions from the ot= her editor and authors.

Best regards,
=A0
Jeong-dong
=A0

From : "Loa Andersson" <= ;loa@pi.nu>
Sent : 2013-12-06 16:11:42 ( +09:00 )
To : Ryoo, Jeong-dong <ryoo@etri.re.kr>, draft-ietf-mpls-tp-psc-itu@tools.i= etf.org <draft-ietf-mpls-tp-psc-itu@tools.ietf.org>
Cc : mpls@ietf.or= g <mpls@ietf.org<= /a>>, mp= ls-chairs@tools.ietf.org <mpls-chairs@tools.ietf.org>, VIGOUREUX, MARTIN= (MARTIN) <martin.vigoureux@alcatel-lucent.com>
Subject : Re: the phrase "meets the ITU-T's protection swit= ching requirements" in draft-ietf-mpls-tp-psc-itu



Jeong-dong,

The requirement text in the two liaisons are weak, most of is not
requirements at all.

Do you say that RFC5654 is not complete when it comes to linear
protection switching and it is not possible to map what is specified in
draft-ietf-mpls-tp-psc-itu ot RFC5654.

Or do you say that draft-ietf-mpls-tp-psc-itu have alternative ways of
meeting the same requirements.

If it is the first case, we would need to do an update to RFC5564, I
hope that such an update is litmited to a simple additions and not
require changes to 5654.

If it is the latter case, you should proceed to do the mapping to
RFC5654.

/Loa

On 2013-12-03 11:09, Ryoo, Jeong-dong wrote:
> Loa,
> The ITU-T's requirements refer to the requirements shown in the li= aison
> statements from ITU-T
> (https://datatracker.ietf.org/liaison/1205 and
> https://datatracker.ietf.org/liaison/1234/ )
> Those liaison statements had been listed as informative references in<= br> > the initial versions of the previous drafts that were merged into the<= br> > current draft. During the MPLS-RT review performed for the
> previous separate drafts in August, an issue with referring to the
> liaison statements was raised. In order to resolve the issue, the
> relavant contents in the liaison statements have been moved to Appendi= x
> and the references were erased.
> I think your point is very valid and the document needs to be clear on=
> what those requirements are.
> Best regards,
> Jeong-dong
>
> ----------------------------------------------------------------------= --
> *From : *"Loa Andersson"
> *Sent : *2013-12-02 11:54:53 ( +09:00 )
> *To : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org
>
> *Cc : *mpls@ietf.or= g , mpls-chairs@tools.ietf.org
> , VIGOUREUX, MARTIN (MARTIN)
>
> *Subject : *the phrase meets the ITU-T's protection switching
> requirements in draft-ietf-mpls-tp-psc-itu
>
>
> Editors/Authors,
>
> I've been thinking about draft-ietf-mpls-tp-psc-itu. The document = says
> at several places "meets the ITU-T's protection switching req= uirements"
> so I thought I go look these requirements up.
>
> To my surprise I found that the only mpls-tp requirement document we > actually refer is RFC5654.
>
> I don't think we can have an open ended reference to "ITU-T&#= 39;s
> protection switching requirements" if they are not documented. >
> We could of course find the document that list the "ITU-T's p= rotection
> switching requirements" and reference that directly.
>
> However my preference would be to add text to the introduction the
> "the ITU-T's protection switching requirements" were inc= orporated in
> RFC5654, and then where you now say "meets the ITU-T's protec= tion
> switching requirements" instead point to RFC5654 and the exact > requirement.
>
> /Loa
>
> --
>
>
> Loa Andersson email: loa@mail01.huawei.com
> Senior MPLS Expert loa@= pi.nu
> Huawei Technologies (consultant) phone: +46 739 81 21 64<= br>
--


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
ht= tps://www.ietf.org/mailman/listinfo/mpls




--
Thanx and BR,
yaacov

Still looking= for new opportunity
--089e01184e5670080704ed01b79d-- From wyaacov@gmail.com Sun Dec 8 03:01:44 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 00E101ADDD0 for ; Sun, 8 Dec 2013 03:01:44 -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 AcC-Z4huyE8U for ; Sun, 8 Dec 2013 03:01:42 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7565C1ADF56 for ; Sun, 8 Dec 2013 03:01:42 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id q58so2318998wes.2 for ; Sun, 08 Dec 2013 03:01:37 -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=cxvUxZiy+ydRtfFd3vJBqYTaRUyqFgM8ncqvtug69rk=; b=UfCM16tOnXQDTrEmv/bJXZNGFUXKoNdu8rJIgk1ADmfChVs6xVtUsHyqml7UvKkwex D7nMSiSmesbqeeTvfmg2HbIlsji4osoIolAxofFpq/fMLL7VHAZ3xzVOCQcB+eFTuGzv u53ozd6qmVHJfhF2unIgU8Z/pa7SF89XRbVKr6/Lg2zR1XBO3+4maCS/6yi0n2lA8TOy xoqpXYwV8WjI6i8pjce5lpYi3DqrVkQgfawY4R632Nc6aeirMyKMVDNfr0jChMMQD5Nr NlWlIbdiE2QPcC0tD5tOaAJx9SihXkOxHzOllhnLK7EAPMxAQxT40NJ80k8e70/mrgdX eLFQ== MIME-Version: 1.0 X-Received: by 10.180.149.175 with SMTP id ub15mr9936564wib.10.1386500497645; Sun, 08 Dec 2013 03:01:37 -0800 (PST) Received: by 10.194.152.202 with HTTP; Sun, 8 Dec 2013 03:01:37 -0800 (PST) Date: Sun, 8 Dec 2013 13:01:37 +0200 Message-ID: From: Yaacov Weingarten To: draft-ietf-mpls-tp-psc-itu@tools.ietf.org, mpls@ietf.org Content-Type: multipart/alternative; boundary=001a11c38118a4a31404ed03cd1a Subject: [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: Sun, 08 Dec 2013 11:01:44 -0000 --001a11c38118a4a31404ed03cd1a Content-Type: text/plain; charset=ISO-8859-1 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* --001a11c38118a4a31404ed03cd1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

After reading through your draft on= the extensions to PSC to support SD situations, I have a question for clar= ification -
In your introduction - you state that the method used= to detect SD situations is out-of-scope of the document. Does this mean th= at 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 relatio= nship 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 ..." =A0that seems to indicate that= the behavior of the system is dependent upon the detection method! Clarifi= cation would be appreciated.=A0

--
Thanx and BR,
yaacov

Still looking for new opportunity
--001a11c38118a4a31404ed03cd1a-- From internet-drafts@ietf.org Mon Dec 9 07:12:15 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 12E311AE33B; Mon, 9 Dec 2013 07:12: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 62W4ogiMfce0; Mon, 9 Dec 2013 07:12:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 818121ADF57; Mon, 9 Dec 2013 07:12:12 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209151212.10904.84782.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 07:12:12 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-09.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, 09 Dec 2013 15:12:15 -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 : Inter-Area P2MP Segmented LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-09.txt Pages : 40 Date : 2013-12-09 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-seamless-mcast-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/ From ryoo@etri.re.kr Mon Dec 9 12:05:01 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 F0D7E1AE2E4 for ; Mon, 9 Dec 2013 12:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.92 X-Spam-Level: X-Spam-Status: No, score=-100.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEFFRM_XJSeH for ; Mon, 9 Dec 2013 12:04:59 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id B24981AE2CB for ; Mon, 9 Dec 2013 12:04:58 -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, 10 Dec 2013 05:04:50 +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, 10 Dec 2013 05:04:46 +0900 From: "Ryoo, Jeong-dong" To: Yaacov Weingarten , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: Question regarding SD protection in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHO9ATofTfzY1WrTkK6rDh0YabjsJpMSsLJ Date: Mon, 9 Dec 2013 20:04:46 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@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.44] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485SMTP2etriinfo_" MIME-Version: 1.0 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: Mon, 09 Dec 2013 20:05:01 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFhY292LA0KDQpZZXMsIFBTQyBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0 aG9kIHVzZWQgZm9yIHRoZSBkZXRlY3Rpb24gb2YgU0YvU0QuDQoNCkl0IGlzIGFsc28gdHJ1ZSB0 aGF0IGFueSBwcm90ZWN0aW9uIHN3aXRjaGluZyAoaW5jbHVkaW5nIFBTQykgaXMgc3VwcG9zZWQg dG8gZGVzY3JpYmUgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLg0KDQpBcyB0 aGVyZSBhcmUgbXVsdGlwbGUgb3B0aW9ucyBmb3IgZGV0ZWN0aW5nIFNELCB3ZSBuZWVkZWQgdG8g ZGVzY3JpYmUgdGhlIGJlaGF2aW9yIG9mIHRoZSBicmlkZ2UgdG8gY292ZXIgYWxsIHRoZSBwb3Nz aWJsZSBkZXRlY3Rpb24gbWV0aG9kcy4gRGVzY3JpYmluZyB0aGUgb3BlcmF0aW9uIG9mIGJyaWRn ZSBmb3IgU0QgcHJvdGVjdGlvbiBpcyBub3QgYSBuZXcgdGhpbmcuIEZvciBleGFtcGxlLCBHLjgw MzEgLSBFdGhlcm5ldCBsaW5lYXIgcHJvdGVjdGlvbiBhbHNvIGRlc2NyaWJlcyB3aGF0IGJyaWRn ZSBjYW4gYmUgdXNlZCBpbiBvcmRlciB0byBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCBTRC4N Cg0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRnJvbSA6ICJZYWFjb3YgV2VpbmdhcnRlbiIgPHd5YWFjb3ZAZ21haWwu Y29tPg0KU2VudCA6IDIwMTMtMTItMDggMjA6MDE6NTUgKCArMDk6MDAgKQ0KVG8gOiBkcmFmdC1p ZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXBz Yy1pdHVAdG9vbHMuaWV0Zi5vcmc+LCBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPg0KQ2Mg Og0KU3ViamVjdCA6IFF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9uIGluIGRyYWZ0LWll dGYtbXBscy10cC1wc2MtaXR1DQoNCkhpLA0KDQpBZnRlciByZWFkaW5nIHRocm91Z2ggeW91ciBk cmFmdCBvbiB0aGUgZXh0ZW5zaW9ucyB0byBQU0MgdG8gc3VwcG9ydCBTRCBzaXR1YXRpb25zLCBJ IGhhdmUgYSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbiAtDQpJbiB5b3VyIGludHJvZHVjdGlv biAtIHlvdSBzdGF0ZSB0aGF0IHRoZSBtZXRob2QgdXNlZCB0byBkZXRlY3QgU0Qgc2l0dWF0aW9u cyBpcyBvdXQtb2Ytc2NvcGUgb2YgdGhlIGRvY3VtZW50LiBEb2VzIHRoaXMgbWVhbiB0aGF0IFBT QyBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoaXMg ZGV0ZWN0aW9uPyBJdCBzaG91bGQgcmVhY3Qgb25seSB0byB0aGUgaW5kaWNhdGlvbiwgc2ltaWxh cmx5IHRvIHRoZSByZWFjdGlvbiBhbmQgcmVsYXRpb25zaGlwIHRvIHRoZSBtZXRob2QgZm9yIGRl dGVjdGluZyBhbmQgZGVjbGFyaW5nIGEgU0Ygc2l0dWF0aW9uLg0KSG93ZXZlciwgd2hlbiB5b3Ug ZXhwbGFpbiB0aGUgYmVoYXZpb3Igb2YgdGhlIFNEIHByb3RlY3Rpb24gaW4gc2VjdGlvbiA3LjMg eW91IGhhdmUgYSBwYXJhZ3JhcGggdGhhdCBzdGFydHMgd2l0aCAiSWYgdGhlIGRldGVjdGlvbiBv ZiBhIFNEIGRlcGVuZHMgb24gdGhlIHByZXNlbmNlIG9mIHVzZXIgZGF0YSBwYWNrZXRzIC4uLiIg IHRoYXQgc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgYmVoYXZpb3Igb2YgdGhlIHN5c3RlbSBp cyBkZXBlbmRlbnQgdXBvbiB0aGUgZGV0ZWN0aW9uIG1ldGhvZCEgQ2xhcmlmaWNhdGlvbiB3b3Vs ZCBiZSBhcHByZWNpYXRlZC4NCg0KLS0NClRoYW54IGFuZCBCUiwNCnlhYWNvdg0KDQpTdGlsbCBs b29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHkNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPllhYWNvdiw8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+WWVzLCBQU0MgaXMgc3VwcG9zZWQgdG8gYmUgYWdu b3N0aWMgdG8gdGhlIG1ldGhvZCB1c2VkIGZvciB0aGUgZGV0ZWN0aW9uIG9mIFNGL1NELg0KPC9m b250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPkl0IGlzIGFsc28gdHJ1ZSB0aGF0IGFueSBwcm90ZWN0aW9uIHN3aXRjaGluZyAoaW5jbHVk aW5nIFBTQykgaXMgc3VwcG9zZWQgdG8gZGVzY3JpYmUgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2Ug YW5kIHNlbGVjdG9yLg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20g MGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPkFzIHRoZXJlIGFyZSBtdWx0aXBsZSBvcHRpb25zIGZvciBk ZXRlY3RpbmcgU0QsIHdlIG5lZWRlZCB0byBkZXNjcmliZSB0aGUgYmVoYXZpb3Igb2YgdGhlIGJy aWRnZSB0byBjb3ZlciBhbGwgdGhlIHBvc3NpYmxlIGRldGVjdGlvbiBtZXRob2RzLiBEZXNjcmli aW5nIHRoZSBvcGVyYXRpb24gb2YNCiBicmlkZ2UgZm9yIFNEIHByb3RlY3Rpb24gaXMgbm90IGEg bmV3IHRoaW5nLiBGb3IgZXhhbXBsZSwgRy44MDMxIC0gRXRoZXJuZXQgbGluZWFyIHByb3RlY3Rp b24gYWxzbyBkZXNjcmliZXMgd2hhdCZuYnNwO2JyaWRnZSBjYW4mbmJzcDtiZSB1c2VkIGluIG9y ZGVyIHRvIHByb3ZpZGUgcHJvdGVjdGlvbiBhZ2FpbnN0IFNELg0KPC9mb250Pjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPkJlc3QgcmVnYXJk cyw8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0 IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+SmVvbmctZG9uZzwvZm9udD48L3NwYW4+PC9wPg0KPGJyPg0KPGJyPg0KPGRpdiBp ZD0iTWFpbFNpZ25TZW50Ij48YnI+DQo8L2Rpdj4NCjxociB0YWJpbmRleD0iLTEiPg0KPGI+RnJv bSA6IDwvYj4mcXVvdDtZYWFjb3YgV2VpbmdhcnRlbiZxdW90OyAmbHQ7d3lhYWNvdkBnbWFpbC5j b20mZ3Q7PGJyPg0KPGI+U2VudCA6IDwvYj4yMDEzLTEyLTA4IDIwOjAxOjU1ICggJiM0MzswOTow MCApPGJyPg0KPGI+VG8gOiA8L2I+ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0 Zi5vcmcgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnJmd0Oywg bXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYyA6IDwvYj48YnI+ DQo8Yj5TdWJqZWN0IDogPC9iPlF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9uIGluIGRy YWZ0LWlldGYtbXBscy10cC1wc2MtaXR1PGJyPg0KPGJyPg0KPGRpdiBkaXI9Imx0ciI+SGksDQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BZnRlciByZWFkaW5nIHRocm91Z2ggeW91ciBkcmFmdCBv biB0aGUgZXh0ZW5zaW9ucyB0byBQU0MgdG8gc3VwcG9ydCBTRCBzaXR1YXRpb25zLCBJIGhhdmUg YSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbiAtPC9kaXY+DQo8ZGl2PkluIHlvdXIgaW50cm9k dWN0aW9uIC0geW91IHN0YXRlIHRoYXQgdGhlIG1ldGhvZCB1c2VkIHRvIGRldGVjdCBTRCBzaXR1 YXRpb25zIGlzIG91dC1vZi1zY29wZSBvZiB0aGUgZG9jdW1lbnQuIERvZXMgdGhpcyBtZWFuIHRo YXQgUFNDIGlzIHN1cHBvc2VkIHRvIGJlIGFnbm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3Ig dGhpcyBkZXRlY3Rpb24/IEl0IHNob3VsZCByZWFjdCBvbmx5IHRvIHRoZSBpbmRpY2F0aW9uLCBz aW1pbGFybHkgdG8NCiB0aGUgcmVhY3Rpb24gYW5kIHJlbGF0aW9uc2hpcCB0byB0aGUgbWV0aG9k IGZvciBkZXRlY3RpbmcgYW5kIGRlY2xhcmluZyBhIFNGIHNpdHVhdGlvbi48L2Rpdj4NCjxkaXY+ SG93ZXZlciwgd2hlbiB5b3UgZXhwbGFpbiB0aGUgYmVoYXZpb3Igb2YgdGhlIFNEIHByb3RlY3Rp b24gaW4gc2VjdGlvbiA3LjMgeW91IGhhdmUgYSBwYXJhZ3JhcGggdGhhdCBzdGFydHMgd2l0aCAm cXVvdDs8c3BhbiBzdHlsZT0iTElORS1IRUlHSFQ6IDEuMmVtOyBDT0xPUjogcmdiKDAsMCwwKTsg Rk9OVC1TSVpFOiAxM3B4Ij5JZiB0aGUgZGV0ZWN0aW9uIG9mIGEgU0QgZGVwZW5kcyBvbiB0aGUg cHJlc2VuY2Ugb2YgdXNlciBkYXRhIHBhY2tldHMNCiAuLi4mcXVvdDsgJm5ic3A7dGhhdCBzZWVt cyB0byBpbmRpY2F0ZSB0aGF0IHRoZSBiZWhhdmlvciBvZiB0aGUgc3lzdGVtIGlzIGRlcGVuZGVu dCB1cG9uIHRoZSBkZXRlY3Rpb24gbWV0aG9kISBDbGFyaWZpY2F0aW9uIHdvdWxkIGJlIGFwcHJl Y2lhdGVkLjwvc3Bhbj48c3BhbiBzdHlsZT0iTElORS1IRUlHSFQ6IDEuMmVtOyBDT0xPUjogcmdi KDAsMCwwKTsgRk9OVC1TSVpFOiAxM3B4Ij4mbmJzcDs8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KLS0gPGJyPg0KPGRpdiBkaXI9Imx0ciI+VGhhbnggYW5kIEJSLA0KPGRpdj55YWFjb3Y8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxpPlN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBv cnR1bml0eTwvaT48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485SMTP2etriinfo_-- From huubatwork@gmail.com Mon Dec 9 13:07:51 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 8BEA01AE595 for ; Mon, 9 Dec 2013 13:07:51 -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 tMSt09oj_DY1 for ; Mon, 9 Dec 2013 13:07:49 -0800 (PST) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 799BF1AE42E for ; Mon, 9 Dec 2013 13:07:48 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b57so1810431eek.31 for ; Mon, 09 Dec 2013 13:07:43 -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=wok7j7Le/ZNvEp2qWtLg7Btl6p5q/zHjfkb8FmgrAH0=; b=NOmpvb2Z8W5HWD9Xa96Pj11Vr+8dMdBU3HMp+/otNPJhh1hxv4AfjpQDE4trUbnr6+ IgzEY/Bh2z1uNbZAxtQBiL4ICh1Qi4bRMRNAVUJo3A1dG00bb7JmkD2W9gFhPs7D/cpN zSlLkgYUO+v0Nywq+LvSJtgIJXXIpGxcQ2agcd5Z2ROc0ZAjPLRZxrA/mIYqrv4Qc1wi q+otSfXFuCkQOr0FIcUM/6Z+zqanoId0eTNFQrOoOPgRY84ftimDwdTTH2cj8qyqxgof KnkkPebBwAtm1W6WMAsZpTvMVbsAU9BzNq6fzKDo+5WVi27axfWVAdWx7EVZcgi7STIj ZBUQ== X-Received: by 10.14.184.66 with SMTP id r42mr7919018eem.86.1386623263052; Mon, 09 Dec 2013 13:07:43 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id m1sm33171915eeg.0.2013.12.09.13.07.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 13:07:42 -0800 (PST) Message-ID: <52A6311D.8090606@gmail.com> Date: Mon, 09 Dec 2013 22:07:41 +0100 From: Huub van Helvoort 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 , "Ryoo, Jeong-dong" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" References: <529BF66B.50405@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4@SMTP2.etri.info> <52A178A2.9000309@pi.nu> In-Reply-To: <52A178A2.9000309@pi.nu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] the phrase "meets the ITU-T's protection switching requirements" in 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, 09 Dec 2013 21:07:51 -0000 Hello Loa, I have carefully re-read RFC5654 and think that draft-ietf-mpls-tp-psc-itu meets all requirements. The RFC is missing the details that determine the difference between the PSC RFC and this draft-ietf-mpls-tp-psc-itu. The main difference is the behavior experienced by the operating staff. Best regards, Huub. ================== > The requirement text in the two liaisons are weak, most of is not > requirements at all. > > Do you say that RFC5654 is not complete when it comes to linear > protection switching and it is not possible to map what is specified in > draft-ietf-mpls-tp-psc-itu ot RFC5654. > > Or do you say that draft-ietf-mpls-tp-psc-itu have alternative ways of > meeting the same requirements. > > If it is the first case, we would need to do an update to RFC5564, I > hope that such an update is litmited to a simple additions and not > require changes to 5654. > > If it is the latter case, you should proceed to do the mapping to > RFC5654. > > /Loa > > On 2013-12-03 11:09, Ryoo, Jeong-dong wrote: >> Loa, >> The ITU-T's requirements refer to the requirements shown in the liaison >> statements from ITU-T >> (https://datatracker.ietf.org/liaison/1205 and >> https://datatracker.ietf.org/liaison/1234/ ) >> Those liaison statements had been listed as informative references in >> the initial versions of the previous drafts that were merged into the >> current draft. During the MPLS-RT review performed for the >> previous separate drafts in August, an issue with referring to the >> liaison statements was raised. In order to resolve the issue, the >> relavant contents in the liaison statements have been moved to Appendix >> and the references were erased. >> I think your point is very valid and the document needs to be clear on >> what those requirements are. >> Best regards, >> Jeong-dong >> >> ------------------------------------------------------------------------ >> *From : *"Loa Andersson" >> *Sent : *2013-12-02 11:54:53 ( +09:00 ) >> *To : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org >> >> *Cc : *mpls@ietf.org , mpls-chairs@tools.ietf.org >> , VIGOUREUX, MARTIN (MARTIN) >> >> *Subject : *the phrase meets the ITU-T's protection switching >> requirements in draft-ietf-mpls-tp-psc-itu >> >> >> Editors/Authors, >> >> I've been thinking about draft-ietf-mpls-tp-psc-itu. The document says >> at several places "meets the ITU-T's protection switching requirements" >> so I thought I go look these requirements up. >> >> To my surprise I found that the only mpls-tp requirement document we >> actually refer is RFC5654. >> >> I don't think we can have an open ended reference to "ITU-T's >> protection switching requirements" if they are not documented. >> >> We could of course find the document that list the "ITU-T's protection >> switching requirements" and reference that directly. >> >> However my preference would be to add text to the introduction the >> "the ITU-T's protection switching requirements" were incorporated in >> RFC5654, and then where you now say "meets the ITU-T's protection >> switching requirements" instead point to RFC5654 and the exact >> requirement. >> >> /Loa >> >> -- >> >> >> 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 Mon Dec 9 14:28:58 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 C32B31AE5E6 for ; Mon, 9 Dec 2013 14:28: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, 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 iO2XnhJgPGbE for ; Mon, 9 Dec 2013 14:28:56 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5A48F1AE0F4 for ; Mon, 9 Dec 2013 14:28:56 -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 rB9MScgp020954; Mon, 9 Dec 2013 22:28:40 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB9MSYHw020932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Dec 2013 22:28:34 GMT From: "Adrian Farrel" To: , "'Loa Andersson'" , "'Ryoo, Jeong-dong'" , References: <529BF66B.50405@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4@SMTP2.etri.info> <52A178A2.9000309@pi.nu> <52A6311D.8090606@gmail.com> In-Reply-To: <52A6311D.8090606@gmail.com> Date: Mon, 9 Dec 2013 22:28:34 -0000 Message-ID: <042c01cef52e$0191b4b0$04b51e10$@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: AQHHoAEeGm6kXxffneaTBqOjTT6oawKks3F2Ar10FpoB6vmF05ogroOw Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] the phrase "meets the ITU-T's protection switching requirements" in draft-ietf-mpls-tp-psc-itu 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, 09 Dec 2013 22:28:58 -0000 Hello all, I wonder if I can offer some thoughts to unblock this since (I'm sure) = we would all rather spend our time working on the technical content of = the document. The current text in draft-ietf-mpls-tp-psc-itu (using the Abstract as an = example) says: > This set of > modified and additional behaviors together with the protocol defined > in RFC6378 meets the ITU-T's protection switching requirements. I wonder what message this is trying to convey, and like Loa, I wonder = whether we in the IETF are in a position to say whether or not this = document addresses the ITU-T's requirements. Perhaps this is = aspirational and can be left to the ITU-T to consider. Maybe the point of the text is to give motivation for this work. The = motivation (hopefully) stands on its own. Sure, it was first discussed = in the ITU-T and was brought to the IETF in a combination of liaison = statements and individual contributions. But I think we can present this = document as addressing some specific additional concerns and clarified = requirements. if that is the case, the Abstract could read something like... Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP) are described in RFC 6378 to meet the requirements described in RFC 5654. =20 This document describes alternate mechanisms to perform some of the sub-functions of linear protection, and also defines additional=20 mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely=20 models the behavior of linear protection seen in other transport=20 networks. This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and nodes=20 advertise their capabilities as described in this document. A mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and=20 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 RFC6378 in that the capability advertisement method defined here is an addition to that document. Just a suggestion. Tell me to shut up and go away if you like :-) Adrian > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Huub van = Helvoort > Sent: 09 December 2013 21:08 > To: Loa Andersson; Ryoo, Jeong-dong; = draft-ietf-mpls-tp-psc-itu@tools.ietf.org > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [mpls] the phrase "meets the ITU-T's protection switching > requirements" in draft-ietf-mpls-tp-psc-itu >=20 > Hello Loa, >=20 > I have carefully re-read RFC5654 and think that > draft-ietf-mpls-tp-psc-itu meets all requirements. >=20 > The RFC is missing the details that determine the difference > between the PSC RFC and this draft-ietf-mpls-tp-psc-itu. >=20 > The main difference is the behavior experienced by the > operating staff. >=20 > Best regards, Huub. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The requirement text in the two liaisons are weak, most of is not > > requirements at all. > > > > Do you say that RFC5654 is not complete when it comes to linear > > protection switching and it is not possible to map what is specified = in > > draft-ietf-mpls-tp-psc-itu ot RFC5654. > > > > Or do you say that draft-ietf-mpls-tp-psc-itu have alternative ways = of > > meeting the same requirements. > > > > If it is the first case, we would need to do an update to RFC5564, I > > hope that such an update is litmited to a simple additions and not > > require changes to 5654. > > > > If it is the latter case, you should proceed to do the mapping to > > RFC5654. > > > > /Loa > > > > On 2013-12-03 11:09, Ryoo, Jeong-dong wrote: > >> Loa, > >> The ITU-T's requirements refer to the requirements shown in the = liaison > >> statements from ITU-T > >> (https://datatracker.ietf.org/liaison/1205 and > >> https://datatracker.ietf.org/liaison/1234/ ) > >> Those liaison statements had been listed as informative references = in > >> the initial versions of the previous drafts that were merged into = the > >> current draft. During the MPLS-RT review performed for the > >> previous separate drafts in August, an issue with referring to the > >> liaison statements was raised. In order to resolve the issue, the > >> relavant contents in the liaison statements have been moved to = Appendix > >> and the references were erased. > >> I think your point is very valid and the document needs to be clear = on > >> what those requirements are. > >> Best regards, > >> Jeong-dong > >> > >> = ------------------------------------------------------------------------ > >> *From : *"Loa Andersson" > >> *Sent : *2013-12-02 11:54:53 ( +09:00 ) > >> *To : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org > >> > >> *Cc : *mpls@ietf.org , mpls-chairs@tools.ietf.org > >> , VIGOUREUX, MARTIN (MARTIN) > >> > >> *Subject : *the phrase meets the ITU-T's protection switching > >> requirements in draft-ietf-mpls-tp-psc-itu > >> > >> > >> Editors/Authors, > >> > >> I've been thinking about draft-ietf-mpls-tp-psc-itu. The document = says > >> at several places "meets the ITU-T's protection switching = requirements" > >> so I thought I go look these requirements up. > >> > >> To my surprise I found that the only mpls-tp requirement document = we > >> actually refer is RFC5654. > >> > >> I don't think we can have an open ended reference to "ITU-T's > >> protection switching requirements" if they are not documented. > >> > >> We could of course find the document that list the "ITU-T's = protection > >> switching requirements" and reference that directly. > >> > >> However my preference would be to add text to the introduction the > >> "the ITU-T's protection switching requirements" were incorporated = in > >> RFC5654, and then where you now say "meets the ITU-T's protection > >> switching requirements" instead point to RFC5654 and the exact > >> requirement. > >> > >> /Loa > >> > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > > >=20 >=20 > -- > ************************************************************** > *** > = =E8=AF=B7=E8=AE=B0=E4=BD=8F=EF=BC=8C=E4=BD=A0=E6=98=AF=E7=8B=AC=E4=B8=80=E6= =97=A0=E4=BA=8C=E7=9A=84=EF=BC=8C=E5=B0=B1=E5=83=8F=E5=85=B6=E4=BB=96=E6=AF= =8F=E4=B8=80=E4=B8=AA=E4=BA=BA=E4=B8=80=E6=A0=B7 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From yakov@juniper.net Mon Dec 9 14:54:26 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 F16021A1F72 for ; Mon, 9 Dec 2013 14:54:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJItg18jIeI2 for ; Mon, 9 Dec 2013 14:54:23 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0411A1F00 for ; Mon, 9 Dec 2013 14:54:22 -0800 (PST) Received: from mail175-db9-R.bigfish.com (10.174.16.250) by DB9EHSOBE023.bigfish.com (10.174.14.86) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Dec 2013 22:54:17 +0000 Received: from mail175-db9 (localhost [127.0.0.1]) by mail175-db9-R.bigfish.com (Postfix) with ESMTP id 324131604A5; Mon, 9 Dec 2013 22:54:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zz1443Ida00h1a09Jdc73hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzc2hzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h1155h) Received-SPF: softfail (mail175-db9: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail175-db9 (localhost.localdomain [127.0.0.1]) by mail175-db9 (MessageSwitch) id 138662965652615_13175; Mon, 9 Dec 2013 22:54:16 +0000 (UTC) Received: from DB9EHSMHS001.bigfish.com (unknown [10.174.16.245]) by mail175-db9.bigfish.com (Postfix) with ESMTP id F228E460041; Mon, 9 Dec 2013 22:54:15 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by DB9EHSMHS001.bigfish.com (10.174.14.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Dec 2013 22:54:15 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 9 Dec 2013 14:53:51 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id rB9MYKL88530; Mon, 9 Dec 2013 14:34:27 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201312092234.rB9MYKL88530@magenta.juniper.net> To: , , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25960.1386628459.1@juniper.net> Date: Mon, 9 Dec 2013 14:34:20 -0800 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: mpls@ietf.org Subject: [mpls] early allocation for P2MP Segmented Next-Hop extended community X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 09 Dec 2013 22:54:26 -0000 Dear WG chairs, I'd like to request early allocation for P2MP Segmented Next-Hop extended community (used in draft-ietf-mpls-seamless-mcast). Many thanks in advance. Yakov. From loa@pi.nu Mon Dec 9 19:11:39 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 B524E1AE133 for ; Mon, 9 Dec 2013 19:11:39 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkQEZsUqbhVd for ; Mon, 9 Dec 2013 19:11:36 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 109051AE11B for ; Mon, 9 Dec 2013 19:11:35 -0800 (PST) Received: from [192.168.1.2] (unknown [112.208.74.180]) (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 272C818013E2; Tue, 10 Dec 2013 04:11:27 +0100 (CET) Message-ID: <52A6865C.8050406@pi.nu> Date: Tue, 10 Dec 2013 11:11:24 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'Ryoo, Jeong-dong'" , draft-ietf-mpls-tp-psc-itu@tools.ietf.org References: <529BF66B.50405@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4@SMTP2.etri.info> <52A178A2.9000309@pi.nu> <52A6311D.8090606@gmail.com> <042c01cef52e$0191b4b0$04b51e10$@olddog.co.uk> In-Reply-To: <042c01cef52e$0191b4b0$04b51e10$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, huubatwork@gmail.com Subject: Re: [mpls] the phrase "meets the ITU-T's protection switching requirements" 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: Tue, 10 Dec 2013 03:11:39 -0000 Adrian, Yes the text is better. As Eric pointed out in an off-line mail it is too long, the maximum for an Abstract is 20 lines, this is 24. I would suggest that we move paragraph 3 and 4 to the Introduction. /Loa On 2013-12-10 06:28, Adrian Farrel wrote: > Hello all, > > I wonder if I can offer some thoughts to unblock this since (I'm sure) we would all rather spend our time working on the technical content of the document. > > The current text in draft-ietf-mpls-tp-psc-itu (using the Abstract as an example) says: > >> This set of >> modified and additional behaviors together with the protocol defined >> in RFC6378 meets the ITU-T's protection switching requirements. > > I wonder what message this is trying to convey, and like Loa, I wonder whether we in the IETF are in a position to say whether or not this document addresses the ITU-T's requirements. Perhaps this is aspirational and can be left to the ITU-T to consider. > > Maybe the point of the text is to give motivation for this work. The motivation (hopefully) stands on its own. Sure, it was first discussed in the ITU-T and was brought to the IETF in a combination of liaison statements and individual contributions. But I think we can present this document as addressing some specific additional concerns and clarified requirements. > > if that is the case, the Abstract could read something like... > > Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP) > are described in RFC 6378 to meet the requirements described in RFC > 5654. > > This document describes alternate mechanisms to perform some of the > sub-functions of linear protection, 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 nodes > advertise their capabilities as described in this document. 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 RFC6378 in that the capability advertisement > method defined here is an addition to that document. > > Just a suggestion. > Tell me to shut up and go away if you like :-) > > Adrian > > > > > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Huub van Helvoort >> Sent: 09 December 2013 21:08 >> To: Loa Andersson; Ryoo, Jeong-dong; draft-ietf-mpls-tp-psc-itu@tools.ietf.org >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] the phrase "meets the ITU-T's protection switching >> requirements" in draft-ietf-mpls-tp-psc-itu >> >> Hello Loa, >> >> I have carefully re-read RFC5654 and think that >> draft-ietf-mpls-tp-psc-itu meets all requirements. >> >> The RFC is missing the details that determine the difference >> between the PSC RFC and this draft-ietf-mpls-tp-psc-itu. >> >> The main difference is the behavior experienced by the >> operating staff. >> >> Best regards, Huub. >> >> ================== >>> The requirement text in the two liaisons are weak, most of is not >>> requirements at all. >>> >>> Do you say that RFC5654 is not complete when it comes to linear >>> protection switching and it is not possible to map what is specified in >>> draft-ietf-mpls-tp-psc-itu ot RFC5654. >>> >>> Or do you say that draft-ietf-mpls-tp-psc-itu have alternative ways of >>> meeting the same requirements. >>> >>> If it is the first case, we would need to do an update to RFC5564, I >>> hope that such an update is litmited to a simple additions and not >>> require changes to 5654. >>> >>> If it is the latter case, you should proceed to do the mapping to >>> RFC5654. >>> >>> /Loa >>> >>> On 2013-12-03 11:09, Ryoo, Jeong-dong wrote: >>>> Loa, >>>> The ITU-T's requirements refer to the requirements shown in the liaison >>>> statements from ITU-T >>>> (https://datatracker.ietf.org/liaison/1205 and >>>> https://datatracker.ietf.org/liaison/1234/ ) >>>> Those liaison statements had been listed as informative references in >>>> the initial versions of the previous drafts that were merged into the >>>> current draft. During the MPLS-RT review performed for the >>>> previous separate drafts in August, an issue with referring to the >>>> liaison statements was raised. In order to resolve the issue, the >>>> relavant contents in the liaison statements have been moved to Appendix >>>> and the references were erased. >>>> I think your point is very valid and the document needs to be clear on >>>> what those requirements are. >>>> Best regards, >>>> Jeong-dong >>>> >>>> ------------------------------------------------------------------------ >>>> *From : *"Loa Andersson" >>>> *Sent : *2013-12-02 11:54:53 ( +09:00 ) >>>> *To : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org >>>> >>>> *Cc : *mpls@ietf.org , mpls-chairs@tools.ietf.org >>>> , VIGOUREUX, MARTIN (MARTIN) >>>> >>>> *Subject : *the phrase meets the ITU-T's protection switching >>>> requirements in draft-ietf-mpls-tp-psc-itu >>>> >>>> >>>> Editors/Authors, >>>> >>>> I've been thinking about draft-ietf-mpls-tp-psc-itu. The document says >>>> at several places "meets the ITU-T's protection switching requirements" >>>> so I thought I go look these requirements up. >>>> >>>> To my surprise I found that the only mpls-tp requirement document we >>>> actually refer is RFC5654. >>>> >>>> I don't think we can have an open ended reference to "ITU-T's >>>> protection switching requirements" if they are not documented. >>>> >>>> We could of course find the document that list the "ITU-T's protection >>>> switching requirements" and reference that directly. >>>> >>>> However my preference would be to add text to the introduction the >>>> "the ITU-T's protection switching requirements" were incorporated in >>>> RFC5654, and then where you now say "meets the ITU-T's protection >>>> switching requirements" instead point to RFC5654 and the exact >>>> requirement. >>>> >>>> /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 > -- 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 Dec 9 19:34:26 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 6E17F1AE15E for ; Mon, 9 Dec 2013 19:34: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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtwwvZIGTc6i for ; Mon, 9 Dec 2013 19:34:24 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id EBC6A1AE153 for ; Mon, 9 Dec 2013 19:34:23 -0800 (PST) Received: from [192.168.1.2] (unknown [112.208.74.180]) (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 1B01318013E2; Tue, 10 Dec 2013 04:34:15 +0100 (CET) Message-ID: <52A68BB2.3050302@pi.nu> Date: Tue, 10 Dec 2013 11:34:10 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: huubatwork@gmail.com, "Ryoo, Jeong-dong" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" References: <529BF66B.50405@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286AB6C4@SMTP2.etri.info> <52A178A2.9000309@pi.nu> <52A6311D.8090606@gmail.com> In-Reply-To: <52A6311D.8090606@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] the phrase "meets the ITU-T's protection switching requirements" 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: Tue, 10 Dec 2013 03:34:26 -0000 Huub, Yes, the question was not whether if draft-ietf-mpls-tp-psc-itu satisfactorily meets the requirements in RFC 5654, I believe we have a general agreement that this is the case. The question was whether we have additional "ITU-T requirements" not captured in RFC 5456, and if so where they were documented. As the discussion stands now and with the Introduction of RFC 5654 stating: Furthermore, for carriers it is important that operation of such packet transport networks should preserve the look-and-feel to which carriers have become accustomed in deploying their optical transport networks, while providing common, multi-layer operations, resiliency, control, and multi-technology management. I believe we are on dry ground if we have an explicit reference to that section and everywhere where the current document says: "... meets the ITU-T's protection switching requirements" change that to "... meets the behavioral requirements indicated in the Introduction of RFC 5654". /Loa On 2013-12-10 05:07, Huub van Helvoort wrote: > Hello Loa, > > I have carefully re-read RFC5654 and think that > draft-ietf-mpls-tp-psc-itu meets all requirements. > > The RFC is missing the details that determine the difference > between the PSC RFC and this draft-ietf-mpls-tp-psc-itu. > > The main difference is the behavior experienced by the > operating staff. > > Best regards, Huub. > > ================== >> The requirement text in the two liaisons are weak, most of is not >> requirements at all. >> >> Do you say that RFC5654 is not complete when it comes to linear >> protection switching and it is not possible to map what is specified in >> draft-ietf-mpls-tp-psc-itu ot RFC5654. >> >> Or do you say that draft-ietf-mpls-tp-psc-itu have alternative ways of >> meeting the same requirements. >> >> If it is the first case, we would need to do an update to RFC5564, I >> hope that such an update is litmited to a simple additions and not >> require changes to 5654. >> >> If it is the latter case, you should proceed to do the mapping to >> RFC5654. >> >> /Loa >> >> On 2013-12-03 11:09, Ryoo, Jeong-dong wrote: >>> Loa, >>> The ITU-T's requirements refer to the requirements shown in the liaison >>> statements from ITU-T >>> (https://datatracker.ietf.org/liaison/1205 and >>> https://datatracker.ietf.org/liaison/1234/ ) >>> Those liaison statements had been listed as informative references in >>> the initial versions of the previous drafts that were merged into the >>> current draft. During the MPLS-RT review performed for the >>> previous separate drafts in August, an issue with referring to the >>> liaison statements was raised. In order to resolve the issue, the >>> relavant contents in the liaison statements have been moved to Appendix >>> and the references were erased. >>> I think your point is very valid and the document needs to be clear on >>> what those requirements are. >>> Best regards, >>> Jeong-dong >>> >>> ------------------------------------------------------------------------ >>> *From : *"Loa Andersson" >>> *Sent : *2013-12-02 11:54:53 ( +09:00 ) >>> *To : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org >>> >>> *Cc : *mpls@ietf.org , mpls-chairs@tools.ietf.org >>> , VIGOUREUX, MARTIN (MARTIN) >>> >>> *Subject : *the phrase meets the ITU-T's protection switching >>> requirements in draft-ietf-mpls-tp-psc-itu >>> >>> >>> Editors/Authors, >>> >>> I've been thinking about draft-ietf-mpls-tp-psc-itu. The document says >>> at several places "meets the ITU-T's protection switching requirements" >>> so I thought I go look these requirements up. >>> >>> To my surprise I found that the only mpls-tp requirement document we >>> actually refer is RFC5654. >>> >>> I don't think we can have an open ended reference to "ITU-T's >>> protection switching requirements" if they are not documented. >>> >>> We could of course find the document that list the "ITU-T's protection >>> switching requirements" and reference that directly. >>> >>> However my preference would be to add text to the introduction the >>> "the ITU-T's protection switching requirements" were incorporated in >>> RFC5654, and then where you now say "meets the ITU-T's protection >>> switching requirements" instead point to RFC5654 and the exact >>> requirement. >>> >>> /Loa >>> >>> -- >>> >>> >>> 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 Mon Dec 9 21:17:25 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 949B11AE1CA for ; Mon, 9 Dec 2013 21:17:25 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4D5iRKBUvVi for ; Mon, 9 Dec 2013 21:17:24 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 33FC41AE1C5 for ; Mon, 9 Dec 2013 21:17:24 -0800 (PST) Received: from [192.168.1.2] (unknown [112.208.74.180]) (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 3D0A118013E2; Tue, 10 Dec 2013 06:17:16 +0100 (CET) Message-ID: <52A6A3D7.6030905@pi.nu> Date: Tue, 10 Dec 2013 13:17:11 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Yakov Rekhter , rcallon@juniper.net, swallow@cisco.com References: <201312092234.rB9MYKL88530@magenta.juniper.net> In-Reply-To: <201312092234.rB9MYKL88530@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] early allocation for P2MP Segmented Next-Hop extended community X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 10 Dec 2013 05:17:25 -0000 Yakov, If my understanding is correct "Early Allocation" is only possible if the registry from where the allocation policies are "Standards Action" both "IPv4 Address Specific Extended Community" and "IPv6 Address Specific Extended Community" registries are both "First Come First Served". /Loa On 2013-12-10 06:34, Yakov Rekhter wrote: > Dear WG chairs, > > I'd like to request early allocation for P2MP Segmented Next-Hop > extended community (used in draft-ietf-mpls-seamless-mcast). > > Many thanks in advance. > > Yakov. > -- 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 Mon Dec 9 22:12:37 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 BD6D91AE21F; Mon, 9 Dec 2013 22:12: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 TVMfxFy0vslQ; Mon, 9 Dec 2013 22:12:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D13F71AC4A3; Mon, 9 Dec 2013 22:12:35 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131210061235.12259.19179.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 22:12:35 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-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: Tue, 10 Dec 2013 06:12:38 -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 : Requirements for MPLS Shared Mesh Protection Author(s) : Yaacov Weingarten Sam Aldrin Ping Pan Jeong-dong Ryoo Greg Mirsky Filename : draft-ietf-mpls-smp-requirements-02.txt Pages : 13 Date : 2013-12-09 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-smp-requirements-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 wyaacov@gmail.com Mon Dec 9 23:04:19 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 0F9081AE1F9 for ; Mon, 9 Dec 2013 23:04:19 -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 djXZqhUzG5tJ for ; Mon, 9 Dec 2013 23:04:17 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id A29291AE0F7 for ; Mon, 9 Dec 2013 23:04:16 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so4566099wgg.16 for ; Mon, 09 Dec 2013 23:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3fBpTQI8YJuTQYL0IjTLeCWn6rrZhARGADONpU/997I=; b=Qc4ucEBWtvWeQYOv9f0niMvdZ4pYa32NywbZdc1lorHRoNULuxrmPq8r3f4/ngB0N5 eRX6T5VxXs0mxO7Un60VCCz0waiJbmNK1ToFDhZjl2Yer8WbwNzXMzBk/PTIvP1zAfsY ORozjrxxAsL5MCFM9z2Nq6quXjcd0L2jo+YMPGpC4sy78DfNkVCXeTGwNaOQHm0jUjg+ WfiqRBqgzZZaQujJ8QljOjIZnEkatVNRLkmOWPrf+pOr/30d7cOmZIkxLB7481dHiPow HqqkPCrait/lIfb0A5Rmf71u/ixdFVUIw8Fo30ydpad2hxX4UbjYgWggBSWPRp+WV37j CoKQ== MIME-Version: 1.0 X-Received: by 10.180.103.193 with SMTP id fy1mr18074862wib.10.1386659051143; Mon, 09 Dec 2013 23:04:11 -0800 (PST) Received: by 10.194.152.202 with HTTP; Mon, 9 Dec 2013 23:04:11 -0800 (PST) In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info> References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info> Date: Tue, 10 Dec 2013 09:04:11 +0200 Message-ID: From: Yaacov Weingarten To: "Ryoo, Jeong-dong" Content-Type: multipart/alternative; boundary=f46d04428e3a2b24bc04ed28b812 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: Tue, 10 Dec 2013 07:04:19 -0000 --f46d04428e3a2b24bc04ed28b812 Content-Type: text/plain; charset=ISO-8859-1 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 and SDH 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 < > 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* --f46d04428e3a2b24bc04ed28b812 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeong-dong, hi

Thank you for your reply= . Your answer seems to be an appropriate answer for other SDOs, not sure th= at it is true for the context of MPLS and IETF work.

1. You wrote "any protection switching (inclu= ding PSC) is supposed to describe the operation of bridge and selector.&quo= t; - this may be true for Ethernet and=C2=A0SDH and for documen= ts that are describing the operation of the physical layer. However, the IE= TF (to my understanding - and I am certainly willing to be corrected on thi= s point) is concerned with the protocol and leave the lower layers to imple= mentation. Also, I am not sure that the concepts of Bridge and Selector rea= lly apply to MPLS (although I admit that we did mention them in the origina= l 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 anothe= r 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-draf= t. Even when the draft states that its purpose is to address the concerns o= f the ITU.

3. To t= he actual point of my earlier comment, that you do not seem to address - th= e paragraph in Section 7.3 seems to state that SD protection changes accord= ing to the method that is used to detect the SD. This means that SD protect= ion is not agnostic to the method used for the detection.
Alternatively, we could break this dependence and sta= te that SD protection is always provided by changing the transmission of th= e data to 1+1 protection in cases of SD detection, which is what the paragr= aph is suggesting to do for some cases.

I hope this formulation make my comme= nt clearer and we are able to discuss the technological approach rather tha= n the philosophical differences.

Thank you,
= yaacov


On Mon,= Dec 9, 2013 at 10:04 PM, Ryoo, Jeong-dong <ryoo@etri.re.kr> w= rote:

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

=C2=A0

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">Yes, PSC is supposed to= be agnostic to the method used for the detection of SF/SD.

=C2=A0

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">It is also true that an= y protection switching (including PSC) is supposed to describe the operatio= n of bridge and selector.

=C2=A0

<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">As there are multiple o= ptions for detecting SD, we needed to describe the behavior of the bridge t= o cover all the possible detection methods. Describing the operation of bridge for SD protection is not a new thing. For example, G.8031 - Etherne= t linear protection also describes what=C2=A0bridge can=C2=A0be used in ord= er to provide protection against SD.

=C2=A0

<= 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 : 2013-12-08 20:01:55 ( +09:00 )
To : draft-ietf-mpls-tp-psc-itu@tools.ietf.org <dra= ft-ietf-mpls-tp-psc-itu@tools.ietf.org>, mpls@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 S= D situations, I have a question for clarification -
In your introduction - you state that the method used to detect SD sit= uations is out-of-scope of the document. Does this mean that PSC is suppose= d to be agnostic to the method used for this detection? It should react onl= y 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 ..." =C2=A0that seems to indicate that the behavior of the system is = dependent upon the detection method! Clarification would be appreciated.=C2=A0

--
Thanx and BR,
yaacov

Still looking for new opportunity



--
Thanx and BR,
yaacov

Still looking for= new opportunity
--f46d04428e3a2b24bc04ed28b812-- From loa@pi.nu Tue Dec 10 05:37:53 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 A931B1ACCEE for ; Tue, 10 Dec 2013 05:37:53 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVtZ2WxjIIDd for ; Tue, 10 Dec 2013 05:37:51 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 89FA51ACB4E for ; Tue, 10 Dec 2013 05:37:51 -0800 (PST) Received: from [192.168.1.2] (unknown [112.208.74.180]) (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 1409718013E2; Tue, 10 Dec 2013 14:37:43 +0100 (CET) Message-ID: <52A71923.8090701@pi.nu> Date: Tue, 10 Dec 2013 21:37:39 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 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-smp-requirements@tools.ietf.org Subject: [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: Tue, 10 Dec 2013 13:37:53 -0000 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 From arkadiy.gulko@thomsonreuters.com Tue Dec 10 10:25:49 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 7B7551AE1FC for ; Tue, 10 Dec 2013 10:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4N3J4GugxNlu for ; Tue, 10 Dec 2013 10:25:47 -0800 (PST) Received: from mailout1-trm.thomsonreuters.com (mailout1-trm.thomsonreuters.com [159.220.28.56]) by ietfa.amsl.com (Postfix) with ESMTP id B0C5A1AE1E1 for ; Tue, 10 Dec 2013 10:25:46 -0800 (PST) Received: from ocdp-erfsmlr01.erf.thomson.com ([10.31.3.8]) by mailout1-trm.thomsonreuters.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rBAIPZXN026829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2013 18:25:36 GMT Received: from EAGE-ERFPHUB06.ERF.thomson.com ([163.231.23.45]) by ocdp-erfsmlr01.erf.thomson.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rBAIPSI9021412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 18:25:34 GMT Received: from C111VCKHUB17.ERF.thomson.com (163.231.29.148) by EAGE-ERFPHUB06.ERF.thomson.com (163.231.23.45) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 12:25:09 -0600 Received: from C111GTUHMBX56.ERF.thomson.com ([fe80::71e6:8d9e:a7f4:fe91]) by C111VCKHUB17.ERF.thomson.com ([fe80::2900:d994:6cb2:b2a9%14]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 12:25:09 -0600 From: To: Thread-Topic: [mpls] Way two progress two mldp draft with an technical overlap Thread-Index: AQHO8QDrsJSDvoCqUEitixJX6aqPtJpHZmCAgAZg5SA= Date: Tue, 10 Dec 2013 18:25:08 +0000 Message-ID: <4A496052E7B7E84A9324854763C616FA0728F18A@C111GTUHMBX56.ERF.thomson.com> References: <529F425C.1050808@pi.nu> <1C5DE0E4-4B11-4098-AF69-C7A01E9D34BF@cisco.com> In-Reply-To: <1C5DE0E4-4B11-4098-AF69-C7A01E9D34BF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.206.30.9] 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-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org, draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 10 Dec 2013 18:25:50 -0000 Dear Chairs, I agree with the proposed resolution below. Thanks, Arkadiy On 04 Dec 2013, at 15:55, Loa Andersson wrote: >=20 > Working Group, >=20 > It has been pointed out that there is overlap between=20 > draft-wijnands-mpls-mldp-in-band-wildcard-encoding and=20 > draft-rekhter-mpls-pim-sm-over-mldp. Within the overlap there is a=20 > critical piece of the protocol specification. > Having this specified in two places is likely to result in=20 > non-interoperable implementations. >=20 > The working group chairs have discussed the overlap and propose the=20 > following as a means of moving forward. >=20 > 1. Issue a single poll to adopt both documents together as working=20 > group documents >=20 > 2. Assuming that the drafts are adopted, complete=20 > draft-wijnands-mpls-in-band-wildcard-encoding as the normative=20 > protocol specification of the piece within the overlap. >=20 > 3. Where mechanisms in draft-wijnanads are needed in=20 > draft-rekhter-mpls-pim-sm-over-mldp have the latter document reference=20 > the necessary sections of the former document. >=20 > MPLS Working Group Chairs > Loa, Ross, George >=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 agmalis@gmail.com Tue Dec 10 10:46:24 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 8B9151AE02A for ; Tue, 10 Dec 2013 10:46: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 K6YohfkhKuVW for ; Tue, 10 Dec 2013 10:46:22 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id AE15D1ADFFF for ; Tue, 10 Dec 2013 10:46:22 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id m20so4125570qcx.8 for ; Tue, 10 Dec 2013 10:46:17 -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=Yy0svIgHtwQ2gMveNZjzzlanqzcqiBvnKrpsT7YBh/A=; b=Hythk5ifHVXNMDXfdIhNnpgN5IB7NKpyhnewFBlX9L+Ai4jRuzlYae9hKazCfDLL+8 8MA7+04SXH5jsk4zmFlGhEjOaBXlK0b8FMp8NTLHKfsgfTqVrSHY5VMmW0cdkc7BYest e29wE51fA0HVGrPgW/EimJbYeQmcrnG2ywCKWGJjoJOxBhP/151p2pdyTrEXIWxqxxMM 8+paGOnrEPbHkObXO4sknUfyFSY+K7tUEF1cnJkvDgc3cr7Yr5gRCAdYWRMJtVzvahWm fsmvtmmhLgzXQ1cShKgWDpaGnO1cKtaaLpn84fRsF7GYLyE8JPG2SfX3bsml0VjSkdrM lhTQ== X-Received: by 10.49.38.37 with SMTP id d5mr46579602qek.17.1386701177240; Tue, 10 Dec 2013 10:46:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.166.9 with HTTP; Tue, 10 Dec 2013 10:45:55 -0800 (PST) In-Reply-To: <52A71923.8090701@pi.nu> References: <52A71923.8090701@pi.nu> From: "Andrew G. Malis" Date: Tue, 10 Dec 2013 13:45:55 -0500 Message-ID: To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 10 Dec 2013 18:46:24 -0000 I've reviewed this draft and IMHO, it's ready for publication. SMP is an important part of the MPLS-TP survivability framework and it meets the requirements in RFC 5654. One small nit (literally) - when I've been running drafts through the nits checker lately, it complains about references in the abstract. So at some point, the abstract in this draft should be revised to remove the references. Cheers, Andy On Tue, Dec 10, 2013 at 8:37 AM, 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 Alexander.Vainshtein@ecitele.com Tue Dec 10 22:05:33 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 663B11AE392; Tue, 10 Dec 2013 22:05:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUDT-vDZH-T6; Tue, 10 Dec 2013 22:05:30 -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 79C831AE390; Tue, 10 Dec 2013 22:05:29 -0800 (PST) Received: from AM3PR03MB529.eurprd03.prod.outlook.com (10.242.109.153) by AM3PR03MB562.eurprd03.prod.outlook.com (10.242.111.147) with Microsoft SMTP Server (TLS) id 15.0.837.10; Wed, 11 Dec 2013 06:05:23 +0000 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.842.7; Wed, 11 Dec 2013 06:05:21 +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.0837.004; Wed, 11 Dec 2013 06:05:21 +0000 From: Alexander Vainshtein To: "curtis@occnc.com" Thread-Topic: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment Thread-Index: AQHO9b9GSq0tCZZscUehMpHq+OAdtZpOe00f Date: Wed, 11 Dec 2013 06:05:20 +0000 Message-ID: <774d74926b684ffba7f4f89ace758547@AM3PR03MB532.eurprd03.prod.outlook.com> References: Your message of "Tue, 26 Nov 2013 16:26:43 +0000." , <201312101547.rBAFl9Be033270@gateway1.ipv6.occnc.com> In-Reply-To: <201312101547.rBAFl9Be033270@gateway1.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.203] x-forefront-prvs: 0057EE387C x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(13464003)(53754006)(199002)(189002)(377454003)(52604005)(51704005)(76482001)(81342001)(81816001)(4396001)(33646001)(69226001)(81542001)(47736001)(47976001)(50986001)(76576001)(76786001)(47446002)(74502001)(74316001)(31966008)(74662001)(49866001)(71446004)(74366001)(56816005)(66066001)(90146001)(51856001)(85852003)(74706001)(63696002)(76796001)(85306002)(65816001)(80022001)(87266001)(87936001)(19580405001)(19580395003)(80976001)(2656002)(46102001)(83322001)(83072002)(59766001)(77982001)(54316002)(56776001)(79102001)(74876001)(81686001)(54356001)(53806001)(427584002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB529; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:5.153.9.203; 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: "samante@apple.com" , "kireeti@juniper.net" , "mpls@ietf.org" , "pwe3 \(pwe3@ietf.org\)" Subject: Re: [mpls] [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Dec 2013 06:05:33 -0000 Curtis,=0A= Lots of thanks for sending out the new text.=0A= =0A= I still have a couple of issues with this version of the text: one technica= l and one editorial.=0A= =0A= The technical issue is about the fragment "A small jitter buffer is always = necessary". =0A= =0A= I am not sure this is correct, since I am aware of several PW implementatio= ns that pass the payload of a received PW packet directly for transmission = via the corresdponding attachment circuit. Of course this payload would be = stored in some Tx queue associated with the attachment circuit and controll= ed by the appropriate egress scheduler, but IMO this does not constitue a P= W jitter bufer, since the PW interworking function does not exersize any co= ntrol over these queues.=0A= In particular, these queues could not be used for re-ordering misordered PW= packets.=0A= IMHO and FWIW this understanding matches RFC 3985 which mentions (in Sectio= n 5.2.1.1 "Frame Ordering") that reodering as the strategy for handling mis= -ordered packets introduces additional delay (i.e., requires a ddicated jit= ter buffer), while the alternative strategy of discarding mis-ordered packe= ts does not introduce such additional delay.=0A= =0A= The editorial issue is about the entire sentence that contains the above-me= ntioned fragment, i.e., "A small jitter buffer is always necessary and the = jitter buffer is needed regardless of whether reordering is done" - to me t= his looks like an unnecessary repetition if if it were techically correct.= =0A= =0A= Hence I would like to suggest discrading the problematic sentence as the si= mplest way to resolve both issues.=0A= =0A= Hopefully these notes will e helpful.=0A= =0A= Regards,=0A= Sasha=0A= =0A= =0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Tuesday, December 10, 2013 5:47 PM=0A= To: Alexander Vainshtein=0A= Cc: curtis@ipv6.occnc.com; curtis@occnc.com; kireeti@juniper.net; samante@a= pple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stei= n (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwardin= g: a minor comment=0A= =0A= In message =0A= Alexander Vainshtein writes:=0A= >=0A= > Curtis,=0A= >=0A= > Lots of thanks for a prompt and very detailed response.=0A= > May I suggest an alternative version of the following text fragment?=0A= >=0A= > =0A= > > Identifying the position of any lost packets is important=0A= > > for PW services which are attempting to reconstruct a bit stream=0A= > > which maintains bit timing, such as time division multiplexing (TDM)= =0A= > > services. TDM and other PW services which require strict ordering= =0A= > > also require that misordered packets be either dropped or reordered.= =0A= =0A= Invalid XML - you didn't close this element. :-)=0A= =0A= > =0A= >=0A= > Identifying lost PW packets and exact amount of lost payload is=0A= > critical for PW services which maintain bit timing, such as Time=0A= > Division Multiplexing (TDM) services since these services MUST=0A= > compensate lost payload on a bit-for-bit basis.=0A= >=0A= > With these services PW packets that have been received out of order=0A= > also MUST also be identified and may be either re-ordered or=0A= > dropped. Reordering requires, in addition to sequence numbering, a=0A= > "de-jitter buffer" in the egress PE, and ability to reorder is=0A= > limited by the depth of this buffer. The down side of maintaining a=0A= > de-jitter buffer is added end-to-end service delay.=0A= >=0A= > =0A= =0A= Accepted with a small change.=0A= =0A= After the words "down side"=0A= s/de-jitter buffer/large jitter buffer/=0A= Elsewhere=0A= s/de-jitter buffer/jitter buffer/g=0A= Then add the sentence.=0A= =0A= A small jitter buffer is always necessary and the jitter buffer=0A= is needed regardless of whether reordering is done.=0A= =0A= This yields a slightly changed second paragraph.=0A= =0A= With these services PW packets that have been received out of order=0A= also MUST also be identified and may be either re-ordered or=0A= dropped. Reordering requires, in addition to sequence numbering, a=0A= "jitter buffer" in the egress PE, and ability to reorder is limited=0A= by the depth of this buffer. The down side of maintaining a large=0A= jitter buffer is added end-to-end service delay. A small jitter=0A= buffer is always necessary and the jitter buffer is needed=0A= regardless of whether reordering is done.=0A= =0A= Is this wording OK with you?=0A= =0A= Curtis=0A= =0A= > Hopefully this will be useful.=0A= >=0A= >=0A= > Regards,=0A= > Sasha=0A= >=0A= > > -----Original Message-----=0A= > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]=0A= > > Sent: Monday, November 25, 2013 8:30 PM=0A= > > To: Alexander Vainshtein=0A= > > Cc: curtis@occnc.com; kireeti@juniper.net; samante@apple.com;=0A= > > agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stein=0A= > > (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= > > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-=0A= > > forwarding: a minor comment=0A= > >=0A= > >=0A= > > In message=0A= > > > om>=0A= > > Alexander Vainshtein writes:=0A= > > >=0A= > > > Hi all,=0A= > > >=0A= > > > I would like to comment on the text in Section 2.1.8.1 "Pseudowire=0A= > > > Sequence Number" in draft-ietf-mpls-forwarding-03 - MPLS Forwarding= =0A= > > > Compliance and Performance Requirements=0A= > > > .=0A= > > >=0A= > > > This section states, in short, that the main drive for using the=0A= > > > sequence number in the PW Control Word is handling of packet=0A= > > > reordering events. TDM PWs are presented as a major example, with CBR= =0A= > > > ATM services as another example.=0A= > > >=0A= > > > In fact, this statement is not accurate.=0A= > >=0A= > > Yes. You are correct in pointing this out as inaccurate by omitting=0A= > > the other important function of identifying drops for the purpose of=0A= > > recunstructing TDM bit streams.=0A= > >=0A= > > Andy brought up resequencing being a strong provider request.=0A= > > Reordering is far more common than loss particularly for high priority= =0A= > > services on provider networks and without resequencing reorder results= =0A= > > in PW loss in what could otherwise be lossless service.=0A= > >=0A= > > So we should get the base requirements right but still reflect this,=0A= > > but strictly as advice with no normative wording. We had used the=0A= > > phrase "is beneficial" and will retain that.=0A= > >=0A= > > Andy brought up the topic. The incorrect wording in the existing=0A= > > draft is my fault. This text went in fairly early with a lot of other= =0A= > > changes and it appears that no one had since given it a careful enough= =0A= > > read and review until you came along.=0A= > >=0A= > > > The main drive for mandating the use of sequence number in TM PWs is= =0A= > > > the need to detect and count lost packets because the egress PE MUST= =0A= > > > compensate the lost payload bit for bit.=0A= > > >=0A= > > > Ability to compensate reordering of PW packets at egress is a side=0A= > > > effect of (a) sequence number usage and (b) usage of the de-jitter=0A= > > > buffer in the egress PW. It is not mandatory and in any case is=0A= > > > limited by the depth of the de-jitter buffer: re-ordered packets that= =0A= > > > cannot be accommodated within this buffer are treated as lost.=0A= > > >=0A= > > > Additional details can be found, e.g., in section 6.2.2 of RFC=0A= > > > 4553. Ability to re-order=0A= > > > mis-ordered PW packets is defined there as OPTIONAL, while replacemen= t=0A= > > > of the payload of lost PW packets is defined as MANDATORY.=0A= > >=0A= > > The change below at the top of the section more accurately reflects=0A= > > requirements in the RFCs but still states that resequencing can be=0A= > > beneficial. The comments about EPD and PPD are dropped and therefore= =0A= > > also the informative reference.=0A= > >=0A= > > Context:=0A= > >=0A= > > 2.1.8.1. Pseudowire Sequence Number=0A= > >=0A= > > OLD=0A= > >=0A= > > Pseudowire (PW) sequence number support is most important for PW=0A= > > payload types with a high expectation of in-order delivery.=0A= > > Resequencing support, rather than dropping at egress on out of order= =0A= > > arrival, is most important for PW payload types with a high=0A= > > expectation of lossless delivery. For example, TDM payloads require= =0A= > > sequence number support and require resequencing support. The same= =0A= > > is true of ATM CBR service. ATM VBR or ABR may have somewhat relaxe= d=0A= > > requirements, but generally require ATM Early Packet Discard (EPD) o= r=0A= > > ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequence= =0A= > > number support and resequencing support are beneficial to PW packet= =0A= > > oriented payloads such as FR and Ethernet, they are highly desirable= =0A= > > but not as strongly required.=0A= > >=0A= > > NEW=0A= > >=0A= > > Pseudowire (PW) sequence number support is most important for PW=0A= > > payload types with a high expectation of lossless and/or in-order=0A= > > delivery. Identifying the position of any lost packets is important= =0A= > > for PW services which are attempting to reconstruct a bit stream=0A= > > which maintains bit timing, such as time division multiplexing (TDM)= =0A= > > services. TDM and other PW services which require strict ordering= =0A= > > also require that misordered packets be either dropped or reordered.= =0A= > >=0A= > > PW services which are not timing critical bit streams in nature are= =0A= > > cell oriented or frame oriented. Though resequencing support is=0A= > > beneficial to PW cell and frame oriented payloads such as ATM, FR an= d=0A= > > Ethernet, they are highly desirable but not required.=0A= > >=0A= > > NEW (end of subsection after list of possible reording causes)=0A= > >=0A= > > In provider networks which use multipath techniques and which may=0A= > > occassionally rebalance traffic or which may change PW paths=0A= > > occasionally for other reasons, reordering may be far more common=0A= > > than loss. Where reordering is more common than loss, resequencing= =0A= > > packets is beneficial, rather than dropping packets at egress when= =0A= > > out of order arrival occus. Resequencing is most important for PW= =0A= > > payload types with a high expectation of lossless delivery since in= =0A= > > such cases out of order delivery within the network results in PW=0A= > > loss.=0A= > >=0A= > > The final paragraph sums up the motivation for highlighting=0A= > > resequencing as beneficial and desirable. It does so without any=0A= > > normative wording.=0A= > >=0A= > > > Hopefully these notes will be useful.=0A= > > >=0A= > > > Regards,=0A= > > > Sasha=0A= > >=0A= > > These notes are very useful. Thank you.=0A= > >=0A= > > Please let us know if you (and the WG) are OK with the rewording=0A= > > proposed above.=0A= > >=0A= > > Curtis=0A= From Alexander.Vainshtein@ecitele.com Tue Dec 10 22:05:41 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 D4A0E1AE39F; Tue, 10 Dec 2013 22:05: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 3ArpOVN4fIcz; Tue, 10 Dec 2013 22:05:38 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0017.outbound.protection.outlook.com [213.199.154.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA261AE39C; Tue, 10 Dec 2013 22:05:37 -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.837.10; Wed, 11 Dec 2013 06:05: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.0837.004; Wed, 11 Dec 2013 06:05:30 +0000 From: Alexander Vainshtein To: "curtis@occnc.com" Thread-Topic: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment Thread-Index: AQHO9jb+Sq0tCZZscUehMpHq+OAdtQ== Date: Wed, 11 Dec 2013 06:05:29 +0000 Message-ID: <96907ab6f1ec48c1971db740f7845ff4@AM3PR03MB532.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.203] x-forefront-prvs: 0057EE387C x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(189002)(199002)(13464003)(377454003)(52604005)(51704005)(53754006)(81542001)(76786001)(81342001)(76576001)(4396001)(49866001)(33646001)(46102001)(74662001)(47446002)(85852003)(83072002)(31966008)(51856001)(76176001)(47976001)(47736001)(76796001)(50986001)(74502001)(74876001)(54356001)(76482001)(74316001)(74706001)(65816001)(87266001)(2656002)(80022001)(63696002)(87936001)(66066001)(74366001)(83322001)(19580405001)(85306002)(90146001)(19580395003)(69226001)(56776001)(80976001)(54316002)(79102001)(53806001)(59766001)(71446004)(81816001)(56816005)(77982001)(81686001)(427584002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB530; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:5.153.9.203; 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: "samante@apple.com" , "kireeti@juniper.net" , "mpls@ietf.org" , "pwe3 \(pwe3@ietf.org\)" Subject: Re: [mpls] [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Dec 2013 06:05:42 -0000 Curtis,=0A= Lots of thanks for sending out the new text.=0A= =0A= I still have a couple of issues with this version of the text: one technica= l and one editorial.=0A= =0A= The technical issue is about the fragment "A small jitter buffer is always = necessary". =0A= =0A= I am not sure this is correct, since I am aware of several PW implementatio= ns that pass the payload of a received PW packet directly for transmission = via the corresdponding attachment circuit. Of course this payload would be = stored in some Tx queue associated with the attachment circuit and controll= ed by the appropriate egress scheduler, but IMO this does not constitue a P= W jitter bufer, since the PW interworking function does not exersize any co= ntrol over these queues.=0A= In particular, these queues could not be used for re-ordering misordered PW= packets.=0A= IMHO and FWIW this understanding matches RFC 3985 which mentions (in Sectio= n 5.2.1.1 "Frame Ordering") that reodering as the strategy for handling mis= -ordered packets introduces additional delay (i.e., requires a ddicated jit= ter buffer), while the alternative strategy of discarding mis-ordered packe= ts does not introduce such additional delay.=0A= =0A= The editorial issue is about the entire sentence that contains the above-me= ntioned fragment, i.e., "A small jitter buffer is always necessary and the = jitter buffer is needed regardless of whether reordering is done" - to me t= his looks like an unnecessary repetition if if it were techically correct.= =0A= =0A= Hence I would like to suggest discrading the problematic sentence as the si= mplest way to resolve both issues.=0A= =0A= Hopefully these notes will e helpful.=0A= =0A= Regards,=0A= Sasha=0A= =0A= =0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Tuesday, December 10, 2013 5:47 PM=0A= To: Alexander Vainshtein=0A= Cc: curtis@ipv6.occnc.com; curtis@occnc.com; kireeti@juniper.net; samante@a= pple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stei= n (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwardin= g: a minor comment=0A= =0A= In message =0A= Alexander Vainshtein writes:=0A= >=0A= > Curtis,=0A= >=0A= > Lots of thanks for a prompt and very detailed response.=0A= > May I suggest an alternative version of the following text fragment?=0A= >=0A= > =0A= > > Identifying the position of any lost packets is important=0A= > > for PW services which are attempting to reconstruct a bit stream=0A= > > which maintains bit timing, such as time division multiplexing (TDM)= =0A= > > services. TDM and other PW services which require strict ordering= =0A= > > also require that misordered packets be either dropped or reordered.= =0A= =0A= Invalid XML - you didn't close this element. :-)=0A= =0A= > =0A= >=0A= > Identifying lost PW packets and exact amount of lost payload is=0A= > critical for PW services which maintain bit timing, such as Time=0A= > Division Multiplexing (TDM) services since these services MUST=0A= > compensate lost payload on a bit-for-bit basis.=0A= >=0A= > With these services PW packets that have been received out of order=0A= > also MUST also be identified and may be either re-ordered or=0A= > dropped. Reordering requires, in addition to sequence numbering, a=0A= > "de-jitter buffer" in the egress PE, and ability to reorder is=0A= > limited by the depth of this buffer. The down side of maintaining a=0A= > de-jitter buffer is added end-to-end service delay.=0A= >=0A= > =0A= =0A= Accepted with a small change.=0A= =0A= After the words "down side"=0A= s/de-jitter buffer/large jitter buffer/=0A= Elsewhere=0A= s/de-jitter buffer/jitter buffer/g=0A= Then add the sentence.=0A= =0A= A small jitter buffer is always necessary and the jitter buffer=0A= is needed regardless of whether reordering is done.=0A= =0A= This yields a slightly changed second paragraph.=0A= =0A= With these services PW packets that have been received out of order=0A= also MUST also be identified and may be either re-ordered or=0A= dropped. Reordering requires, in addition to sequence numbering, a=0A= "jitter buffer" in the egress PE, and ability to reorder is limited=0A= by the depth of this buffer. The down side of maintaining a large=0A= jitter buffer is added end-to-end service delay. A small jitter=0A= buffer is always necessary and the jitter buffer is needed=0A= regardless of whether reordering is done.=0A= =0A= Is this wording OK with you?=0A= =0A= Curtis=0A= =0A= > Hopefully this will be useful.=0A= >=0A= >=0A= > Regards,=0A= > Sasha=0A= >=0A= > > -----Original Message-----=0A= > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]=0A= > > Sent: Monday, November 25, 2013 8:30 PM=0A= > > To: Alexander Vainshtein=0A= > > Cc: curtis@occnc.com; kireeti@juniper.net; samante@apple.com;=0A= > > agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stein=0A= > > (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= > > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-=0A= > > forwarding: a minor comment=0A= > >=0A= > >=0A= > > In message=0A= > > > om>=0A= > > Alexander Vainshtein writes:=0A= > > >=0A= > > > Hi all,=0A= > > >=0A= > > > I would like to comment on the text in Section 2.1.8.1 "Pseudowire=0A= > > > Sequence Number" in draft-ietf-mpls-forwarding-03 - MPLS Forwarding= =0A= > > > Compliance and Performance Requirements=0A= > > > .=0A= > > >=0A= > > > This section states, in short, that the main drive for using the=0A= > > > sequence number in the PW Control Word is handling of packet=0A= > > > reordering events. TDM PWs are presented as a major example, with CBR= =0A= > > > ATM services as another example.=0A= > > >=0A= > > > In fact, this statement is not accurate.=0A= > >=0A= > > Yes. You are correct in pointing this out as inaccurate by omitting=0A= > > the other important function of identifying drops for the purpose of=0A= > > recunstructing TDM bit streams.=0A= > >=0A= > > Andy brought up resequencing being a strong provider request.=0A= > > Reordering is far more common than loss particularly for high priority= =0A= > > services on provider networks and without resequencing reorder results= =0A= > > in PW loss in what could otherwise be lossless service.=0A= > >=0A= > > So we should get the base requirements right but still reflect this,=0A= > > but strictly as advice with no normative wording. We had used the=0A= > > phrase "is beneficial" and will retain that.=0A= > >=0A= > > Andy brought up the topic. The incorrect wording in the existing=0A= > > draft is my fault. This text went in fairly early with a lot of other= =0A= > > changes and it appears that no one had since given it a careful enough= =0A= > > read and review until you came along.=0A= > >=0A= > > > The main drive for mandating the use of sequence number in TM PWs is= =0A= > > > the need to detect and count lost packets because the egress PE MUST= =0A= > > > compensate the lost payload bit for bit.=0A= > > >=0A= > > > Ability to compensate reordering of PW packets at egress is a side=0A= > > > effect of (a) sequence number usage and (b) usage of the de-jitter=0A= > > > buffer in the egress PW. It is not mandatory and in any case is=0A= > > > limited by the depth of the de-jitter buffer: re-ordered packets that= =0A= > > > cannot be accommodated within this buffer are treated as lost.=0A= > > >=0A= > > > Additional details can be found, e.g., in section 6.2.2 of RFC=0A= > > > 4553. Ability to re-order=0A= > > > mis-ordered PW packets is defined there as OPTIONAL, while replacemen= t=0A= > > > of the payload of lost PW packets is defined as MANDATORY.=0A= > >=0A= > > The change below at the top of the section more accurately reflects=0A= > > requirements in the RFCs but still states that resequencing can be=0A= > > beneficial. The comments about EPD and PPD are dropped and therefore= =0A= > > also the informative reference.=0A= > >=0A= > > Context:=0A= > >=0A= > > 2.1.8.1. Pseudowire Sequence Number=0A= > >=0A= > > OLD=0A= > >=0A= > > Pseudowire (PW) sequence number support is most important for PW=0A= > > payload types with a high expectation of in-order delivery.=0A= > > Resequencing support, rather than dropping at egress on out of order= =0A= > > arrival, is most important for PW payload types with a high=0A= > > expectation of lossless delivery. For example, TDM payloads require= =0A= > > sequence number support and require resequencing support. The same= =0A= > > is true of ATM CBR service. ATM VBR or ABR may have somewhat relaxe= d=0A= > > requirements, but generally require ATM Early Packet Discard (EPD) o= r=0A= > > ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequence= =0A= > > number support and resequencing support are beneficial to PW packet= =0A= > > oriented payloads such as FR and Ethernet, they are highly desirable= =0A= > > but not as strongly required.=0A= > >=0A= > > NEW=0A= > >=0A= > > Pseudowire (PW) sequence number support is most important for PW=0A= > > payload types with a high expectation of lossless and/or in-order=0A= > > delivery. Identifying the position of any lost packets is important= =0A= > > for PW services which are attempting to reconstruct a bit stream=0A= > > which maintains bit timing, such as time division multiplexing (TDM)= =0A= > > services. TDM and other PW services which require strict ordering= =0A= > > also require that misordered packets be either dropped or reordered.= =0A= > >=0A= > > PW services which are not timing critical bit streams in nature are= =0A= > > cell oriented or frame oriented. Though resequencing support is=0A= > > beneficial to PW cell and frame oriented payloads such as ATM, FR an= d=0A= > > Ethernet, they are highly desirable but not required.=0A= > >=0A= > > NEW (end of subsection after list of possible reording causes)=0A= > >=0A= > > In provider networks which use multipath techniques and which may=0A= > > occassionally rebalance traffic or which may change PW paths=0A= > > occasionally for other reasons, reordering may be far more common=0A= > > than loss. Where reordering is more common than loss, resequencing= =0A= > > packets is beneficial, rather than dropping packets at egress when= =0A= > > out of order arrival occus. Resequencing is most important for PW= =0A= > > payload types with a high expectation of lossless delivery since in= =0A= > > such cases out of order delivery within the network results in PW=0A= > > loss.=0A= > >=0A= > > The final paragraph sums up the motivation for highlighting=0A= > > resequencing as beneficial and desirable. It does so without any=0A= > > normative wording.=0A= > >=0A= > > > Hopefully these notes will be useful.=0A= > > >=0A= > > > Regards,=0A= > > > Sasha=0A= > >=0A= > > These notes are very useful. Thank you.=0A= > >=0A= > > Please let us know if you (and the WG) are OK with the rewording=0A= > > proposed above.=0A= > >=0A= > > Curtis=0A= From internet-drafts@ietf.org Wed Dec 11 06:59:17 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 9E7571ADF66; Wed, 11 Dec 2013 06:59: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 wIJPJadMTcnk; Wed, 11 Dec 2013 06:59:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 353C71AD34C; Wed, 11 Dec 2013 06:59:16 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211145915.2259.42298.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 06:59:15 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-hsmp-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: Wed, 11 Dec 2013 14:59: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 : LDP Extensions for Hub & Spoke Multipoint Label Switched= Path Author(s) : Lizhong Jin Frederic Jounay IJsbrand Wijnands Nicolai Leymann Filename : draft-ietf-mpls-mldp-hsmp-05.txt Pages : 16 Date : 2013-12-11 Abstract: 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. Direct communication among the leaf nodes is not allowed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-hsmp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-mldp-hsmp-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-mldp-hsmp-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 internet-drafts@ietf.org Wed Dec 11 09:09:30 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 34AD51AE160; Wed, 11 Dec 2013 09:09: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhpcBzIUIaOF; Wed, 11 Dec 2013 09:09:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F250A1AE03A; Wed, 11 Dec 2013 09:09:28 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211170928.24564.32989.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 09:09:28 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-10.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, 11 Dec 2013 17:09:30 -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 LDP for IPv6 Author(s) : Rajiv Asati Vishwas Manral Rajiv Papneja Carlos Pignataro Filename : draft-ietf-mpls-ldp-ipv6-10.txt Pages : 18 Date : 2013-12-11 Abstract: The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ipv6-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Dec 11 18:44:49 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 439CA1AE140; Wed, 11 Dec 2013 18:44:49 -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 vS4ZWlqAy0Qv; Wed, 11 Dec 2013 18:44:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F9A1AE114; Wed, 11 Dec 2013 18:44:47 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212024447.5862.39310.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 18:44:47 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-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, 12 Dec 2013 02:44: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 : Encapsulating MPLS in UDP Author(s) : Xiaohu Xu Nischal Sheth Lucy Yong Carlos Pignataro Yongbing Fan Filename : draft-ietf-mpls-in-udp-04.txt Pages : 11 Date : 2013-12-11 Abstract: This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol). 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-in-udp-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 Alexander.Vainshtein@ecitele.com Wed Dec 11 21:49:40 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 518F51AE006; Wed, 11 Dec 2013 21:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxtZXleP4YZZ; Wed, 11 Dec 2013 21:49:35 -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 6ACBE1A802D; Wed, 11 Dec 2013 21:49:32 -0800 (PST) Received: from AM3PR03MB529.eurprd03.prod.outlook.com (10.242.109.153) by AM3PR03MB401.eurprd03.prod.outlook.com (10.242.110.14) with Microsoft SMTP Server (TLS) id 15.0.837.10; Thu, 12 Dec 2013 05:49:26 +0000 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.842.7; Thu, 12 Dec 2013 05:49:24 +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.0842.003; Thu, 12 Dec 2013 05:49:23 +0000 From: Alexander Vainshtein To: "curtis@ipv6.occnc.com" Thread-Topic: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment Thread-Index: AQHO9vYcSq0tCZZscUehMpHq+OAdtZpQDFrZ Date: Thu, 12 Dec 2013 05:49:22 +0000 Message-ID: <4946c79f4554497d84cd676684739124@AM3PR03MB532.eurprd03.prod.outlook.com> References: Your message of "Wed, 11 Dec 2013 06:05:20 +0000." <774d74926b684ffba7f4f89ace758547@AM3PR03MB532.eurprd03.prod.outlook.com>, <201312120453.rBC4rYp4065163@gateway1.ipv6.occnc.com> In-Reply-To: <201312120453.rBC4rYp4065163@gateway1.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.202] x-forefront-prvs: 0058ABBBC7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(13464003)(53754006)(189002)(199002)(43784003)(377454003)(52604005)(51704005)(76482001)(47736001)(50986001)(47976001)(81342001)(4396001)(81816001)(76576001)(74662001)(47446002)(74502001)(76786001)(31966008)(74316001)(49866001)(71446004)(74366001)(56816005)(90146001)(66066001)(74706001)(63696002)(76796001)(85306002)(65816001)(80022001)(87266001)(87936001)(19580405001)(19580395003)(80976001)(2656002)(46102001)(83322001)(56776001)(79102001)(74876001)(77982001)(59766001)(83072002)(81542001)(51856001)(85852003)(33646001)(69226001)(54356001)(81686001)(54316002)(53806001)(427584002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB529; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:5.153.9.202; 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: "samante@apple.com" , "kireeti@juniper.net" , "mpls@ietf.org" , "curtis@occnc.com" , "pwe3 \(pwe3@ietf.org\)" Subject: Re: [mpls] [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Dec 2013 05:49:40 -0000 Curtis,=0A= Lots of hanks for a long and detailed explanation.=0A= =0A= It appears that your original comment about the need of jitter buffer refer= ed to TDM (or TDM-like) PWs (bit-stream PWs in the Architecture RFC). If th= is was indeed the case, there is nothing to argue about, because I agree co= mpletely that jitter buffer is absolutely necessary for these.=0A= =0A= My impression from reading the original text has been that it referred to A= LL kinds of PWs (bit-stream, celland packet) alike. Apparently this has bee= n my mis-interptetation; if this is indeed so, then maybe some clarificatio= n (placing the jiter buffer discussion in the proper context) would hopeful= ly help.=0A= =0A= Regards,=0A= Sasha=0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Thursday, December 12, 2013 6:53 AM=0A= To: Alexander Vainshtein=0A= Cc: curtis@occnc.com; curtis@ipv6.occnc.com; kireeti@juniper.net; samante@a= pple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stei= n (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwardin= g: a minor comment=0A= =0A= In message <774d74926b684ffba7f4f89ace758547@AM3PR03MB532.eurprd03.prod.out= look.com>=0A= Alexander Vainshtein writes:=0A= =0A= > Curtis,=0A= > Lots of thanks for sending out the new text.=0A= >=0A= > I still have a couple of issues with this version of the text: one=0A= > technical and one editorial.=0A= >=0A= > The technical issue is about the fragment "A small jitter buffer is=0A= > always necessary".=0A= >=0A= > I am not sure this is correct, since I am aware of several PW=0A= > implementations that pass the payload of a received PW packet directly=0A= > for transmission via the corresdponding attachment circuit. Of course=0A= > this payload would be stored in some Tx queue associated with the=0A= > attachment circuit and controlled by the appropriate egress scheduler,=0A= > but IMO this does not constitue a PW jitter bufer, since the PW=0A= > interworking function does not exersize any control over these=0A= > queues.=0A= =0A= Well if its a technical argument you want, then here goes ...=0A= =0A= Even in pure TDM systems some jitter exist due to the longer time it=0A= takes if multiple passes of the FEC algorithm are needed. In that=0A= case there is a very small jitter buffer that can be set to the=0A= maximum needed for a worst case FEC, or set lower to decrease delay=0A= with the potential to make a greater number of errors uncorrectable.=0A= =0A= For IP, even if IP EF service is used and there is a very small amount=0A= of EF traffic, some jitter exists. For most systems there is some=0A= jitter crossing the fabric and internal jitter elsewhere. The egress=0A= buffer in most chips is very small but needed for that jitter. For=0A= TDM, the egress buffer can never run dry or there will be a timing=0A= slip.=0A= =0A= Consider what happens when packets arrive late in a system with only a=0A= non-zero egress buffer. For example, assume 1% of packets arrive=0A= about one packet time late (one other EF packet in queue somewhere on=0A= the path), 0.1% arrive two packets late. Note that this would be an=0A= extremely light EF load. Generally most packets arrive at least zero=0A= to one minus epsilon packet times late due to a lower priority packet=0A= partially transmited when the EF packet is moved to the front of the=0A= queue. If there is no egress buffer at all or considerably less than=0A= a packet time, lots of data would be dropped. If the egress buffer=0A= could hold just a few packets data drop would be very low.=0A= =0A= If a packet arrives late and there is no standing queue the egress=0A= runs dry, there is a timing slip. When the packet does arrive a=0A= little late the packet is sent, albiet late. Every packet to follow=0A= is now late by that amount of time (if the egress buffer has not=0A= overflowed on a later packet).=0A= =0A= At that point there is an standing queue in the egress buffer which=0A= acts as a jitter buffer. Most packets arrive early. A few arrive a=0A= little later but as long as the queue doesn't run dry again, the=0A= jitter is compensated for.=0A= =0A= If the egress buffer is large, then it will tend to grow to the worst=0A= case packet delay and keep a large standing queue. This is with no=0A= reorder and no drop. If the egress buffer is small (or configured to=0A= be small) then when a packet arrives very late followed by a set of=0A= packets in close succession, the buffer runs dry until that first late=0A= packet arrives. This packet is transmitted but very late. Subsequent=0A= packets arrive and some of them have to be dropped due to the limited=0A= queue capacity. This in effect puts a cap on the jitter buffer.=0A= =0A= With only an egress buffer there are multiple strategies for dealing=0A= with dropped packets.=0A= =0A= 1. Just ignore it and send the next one.=0A= 2. Put one packet time worth of all zeros in the queue.=0A= =0A= Now consider what happens with a dropped packet and a standing queue.=0A= The first strategy creates a hidden timing slip. The second strategy=0A= avoids the timing slip.=0A= =0A= So my argument is that the egress buffer is in effect the jitter=0A= buffer. When jitter occurs a standing buffer forms that reflects the=0A= lesser of the limit of the buffer size or the worst case jitter.=0A= There is always a jitter buffer. There always needs to be a jitter=0A= buffer of at least one large packet time, otherwise high loss of data=0A= will occur. There should be a jitter buffer that can be made larger=0A= so that jitter of multiple packet times doesn't turn in to loss.=0A= =0A= Therefore I assert that a jitter buffer is always present and is=0A= always needed because jitter is always non-zero. Therefore this=0A= statement is true:=0A= =0A= A small jitter buffer is always necessary and the jitter buffer is=0A= needed regardless of whether reordering is done.=0A= =0A= > In particular, these queues could not be used for re-ordering=0A= > misordered PW packets.=0A= =0A= That does not mean that they can't be used to compensate for jitter=0A= which is by definition what a jitter buffer is for.=0A= =0A= When reordering is done, the egress buffer is made small and a buffer=0A= preceding that is used which has some ability to reorder packets. In=0A= hardware a circular queue makes sense with packets place according to=0A= their sequence number. If you prescribe to the "just insert zeros"=0A= idea when a packet is dropped, then after moving a packet to the=0A= egress queue, zero the buffer or mark it as unoccupied and more the=0A= circular buffer a bit. If the packet that is later supposed to occupy=0A= that slot never arrives, then it is already zerod (or marked as=0A= missing in which case a packet of all zeros is put on the egress=0A= queue).=0A= =0A= So ... reording within a small jitter buffer is not hard to do.=0A= =0A= Reordering can be supported with a small jitter buffer but adding=0A= reordering to a small buffer may be ineffective. If reordering is due=0A= to a path change, then the buffer of a small number of packet times=0A= may yield no improvement. To be effective in that situation, the=0A= buffer may need to be larger. OTOH if moving EF traffic from one=0A= queue with no standing EF queue to another with no standing EF queue=0A= and the path change is just moving to another wave on the WDM,=0A= reordering with a small jitter buffer may help.=0A= =0A= > IMHO and FWIW this understanding matches RFC 3985 which mentions (in=0A= > Section 5.2.1.1 "Frame Ordering") that reodering as the strategy for=0A= > handling mis-ordered packets introduces additional delay (i.e.,=0A= > requires a ddicated jitter buffer), while the alternative strategy of=0A= > discarding mis-ordered packets does not introduce such additional=0A= > delay.=0A= =0A= You quoted the framework and not a TDM document. Nowhere in that text=0A= is there mention of a jitter buffer because that text is not specific=0A= to TDM.=0A= =0A= For packet traffic you have no idea if a prior packet is dropped or=0A= will arrive out of order and so when a drop occurs packets have to be=0A= held for a non-zero amount of time rather than transmitted as soon as=0A= they arrive. This applies to all cell or packet AC, such as FR, ATM,=0A= Ethernet, etc.=0A= =0A= You might want to look at section 5.2.2.1. Clock Recovery which does=0A= apply to TDM. It points to RFC3550 (RTP) which assumes a jitter=0A= buffer is always needed.=0A= =0A= > The editorial issue is about the entire sentence that contains the=0A= > above-mentioned fragment, i.e., "A small jitter buffer is always=0A= > necessary and the jitter buffer is needed regardless of whether=0A= > reordering is done" - to me this looks like an unnecessary repetition=0A= > if if it were techically correct.=0A= =0A= The second part of the sentence was to emphasis that the need for a=0A= jitter buffer is not contingent on implementation or reordering.=0A= Perhaps it would be more clear if the two points were separated. How=0A= about this=0A= =0A= OLD new sentence=0A= =0A= A small jitter buffer is always necessary and the jitter buffer=0A= is needed regardless of whether reordering is done.=0A= =0A= NEW new sentence=0A= =0A= A small jitter buffer is always necessary. A jitter buffer is=0A= needed regardless of whether reordering is done.=0A= =0A= > Hence I would like to suggest discrading the problematic sentence as=0A= > the simplest way to resolve both issues.=0A= =0A= I think the sentence provides an important clarification. I think the=0A= need to have this discussion proves that the clarification is needed.=0A= =0A= If we can agree on keeping this, I can submit the updated draft.=0A= =0A= > Hopefully these notes will e helpful.=0A= >=0A= > Regards,=0A= > Sasha=0A= =0A= Thanks again for the review and good comments.=0A= =0A= Regards,=0A= =0A= Curtis=0A= =0A= =0A= > ________________________________________=0A= > From: Curtis Villamizar =0A= > Sent: Tuesday, December 10, 2013 5:47 PM=0A= > To: Alexander Vainshtein=0A= > Cc: curtis@ipv6.occnc.com; curtis@occnc.com; kireeti@juniper.net; samante= @apple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov St= ein (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forward= ing: a minor comment=0A= >=0A= > In message =0A= > Alexander Vainshtein writes:=0A= > >=0A= > > Curtis,=0A= > >=0A= > > Lots of thanks for a prompt and very detailed response.=0A= > > May I suggest an alternative version of the following text fragment?=0A= > >=0A= > > =0A= > > > Identifying the position of any lost packets is important=0A= > > > for PW services which are attempting to reconstruct a bit stream= =0A= > > > which maintains bit timing, such as time division multiplexing (TD= M)=0A= > > > services. TDM and other PW services which require strict ordering= =0A= > > > also require that misordered packets be either dropped or reordere= d.=0A= >=0A= > Invalid XML - you didn't close this element. :-)=0A= >=0A= > > =0A= > >=0A= > > Identifying lost PW packets and exact amount of lost payload is=0A= > > critical for PW services which maintain bit timing, such as Time=0A= > > Division Multiplexing (TDM) services since these services MUST=0A= > > compensate lost payload on a bit-for-bit basis.=0A= > >=0A= > > With these services PW packets that have been received out of order= =0A= > > also MUST also be identified and may be either re-ordered or=0A= > > dropped. Reordering requires, in addition to sequence numbering, a= =0A= > > "de-jitter buffer" in the egress PE, and ability to reorder is=0A= > > limited by the depth of this buffer. The down side of maintaining a= =0A= > > de-jitter buffer is added end-to-end service delay.=0A= > >=0A= > > =0A= >=0A= > Accepted with a small change.=0A= >=0A= > After the words "down side"=0A= > s/de-jitter buffer/large jitter buffer/=0A= > Elsewhere=0A= > s/de-jitter buffer/jitter buffer/g=0A= > Then add the sentence.=0A= >=0A= > A small jitter buffer is always necessary and the jitter buffer=0A= > is needed regardless of whether reordering is done.=0A= >=0A= > This yields a slightly changed second paragraph.=0A= >=0A= > With these services PW packets that have been received out of order=0A= > also MUST also be identified and may be either re-ordered or=0A= > dropped. Reordering requires, in addition to sequence numbering, a=0A= > "jitter buffer" in the egress PE, and ability to reorder is limited=0A= > by the depth of this buffer. The down side of maintaining a large=0A= > jitter buffer is added end-to-end service delay. A small jitter=0A= > buffer is always necessary and the jitter buffer is needed=0A= > regardless of whether reordering is done.=0A= >=0A= > Is this wording OK with you?=0A= >=0A= > Curtis=0A= >=0A= > > Hopefully this will be useful.=0A= > >=0A= > >=0A= > > Regards,=0A= > > Sasha=0A= > >=0A= > > > -----Original Message-----=0A= > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]=0A= > > > Sent: Monday, November 25, 2013 8:30 PM=0A= > > > To: Alexander Vainshtein=0A= > > > Cc: curtis@occnc.com; kireeti@juniper.net; samante@apple.com;=0A= > > > agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stein=0A= > > > (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= > > > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-=0A= > > > forwarding: a minor comment=0A= > > >=0A= > > >=0A= > > > In message=0A= > > > > > om>=0A= > > > Alexander Vainshtein writes:=0A= > > > >=0A= > > > > Hi all,=0A= > > > >=0A= > > > > I would like to comment on the text in Section 2.1.8.1 "Pseudowire= =0A= > > > > Sequence Number" in draft-ietf-mpls-forwarding-03 - MPLS Forwarding= =0A= > > > > Compliance and Performance Requirements=0A= > > > > .=0A= > > > >=0A= > > > > This section states, in short, that the main drive for using the=0A= > > > > sequence number in the PW Control Word is handling of packet=0A= > > > > reordering events. TDM PWs are presented as a major example, with C= BR=0A= > > > > ATM services as another example.=0A= > > > >=0A= > > > > In fact, this statement is not accurate.=0A= > > >=0A= > > > Yes. You are correct in pointing this out as inaccurate by omitting= =0A= > > > the other important function of identifying drops for the purpose of= =0A= > > > recunstructing TDM bit streams.=0A= > > >=0A= > > > Andy brought up resequencing being a strong provider request.=0A= > > > Reordering is far more common than loss particularly for high priorit= y=0A= > > > services on provider networks and without resequencing reorder result= s=0A= > > > in PW loss in what could otherwise be lossless service.=0A= > > >=0A= > > > So we should get the base requirements right but still reflect this,= =0A= > > > but strictly as advice with no normative wording. We had used the=0A= > > > phrase "is beneficial" and will retain that.=0A= > > >=0A= > > > Andy brought up the topic. The incorrect wording in the existing=0A= > > > draft is my fault. This text went in fairly early with a lot of othe= r=0A= > > > changes and it appears that no one had since given it a careful enoug= h=0A= > > > read and review until you came along.=0A= > > >=0A= > > > > The main drive for mandating the use of sequence number in TM PWs i= s=0A= > > > > the need to detect and count lost packets because the egress PE MUS= T=0A= > > > > compensate the lost payload bit for bit.=0A= > > > >=0A= > > > > Ability to compensate reordering of PW packets at egress is a side= =0A= > > > > effect of (a) sequence number usage and (b) usage of the de-jitter= =0A= > > > > buffer in the egress PW. It is not mandatory and in any case is=0A= > > > > limited by the depth of the de-jitter buffer: re-ordered packets th= at=0A= > > > > cannot be accommodated within this buffer are treated as lost.=0A= > > > >=0A= > > > > Additional details can be found, e.g., in section 6.2.2 of RFC=0A= > > > > 4553. Ability to re-order=0A= > > > > mis-ordered PW packets is defined there as OPTIONAL, while replacem= ent=0A= > > > > of the payload of lost PW packets is defined as MANDATORY.=0A= > > >=0A= > > > The change below at the top of the section more accurately reflects= =0A= > > > requirements in the RFCs but still states that resequencing can be=0A= > > > beneficial. The comments about EPD and PPD are dropped and therefore= =0A= > > > also the informative reference.=0A= > > >=0A= > > > Context:=0A= > > >=0A= > > > 2.1.8.1. Pseudowire Sequence Number=0A= > > >=0A= > > > OLD=0A= > > >=0A= > > > Pseudowire (PW) sequence number support is most important for PW= =0A= > > > payload types with a high expectation of in-order delivery.=0A= > > > Resequencing support, rather than dropping at egress on out of ord= er=0A= > > > arrival, is most important for PW payload types with a high=0A= > > > expectation of lossless delivery. For example, TDM payloads requi= re=0A= > > > sequence number support and require resequencing support. The sam= e=0A= > > > is true of ATM CBR service. ATM VBR or ABR may have somewhat rela= xed=0A= > > > requirements, but generally require ATM Early Packet Discard (EPD)= or=0A= > > > ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequen= ce=0A= > > > number support and resequencing support are beneficial to PW packe= t=0A= > > > oriented payloads such as FR and Ethernet, they are highly desirab= le=0A= > > > but not as strongly required.=0A= > > >=0A= > > > NEW=0A= > > >=0A= > > > Pseudowire (PW) sequence number support is most important for PW= =0A= > > > payload types with a high expectation of lossless and/or in-order= =0A= > > > delivery. Identifying the position of any lost packets is importa= nt=0A= > > > for PW services which are attempting to reconstruct a bit stream= =0A= > > > which maintains bit timing, such as time division multiplexing (TD= M)=0A= > > > services. TDM and other PW services which require strict ordering= =0A= > > > also require that misordered packets be either dropped or reordere= d.=0A= > > >=0A= > > > PW services which are not timing critical bit streams in nature ar= e=0A= > > > cell oriented or frame oriented. Though resequencing support is= =0A= > > > beneficial to PW cell and frame oriented payloads such as ATM, FR = and=0A= > > > Ethernet, they are highly desirable but not required.=0A= > > >=0A= > > > NEW (end of subsection after list of possible reording causes)=0A= > > >=0A= > > > In provider networks which use multipath techniques and which may= =0A= > > > occassionally rebalance traffic or which may change PW paths=0A= > > > occasionally for other reasons, reordering may be far more common= =0A= > > > than loss. Where reordering is more common than loss, resequencin= g=0A= > > > packets is beneficial, rather than dropping packets at egress when= =0A= > > > out of order arrival occus. Resequencing is most important for PW= =0A= > > > payload types with a high expectation of lossless delivery since i= n=0A= > > > such cases out of order delivery within the network results in PW= =0A= > > > loss.=0A= > > >=0A= > > > The final paragraph sums up the motivation for highlighting=0A= > > > resequencing as beneficial and desirable. It does so without any=0A= > > > normative wording.=0A= > > >=0A= > > > > Hopefully these notes will be useful.=0A= > > > >=0A= > > > > Regards,=0A= > > > > Sasha=0A= > > >=0A= > > > These notes are very useful. Thank you.=0A= > > >=0A= > > > Please let us know if you (and the WG) are OK with the rewording=0A= > > > proposed above.=0A= > > >=0A= > > > Curtis=0A= From loa@pi.nu Wed Dec 11 23:52:28 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 9A0C11A1F62 for ; Wed, 11 Dec 2013 23:52:28 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1AYar_5i4Hg for ; Wed, 11 Dec 2013 23:52:25 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACA31AE18C for ; Wed, 11 Dec 2013 23:52:24 -0800 (PST) Received: from [192.168.1.2] (unknown [112.208.74.180]) (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 2A9411800740; Thu, 12 Dec 2013 08:52:16 +0100 (CET) Message-ID: <52A96B2D.6060003@pi.nu> Date: Thu, 12 Dec 2013 15:52:13 +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-ldp-ipv6@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Short wg last call on 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, 12 Dec 2013 07:52:28 -0000 Working Group, This is to start a one week working group last call on draft-ietf-mpls-ldp-ipv6-10 We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good comments and the document almost ready to go. At that point a discussion on the number of LDP session needed between a pair LSRs with both IPv4 and IPv6 emerged, it has taken us quite a long time to resolve this. However, the author, wg chairs and people making the comments now agree that version -10 is resolve those comments. This working group last call is limited to the changes since the previous last call. A diff can be found at: http://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-ldp-ipv6-07&difftype=--html&submit=Go%21&url2=draft-ietf-mpls-ldp-ipv6-10 Please send you comments to the MPLS wg mailing list (mpls@ietf.org). This wglc ends Dec 20, 2013. /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 Thu Dec 12 02:53:14 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 3B72B1AE020 for ; Thu, 12 Dec 2013 02:53:14 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONWqYJkQtCN6 for ; Thu, 12 Dec 2013 02:53:12 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 024591ACCDC for ; Thu, 12 Dec 2013 02:53:12 -0800 (PST) Received: from [192.168.1.2] (unknown [112.208.74.180]) (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 94A321800740; Thu, 12 Dec 2013 11:53:03 +0100 (CET) Message-ID: <52A9958B.7040508@pi.nu> Date: Thu, 12 Dec 2013 18:52: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: Yakov Rekhter References: <529F425C.1050808@pi.nu> <201312061405.rB6E5bL25339@magenta.juniper.net> In-Reply-To: <201312061405.rB6E5bL25339@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Dec 2013 10:53:14 -0000 Yacov, I can't see that this flies! In fact it is counter to the wg chair proposal. We intended to keep the overlap as small as possible, specify a function in the document that needs the function. We did not intend to increase the overlap, but keep it as small as possible. You have this already neatly specified in draft-rekhter- let it stay there. /Loa On 2013-12-06 22:05, Yakov Rekhter wrote: > Loa, > >> Working Group, >> >> It has been pointed out that there is overlap between >> draft-wijnands-mpls-mldp-in-band-wildcard-encoding and >> draft-rekhter-mpls-pim-sm-over-mldp. Within the overlap >> there is a critical piece of the protocol specification. >> Having this specified in two places is likely to result >> in non-interoperable implementations. >> >> The working group chairs have discussed the overlap and >> propose the following as a means of moving forward. >> >> 1. Issue a single poll to adopt both documents together as >> working group documents >> >> 2. Assuming that the drafts are adopted, complete >> draft-wijnands-mpls-in-band-wildcard-encoding as the >> normative protocol specification of the piece within the >> overlap. >> >> 3. Where mechanisms in draft-wijnanads are needed in >> draft-rekhter-mpls-pim-sm-over-mldp have the latter document >> reference the necessary sections of the former document. > > This would be fine with me, *provided* that > draft-wijnands-mpls-in-band-wildcard-encoding will add the encoding > of two new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit > IPv6 Shared Tree TLV, as these two TLVs are required by the mechanisms > defined in draft-rekhter-mpls-pim-sm-over-mldp. > > Yakov. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From jeff.tantsura@ericsson.com Thu Dec 12 03:28:32 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 51C7A1A1F4A for ; Thu, 12 Dec 2013 03:28:32 -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 72QukaMYBGNP for ; Thu, 12 Dec 2013 03:28:30 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 24AAE1A1F3F for ; Thu, 12 Dec 2013 03:28:30 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-4c-52a99dd79422 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BF.35.04556.7DD99A25; Thu, 12 Dec 2013 12:28:24 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0347.000; Thu, 12 Dec 2013 06:28:22 -0500 From: Jeff Tantsura To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Thread-Topic: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6 Thread-Index: AQHO9w8dQlFE4U5kj0yDTsda2VjqS5pQOhaA Date: Thu, 12 Dec 2013 11:28:21 +0000 Message-ID: In-Reply-To: <52A96B2D.6060003@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <20E17FF451134F4C9E94837243FCD79B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPrO6NuSuDDD7/YLM4vm8yq8W/uXOY Le7s+sJq8f3SEhaLW0tXsjqwerQ+28vqsWTJTyaPWdPb2Dy+XP7MFsASxWWTkpqTWZZapG+X wJXRtHQ7W8E63oqHvyYzNjB+5+pi5OSQEDCRmDvxERuELSZx4d56IJuLQ0jgCKPEnnWvmSCc 5YwSTVN/MIFUsQkYSPz/dpwFJCEiMItJYtaFCYwgCWEBJ4mH77+ydzFyACWcJa68zwIJiwgY SZy+1wBWwiKgKjHh6A4WEJtXwFzi35mpYDYnULx3+kew+YxAV3w/tQbMZhYQl7j1ZD4TxHUC Ekv2nGeGsEUlXj7+xwpiiwroSbQdO8MOEVeW+D7nEQtEr47Egt2f2EDOYRawllh9PQ0irC2x bOFrZogTBCVOznzCMoFRbBaSbbOQdM9C6J6FpHsWku4FjKyrGDlKi1PLctONDDcxAqPtmASb 4w7GBZ8sDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRS3RFtnLH6oSn ky5n8m6Y8m/CfvZQ4echUTvyzbeWi67/dNYmnlUoRE0koFFw2xql+soIuQV2lxakV27t9OO7 eH/Kr0aLfYsks17Im/X2rCy+duFlQqSq/5pN2+bmhPg09bIfYrgyx6iz+dTqSWqMWifmRhsG za5lPfetOW5v0/Xo/tbH/mJKLMUZiYZazEXFiQAKs8lAhAIAAA== Subject: Re: [mpls] Short wg last call on 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, 12 Dec 2013 11:28:32 -0000 Yes/support Cheers, Jeff -----Original Message----- From: Loa Andersson Date: Wednesday, December 11, 2013 11:52 PM To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6 >Working Group, > >This is to start a one week working group last call on >draft-ietf-mpls-ldp-ipv6-10 > >We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good >comments and the document almost ready to go. At that point a discussion >on the number of LDP session needed between a pair LSRs with both IPv4 >and IPv6 emerged, it has taken us quite a long time to resolve this. > >However, the author, wg chairs and people making the comments now agree >that version -10 is resolve those comments. > >This working group last call is limited to the changes since the >previous last call. A diff can be found at: > >http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-ldp-ipv6-07&difftype=3D= --ht >ml&submit=3DGo%21&url2=3Ddraft-ietf-mpls-ldp-ipv6-10 > >Please send you comments to the MPLS wg mailing list (mpls@ietf.org). > >This wglc ends Dec 20, 2013. > >/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 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From huaimo.chen@huawei.com Thu Dec 12 05:21:17 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 882C31AE2C0 for ; Thu, 12 Dec 2013 05:21:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 KfnObC2NTrmL for ; Thu, 12 Dec 2013 05:21:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D574F1ADA5D for ; Thu, 12 Dec 2013 05:21:15 -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 BBH62923; Thu, 12 Dec 2013 13:21:08 +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, 12 Dec 2013 13:20:39 +0000 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 13:20:51 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.165]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Thu, 12 Dec 2013 05:20:45 -0800 From: Huaimo Chen To: "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHO9zz2D8OUboE/BU63IW10jjHvHg== Date: Thu, 12 Dec 2013 13:20:44 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.93] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C1F60Dsjceml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Raveendra Torvi 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: Thu, 12 Dec 2013 13:21:17 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C1F60Dsjceml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_5316A0AB3C851246A7CA5758973207D445C1F60Dsjceml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 fro= m some of the reviewers that they are comfortable with how the comments have been addressed. We would like t= o have the same response from the other two reviewers.

 

Best Regards,

Huaimo<= /p>

--_000_5316A0AB3C851246A7CA5758973207D445C1F60Dsjceml501mbschi_-- From yakov@juniper.net Thu Dec 12 08:51:47 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 D68CA1ADF7E for ; Thu, 12 Dec 2013 08:51:47 -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 3QNzzrz4dsJD for ; Thu, 12 Dec 2013 08:51:45 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8890A1AD8F4 for ; Thu, 12 Dec 2013 08:51:45 -0800 (PST) Received: from mail210-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.22; Thu, 12 Dec 2013 16:51:39 +0000 Received: from mail210-tx2 (localhost [127.0.0.1]) by mail210-tx2-R.bigfish.com (Postfix) with ESMTP id 5DB858C0312; Thu, 12 Dec 2013 16:51:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.16; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzdb82h62a3I98dI936eI1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h1155h) Received-SPF: softfail (mail210-tx2: transitioning domain of juniper.net does not designate 66.129.239.16 as permitted sender) client-ip=66.129.239.16; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail210-tx2 (localhost.localdomain [127.0.0.1]) by mail210-tx2 (MessageSwitch) id 138686709879899_31953; Thu, 12 Dec 2013 16:51:38 +0000 (UTC) Received: from TX2EHSMHS001.bigfish.com (unknown [10.9.14.241]) by mail210-tx2.bigfish.com (Postfix) with ESMTP id 057318A0064; Thu, 12 Dec 2013 16:51:38 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by TX2EHSMHS001.bigfish.com (10.9.99.101) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 12 Dec 2013 16:51:37 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Dec 2013 08:51:36 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id rBCGpYL46117; Thu, 12 Dec 2013 08:51:34 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201312121651.rBCGpYL46117@magenta.juniper.net> To: Loa Andersson In-Reply-To: <52A9958B.7040508@pi.nu> References: <529F425C.1050808@pi.nu> <201312061405.rB6E5bL25339@magenta.juniper.net> <52A9958B.7040508@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Thu, 12 Dec 2013 18:52:59 +0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8301.1386867093.1@juniper.net> Date: Thu, 12 Dec 2013 08:51:33 -0800 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Dec 2013 16:51:48 -0000 Loa, > Yacov, > > I can't see that this flies! In fact it is counter to the wg chair > proposal. We intended to keep the overlap as small as possible, > specify a function in the document that needs the function. We did > not intend to increase the overlap, but keep it as small as possible. > > You have this already neatly specified in draft-rekhter- let it stay > there. I am fine with keeping the encoding and the procedures for the two new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit IPv6 Shared Tree TLV in draft-rekhter-mpls-pim-sm-over-mldp. However, I have a question on the following: 2. Assuming that the drafts are adopted, complete draft-wijnands-mpls-in-band-wildcard-encoding as the normative protocol specification of the piece within the overlap. What do you define as "the overlap" ? Yakov. > > /Loa > > > > On 2013-12-06 22:05, Yakov Rekhter wrote: > > Loa, > > > >> Working Group, > >> > >> It has been pointed out that there is overlap between > >> draft-wijnands-mpls-mldp-in-band-wildcard-encoding and > >> draft-rekhter-mpls-pim-sm-over-mldp. Within the overlap > >> there is a critical piece of the protocol specification. > >> Having this specified in two places is likely to result > >> in non-interoperable implementations. > >> > >> The working group chairs have discussed the overlap and > >> propose the following as a means of moving forward. > >> > >> 1. Issue a single poll to adopt both documents together as > >> working group documents > >> > >> 2. Assuming that the drafts are adopted, complete > >> draft-wijnands-mpls-in-band-wildcard-encoding as the > >> normative protocol specification of the piece within the > >> overlap. > >> > >> 3. Where mechanisms in draft-wijnanads are needed in > >> draft-rekhter-mpls-pim-sm-over-mldp have the latter document > >> reference the necessary sections of the former document. > > > > This would be fine with me, *provided* that > > draft-wijnands-mpls-in-band-wildcard-encoding will add the encoding > > of two new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit > > IPv6 Shared Tree TLV, as these two TLVs are required by the mechanisms > > defined in draft-rekhter-mpls-pim-sm-over-mldp. > > > > Yakov. > > > > -- > > > 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 Dec 12 12:44:24 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 D21051AE42C; Thu, 12 Dec 2013 12:44: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 fjsklwaE6WDq; Thu, 12 Dec 2013 12:44:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFCC1ADFD6; Thu, 12 Dec 2013 12:44:23 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212204423.30513.5471.idtracker@ietfa.amsl.com> Date: Thu, 12 Dec 2013 12:44:23 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rsvp-te-hsmp-lsp-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, 12 Dec 2013 20:44:25 -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 : Hub and Spoke Multipoint Label Switched Path Tunnels Author(s) : Lizhong Jin Frederic Jounay Manav Bhatia Sriganesh Kini Filename : draft-ietf-mpls-rsvp-te-hsmp-lsp-01.txt Pages : 8 Date : 2013-12-12 Abstract: There are applications that require bi-directional, co-routed and guaranteed communication from a root node to several leaf nodes in a hub and spoke fashion. To meet such application requirements in a Multi-protocol Label Switching (MPLS) network this draft defines a Hub and Spoke Multipoint Traffic Engineered Label Switched Path (HSMP TE LSP) with resource reservations for guaranteed communication. This draft also defines a protocol to setup such LSPs by re-using and extending P2MP RSVP-TE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-te-hsmp-lsp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-hsmp-lsp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-rsvp-te-hsmp-lsp-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 Alexander.Vainshtein@ecitele.com Fri Dec 13 22:27:38 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 4FA3E1AE4B3; Fri, 13 Dec 2013 22:27:38 -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 mvaI8sfUXvuB; Fri, 13 Dec 2013 22:27:32 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) by ietfa.amsl.com (Postfix) with ESMTP id 75D361A802D; Fri, 13 Dec 2013 22:27:30 -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.842.7; Sat, 14 Dec 2013 06:27:21 +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.0842.003; Sat, 14 Dec 2013 06:27:20 +0000 From: Alexander Vainshtein To: "curtis@ipv6.occnc.com" Thread-Topic: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment Thread-Index: AQHO+DfmSq0tCZZscUehMpHq+OAdtZpTOidO Date: Sat, 14 Dec 2013 06:27:20 +0000 Message-ID: References: Your message of "Thu, 12 Dec 2013 05:49:22 +0000." <4946c79f4554497d84cd676684739124@AM3PR03MB532.eurprd03.prod.outlook.com>, <201312131917.rBDJH1ev034508@gateway1.ipv6.occnc.com> In-Reply-To: <201312131917.rBDJH1ev034508@gateway1.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.203] x-forefront-prvs: 00603B7EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(53754006)(43784003)(199002)(189002)(13464003)(51704005)(52604005)(377454003)(31966008)(74316001)(19580405001)(19580395003)(85306002)(85852003)(59766001)(83322001)(71446004)(74366001)(54356001)(4396001)(33646001)(47976001)(50986001)(49866001)(74706001)(74662001)(47736001)(81816001)(46102001)(81686001)(76576001)(76786001)(76482001)(51856001)(76796001)(56776001)(2656002)(47446002)(69226001)(65816001)(87266001)(74876001)(81342001)(83072002)(87936001)(66066001)(74502001)(53806001)(80976001)(81542001)(80022001)(54316002)(77982001)(79102001)(56816005)(90146001)(63696002)(427584002)(24736002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB530; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:5.153.9.203; 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: "samante@apple.com" , "kireeti@juniper.net" , "mpls@ietf.org" , "curtis@occnc.com" , "pwe3 \(pwe3@ietf.org\)" Subject: Re: [mpls] [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Dec 2013 06:27:38 -0000 Curtis,=0A= Lots of thanks for a prompt and most encouraging response.=0A= =0A= I believe that the last proposed text fully addreses both my original comme= nt and the misunderstanding that has been encountered at some stage in this= email thread.=0A= =0A= Regards,=0A= Sassha=0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Friday, December 13, 2013 9:17 PM=0A= To: Alexander Vainshtein=0A= Cc: curtis@ipv6.occnc.com; curtis@occnc.com; kireeti@juniper.net; samante@a= pple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stei= n (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwardin= g: a minor comment=0A= =0A= Sasha,=0A= =0A= Thanks for pointing out the lack of clarity regarding the context of=0A= the statement we were discussing. These are the first three paragraphs=0A= (originally one) of "2.1.8.1. Pseudowire Sequence Number" that we've=0A= been discussing=0A= =0A= Original (draft-ietf-mpls-forwarding-03, short but inaccurate)=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of in-order delivery.=0A= Resequencing support, rather than dropping at egress on out of order=0A= arrival, is most important for PW payload types with a high=0A= expectation of lossless delivery. For example, TDM payloads require=0A= sequence number support and require resequencing support. The same=0A= is true of ATM CBR service. ATM VBR or ABR may have somewhat relaxed=0A= requirements, but generally require ATM Early Packet Discard (EPD) or=0A= ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequence=0A= number support and resequencing support are beneficial to PW packet=0A= oriented payloads such as FR and Ethernet, they are highly desirable=0A= but not as strongly required.=0A= =0A= First change=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying the position of any lost packets is important=0A= for PW services which are attempting to reconstruct a bit stream=0A= which maintains bit timing, such as time division multiplexing (TDM)=0A= services. TDM and other PW services which require strict ordering=0A= also require that misordered packets be either dropped or reordered.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support is=0A= beneficial to PW cell and frame oriented payloads such as ATM, FR and=0A= Ethernet, they are highly desirable but not required.=0A= =0A= Suggested new para (Sasha) - part of second para rewritten=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying lost PW packets and exact amount of lost=0A= payload is critical for PW services which maintain bit timing, such=0A= as Time Division Multiplexing (TDM) services since these services=0A= MUST compensate lost payload on a bit-for-bit basis.=0A= =0A= With these services PW packets that have been received out of order=0A= also MUST also be identified and may be either re-ordered or=0A= dropped. Reordering requires, in addition to sequence numbering, a=0A= "de-jitter buffer" in the egress PE, and ability to reorder is=0A= limited by the depth of this buffer. The down side of maintaining a=0A= de-jitter buffer is added end-to-end service delay.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support is=0A= beneficial to PW cell and frame oriented payloads such as ATM, FR and=0A= Ethernet, they are highly desirable but not required.=0A= =0A= Suggested change to above (Curtis) - minor plus add last sentence=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying lost PW packets and exact amount of lost=0A= payload is critical for PW services which maintain bit timing, such=0A= as Time Division Multiplexing (TDM) services since these services=0A= MUST compensate lost payload on a bit-for-bit basis.=0A= =0A= With these services PW packets that have been received out of order=0A= also MUST also be identified and may be either re-ordered or=0A= dropped. Reordering requires, in addition to sequence numbering, a=0A= "jitter buffer" in the egress PE, and ability to reorder is limited=0A= by the depth of this buffer. The down side of maintaining a large=0A= jitter buffer is added end-to-end service delay. A small jitter=0A= buffer is always necessary and the jitter buffer is needed=0A= regardless of whether reordering is done.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support is=0A= beneficial to PW cell and frame oriented payloads such as ATM, FR=0A= and Ethernet, they are highly desirable but not required.=0A= =0A= Reorder paragraphs and edit for clarity of context=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying lost PW packets and exact amount of lost=0A= payload is critical for PW services which maintain bit timing, such=0A= as Time Division Multiplexing (TDM) services since these services=0A= MUST compensate lost payload on a bit-for-bit basis.=0A= =0A= With PW services which maintain bit timing, packets that have been=0A= received out of order also MUST be identified and may be either=0A= re-ordered or dropped. Reordering requires, in addition to=0A= sequence numbering, a "reorder buffer" in the egress PE, and ability=0A= to reorder is limited by the depth of this buffer. The down side of=0A= maintaining a large reorder buffer is added end-to-end service=0A= delay.=0A= =0A= For PW services which maintain bit timing or any other service=0A= where jitter must be bounded, a jitter buffer is always necessary.=0A= The jitter buffer is needed regardless of whether reordering is=0A= done. In order to be effective, a reorder buffer must often be=0A= larger than a jitter buffer needs to be creating a tradeoff between=0A= reducing loss and minimizing delay.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support may=0A= be beneficial to PW cell and frame oriented payloads such as ATM,=0A= FR and Ethernet, this support is desirable but not required.=0A= Requirements to hamdle out of order packets at all vary among=0A= services and deployments. For example for Ethernet PW, occasional=0A= (very rare) reordering is usually acceptable. If the Ethernet PW=0A= is carrying MPLS-TP, then this reordering may be acceptable.=0A= =0A= Reducing jitter is best done by an end-system, given that the=0A= tradeoff of loss vs delay varies among services. For example with=0A= interactive real time services low delay is preferred, while with=0A= non-interactive (one way) real time services low loss is preferred.=0A= The same end-site may be receiving both types of traffic.=0A= Regardless of this, bounded jitter is sometimes a requiremnet for=0A= specific deployments.=0A= =0A= In the prior iteration a paragraph began with "With these services"=0A= following the prior paragraph discussing "PW services which maintain=0A= bit timing, such as Time Division Multiplexing (TDM) services" which=0A= did not clearly carry over the context.=0A= =0A= At this point, each paragraph clearly indicates its context, either=0A= bit timing, not bit timing, or all PW. It also makes a distinction=0A= between a reorder buffer and a jitter buffer.=0A= =0A= This is a more thorough treatment of the tradeoffs of using PW=0A= sequence in supporting de-jitter and reordering in PW services than=0A= what was originally in the document (but given that it wasn't correct=0A= some change was needed).=0A= =0A= Curtis=0A= =0A= =0A= ps - Needed to top post a summary since your repeated top posting was=0A= obscuring the context of the (longish) conversation thread. You've=0A= probably seen something like this before:=0A= =0A= You're welcome.=0A= I get it. Thanks.=0A= Because it is the default in most pee-cee mailers.=0A= Why do people do it so often then?=0A= Because it loses context and reverses the order of the discussion.=0A= Why?=0A= Yes.=0A= Is top posting a bad practice?=0A= =0A= =0A= In message <4946c79f4554497d84cd676684739124@AM3PR03MB532.eurprd03.prod.out= look.com>=0A= Alexander Vainshtein writes:=0A= =0A= Curtis,=0A= Lots of hanks for a long and detailed explanation.=0A= =0A= It appears that your original comment about the need of jitter buffer=0A= refered to TDM (or TDM-like) PWs (bit-stream PWs in the Architecture=0A= RFC). If this was indeed the case, there is nothing to argue about,=0A= because I agree completely that jitter buffer is absolutely necessary=0A= for these.=0A= =0A= My impression from reading the original text has been that it referred=0A= to ALL kinds of PWs (bit-stream, celland packet) alike. Apparently=0A= this has been my mis-interptetation; if this is indeed so, then maybe=0A= some clarification (placing the jiter buffer discussion in the proper=0A= context) would hopefully help.=0A= =0A= Regards,=0A= Sasha=0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Thursday, December 12, 2013 6:53 AM=0A= To: Alexander Vainshtein=0A= Cc: curtis@occnc.com; curtis@ipv6.occnc.com; kireeti@juniper.net; samante@a= pple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stei= n (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwardin= g: a minor comment=0A= =0A= In message <774d74926b684ffba7f4f89ace758547@AM3PR03MB532.eurprd03.prod.out= look.com>=0A= Alexander Vainshtein writes:=0A= =0A= > Curtis,=0A= > Lots of thanks for sending out the new text.=0A= >=0A= > I still have a couple of issues with this version of the text: one=0A= > technical and one editorial.=0A= >=0A= > The technical issue is about the fragment "A small jitter buffer is=0A= > always necessary".=0A= >=0A= > I am not sure this is correct, since I am aware of several PW=0A= > implementations that pass the payload of a received PW packet directly=0A= > for transmission via the corresdponding attachment circuit. Of course=0A= > this payload would be stored in some Tx queue associated with the=0A= > attachment circuit and controlled by the appropriate egress scheduler,=0A= > but IMO this does not constitue a PW jitter bufer, since the PW=0A= > interworking function does not exersize any control over these=0A= > queues.=0A= =0A= Well if its a technical argument you want, then here goes ...=0A= =0A= Even in pure TDM systems some jitter exist due to the longer time it=0A= takes if multiple passes of the FEC algorithm are needed. In that=0A= case there is a very small jitter buffer that can be set to the=0A= maximum needed for a worst case FEC, or set lower to decrease delay=0A= with the potential to make a greater number of errors uncorrectable.=0A= =0A= For IP, even if IP EF service is used and there is a very small amount=0A= of EF traffic, some jitter exists. For most systems there is some=0A= jitter crossing the fabric and internal jitter elsewhere. The egress=0A= buffer in most chips is very small but needed for that jitter. For=0A= TDM, the egress buffer can never run dry or there will be a timing=0A= slip.=0A= =0A= Consider what happens when packets arrive late in a system with only a=0A= non-zero egress buffer. For example, assume 1% of packets arrive=0A= about one packet time late (one other EF packet in queue somewhere on=0A= the path), 0.1% arrive two packets late. Note that this would be an=0A= extremely light EF load. Generally most packets arrive at least zero=0A= to one minus epsilon packet times late due to a lower priority packet=0A= partially transmited when the EF packet is moved to the front of the=0A= queue. If there is no egress buffer at all or considerably less than=0A= a packet time, lots of data would be dropped. If the egress buffer=0A= could hold just a few packets data drop would be very low.=0A= =0A= If a packet arrives late and there is no standing queue the egress=0A= runs dry, there is a timing slip. When the packet does arrive a=0A= little late the packet is sent, albiet late. Every packet to follow=0A= is now late by that amount of time (if the egress buffer has not=0A= overflowed on a later packet).=0A= =0A= At that point there is an standing queue in the egress buffer which=0A= acts as a jitter buffer. Most packets arrive early. A few arrive a=0A= little later but as long as the queue doesn't run dry again, the=0A= jitter is compensated for.=0A= =0A= If the egress buffer is large, then it will tend to grow to the worst=0A= case packet delay and keep a large standing queue. This is with no=0A= reorder and no drop. If the egress buffer is small (or configured to=0A= be small) then when a packet arrives very late followed by a set of=0A= packets in close succession, the buffer runs dry until that first late=0A= packet arrives. This packet is transmitted but very late. Subsequent=0A= packets arrive and some of them have to be dropped due to the limited=0A= queue capacity. This in effect puts a cap on the jitter buffer.=0A= =0A= With only an egress buffer there are multiple strategies for dealing=0A= with dropped packets.=0A= =0A= 1. Just ignore it and send the next one.=0A= 2. Put one packet time worth of all zeros in the queue.=0A= =0A= Now consider what happens with a dropped packet and a standing queue.=0A= The first strategy creates a hidden timing slip. The second strategy=0A= avoids the timing slip.=0A= =0A= So my argument is that the egress buffer is in effect the jitter=0A= buffer. When jitter occurs a standing buffer forms that reflects the=0A= lesser of the limit of the buffer size or the worst case jitter.=0A= There is always a jitter buffer. There always needs to be a jitter=0A= buffer of at least one large packet time, otherwise high loss of data=0A= will occur. There should be a jitter buffer that can be made larger=0A= so that jitter of multiple packet times doesn't turn in to loss.=0A= =0A= Therefore I assert that a jitter buffer is always present and is=0A= always needed because jitter is always non-zero. Therefore this=0A= statement is true:=0A= =0A= A small jitter buffer is always necessary and the jitter buffer is=0A= needed regardless of whether reordering is done.=0A= =0A= > In particular, these queues could not be used for re-ordering=0A= > misordered PW packets.=0A= =0A= That does not mean that they can't be used to compensate for jitter=0A= which is by definition what a jitter buffer is for.=0A= =0A= When reordering is done, the egress buffer is made small and a buffer=0A= preceding that is used which has some ability to reorder packets. In=0A= hardware a circular queue makes sense with packets place according to=0A= their sequence number. If you prescribe to the "just insert zeros"=0A= idea when a packet is dropped, then after moving a packet to the=0A= egress queue, zero the buffer or mark it as unoccupied and more the=0A= circular buffer a bit. If the packet that is later supposed to occupy=0A= that slot never arrives, then it is already zerod (or marked as=0A= missing in which case a packet of all zeros is put on the egress=0A= queue).=0A= =0A= So ... reording within a small jitter buffer is not hard to do.=0A= =0A= Reordering can be supported with a small jitter buffer but adding=0A= reordering to a small buffer may be ineffective. If reordering is due=0A= to a path change, then the buffer of a small number of packet times=0A= may yield no improvement. To be effective in that situation, the=0A= buffer may need to be larger. OTOH if moving EF traffic from one=0A= queue with no standing EF queue to another with no standing EF queue=0A= and the path change is just moving to another wave on the WDM,=0A= reordering with a small jitter buffer may help.=0A= =0A= > IMHO and FWIW this understanding matches RFC 3985 which mentions (in=0A= > Section 5.2.1.1 "Frame Ordering") that reodering as the strategy for=0A= > handling mis-ordered packets introduces additional delay (i.e.,=0A= > requires a ddicated jitter buffer), while the alternative strategy of=0A= > discarding mis-ordered packets does not introduce such additional=0A= > delay.=0A= =0A= You quoted the framework and not a TDM document. Nowhere in that text=0A= is there mention of a jitter buffer because that text is not specific=0A= to TDM.=0A= =0A= For packet traffic you have no idea if a prior packet is dropped or=0A= will arrive out of order and so when a drop occurs packets have to be=0A= held for a non-zero amount of time rather than transmitted as soon as=0A= they arrive. This applies to all cell or packet AC, such as FR, ATM,=0A= Ethernet, etc.=0A= =0A= You might want to look at section 5.2.2.1. Clock Recovery which does=0A= apply to TDM. It points to RFC3550 (RTP) which assumes a jitter=0A= buffer is always needed.=0A= =0A= > The editorial issue is about the entire sentence that contains the=0A= > above-mentioned fragment, i.e., "A small jitter buffer is always=0A= > necessary and the jitter buffer is needed regardless of whether=0A= > reordering is done" - to me this looks like an unnecessary repetition=0A= > if if it were techically correct.=0A= =0A= The second part of the sentence was to emphasis that the need for a=0A= jitter buffer is not contingent on implementation or reordering.=0A= Perhaps it would be more clear if the two points were separated. How=0A= about this=0A= =0A= OLD new sentence=0A= =0A= A small jitter buffer is always necessary and the jitter buffer=0A= is needed regardless of whether reordering is done.=0A= =0A= NEW new sentence=0A= =0A= A small jitter buffer is always necessary. A jitter buffer is=0A= needed regardless of whether reordering is done.=0A= =0A= > Hence I would like to suggest discrading the problematic sentence as=0A= > the simplest way to resolve both issues.=0A= =0A= I think the sentence provides an important clarification. I think the=0A= need to have this discussion proves that the clarification is needed.=0A= =0A= If we can agree on keeping this, I can submit the updated draft.=0A= =0A= > Hopefully these notes will e helpful.=0A= >=0A= > Regards,=0A= > Sasha=0A= =0A= Thanks again for the review and good comments.=0A= =0A= Regards,=0A= =0A= Curtis=0A= =0A= =0A= > ________________________________________=0A= > From: Curtis Villamizar =0A= > Sent: Tuesday, December 10, 2013 5:47 PM=0A= > To: Alexander Vainshtein=0A= > Cc: curtis@ipv6.occnc.com; curtis@occnc.com; kireeti@juniper.net; samante= @apple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov St= ein (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forward= ing: a minor comment=0A= >=0A= > In message =0A= > Alexander Vainshtein writes:=0A= > >=0A= > > Curtis,=0A= > >=0A= > > Lots of thanks for a prompt and very detailed response.=0A= > > May I suggest an alternative version of the following text fragment?=0A= > >=0A= > > =0A= > > > Identifying the position of any lost packets is important=0A= > > > for PW services which are attempting to reconstruct a bit stream= =0A= > > > which maintains bit timing, such as time division multiplexing (TD= M)=0A= > > > services. TDM and other PW services which require strict ordering= =0A= > > > also require that misordered packets be either dropped or reordere= d.=0A= >=0A= > Invalid XML - you didn't close this element. :-)=0A= >=0A= > > =0A= > >=0A= > > Identifying lost PW packets and exact amount of lost payload is=0A= > > critical for PW services which maintain bit timing, such as Time=0A= > > Division Multiplexing (TDM) services since these services MUST=0A= > > compensate lost payload on a bit-for-bit basis.=0A= > >=0A= > > With these services PW packets that have been received out of order= =0A= > > also MUST also be identified and may be either re-ordered or=0A= > > dropped. Reordering requires, in addition to sequence numbering, a= =0A= > > "de-jitter buffer" in the egress PE, and ability to reorder is=0A= > > limited by the depth of this buffer. The down side of maintaining a= =0A= > > de-jitter buffer is added end-to-end service delay.=0A= > >=0A= > > =0A= >=0A= > Accepted with a small change.=0A= >=0A= > After the words "down side"=0A= > s/de-jitter buffer/large jitter buffer/=0A= > Elsewhere=0A= > s/de-jitter buffer/jitter buffer/g=0A= > Then add the sentence.=0A= >=0A= > A small jitter buffer is always necessary and the jitter buffer=0A= > is needed regardless of whether reordering is done.=0A= >=0A= > This yields a slightly changed second paragraph.=0A= >=0A= > With these services PW packets that have been received out of order=0A= > also MUST also be identified and may be either re-ordered or=0A= > dropped. Reordering requires, in addition to sequence numbering, a=0A= > "jitter buffer" in the egress PE, and ability to reorder is limited=0A= > by the depth of this buffer. The down side of maintaining a large=0A= > jitter buffer is added end-to-end service delay. A small jitter=0A= > buffer is always necessary and the jitter buffer is needed=0A= > regardless of whether reordering is done.=0A= >=0A= > Is this wording OK with you?=0A= >=0A= > Curtis=0A= >=0A= > > Hopefully this will be useful.=0A= > >=0A= > >=0A= > > Regards,=0A= > > Sasha=0A= > >=0A= > > > -----Original Message-----=0A= > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]=0A= > > > Sent: Monday, November 25, 2013 8:30 PM=0A= > > > To: Alexander Vainshtein=0A= > > > Cc: curtis@occnc.com; kireeti@juniper.net; samante@apple.com;=0A= > > > agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stein=0A= > > > (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= > > > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-=0A= > > > forwarding: a minor comment=0A= > > >=0A= > > >=0A= > > > In message=0A= > > > > > om>=0A= > > > Alexander Vainshtein writes:=0A= > > > >=0A= > > > > Hi all,=0A= > > > >=0A= > > > > I would like to comment on the text in Section 2.1.8.1 "Pseudowire= =0A= > > > > Sequence Number" in draft-ietf-mpls-forwarding-03 - MPLS Forwarding= =0A= > > > > Compliance and Performance Requirements=0A= > > > > .=0A= > > > >=0A= > > > > This section states, in short, that the main drive for using the=0A= > > > > sequence number in the PW Control Word is handling of packet=0A= > > > > reordering events. TDM PWs are presented as a major example, with C= BR=0A= > > > > ATM services as another example.=0A= > > > >=0A= > > > > In fact, this statement is not accurate.=0A= > > >=0A= > > > Yes. You are correct in pointing this out as inaccurate by omitting= =0A= > > > the other important function of identifying drops for the purpose of= =0A= > > > recunstructing TDM bit streams.=0A= > > >=0A= > > > Andy brought up resequencing being a strong provider request.=0A= > > > Reordering is far more common than loss particularly for high priorit= y=0A= > > > services on provider networks and without resequencing reorder result= s=0A= > > > in PW loss in what could otherwise be lossless service.=0A= > > >=0A= > > > So we should get the base requirements right but still reflect this,= =0A= > > > but strictly as advice with no normative wording. We had used the=0A= > > > phrase "is beneficial" and will retain that.=0A= > > >=0A= > > > Andy brought up the topic. The incorrect wording in the existing=0A= > > > draft is my fault. This text went in fairly early with a lot of othe= r=0A= > > > changes and it appears that no one had since given it a careful enoug= h=0A= > > > read and review until you came along.=0A= > > >=0A= > > > > The main drive for mandating the use of sequence number in TM PWs i= s=0A= > > > > the need to detect and count lost packets because the egress PE MUS= T=0A= > > > > compensate the lost payload bit for bit.=0A= > > > >=0A= > > > > Ability to compensate reordering of PW packets at egress is a side= =0A= > > > > effect of (a) sequence number usage and (b) usage of the de-jitter= =0A= > > > > buffer in the egress PW. It is not mandatory and in any case is=0A= > > > > limited by the depth of the de-jitter buffer: re-ordered packets th= at=0A= > > > > cannot be accommodated within this buffer are treated as lost.=0A= > > > >=0A= > > > > Additional details can be found, e.g., in section 6.2.2 of RFC=0A= > > > > 4553. Ability to re-order=0A= > > > > mis-ordered PW packets is defined there as OPTIONAL, while replacem= ent=0A= > > > > of the payload of lost PW packets is defined as MANDATORY.=0A= > > >=0A= > > > The change below at the top of the section more accurately reflects= =0A= > > > requirements in the RFCs but still states that resequencing can be=0A= > > > beneficial. The comments about EPD and PPD are dropped and therefore= =0A= > > > also the informative reference.=0A= > > >=0A= > > > Context:=0A= > > >=0A= > > > 2.1.8.1. Pseudowire Sequence Number=0A= > > >=0A= > > > OLD=0A= > > >=0A= > > > Pseudowire (PW) sequence number support is most important for PW= =0A= > > > payload types with a high expectation of in-order delivery.=0A= > > > Resequencing support, rather than dropping at egress on out of ord= er=0A= > > > arrival, is most important for PW payload types with a high=0A= > > > expectation of lossless delivery. For example, TDM payloads requi= re=0A= > > > sequence number support and require resequencing support. The sam= e=0A= > > > is true of ATM CBR service. ATM VBR or ABR may have somewhat rela= xed=0A= > > > requirements, but generally require ATM Early Packet Discard (EPD)= or=0A= > > > ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequen= ce=0A= > > > number support and resequencing support are beneficial to PW packe= t=0A= > > > oriented payloads such as FR and Ethernet, they are highly desirab= le=0A= > > > but not as strongly required.=0A= > > >=0A= > > > NEW=0A= > > >=0A= > > > Pseudowire (PW) sequence number support is most important for PW= =0A= > > > payload types with a high expectation of lossless and/or in-order= =0A= > > > delivery. Identifying the position of any lost packets is importa= nt=0A= > > > for PW services which are attempting to reconstruct a bit stream= =0A= > > > which maintains bit timing, such as time division multiplexing (TD= M)=0A= > > > services. TDM and other PW services which require strict ordering= =0A= > > > also require that misordered packets be either dropped or reordere= d.=0A= > > >=0A= > > > PW services which are not timing critical bit streams in nature ar= e=0A= > > > cell oriented or frame oriented. Though resequencing support is= =0A= > > > beneficial to PW cell and frame oriented payloads such as ATM, FR = and=0A= > > > Ethernet, they are highly desirable but not required.=0A= > > >=0A= > > > NEW (end of subsection after list of possible reording causes)=0A= > > >=0A= > > > In provider networks which use multipath techniques and which may= =0A= > > > occassionally rebalance traffic or which may change PW paths=0A= > > > occasionally for other reasons, reordering may be far more common= =0A= > > > than loss. Where reordering is more common than loss, resequencin= g=0A= > > > packets is beneficial, rather than dropping packets at egress when= =0A= > > > out of order arrival occus. Resequencing is most important for PW= =0A= > > > payload types with a high expectation of lossless delivery since i= n=0A= > > > such cases out of order delivery within the network results in PW= =0A= > > > loss.=0A= > > >=0A= > > > The final paragraph sums up the motivation for highlighting=0A= > > > resequencing as beneficial and desirable. It does so without any=0A= > > > normative wording.=0A= > > >=0A= > > > > Hopefully these notes will be useful.=0A= > > > >=0A= > > > > Regards,=0A= > > > > Sasha=0A= > > >=0A= > > > These notes are very useful. Thank you.=0A= > > >=0A= > > > Please let us know if you (and the WG) are OK with the rewording=0A= > > > proposed above.=0A= > > >=0A= > > > Curtis=0A= =0A= From Alexander.Vainshtein@ecitele.com Fri Dec 13 22:27:45 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 34D5D1AE4E8; Fri, 13 Dec 2013 22:27:45 -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 L9k3Gcpf30vQ; Fri, 13 Dec 2013 22:27:40 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0017.outbound.protection.outlook.com [213.199.154.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA461A802D; Fri, 13 Dec 2013 22:27:39 -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.842.7; Sat, 14 Dec 2013 06:27: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.0842.003; Sat, 14 Dec 2013 06:27:29 +0000 From: Alexander Vainshtein To: "curtis@ipv6.occnc.com" Thread-Topic: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment Thread-Index: AQHO+JWQSq0tCZZscUehMpHq+OAdtQ== Date: Sat, 14 Dec 2013 06:27:29 +0000 Message-ID: <0e9fa8a68b14411983975b85d76678ca@AM3PR03MB532.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.203] x-forefront-prvs: 00603B7EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(52604005)(377454003)(43784003)(189002)(199002)(53754006)(13464003)(51704005)(81342001)(65816001)(74502001)(87936001)(83072002)(74706001)(56776001)(76576001)(76786001)(87266001)(76796001)(74876001)(69226001)(51856001)(76176001)(81542001)(2656002)(90146001)(56816005)(47446002)(79102001)(53806001)(63696002)(66066001)(80022001)(76482001)(74662001)(71446004)(85852003)(77982001)(54316002)(81686001)(74366001)(31966008)(74316001)(83322001)(4396001)(46102001)(54356001)(80976001)(81816001)(59766001)(33646001)(47976001)(19580395003)(19580405001)(85306002)(47736001)(50986001)(49866001)(427584002)(24736002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB532; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:5.153.9.203; 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: "samante@apple.com" , "kireeti@juniper.net" , "mpls@ietf.org" , "curtis@occnc.com" , "pwe3 \(pwe3@ietf.org\)" Subject: Re: [mpls] [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Dec 2013 06:27:45 -0000 Curtis,=0A= Lots of thanks for a prompt and most encouraging response.=0A= =0A= I believe that the last proposed text fully addreses both my original comme= nt and the misunderstanding that has been encountered at some stage in this= email thread.=0A= =0A= Regards,=0A= Sassha=0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Friday, December 13, 2013 9:17 PM=0A= To: Alexander Vainshtein=0A= Cc: curtis@ipv6.occnc.com; curtis@occnc.com; kireeti@juniper.net; samante@a= pple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stei= n (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwardin= g: a minor comment=0A= =0A= Sasha,=0A= =0A= Thanks for pointing out the lack of clarity regarding the context of=0A= the statement we were discussing. These are the first three paragraphs=0A= (originally one) of "2.1.8.1. Pseudowire Sequence Number" that we've=0A= been discussing=0A= =0A= Original (draft-ietf-mpls-forwarding-03, short but inaccurate)=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of in-order delivery.=0A= Resequencing support, rather than dropping at egress on out of order=0A= arrival, is most important for PW payload types with a high=0A= expectation of lossless delivery. For example, TDM payloads require=0A= sequence number support and require resequencing support. The same=0A= is true of ATM CBR service. ATM VBR or ABR may have somewhat relaxed=0A= requirements, but generally require ATM Early Packet Discard (EPD) or=0A= ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequence=0A= number support and resequencing support are beneficial to PW packet=0A= oriented payloads such as FR and Ethernet, they are highly desirable=0A= but not as strongly required.=0A= =0A= First change=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying the position of any lost packets is important=0A= for PW services which are attempting to reconstruct a bit stream=0A= which maintains bit timing, such as time division multiplexing (TDM)=0A= services. TDM and other PW services which require strict ordering=0A= also require that misordered packets be either dropped or reordered.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support is=0A= beneficial to PW cell and frame oriented payloads such as ATM, FR and=0A= Ethernet, they are highly desirable but not required.=0A= =0A= Suggested new para (Sasha) - part of second para rewritten=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying lost PW packets and exact amount of lost=0A= payload is critical for PW services which maintain bit timing, such=0A= as Time Division Multiplexing (TDM) services since these services=0A= MUST compensate lost payload on a bit-for-bit basis.=0A= =0A= With these services PW packets that have been received out of order=0A= also MUST also be identified and may be either re-ordered or=0A= dropped. Reordering requires, in addition to sequence numbering, a=0A= "de-jitter buffer" in the egress PE, and ability to reorder is=0A= limited by the depth of this buffer. The down side of maintaining a=0A= de-jitter buffer is added end-to-end service delay.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support is=0A= beneficial to PW cell and frame oriented payloads such as ATM, FR and=0A= Ethernet, they are highly desirable but not required.=0A= =0A= Suggested change to above (Curtis) - minor plus add last sentence=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying lost PW packets and exact amount of lost=0A= payload is critical for PW services which maintain bit timing, such=0A= as Time Division Multiplexing (TDM) services since these services=0A= MUST compensate lost payload on a bit-for-bit basis.=0A= =0A= With these services PW packets that have been received out of order=0A= also MUST also be identified and may be either re-ordered or=0A= dropped. Reordering requires, in addition to sequence numbering, a=0A= "jitter buffer" in the egress PE, and ability to reorder is limited=0A= by the depth of this buffer. The down side of maintaining a large=0A= jitter buffer is added end-to-end service delay. A small jitter=0A= buffer is always necessary and the jitter buffer is needed=0A= regardless of whether reordering is done.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support is=0A= beneficial to PW cell and frame oriented payloads such as ATM, FR=0A= and Ethernet, they are highly desirable but not required.=0A= =0A= Reorder paragraphs and edit for clarity of context=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying lost PW packets and exact amount of lost=0A= payload is critical for PW services which maintain bit timing, such=0A= as Time Division Multiplexing (TDM) services since these services=0A= MUST compensate lost payload on a bit-for-bit basis.=0A= =0A= With PW services which maintain bit timing, packets that have been=0A= received out of order also MUST be identified and may be either=0A= re-ordered or dropped. Reordering requires, in addition to=0A= sequence numbering, a "reorder buffer" in the egress PE, and ability=0A= to reorder is limited by the depth of this buffer. The down side of=0A= maintaining a large reorder buffer is added end-to-end service=0A= delay.=0A= =0A= For PW services which maintain bit timing or any other service=0A= where jitter must be bounded, a jitter buffer is always necessary.=0A= The jitter buffer is needed regardless of whether reordering is=0A= done. In order to be effective, a reorder buffer must often be=0A= larger than a jitter buffer needs to be creating a tradeoff between=0A= reducing loss and minimizing delay.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support may=0A= be beneficial to PW cell and frame oriented payloads such as ATM,=0A= FR and Ethernet, this support is desirable but not required.=0A= Requirements to hamdle out of order packets at all vary among=0A= services and deployments. For example for Ethernet PW, occasional=0A= (very rare) reordering is usually acceptable. If the Ethernet PW=0A= is carrying MPLS-TP, then this reordering may be acceptable.=0A= =0A= Reducing jitter is best done by an end-system, given that the=0A= tradeoff of loss vs delay varies among services. For example with=0A= interactive real time services low delay is preferred, while with=0A= non-interactive (one way) real time services low loss is preferred.=0A= The same end-site may be receiving both types of traffic.=0A= Regardless of this, bounded jitter is sometimes a requiremnet for=0A= specific deployments.=0A= =0A= In the prior iteration a paragraph began with "With these services"=0A= following the prior paragraph discussing "PW services which maintain=0A= bit timing, such as Time Division Multiplexing (TDM) services" which=0A= did not clearly carry over the context.=0A= =0A= At this point, each paragraph clearly indicates its context, either=0A= bit timing, not bit timing, or all PW. It also makes a distinction=0A= between a reorder buffer and a jitter buffer.=0A= =0A= This is a more thorough treatment of the tradeoffs of using PW=0A= sequence in supporting de-jitter and reordering in PW services than=0A= what was originally in the document (but given that it wasn't correct=0A= some change was needed).=0A= =0A= Curtis=0A= =0A= =0A= ps - Needed to top post a summary since your repeated top posting was=0A= obscuring the context of the (longish) conversation thread. You've=0A= probably seen something like this before:=0A= =0A= You're welcome.=0A= I get it. Thanks.=0A= Because it is the default in most pee-cee mailers.=0A= Why do people do it so often then?=0A= Because it loses context and reverses the order of the discussion.=0A= Why?=0A= Yes.=0A= Is top posting a bad practice?=0A= =0A= =0A= In message <4946c79f4554497d84cd676684739124@AM3PR03MB532.eurprd03.prod.out= look.com>=0A= Alexander Vainshtein writes:=0A= =0A= Curtis,=0A= Lots of hanks for a long and detailed explanation.=0A= =0A= It appears that your original comment about the need of jitter buffer=0A= refered to TDM (or TDM-like) PWs (bit-stream PWs in the Architecture=0A= RFC). If this was indeed the case, there is nothing to argue about,=0A= because I agree completely that jitter buffer is absolutely necessary=0A= for these.=0A= =0A= My impression from reading the original text has been that it referred=0A= to ALL kinds of PWs (bit-stream, celland packet) alike. Apparently=0A= this has been my mis-interptetation; if this is indeed so, then maybe=0A= some clarification (placing the jiter buffer discussion in the proper=0A= context) would hopefully help.=0A= =0A= Regards,=0A= Sasha=0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Thursday, December 12, 2013 6:53 AM=0A= To: Alexander Vainshtein=0A= Cc: curtis@occnc.com; curtis@ipv6.occnc.com; kireeti@juniper.net; samante@a= pple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stei= n (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwardin= g: a minor comment=0A= =0A= In message <774d74926b684ffba7f4f89ace758547@AM3PR03MB532.eurprd03.prod.out= look.com>=0A= Alexander Vainshtein writes:=0A= =0A= > Curtis,=0A= > Lots of thanks for sending out the new text.=0A= >=0A= > I still have a couple of issues with this version of the text: one=0A= > technical and one editorial.=0A= >=0A= > The technical issue is about the fragment "A small jitter buffer is=0A= > always necessary".=0A= >=0A= > I am not sure this is correct, since I am aware of several PW=0A= > implementations that pass the payload of a received PW packet directly=0A= > for transmission via the corresdponding attachment circuit. Of course=0A= > this payload would be stored in some Tx queue associated with the=0A= > attachment circuit and controlled by the appropriate egress scheduler,=0A= > but IMO this does not constitue a PW jitter bufer, since the PW=0A= > interworking function does not exersize any control over these=0A= > queues.=0A= =0A= Well if its a technical argument you want, then here goes ...=0A= =0A= Even in pure TDM systems some jitter exist due to the longer time it=0A= takes if multiple passes of the FEC algorithm are needed. In that=0A= case there is a very small jitter buffer that can be set to the=0A= maximum needed for a worst case FEC, or set lower to decrease delay=0A= with the potential to make a greater number of errors uncorrectable.=0A= =0A= For IP, even if IP EF service is used and there is a very small amount=0A= of EF traffic, some jitter exists. For most systems there is some=0A= jitter crossing the fabric and internal jitter elsewhere. The egress=0A= buffer in most chips is very small but needed for that jitter. For=0A= TDM, the egress buffer can never run dry or there will be a timing=0A= slip.=0A= =0A= Consider what happens when packets arrive late in a system with only a=0A= non-zero egress buffer. For example, assume 1% of packets arrive=0A= about one packet time late (one other EF packet in queue somewhere on=0A= the path), 0.1% arrive two packets late. Note that this would be an=0A= extremely light EF load. Generally most packets arrive at least zero=0A= to one minus epsilon packet times late due to a lower priority packet=0A= partially transmited when the EF packet is moved to the front of the=0A= queue. If there is no egress buffer at all or considerably less than=0A= a packet time, lots of data would be dropped. If the egress buffer=0A= could hold just a few packets data drop would be very low.=0A= =0A= If a packet arrives late and there is no standing queue the egress=0A= runs dry, there is a timing slip. When the packet does arrive a=0A= little late the packet is sent, albiet late. Every packet to follow=0A= is now late by that amount of time (if the egress buffer has not=0A= overflowed on a later packet).=0A= =0A= At that point there is an standing queue in the egress buffer which=0A= acts as a jitter buffer. Most packets arrive early. A few arrive a=0A= little later but as long as the queue doesn't run dry again, the=0A= jitter is compensated for.=0A= =0A= If the egress buffer is large, then it will tend to grow to the worst=0A= case packet delay and keep a large standing queue. This is with no=0A= reorder and no drop. If the egress buffer is small (or configured to=0A= be small) then when a packet arrives very late followed by a set of=0A= packets in close succession, the buffer runs dry until that first late=0A= packet arrives. This packet is transmitted but very late. Subsequent=0A= packets arrive and some of them have to be dropped due to the limited=0A= queue capacity. This in effect puts a cap on the jitter buffer.=0A= =0A= With only an egress buffer there are multiple strategies for dealing=0A= with dropped packets.=0A= =0A= 1. Just ignore it and send the next one.=0A= 2. Put one packet time worth of all zeros in the queue.=0A= =0A= Now consider what happens with a dropped packet and a standing queue.=0A= The first strategy creates a hidden timing slip. The second strategy=0A= avoids the timing slip.=0A= =0A= So my argument is that the egress buffer is in effect the jitter=0A= buffer. When jitter occurs a standing buffer forms that reflects the=0A= lesser of the limit of the buffer size or the worst case jitter.=0A= There is always a jitter buffer. There always needs to be a jitter=0A= buffer of at least one large packet time, otherwise high loss of data=0A= will occur. There should be a jitter buffer that can be made larger=0A= so that jitter of multiple packet times doesn't turn in to loss.=0A= =0A= Therefore I assert that a jitter buffer is always present and is=0A= always needed because jitter is always non-zero. Therefore this=0A= statement is true:=0A= =0A= A small jitter buffer is always necessary and the jitter buffer is=0A= needed regardless of whether reordering is done.=0A= =0A= > In particular, these queues could not be used for re-ordering=0A= > misordered PW packets.=0A= =0A= That does not mean that they can't be used to compensate for jitter=0A= which is by definition what a jitter buffer is for.=0A= =0A= When reordering is done, the egress buffer is made small and a buffer=0A= preceding that is used which has some ability to reorder packets. In=0A= hardware a circular queue makes sense with packets place according to=0A= their sequence number. If you prescribe to the "just insert zeros"=0A= idea when a packet is dropped, then after moving a packet to the=0A= egress queue, zero the buffer or mark it as unoccupied and more the=0A= circular buffer a bit. If the packet that is later supposed to occupy=0A= that slot never arrives, then it is already zerod (or marked as=0A= missing in which case a packet of all zeros is put on the egress=0A= queue).=0A= =0A= So ... reording within a small jitter buffer is not hard to do.=0A= =0A= Reordering can be supported with a small jitter buffer but adding=0A= reordering to a small buffer may be ineffective. If reordering is due=0A= to a path change, then the buffer of a small number of packet times=0A= may yield no improvement. To be effective in that situation, the=0A= buffer may need to be larger. OTOH if moving EF traffic from one=0A= queue with no standing EF queue to another with no standing EF queue=0A= and the path change is just moving to another wave on the WDM,=0A= reordering with a small jitter buffer may help.=0A= =0A= > IMHO and FWIW this understanding matches RFC 3985 which mentions (in=0A= > Section 5.2.1.1 "Frame Ordering") that reodering as the strategy for=0A= > handling mis-ordered packets introduces additional delay (i.e.,=0A= > requires a ddicated jitter buffer), while the alternative strategy of=0A= > discarding mis-ordered packets does not introduce such additional=0A= > delay.=0A= =0A= You quoted the framework and not a TDM document. Nowhere in that text=0A= is there mention of a jitter buffer because that text is not specific=0A= to TDM.=0A= =0A= For packet traffic you have no idea if a prior packet is dropped or=0A= will arrive out of order and so when a drop occurs packets have to be=0A= held for a non-zero amount of time rather than transmitted as soon as=0A= they arrive. This applies to all cell or packet AC, such as FR, ATM,=0A= Ethernet, etc.=0A= =0A= You might want to look at section 5.2.2.1. Clock Recovery which does=0A= apply to TDM. It points to RFC3550 (RTP) which assumes a jitter=0A= buffer is always needed.=0A= =0A= > The editorial issue is about the entire sentence that contains the=0A= > above-mentioned fragment, i.e., "A small jitter buffer is always=0A= > necessary and the jitter buffer is needed regardless of whether=0A= > reordering is done" - to me this looks like an unnecessary repetition=0A= > if if it were techically correct.=0A= =0A= The second part of the sentence was to emphasis that the need for a=0A= jitter buffer is not contingent on implementation or reordering.=0A= Perhaps it would be more clear if the two points were separated. How=0A= about this=0A= =0A= OLD new sentence=0A= =0A= A small jitter buffer is always necessary and the jitter buffer=0A= is needed regardless of whether reordering is done.=0A= =0A= NEW new sentence=0A= =0A= A small jitter buffer is always necessary. A jitter buffer is=0A= needed regardless of whether reordering is done.=0A= =0A= > Hence I would like to suggest discrading the problematic sentence as=0A= > the simplest way to resolve both issues.=0A= =0A= I think the sentence provides an important clarification. I think the=0A= need to have this discussion proves that the clarification is needed.=0A= =0A= If we can agree on keeping this, I can submit the updated draft.=0A= =0A= > Hopefully these notes will e helpful.=0A= >=0A= > Regards,=0A= > Sasha=0A= =0A= Thanks again for the review and good comments.=0A= =0A= Regards,=0A= =0A= Curtis=0A= =0A= =0A= > ________________________________________=0A= > From: Curtis Villamizar =0A= > Sent: Tuesday, December 10, 2013 5:47 PM=0A= > To: Alexander Vainshtein=0A= > Cc: curtis@ipv6.occnc.com; curtis@occnc.com; kireeti@juniper.net; samante= @apple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov St= ein (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forward= ing: a minor comment=0A= >=0A= > In message =0A= > Alexander Vainshtein writes:=0A= > >=0A= > > Curtis,=0A= > >=0A= > > Lots of thanks for a prompt and very detailed response.=0A= > > May I suggest an alternative version of the following text fragment?=0A= > >=0A= > > =0A= > > > Identifying the position of any lost packets is important=0A= > > > for PW services which are attempting to reconstruct a bit stream= =0A= > > > which maintains bit timing, such as time division multiplexing (TD= M)=0A= > > > services. TDM and other PW services which require strict ordering= =0A= > > > also require that misordered packets be either dropped or reordere= d.=0A= >=0A= > Invalid XML - you didn't close this element. :-)=0A= >=0A= > > =0A= > >=0A= > > Identifying lost PW packets and exact amount of lost payload is=0A= > > critical for PW services which maintain bit timing, such as Time=0A= > > Division Multiplexing (TDM) services since these services MUST=0A= > > compensate lost payload on a bit-for-bit basis.=0A= > >=0A= > > With these services PW packets that have been received out of order= =0A= > > also MUST also be identified and may be either re-ordered or=0A= > > dropped. Reordering requires, in addition to sequence numbering, a= =0A= > > "de-jitter buffer" in the egress PE, and ability to reorder is=0A= > > limited by the depth of this buffer. The down side of maintaining a= =0A= > > de-jitter buffer is added end-to-end service delay.=0A= > >=0A= > > =0A= >=0A= > Accepted with a small change.=0A= >=0A= > After the words "down side"=0A= > s/de-jitter buffer/large jitter buffer/=0A= > Elsewhere=0A= > s/de-jitter buffer/jitter buffer/g=0A= > Then add the sentence.=0A= >=0A= > A small jitter buffer is always necessary and the jitter buffer=0A= > is needed regardless of whether reordering is done.=0A= >=0A= > This yields a slightly changed second paragraph.=0A= >=0A= > With these services PW packets that have been received out of order=0A= > also MUST also be identified and may be either re-ordered or=0A= > dropped. Reordering requires, in addition to sequence numbering, a=0A= > "jitter buffer" in the egress PE, and ability to reorder is limited=0A= > by the depth of this buffer. The down side of maintaining a large=0A= > jitter buffer is added end-to-end service delay. A small jitter=0A= > buffer is always necessary and the jitter buffer is needed=0A= > regardless of whether reordering is done.=0A= >=0A= > Is this wording OK with you?=0A= >=0A= > Curtis=0A= >=0A= > > Hopefully this will be useful.=0A= > >=0A= > >=0A= > > Regards,=0A= > > Sasha=0A= > >=0A= > > > -----Original Message-----=0A= > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]=0A= > > > Sent: Monday, November 25, 2013 8:30 PM=0A= > > > To: Alexander Vainshtein=0A= > > > Cc: curtis@occnc.com; kireeti@juniper.net; samante@apple.com;=0A= > > > agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stein=0A= > > > (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= > > > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-=0A= > > > forwarding: a minor comment=0A= > > >=0A= > > >=0A= > > > In message=0A= > > > > > om>=0A= > > > Alexander Vainshtein writes:=0A= > > > >=0A= > > > > Hi all,=0A= > > > >=0A= > > > > I would like to comment on the text in Section 2.1.8.1 "Pseudowire= =0A= > > > > Sequence Number" in draft-ietf-mpls-forwarding-03 - MPLS Forwarding= =0A= > > > > Compliance and Performance Requirements=0A= > > > > .=0A= > > > >=0A= > > > > This section states, in short, that the main drive for using the=0A= > > > > sequence number in the PW Control Word is handling of packet=0A= > > > > reordering events. TDM PWs are presented as a major example, with C= BR=0A= > > > > ATM services as another example.=0A= > > > >=0A= > > > > In fact, this statement is not accurate.=0A= > > >=0A= > > > Yes. You are correct in pointing this out as inaccurate by omitting= =0A= > > > the other important function of identifying drops for the purpose of= =0A= > > > recunstructing TDM bit streams.=0A= > > >=0A= > > > Andy brought up resequencing being a strong provider request.=0A= > > > Reordering is far more common than loss particularly for high priorit= y=0A= > > > services on provider networks and without resequencing reorder result= s=0A= > > > in PW loss in what could otherwise be lossless service.=0A= > > >=0A= > > > So we should get the base requirements right but still reflect this,= =0A= > > > but strictly as advice with no normative wording. We had used the=0A= > > > phrase "is beneficial" and will retain that.=0A= > > >=0A= > > > Andy brought up the topic. The incorrect wording in the existing=0A= > > > draft is my fault. This text went in fairly early with a lot of othe= r=0A= > > > changes and it appears that no one had since given it a careful enoug= h=0A= > > > read and review until you came along.=0A= > > >=0A= > > > > The main drive for mandating the use of sequence number in TM PWs i= s=0A= > > > > the need to detect and count lost packets because the egress PE MUS= T=0A= > > > > compensate the lost payload bit for bit.=0A= > > > >=0A= > > > > Ability to compensate reordering of PW packets at egress is a side= =0A= > > > > effect of (a) sequence number usage and (b) usage of the de-jitter= =0A= > > > > buffer in the egress PW. It is not mandatory and in any case is=0A= > > > > limited by the depth of the de-jitter buffer: re-ordered packets th= at=0A= > > > > cannot be accommodated within this buffer are treated as lost.=0A= > > > >=0A= > > > > Additional details can be found, e.g., in section 6.2.2 of RFC=0A= > > > > 4553. Ability to re-order=0A= > > > > mis-ordered PW packets is defined there as OPTIONAL, while replacem= ent=0A= > > > > of the payload of lost PW packets is defined as MANDATORY.=0A= > > >=0A= > > > The change below at the top of the section more accurately reflects= =0A= > > > requirements in the RFCs but still states that resequencing can be=0A= > > > beneficial. The comments about EPD and PPD are dropped and therefore= =0A= > > > also the informative reference.=0A= > > >=0A= > > > Context:=0A= > > >=0A= > > > 2.1.8.1. Pseudowire Sequence Number=0A= > > >=0A= > > > OLD=0A= > > >=0A= > > > Pseudowire (PW) sequence number support is most important for PW= =0A= > > > payload types with a high expectation of in-order delivery.=0A= > > > Resequencing support, rather than dropping at egress on out of ord= er=0A= > > > arrival, is most important for PW payload types with a high=0A= > > > expectation of lossless delivery. For example, TDM payloads requi= re=0A= > > > sequence number support and require resequencing support. The sam= e=0A= > > > is true of ATM CBR service. ATM VBR or ABR may have somewhat rela= xed=0A= > > > requirements, but generally require ATM Early Packet Discard (EPD)= or=0A= > > > ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequen= ce=0A= > > > number support and resequencing support are beneficial to PW packe= t=0A= > > > oriented payloads such as FR and Ethernet, they are highly desirab= le=0A= > > > but not as strongly required.=0A= > > >=0A= > > > NEW=0A= > > >=0A= > > > Pseudowire (PW) sequence number support is most important for PW= =0A= > > > payload types with a high expectation of lossless and/or in-order= =0A= > > > delivery. Identifying the position of any lost packets is importa= nt=0A= > > > for PW services which are attempting to reconstruct a bit stream= =0A= > > > which maintains bit timing, such as time division multiplexing (TD= M)=0A= > > > services. TDM and other PW services which require strict ordering= =0A= > > > also require that misordered packets be either dropped or reordere= d.=0A= > > >=0A= > > > PW services which are not timing critical bit streams in nature ar= e=0A= > > > cell oriented or frame oriented. Though resequencing support is= =0A= > > > beneficial to PW cell and frame oriented payloads such as ATM, FR = and=0A= > > > Ethernet, they are highly desirable but not required.=0A= > > >=0A= > > > NEW (end of subsection after list of possible reording causes)=0A= > > >=0A= > > > In provider networks which use multipath techniques and which may= =0A= > > > occassionally rebalance traffic or which may change PW paths=0A= > > > occasionally for other reasons, reordering may be far more common= =0A= > > > than loss. Where reordering is more common than loss, resequencin= g=0A= > > > packets is beneficial, rather than dropping packets at egress when= =0A= > > > out of order arrival occus. Resequencing is most important for PW= =0A= > > > payload types with a high expectation of lossless delivery since i= n=0A= > > > such cases out of order delivery within the network results in PW= =0A= > > > loss.=0A= > > >=0A= > > > The final paragraph sums up the motivation for highlighting=0A= > > > resequencing as beneficial and desirable. It does so without any=0A= > > > normative wording.=0A= > > >=0A= > > > > Hopefully these notes will be useful.=0A= > > > >=0A= > > > > Regards,=0A= > > > > Sasha=0A= > > >=0A= > > > These notes are very useful. Thank you.=0A= > > >=0A= > > > Please let us know if you (and the WG) are OK with the rewording=0A= > > > proposed above.=0A= > > >=0A= > > > Curtis=0A= =0A= From Alexander.Vainshtein@ecitele.com Fri Dec 13 22:28:49 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 1C86B1AE4E7; Fri, 13 Dec 2013 22:28:49 -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 HH07WchPCwGO; Fri, 13 Dec 2013 22:28:44 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0011.outbound.protection.outlook.com [213.199.154.11]) by ietfa.amsl.com (Postfix) with ESMTP id BB2E01AE4F0; Fri, 13 Dec 2013 22:28:42 -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.842.7; Sat, 14 Dec 2013 06:28:33 +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.0842.003; Sat, 14 Dec 2013 06:28:33 +0000 From: Alexander Vainshtein To: "curtis@ipv6.occnc.com" Thread-Topic: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment Thread-Index: AQHO+JWQSq0tCZZscUehMpHq+OAdtZpTOhu1 Date: Sat, 14 Dec 2013 06:28:33 +0000 Message-ID: References: <0e9fa8a68b14411983975b85d76678ca@AM3PR03MB532.eurprd03.prod.outlook.com> In-Reply-To: <0e9fa8a68b14411983975b85d76678ca@AM3PR03MB532.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.203] x-forefront-prvs: 00603B7EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(43784003)(199002)(189002)(53754006)(51704005)(52604005)(377454003)(13464003)(74316001)(31966008)(83322001)(19580395003)(19580405001)(54316002)(77982001)(85852003)(71446004)(85306002)(33646001)(50986001)(47976001)(47736001)(49866001)(4396001)(81816001)(59766001)(80976001)(65816001)(46102001)(81686001)(74662001)(76576001)(74706001)(76796001)(76786001)(83072002)(53806001)(69226001)(87266001)(74876001)(2656002)(51856001)(81542001)(81342001)(87936001)(74502001)(56776001)(66066001)(80022001)(63696002)(74366001)(76482001)(54356001)(47446002)(79102001)(90146001)(56816005)(427584002)(24736002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB531; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:5.153.9.203; 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: "samante@apple.com" , "kireeti@juniper.net" , "mpls@ietf.org" , "curtis@occnc.com" , "pwe3 \(pwe3@ietf.org\)" Subject: Re: [mpls] [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Dec 2013 06:28:49 -0000 Re-sending due to an unspecified issue with my mail server... =0A= ________________________________________=0A= From: Alexander Vainshtein=0A= Sent: Saturday, December 14, 2013 8:27 AM=0A= To: curtis@ipv6.occnc.com=0A= Cc: curtis@occnc.com; kireeti@juniper.net; samante@apple.com; agmalis@gmail= .com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stein (yaakov_s@rad.com); p= we3 (pwe3@ietf.org)=0A= Subject: RE: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwardin= g: a minor comment=0A= =0A= Curtis,=0A= Lots of thanks for a prompt and most encouraging response.=0A= =0A= I believe that the last proposed text fully addreses both my original comme= nt and the misunderstanding that has been encountered at some stage in this= email thread.=0A= =0A= Regards,=0A= Sassha=0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Friday, December 13, 2013 9:17 PM=0A= To: Alexander Vainshtein=0A= Cc: curtis@ipv6.occnc.com; curtis@occnc.com; kireeti@juniper.net; samante@a= pple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stei= n (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwardin= g: a minor comment=0A= =0A= Sasha,=0A= =0A= Thanks for pointing out the lack of clarity regarding the context of=0A= the statement we were discussing. These are the first three paragraphs=0A= (originally one) of "2.1.8.1. Pseudowire Sequence Number" that we've=0A= been discussing=0A= =0A= Original (draft-ietf-mpls-forwarding-03, short but inaccurate)=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of in-order delivery.=0A= Resequencing support, rather than dropping at egress on out of order=0A= arrival, is most important for PW payload types with a high=0A= expectation of lossless delivery. For example, TDM payloads require=0A= sequence number support and require resequencing support. The same=0A= is true of ATM CBR service. ATM VBR or ABR may have somewhat relaxed=0A= requirements, but generally require ATM Early Packet Discard (EPD) or=0A= ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequence=0A= number support and resequencing support are beneficial to PW packet=0A= oriented payloads such as FR and Ethernet, they are highly desirable=0A= but not as strongly required.=0A= =0A= First change=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying the position of any lost packets is important=0A= for PW services which are attempting to reconstruct a bit stream=0A= which maintains bit timing, such as time division multiplexing (TDM)=0A= services. TDM and other PW services which require strict ordering=0A= also require that misordered packets be either dropped or reordered.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support is=0A= beneficial to PW cell and frame oriented payloads such as ATM, FR and=0A= Ethernet, they are highly desirable but not required.=0A= =0A= Suggested new para (Sasha) - part of second para rewritten=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying lost PW packets and exact amount of lost=0A= payload is critical for PW services which maintain bit timing, such=0A= as Time Division Multiplexing (TDM) services since these services=0A= MUST compensate lost payload on a bit-for-bit basis.=0A= =0A= With these services PW packets that have been received out of order=0A= also MUST also be identified and may be either re-ordered or=0A= dropped. Reordering requires, in addition to sequence numbering, a=0A= "de-jitter buffer" in the egress PE, and ability to reorder is=0A= limited by the depth of this buffer. The down side of maintaining a=0A= de-jitter buffer is added end-to-end service delay.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support is=0A= beneficial to PW cell and frame oriented payloads such as ATM, FR and=0A= Ethernet, they are highly desirable but not required.=0A= =0A= Suggested change to above (Curtis) - minor plus add last sentence=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying lost PW packets and exact amount of lost=0A= payload is critical for PW services which maintain bit timing, such=0A= as Time Division Multiplexing (TDM) services since these services=0A= MUST compensate lost payload on a bit-for-bit basis.=0A= =0A= With these services PW packets that have been received out of order=0A= also MUST also be identified and may be either re-ordered or=0A= dropped. Reordering requires, in addition to sequence numbering, a=0A= "jitter buffer" in the egress PE, and ability to reorder is limited=0A= by the depth of this buffer. The down side of maintaining a large=0A= jitter buffer is added end-to-end service delay. A small jitter=0A= buffer is always necessary and the jitter buffer is needed=0A= regardless of whether reordering is done.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support is=0A= beneficial to PW cell and frame oriented payloads such as ATM, FR=0A= and Ethernet, they are highly desirable but not required.=0A= =0A= Reorder paragraphs and edit for clarity of context=0A= =0A= Pseudowire (PW) sequence number support is most important for PW=0A= payload types with a high expectation of lossless and/or in-order=0A= delivery. Identifying lost PW packets and exact amount of lost=0A= payload is critical for PW services which maintain bit timing, such=0A= as Time Division Multiplexing (TDM) services since these services=0A= MUST compensate lost payload on a bit-for-bit basis.=0A= =0A= With PW services which maintain bit timing, packets that have been=0A= received out of order also MUST be identified and may be either=0A= re-ordered or dropped. Reordering requires, in addition to=0A= sequence numbering, a "reorder buffer" in the egress PE, and ability=0A= to reorder is limited by the depth of this buffer. The down side of=0A= maintaining a large reorder buffer is added end-to-end service=0A= delay.=0A= =0A= For PW services which maintain bit timing or any other service=0A= where jitter must be bounded, a jitter buffer is always necessary.=0A= The jitter buffer is needed regardless of whether reordering is=0A= done. In order to be effective, a reorder buffer must often be=0A= larger than a jitter buffer needs to be creating a tradeoff between=0A= reducing loss and minimizing delay.=0A= =0A= PW services which are not timing critical bit streams in nature are=0A= cell oriented or frame oriented. Though resequencing support may=0A= be beneficial to PW cell and frame oriented payloads such as ATM,=0A= FR and Ethernet, this support is desirable but not required.=0A= Requirements to hamdle out of order packets at all vary among=0A= services and deployments. For example for Ethernet PW, occasional=0A= (very rare) reordering is usually acceptable. If the Ethernet PW=0A= is carrying MPLS-TP, then this reordering may be acceptable.=0A= =0A= Reducing jitter is best done by an end-system, given that the=0A= tradeoff of loss vs delay varies among services. For example with=0A= interactive real time services low delay is preferred, while with=0A= non-interactive (one way) real time services low loss is preferred.=0A= The same end-site may be receiving both types of traffic.=0A= Regardless of this, bounded jitter is sometimes a requiremnet for=0A= specific deployments.=0A= =0A= In the prior iteration a paragraph began with "With these services"=0A= following the prior paragraph discussing "PW services which maintain=0A= bit timing, such as Time Division Multiplexing (TDM) services" which=0A= did not clearly carry over the context.=0A= =0A= At this point, each paragraph clearly indicates its context, either=0A= bit timing, not bit timing, or all PW. It also makes a distinction=0A= between a reorder buffer and a jitter buffer.=0A= =0A= This is a more thorough treatment of the tradeoffs of using PW=0A= sequence in supporting de-jitter and reordering in PW services than=0A= what was originally in the document (but given that it wasn't correct=0A= some change was needed).=0A= =0A= Curtis=0A= =0A= =0A= ps - Needed to top post a summary since your repeated top posting was=0A= obscuring the context of the (longish) conversation thread. You've=0A= probably seen something like this before:=0A= =0A= You're welcome.=0A= I get it. Thanks.=0A= Because it is the default in most pee-cee mailers.=0A= Why do people do it so often then?=0A= Because it loses context and reverses the order of the discussion.=0A= Why?=0A= Yes.=0A= Is top posting a bad practice?=0A= =0A= =0A= In message <4946c79f4554497d84cd676684739124@AM3PR03MB532.eurprd03.prod.out= look.com>=0A= Alexander Vainshtein writes:=0A= =0A= Curtis,=0A= Lots of hanks for a long and detailed explanation.=0A= =0A= It appears that your original comment about the need of jitter buffer=0A= refered to TDM (or TDM-like) PWs (bit-stream PWs in the Architecture=0A= RFC). If this was indeed the case, there is nothing to argue about,=0A= because I agree completely that jitter buffer is absolutely necessary=0A= for these.=0A= =0A= My impression from reading the original text has been that it referred=0A= to ALL kinds of PWs (bit-stream, celland packet) alike. Apparently=0A= this has been my mis-interptetation; if this is indeed so, then maybe=0A= some clarification (placing the jiter buffer discussion in the proper=0A= context) would hopefully help.=0A= =0A= Regards,=0A= Sasha=0A= ________________________________________=0A= From: Curtis Villamizar =0A= Sent: Thursday, December 12, 2013 6:53 AM=0A= To: Alexander Vainshtein=0A= Cc: curtis@occnc.com; curtis@ipv6.occnc.com; kireeti@juniper.net; samante@a= pple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stei= n (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwardin= g: a minor comment=0A= =0A= In message <774d74926b684ffba7f4f89ace758547@AM3PR03MB532.eurprd03.prod.out= look.com>=0A= Alexander Vainshtein writes:=0A= =0A= > Curtis,=0A= > Lots of thanks for sending out the new text.=0A= >=0A= > I still have a couple of issues with this version of the text: one=0A= > technical and one editorial.=0A= >=0A= > The technical issue is about the fragment "A small jitter buffer is=0A= > always necessary".=0A= >=0A= > I am not sure this is correct, since I am aware of several PW=0A= > implementations that pass the payload of a received PW packet directly=0A= > for transmission via the corresdponding attachment circuit. Of course=0A= > this payload would be stored in some Tx queue associated with the=0A= > attachment circuit and controlled by the appropriate egress scheduler,=0A= > but IMO this does not constitue a PW jitter bufer, since the PW=0A= > interworking function does not exersize any control over these=0A= > queues.=0A= =0A= Well if its a technical argument you want, then here goes ...=0A= =0A= Even in pure TDM systems some jitter exist due to the longer time it=0A= takes if multiple passes of the FEC algorithm are needed. In that=0A= case there is a very small jitter buffer that can be set to the=0A= maximum needed for a worst case FEC, or set lower to decrease delay=0A= with the potential to make a greater number of errors uncorrectable.=0A= =0A= For IP, even if IP EF service is used and there is a very small amount=0A= of EF traffic, some jitter exists. For most systems there is some=0A= jitter crossing the fabric and internal jitter elsewhere. The egress=0A= buffer in most chips is very small but needed for that jitter. For=0A= TDM, the egress buffer can never run dry or there will be a timing=0A= slip.=0A= =0A= Consider what happens when packets arrive late in a system with only a=0A= non-zero egress buffer. For example, assume 1% of packets arrive=0A= about one packet time late (one other EF packet in queue somewhere on=0A= the path), 0.1% arrive two packets late. Note that this would be an=0A= extremely light EF load. Generally most packets arrive at least zero=0A= to one minus epsilon packet times late due to a lower priority packet=0A= partially transmited when the EF packet is moved to the front of the=0A= queue. If there is no egress buffer at all or considerably less than=0A= a packet time, lots of data would be dropped. If the egress buffer=0A= could hold just a few packets data drop would be very low.=0A= =0A= If a packet arrives late and there is no standing queue the egress=0A= runs dry, there is a timing slip. When the packet does arrive a=0A= little late the packet is sent, albiet late. Every packet to follow=0A= is now late by that amount of time (if the egress buffer has not=0A= overflowed on a later packet).=0A= =0A= At that point there is an standing queue in the egress buffer which=0A= acts as a jitter buffer. Most packets arrive early. A few arrive a=0A= little later but as long as the queue doesn't run dry again, the=0A= jitter is compensated for.=0A= =0A= If the egress buffer is large, then it will tend to grow to the worst=0A= case packet delay and keep a large standing queue. This is with no=0A= reorder and no drop. If the egress buffer is small (or configured to=0A= be small) then when a packet arrives very late followed by a set of=0A= packets in close succession, the buffer runs dry until that first late=0A= packet arrives. This packet is transmitted but very late. Subsequent=0A= packets arrive and some of them have to be dropped due to the limited=0A= queue capacity. This in effect puts a cap on the jitter buffer.=0A= =0A= With only an egress buffer there are multiple strategies for dealing=0A= with dropped packets.=0A= =0A= 1. Just ignore it and send the next one.=0A= 2. Put one packet time worth of all zeros in the queue.=0A= =0A= Now consider what happens with a dropped packet and a standing queue.=0A= The first strategy creates a hidden timing slip. The second strategy=0A= avoids the timing slip.=0A= =0A= So my argument is that the egress buffer is in effect the jitter=0A= buffer. When jitter occurs a standing buffer forms that reflects the=0A= lesser of the limit of the buffer size or the worst case jitter.=0A= There is always a jitter buffer. There always needs to be a jitter=0A= buffer of at least one large packet time, otherwise high loss of data=0A= will occur. There should be a jitter buffer that can be made larger=0A= so that jitter of multiple packet times doesn't turn in to loss.=0A= =0A= Therefore I assert that a jitter buffer is always present and is=0A= always needed because jitter is always non-zero. Therefore this=0A= statement is true:=0A= =0A= A small jitter buffer is always necessary and the jitter buffer is=0A= needed regardless of whether reordering is done.=0A= =0A= > In particular, these queues could not be used for re-ordering=0A= > misordered PW packets.=0A= =0A= That does not mean that they can't be used to compensate for jitter=0A= which is by definition what a jitter buffer is for.=0A= =0A= When reordering is done, the egress buffer is made small and a buffer=0A= preceding that is used which has some ability to reorder packets. In=0A= hardware a circular queue makes sense with packets place according to=0A= their sequence number. If you prescribe to the "just insert zeros"=0A= idea when a packet is dropped, then after moving a packet to the=0A= egress queue, zero the buffer or mark it as unoccupied and more the=0A= circular buffer a bit. If the packet that is later supposed to occupy=0A= that slot never arrives, then it is already zerod (or marked as=0A= missing in which case a packet of all zeros is put on the egress=0A= queue).=0A= =0A= So ... reording within a small jitter buffer is not hard to do.=0A= =0A= Reordering can be supported with a small jitter buffer but adding=0A= reordering to a small buffer may be ineffective. If reordering is due=0A= to a path change, then the buffer of a small number of packet times=0A= may yield no improvement. To be effective in that situation, the=0A= buffer may need to be larger. OTOH if moving EF traffic from one=0A= queue with no standing EF queue to another with no standing EF queue=0A= and the path change is just moving to another wave on the WDM,=0A= reordering with a small jitter buffer may help.=0A= =0A= > IMHO and FWIW this understanding matches RFC 3985 which mentions (in=0A= > Section 5.2.1.1 "Frame Ordering") that reodering as the strategy for=0A= > handling mis-ordered packets introduces additional delay (i.e.,=0A= > requires a ddicated jitter buffer), while the alternative strategy of=0A= > discarding mis-ordered packets does not introduce such additional=0A= > delay.=0A= =0A= You quoted the framework and not a TDM document. Nowhere in that text=0A= is there mention of a jitter buffer because that text is not specific=0A= to TDM.=0A= =0A= For packet traffic you have no idea if a prior packet is dropped or=0A= will arrive out of order and so when a drop occurs packets have to be=0A= held for a non-zero amount of time rather than transmitted as soon as=0A= they arrive. This applies to all cell or packet AC, such as FR, ATM,=0A= Ethernet, etc.=0A= =0A= You might want to look at section 5.2.2.1. Clock Recovery which does=0A= apply to TDM. It points to RFC3550 (RTP) which assumes a jitter=0A= buffer is always needed.=0A= =0A= > The editorial issue is about the entire sentence that contains the=0A= > above-mentioned fragment, i.e., "A small jitter buffer is always=0A= > necessary and the jitter buffer is needed regardless of whether=0A= > reordering is done" - to me this looks like an unnecessary repetition=0A= > if if it were techically correct.=0A= =0A= The second part of the sentence was to emphasis that the need for a=0A= jitter buffer is not contingent on implementation or reordering.=0A= Perhaps it would be more clear if the two points were separated. How=0A= about this=0A= =0A= OLD new sentence=0A= =0A= A small jitter buffer is always necessary and the jitter buffer=0A= is needed regardless of whether reordering is done.=0A= =0A= NEW new sentence=0A= =0A= A small jitter buffer is always necessary. A jitter buffer is=0A= needed regardless of whether reordering is done.=0A= =0A= > Hence I would like to suggest discrading the problematic sentence as=0A= > the simplest way to resolve both issues.=0A= =0A= I think the sentence provides an important clarification. I think the=0A= need to have this discussion proves that the clarification is needed.=0A= =0A= If we can agree on keeping this, I can submit the updated draft.=0A= =0A= > Hopefully these notes will e helpful.=0A= >=0A= > Regards,=0A= > Sasha=0A= =0A= Thanks again for the review and good comments.=0A= =0A= Regards,=0A= =0A= Curtis=0A= =0A= =0A= > ________________________________________=0A= > From: Curtis Villamizar =0A= > Sent: Tuesday, December 10, 2013 5:47 PM=0A= > To: Alexander Vainshtein=0A= > Cc: curtis@ipv6.occnc.com; curtis@occnc.com; kireeti@juniper.net; samante= @apple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov St= ein (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forward= ing: a minor comment=0A= >=0A= > In message =0A= > Alexander Vainshtein writes:=0A= > >=0A= > > Curtis,=0A= > >=0A= > > Lots of thanks for a prompt and very detailed response.=0A= > > May I suggest an alternative version of the following text fragment?=0A= > >=0A= > > =0A= > > > Identifying the position of any lost packets is important=0A= > > > for PW services which are attempting to reconstruct a bit stream= =0A= > > > which maintains bit timing, such as time division multiplexing (TD= M)=0A= > > > services. TDM and other PW services which require strict ordering= =0A= > > > also require that misordered packets be either dropped or reordere= d.=0A= >=0A= > Invalid XML - you didn't close this element. :-)=0A= >=0A= > > =0A= > >=0A= > > Identifying lost PW packets and exact amount of lost payload is=0A= > > critical for PW services which maintain bit timing, such as Time=0A= > > Division Multiplexing (TDM) services since these services MUST=0A= > > compensate lost payload on a bit-for-bit basis.=0A= > >=0A= > > With these services PW packets that have been received out of order= =0A= > > also MUST also be identified and may be either re-ordered or=0A= > > dropped. Reordering requires, in addition to sequence numbering, a= =0A= > > "de-jitter buffer" in the egress PE, and ability to reorder is=0A= > > limited by the depth of this buffer. The down side of maintaining a= =0A= > > de-jitter buffer is added end-to-end service delay.=0A= > >=0A= > > =0A= >=0A= > Accepted with a small change.=0A= >=0A= > After the words "down side"=0A= > s/de-jitter buffer/large jitter buffer/=0A= > Elsewhere=0A= > s/de-jitter buffer/jitter buffer/g=0A= > Then add the sentence.=0A= >=0A= > A small jitter buffer is always necessary and the jitter buffer=0A= > is needed regardless of whether reordering is done.=0A= >=0A= > This yields a slightly changed second paragraph.=0A= >=0A= > With these services PW packets that have been received out of order=0A= > also MUST also be identified and may be either re-ordered or=0A= > dropped. Reordering requires, in addition to sequence numbering, a=0A= > "jitter buffer" in the egress PE, and ability to reorder is limited=0A= > by the depth of this buffer. The down side of maintaining a large=0A= > jitter buffer is added end-to-end service delay. A small jitter=0A= > buffer is always necessary and the jitter buffer is needed=0A= > regardless of whether reordering is done.=0A= >=0A= > Is this wording OK with you?=0A= >=0A= > Curtis=0A= >=0A= > > Hopefully this will be useful.=0A= > >=0A= > >=0A= > > Regards,=0A= > > Sasha=0A= > >=0A= > > > -----Original Message-----=0A= > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]=0A= > > > Sent: Monday, November 25, 2013 8:30 PM=0A= > > > To: Alexander Vainshtein=0A= > > > Cc: curtis@occnc.com; kireeti@juniper.net; samante@apple.com;=0A= > > > agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stein=0A= > > > (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)=0A= > > > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-=0A= > > > forwarding: a minor comment=0A= > > >=0A= > > >=0A= > > > In message=0A= > > > > > om>=0A= > > > Alexander Vainshtein writes:=0A= > > > >=0A= > > > > Hi all,=0A= > > > >=0A= > > > > I would like to comment on the text in Section 2.1.8.1 "Pseudowire= =0A= > > > > Sequence Number" in draft-ietf-mpls-forwarding-03 - MPLS Forwarding= =0A= > > > > Compliance and Performance Requirements=0A= > > > > .=0A= > > > >=0A= > > > > This section states, in short, that the main drive for using the=0A= > > > > sequence number in the PW Control Word is handling of packet=0A= > > > > reordering events. TDM PWs are presented as a major example, with C= BR=0A= > > > > ATM services as another example.=0A= > > > >=0A= > > > > In fact, this statement is not accurate.=0A= > > >=0A= > > > Yes. You are correct in pointing this out as inaccurate by omitting= =0A= > > > the other important function of identifying drops for the purpose of= =0A= > > > recunstructing TDM bit streams.=0A= > > >=0A= > > > Andy brought up resequencing being a strong provider request.=0A= > > > Reordering is far more common than loss particularly for high priorit= y=0A= > > > services on provider networks and without resequencing reorder result= s=0A= > > > in PW loss in what could otherwise be lossless service.=0A= > > >=0A= > > > So we should get the base requirements right but still reflect this,= =0A= > > > but strictly as advice with no normative wording. We had used the=0A= > > > phrase "is beneficial" and will retain that.=0A= > > >=0A= > > > Andy brought up the topic. The incorrect wording in the existing=0A= > > > draft is my fault. This text went in fairly early with a lot of othe= r=0A= > > > changes and it appears that no one had since given it a careful enoug= h=0A= > > > read and review until you came along.=0A= > > >=0A= > > > > The main drive for mandating the use of sequence number in TM PWs i= s=0A= > > > > the need to detect and count lost packets because the egress PE MUS= T=0A= > > > > compensate the lost payload bit for bit.=0A= > > > >=0A= > > > > Ability to compensate reordering of PW packets at egress is a side= =0A= > > > > effect of (a) sequence number usage and (b) usage of the de-jitter= =0A= > > > > buffer in the egress PW. It is not mandatory and in any case is=0A= > > > > limited by the depth of the de-jitter buffer: re-ordered packets th= at=0A= > > > > cannot be accommodated within this buffer are treated as lost.=0A= > > > >=0A= > > > > Additional details can be found, e.g., in section 6.2.2 of RFC=0A= > > > > 4553. Ability to re-order=0A= > > > > mis-ordered PW packets is defined there as OPTIONAL, while replacem= ent=0A= > > > > of the payload of lost PW packets is defined as MANDATORY.=0A= > > >=0A= > > > The change below at the top of the section more accurately reflects= =0A= > > > requirements in the RFCs but still states that resequencing can be=0A= > > > beneficial. The comments about EPD and PPD are dropped and therefore= =0A= > > > also the informative reference.=0A= > > >=0A= > > > Context:=0A= > > >=0A= > > > 2.1.8.1. Pseudowire Sequence Number=0A= > > >=0A= > > > OLD=0A= > > >=0A= > > > Pseudowire (PW) sequence number support is most important for PW= =0A= > > > payload types with a high expectation of in-order delivery.=0A= > > > Resequencing support, rather than dropping at egress on out of ord= er=0A= > > > arrival, is most important for PW payload types with a high=0A= > > > expectation of lossless delivery. For example, TDM payloads requi= re=0A= > > > sequence number support and require resequencing support. The sam= e=0A= > > > is true of ATM CBR service. ATM VBR or ABR may have somewhat rela= xed=0A= > > > requirements, but generally require ATM Early Packet Discard (EPD)= or=0A= > > > ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequen= ce=0A= > > > number support and resequencing support are beneficial to PW packe= t=0A= > > > oriented payloads such as FR and Ethernet, they are highly desirab= le=0A= > > > but not as strongly required.=0A= > > >=0A= > > > NEW=0A= > > >=0A= > > > Pseudowire (PW) sequence number support is most important for PW= =0A= > > > payload types with a high expectation of lossless and/or in-order= =0A= > > > delivery. Identifying the position of any lost packets is importa= nt=0A= > > > for PW services which are attempting to reconstruct a bit stream= =0A= > > > which maintains bit timing, such as time division multiplexing (TD= M)=0A= > > > services. TDM and other PW services which require strict ordering= =0A= > > > also require that misordered packets be either dropped or reordere= d.=0A= > > >=0A= > > > PW services which are not timing critical bit streams in nature ar= e=0A= > > > cell oriented or frame oriented. Though resequencing support is= =0A= > > > beneficial to PW cell and frame oriented payloads such as ATM, FR = and=0A= > > > Ethernet, they are highly desirable but not required.=0A= > > >=0A= > > > NEW (end of subsection after list of possible reording causes)=0A= > > >=0A= > > > In provider networks which use multipath techniques and which may= =0A= > > > occassionally rebalance traffic or which may change PW paths=0A= > > > occasionally for other reasons, reordering may be far more common= =0A= > > > than loss. Where reordering is more common than loss, resequencin= g=0A= > > > packets is beneficial, rather than dropping packets at egress when= =0A= > > > out of order arrival occus. Resequencing is most important for PW= =0A= > > > payload types with a high expectation of lossless delivery since i= n=0A= > > > such cases out of order delivery within the network results in PW= =0A= > > > loss.=0A= > > >=0A= > > > The final paragraph sums up the motivation for highlighting=0A= > > > resequencing as beneficial and desirable. It does so without any=0A= > > > normative wording.=0A= > > >=0A= > > > > Hopefully these notes will be useful.=0A= > > > >=0A= > > > > Regards,=0A= > > > > Sasha=0A= > > >=0A= > > > These notes are very useful. Thank you.=0A= > > >=0A= > > > Please let us know if you (and the WG) are OK with the rewording=0A= > > > proposed above.=0A= > > >=0A= > > > Curtis=0A= =0A= From internet-drafts@ietf.org Sat Dec 14 19:52:04 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 2AB591AE054; Sat, 14 Dec 2013 19:52:04 -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 I-pmadQC1ccH; Sat, 14 Dec 2013 19:52:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 597931AE03F; Sat, 14 Dec 2013 19:52: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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131215035201.9149.29176.idtracker@ietfa.amsl.com> Date: Sat, 14 Dec 2013 19:52:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-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, 15 Dec 2013 03:52: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-TP Operations, Administration, and Management (OAM)= Identifiers Management Information Base (MIB) Author(s) : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-mpls-tp-oam-id-mib-04.txt Pages : 28 Date : 2013-12-14 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes Operations, Administration, and Management (OAM) identifiers related managed objects for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-oam-id-mib-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 huaimo.chen@huawei.com Sun Dec 15 18:01:15 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 200601AE272 for ; Sun, 15 Dec 2013 18:01: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 7A0MdEwoEfM6 for ; Sun, 15 Dec 2013 18:01:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9CDD1AE224 for ; Sun, 15 Dec 2013 18:01:11 -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 AZA78414; Mon, 16 Dec 2013 02:01:09 +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, 16 Dec 2013 02:00:45 +0000 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Dec 2013 02:01:06 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.165]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Sun, 15 Dec 2013 18:01:00 -0800 From: Huaimo Chen To: "Nobo Akiya (nobo)" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: Comment on draft-chen-mpls-p2mp-ingress-protection Thread-Index: Ac7bieAe3j4zI+A+Rcq0NrmUMXL15gedQ3YA Date: Mon, 16 Dec 2013 02:00:59 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C200A7@sjceml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Comment 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: Mon, 16 Dec 2013 02:01:15 -0000 Hi Nobo, Thanks for your comments! See my answers/explanations inline below. Best Regards, Huaimo -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Nob= o Akiya (nobo) Sent: Thursday, November 07, 2013 2:51 AM To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protection Hi Authors, I didn't get a chance to comment on your draft at the WG session today, so = sending to the list. My concern is similar to what Greg Mirsky stated. Simp= ly running 2 independent BFD sessions (as described in the slides) will hav= e issues. Huaimo: In normal operations, source CE sends the traffic to the primary in= gress, which imports the traffic into the primary LSP. It does not send the= traffic to the backup ingress.=20 When the primary ingress fails, the source CE will detect the failure of th= e primary ingress through the BFD between CE and the primary ingress and sw= itches the traffic to the backup ingress. The backup ingress will also dete= ct the failure of the primary ingress through the BFD between the backup in= gress and the primary ingress, and put the traffic from the source CE into = the backup LSP to the next hops of the primary ingress, where the traffic i= s merged into the primary LSP. When the link between the backup ingress and the primary ingress fails, the= source CE will continue to send the traffic to the primary ingress, and do= es not send the traffic to the backup ingress. The traffic will be delivere= d to the destinations via the primary LSP.=20 It seems that it works as expected.=20 Can you give more details about "Simply running 2 independent BFD sessions = (as described in the slides) will have issues."? > 3. Ingress Failure Detection >=20 > Exactly how the failure of the ingress (e.g. R1 in Figure 1) is > detected is out of scope for this document. I believe, at least, definition of the "failure" should be defined in the d= raft. Without it, it can be interpreted by readers as complete node outage,= outage of all involved links, outage of just primary-backup link, or even = something else. And without defining what the "failure" is, it's difficult = to figure out the right techniques to detect the failure. And that can easi= ly result in deviating detection implementations for described solution to = not kick off in expected manner. Huaimo: The primary ingress node failure in this draft is similar to the no= de failure in RFC 4090. -Nobo _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From rcallon@juniper.net Sun Dec 15 18:09:41 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 DCBBA1AE274 for ; Sun, 15 Dec 2013 18:09: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, 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 OVZ8N7CVojp4 for ; Sun, 15 Dec 2013 18:09:39 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id CB1371ADFD1 for ; Sun, 15 Dec 2013 18:09:38 -0800 (PST) Received: from mail44-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE026.bigfish.com (10.3.207.148) with Microsoft SMTP Server id 14.1.225.22; Mon, 16 Dec 2013 02:09:38 +0000 Received: from mail44-am1 (localhost [127.0.0.1]) by mail44-am1-R.bigfish.com (Postfix) with ESMTP id C4415360253; Mon, 16 Dec 2013 02:09:37 +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: -2 X-BigFish: VPS-2(zz1431Jc85fh1454I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz18c673hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail44-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)(199002)(52044002)(51694002)(189002)(164054003)(76576001)(83322001)(85306002)(85852003)(83072002)(31966008)(66066001)(33646001)(47736001)(4396001)(19580395003)(80976001)(74502001)(74316001)(50986001)(76482001)(15202345003)(53806001)(49866001)(46102001)(81686001)(79102001)(74876001)(51856001)(77982001)(54316002)(81816001)(56776001)(69226001)(81542001)(59766001)(76786001)(87266001)(65816001)(76796001)(80022001)(81342001)(54356001)(47446002)(90146001)(56816005)(74662001)(2656002)(76176001)(74706001)(74366001)(15975445006)(63696002)(47976001)(87936001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB634; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail44-am1 (localhost.localdomain [127.0.0.1]) by mail44-am1 (MessageSwitch) id 138715977499773_10300; Mon, 16 Dec 2013 02:09:34 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.241]) by mail44-am1.bigfish.com (Postfix) with ESMTP id 14726300047; Mon, 16 Dec 2013 02:09:34 +0000 (UTC) Received: from BL2PRD0510HT004.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; Mon, 16 Dec 2013 02:09:33 +0000 Received: from CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Mon, 16 Dec 2013 02:09:32 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 16 Dec 2013 02:09:29 +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.0820.005; Mon, 16 Dec 2013 02:09:23 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: Update to draft-ietf-mpls-in-udp Thread-Index: Ac76A9WfAkQisKcvR3CK41QpQI3x+Q== Date: Mon, 16 Dec 2013 02:09:22 +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.19] x-forefront-prvs: 0062BDD52C Content-Type: multipart/alternative; boundary="_000_dc4589bab65649d787f6bdee31d1ed85CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "draft-ietf-mpls-in-udp@tools.ietf.org" Subject: [mpls] Update to 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, 16 Dec 2013 02:09:42 -0000 --_000_dc4589bab65649d787f6bdee31d1ed85CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As document shepherd, I just wanted to send a heads-up to the WG on the sta= tus of draft-ietf-mpls-in-udp. The document has been submitted for publication, and has gone through secur= ity directorate and AD review. As a result of these reviews, there have bee= n significant editorial improvements to the document. These editorial impro= vements do not change anything in the operation of the protocol. However, t= here is also a provision to mention and support possible use of DTLS [RFC63= 47] in addition to IPSEC (IPSEC was already mentioned) in the event that a = user wants to secure the payload (ie, to protect whatever is being sent ove= r MPLS over UDP). We will continue with progression of the document. If anyone has strong con= cern with any of these changes feel free to bring these to the MPLS email l= ist. Thanks, Ross --_000_dc4589bab65649d787f6bdee31d1ed85CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As document shepherd, I just wanted to send a heads-up to the WG on th= e status of draft-ietf-mpls-in-udp.
 
The document has been submitted for publication, and has gone through = security directorate and AD review. As a result of these reviews, there hav= e been significant editorial improvements to the document. These editorial = improvements do not change anything in the operation of the protocol. However, there is also a provision to men= tion and support possible use of DTLS [RFC6347] in addition to IPSEC (IPSEC= was already mentioned) in the event that a user wants to secure the payloa= d (ie, to protect whatever is being sent over MPLS over UDP).
 
We will continue with progression of the document. If anyone has stron= g concern with any of these changes feel free to bring these to the MPLS em= ail list.
 
Thanks, Ross
 
 --_000_dc4589bab65649d787f6bdee31d1ed85CO2PR05MB636namprd05pro_-- From tsaad@cisco.com Sun Dec 15 19:08:55 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 E9D2A1AE025 for ; Sun, 15 Dec 2013 19:08:54 -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 I_s_Serb4AA1 for ; Sun, 15 Dec 2013 19:08:51 -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 90E8C1AE004 for ; Sun, 15 Dec 2013 19:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7604; q=dns/txt; s=iport; t=1387163330; x=1388372930; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GnXWVspSRx4KtprmYK3tMxQ67CNlJDBtkB1IPZaTt+E=; b=Pn8s3dd33PexidsFnWCkXr9l9dbCYOXU7AiKUQhzXdi0PG8KT8kP8ey5 BGKOcoeX+twTGobzOvyG+IOsSI1XvUJ3TfSwg2AKpphcR3ilERDRU3unr LxFA/4Rx7OXib/WEJXjCHy3puuQj0yqiRMaoTyy4AYnvFgx0PDMu2AeJW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAIxurlKtJV2b/2dsb2JhbABZgkZEOFW4ZIEcFnSCJQEBAQQtTBACAQgRAwECKAcyFAkIAgQBDQWIBMcvF44uWhEHhDYEmBaSFIMqgio X-IronPort-AV: E=Sophos;i="4.95,492,1384300800"; d="scan'208,217";a="6941450" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 16 Dec 2013 03:08:49 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBG38nua014090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 03:08:49 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sun, 15 Dec 2013 21:08:49 -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/BU63IW10jjHvHppWOpUA Date: Mon, 16 Dec 2013 03:08:48 +0000 Message-ID: References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C1F60D@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.248.239] Content-Type: multipart/alternative; boundary="_000_CED3CE0A97C36tsaadciscocom_" MIME-Version: 1.0 Cc: Raveendra Torvi 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, 16 Dec 2013 03:08:55 -0000 --_000_CED3CE0A97C36tsaadciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 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= ., for collecting rx stats, for doing RPF check, etc.-- hence above stateme= nt is not necessarily true 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? 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_CED3CE0A97C36tsaadciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
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 t= he backup path (in form of EB-SERO) from previous hop PLR to the backup egr= ess node
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 th= e egress=97 e.g., for collecting rx stats, for doing RPF check, etc.-- henc= e above statement is not necessarily true
3. Incidentally, "draft-minto-rsvp-lsp-egress-fast-protection-03&= quot; is also proposing a mechanism to achieve this protection using p= roxy/virtual egress node - although little mention to P2MP. Have you c= onsidered if there's any overlap there?

Regards,
Tarek

From: Huaimo Chen <huaimo.chen@huawei.com>
Date: Thursday, 12 December, 2013 8= :20 AM
To: "mpls@ietf.org" <mpls@i= etf.org>
Cc: Tarek Saad <tsaad@cisco.com>, Raveendra Torvi <rtorvi@juniper.net>
Subject: RE: MPLS-RT review of draf= t-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 fro= m some of the reviewers that they are comfortable with how the comments have been addressed. We would like t= o have the same response from the other two reviewers.

 

Best Regards,

Huaimo

 --_000_CED3CE0A97C36tsaadciscocom_-- From bill.wu@huawei.com Sun Dec 15 23:25:18 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 7B8E81AE2BF for ; Sun, 15 Dec 2013 23:25:18 -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 Me0t431_3dfY for ; Sun, 15 Dec 2013 23:25:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA9891AE2BA for ; Sun, 15 Dec 2013 23:25:10 -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 AZA99476; Mon, 16 Dec 2013 07:25:09 +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, 16 Dec 2013 07:23:37 +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, 16 Dec 2013 07:24:01 +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, 16 Dec 2013 15:23:56 +0800 From: Qin Wu To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] wglc on draft-ietf-mpls-smp-requirements Thread-Index: Ac76L8gPAbx7QpzERKO4dZ+zkusX+g== Date: Mon, 16 Dec 2013 07:23:56 +0000 Message-ID: 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_B8F9A780D330094D99AF023C5877DABA43C6C955nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [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, 16 Dec 2013 07:25:18 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C6C955nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,all: I have reviewed draft-ietf-mpls-smp-requirements. Here are a few comments I= have below. 1. Abstract said: " This document presents the basic network objectives for the behavior of shared mesh protection (SMP) not based on control-plane support. " [Qin]: Can SMP behavior be based on management plane, if not, why not say t= he SMP behavior is based on data-plane support directly. 2. Section 1, Paragraph two said: " MPLS provides control-plane tools to support various survivability schemes (Editor's note - add references). " [Qin]: What reference should be put here needs to be fixed. 3. Section 1, Paragraph three said: " When considering a full-mesh network and the protection of different paths that criss-cross the mesh, it is possible to provide an acceptable level of protection while conserving the amount of protection resources needed to protect the different data paths. " [Qin]: It is not clear to me what criss-cross is? Would it be good to add a= reference for "criss-cross" here? 4.Section 4, it said: " "Hard Preemption" requires the programming of selectors at the ingress of each shared segment to enforce which backup path has the highest priority when committing protection resources, the others being preempted. " [Qin]: Is selector one of protection endpoints? Is selector belong to share= d segment or unshared portions of segment? Is selector in the protection path or working path? It is better to be clear in the text. 5. Section 5.1, last paragraph said: " What is required is a preemption mechanism to implement business priority when multiple failure scenarios occur. " [Qin]: Is priority business related or policy decision related? Can both pr= eemption and priority policy decision related? It is not clear to me the difference between busin= ess related and policy decision related. Would you like to clarify a little bit? 6. Section 5.2, 1st paragraph said: " For those networks, in particular for networks that support the requirement= s in [RFC5654][and in particular support for requirement 58], that require the exclusive use of the protection resources, i.e. hard preemtion, the following behavior SHOULD be supported: " [Qin]: s/preemtion/preemption 7.Section 5.2, last bullet said: " During preemption, if there is an over subscription of resources protected traffic SHOULD be treated as defined in [RFC5712] or [RFC3209] " [Qin]s/[RFC3209]/[RFC3209]. [Qin]: It is not clear to me why soft preemption behavior defined in RFC5712 should be applied to hard preemption part of section 5.2 described in this document? Is there any common behavior between soft preemption and hard preemption? It is better to be clear about this in the text. 8.Section 5.5, 1st paragraph said: " Protection switching time refers to the transfer time (Tt) defined in [G.808.1] and recovery switching time defined in [RFC4427], and is defined as the interval after a switching trigger is identified until the traffic begins to be transmitted on the protection path. " [Qin]: What the relationship between "protection switching time" and "transfer time" or "recovery switching time" Can I parse this relation as: Protection switching time =3D the transfer time + recovery switching time? 9.Section 5.5, 1st paragraph said: " In order to prevent multiple switching actions for a single switching trigger, SMP SHOULD be controlled by a hold-off timer that would allow lower level mechanisms to complete their switching actions before invoking SMP protection actions. " [Qin]:Why are there multiple switching actions for a single switching trigger? Isn't one switching trigger corresponding to one switching action? Can you give an example for that? 10.Section 5.5, 1st paragraph said: " In order to prevent multiple switching actions for a single switching trigger, SMP SHOULD be controlled by a hold-off timer that would allow lower level mechanisms to complete their switching actions before invoking SMP protection actions. " [Qin]:What lower level means? What the difference between low level and high level? Does this relate to lower priority or high priority? On Tue, Dec 10, 2013 at 8:37 AM, 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 at 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 ________________________________ --_000_B8F9A780D330094D99AF023C5877DABA43C6C955nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,all:

I have reviewed draft-ietf-mpls-smp-requirements. Here are= a few comments I have below.

1. Abstract said:

“

This document presents the basic network objectives for th= e behavior

of shared mesh protection (SMP) not based on control-plane= support.

 

”

[Qin]: Can SMP behavior be based on management plan= e, if not, why not say the SMP behavior is based on data-plane support dire= ctly.

 

2. Section 1, Paragraph two said:

“

MPLS provides control-plane tools to support various survi= vability

   schemes (Editor's note - add references).&nbs= p;

 

”

[Qin]: What reference should be put here needs to be= fixed.

 

3. Section 1, Paragraph three said:

“

When considering a full-mesh network and the protection of= different

   paths that criss-cross the mesh, it is possib= le to provide an

   acceptable level of protection while conservi= ng the amount of

   protection resources needed to protect the di= fferent data paths. 

 

”

 

[Qin]: It is not clear to me what criss-cross is? = Would it be good to add a reference for “criss-cross” here?

=  

= 4.Section 4, it said:

= “

"Hard Preemption" requires the programming of se= lectors at the ingress of

each shared segment to enforce which backup path has the h= ighest

priority when committing protection resources, the others = being

preempted.

=  

= ”

[Qin]: Is selector one of protection endpoints? Is selector bel= ong to shared segment or unshared

portions of= segment? Is selector in the protection path or working path?

It is better to be clear in the text.

 

5. Section 5.1, last paragraph said:

“

What is required is a preemption mechanism to

   implement business priority when multiple fai= lure scenarios occur.

 

”

[Qin]: Is priority business related or policy decisi= on related? Can both preemption and priority

policy decision related? It is not clear to me the d= ifference between business related and policy

decision related. Would you like to clarify a little= bit?

 

6. Section 5.2, 1st  paragraph said:=

“

For those networks, in particular for networks that suppor= t the requirements in

[RFC5654][and in particular support for requirement 58], t= hat require

the exclusive use of the protection resources, i.e. hard p= reemtion,

the following behavior SHOULD be supported:

”

[Qin]: s/preemtion/preemption

 

7.Section 5.2, last bullet said:

“

During preemption, if there is an over subscription of res= ources

protected traffic SHOULD be treated as defined in [RFC5712= ] or

[RFC3209]

”

[Qin]s/[RFC3209]/[RFC3209].

 

[Qin]: It is not clear to me why soft preemption behavior = defined

in RFC5712 should be applied to hard preemption part of se= ction

5.2 described in this document?

 

Is there any common behavior between soft preemption and h= ard preemption?

It is better to be clear about this in the text.

 

8.Section 5.5, 1st paragraph said:

“

   Protection switching time refers to the trans= fer time (Tt) defined in

   [G.808.1] and recovery switching time defined= in [RFC4427], and is

   defined as the interval after a switching tri= gger is identified until

   the traffic begins to be transmitted on the p= rotection path. 

 

”

 

[Qin]:

What the relationship between “protection switching = time”

and “transfer time” or “recovery switchi= ng time”

Can I parse this relation as:

Protection switching time =3D the transfer time + reco= very switching time?

 

9.Section 5.5, 1st paragraph said:

“

   In order to prevent multiple switching action= s for a single switching

   trigger, SMP SHOULD be controlled by a hold-o= ff timer that would

   allow lower level mechanisms to complete thei= r switching actions

   before invoking SMP protection actions.<= /o:p>

 

”

[Qin]:Why are there multiple switching actions for a singl= e switching

trigger? Isn’t one switching trigger corresponding t= o one switching action?

Can you give an example for that?

 

10.Section 5.5, 1st paragraph said:

“

   In order to prevent multiple switching action= s for a single switching

   trigger, SMP SHOULD be controlled by a hold-o= ff timer that would

   allow lower level mechanisms to complete thei= r switching actions

   before invoking SMP protection actions.<= /o:p>

 

”

 

[Qin]:What lower level means? What the difference between = low level

and high level? Does this relate to lower priority or high= priority?

 

 

On Tue, Dec 10, 2013 at 8:37 AM, Loa Andersson <loa at = pi.nu> wrote:

> Working Group,

> 

> 

> this is to start a 2 week working group last call on<= o:p>

> draft-ietf-mpls-smp-requirements-02.

> 

> Please review the document and send comments to the M= PLS WG

> mailing list (mpls at ietf.org) .

> 

> There are no IPR claims against this document.

> 

> All the authors have stated on the MPLS wg mailing li= st 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

 

--_000_B8F9A780D330094D99AF023C5877DABA43C6C955nkgeml501mbschi_-- From bill.wu@huawei.com Sun Dec 15 23:38:20 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 79CA11AE2BA for ; Sun, 15 Dec 2013 23:38:20 -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 Hmw5xHjTUrZ6 for ; Sun, 15 Dec 2013 23:38:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8901AE0D9 for ; Sun, 15 Dec 2013 23:38:13 -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 BBL01279; Mon, 16 Dec 2013 07:38:11 +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; Mon, 16 Dec 2013 07:37:45 +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; Mon, 16 Dec 2013 07:38:07 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 16 Dec 2013 15:38:03 +0800 From: Qin Wu To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6 Thread-Index: Ac76McDT81KeKOoTQciG8BVEHs9hcQ== Date: Mon, 16 Dec 2013 07:38:03 +0000 Message-ID: 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_B8F9A780D330094D99AF023C5877DABA43C6C984nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] Short wg last call on 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, 16 Dec 2013 07:38:20 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C6C984nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all: Here are my review to draft-ietf-mpls-ldp-ipv6. 1. Section 5.1 said: " Additionally, the link-local IPv6 address MUST be used as the source IP address in IPv6 LDP Link Hellos. " [Qin]: Why the link local multicast IPv6 address MUST be used as the source= address? Usually multicast IPv6 address is used as destination address for datagram,= what am I missing? 2. Section 5.1, last paragraph said: " Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the same LDP identifier (assuming per-platform label space usage). " s/must/MUST 3. Section 5.2, 1st paragraph said: " Suffice to say, the extended discovery mechanism (defined in section 2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific consideration, since the targeted LDP Hellos are sent to a pre- configured (unicast) destination IPv6 address. " [Qin]; It is better to clarify the purpose of extended discovery mechanism?= E.g., for discovery of the LSR that is not directly connected in the LDP session? 4. Section 6.1, said: " however, it does not specify the behavior of LDP if both IPv4 and IPv6 transport address objects (TLV) are sent in a Hello message or separate Hello messages. " [Qin]: It is better to distinct one Hello from two Hello, so suggest the fo= llowing change s/separate Hello/two separate Hello 5. Section 6.1,2nd bullet: " O An LSR SHOULD accept the Hello message that contains both IPv4 and IPv6 transport address optional objects, but MUST use only the transport address whose address family is the same as that of the IP packet carrying Hello. " [Qin]: Since LSR is not allowed to send a Hello containing both IPv4 and IP= v6 transport address, why receiving LSR need to process such Hello message? 6.Section 6.1, 5th bullet: " An LSR MUST prefer using global unicast IPv6 address for an LDP session with a remote LSR, if it had to choose between global unicast IPv6 address and unique-local or link-local IPv6 address (pertaining to the same LDP Identifier) for the transport connection. " [Qin]: Can unique-local or link local IPv6 address be used in IPv6 transpor= t address optional object? Is bullet 5 contradict with bullet 4? 7. Section 6.2 said: " This document allows an LSR to maintain Rx-side Link Hello adjacency for only one address family that has been used for the establishment of the LDP session. " [Qin]: What does Rx-side mean? Is there sender side Link Hello? -----Original Message----- From: Loa Andersson Date: Wednesday, December 11, 2013 11:52 PM To: "mpls at ietf.org" , "mpls-chairs at tools.ietf.org" , Martin Vigoureux , "draft-ietf-mpls-ldp-ipv6 at tools.ietf.org" Subject: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6 >Working Group, > >This is to start a one week working group last call on >draft-ietf-mpls-ldp-ipv6-10 > >We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good >comments and the document almost ready to go. At that point a discussion >on the number of LDP session needed between a pair LSRs with both IPv4 >and IPv6 emerged, it has taken us quite a long time to resolve this. > >However, the author, wg chairs and people making the comments now agree >that version -10 is resolve those comments. > >This working group last call is limited to the changes since the >previous last call. A diff can be found at: > >http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-ldp-ipv6-07&difftype=3D= --ht >ml&submit=3DGo%21&url2=3Ddraft-ietf-mpls-ldp-ipv6-10 > >Please send you comments to the MPLS wg mailing list (mpls at ietf.org). > >This wglc ends Dec 20, 2013. > >/Loa ________________________________ --_000_B8F9A780D330094D99AF023C5877DABA43C6C984nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all:

Here are my review to draft-ietf-mpls-ldp-ipv6.=

1. Section 5.1 said:

“

Additionally, the link-local

IPv6 address MUST be used as the source IP address in IPv6= LDP Link

Hellos.

 

”

[Qin]: Why the= link local multicast IPv6 address MUST be used as the source address?=

Usually multic= ast IPv6 address is used as destination address for datagram, what am I mis= sing?

 

2. Section 5.1= , last paragraph said:

“

Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the s= ame LDP

identifier (assuming per-platform label space usage).=

 

”

s/must/MUST

3. Section 5.2= , 1st paragraph said:

“

Suffice to say, the extended discovery mechanism (defined = in section

2.4.2 of [RFC5036]) doesn't require any additional IPv6 sp= ecific

consideration, since the targeted LDP Hellos are sent to a= pre-

configured (unicast) destination IPv6 address.=

”

 

[Qin]; It is b= etter to clarify the purpose of extended discovery mechanism? E.g., for

discovery of t= he LSR that is not directly connected in the LDP session?=

 

4. Section 6.1= , said:

“

however, it does not specify the

   behavior of LDP if both IPv4 and IPv6 transpo= rt address objects

   (TLV) are sent in a Hello message or separate= Hello messages.

 

”

[Qin]: = It is better to distinct one Hello from two Hello, so suggest the following= change
s/separate Hello/two separate Hello

 

5. Section 6.1,2nd bullet:

“

O An LSR= SHOULD accept the Hello message that contains both IPv4<= /p>

and IPv6 transport address optional objects, but MUST use = only

the transport address whose address family is the same as = that

of the IP packet carrying Hello.

 

”

[Qin]: Since LSR is not allowed to send a Hello cont= aining both IPv4 and IPv6 transport address, why receiving LSR need to proc= ess such Hello message?

 

6.Section 6.1, 5th bullet:

“

An LSR MUST prefer using global unicast IPv6 address for a= n LDP

session with a remote LSR, if it had to choose between glo= bal

unicast IPv6 address and unique-local or link-local IPv6

address (pertaining to the same LDP Identifier) for the

transport connection.

”

[Qin]: Can unique-local or link local IPv6 address b= e used in IPv6 transport address optional object? Is bullet 5 contradict wi= th bullet 4?

 

7. Section 6.2 said:

“

This document allows an LSR to maintain Rx-side Link Hello= adjacency

for only one address family that has been used for the est= ablishment

of the LDP session.

”

[Qin]: What does Rx-side mean?

Is there sender side Link Hello?

 

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

From: Loa Andersson <loa at pi.nu><= /p>

Date: Wednesday, December 11, 2013 11:52 PM

To: "mpls at ietf.org" <mpls at ietf.or= g>, "mpls-chairs at tools.ietf.org"

<mpls-chairs at tools.ietf.org>, Martin Vigour= eux

<martin.vigoureux at alcatel-lucent.com>,=

"draft-ietf-mpls-ldp-ipv6 at tools.ietf.org&quo= t;

<draft-ietf-mpls-ldp-ipv6 at tools.ietf.org>

Subject: [mpls] Short wg last call on draft-ietf-mpl= s-ldp-ipv6

 

>Working Group,

> 

>This is to start a one week working group last c= all on

>draft-ietf-mpls-ldp-ipv6-10

> 

>We did a wglc on draft draft-ietf-mpls-ldp-ipv6 = mid-2011. We had good

>comments and the document almost ready to go. At= that point a discussion

>on the number of LDP session needed between a pa= ir LSRs with both IPv4

>and IPv6 emerged, it has taken us quite a long t= ime to resolve this.

> 

>However, the author, wg chairs and people making= the comments now agree

>that version -10 is resolve those comments.=

> 

>This working group last call is limited to the c= hanges since the

>previous last call. A diff can be found at:=

> 

>http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mp= ls-ldp-ipv6-07&difftype=3D--ht

>ml&submit=3DGo%21&url2=3Ddraft-ietf-mpls= -ldp-ipv6-10

> 

>Please send you comments to the MPLS wg mailing = list (mpls at ietf.org).

> 

>This wglc ends Dec 20, 2013.

> 

>/Loa

--_000_B8F9A780D330094D99AF023C5877DABA43C6C984nkgeml501mbschi_-- From rcallon@juniper.net Mon Dec 16 08:33:33 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 9EF501ADF83 for ; Mon, 16 Dec 2013 08:33:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsMBiNW0yYPn for ; Mon, 16 Dec 2013 08:33:31 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8CE1ADF50 for ; Mon, 16 Dec 2013 08:33:31 -0800 (PST) Received: from mail4-db9-R.bigfish.com (10.174.16.237) by DB9EHSOBE011.bigfish.com (10.174.14.74) with Microsoft SMTP Server id 14.1.225.22; Mon, 16 Dec 2013 16:33:29 +0000 Received: from mail4-db9 (localhost [127.0.0.1]) by mail4-db9-R.bigfish.com (Postfix) with ESMTP id B9F582806BB; Mon, 16 Dec 2013 16:33:29 +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(z579ehz9371I542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzc2hz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail4-db9: 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)(164054003)(13464003)(199002)(377454003)(63696002)(87936001)(49866001)(47736001)(85852003)(87266001)(83072002)(69226001)(74876001)(50986001)(59766001)(81542001)(83322001)(76796001)(81686001)(74316001)(80022001)(19580405001)(19580395003)(76786001)(47976001)(85306002)(54316002)(65816001)(1941001)(56816005)(2656002)(77982001)(76482001)(74706001)(74662001)(74502001)(81342001)(31966008)(46102001)(80976001)(53806001)(90146001)(81816001)(79102001)(4396001)(51856001)(66066001)(74366001)(54356001)(76576001)(56776001)(47446002)(33646001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.14; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail4-db9 (localhost.localdomain [127.0.0.1]) by mail4-db9 (MessageSwitch) id 138721160826451_19062; Mon, 16 Dec 2013 16:33:28 +0000 (UTC) Received: from DB9EHSMHS031.bigfish.com (unknown [10.174.16.227]) by mail4-db9.bigfish.com (Postfix) with ESMTP id EC348560052; Mon, 16 Dec 2013 16:33:27 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS031.bigfish.com (10.174.14.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 16 Dec 2013 16:33:25 +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.383.1; Mon, 16 Dec 2013 16:33:25 +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.820.5; Mon, 16 Dec 2013 16:33:23 +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.0820.005; Mon, 16 Dec 2013 16:33:23 +0000 From: Ross Callon To: Ross Callon , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO8Ilsdxvw6W4DfkSXFkfIGRLzvppXFviQ Date: Mon, 16 Dec 2013 16:33:22 +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: 0062BDD52C 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" , "draft-ietf-mpls-moving-iana-registries@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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, 16 Dec 2013 16:33:33 -0000 This working group last call ends in two days. However, to this point we ha= ve only one reply (from Andy Malis -- thanks Andy).=20 Please review the document and respond. If you think that the document is f= ine a simple "support" is sufficient, but the document cannot progress unle= ss there is some WG support.=20 Thanks, Ross PS: If you think that you have already replied and you are not Andy, then l= et me know and include "draft-ietf-mpls-moving-iana-registries" in the subj= ect line.=20 -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Tuesday, December 03, 2013 7:40 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-moving-iana-registries@tool= s.ietf.org Subject: working group last call on draft-ietf-mpls-moving-iana-registries-= 00 Working Group; =20 This is to start a two week working group last call on draft-ietf-mpls-moving-iana-registries-00.txt. Please send your comment to the working group mailing list (mpls@ietf.org). We did an IPR poll on this document in September. The authors each responde= d to the=20 IPR poll that they not aware of any IPR relating to this document. There ar= e no IPRs=20 disclosed against this document. The working group last call will end Wednesday December 18, 2013. Ross (as mpls wg co-chair) From nobo@cisco.com Mon Dec 16 15:01:31 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 F2B6F1ADF78 for ; Mon, 16 Dec 2013 15:01:30 -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 04_VxeYsjmGc for ; Mon, 16 Dec 2013 15:01:29 -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 E0C311AD9AD for ; Mon, 16 Dec 2013 15:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5486; q=dns/txt; s=iport; t=1387234888; x=1388444488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Z4ywGb/zns6P+fjo+jOocd1STZ+xxhnFWNHqNoYF1Y0=; b=g1Ko80m/kip8vkeX+v/VCrQUERhIIzXMb4pEOOFwefhnAN7ePiJx2FqR ad4a0d/lutDNb91Y3N9ifKKUYfsFNv1oD5CwBKrgqeTwlHYeZjIIH+Fsj So70GMFPJ8z6yARQMI8P4kHZTpDftvpQL4qHXk/UomHl8FkDHJbU5l+RK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALGFr1KtJV2a/2dsb2JhbABZgmkhOFW4SYElFnSCJQEBAQQBAQEkEzQLDAQCAQgRBAEBCxQJBycLFAkIAQEEAQ0FCBOHaQEMyC4TBI4uOjEHBoMdgRMBA6oqgyqCKg X-IronPort-AV: E=Sophos;i="4.95,498,1384300800"; d="scan'208";a="7194754" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 16 Dec 2013 23:01:27 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBGN1RHr031556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 23:01:27 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 17:01:27 -0600 From: "Nobo Akiya (nobo)" To: Huaimo Chen , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: Comment on draft-chen-mpls-p2mp-ingress-protection Thread-Index: Ac7bieAe3j4zI+A+Rcq0NrmUMXL15gedQ3YAACODSLA= Date: Mon, 16 Dec 2013 23:01:27 +0000 Message-ID: References: <5316A0AB3C851246A7CA5758973207D445C200A7@sjceml501-mbs.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C200A7@sjceml501-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comment 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: Mon, 16 Dec 2013 23:01:31 -0000 Hi Huaimo, Thanks for response! The fundamental thing is, node failure will fail relevant BFD in your propo= sal, but BFD failure may not mean node failure. Please see comments inline. > -----Original Message----- > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > Sent: Sunday, December 15, 2013 9:01 PM > To: Nobo Akiya (nobo); draft-chen-mpls-p2mp-ingress- > protection@tools.ietf.org > Cc: mpls@ietf.org > Subject: RE: Comment on draft-chen-mpls-p2mp-ingress-protection >=20 > Hi Nobo, >=20 > Thanks for your comments! > See my answers/explanations inline below. >=20 > Best Regards, > Huaimo >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Nobo Akiya (nobo) > Sent: Thursday, November 07, 2013 2:51 AM > To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org > Cc: mpls@ietf.org > Subject: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protection >=20 > Hi Authors, >=20 > I didn't get a chance to comment on your draft at the WG session today, s= o > sending to the list. My concern is similar to what Greg Mirsky stated. > Simply running 2 independent BFD sessions (as described in the slides) wi= ll > have issues. >=20 > Huaimo: In normal operations, source CE sends the traffic to the primary > ingress, which imports the traffic into the primary LSP. It does not send= the > traffic to the backup ingress. > When the primary ingress fails, the source CE will detect the failure of = the > primary ingress through the BFD between CE and the primary ingress and > switches the traffic to the backup ingress. The backup ingress will also > detect the failure of the primary ingress through the BFD between the > backup ingress and the primary ingress, and put the traffic from the sour= ce > CE into the backup LSP to the next hops of the primary ingress, where the > traffic is merged into the primary LSP. > When the link between the backup ingress and the primary ingress fails, t= he > source CE will continue to send the traffic to the primary ingress, and d= oes > not send the traffic to the backup ingress. The traffic will be delivered= to the > destinations via the primary LSP. > It seems that it works as expected. > Can you give more details about "Simply running 2 independent BFD > sessions (as described in the slides) will have issues."? One example would be the case where BFD between CE and primary ingress fail= s but not BFD between primary ingress and backup ingress. Section 3.1 says: [snip] The backup ingress does not import any traffic from the source into the backup LSP in normal operations. When it detects a failure involving the primary ingress, it imports the traffic from the source into the backup LSP to the next hops of the primary ingress, where the traffic is merged into the primary LSP. [snip] In this case, CE will be sending traffic to backup ingress, but backup ingr= ess isn't sending the traffic into backup LSP, since BFD from backup ingres= s to primary ingress is still up. Because proposal [currently] requires syn= chronized decision made by multiple devices making independent decisions, t= his is an area which should require further attention.=20 The detection which this proposal is really interested in is failures in fo= llowing paths: CE --> primary ingress --> primary LSP --> in-band at least to nexthop Running multiple single-hop BFD doesn't accurately achieve this. For the backup activation, you probably want to have one failure detection,= or one node making the decision based on multiple failure detections ... i= deally. >=20 >=20 > > 3. Ingress Failure Detection > > > > Exactly how the failure of the ingress (e.g. R1 in Figure 1) is > > detected is out of scope for this document. >=20 > I believe, at least, definition of the "failure" should be defined in the= draft. > Without it, it can be interpreted by readers as complete node outage, > outage of all involved links, outage of just primary-backup link, or even > something else. And without defining what the "failure" is, it's difficul= t to > figure out the right techniques to detect the failure. And that can easil= y > result in deviating detection implementations for described solution to n= ot > kick off in expected manner. >=20 > Huaimo: The primary ingress node failure in this draft is similar to the = node > failure in RFC 4090. For non-ingress-protection, failure of a downstream from upstream perspecti= ve is clear: there is no need to differentiate between link failure and nod= e failure. What is proposed in the document is a detection mechanism where = (link failure & node alive) scenario can create inconsistent backup takeove= r. In addition, because you have multiple "detector" nodes, failure of a si= ngle-hop BFD cannot be assumed as a node failure. It can just be a link fai= lure, or LC failure of one node which doesn't impact any corresponding traf= fic. I think you can see from above that there's a bit of difference betwee= n the "failure" which you want backup activated vs. "failure" which propose= d detection mechanism detects. This is why I think it'll be beneficial to d= efine what the "failure" is. -Nobo >=20 > -Nobo >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobo@cisco.com Mon Dec 16 15:36:41 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 CBB8D1ADF4E for ; Mon, 16 Dec 2013 15:36: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 biRN1rEeNNgj for ; Mon, 16 Dec 2013 15:36:40 -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 1F3A31AD9B7 for ; Mon, 16 Dec 2013 15:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2295; q=dns/txt; s=iport; t=1387236999; x=1388446599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/wRI9rMrFLt+yCKwPNlNK5Cw4nc83svRdeUFax1JWQI=; b=QGv7nbYX4mNz6+8FvA/XXa85zA1SzIoz9cywWk1eHSlHMNN44ASAhyxk 5CXiT6gBoOmpfEQKGac3PoC1mnaLy7fDXPKH7w+SsGsH0FJS/XyI6FrYo 9R49qo+g3f64NUYj3v/K2rZj1Zd9hdqW4YrYVWHH0xZQDBSTXKVygVoD5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOWNr1KtJXG//2dsb2JhbABZgmkhOFW4VoElFnSCJQEBAQQBAQE3NAsMBAIBCA4DBAEBCxQJBycLFAkIAgQBDQUIh3wBDMgkEwSOaDEHBoMdgRMEqiqDKoIq X-IronPort-AV: E=Sophos;i="4.95,498,1384300800"; d="scan'208";a="7202229" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-2.cisco.com with ESMTP; 16 Dec 2013 23:36:39 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBGNadCk007508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 23:36:39 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 17:36:38 -0600 From: "Nobo Akiya (nobo)" To: Ross Callon , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO+nyU+4+Pft+SP0GPtXGGLPL025pXbOvA Date: Mon, 16 Dec 2013 23:36:37 +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: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-moving-iana-registries@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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, 16 Dec 2013 23:36:42 -0000 Support, this cleanup is very useful. I do have couple of very minor nitpicks. 1. section=3DIntroduction, paragraph=3D1 s/This is an update to RFC RFC 5586 [RFC5586]/This is an update to RFC 5586= [RFC5586]/ 2. section=3DIntroduction, paragraph=3D3 s/... RFC 6378] [RFC6378], .../... RFC 6378 [RFC6378], .../ -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: Monday, December 16, 2013 11:33 AM > To: Ross Callon; mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-moving-iana- > registries@tools.ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-ian= a- > registries-00 >=20 > This working group last call ends in two days. However, to this point we > have only one reply (from Andy Malis -- thanks Andy). >=20 > Please review the document and respond. If you think that the document is > fine a simple "support" is sufficient, but the document cannot progress > unless there is some WG support. >=20 > Thanks, Ross >=20 > PS: If you think that you have already replied and you are not Andy, then= let > me know and include "draft-ietf-mpls-moving-iana-registries" in the subje= ct > line. >=20 > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: Tuesday, December 03, 2013 7:40 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-moving-iana- > registries@tools.ietf.org > Subject: working group last call on draft-ietf-mpls-moving-iana-registrie= s-00 >=20 > Working Group; >=20 > This is to start a two week working group last call on draft-ietf-mpls- > moving-iana-registries-00.txt. >=20 > Please send your comment to the working group mailing list > (mpls@ietf.org). >=20 > We did an IPR poll on this document in September. The authors each > responded to the IPR poll that they not aware of any IPR relating to this > document. There are no IPRs disclosed against this document. >=20 > The working group last call will end Wednesday December 18, 2013. >=20 > Ross > (as mpls wg co-chair) >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From wwwrun@rfc-editor.org Mon Dec 16 15:38:15 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 502531ADFA8; Mon, 16 Dec 2013 15:38:15 -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 KEU1JJU3q7qd; Mon, 16 Dec 2013 15:38:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 32E4F1ADF7F; Mon, 16 Dec 2013 15:38:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6FD857FC39A; Mon, 16 Dec 2013 15:38:09 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131216233809.6FD857FC39A@rfc-editor.org> Date: Mon, 16 Dec 2013 15:38:09 -0800 (PST) Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7087 on A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 16 Dec 2013 23:38:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7087 Title: A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations Author: H. van Helvoort, Ed., L. Andersson, Ed., N. Sprecher, Ed. Status: Informational Stream: IETF Date: December 2013 Mailbox: Huub.van.Helvoort@huawei.com, loa@mail01.huawei.com, nurit.sprecher@nsn.com Pages: 21 Characters: 43925 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-rosetta-stone-13.txt URL: http://www.rfc-editor.org/rfc/rfc7087.txt The MPLS Transport Profile (MPLS-TP) is based on a profile of the MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force (IETF). The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network Recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive or complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 naikumar@cisco.com Mon Dec 16 16:55:54 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 985071ADF80 for ; Mon, 16 Dec 2013 16:55:54 -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 lEgAQ6_-HBC0 for ; Mon, 16 Dec 2013 16:55:53 -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 1A3931ADF32 for ; Mon, 16 Dec 2013 16:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1614; q=dns/txt; s=iport; t=1387241752; x=1388451352; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=b1xZIM51vJ9Yj6LnOL16cH/SUcIr8q0sMeoA3sw281w=; b=j8yyYiM+kSc1ncFK9+jg4A8k36Y4OkTLweD0cANhQyRGDmHkVkXWpKXU +HegxrrNfgGx6CKuC9eX2jwy82nCWhl4CJjVAhcNIAHULzAa4TQu+7V4+ IntjHvgSm048NR9N+UYQZswH/M/oD2PVIACKB/i44mEc9MJHCP75FC1zf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAGegr1KtJXG+/2dsb2JhbABZgwo4VbhXgSMWdIIlAQEBBAEBATc0CwwGAQgOAwQBAR8JLgsUCQgCBAENBYgEDcgtEwSPGQcGhDABA5gWkhSDKoIq X-IronPort-AV: E=Sophos;i="4.95,498,1384300800"; d="scan'208";a="291950076" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 17 Dec 2013 00:55:52 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBH0tqh9028084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Dec 2013 00:55:52 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.23]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 18:55:51 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO+nyVfYtBqWqh9kaX6+smW4sh4JpXoTuA Date: Tue, 17 Dec 2013 00:55:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.89.103] Content-Type: text/plain; charset="us-ascii" Content-ID: <21552CF985BEE146A961A94717DA0772@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-moving-iana-registries@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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, 17 Dec 2013 00:55:54 -0000 Support. Regards, Nagendra On 12/16/13 11:33 AM, "Ross Callon" wrote: >This working group last call ends in two days. However, to this point we >have only one reply (from Andy Malis -- thanks Andy). > >Please review the document and respond. If you think that the document is >fine a simple "support" is sufficient, but the document cannot progress >unless there is some WG support. > >Thanks, Ross > >PS: If you think that you have already replied and you are not Andy, then >let me know and include "draft-ietf-mpls-moving-iana-registries" in the >subject line.=20 > >-----Original Message----- >From: Ross Callon [mailto:rcallon@juniper.net] >Sent: Tuesday, December 03, 2013 7:40 PM >To: mpls@ietf.org >Cc: mpls-chairs@tools.ietf.org; >draft-ietf-mpls-moving-iana-registries@tools.ietf.org >Subject: working group last call on >draft-ietf-mpls-moving-iana-registries-00 > >Working Group; >=20 >This is to start a two week working group last call on >draft-ietf-mpls-moving-iana-registries-00.txt. > >Please send your comment to the working group mailing list >(mpls@ietf.org). > >We did an IPR poll on this document in September. The authors each >responded to the=20 >IPR poll that they not aware of any IPR relating to this document. There >are no IPRs=20 >disclosed against this document. > >The working group last call will end Wednesday December 18, 2013. > >Ross >(as mpls wg co-chair) > > > > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From mach.chen@huawei.com Mon Dec 16 17:02:29 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 C83631ADFC8 for ; Mon, 16 Dec 2013 17:02:29 -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 5sm9HjbucwLr for ; Mon, 16 Dec 2013 17:02:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE7F1ADFB0 for ; Mon, 16 Dec 2013 17:02:26 -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 BBM65962; Tue, 17 Dec 2013 01:02:24 +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; Tue, 17 Dec 2013 01:01:59 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 01:02:23 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 09:02:21 +0800 From: Mach Chen To: Ross Callon , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO+nyX+5X86TJuA0WNOI3CXA4x85pXkYSA Date: Tue, 17 Dec 2013 01:02:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.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-moving-iana-registries@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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, 17 Dec 2013 01:02:30 -0000 I have read the draft, it's useful and well written, support to progress th= e draft. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: Tuesday, December 17, 2013 12:33 AM > To: Ross Callon; mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; > draft-ietf-mpls-moving-iana-registries@tools.ietf.org > Subject: Re: [mpls] working group last call on > draft-ietf-mpls-moving-iana-registries-00 >=20 > This working group last call ends in two days. However, to this point we = have only > one reply (from Andy Malis -- thanks Andy). >=20 > Please review the document and respond. If you think that the document is= fine > a simple "support" is sufficient, but the document cannot progress unless= there is > some WG support. >=20 > Thanks, Ross >=20 > PS: If you think that you have already replied and you are not Andy, then= let me > know and include "draft-ietf-mpls-moving-iana-registries" in the subject = line. >=20 > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: Tuesday, December 03, 2013 7:40 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; > draft-ietf-mpls-moving-iana-registries@tools.ietf.org > Subject: working group last call on draft-ietf-mpls-moving-iana-registrie= s-00 >=20 > Working Group; >=20 > This is to start a two week working group last call on > draft-ietf-mpls-moving-iana-registries-00.txt. >=20 > Please send your comment to the working group mailing list (mpls@ietf.org= ). >=20 > We did an IPR poll on this document in September. The authors each respon= ded > to the IPR poll that they not aware of any IPR relating to this document.= There are > no IPRs disclosed against this document. >=20 > The working group last call will end Wednesday December 18, 2013. >=20 > Ross > (as mpls wg co-chair) >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huaimo.chen@huawei.com Mon Dec 16 17:07:12 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 2C0081ADFB4 for ; Mon, 16 Dec 2013 17:07:12 -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 BadA3w5KRnGp for ; Mon, 16 Dec 2013 17:07:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E5AD11ADFBD for ; Mon, 16 Dec 2013 17:07:08 -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 AZB75437; Tue, 17 Dec 2013 01:07:07 +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; Tue, 17 Dec 2013 01:06:42 +0000 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 01:07:06 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.165]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Mon, 16 Dec 2013 17:07:00 -0800 From: Huaimo Chen To: "Nobo Akiya (nobo)" , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: Comment on draft-chen-mpls-p2mp-ingress-protection Thread-Index: Ac7bieAe3j4zI+A+Rcq0NrmUMXL15gedQ3YAACODSLAADPbeQA== Date: Tue, 17 Dec 2013 01:06:59 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C20285@sjceml501-mbs.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D445C200A7@sjceml501-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Comment 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, 17 Dec 2013 01:07:12 -0000 Hi Nobo, Thanks for your reply in details! Basically, there are three failure points related to the primary ingres= s here. The first one is the failure of the primary ingress. The second is = the failure of the link between the primary ingress and the backup ingress.= The third is the failure of the link between the primary ingress and the s= ource CE.=20 The problem is how to make sure that the traffic from the source CE is = delivered to the destinations via the LSP when any one of the above three f= ailures happens. When any one of the first two failures happens, the draft = provides a way to make sure that the traffic from the source CE is sent to = the destinations. What happens if the third failure occurs (i.e., the link = between the primary ingress and the source CE fails)? It seems that this is= your question. Is my understanding right? Best Regards, Huaimo -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Monday, December 16, 2013 6:01 PM To: Huaimo Chen; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: RE: Comment on draft-chen-mpls-p2mp-ingress-protection Hi Huaimo, Thanks for response! The fundamental thing is, node failure will fail relevant BFD in your propo= sal, but BFD failure may not mean node failure. Please see comments inline. > -----Original Message----- > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > Sent: Sunday, December 15, 2013 9:01 PM > To: Nobo Akiya (nobo); draft-chen-mpls-p2mp-ingress-=20 > protection@tools.ietf.org > Cc: mpls@ietf.org > Subject: RE: Comment on draft-chen-mpls-p2mp-ingress-protection >=20 > Hi Nobo, >=20 > Thanks for your comments! > See my answers/explanations inline below. >=20 > Best Regards, > Huaimo >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Nobo Akiya (nobo) > Sent: Thursday, November 07, 2013 2:51 AM > To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org > Cc: mpls@ietf.org > Subject: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protection >=20 > Hi Authors, >=20 > I didn't get a chance to comment on your draft at the WG session=20 > today, so sending to the list. My concern is similar to what Greg Mirsky = stated. > Simply running 2 independent BFD sessions (as described in the slides)=20 > will have issues. >=20 > Huaimo: In normal operations, source CE sends the traffic to the=20 > primary ingress, which imports the traffic into the primary LSP. It=20 > does not send the traffic to the backup ingress. > When the primary ingress fails, the source CE will detect the failure=20 > of the primary ingress through the BFD between CE and the primary=20 > ingress and switches the traffic to the backup ingress. The backup=20 > ingress will also detect the failure of the primary ingress through=20 > the BFD between the backup ingress and the primary ingress, and put=20 > the traffic from the source CE into the backup LSP to the next hops of=20 > the primary ingress, where the traffic is merged into the primary LSP. > When the link between the backup ingress and the primary ingress=20 > fails, the source CE will continue to send the traffic to the primary=20 > ingress, and does not send the traffic to the backup ingress. The=20 > traffic will be delivered to the destinations via the primary LSP. > It seems that it works as expected. > Can you give more details about "Simply running 2 independent BFD=20 > sessions (as described in the slides) will have issues."? One example would be the case where BFD between CE and primary ingress fail= s but not BFD between primary ingress and backup ingress. Section 3.1 says: [snip] The backup ingress does not import any traffic from the source into the backup LSP in normal operations. When it detects a failure involving the primary ingress, it imports the traffic from the source into the backup LSP to the next hops of the primary ingress, where the traffic is merged into the primary LSP. [snip] In this case, CE will be sending traffic to backup ingress, but backup ingr= ess isn't sending the traffic into backup LSP, since BFD from backup ingres= s to primary ingress is still up. Because proposal [currently] requires syn= chronized decision made by multiple devices making independent decisions, t= his is an area which should require further attention.=20 The detection which this proposal is really interested in is failures in fo= llowing paths: CE --> primary ingress --> primary LSP --> in-band at least to nexthop Runn= ing multiple single-hop BFD doesn't accurately achieve this. For the backup activation, you probably want to have one failure detection,= or one node making the decision based on multiple failure detections ... i= deally. >=20 >=20 > > 3. Ingress Failure Detection > > > > Exactly how the failure of the ingress (e.g. R1 in Figure 1) is > > detected is out of scope for this document. >=20 > I believe, at least, definition of the "failure" should be defined in the= draft. > Without it, it can be interpreted by readers as complete node outage,=20 > outage of all involved links, outage of just primary-backup link, or=20 > even something else. And without defining what the "failure" is, it's=20 > difficult to figure out the right techniques to detect the failure.=20 > And that can easily result in deviating detection implementations for=20 > described solution to not kick off in expected manner. >=20 > Huaimo: The primary ingress node failure in this draft is similar to=20 > the node failure in RFC 4090. For non-ingress-protection, failure of a downstream from upstream perspecti= ve is clear: there is no need to differentiate between link failure and nod= e failure. What is proposed in the document is a detection mechanism where = (link failure & node alive) scenario can create inconsistent backup takeove= r. In addition, because you have multiple "detector" nodes, failure of a si= ngle-hop BFD cannot be assumed as a node failure. It can just be a link fai= lure, or LC failure of one node which doesn't impact any corresponding traf= fic. I think you can see from above that there's a bit of difference betwee= n the "failure" which you want backup activated vs. "failure" which propose= d detection mechanism detects. This is why I think it'll be beneficial to d= efine what the "failure" is. -Nobo >=20 > -Nobo >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huaimo.chen@huawei.com Mon Dec 16 17:09:49 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 223CB1ADFD2 for ; Mon, 16 Dec 2013 17:09:49 -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 0yf-X1RrJgWb for ; Mon, 16 Dec 2013 17:09:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 35E2A1ADFB4 for ; Mon, 16 Dec 2013 17:09:47 -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 BBM66238; Tue, 17 Dec 2013 01:09:46 +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; Tue, 17 Dec 2013 01:09:21 +0000 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 01:09:45 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.165]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Mon, 16 Dec 2013 17:09:37 -0800 From: Huaimo Chen To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO8Ilsdxvw6W4DfkSXFkfIGRLzvppXFviQgAEThgD//31Q8A== Date: Tue, 17 Dec 2013 01:09:37 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C20294@sjceml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.50] 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-moving-iana-registries@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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, 17 Dec 2013 01:09:49 -0000 Support. Best Regards, Huaimo On 12/16/13 11:33 AM, "Ross Callon" wrote: >This working group last call ends in two days. However, to this point=20 >we have only one reply (from Andy Malis -- thanks Andy). > >Please review the document and respond. If you think that the document=20 >is fine a simple "support" is sufficient, but the document cannot=20 >progress unless there is some WG support. > >Thanks, Ross > >PS: If you think that you have already replied and you are not Andy,=20 >then let me know and include "draft-ietf-mpls-moving-iana-registries"=20 >in the subject line. > >-----Original Message----- >From: Ross Callon [mailto:rcallon@juniper.net] >Sent: Tuesday, December 03, 2013 7:40 PM >To: mpls@ietf.org >Cc: mpls-chairs@tools.ietf.org; >draft-ietf-mpls-moving-iana-registries@tools.ietf.org >Subject: working group last call on >draft-ietf-mpls-moving-iana-registries-00 > >Working Group; >=20 >This is to start a two week working group last call on=20 >draft-ietf-mpls-moving-iana-registries-00.txt. > >Please send your comment to the working group mailing list=20 >(mpls@ietf.org). > >We did an IPR poll on this document in September. The authors each=20 >responded to the IPR poll that they not aware of any IPR relating to=20 >this document. There are no IPRs disclosed against this document. > >The working group last call will end Wednesday December 18, 2013. > >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 gregory.mirsky@ericsson.com Mon Dec 16 17:25:30 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 A97ED1ADFFB for ; Mon, 16 Dec 2013 17: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 W-U7i6LRT-J2 for ; Mon, 16 Dec 2013 17:25:28 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8E61ADFF4 for ; Mon, 16 Dec 2013 17:25:28 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-11-52afa8074831 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 52.61.04556.708AFA25; Tue, 17 Dec 2013 02:25:27 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0347.000; Mon, 16 Dec 2013 20:25:16 -0500 From: Gregory Mirsky To: Ross Callon , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO8Ilsdxvw6W4DfkSXFkfIGRLzvppXFviQgACVh5A= Date: Tue, 17 Dec 2013 01:25:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B73B2E6@eusaamb103.ericsson.se> References: In-Reply-To: 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+NgFrrPLMWRmVeSWpSXmKPExsUyuXRPuC77ivVBBi/naVjc+3uIzeL7pSUs FreWrmS1+LviCosDi8eSJT+ZPK43XWX3+HL5M1sAcxSXTUpqTmZZapG+XQJXRuenZpaCc3wV V1YtZG5g7OPpYuTkkBAwkfj+8RsLhC0mceHeerYuRi4OIYEjjBJd584zQTjLGSVePtnMBFLF JmAk8WJjDzuILSLgJjGn/wRYEbPAJkaJ5zeOgSWEBYIlrr9dzwRRFCKxefVLVgjbSuL+zc/M IDaLgKrEiQnzwVbzCvhK9M+4yQ6xbSGjxN9bW8EGcQqESezpmQNmMwLd9/3UGrChzALiEree zGeCuFtAYsme88wQtqjEy8f/WCFsZYnvcx6xQNTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExg FJuFZOwsJC2zkLTMQtKygJFlFSNHaXFqWW66keEmRmAkHZNgc9zBuOCT5SFGaQ4WJXHeL2+d g4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwpm1xeRJrJ6Y7Ibp/yRYfplOm32M8rff8CF2l fv9PqNIKo+9T/K5/Mz7Y5fovUXG/VmlFY8nbiOD8wFVtzl81GaJ17k9ZmX18skGwxK8zNQEh UYJ6b95ffbPo1snEd7PWvYmKucOv0ablvjPw2sJ1/KFsOosUlVpCHqYJnlS8xHLv8hvJ6+VL lViKMxINtZiLihMB/jVzW3ICAAA= Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-moving-iana-registries@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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, 17 Dec 2013 01:25:30 -0000 yes/support Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, December 16, 2013 8:33 AM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-moving-iana-registries@tool= s.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-= registries-00 This working group last call ends in two days. However, to this point we ha= ve only one reply (from Andy Malis -- thanks Andy).=20 Please review the document and respond. If you think that the document is f= ine a simple "support" is sufficient, but the document cannot progress unle= ss there is some WG support.=20 Thanks, Ross PS: If you think that you have already replied and you are not Andy, then l= et me know and include "draft-ietf-mpls-moving-iana-registries" in the subj= ect line.=20 -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net] Sent: Tuesday, December 03, 2013 7:40 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-moving-iana-registries@tool= s.ietf.org Subject: working group last call on draft-ietf-mpls-moving-iana-registries-= 00 Working Group; =20 This is to start a two week working group last call on draft-ietf-mpls-movi= ng-iana-registries-00.txt. Please send your comment to the working group mailing list (mpls@ietf.org). We did an IPR poll on this document in September. The authors each responde= d to the IPR poll that they not aware of any IPR relating to this document.= There are no IPRs disclosed against this document. The working group last call will end Wednesday December 18, 2013. Ross (as mpls wg co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From bill.wu@huawei.com Mon Dec 16 17:25:46 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 0C0F91AE008 for ; Mon, 16 Dec 2013 17:25:46 -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 14p4VvOMnKBa for ; Mon, 16 Dec 2013 17:25:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE661AE00B for ; Mon, 16 Dec 2013 17:25: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 AZB76243; Tue, 17 Dec 2013 01:25:35 +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, 17 Dec 2013 01:25:08 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 01:25:34 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 09:25:31 +0800 From: Qin Wu To: Ross Callon , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO8Ilsdxvw6W4DfkSXFkfIGRLzvppXFviQgACTFUA= Date: Tue, 17 Dec 2013 01:25:30 +0000 Message-ID: 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.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-moving-iana-registries@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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, 17 Dec 2013 01:25:46 -0000 Hi,all: I have read draft-ietf-mpls-moving-iana-registries-00. One comment I have is section 2.3, last bullet said: " All the sub-registries are moved from "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The IANA is therefore requested to remove this registry. " It looks this paragraph are also applied to sub-registries in the PWE Regis= try although this paragraph only left aligns with MPLS OAM Registry bullet. To avoid confusion, I suggest the following change " Note that all the sub-registries in [IANA-MPLS-OAM] are moved from "Multipr= otocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The IANA is therefore requested to remove this registry. " Then this paragraph can left align with the first paragraph in the section = 2.3. Besides this, I think this draft is ready to go for publication. =20 Regards! -Qin -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Tuesday, December 17, 2013 12:33 AM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-moving-iana-registries@tool= s.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-= registries-00 This working group last call ends in two days. However, to this point we ha= ve only one reply (from Andy Malis -- thanks Andy).=20 Please review the document and respond. If you think that the document is f= ine a simple "support" is sufficient, but the document cannot progress unle= ss there is some WG support.=20 Thanks, Ross PS: If you think that you have already replied and you are not Andy, then l= et me know and include "draft-ietf-mpls-moving-iana-registries" in the subj= ect line.=20 -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Tuesday, December 03, 2013 7:40 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-moving-iana-registries@tool= s.ietf.org Subject: working group last call on draft-ietf-mpls-moving-iana-registries-= 00 Working Group; =20 This is to start a two week working group last call on draft-ietf-mpls-moving-iana-registries-00.txt. Please send your comment to the working group mailing list (mpls@ietf.org). We did an IPR poll on this document in September. The authors each responde= d to the=20 IPR poll that they not aware of any IPR relating to this document. There ar= e no IPRs=20 disclosed against this document. The working group last call will end Wednesday December 18, 2013. Ross (as mpls wg co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Mon Dec 16 18:13:18 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 87F4F1AE00A; Mon, 16 Dec 2013 18:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_RHS_DOB=1.514] 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 MzFBJDXxfQOT; Mon, 16 Dec 2013 18:13:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 718421ADFD3; Mon, 16 Dec 2013 18:13: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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131217021317.4125.78627.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2013 18:13:17 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-akiya-mpls-entropy-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: Tue, 17 Dec 2013 02:13: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 : Label Switched Path (LSP) Ping/Trace over MPLS Network u= sing Entropy Labels (EL) Author(s) : Nobo Akiya George Swallow Carlos Pignataro Filename : draft-akiya-mpls-entropy-lsp-ping-01.txt Pages : 17 Date : 2013-12-16 Abstract: The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute are used to exercise specific paths of Equal Cost Multipath (ECMP). When LSP is signaled to use Entropy Label (EL) described in RFC6790, the ability for LSP Ping and Traceroute operation to discover and exercise ECMP paths has been lost in scenarios which LSRs apply deviating load balance techniques. One such scenario is when some LSRs apply EL based load balancing while other LSRs apply non-EL based load balancing (ex: IP). Another scenario is when EL based LSP is stitched with another LSP which can be EL based or non-EL based. This document extends the MPLS LSP Ping and Traceroute mechanisms to restore the ability of exercising specific paths of ECMP over LSP which make use of Entropy Label. This document updates RFC4379 and RFC6790. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-akiya-mpls-entropy-lsp-ping There's also a htmlized version available at: http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-ping-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-entropy-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 nobo@cisco.com Mon Dec 16 18:16:20 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 D099A1ADF95 for ; Mon, 16 Dec 2013 18:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.525 X-Spam-Level: X-Spam-Status: No, score=-8.525 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, URIBL_RHS_DOB=1.514, 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 AqNh8bQnhl3e for ; Mon, 16 Dec 2013 18:16:19 -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 ED9391ADEB4 for ; Mon, 16 Dec 2013 18:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1209; q=dns/txt; s=iport; t=1387246578; x=1388456178; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=D5eOs8018nZbBGNi3DbW8LHtQPYi0+6jdB6HWp8odqw=; b=JgECVkfAs1/uGNu9o6plVfLwfW9PHkBPAWXux9Q9DztBntGNE4KU6et+ 6l1W4qu5oLWsY+Pm5dGPf3Q4FoRPPorLpWkCqSl0uJaSkCthqa7AxGAZ7 BUThGaiTxGVBuYxG/URLbpmJwMORvC/FLXCg/gzvYPvkcYXGJxnNCMzB+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFAGizr1KtJV2Z/2dsb2JhbABZgmkhOE8GuFyBIRZ0giUBAQEEOjEaAgICAQgRBAEBCxQJBxsXFAkIAgQBEggBh3sBBwXIPBcEjjMRAR84BoMdgRMEmUaQZIMqgXE5 X-IronPort-AV: E=Sophos;i="4.95,498,1384300800"; d="scan'208";a="7224259" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 17 Dec 2013 02:16:17 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBH2GHq7027431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Dec 2013 02:16:17 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 20:16:17 -0600 From: "Nobo Akiya (nobo)" To: Loa Andersson , "draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: review of draft-akiya-mpls-entropy-lsp-ping Thread-Index: AQHO1r2Br+uxl4CPTkKKg3piP/TqB5pX7iSw Date: Tue, 17 Dec 2013 02:16:17 +0000 Message-ID: References: <52733261.9070208@pi.nu> In-Reply-To: <52733261.9070208@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] review of 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: Tue, 17 Dec 2013 02:16:21 -0000 Hi Loa, Again, thank you for many useful comments. We have addressed them and poste= d -01. URL: http://www.ietf.org/internet-drafts/draft-akiya-mpls-entro= py-lsp-ping-01.txt Status: http://datatracker.ietf.org/doc/draft-akiya-mpls-entropy-l= sp-ping Htmlized: http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-pi= ng-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-entrop= y-lsp-ping-01 -Nobo > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Friday, November 01, 2013 12:47 AM > To: draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org; mpls- > chairs@tools.ietf.org; mpls@ietf.org > Subject: review of draft-akiya-mpls-entropy-lsp-ping >=20 > Authors, >=20 > I've reviewed you draft (draft-akiya-mpls-entropy-lsp-ping) there are som= e > comments but in general I thin this should be progressed. >=20 > Please do not update until after your agenda slot in Vancouver. >=20 > /Loa > -- >=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 internet-drafts@ietf.org Mon Dec 16 18:22:20 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 7DE261AE021; Mon, 16 Dec 2013 18:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_RHS_DOB=1.514] 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 fXQ7O4GrRQjc; Mon, 16 Dec 2013 18:22:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEC61ADEB4; Mon, 16 Dec 2013 18:22:19 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131217022219.17786.79985.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2013 18:22:19 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-reply-mode-simple-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: Tue, 17 Dec 2013 02:22:20 -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 Switched Path (LSP) Ping/Trace Reply Mode Simplifi= cation Author(s) : Nobo Akiya George Swallow Carlos Pignataro Loa Andersson Mach(Guoyi) Chen Filename : draft-akiya-mpls-lsp-ping-reply-mode-simple-01.txt Pages : 8 Date : 2013-12-16 Abstract: This document adds one reply mode to indicate reverse LSP, to be used by Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute. This document also adds an optional TLV which can carry ordered list of reply modes. This document updates [RFC4379]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-reply-mode-simple There's also a htmlized version available at: http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-lsp-ping-reply-mode-sim= ple-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 nobo@cisco.com Mon Dec 16 18:28:50 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 2282D1ADFEC for ; Mon, 16 Dec 2013 18:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.525 X-Spam-Level: X-Spam-Status: No, score=-8.525 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, URIBL_RHS_DOB=1.514, 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 mvd5aeVo9yFi for ; Mon, 16 Dec 2013 18:28:45 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 45FE81ADFD3 for ; Mon, 16 Dec 2013 18:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=850; q=dns/txt; s=iport; t=1387247324; x=1388456924; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=M/It/fWWkY0uPnglBnvzQunlY+Al5+47e4RSwtRa3X8=; b=TdljB2uqqVIfGIW4jbykFmzSPrqfqeiPL5J36sH+CqYquXgxaBab1LD0 Gyyi1EWw6h0PUch7hBsJAaaYkG5ByburTUBaUTvduOMez/wq3zgqdAoxZ xY4dE9RrPVWWNYwNnzJMAmeSaAwUHOjgTEvRD2lbvmC4tZZkjuSlAeqfx Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAH+1r1KtJXHB/2dsb2JhbABZgmkhOFW4XIEhFnSCJgEBBDo/EAIBCCIUEDIlAQEEAQ0NAYd7AQzIPheOaDEHgyOBEwEDlDOFE5BkgyqCKg X-IronPort-AV: E=Sophos;i="4.95,498,1384300800"; d="scan'208";a="7230265" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-4.cisco.com with ESMTP; 17 Dec 2013 02:28:44 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBH2SiiT012037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Dec 2013 02:28:44 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 20:28:43 -0600 From: "Nobo Akiya (nobo)" To: Sam Aldrin , Curtis Villamizar , "Gregory Mirsky (gregory.mirsky@ericsson.com)" Thread-Topic: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac7bjm3cTBhLnI0pTpa7M681uYyPWwAjKsEAAAxJ8oD//6wQgIAAVouw/8L+pjA= Date: Tue, 17 Dec 2013 02:28:43 +0000 Message-ID: References: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> <84A5DEF5-8FFB-4F04-BCEC-A8EEBD05A3BA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Dec 2013 02:28:50 -0000 Hi Sam, Curtis, Greg, Thank you for your comments at IETF88, in particular about: - Transition plan - Deviating operational preference in Reply Mode order - Error cases for "Reply Mode Order TLV" These points have been updated in -01. In summary, we have decided to remove " Reply via pre-defined preference" R= eply Mode, and to allow the "Reply Mode Order TLV" to be used with any Repl= y Mode value in echo request. URL: http://www.ietf.org/internet-drafts/draft-akiya-mpls-lsp-p= ing-reply-mode-simple-01.txt Status: http://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-= reply-mode-simple Htmlized: http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply= -mode-simple-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-lsp-pi= ng-reply-mode-simple-01 -Nobo From huaimo.chen@huawei.com Mon Dec 16 19:56:02 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 A431C1AE0BE for ; Mon, 16 Dec 2013 19:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 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, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OdSKRTa-UZQ for ; Mon, 16 Dec 2013 19:55:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B51E81AE0BD for ; Mon, 16 Dec 2013 19:55:57 -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 AZB84878; Tue, 17 Dec 2013 03:55:56 +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; Tue, 17 Dec 2013 03:55:30 +0000 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 03:55:55 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.165]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Mon, 16 Dec 2013 19:55:47 -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/BU63IW10jjHvHppWOpUAgACbxPA= Date: Tue, 17 Dec 2013 03:55:47 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C20383@sjceml501-mbs.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.50] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C20383sjceml501mbschi_" 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: Tue, 17 Dec 2013 03:56:02 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C20383sjceml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_5316A0AB3C851246A7CA5758973207D445C20383sjceml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tarek,

 <= /p>

Thank you very 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: 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-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.

 <= /p>

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

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?<= /span>

 <= /p>

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?<= o:p>

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,<= /p>

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_5316A0AB3C851246A7CA5758973207D445C20383sjceml501mbschi_-- From yshen@juniper.net Tue Dec 17 08: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 BE66B1AE14F for ; Tue, 17 Dec 2013 08:54:16 -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 6Jkm7ACkUz91 for ; Tue, 17 Dec 2013 08:54:13 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1C54A1AE02D for ; Tue, 17 Dec 2013 08:54:12 -0800 (PST) Received: from mail10-va3-R.bigfish.com (10.7.14.229) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Dec 2013 16:54:11 +0000 Received: from mail10-va3 (localhost [127.0.0.1]) by mail10-va3-R.bigfish.com (Postfix) with ESMTP id 3DAE21A00A0; Tue, 17 Dec 2013 16:54:11 +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: -21 X-BigFish: VPS-21(zz9371Ic85fhec9I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail10-va3: 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)(189002)(199002)(37854004)(164054003)(377454003)(18717965001)(15202345003)(83322001)(56816005)(47736001)(49866001)(76796001)(76786001)(83072002)(76576001)(4396001)(50986001)(74316001)(47976001)(19580405001)(90146001)(19580395003)(74502001)(74662001)(31966008)(81686001)(74366001)(85852003)(16236675002)(47446002)(81816001)(69226001)(74876001)(74706001)(19300405004)(80976001)(33646001)(19609705001)(15975445006)(54356001)(53806001)(76482001)(46102001)(51856001)(85306002)(2656002)(87936001)(81342001)(56776001)(80022001)(65816001)(63696002)(66066001)(81542001)(87266001)(59766001)(79102001)(77982001)(54316002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB711; H:BY2PR05MB728.namprd05.prod.outlook.com; CLIP:66.129.241.17; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail10-va3 (localhost.localdomain [127.0.0.1]) by mail10-va3 (MessageSwitch) id 1387299249249311_13789; Tue, 17 Dec 2013 16:54:09 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.226]) by mail10-va3.bigfish.com (Postfix) with ESMTP id 2DC333800F2; Tue, 17 Dec 2013 16:54:09 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 17 Dec 2013 16:54:09 +0000 Received: from BY2PR05MB711.namprd05.prod.outlook.com (10.141.222.149) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Tue, 17 Dec 2013 16:54:08 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB711.namprd05.prod.outlook.com (10.141.222.149) with Microsoft SMTP Server (TLS) id 15.0.837.10; Tue, 17 Dec 2013 16:54:07 +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.0837.004; Tue, 17 Dec 2013 16:54:06 +0000 From: Yimin Shen To: Huaimo Chen , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHO9zz2D8OUboE/BU63IW10jjHvHppYmeWw Date: Tue, 17 Dec 2013 16:54:05 +0000 Message-ID: <3e2e8b8ddcb54bfc9f1de747bc51efa1@BY2PR05MB728.namprd05.prod.outlook.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.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.17] x-forefront-prvs: 006339698F Content-Type: multipart/alternative; boundary="_000_3e2e8b8ddcb54bfc9f1de747bc51efa1BY2PR05MB728namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Raveendra Torvi 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: Tue, 17 Dec 2013 16:54:17 -0000 --_000_3e2e8b8ddcb54bfc9f1de747bc51efa1BY2PR05MB728namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, In the traditional RSVP FRR (RFC 4090), an ingress router requests link pro= tection, node protection and/or bandwidth protection by setting some flags = in the Path message, and it's the decision of a transit router whether to a= ctually set up FRR, based on its capability, local policy and local topolog= y. In this draft, the model seems completely ingress-driven. The ingress not o= nly requests FRR, but also pushes an explicit bypass route to the PLR to fo= rce to set it up. So I have a doubt whether this is always desirable and po= ssible? IMO, we may not assume that the ingress router can always have the= visibility of the topology of entire network (including the location of pr= otected node, PLR and protector) and the knowledge of local policies of eac= h PLR. For example, there are cases where a P2MP LSP needs to traverse mult= iple domains, some kind of topology abstraction/hiding is required between = domains, and loose hop expansion has to be performed at domain boundaries. Thanks, /Yimin From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Huaimo Chen Sent: Thursday, December 12, 2013 8:21 AM To: mpls@ietf.org Cc: Raveendra Torvi Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n 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_3e2e8b8ddcb54bfc9f1de747bc51efa1BY2PR05MB728namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

 <= /p>

In the traditional RSVP F= RR (RFC 4090), an ingress router requests link protection, node protection = and/or bandwidth protection by setting some flags in the Path message, and it’s the decision of a transit router whether to a= ctually set up FRR, based on its capability, local policy and local topolog= y.

 <= /p>

In this draft, the model = seems completely ingress-driven. The ingress not only requests FRR, but als= o pushes an explicit bypass route to the PLR to force to set it up. So I have a doubt whether this is always desirable and possible= ? IMO, we may not assume that the ingress router can always  have the = visibility of the topology of entire network (including the location of pro= tected node, PLR and protector) and the knowledge of local policies of each PLR. For example, there are cases wher= e a P2MP LSP needs to traverse multiple domains, some kind of topology abst= raction/hiding is required between domains, and loose hop expansion has to = be performed at domain boundaries.

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Huaimo Chen
Sent: Thursday, December 12, 2013 8:21 AM
To: mpls@ietf.org
Cc: Raveendra Torvi
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

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 fro= m some of the reviewers that they are comfortable with how the comments have been addressed. We would like t= o have the same response from the other two reviewers.

 

Best Regards,

Huaimo<= /p>

--_000_3e2e8b8ddcb54bfc9f1de747bc51efa1BY2PR05MB728namprd05pro_-- From gregory.mirsky@ericsson.com Tue Dec 17 09:11:31 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 15E381AE041 for ; Tue, 17 Dec 2013 09:11: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, 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 YIspmnoicijx for ; Tue, 17 Dec 2013 09:11:29 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 020B31AE028 for ; Tue, 17 Dec 2013 09:11:28 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-04-52b085bc622f Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 12.B9.23183.CB580B25; Tue, 17 Dec 2013 18:11:25 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0347.000; Tue, 17 Dec 2013 12:11:14 -0500 From: Gregory Mirsky To: "mpls@ietf.org" Thread-Topic: Note on p2mp ingress and egress protection proposals Thread-Index: Ac77SQgjFiRx71WkT86cjtgOzPNpQw== Date: Tue, 17 Dec 2013 17:11:13 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B73C6B8@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: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B73C6B8eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyuXRPrO7e1g1BBm/WsVjcWrqS1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGZc+LWcsuC9bsWjdedYGxneSXYycHBICJhITz7ewQ9hiEhfu rWfrYuTiEBI4wiix8coDdghnOaPE/cPzwKrYBIwkXmzsAbNFBJQljkzsZgWxhQVsJW7sWMYE EXeSWHbqGRuErSdx7sYkFhCbRUBVYunxXWA1vAK+EscfdIH1MgJt/n5qDVicWUBc4taT+UwQ FwlILNlznhnCFpV4+fgfK4StLPF9ziMWiPp8iab1t9khZgpKnJz5hGUCo9AsJKNmISmbhaQM Iq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLYxAgM/WMSbLo7GPe8tDzE KM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxl6m7ywm/ssiTevjV01okllk olDBz/eyekprJqee3+KQXbPclj7VfiuyrFno+JkPfOFCG9t4/i1f5nNy7cLtrC+DLkz7GP36 53bZOEsO8Y8HjhQKp7VPMKm6sqL+u2jTtOrYVzmTbOsuJkwKaej4aHkyZaLjK9+Td4TFc38X rS5a/fi+m6pztBJLcUaioRZzUXEiAPf2QZNLAgAA Subject: [mpls] Note on p2mp ingress and egress protection proposals X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Dec 2013 17:11:31 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B73C6B8eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I've been following these proposals for a quite some time and actively part= icipated in the discussion with authors. I do believe that both scenarios r= epresent use of redundancy and hence explicit coordination of Active/Standb= y roles is required. That certainly would simplify OAM for both cases. And = I believe that ICCP is good candidate for coordination within Redundancy Gr= oup. Though it would hardly be "fast protection" then. Hence I believe that all pieces needed to address both scenarios already ex= ist and Informational documents may be needed if anything at all. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B73C6B8eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

I’ve been following these proposals for a quit= e some time and actively participated in the discussion with authors. I do = believe that both scenarios represent use of redundancy and hence explicit = coordination of Active/Standby roles is required. That certainly would simplify OAM for both cases. And I believe = that ICCP is good candidate for coordination within Redundancy Group. Thoug= h it would hardly be “fast protection” then.

Hence I believe that all pieces needed to address bo= th scenarios already exist and Informational documents may be needed if any= thing at all.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B73C6B8eusaamb103erics_-- From akatlas@gmail.com Tue Dec 17 09:20:23 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 4E7831AE092 for ; Tue, 17 Dec 2013 09:20:23 -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 paccov-5uY-G for ; Tue, 17 Dec 2013 09:20:20 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 520AF1AE1F6 for ; Tue, 17 Dec 2013 09:20:20 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id k19so6857164igc.3 for ; Tue, 17 Dec 2013 09:20: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=f9tnk6SJOXqKeUB+hqcdNkozsSCIEUZKpueCcFsVovw=; b=ToRwDaI6ucwqmK5YaPy2ZdFWPvp6KaHfAAJBN+rSywOByAesnXGTYLVo86TwxMNZ/t h/KFnYDcrW0+vvs+gd1h5ID0MUDODTQWLFJZBg/l2NPGHkEjSL6AD6sUg3CA7987SlJv fLK8EiGC+6NQ22IaWehWih2mccQQr+kV8r1CX/deUYAResqdUkLdaG3aPb+nLuTNeNF9 No+LeW6hhXMDfz8piGE2Vxa+jdyarA2r/AHHLuqR6alcX4fv4XXByUx47Ez3lsz1u+Tf uTiFgnqfCEv0+jGoWxE3bVPEUmFpKvKWWSwD6yeeSAV5lRCZn+LKXAo0G27teLZDO5Uy bXwg== MIME-Version: 1.0 X-Received: by 10.50.40.102 with SMTP id w6mr4317389igk.20.1387300819101; Tue, 17 Dec 2013 09:20:19 -0800 (PST) Received: by 10.64.78.103 with HTTP; Tue, 17 Dec 2013 09:20:19 -0800 (PST) In-Reply-To: References: <5316A0AB3C851246A7CA5758973207D445C200A7@sjceml501-mbs.china.huawei.com> Date: Tue, 17 Dec 2013 12:20:19 -0500 Message-ID: From: Alia Atlas To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=089e0112c7fe85258e04edbe24df Cc: "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Comment 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, 17 Dec 2013 17:20:23 -0000 --089e0112c7fe85258e04edbe24df Content-Type: text/plain; charset=ISO-8859-1 Hi Nobo, Here's a quick summary response (which is why I am top-posting). Yes, it is hard to correctly determine precisely what failure has occurred. Doing so depends on the network topology, whether the CE can run BFD and so on. The set of how to determine the failure is large and NOT specified in this draft. What is specified in this draft are different "failure-detection modes" which need to be signaled so that the Backup Ingress and Merge Points know what it needs to do. Each different mode is intended to address a different scenario. Remember that what matters is whether traffic continues to flow and whether the repair might result in duplicate traffic. For instance, if the CE determines that it can't send traffic to the Ingress - then traffic won't flow - and the CE can send the traffic to the Backup Ingress. This is the source-detected mode. Regards, Alia On Mon, Dec 16, 2013 at 6:01 PM, Nobo Akiya (nobo) wrote: > Hi Huaimo, > > Thanks for response! > > The fundamental thing is, node failure will fail relevant BFD in your > proposal, but BFD failure may not mean node failure. > > Please see comments inline. > > > -----Original Message----- > > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > > Sent: Sunday, December 15, 2013 9:01 PM > > To: Nobo Akiya (nobo); draft-chen-mpls-p2mp-ingress- > > protection@tools.ietf.org > > Cc: mpls@ietf.org > > Subject: RE: Comment on draft-chen-mpls-p2mp-ingress-protection > > > > Hi Nobo, > > > > Thanks for your comments! > > See my answers/explanations inline below. > > > > Best Regards, > > Huaimo > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Nobo Akiya (nobo) > > Sent: Thursday, November 07, 2013 2:51 AM > > To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org > > Cc: mpls@ietf.org > > Subject: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protection > > > > Hi Authors, > > > > I didn't get a chance to comment on your draft at the WG session today, > so > > sending to the list. My concern is similar to what Greg Mirsky stated. > > Simply running 2 independent BFD sessions (as described in the slides) > will > > have issues. > > > > Huaimo: In normal operations, source CE sends the traffic to the primary > > ingress, which imports the traffic into the primary LSP. It does not > send the > > traffic to the backup ingress. > > When the primary ingress fails, the source CE will detect the failure of > the > > primary ingress through the BFD between CE and the primary ingress and > > switches the traffic to the backup ingress. The backup ingress will also > > detect the failure of the primary ingress through the BFD between the > > backup ingress and the primary ingress, and put the traffic from the > source > > CE into the backup LSP to the next hops of the primary ingress, where the > > traffic is merged into the primary LSP. > > When the link between the backup ingress and the primary ingress fails, > the > > source CE will continue to send the traffic to the primary ingress, and > does > > not send the traffic to the backup ingress. The traffic will be > delivered to the > > destinations via the primary LSP. > > It seems that it works as expected. > > Can you give more details about "Simply running 2 independent BFD > > sessions (as described in the slides) will have issues."? > > One example would be the case where BFD between CE and primary ingress > fails but not BFD between primary ingress and backup ingress. Section 3.1 > says: > > [snip] > The backup ingress does not import any traffic from the source into > the backup LSP in normal operations. When it detects a failure > involving the primary ingress, it imports the traffic from the source > into the backup LSP to the next hops of the primary ingress, where > the traffic is merged into the primary LSP. > [snip] > > In this case, CE will be sending traffic to backup ingress, but backup > ingress isn't sending the traffic into backup LSP, since BFD from backup > ingress to primary ingress is still up. Because proposal [currently] > requires synchronized decision made by multiple devices making independent > decisions, this is an area which should require further attention. > > The detection which this proposal is really interested in is failures in > following paths: > CE --> primary ingress --> primary LSP --> in-band at least to nexthop > Running multiple single-hop BFD doesn't accurately achieve this. > > For the backup activation, you probably want to have one failure > detection, or one node making the decision based on multiple failure > detections ... ideally. > > > > > > > > 3. Ingress Failure Detection > > > > > > Exactly how the failure of the ingress (e.g. R1 in Figure 1) is > > > detected is out of scope for this document. > > > > I believe, at least, definition of the "failure" should be defined in > the draft. > > Without it, it can be interpreted by readers as complete node outage, > > outage of all involved links, outage of just primary-backup link, or even > > something else. And without defining what the "failure" is, it's > difficult to > > figure out the right techniques to detect the failure. And that can > easily > > result in deviating detection implementations for described solution to > not > > kick off in expected manner. > > > > Huaimo: The primary ingress node failure in this draft is similar to the > node > > failure in RFC 4090. > > For non-ingress-protection, failure of a downstream from upstream > perspective is clear: there is no need to differentiate between link > failure and node failure. What is proposed in the document is a detection > mechanism where (link failure & node alive) scenario can create > inconsistent backup takeover. In addition, because you have multiple > "detector" nodes, failure of a single-hop BFD cannot be assumed as a node > failure. It can just be a link failure, or LC failure of one node which > doesn't impact any corresponding traffic. I think you can see from above > that there's a bit of difference between the "failure" which you want > backup activated vs. "failure" which proposed detection mechanism detects. > This is why I think it'll be beneficial to define what the "failure" is. > > -Nobo > > > > > -Nobo > > > > _______________________________________________ > > 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 > --089e0112c7fe85258e04edbe24df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Nobo,

Here's a quick summary res= ponse (which is why I am top-posting).

Yes, it is = hard to correctly determine precisely what failure has occurred. =A0Doing s= o depends on the network topology, whether the CE can run BFD and so on. = =A0The set of how to determine the failure is large and NOT specified in th= is draft.

What is specified in this draft are different "fai= lure-detection modes" which need to be signaled so that the Backup Ing= ress and Merge Points know what it needs to do. =A0Each different mode is i= ntended to address a different scenario. =A0Remember that what matters is w= hether traffic continues to flow and whether the repair might result in dup= licate traffic.

For instance, if the CE determines that it can't se= nd traffic to the Ingress - then traffic won't flow - and the CE can se= nd the traffic to the Backup Ingress. =A0This is the source-detected mode.<= /div>

Regards,
Alia


On Mon, Dec 16, 2013 at 6:01 PM, = Nobo Akiya (nobo) <nobo@cisco.com> wrote:
Hi Huaimo,

Thanks for response!

The fundamental thing is, node failure will fail relevant BFD in your propo= sal, but BFD failure may not mean node failure.

Please see comments inline.

> -----Original Message-----
> From: Huaimo Chen [mailto:hu= aimo.chen@huawei.com]
> Sent: Sunday, December 15, 2013 9:01 PM
> To: Nobo Akiya (nobo); draft-chen-mpls-p2mp-ingress-
> protection@tools.ietf.org=
> Cc: mpls@ietf.org
> Subject: RE: Comment on draft-chen-mpls-p2mp-ingress-protection
>
> Hi Nobo,
>
> =A0 =A0 Thanks for your comments!
> =A0 =A0 See my answers/explanations inline below.
>
> Best Regards,
> Huaimo
>
> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Nobo Akiya (nobo)
> Sent: Thursday, November 07, 2013 2:51 AM
> To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org
> Cc: mpls@ietf.org
> Subject: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protection
>
> Hi Authors,
>
> I didn't get a chance to comment on your draft at the WG session t= oday, so
> sending to the list. My concern is similar to what Greg Mirsky stated.=
> Simply running 2 independent BFD sessions (as described in the slides)= will
> have issues.
>
> Huaimo: In normal operations, source CE sends the traffic to the prima= ry
> ingress, which imports the traffic into the primary LSP. It does not s= end the
> traffic to the backup ingress.
> When the primary ingress fails, the source CE will detect the failure = of the
> primary ingress through the BFD between CE and the primary ingress and=
> switches the traffic to the backup ingress. The backup ingress will al= so
> detect the failure of the primary ingress through the BFD between the<= br> > backup ingress and the primary ingress, and put the traffic from the s= ource
> CE into the backup LSP to the next hops of the primary ingress, where = the
> traffic is merged into the primary LSP.
> When the link between the backup ingress and the primary ingress fails= , the
> source CE will continue to send the traffic to the primary ingress, an= d does
> not send the traffic to the backup ingress. The traffic will be delive= red to the
> destinations via the primary LSP.
> It seems that it works as expected.
> Can you give more details about "Simply running 2 independent BFD=
> sessions (as described in the slides) will have issues."?

One example would be the case where BFD between CE and primary = ingress fails but not BFD between primary ingress and backup ingress. Secti= on 3.1 says:

[snip]
=A0 =A0The backup ingress does not import any traffic from the source into<= br> =A0 =A0the backup LSP in normal operations. =A0When it detects a failure =A0 =A0involving the primary ingress, it imports the traffic from the sourc= e
=A0 =A0into the backup LSP to the next hops of the primar= y ingress, where
=A0 =A0the traffic is merged into the primary LSP.
[snip]

In this case, CE will be sending traffic to backup ingress, but backup ingr= ess isn't sending the traffic into backup LSP, since BFD from backup in= gress to primary ingress is still up. Because proposal [currently] requires= synchronized decision made by multiple devices making independent decision= s, this is an area which should require further attention.

The detection which this proposal is really interested in is failures in fo= llowing paths:
CE --> primary ingress --> primary LSP --> in-band at least to nex= thop
Running multiple single-hop BFD doesn't accurately achieve this.

For the backup activation, you probably want to have one failure detection,= or one node making the decision based on multiple failure detections ... i= deally.

>
>
> > 3. =A0Ingress Failure Detection
> >
> > =A0 Exactly how the failure of the ingress (e.g. =A0R1 in Figure = 1) is
> > =A0 detected is out of scope for this document.
>
> I believe, at least, definition of the "failure" should be d= efined in the draft.
> Without it, it can be interpreted by readers as complete node outage,<= br> > outage of all involved links, outage of just primary-backup link, or e= ven
> something else. And without defining what the "failure" is, = it's difficult to
> figure out the right techniques to detect the failure. And that can ea= sily
> result in deviating detection implementations for described solution t= o not
> kick off in expected manner.
>
> Huaimo: The primary ingress node failure in this draft is similar to t= he node
> failure in RFC 4090.

For non-ingress-protection, failure of a downstream from upstream per= spective is clear: there is no need to differentiate between link failure a= nd node failure. What is proposed in the document is a detection mechanism = where (link failure & node alive) scenario can create inconsistent back= up takeover. In addition, because you have multiple "detector" no= des, failure of a single-hop BFD cannot be assumed as a node failure. It ca= n just be a link failure, or LC failure of one node which doesn't impac= t any corresponding traffic. I think you can see from above that there'= s a bit of difference between the "failure" which you want backup= activated vs. "failure" which proposed detection mechanism detec= ts. This is why I think it'll be beneficial to define what the "fa= ilure" is.

-Nobo

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

--089e0112c7fe85258e04edbe24df-- From cpignata@cisco.com Tue Dec 17 11:54:57 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 7E8E01AE30E for ; Tue, 17 Dec 2013 11:54:57 -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 1AzNLCMndqef for ; Tue, 17 Dec 2013 11:54:56 -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 DEFDE1AE305 for ; Tue, 17 Dec 2013 11:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4256; q=dns/txt; s=iport; t=1387310095; x=1388519695; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0xZxPEThdiJcK3JRcVWFnOCIy/4ts4FTuWUt3QyHIO4=; b=bLhTaa5LvjehQ0ms3Zy1UvwZ5rKJGBdSk7K+dFOLsgnpwaZe/byIfvyy Oj53VQw5ikRR+P2mqTuT9BGaS4NjOtwQScY38bOkwkHwcQ245z4AgRPLb ayfvT+Buprsi1CcIWHeY+PAsjA/RGM4Rsja/Qa3SFi0Tct552vEJ9CeTr o=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAFqrsFKtJXG8/2dsb2JhbABZgwo4VbhpgSAWdIIlAQEBAwEBAQFrCwUHBAIBCA4DBAEBKAcnCxQJCAIEDgUOh24IDclcEwSPEgcGgx2BEwSQM4ExhjKSFIMrgio X-IronPort-AV: E=Sophos;i="4.95,502,1384300800"; d="asc'?scan'208";a="292151222" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 17 Dec 2013 19:54:54 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBHJss1h006990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Dec 2013 19:54:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 17 Dec 2013 13:54:53 -0600 From: "Carlos Pignataro (cpignata)" To: Qin Wu Thread-Topic: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO8Ilsdxvw6W4DfkSXFkfIGRLzvppXFviQgACTFUCAAZ0pgA== Date: Tue, 17 Dec 2013 19:54:53 +0000 Message-ID: <730EA08E-61FB-446B-A6C3-35B19EDDD132@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.131.24.230] Content-Type: multipart/signed; boundary="Apple-Mail=_7F5A3844-A055-4F65-ABF4-07821FC670BE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-moving-iana-registries@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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, 17 Dec 2013 19:54:57 -0000 --Apple-Mail=_7F5A3844-A055-4F65-ABF4-07821FC670BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Qin, Thanks -- that is a fair comment. I'd suggest also to add one more = thing: 'Note that all the sub-registries in [IANA-MPLS-OAM] are moved from = "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The IANA is therefore requested to remove the "MPLS OAM" registry.' Thanks, -- Carlos. On Dec 16, 2013, at 8:25 PM, Qin Wu wrote: > Hi,all: > I have read draft-ietf-mpls-moving-iana-registries-00. > One comment I have is section 2.3, last bullet said: > " > All the sub-registries are moved from "Multiprotocol Label > Switching (MPLS) Operations, Administration, and Management (OAM) > Parameters" registry. The IANA is therefore requested to remove > this registry. >=20 > " > It looks this paragraph are also applied to sub-registries in the PWE = Registry although > this paragraph only left aligns with MPLS OAM Registry bullet. >=20 > To avoid confusion, I suggest the following change > " > Note that all the sub-registries in [IANA-MPLS-OAM] are moved from = "Multiprotocol Label > Switching (MPLS) Operations, Administration, and Management (OAM) > Parameters" registry. The IANA is therefore requested to remove > this registry. >=20 > " > Then this paragraph can left align with the first paragraph in the = section 2.3. >=20 > Besides this, I think this draft is ready to go for publication. >=20 > Regards! > -Qin > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: Tuesday, December 17, 2013 12:33 AM > To: Ross Callon; mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-moving-iana-registries@tools.ietf.org > Subject: Re: [mpls] working group last call on = draft-ietf-mpls-moving-iana-registries-00 >=20 > This working group last call ends in two days. However, to this point = we have only one reply (from Andy Malis -- thanks Andy).=20 >=20 > Please review the document and respond. If you think that the document = is fine a simple "support" is sufficient, but the document cannot = progress unless there is some WG support.=20 >=20 > Thanks, Ross >=20 > PS: If you think that you have already replied and you are not Andy, = then let me know and include "draft-ietf-mpls-moving-iana-registries" in = the subject line.=20 >=20 > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net]=20 > Sent: Tuesday, December 03, 2013 7:40 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-moving-iana-registries@tools.ietf.org > Subject: working group last call on = draft-ietf-mpls-moving-iana-registries-00 >=20 > Working Group; >=20 > This is to start a two week working group last call on > draft-ietf-mpls-moving-iana-registries-00.txt. >=20 > Please send your comment to the working group mailing list = (mpls@ietf.org). >=20 > We did an IPR poll on this document in September. The authors each = responded to the=20 > IPR poll that they not aware of any IPR relating to this document. = There are no IPRs=20 > disclosed against this document. >=20 > The working group last call will end Wednesday December 18, 2013. >=20 > Ross > (as mpls wg co-chair) >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 --Apple-Mail=_7F5A3844-A055-4F65-ABF4-07821FC670BE 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 iEYEARECAAYFAlKwrA0ACgkQtfDPGTp3USyXHwCgt/9/b3P3cBGSfrpMzEtyTAvM qpMAoIz5tik5QSVUn/ILL3h8wTcd2Z1r =5Qr9 -----END PGP SIGNATURE----- --Apple-Mail=_7F5A3844-A055-4F65-ABF4-07821FC670BE-- From internet-drafts@ietf.org Tue Dec 17 15:03:39 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 B15B01AD9AE; Tue, 17 Dec 2013 15:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB-n9z2Bi63b; Tue, 17 Dec 2013 15:03:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A331ACCE8; Tue, 17 Dec 2013 15:03:38 -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.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131217230337.5587.32596.idtracker@ietfa.amsl.com> Date: Tue, 17 Dec 2013 15:03:37 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-forwarding-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, 17 Dec 2013 23:03:39 -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 Requirements Author(s) : Curtis Villamizar Kireeti Kompella Shane Amante Andrew Malis Carlos Pignataro Filename : draft-ietf-mpls-forwarding-04.txt Pages : 52 Date : 2013-12-17 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-forwarding-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 nobo@cisco.com Tue Dec 17 16:36: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 7FA741ADF57 for ; Tue, 17 Dec 2013 16:36:16 -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 TmKQUsWHHKPs for ; Tue, 17 Dec 2013 16:36:13 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 260811ADF66 for ; Tue, 17 Dec 2013 16:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21690; q=dns/txt; s=iport; t=1387326972; x=1388536572; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rjy0bDss8rME+zPlVUL7qE8pu01cT8mNwVSMpZjBuRg=; b=gad1N1mnLqlVV7udurSLaXpQ13u0iKqYq4hG8aqQrw/hQm1jqTYo36mC o2J0EHoMUQkeNjOAIQtu9NcViC98YIs+LfIm+7WA9KKgRHby+8/arEVVN UhDwPZua01THPDO+6LK/u5snudoCPwIeuu40RDRf2jZE08CNrXq3EPYPl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAIXtsFKtJV2a/2dsb2JhbABZgkYjIThVuGyBIBZ0giUBAQEEAQEBJAZBCwwEAgEIDgMEAQELHQchBgsUCQgBAQQOBQgTh1UDEQEMwjkNhnwTBIx/gSg6LQQGAQaDHYETBJYrjkWFOoMrgWgHOw X-IronPort-AV: E=Sophos;i="4.95,504,1384300800"; d="scan'208,217";a="7491937" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 18 Dec 2013 00:36: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 rBI0aAqW003959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 00:36:10 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; Tue, 17 Dec 2013 18:36:10 -0600 From: "Nobo Akiya (nobo)" To: Alia Atlas Thread-Topic: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protection Thread-Index: Ac7bieAe3j4zI+A+Rcq0NrmUMXL15gedQ3YAACODSLAAPGR5gAABqXtw Date: Wed, 18 Dec 2013 00:36:10 +0000 Message-ID: References: <5316A0AB3C851246A7CA5758973207D445C200A7@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.86.240.148] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941DF107B8xmbalnx01ciscoc_" MIME-Version: 1.0 Cc: "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Comment 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, 18 Dec 2013 00:36:16 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941DF107B8xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alias, Thank you for summarizing the response. I agree that source-detect mode make sense. For other modes, if we want to = preserve these modes and if we want to have deterministic detection mechani= sm, as Greg Mirsky has pointed out in other thread, exploring usage of ICCP= might be a good idea. -Nobo From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Tuesday, December 17, 2013 12:20 PM To: Nobo Akiya (nobo) Cc: Huaimo Chen; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org; mp= ls@ietf.org Subject: Re: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protection Hi Nobo, Here's a quick summary response (which is why I am top-posting). Yes, it is hard to correctly determine precisely what failure has occurred.= Doing so depends on the network topology, whether the CE can run BFD and = so on. The set of how to determine the failure is large and NOT specified = in this draft. What is specified in this draft are different "failure-detection modes" whi= ch need to be signaled so that the Backup Ingress and Merge Points know wha= t it needs to do. Each different mode is intended to address a different s= cenario. Remember that what matters is whether traffic continues to flow a= nd whether the repair might result in duplicate traffic. For instance, if the CE determines that it can't send traffic to the Ingres= s - then traffic won't flow - and the CE can send the traffic to the Backup= Ingress. This is the source-detected mode. Regards, Alia On Mon, Dec 16, 2013 at 6:01 PM, Nobo Akiya (nobo) > wrote: Hi Huaimo, Thanks for response! The fundamental thing is, node failure will fail relevant BFD in your propo= sal, but BFD failure may not mean node failure. Please see comments inline. > -----Original Message----- > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > Sent: Sunday, December 15, 2013 9:01 PM > To: Nobo Akiya (nobo); draft-chen-mpls-p2mp-ingress- > protection@tools.ietf.org > Cc: mpls@ietf.org > Subject: RE: Comment on draft-chen-mpls-p2mp-ingress-protection > > Hi Nobo, > > Thanks for your comments! > See my answers/explanations inline below. > > Best Regards, > Huaimo > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bo= unces@ietf.org] On Behalf Of > Nobo Akiya (nobo) > Sent: Thursday, November 07, 2013 2:51 AM > To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org > Cc: mpls@ietf.org > Subject: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protection > > Hi Authors, > > I didn't get a chance to comment on your draft at the WG session today, s= o > sending to the list. My concern is similar to what Greg Mirsky stated. > Simply running 2 independent BFD sessions (as described in the slides) wi= ll > have issues. > > Huaimo: In normal operations, source CE sends the traffic to the primary > ingress, which imports the traffic into the primary LSP. It does not send= the > traffic to the backup ingress. > When the primary ingress fails, the source CE will detect the failure of = the > primary ingress through the BFD between CE and the primary ingress and > switches the traffic to the backup ingress. The backup ingress will also > detect the failure of the primary ingress through the BFD between the > backup ingress and the primary ingress, and put the traffic from the sour= ce > CE into the backup LSP to the next hops of the primary ingress, where the > traffic is merged into the primary LSP. > When the link between the backup ingress and the primary ingress fails, t= he > source CE will continue to send the traffic to the primary ingress, and d= oes > not send the traffic to the backup ingress. The traffic will be delivered= to the > destinations via the primary LSP. > It seems that it works as expected. > Can you give more details about "Simply running 2 independent BFD > sessions (as described in the slides) will have issues."? One example would be the case where BFD between CE and primary ingress fail= s but not BFD between primary ingress and backup ingress. Section 3.1 says: [snip] The backup ingress does not import any traffic from the source into the backup LSP in normal operations. When it detects a failure involving the primary ingress, it imports the traffic from the source into the backup LSP to the next hops of the primary ingress, where the traffic is merged into the primary LSP. [snip] In this case, CE will be sending traffic to backup ingress, but backup ingr= ess isn't sending the traffic into backup LSP, since BFD from backup ingres= s to primary ingress is still up. Because proposal [currently] requires syn= chronized decision made by multiple devices making independent decisions, t= his is an area which should require further attention. The detection which this proposal is really interested in is failures in fo= llowing paths: CE --> primary ingress --> primary LSP --> in-band at least to nexthop Running multiple single-hop BFD doesn't accurately achieve this. For the backup activation, you probably want to have one failure detection,= or one node making the decision based on multiple failure detections ... i= deally. > > > > 3. Ingress Failure Detection > > > > Exactly how the failure of the ingress (e.g. R1 in Figure 1) is > > detected is out of scope for this document. > > I believe, at least, definition of the "failure" should be defined in the= draft. > Without it, it can be interpreted by readers as complete node outage, > outage of all involved links, outage of just primary-backup link, or even > something else. And without defining what the "failure" is, it's difficul= t to > figure out the right techniques to detect the failure. And that can easil= y > result in deviating detection implementations for described solution to n= ot > kick off in expected manner. > > Huaimo: The primary ingress node failure in this draft is similar to the = node > failure in RFC 4090. For non-ingress-protection, failure of a downstream from upstream perspecti= ve is clear: there is no need to differentiate between link failure and nod= e failure. What is proposed in the document is a detection mechanism where = (link failure & node alive) scenario can create inconsistent backup takeove= r. In addition, because you have multiple "detector" nodes, failure of a si= ngle-hop BFD cannot be assumed as a node failure. It can just be a link fai= lure, or LC failure of one node which doesn't impact any corresponding traf= fic. I think you can see from above that there's a bit of difference betwee= n the "failure" which you want backup activated vs. "failure" which propose= d detection mechanism detects. This is why I think it'll be beneficial to d= efine what the "failure" is. -Nobo > > -Nobo > > _______________________________________________ > 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 --_000_CECE764681BE964CBE1DFF78F3CDD3941DF107B8xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alias,

 <= /p>

Thank you for summarizing= the response.

 <= /p>

I agree that source-detec= t mode make sense. For other modes, if we want to preserve these modes and = if we want to have deterministic detection mechanism, as Greg Mirsky has pointed out in other thread, exploring usage of ICCP might= be a good idea.

-Nobo

 <= /p>

From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: Tuesday, December 17, 2013 12:20 PM
To: Nobo Akiya (nobo)
Cc: Huaimo Chen; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.= org; mpls@ietf.org
Subject: Re: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protecti= on

 

Hi Nobo,

 

Here's a quick summary response (which is why I am t= op-posting).

 

Yes, it is hard to correctly determine precisely wha= t failure has occurred.  Doing so depends on the network topology, whe= ther the CE can run BFD and so on.  The set of how to determine the fa= ilure is large and NOT specified in this draft.

 

What is specified in this draft are different "= failure-detection modes" which need to be signaled so that the Backup = Ingress and Merge Points know what it needs to do.  Each different mod= e is intended to address a different scenario.  Remember that what matters is whether traffic continues to flow and whether the rep= air might result in duplicate traffic.

 

For instance, if the CE determines that it can't sen= d traffic to the Ingress - then traffic won't flow - and the CE can send th= e traffic to the Backup Ingress.  This is the source-detected mode.

 

Regards,

Alia

 

On Mon, Dec 16, 2013 at 6:01 PM, Nobo Akiya (nobo) &= lt;nobo@cisco.com&g= t; wrote:

Hi Huaimo,

Thanks for response!

The fundamental thing is, node failure will fail relevant BFD in your propo= sal, but BFD failure may not mean node failure.

Please see comments inline.


> -----Original Message-----
> From: Huaimo Chen [mailto:hu= aimo.chen@huawei.com]
> Sent: Sunday, December 15, 2013 9:01 PM
> To: Nobo Akiya (nobo); draft-chen-mpls-p2mp-ingress-
> protection@tools.ietf.org=
> Cc: mpls@ietf.org
> Subject: RE: Comment on draft-chen-mpls-p2mp-ingress-protection
>
> Hi Nobo,
>
>     Thanks for your comments!
>     See my answers/explanations inline below.
>
> Best Regards,
> Huaimo
>
> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Nobo Akiya (nobo)
> Sent: Thursday, November 07, 2013 2:51 AM
> To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org
> Cc: mpls@ietf.org
> Subject: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protection
>
> Hi Authors,
>
> I didn't get a chance to comment on your draft at the WG session today= , so
> sending to the list. My concern is similar to what Greg Mirsky stated.=
> Simply running 2 independent BFD sessions (as described in the slides)= will
> have issues.
>
> Huaimo: In normal operations, source CE sends the traffic to the prima= ry
> ingress, which imports the traffic into the primary LSP. It does not s= end the
> traffic to the backup ingress.
> When the primary ingress fails, the source CE will detect the failure = of the
> primary ingress through the BFD between CE and the primary ingress and=
> switches the traffic to the backup ingress. The backup ingress will al= so
> detect the failure of the primary ingress through the BFD between the<= br> > backup ingress and the primary ingress, and put the traffic from the s= ource
> CE into the backup LSP to the next hops of the primary ingress, where = the
> traffic is merged into the primary LSP.
> When the link between the backup ingress and the primary ingress fails= , the
> source CE will continue to send the traffic to the primary ingress, an= d does
> not send the traffic to the backup ingress. The traffic will be delive= red to the
> destinations via the primary LSP.
> It seems that it works as expected.
> Can you give more details about "Simply running 2 independent BFD=
> sessions (as described in the slides) will have issues."?

One example would be the case where BFD between CE a= nd primary ingress fails but not BFD between primary ingress and backup ing= ress. Section 3.1 says:

[snip]
   The backup ingress does not import any traffic from the source= into
   the backup LSP in normal operations.  When it detects a f= ailure
   involving the primary ingress, it imports the traffic from the= source

   into the backup LSP to the next hops of= the primary ingress, where
   the traffic is merged into the primary LSP.

[snip]

In this case, CE will be sending traffic to backup ingress, but backup ingr= ess isn't sending the traffic into backup LSP, since BFD from backup ingres= s to primary ingress is still up. Because proposal [currently] requires syn= chronized decision made by multiple devices making independent decisions, this is an area which should require= further attention.

The detection which this proposal is really interested in is failures in fo= llowing paths:
CE --> primary ingress --> primary LSP --> in-band at least to nex= thop
Running multiple single-hop BFD doesn't accurately achieve this.

For the backup activation, you probably want to have one failure detection,= or one node making the decision based on multiple failure detections ... i= deally.


>
>
> > 3.  Ingress Failure Detection
> >
> >   Exactly how the failure of the ingress (e.g.  R1 in F= igure 1) is
> >   detected is out of scope for this document.
>
> I believe, at least, definition of the "failure" should be d= efined in the draft.
> Without it, it can be interpreted by readers as complete node outage,<= br> > outage of all involved links, outage of just primary-backup link, or e= ven
> something else. And without defining what the "failure" is, = it's difficult to
> figure out the right techniques to detect the failure. And that can ea= sily
> result in deviating detection implementations for described solution t= o not
> kick off in expected manner.
>
> Huaimo: The primary ingress node failure in this draft is similar to t= he node
> failure in RFC 4090.

For non-ingress-protection, failure of a downstream = from upstream perspective is clear: there is no need to differentiate betwe= en link failure and node failure. What is proposed in the document is a det= ection mechanism where (link failure & node alive) scenario can create inconsistent backup takeover. In add= ition, because you have multiple "detector" nodes, failure of a s= ingle-hop BFD cannot be assumed as a node failure. It can just be a link fa= ilure, or LC failure of one node which doesn't impact any corresponding traffic. I think you can see from above that ther= e's a bit of difference between the "failure" which you want back= up activated vs. "failure" which proposed detection mechanism det= ects. This is why I think it'll be beneficial to define what the "failure" is.

-Nobo


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

 

--_000_CECE764681BE964CBE1DFF78F3CDD3941DF107B8xmbalnx01ciscoc_-- From bill.wu@huawei.com Tue Dec 17 17:11:42 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 2F9CB1AE0B0 for ; Tue, 17 Dec 2013 17:11:42 -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 sL02Jd_HQdvY for ; Tue, 17 Dec 2013 17:11:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A577D1AE14E for ; Tue, 17 Dec 2013 17:11:39 -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 BBN69465; Wed, 18 Dec 2013 01:11:37 +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, 18 Dec 2013 01:11:07 +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; Wed, 18 Dec 2013 01:11:37 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 09:11:31 +0800 From: Qin Wu To: "Carlos Pignataro (cpignata)" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO8Ilsdxvw6W4DfkSXFkfIGRLzvppXFviQgACTFUCAAZ0pgP//875Q Date: Wed, 18 Dec 2013 01:11:31 +0000 Message-ID: References: <730EA08E-61FB-446B-A6C3-35B19EDDD132@cisco.com> In-Reply-To: <730EA08E-61FB-446B-A6C3-35B19EDDD132@cisco.com> 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: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-moving-iana-registries@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-registries-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: Wed, 18 Dec 2013 01:11:42 -0000 Agree, thank for addressing my comment. Regards! -Qin -----Original Message----- From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: Wednesday, December 18, 2013 3:55 AM To: Qin Wu Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls= -moving-iana-registries@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-moving-iana-= registries-00 Qin, Thanks -- that is a fair comment. I'd suggest also to add one more thing: 'Note that all the sub-registries in [IANA-MPLS-OAM] are moved from "Multip= rotocol Label Switching (MPLS) Operations, Administration, and Management (= OAM) Parameters" registry. The IANA is therefore requested to remove the "= MPLS OAM" registry.' Thanks, -- Carlos. On Dec 16, 2013, at 8:25 PM, Qin Wu wrote: > Hi,all: > I have read draft-ietf-mpls-moving-iana-registries-00. > One comment I have is section 2.3, last bullet said: > " > All the sub-registries are moved from "Multiprotocol Label Switching=20 > (MPLS) Operations, Administration, and Management (OAM) Parameters"=20 > registry. The IANA is therefore requested to remove this registry. >=20 > " > It looks this paragraph are also applied to sub-registries in the PWE=20 > Registry although this paragraph only left aligns with MPLS OAM Registry = bullet. >=20 > To avoid confusion, I suggest the following change " > Note that all the sub-registries in [IANA-MPLS-OAM] are moved from=20 > "Multiprotocol Label Switching (MPLS) Operations, Administration, and=20 > Management (OAM) Parameters" registry. The IANA is therefore=20 > requested to remove this registry. >=20 > " > Then this paragraph can left align with the first paragraph in the sectio= n 2.3. >=20 > Besides this, I think this draft is ready to go for publication. >=20 > Regards! > -Qin > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: Tuesday, December 17, 2013 12:33 AM > To: Ross Callon; mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org;=20 > draft-ietf-mpls-moving-iana-registries@tools.ietf.org > Subject: Re: [mpls] working group last call on=20 > draft-ietf-mpls-moving-iana-registries-00 >=20 > This working group last call ends in two days. However, to this point we = have only one reply (from Andy Malis -- thanks Andy).=20 >=20 > Please review the document and respond. If you think that the document is= fine a simple "support" is sufficient, but the document cannot progress un= less there is some WG support.=20 >=20 > Thanks, Ross >=20 > PS: If you think that you have already replied and you are not Andy, then= let me know and include "draft-ietf-mpls-moving-iana-registries" in the su= bject line.=20 >=20 > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: Tuesday, December 03, 2013 7:40 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org;=20 > draft-ietf-mpls-moving-iana-registries@tools.ietf.org > Subject: working group last call on=20 > draft-ietf-mpls-moving-iana-registries-00 >=20 > Working Group; >=20 > This is to start a two week working group last call on=20 > draft-ietf-mpls-moving-iana-registries-00.txt. >=20 > Please send your comment to the working group mailing list (mpls@ietf.org= ). >=20 > We did an IPR poll on this document in September. The authors each=20 > responded to the IPR poll that they not aware of any IPR relating to=20 > this document. There are no IPRs disclosed against this document. >=20 > The working group last call will end Wednesday December 18, 2013. >=20 > Ross > (as mpls wg co-chair) >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 akatlas@gmail.com Wed Dec 18 09:17:42 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 EAE0A1AC829 for ; Wed, 18 Dec 2013 09:17:42 -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 pzGb8Rx74zPw for ; Wed, 18 Dec 2013 09:17:40 -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 BDCED1A802A for ; Wed, 18 Dec 2013 09:17:40 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so10101403ieb.8 for ; Wed, 18 Dec 2013 09:17:39 -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=s9MR2+NHmbhWX3Hmi2zNiS1VlnuW4hKrcrrxWvv2qd0=; b=Qrv+GdzUYwGG5HJ8AZZ7YPfb3/trm1ZGWchcWtAG3te+DKDsRtmL5dqZf9q/AdiSPq 00DjYW5QLLQLluwfwKwCUEtcRAmY1yMt+MF5eP6hN4tZgGvE5kl+SfcZhBLX13Mhi/cD TxHsDkPeyYnqwL79aynXFu3VrQISB/5/jQCs11SSoPUHWBnzvQ4hny6ZrNYFpIynXrvs Rmij+u2701j1z4tCSe3dxVWb10bUbI+Ek0D/lUYZBW0mZiYgahL8P1l7V+QAqFHP9ddf 4gG9rMszZ6e7ua1uWFKSiOAc82jmib41hiBLR3sw3k5D4hhi9HELt9O4jKx5rge/3pPh ugng== MIME-Version: 1.0 X-Received: by 10.42.48.202 with SMTP id t10mr21709837icf.9.1387387059009; Wed, 18 Dec 2013 09:17:39 -0800 (PST) Received: by 10.64.78.103 with HTTP; Wed, 18 Dec 2013 09:17:38 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B73C6B8@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B73C6B8@eusaamb103.ericsson.se> Date: Wed, 18 Dec 2013 12:17:38 -0500 Message-ID: From: Alia Atlas To: Gregory Mirsky Content-Type: multipart/alternative; boundary=90e6ba6e8e88d1876304edd23899 Cc: "mpls@ietf.org" Subject: Re: [mpls] Note on p2mp ingress and egress protection proposals X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2013 17:17:43 -0000 --90e6ba6e8e88d1876304edd23899 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Greg, Can you briefly summarize what part of the problem ICCP is solving and why you think it can be improved to offer fast protection? From a quick glance at the first couple pages, it looks like it does the state coordination for the service - but not setting up the transport LSPs?? The RSVP-TE ingress protection draft describes different failure detection modes so that the appropriate action on detecting a failure is clearly agreed before the failure occurs. Handling a failure in a non fast fashion is fairly rivial; for instance, the backup ingress could run BFD to the ingress node's loopback and see if it fails after the network has converged. I do think that there are basic RSVP-TE mechanisms required to set up the backup LSPs, indicate the traffic to insert, and what type of failure detection will be used. Those seem to require standardization for interoperability - not just informational. Perhaps you can more clearly describe what you are proposing? Of course, if you already have a draft written, please just point me at it. Regards, Alia On Tue, Dec 17, 2013 at 12:11 PM, Gregory Mirsky < gregory.mirsky@ericsson.com> wrote: > Dear All, > > I=92ve been following these proposals for a quite some time and actively > participated in the discussion with authors. I do believe that both > scenarios represent use of redundancy and hence explicit coordination of > Active/Standby roles is required. That certainly would simplify OAM for > both cases. And I believe that ICCP is good candidate for coordination > within Redundancy Group. Though it would hardly be =93fast protection=94 = then. > > Hence I believe that all pieces needed to address both scenarios already > exist and Informational documents may be needed if anything at all. > > > > Regards, > > Greg > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --90e6ba6e8e88d1876304edd23899 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Greg,

Can you briefly summarize what= part of the problem ICCP is solving and why you think it can be improved t= o offer fast protection? =A0From a quick glance at the first couple pages, = it looks like it does the state coordination for the service - but not sett= ing up the transport LSPs??

The RSVP-TE ingress protection draft describes differen= t failure detection modes so that the appropriate action on detecting a fai= lure is clearly agreed before the failure occurs.

Handling a failure in a non fast fashion is fairly rivial; for instance, th= e backup ingress could run BFD to the ingress node's loopback and see i= f it fails after the network has converged.

I do t= hink that there are basic RSVP-TE mechanisms required to set up the backup = LSPs, indicate the traffic to insert, and what type of failure detection wi= ll be used. =A0Those seem to require standardization for interoperability -= not just informational.

Perhaps you can more clearly describe what you are prop= osing? =A0Of course, if you already have a draft written, please just point= me at it.

Regards,
Alia


On Tue, Dec 17, 2013 at 12:11 PM, Gregor= y Mirsky <gregory.mirsky@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Dear All,

I=92ve been following these proposals for a quite so= me time and actively participated in the discussion with authors. I do beli= eve that both scenarios represent use of redundancy and hence explicit coor= dination of Active/Standby roles is required. That certainly would simplify OAM for both cases. And I believe = that ICCP is good candidate for coordination within Redundancy Group. Thoug= h it would hardly be =93fast protection=94 then.

Hence I believe that all pieces needed to address bo= th scenarios already exist and Informational documents may be needed if any= thing at all.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Regard= s,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg


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


--90e6ba6e8e88d1876304edd23899-- From huaimo.chen@huawei.com Wed Dec 18 12:21:46 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 813251AE252 for ; Wed, 18 Dec 2013 12:21:46 -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 J0oiOtEQ0Hht for ; Wed, 18 Dec 2013 12:21:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB991AE269 for ; Wed, 18 Dec 2013 12:21: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 BBO59231; Wed, 18 Dec 2013 20:21:23 +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, 18 Dec 2013 20:20:50 +0000 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 20:21:22 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.165]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 12:21:06 -0800 From: Huaimo Chen To: Yimin Shen , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHO9zz2D8OUboE/BU63IW10jjHvHppYmeWwgAHOdjA= Date: Wed, 18 Dec 2013 20:21:05 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C206DB@sjceml501-mbs.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C1F60D@sjceml501-mbs.china.huawei.com> <3e2e8b8ddcb54bfc9f1de747bc51efa1@BY2PR05MB728.namprd05.prod.outlook.com> In-Reply-To: <3e2e8b8ddcb54bfc9f1de747bc51efa1@BY2PR05MB728.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.77] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C206DBsjceml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Raveendra Torvi 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: Wed, 18 Dec 2013 20:21:46 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C206DBsjceml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yimin, Thank you for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Yimin Shen [mailto:yshen@juniper.net] Sent: Tuesday, December 17, 2013 11:54 AM To: Huaimo Chen; mpls@ietf.org Cc: Raveendra Torvi Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi Huaimo, In the traditional RSVP FRR (RFC 4090), an ingress router requests link pro= tection, node protection and/or bandwidth protection by setting some flags = in the Path message, and it's the decision of a transit router whether to a= ctually set up FRR, based on its capability, local policy and local topolog= y. In this draft, the model seems completely ingress-driven. The ingress not o= nly requests FRR, but also pushes an explicit bypass route to the PLR to fo= rce to set it up. So I have a doubt whether this is always desirable and po= ssible? IMO, we may not assume that the ingress router can always have the= visibility of the topology of entire network (including the location of pr= otected node, PLR and protector) and the knowledge of local policies of eac= h PLR. For example, there are cases where a P2MP LSP needs to traverse mult= iple domains, some kind of topology abstraction/hiding is required between = domains, and loose hop expansion has to be performed at domain boundaries. Huaimo: An explicit bypass or backup route is not required. It is optional.= The ingress router does not have to put any explicit bypass or backup rou= te into a Path message to be sent to the PLR. We will revise the draft acc= ordingly. Thanks, /Yimin From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Huaimo Chen Sent: Thursday, December 12, 2013 8:21 AM To: mpls@ietf.org Cc: Raveendra Torvi Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n 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_5316A0AB3C851246A7CA5758973207D445C206DBsjceml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yimin,

 <= /p>

Thank you for your comments!

My answers/explanations are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Yimin Sh= en [mailto:yshen@juniper.net]
Sent: Tuesday, December 17, 2013 11:54 AM
To: Huaimo Chen; mpls@ietf.org
Cc: Raveendra Torvi
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n

 

Hi Huaimo,

 <= /p>

In the traditional RSVP F= RR (RFC 4090), an ingress router requests link protection, node protection = and/or bandwidth protection by setting some flags in the Path message, and it’s the decision of a transit router whether to a= ctually set up FRR, based on its capability, local policy and local topolog= y.

 <= /p>

In this draft, the model = seems completely ingress-driven. The ingress not only requests FRR, but als= o pushes an explicit bypass route to the PLR to force to set it up. So I have a doubt whether this is always desirable and possible= ? IMO, we may not assume that the ingress router can always  have the = visibility of the topology of entire network (including the location of pro= tected node, PLR and protector) and the knowledge of local policies of each PLR. For example, there are cases wher= e a P2MP LSP needs to traverse multiple domains, some kind of topology abst= raction/hiding is required between domains, and loose hop expansion has to = be performed at domain boundaries.

 <= /p>

Huaimo: An explicit bypas= s or backup route is not required. It is optional. The ingress router does = not have  to put any explicit bypass or backup route into a Path message to be sent to the PLR.  We will revise the draft accor= dingly.  

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Huaimo Chen
Sent: Thursday, December 12, 2013 8:21 AM
To: mpls@ietf.org
Cc: Raveendra Torvi
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

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 fro= m some of the reviewers that they are comfortable with how the comments have been addressed. We would like t= o have the same response from the other two reviewers.

 

Best Regards,

Huaimo<= /p>

--_000_5316A0AB3C851246A7CA5758973207D445C206DBsjceml501mbschi_-- From gregory.mirsky@ericsson.com Wed Dec 18 13:30:24 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 510061ADFFA for ; Wed, 18 Dec 2013 13:30: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, 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 Gf3OjSSUVL2c for ; Wed, 18 Dec 2013 13:30:18 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E3F971AE192 for ; Wed, 18 Dec 2013 13:30:17 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-c7-52b213e543ed Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 28.AB.04556.5E312B25; Wed, 18 Dec 2013 22:30:13 +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; Wed, 18 Dec 2013 16:29:58 -0500 From: Gregory Mirsky To: Alia Atlas Thread-Topic: [mpls] Note on p2mp ingress and egress protection proposals Thread-Index: Ac77SQgjFiRx71WkT86cjtgOzPNpQwA9e2EAAAIZXpA= Date: Wed, 18 Dec 2013 21:29:57 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B73ECAD@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B73C6B8@eusaamb103.ericsson.se> In-Reply-To: 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: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B73ECADeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXRPoO5T4U1BBpf3SVp8eniJ2eLW0pWs DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGtPsrmQuWJFXMmbCItYHxQ0gXIyeHhICJ xP4zl1ggbDGJC/fWs3UxcnEICRxhlNh55SE7hLOcUWLLjcuMIFVsAkYSLzb2ACU4OEQElCSm vhQGMZkFlCVO3ZUBqRAW8JCYub+TFcQWEfCUOLFtD1S1lcSfs8EgYRYBVYnFNxezgdi8Ar4S R9Z9Z4XYNIVR4um+k2wg9ZwCgRJft/uB1DACnfb91BomEJtZQFzi1pP5TBAnC0gs2XOeGcIW lXj5+B8rhK0s8X3OIxaI+nyJo4vOMUHsEpQ4OfMJywRG0VlIRs1CUjYLSRlEXEdiwe5PbBC2 tsSyha+ZYewzBx4zIYsvYGRfxchRWpxalptuZLiJERhRxyTYHHcwLvhkeYhRmoNFSZz3y1vn ICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MYrluzq/WXrFrdX+/kDs8NT2oMrowgOtR/7ZS doljNTvcJ/95dv4m+9alXD3FewLPd0v5cJb4mHqu3mKms2ze9J6FC80C6vf+T1l34bPZgl6l eR2qFg3mLoeuT7gYeX+hU6BQ3PGDk5R/OHqaXmlleHJwCaPN4T8s22KdXjAZpr4wCQ9v/xGi xFKckWioxVxUnAgAvTdCQ3YCAAA= Cc: "mpls@ietf.org" Subject: Re: [mpls] Note on p2mp ingress and egress protection proposals X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2013 21:30:24 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B73ECADeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alia, yes, I'd consider using the ICCP, Inter-Chassis Communication Protocol, in = cases of LSP ingress and egress protection to synchronize state. I agree wi= th your analysis that ICCP unlikely to support fast protection switchover b= ut I'm not certain that such is required because we don't have any use case= and/or requirements for LSP ingress and/or egress protection scenarios. As= I can see and was commenting, proposed application of OAM monitoring does = create likely positive negative scenarios. The ICCP will address them, I be= lieve. Is that required? We can determine that if we have agreed upon requi= rements but until then that is matter of personal opinion. I think that both scenarios present cases of LSP redundancy that are simila= r to PW redundancy where ICCP plays integral and important role. Hence my r= ecommendation to discuss applicability of ICCP. But even more stronger I'd = encourage and would gladly cooperate on requirements towards LSP ingress an= d egress protection. Regards, Greg From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, December 18, 2013 9:18 AM To: Gregory Mirsky Cc: mpls@ietf.org Subject: Re: [mpls] Note on p2mp ingress and egress protection proposals Hi Greg, Can you briefly summarize what part of the problem ICCP is solving and why = you think it can be improved to offer fast protection? From a quick glance= at the first couple pages, it looks like it does the state coordination fo= r the service - but not setting up the transport LSPs?? The RSVP-TE ingress protection draft describes different failure detection = modes so that the appropriate action on detecting a failure is clearly agre= ed before the failure occurs. Handling a failure in a non fast fashion is fairly rivial; for instance, th= e backup ingress could run BFD to the ingress node's loopback and see if it= fails after the network has converged. I do think that there are basic RSVP-TE mechanisms required to set up the b= ackup LSPs, indicate the traffic to insert, and what type of failure detect= ion will be used. Those seem to require standardization for interoperabili= ty - not just informational. Perhaps you can more clearly describe what you are proposing? Of course, i= f you already have a draft written, please just point me at it. Regards, Alia On Tue, Dec 17, 2013 at 12:11 PM, Gregory Mirsky > wrote: Dear All, I've been following these proposals for a quite some time and actively part= icipated in the discussion with authors. I do believe that both scenarios r= epresent use of redundancy and hence explicit coordination of Active/Standb= y roles is required. That certainly would simplify OAM for both cases. And = I believe that ICCP is good candidate for coordination within Redundancy Gr= oup. Though it would hardly be "fast protection" then. Hence I believe that all pieces needed to address both scenarios already ex= ist and Informational documents may be needed if anything at all. Regards, Greg _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_7347100B5761DC41A166AC17F22DF1121B73ECADeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alia,

yes, I’d consider u= sing the ICCP, Inter-Chassis Communication Protocol, in cases of LSP ingres= s and egress protection to synchronize state. I agree with your analysis that ICCP unlikely to support fast protection switchover but I= 217;m not certain that such is required because we don’t have any use= case and/or requirements for LSP ingress and/or egress protection scenario= s. As I can see and was commenting, proposed application of OAM monitoring does create likely positive negative scenari= os. The ICCP will address them, I believe. Is that required? We can determi= ne that if we have agreed upon requirements but until then that is matter o= f personal opinion.

I think that both scenari= os present cases of LSP redundancy that are similar to PW redundancy where = ICCP plays integral and important role. Hence my recommendation to discuss applicability of ICCP. But even more stronger I’d encoura= ge and would gladly cooperate on requirements towards LSP ingress and egres= s protection.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Alia Atl= as [mailto:akatlas@gmail.com]
Sent: Wednesday, December 18, 2013 9:18 AM
To: Gregory Mirsky
Cc: mpls@ietf.org
Subject: Re: [mpls] Note on p2mp ingress and egress protection propo= sals

 

Hi Greg,

 

Can you briefly summarize what part of the problem I= CCP is solving and why you think it can be improved to offer fast protectio= n?  From a quick glance at the first couple pages, it looks like it do= es the state coordination for the service - but not setting up the transport LSPs??

 

The RSVP-TE ingress protection draft describes diffe= rent failure detection modes so that the appropriate action on detecting a = failure is clearly agreed before the failure occurs.

 

Handling a failure in a non fast fashion is fairly r= ivial; for instance, the backup ingress could run BFD to the ingress node's= loopback and see if it fails after the network has converged.

 

I do think that there are basic RSVP-TE mechanisms r= equired to set up the backup LSPs, indicate the traffic to insert, and what= type of failure detection will be used.  Those seem to require standa= rdization for interoperability - not just informational.

 

Perhaps you can more clearly describe what you are p= roposing?  Of course, if you already have a draft written, please just= point me at it.

 

Regards,

Alia

 

On Tue, Dec 17, 2013 at 12:11 PM, Gregory Mirsky <= ;gregory.m= irsky@ericsson.com> wrote:

Dear All,

I’ve been following these proposals for a quite some time an= d actively participated in the discussion with authors. I do believe that b= oth scenarios represent use of redundancy and hence explicit coordination of Active/Standby roles is required. That = certainly would simplify OAM for both cases. And I believe that ICCP is goo= d candidate for coordination within Redundancy Group. Though it would hardl= y be “fast protection” then.

Hence I believe that all pieces needed to address both scenarios a= lready exist and Informational documents may be needed if anything at all.<= o:p>

 

           =      Regards,

           =             &nb= sp;        Greg


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

 

--_000_7347100B5761DC41A166AC17F22DF1121B73ECADeusaamb103erics_-- From rcallon@juniper.net Thu Dec 19 20:42:05 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 9DD121AF457 for ; Thu, 19 Dec 2013 20:42:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gdjwlt0mpPFY for ; Thu, 19 Dec 2013 20:42:03 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 373CF1AF453 for ; Thu, 19 Dec 2013 20:42:03 -0800 (PST) Received: from mail170-db9-R.bigfish.com (10.174.16.246) by DB9EHSOBE017.bigfish.com (10.174.14.80) with Microsoft SMTP Server id 14.1.225.22; Fri, 20 Dec 2013 04:42:00 +0000 Received: from mail170-db9 (localhost [127.0.0.1]) by mail170-db9-R.bigfish.com (Postfix) with ESMTP id 974811A009C; Fri, 20 Dec 2013 04:42:00 +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: -21 X-BigFish: VPS-21(z579ehz9371I542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail170-db9: 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)(13464003)(189002)(377454003)(164054003)(199002)(53806001)(46102001)(56776001)(83072002)(85306002)(50986001)(31966008)(77982001)(74316001)(81686001)(81342001)(33646001)(81816001)(80976001)(85852003)(19580405001)(59766001)(74502001)(76482001)(4396001)(83322001)(49866001)(54316002)(47446002)(65816001)(87266001)(76576001)(79102001)(63696002)(74706001)(80022001)(74366001)(47736001)(66066001)(81542001)(19580395003)(90146001)(2656002)(76786001)(47976001)(74662001)(56816005)(74876001)(54356001)(69226001)(51856001)(76796001)(87936001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.16; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail170-db9 (localhost.localdomain [127.0.0.1]) by mail170-db9 (MessageSwitch) id 1387514517522571_15372; Fri, 20 Dec 2013 04:41:57 +0000 (UTC) Received: from DB9EHSMHS032.bigfish.com (unknown [10.174.16.250]) by mail170-db9.bigfish.com (Postfix) with ESMTP id 70F27300047; Fri, 20 Dec 2013 04:41:57 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS032.bigfish.com (10.174.14.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 20 Dec 2013 04:41:57 +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.383.1; Fri, 20 Dec 2013 04:41:56 +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.820.5; Fri, 20 Dec 2013 04:41:47 +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.0820.005; Fri, 20 Dec 2013 04:41:47 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-ietf-mpls-moving-iana-registries@tools.ietf.org" Thread-Topic: Closed: working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO8Ilsdxvw6W4DfkSXFkfIGRLzvppclxGA Date: Fri, 20 Dec 2013 04:41:47 +0000 Message-ID: <78f33ff05a014457b51a022f00895bfe@CO2PR05MB636.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.16] x-forefront-prvs: 0066D63CE6 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] Closed: working group last call on draft-ietf-mpls-moving-iana-registries-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: Fri, 20 Dec 2013 04:42:05 -0000 The WG last call has ended with solid support, and draft-ietf-mpls-moving-i= ana-registries-00 has passed WG last call. There are however a couple of co= mments that provide editorial improvements and there has been some discussi= on of these on the WG list.=20 Authors, please reissue the Internet Draft with the editorial updates as di= scussed during the WG last call.=20 When this is done, I will submit the document for publication.=20 Thanks, Ross (as WG co-chair)=20 -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Tuesday, December 03, 2013 7:40 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-moving-iana-registries@tool= s.ietf.org Subject: working group last call on draft-ietf-mpls-moving-iana-registries-= 00 Working Group; =20 This is to start a two week working group last call on draft-ietf-mpls-moving-iana-registries-00.txt. Please send your comment to the working group mailing list (mpls@ietf.org). We did an IPR poll on this document in September. The authors each responde= d to the=20 IPR poll that they not aware of any IPR relating to this document. There ar= e no IPRs=20 disclosed against this document. The working group last call will end Wednesday December 18, 2013. Ross (as mpls wg co-chair) From internet-drafts@ietf.org Fri Dec 20 07:38:44 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 EF8EA1AE315; Fri, 20 Dec 2013 07:38:43 -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 n7afhxMriJ4p; Fri, 20 Dec 2013 07:38:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5921AE305; Fri, 20 Dec 2013 07:38:42 -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.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131220153842.16699.71812.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2013 07:38:42 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-moving-iana-registries-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, 20 Dec 2013 15:38:44 -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 registrie= s to a new registry Author(s) : Loa Andersson Carlos Pignataro Filename : draft-ietf-mpls-moving-iana-registries-01.txt Pages : 7 Date : 2013-12-20 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)" 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-08, and RFC-ietf-mpls-tp-ethernet-addressing-08. 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-moving-iana-registries-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 cpignata@cisco.com Fri Dec 20 07:40:32 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 F11461AE33E for ; Fri, 20 Dec 2013 07:40:31 -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 Z9DKm6W51gqj for ; Fri, 20 Dec 2013 07:40:30 -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 511311AE31B for ; Fri, 20 Dec 2013 07:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2362; q=dns/txt; s=iport; t=1387554027; x=1388763627; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f/iaFyknugWqZtdARXmUBiUevD+RGbziwOCuJX7DEbw=; b=iI9TV3rUaq7PP0OqNH20JN9rBrh1BxDbBs91lQtBWputgrwsHq6pn2Bm PWo72wkL2d+1rWoJ6JweUXPryKe773UeDDw3cHNLAWtvaZmFBM37jPoes ADsff68OExkjG1aayF8rMFuKISFSna2cGAijcflCcGoAqGQkYAuvvzORx 4=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANFjtFKtJV2b/2dsb2JhbABZgws4Vbk2gRsWdIIlAQEBAwEBAQFrCwUHBAIBCA4DBAEBKAcnCxQJCAIEDgUOh24IDcp7EwSPEgcGgx2BEwSQM4ExhjKSFIFtgT6CKg X-IronPort-AV: E=Sophos;i="4.95,521,1384300800"; d="asc'?scan'208";a="292746525" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 20 Dec 2013 15:40:27 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBKFeR2T021263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Dec 2013 15:40:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.18]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 20 Dec 2013 09:40:27 -0600 From: "Carlos Pignataro (cpignata)" To: Ross Callon Thread-Topic: [mpls] Closed: working group last call on draft-ietf-mpls-moving-iana-registries-00 Thread-Index: AQHO8Ilsdxvw6W4DfkSXFkfIGRLzvppclxGAgAEgC4A= Date: Fri, 20 Dec 2013 15:40:27 +0000 Message-ID: <7F733C23-5A54-47F9-8AF9-A1EA4277D30F@cisco.com> References: <78f33ff05a014457b51a022f00895bfe@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <78f33ff05a014457b51a022f00895bfe@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: multipart/signed; boundary="Apple-Mail=_336454B8-2B8A-454E-AC1E-40971DC4D073"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-moving-iana-registries@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Closed: working group last call on draft-ietf-mpls-moving-iana-registries-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: Fri, 20 Dec 2013 15:40:32 -0000 --Apple-Mail=_336454B8-2B8A-454E-AC1E-40971DC4D073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Done, Ross. Thanks! On Dec 19, 2013, at 11:41 PM, Ross Callon wrote: > The WG last call has ended with solid support, and = draft-ietf-mpls-moving-iana-registries-00 has passed WG last call. There = are however a couple of comments that provide editorial improvements and = there has been some discussion of these on the WG list.=20 >=20 > Authors, please reissue the Internet Draft with the editorial updates = as discussed during the WG last call.=20 >=20 > When this is done, I will submit the document for publication.=20 >=20 > Thanks, Ross > (as WG co-chair)=20 >=20 > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net]=20 > Sent: Tuesday, December 03, 2013 7:40 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-moving-iana-registries@tools.ietf.org > Subject: working group last call on = draft-ietf-mpls-moving-iana-registries-00 >=20 > Working Group; >=20 > This is to start a two week working group last call on > draft-ietf-mpls-moving-iana-registries-00.txt. >=20 > Please send your comment to the working group mailing list = (mpls@ietf.org). >=20 > We did an IPR poll on this document in September. The authors each = responded to the=20 > IPR poll that they not aware of any IPR relating to this document. = There are no IPRs=20 > disclosed against this document. >=20 > The working group last call will end Wednesday December 18, 2013. >=20 > Ross > (as mpls wg co-chair) >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_336454B8-2B8A-454E-AC1E-40971DC4D073 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 iEYEARECAAYFAlK0ZOkACgkQtfDPGTp3USwbVQCeJuGrKY5tEJzkwM5N2OpRGiYY S+EAn2M1kpVc6VJfKCEAajn97/Vy8bm6 =u4qD -----END PGP SIGNATURE----- --Apple-Mail=_336454B8-2B8A-454E-AC1E-40971DC4D073-- From loa@pi.nu Sat Dec 21 00:27:40 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 2806C1AE0D5 for ; Sat, 21 Dec 2013 00:27: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 hfJeCdUBB2Mq for ; Sat, 21 Dec 2013 00:27:37 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 68B411AE0B0 for ; Sat, 21 Dec 2013 00:27:37 -0800 (PST) Received: from [10.136.169.137] (unknown [124.127.168.139]) (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 EE6D71800740; Sat, 21 Dec 2013 09:27:32 +0100 (CET) Message-ID: <52B550D6.3030606@pi.nu> Date: Sat, 21 Dec 2013 16:27:02 +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-ldp-ipv6@tools.ietf.org" References: <52A96B2D.6060003@pi.nu> In-Reply-To: <52A96B2D.6060003@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Closed: Short wg last call on 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: Sat, 21 Dec 2013 08:27:40 -0000 Working Group, this wglc is closed. We have not other comments than support. This is what we expect after a penetrating discussion and the wglc limited to the changes based on this discussion. The working group chairs plan to go ahead and request publication. /Loa MPLS WG co-chair On 2013-12-12 15:52, Loa Andersson wrote: > Working Group, > > This is to start a one week working group last call on > draft-ietf-mpls-ldp-ipv6-10 > > We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good > comments and the document almost ready to go. At that point a discussion > on the number of LDP session needed between a pair LSRs with both IPv4 > and IPv6 emerged, it has taken us quite a long time to resolve this. > > However, the author, wg chairs and people making the comments now agree > that version -10 is resolve those comments. > > This working group last call is limited to the changes since the > previous last call. A diff can be found at: > > http://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-ldp-ipv6-07&difftype=--html&submit=Go%21&url2=draft-ietf-mpls-ldp-ipv6-10 > > > Please send you comments to the MPLS wg mailing list (mpls@ietf.org). > > This wglc ends Dec 20, 2013. > > /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 Sat Dec 21 02:55:50 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 A92E41AD79D for ; Sat, 21 Dec 2013 02:55:50 -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 pxoUTDt34tMl for ; Sat, 21 Dec 2013 02:55:49 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 26BCF1AD68D for ; Sat, 21 Dec 2013 02:55:49 -0800 (PST) Received: from [10.136.170.1] (unknown [124.127.168.3]) (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 F30F91800740; Sat, 21 Dec 2013 11:55:41 +0100 (CET) Message-ID: <52B573AA.4060208@pi.nu> Date: Sat, 21 Dec 2013 18:55:38 +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 , "Ryoo, Jeong-dong" , "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] Additional comment on draft-ietf-mpls-tp-psc-tu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 21 Dec 2013 10:55:50 -0000 Working Group and Editors, Over the last two weeks I've had the opportunity to discuss draft-ietf-mpls-tp-psc-itu with people with different background. The reaction is mainly very positive :). However, there is one feedback that I get consistently, there is a rather high threshold when starting to read the document. Even though we taken steps to point out that the specification heveily depends on RFC 6378, I thin we should make this explicit. I propose that the add a sentence early in the inroduction, something like "The reader of this document is assumed to be familiar with RFC 6378. /Loa -- 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 Sat Dec 21 20:52:44 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 20BA01ADF51 for ; Sat, 21 Dec 2013 20:52: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 NjLFseJE5mPK for ; Sat, 21 Dec 2013 20:52:41 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9D01AE17A for ; Sat, 21 Dec 2013 20:52:41 -0800 (PST) Received: from [192.168.1.9] (unknown [112.208.48.76]) (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 1043A18013E2; Sun, 22 Dec 2013 05:52:35 +0100 (CET) Message-ID: <52B67013.2050907@pi.nu> Date: Sun, 22 Dec 2013 12:52:35 +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-ldp-ipv6@tools.ietf.org" References: <52A96B2D.6060003@pi.nu> <52B550D6.3030606@pi.nu> In-Reply-To: <52B550D6.3030606@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Closed: Short wg last call on 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: Sun, 22 Dec 2013 04:52:44 -0000 Working Group, authors and Qin Wu, The mail closing the wglc was not quite accurate, there are a set of comments from Qin Wu (that I had misplaced). I've asked the authors to address the comments. /Loa On 2013-12-21 16:27, Loa Andersson wrote: > Working Group, > > this wglc is closed. We have not other comments than support. > This is what we expect after a penetrating discussion and the wglc > limited to the changes based on this discussion. > > The working group chairs plan to go ahead and request publication. > > /Loa > > MPLS WG co-chair > > On 2013-12-12 15:52, Loa Andersson wrote: >> Working Group, >> >> This is to start a one week working group last call on >> draft-ietf-mpls-ldp-ipv6-10 >> >> We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good >> comments and the document almost ready to go. At that point a discussion >> on the number of LDP session needed between a pair LSRs with both IPv4 >> and IPv6 emerged, it has taken us quite a long time to resolve this. >> >> However, the author, wg chairs and people making the comments now agree >> that version -10 is resolve those comments. >> >> This working group last call is limited to the changes since the >> previous last call. A diff can be found at: >> >> http://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-ldp-ipv6-07&difftype=--html&submit=Go%21&url2=draft-ietf-mpls-ldp-ipv6-10 >> >> >> >> Please send you comments to the MPLS wg mailing list (mpls@ietf.org). >> >> This wglc ends Dec 20, 2013. >> >> /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 cpignata@cisco.com Sun Dec 22 05:53:38 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 1CEDB1AE2CD for ; Sun, 22 Dec 2013 05:53:38 -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 NEM63pzTLrhT for ; Sun, 22 Dec 2013 05:53:36 -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 6932E1AE2CC for ; Sun, 22 Dec 2013 05:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2705; q=dns/txt; s=iport; t=1387720414; x=1388930014; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kBeq7ngZDqyiMEl0DUq3+MefDAOhJz5K3Pnm5RBVnGw=; b=Z/74KAyJG1cQtYPVctDDoFZcegF9yLJceVPSCGlEsQnf/w4eMHIP85tQ FCHaeroyD/H2tXKjbY/gDpoBnpRLvsURob/hii5XqMqGyWm+YxUBOtv40 e1Gv6qT61PxYsiCfIiig9VS+g49dY2GKCwUJsrHYpHgsFwrCgwcTkscJb s=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAIXttlKtJXG//2dsb2JhbABYgws4Vbk/gRIWdIIlAQEBAwFrAwsFCQICAQgYLhsXJQIEDgUJBYduCA3KbxcEjj8KBgIBTweDI4ETBJAzgTGGM5IUgy2BaEI X-IronPort-AV: E=Sophos;i="4.95,531,1384300800"; d="asc'?scan'208";a="293240502" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 22 Dec 2013 13:53:32 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBMDrWJt022410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Dec 2013 13:53:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.18]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Sun, 22 Dec 2013 07:53:32 -0600 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: Closed: Short wg last call on draft-ietf-mpls-ldp-ipv6 Thread-Index: AQHO/tGpMAwApbsIskWYIFg6fneHqppgoVeA Date: Sun, 22 Dec 2013 13:53:31 +0000 Message-ID: References: <52A96B2D.6060003@pi.nu> <52B550D6.3030606@pi.nu> <52B67013.2050907@pi.nu> In-Reply-To: <52B67013.2050907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.239.63] Content-Type: multipart/signed; boundary="Apple-Mail=_9A7E3720-3F78-47D1-9052-D59671095444"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Closed: Short wg last call on 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: Sun, 22 Dec 2013 13:53:38 -0000 --Apple-Mail=_9A7E3720-3F78-47D1-9052-D59671095444 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 21, 2013, at 11:52 PM, Loa Andersson wrote: > Working Group, authors and Qin Wu, >=20 > The mail closing the wglc was not quite accurate, there are a set of > comments from Qin Wu (that I had misplaced). I've asked the authors > to address the comments. >=20 > /Loa >=20 > On 2013-12-21 16:27, Loa Andersson wrote: >> Working Group, >>=20 >> this wglc is closed. We have not other comments than support. >> This is what we expect after a penetrating discussion and the wglc >> limited to the changes based on this discussion. >>=20 >> The working group chairs plan to go ahead and request publication. >>=20 >> /Loa >>=20 >> MPLS WG co-chair >>=20 >> On 2013-12-12 15:52, Loa Andersson wrote: >>> Working Group, >>>=20 >>> This is to start a one week working group last call on >>> draft-ietf-mpls-ldp-ipv6-10 >>>=20 >>> We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had = good >>> comments and the document almost ready to go. At that point a = discussion >>> on the number of LDP session needed between a pair LSRs with both = IPv4 >>> and IPv6 emerged, it has taken us quite a long time to resolve this. >>>=20 >>> However, the author, wg chairs and people making the comments now = agree >>> that version -10 is resolve those comments. >>>=20 >>> This working group last call is limited to the changes since the >>> previous last call. A diff can be found at: >>>=20 >>> = http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-ldp-ipv6-07&difftype=3D= --html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-ldp-ipv6-10 >>>=20 >>>=20 >>>=20 >>> Please send you comments to the MPLS wg mailing list = (mpls@ietf.org). >>>=20 >>> This wglc ends Dec 20, 2013. >>>=20 >>> /Loa >>> for the MPLS wg co-chairs >>=20 >=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 --Apple-Mail=_9A7E3720-3F78-47D1-9052-D59671095444 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 iEYEARECAAYFAlK27tsACgkQtfDPGTp3USyFjwCgkCoFUGJ811N+5KA7UXuoyUVM KNMAoNIlAsxz9izR182KQjXcgA/zJvcG =gn+a -----END PGP SIGNATURE----- --Apple-Mail=_9A7E3720-3F78-47D1-9052-D59671095444-- From cpignata@cisco.com Sun Dec 22 05:57:26 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 B90221AE2ED for ; Sun, 22 Dec 2013 05:57:26 -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 pKQ80ZFRwK7i for ; Sun, 22 Dec 2013 05:57:24 -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 CB0C21AE2EC for ; Sun, 22 Dec 2013 05:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3130; q=dns/txt; s=iport; t=1387720642; x=1388930242; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pedDC6jwW55KdqE0pCdtq5YZUOz3A25WgbQVO+J5vSQ=; b=JSsTEFe3Nu91q8VIi1La4yreSwT+cJQvVs8Cbe0hd34OuL2aAxRkpHhB 7sQnTYFhFjbjHXmJ0JzYuAcHBIrk6ZtfZswK387px25wvYU80Ify6TU6g 0Rap+cfxO4AiHAMZNns0Mj9q+k4kq0oKMxJ3mPFiE3JZdr+4+cJVeLTcg I=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAK3utlKtJV2b/2dsb2JhbABYgws4Vbk/gRIWdIIlAQEBAwFrAwsFCQICAQgYLhsXJQIEDgUJBYduCA3KcRcEjj8KBgIBTweDI4ETBJAzgTGGM5IUgy2BaEI X-IronPort-AV: E=Sophos;i="4.95,531,1384300800"; d="asc'?scan'208";a="293254784" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 22 Dec 2013 13:57:21 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBMDvLQp004356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Dec 2013 13:57:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.18]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Sun, 22 Dec 2013 07:57:21 -0600 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: Closed: Short wg last call on draft-ietf-mpls-ldp-ipv6 Thread-Index: AQHO/tGpMAwApbsIskWYIFg6fneHqppgomeA Date: Sun, 22 Dec 2013 13:57:20 +0000 Message-ID: <88E7475E-8B64-4005-8A5A-780721D6D5AA@cisco.com> References: <52A96B2D.6060003@pi.nu> <52B550D6.3030606@pi.nu> <52B67013.2050907@pi.nu> In-Reply-To: <52B67013.2050907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.239.63] Content-Type: multipart/signed; boundary="Apple-Mail=_A3274763-1C57-4A2B-BA8B-B41C1EF45A86"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Closed: Short wg last call on 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: Sun, 22 Dec 2013 13:57:26 -0000 --Apple-Mail=_A3274763-1C57-4A2B-BA8B-B41C1EF45A86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Loa, Actually, the comments from Qin Wu are not limited to the changes from = the previous WGLC (as the call text specified). They are general = comments on the doc. All good and useful that we should discuss and = address. But as such, I suggest we continue forward without stopping the pub = request, and treat these as IETF LC comments and go incorporating them = with others later. Thanks, -- Carlos. On Dec 21, 2013, at 11:52 PM, Loa Andersson wrote: > Working Group, authors and Qin Wu, >=20 > The mail closing the wglc was not quite accurate, there are a set of > comments from Qin Wu (that I had misplaced). I've asked the authors > to address the comments. >=20 > /Loa >=20 > On 2013-12-21 16:27, Loa Andersson wrote: >> Working Group, >>=20 >> this wglc is closed. We have not other comments than support. >> This is what we expect after a penetrating discussion and the wglc >> limited to the changes based on this discussion. >>=20 >> The working group chairs plan to go ahead and request publication. >>=20 >> /Loa >>=20 >> MPLS WG co-chair >>=20 >> On 2013-12-12 15:52, Loa Andersson wrote: >>> Working Group, >>>=20 >>> This is to start a one week working group last call on >>> draft-ietf-mpls-ldp-ipv6-10 >>>=20 >>> We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had = good >>> comments and the document almost ready to go. At that point a = discussion >>> on the number of LDP session needed between a pair LSRs with both = IPv4 >>> and IPv6 emerged, it has taken us quite a long time to resolve this. >>>=20 >>> However, the author, wg chairs and people making the comments now = agree >>> that version -10 is resolve those comments. >>>=20 >>> This working group last call is limited to the changes since the >>> previous last call. A diff can be found at: >>>=20 >>> = http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-ldp-ipv6-07&difftype=3D= --html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-ldp-ipv6-10 >>>=20 >>>=20 >>>=20 >>> Please send you comments to the MPLS wg mailing list = (mpls@ietf.org). >>>=20 >>> This wglc ends Dec 20, 2013. >>>=20 >>> /Loa >>> for the MPLS wg co-chairs >>=20 >=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 --Apple-Mail=_A3274763-1C57-4A2B-BA8B-B41C1EF45A86 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 iEYEARECAAYFAlK2778ACgkQtfDPGTp3USzn1ACeP7G16mT2ZYSXFXJxboxVr5DQ cx4AoJlo7rs2yWOQInnV/Xrwl1JWLHlO =SeAc -----END PGP SIGNATURE----- --Apple-Mail=_A3274763-1C57-4A2B-BA8B-B41C1EF45A86-- From tnadeau@lucidvision.com Sun Dec 22 07:01:00 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 2130B1AE3B0 for ; Sun, 22 Dec 2013 07:01:00 -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 tiioC0KED0qL for ; Sun, 22 Dec 2013 07:00:58 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 55DD81AE392 for ; Sun, 22 Dec 2013 07:00:58 -0800 (PST) Received: from [192.168.1.101] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C93D92693267; Sun, 22 Dec 2013 10:00:54 -0500 (EST) References: <52A96B2D.6060003@pi.nu> <52B550D6.3030606@pi.nu> <52B67013.2050907@pi.nu> <88E7475E-8B64-4005-8A5A-780721D6D5AA@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <88E7475E-8B64-4005-8A5A-780721D6D5AA@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2BD21A79-030E-4EF6-97BE-EF895107D5BB@lucidvision.com> X-Mailer: iPhone Mail (11B554a) From: "Thomas D. Nadeau" Date: Sun, 22 Dec 2013 10:00:55 -0500 To: "Carlos Pignataro (cpignata)" Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Closed: Short wg last call on 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: Sun, 22 Dec 2013 15:01:00 -0000 > On Dec 22, 2013, at 8:57 AM, "Carlos Pignataro (cpignata)" wrote: >=20 > Hi, Loa, >=20 > Actually, the comments from Qin Wu are not limited to the changes from the= previous WGLC (as the call text specified). They are general comments on th= e doc. All good and useful that we should discuss and address. >=20 > But as such, I suggest we continue forward without stopping the pub reques= t, and treat these as IETF LC comments and go incorporating them with others= later. I agree with Carlos. Let's please stick to the guidelines of the LC. Tom=20 >=20 > Thanks, >=20 > -- Carlos. >=20 >=20 >> On Dec 21, 2013, at 11:52 PM, Loa Andersson wrote: >>=20 >> Working Group, authors and Qin Wu, >>=20 >> The mail closing the wglc was not quite accurate, there are a set of >> comments from Qin Wu (that I had misplaced). I've asked the authors >> to address the comments. >>=20 >> /Loa >>=20 >>> On 2013-12-21 16:27, Loa Andersson wrote: >>> Working Group, >>>=20 >>> this wglc is closed. We have not other comments than support. >>> This is what we expect after a penetrating discussion and the wglc >>> limited to the changes based on this discussion. >>>=20 >>> The working group chairs plan to go ahead and request publication. >>>=20 >>> /Loa >>>=20 >>> MPLS WG co-chair >>>=20 >>>> On 2013-12-12 15:52, Loa Andersson wrote: >>>> Working Group, >>>>=20 >>>> This is to start a one week working group last call on >>>> draft-ietf-mpls-ldp-ipv6-10 >>>>=20 >>>> We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good >>>> comments and the document almost ready to go. At that point a discussio= n >>>> on the number of LDP session needed between a pair LSRs with both IPv4 >>>> and IPv6 emerged, it has taken us quite a long time to resolve this. >>>>=20 >>>> However, the author, wg chairs and people making the comments now agree= >>>> that version -10 is resolve those comments. >>>>=20 >>>> This working group last call is limited to the changes since the >>>> previous last call. A diff can be found at: >>>>=20 >>>> http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-ldp-ipv6-07&difftype= =3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-ldp-ipv6-10 >>>>=20 >>>>=20 >>>>=20 >>>> Please send you comments to the MPLS wg mailing list (mpls@ietf.org). >>>>=20 >>>> This wglc ends Dec 20, 2013. >>>>=20 >>>> /Loa >>>> for the MPLS wg co-chairs >>=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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Sun Dec 22 08:20:31 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 82C051AE330; Sun, 22 Dec 2013 08:20: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 Eiixk8qrRO2t; Sun, 22 Dec 2013 08:20:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BE11ADF74; Sun, 22 Dec 2013 08:20: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 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131222162029.31433.49018.idtracker@ietfa.amsl.com> Date: Sun, 22 Dec 2013 08:20:29 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-moving-iana-registries-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: Sun, 22 Dec 2013 16:20: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 : 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-02.txt Pages : 8 Date : 2013-12-22 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)" 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-moving-iana-registries-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 ryoo@etri.re.kr Sun Dec 22 18:17:04 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 738D41AE4B6 for ; Sun, 22 Dec 2013 18:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r1fysW1AaHTx for ; Sun, 22 Dec 2013 18:17:02 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id CCADF1AE3DC for ; Sun, 22 Dec 2013 18:17:01 -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, 23 Dec 2013 11:16:46 +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, 23 Dec 2013 11:16:48 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , Eric Gray , "mpls@ietf.org" Thread-Topic: Additional comment on draft-ietf-mpls-tp-psc-tu Thread-Index: AQHO/js1RIXR2lMm5kCB1NOSPfdq6pphC2o8 Date: Mon, 23 Dec 2013 02:16:47 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEDB3@SMTP2.etri.info> References: <52B573AA.4060208@pi.nu> In-Reply-To: <52B573AA.4060208@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_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEDB3SMTP2etriinfo_" MIME-Version: 1.0 Cc: "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Additional comment on draft-ietf-mpls-tp-psc-tu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 23 Dec 2013 02:17:04 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEDB3SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLCB0aGFua3MgZm9yIGxldHRpbmcgdXMga25vdyBvZiB0aGUgcmVzcG9uc2UgZnJvbSBwZW9w bGUgd2l0aCBkaWZmZXJlbnQgYmFja2dyb3VuZC4NCkkgYWxzbyBhcHByZWNpYXRlIHlvdXIgYXR0 ZW50aW9uIG9uIHRoaXMgZG9jdW1lbnQuDQpJbiBteSBvcGluaW9uLCB5b3VyIHByb3Bvc2FsIGlz IHF1aXRlIGNvbnNpZGVyYXRlLg0KDQpKZW9uZy1kb25nDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRnJvbSA6ICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51Pg0KU2Vu dCA6IDIwMTMtMTItMjEgMTk6NTU6NDkgKCArMDk6MDAgKQ0KVG8gOiBFcmljIEdyYXkgPGVyaWMu Z3JheUBlcmljc3Nvbi5jb20+LCBSeW9vLCBKZW9uZy1kb25nIDxyeW9vQGV0cmkucmUua3I+LCBt cGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPg0KQ2MgOiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNj LWl0dUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0 Zi5vcmc+LCBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyA8bXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc+DQpTdWJqZWN0IDogQWRkaXRpb25hbCBjb21tZW50IG9uIGRyYWZ0LWlldGYtbXBscy10 cC1wc2MtdHUNCg0KV29ya2luZyBHcm91cCBhbmQgRWRpdG9ycywNCg0KT3ZlciB0aGUgbGFzdCB0 d28gd2Vla3MgSSd2ZSBoYWQgdGhlIG9wcG9ydHVuaXR5IHRvIGRpc2N1c3MNCmRyYWZ0LWlldGYt bXBscy10cC1wc2MtaXR1IHdpdGggcGVvcGxlIHdpdGggZGlmZmVyZW50IGJhY2tncm91bmQuDQpU aGUgcmVhY3Rpb24gaXMgbWFpbmx5IHZlcnkgcG9zaXRpdmUgOikuDQoNCkhvd2V2ZXIsIHRoZXJl IGlzIG9uZSBmZWVkYmFjayB0aGF0IEkgZ2V0IGNvbnNpc3RlbnRseSwgdGhlcmUgaXMNCmEgcmF0 aGVyIGhpZ2ggdGhyZXNob2xkIHdoZW4gc3RhcnRpbmcgdG8gcmVhZCB0aGUgZG9jdW1lbnQuIEV2 ZW4gdGhvdWdoDQp3ZSB0YWtlbiBzdGVwcyB0byBwb2ludCBvdXQgdGhhdCB0aGUgc3BlY2lmaWNh dGlvbiBoZXZlaWx5IGRlcGVuZHMgb24NClJGQyA2Mzc4LCBJIHRoaW4gd2Ugc2hvdWxkIG1ha2Ug dGhpcyBleHBsaWNpdC4NCg0KSSBwcm9wb3NlIHRoYXQgdGhlIGFkZCBhIHNlbnRlbmNlIGVhcmx5 IGluIHRoZSBpbnJvZHVjdGlvbiwgc29tZXRoaW5nDQpsaWtlICJUaGUgcmVhZGVyIG9mIHRoaXMg ZG9jdW1lbnQgaXMgYXNzdW1lZCB0byBiZSBmYW1pbGlhciB3aXRoDQpSRkMgNjM3OC4NCg0KL0xv YQ0KLS0NCg0KDQpMb2EgQW5kZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NClNl bmlvciBNUExTIEV4cGVydCBsb2FAcGkubnUNCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRh bnQpIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEDB3SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsIHRoYW5rcyBmb3IgbGV0dGluZyB1cyBr bm93IG9mIHRoZSByZXNwb25zZSBmcm9tIHBlb3BsZSB3aXRoIGRpZmZlcmVudCBiYWNrZ3JvdW5k LjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkkgYWxzbyBhcHByZWNpYXRl IHlvdXIgYXR0ZW50aW9uIG9uIHRoaXMgZG9jdW1lbnQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+SW4gbXkgb3BpbmlvbiwgeW91ciBwcm9wb3NhbCBpcyBxdWl0ZSBjb25z aWRlcmF0ZS48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48YnI+DQpKZW9u Zy1kb25nPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0KJm5ic3A7 PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgaWQ9Ik1haWxTaWduIj48YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxociB0YWJpbmRleD0i LTEiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGI+RnJvbSA6IDwv Yj4mcXVvdDtMb2EgQW5kZXJzc29uJnF1b3Q7ICZsdDtsb2FAcGkubnUmZ3Q7PGJyPg0KPGI+U2Vu dCA6IDwvYj4yMDEzLTEyLTIxIDE5OjU1OjQ5ICggJiM0MzswOTowMCApPGJyPg0KPGI+VG8gOiA8 L2I+RXJpYyBHcmF5ICZsdDtlcmljLmdyYXlAZXJpY3Nzb24uY29tJmd0OywgUnlvbywgSmVvbmct ZG9uZyAmbHQ7cnlvb0BldHJpLnJlLmtyJmd0OywgbXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRm Lm9yZyZndDs8YnI+DQo8Yj5DYyA6IDwvYj5kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29s cy5pZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcm Z3Q7LCBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5BZGRpdGlvbmFsIGNvbW1lbnQgb24gZHJh ZnQtaWV0Zi1tcGxzLXRwLXBzYy10dTxicj4NCjxicj4NCldvcmtpbmcgR3JvdXAgYW5kIEVkaXRv cnMsPGJyPg0KPGJyPg0KT3ZlciB0aGUgbGFzdCB0d28gd2Vla3MgSSd2ZSBoYWQgdGhlIG9wcG9y dHVuaXR5IHRvIGRpc2N1c3M8YnI+DQpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dSB3aXRoIHBl b3BsZSB3aXRoIGRpZmZlcmVudCBiYWNrZ3JvdW5kLjxicj4NClRoZSByZWFjdGlvbiBpcyBtYWlu bHkgdmVyeSBwb3NpdGl2ZSA6KS48YnI+DQo8YnI+DQpIb3dldmVyLCB0aGVyZSBpcyBvbmUgZmVl ZGJhY2sgdGhhdCBJIGdldCBjb25zaXN0ZW50bHksIHRoZXJlIGlzPGJyPg0KYSByYXRoZXIgaGln aCB0aHJlc2hvbGQgd2hlbiBzdGFydGluZyB0byByZWFkIHRoZSBkb2N1bWVudC4gRXZlbiB0aG91 Z2g8YnI+DQp3ZSB0YWtlbiBzdGVwcyB0byBwb2ludCBvdXQgdGhhdCB0aGUgc3BlY2lmaWNhdGlv biBoZXZlaWx5IGRlcGVuZHMgb248YnI+DQpSRkMgNjM3OCwgSSB0aGluIHdlIHNob3VsZCBtYWtl IHRoaXMgZXhwbGljaXQuPGJyPg0KPGJyPg0KSSBwcm9wb3NlIHRoYXQgdGhlIGFkZCBhIHNlbnRl bmNlIGVhcmx5IGluIHRoZSBpbnJvZHVjdGlvbiwgc29tZXRoaW5nPGJyPg0KbGlrZSAmcXVvdDtU aGUgcmVhZGVyIG9mIHRoaXMgZG9jdW1lbnQgaXMgYXNzdW1lZCB0byBiZSBmYW1pbGlhciB3aXRo PGJyPg0KUkZDIDYzNzguPGJyPg0KPGJyPg0KL0xvYTxicj4NCi0tIDxicj4NCjxicj4NCjxicj4N CkxvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxicj4NClNlbmlvciBN UExTIEV4cGVydCBsb2FAcGkubnU8YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50 KSBwaG9uZTogJiM0Mzs0NiA3MzkgODEgMjEgNjQ8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEDB3SMTP2etriinfo_-- From loa@pi.nu Sun Dec 22 18:34:30 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 6B7F01AE626 for ; Sun, 22 Dec 2013 18:34: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 V2ryYbWWRmDm for ; Sun, 22 Dec 2013 18:34:28 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 995D51AE140 for ; Sun, 22 Dec 2013 18:34:27 -0800 (PST) Received: from [192.168.1.9] (unknown [112.208.91.36]) (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 6388918029FB; Mon, 23 Dec 2013 03:34:21 +0100 (CET) Message-ID: <52B7A12C.9030009@pi.nu> Date: Mon, 23 Dec 2013 10:34: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: "Carlos Pignataro (cpignata)" References: <52A96B2D.6060003@pi.nu> <52B550D6.3030606@pi.nu> <52B67013.2050907@pi.nu> <88E7475E-8B64-4005-8A5A-780721D6D5AA@cisco.com> In-Reply-To: <88E7475E-8B64-4005-8A5A-780721D6D5AA@cisco.com> 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@tools.ietf.org" Subject: Re: [mpls] Closed: Short wg last call on 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, 23 Dec 2013 02:34:30 -0000 Carlos, Working Group and Qin Wu, Carlos is right, the comments are on the draft in general and not within the scope of the short wglc. The first step after a working group request publication of a document is an "AD Evaluation", rather than waiting for the IETF last call we will blend Qin Wu's comments in when the comments from the AD Evaluation are addressed. I will go ahead and write the shepherd write-up. /Loa On 2013-12-22 21:57, Carlos Pignataro (cpignata) wrote: > Hi, Loa, > > Actually, the comments from Qin Wu are not limited to the changes from the previous WGLC (as the call text specified). They are general comments on the doc. All good and useful that we should discuss and address. > > But as such, I suggest we continue forward without stopping the pub request, and treat these as IETF LC comments and go incorporating them with others later. > > Thanks, > > -- Carlos. > > > On Dec 21, 2013, at 11:52 PM, Loa Andersson wrote: > >> Working Group, authors and Qin Wu, >> >> The mail closing the wglc was not quite accurate, there are a set of >> comments from Qin Wu (that I had misplaced). I've asked the authors >> to address the comments. >> >> /Loa >> >> On 2013-12-21 16:27, Loa Andersson wrote: >>> Working Group, >>> >>> this wglc is closed. We have not other comments than support. >>> This is what we expect after a penetrating discussion and the wglc >>> limited to the changes based on this discussion. >>> >>> The working group chairs plan to go ahead and request publication. >>> >>> /Loa >>> >>> MPLS WG co-chair >>> >>> On 2013-12-12 15:52, Loa Andersson wrote: >>>> Working Group, >>>> >>>> This is to start a one week working group last call on >>>> draft-ietf-mpls-ldp-ipv6-10 >>>> >>>> We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good >>>> comments and the document almost ready to go. At that point a discussion >>>> on the number of LDP session needed between a pair LSRs with both IPv4 >>>> and IPv6 emerged, it has taken us quite a long time to resolve this. >>>> >>>> However, the author, wg chairs and people making the comments now agree >>>> that version -10 is resolve those comments. >>>> >>>> This working group last call is limited to the changes since the >>>> previous last call. A diff can be found at: >>>> >>>> http://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-ldp-ipv6-07&difftype=--html&submit=Go%21&url2=draft-ietf-mpls-ldp-ipv6-10 >>>> >>>> >>>> >>>> Please send you comments to the MPLS wg mailing list (mpls@ietf.org). >>>> >>>> This wglc ends Dec 20, 2013. >>>> >>>> /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 bill.wu@huawei.com Sun Dec 22 18:47:03 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 302931AE634 for ; Sun, 22 Dec 2013 18:47:03 -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 gXSM9gNjB2CY for ; Sun, 22 Dec 2013 18:47:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CF80B1AE141 for ; Sun, 22 Dec 2013 18:46: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 BBR93764; Mon, 23 Dec 2013 02:46:55 +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, 23 Dec 2013 02:46:12 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Dec 2013 02:46:52 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 23 Dec 2013 10:46:45 +0800 From: Qin Wu To: Loa Andersson , "Carlos Pignataro (cpignata)" Thread-Topic: [mpls] Closed: Short wg last call on draft-ietf-mpls-ldp-ipv6 Thread-Index: AQHO/x3CT1+ZE76LOEWosDd5CYb3KJpgip8AgACIblA= Date: Mon, 23 Dec 2013 02:46:44 +0000 Message-ID: References: <52A96B2D.6060003@pi.nu> <52B550D6.3030606@pi.nu> <52B67013.2050907@pi.nu> <88E7475E-8B64-4005-8A5A-780721D6D5AA@cisco.com> <52B7A12C.9030009@pi.nu> In-Reply-To: <52B7A12C.9030009@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@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Closed: Short wg last call on 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, 23 Dec 2013 02:47:03 -0000 Hi,Loa and Carlos: Your proposed follow up is a little bit different. But I am okay with either way.:-), Thanks for taking my comments into accou= nt. Regards! -Qin -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, December 23, 2013 10:34 AM To: Carlos Pignataro (cpignata) Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-ipv6@too= ls.ietf.org Subject: Re: [mpls] Closed: Short wg last call on draft-ietf-mpls-ldp-ipv6 Carlos, Working Group and Qin Wu, Carlos is right, the comments are on the draft in general and not within the scope of the short wglc. The first step after a working group request publication of a document is an "AD Evaluation", rather than waiting for the IETF last call we will blend Qin Wu's comments in when the comments from the AD Evaluation are addressed. I will go ahead and write the shepherd write-up. /Loa On 2013-12-22 21:57, Carlos Pignataro (cpignata) wrote: > Hi, Loa, > > Actually, the comments from Qin Wu are not limited to the changes from the previous WGLC (as the call text specified). They are general comments on the doc. All good and useful that we should discuss and address. > > But as such, I suggest we continue forward without stopping the pub reque= st, and treat these as IETF LC comments and go incorporating them with othe= rs later. > > Thanks, > > -- Carlos. > > > On Dec 21, 2013, at 11:52 PM, Loa Andersson wrote: > >> Working Group, authors and Qin Wu, >> >> The mail closing the wglc was not quite accurate, there are a set of >> comments from Qin Wu (that I had misplaced). I've asked the authors >> to address the comments. >> >> /Loa >> >> On 2013-12-21 16:27, Loa Andersson wrote: >>> Working Group, >>> >>> this wglc is closed. We have not other comments than support. >>> This is what we expect after a penetrating discussion and the wglc >>> limited to the changes based on this discussion. >>> >>> The working group chairs plan to go ahead and request publication. >>> >>> /Loa >>> >>> MPLS WG co-chair >>> >>> On 2013-12-12 15:52, Loa Andersson wrote: >>>> Working Group, >>>> >>>> This is to start a one week working group last call on >>>> draft-ietf-mpls-ldp-ipv6-10 >>>> >>>> We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good >>>> comments and the document almost ready to go. At that point a discussi= on >>>> on the number of LDP session needed between a pair LSRs with both IPv4 >>>> and IPv6 emerged, it has taken us quite a long time to resolve this. >>>> >>>> However, the author, wg chairs and people making the comments now agre= e >>>> that version -10 is resolve those comments. >>>> >>>> This working group last call is limited to the changes since the >>>> previous last call. A diff can be found at: >>>> >>>> http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-ldp-ipv6-07&difftyp= e=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-ldp-ipv6-10 >>>> >>>> >>>> >>>> Please send you comments to the MPLS wg mailing list (mpls@ietf.org). >>>> >>>> This wglc ends Dec 20, 2013. >>>> >>>> /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 > --=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 huub.van.helvoort@huawei.com Mon Dec 23 12:20:42 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 8EFBD1AE291 for ; Mon, 23 Dec 2013 12:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, CN_BODY_457=0.011, CN_BODY_832=0.004, HTML_MESSAGE=0.001, 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 duEV8_JHc7iw for ; Mon, 23 Dec 2013 12:20:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 95F401AE28E for ; Mon, 23 Dec 2013 12:20:37 -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 AZH62358; Mon, 23 Dec 2013 20:20:29 +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; Mon, 23 Dec 2013 20:19:43 +0000 Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 23 Dec 2013 20:20:24 +0000 From: Huub helvoort To: "Ryoo, Jeong-dong" , Loa Andersson , Eric Gray , "mpls@ietf.org" Thread-Topic: Additional comment on draft-ietf-mpls-tp-psc-tu Thread-Index: AQHO/jtDY1mvTxhtN0SYtgHNQbMHUJphDZmAgAEuYag= Date: Mon, 23 Dec 2013 20:20:23 +0000 Message-ID: <73E555AA235F3846B8051DB38C8776272E6B5125@lhreml509-mbx> References: <52B573AA.4060208@pi.nu>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEDB3@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEDB3@SMTP2.etri.info> Accept-Language: en-GB, en-US, zh-CN Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.216.70] Content-Type: multipart/alternative; boundary="_000_73E555AA235F3846B8051DB38C8776272E6B5125lhreml509mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Additional comment on draft-ietf-mpls-tp-psc-tu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 23 Dec 2013 20:20:42 -0000 --_000_73E555AA235F3846B8051DB38C8776272E6B5125lhreml509mbx_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gTG9hLA0KDQoNCg0KVGhhbmsgeW91IGZvciB0ZXN0aW5nIHRoZSBhcHByZWNpYXRpb24g b2YgdGhpcyBkcmFmdC4NCg0KDQoNCklmIGl0IGhlbHBzLCBJIGhhdmUgbm8gb2JqZWN0aW9uIHRv IGFkZCB5b3VyIHByb3Bvc2VkIHNlbnRlbmNlLg0KDQoNCg0KQmVzdCByZWdhcmRzLCBIdXViLg0K DQoNCg0KDQoNCkh1dWIgdmFuIEhlbHZvb3J0LCC6o7jfw/cNClNlbmlvciBDb25zdWx0YW50LCC4 37y2ucvOyg0KSHVhd2VpIFRlY2hub2xvZ2llcyBMdGQsILuqzqq8vMr109DP3rmry74gLSBFdXJv cGVhbiBSZXNlYXJjaCBDZW50ZXIsIMW31t7R0L6/y/kNCkthcnNwZWxkcmVlZiA0LCAxMTAxQ0og QW1zdGVyZGFtLCBUaGUgTmV0aGVybGFuZHMNClRlbDogKzMxIDIwIDQzMDAgOTM2ICAgTW9iOiAr MzEgNiA0OTI0ODkzNg0KDQotLQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KQWx3YXlzIHJlbWVtYmVyIHRoYXQgeW91IGFy ZSB1bmlxdWUuLi4ganVzdCBsaWtlIGV2ZXJ5b25lIGVsc2UuLi4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IFJ5b28sIEplb25nLWRvbmcgW3J5b29AZXRyaS5yZS5r cl0NClNlbnQ6IDIzIERlY2VtYmVyIDIwMTMgMDM6MTYNClRvOiBMb2EgQW5kZXJzc29uOyBFcmlj IEdyYXk7IG1wbHNAaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29s cy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBBZGRp dGlvbmFsIGNvbW1lbnQgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy10dQ0KDQpMb2EsIHRoYW5r cyBmb3IgbGV0dGluZyB1cyBrbm93IG9mIHRoZSByZXNwb25zZSBmcm9tIHBlb3BsZSB3aXRoIGRp ZmZlcmVudCBiYWNrZ3JvdW5kLg0KSSBhbHNvIGFwcHJlY2lhdGUgeW91ciBhdHRlbnRpb24gb24g dGhpcyBkb2N1bWVudC4NCkluIG15IG9waW5pb24sIHlvdXIgcHJvcG9zYWwgaXMgcXVpdGUgY29u c2lkZXJhdGUuDQoNCkplb25nLWRvbmcNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tIDogIkxvYSBBbmRlcnNzb24iIDxsb2FAcGkubnU+DQpTZW50IDogMjAxMy0x Mi0yMSAxOTo1NTo0OSAoICswOTowMCApDQpUbyA6IEVyaWMgR3JheSA8ZXJpYy5ncmF5QGVyaWNz c29uLmNvbT4sIFJ5b28sIEplb25nLWRvbmcgPHJ5b29AZXRyaS5yZS5rcj4sIG1wbHNAaWV0Zi5v cmcgPG1wbHNAaWV0Zi5vcmc+DQpDYyA6IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xz LmlldGYub3JnIDxkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz4sIG1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClN1 YmplY3QgOiBBZGRpdGlvbmFsIGNvbW1lbnQgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy10dQ0K DQpXb3JraW5nIEdyb3VwIGFuZCBFZGl0b3JzLA0KDQpPdmVyIHRoZSBsYXN0IHR3byB3ZWVrcyBJ J3ZlIGhhZCB0aGUgb3Bwb3J0dW5pdHkgdG8gZGlzY3Vzcw0KZHJhZnQtaWV0Zi1tcGxzLXRwLXBz Yy1pdHUgd2l0aCBwZW9wbGUgd2l0aCBkaWZmZXJlbnQgYmFja2dyb3VuZC4NClRoZSByZWFjdGlv biBpcyBtYWlubHkgdmVyeSBwb3NpdGl2ZSA6KS4NCg0KSG93ZXZlciwgdGhlcmUgaXMgb25lIGZl ZWRiYWNrIHRoYXQgSSBnZXQgY29uc2lzdGVudGx5LCB0aGVyZSBpcw0KYSByYXRoZXIgaGlnaCB0 aHJlc2hvbGQgd2hlbiBzdGFydGluZyB0byByZWFkIHRoZSBkb2N1bWVudC4gRXZlbiB0aG91Z2gN CndlIHRha2VuIHN0ZXBzIHRvIHBvaW50IG91dCB0aGF0IHRoZSBzcGVjaWZpY2F0aW9uIGhldmVp bHkgZGVwZW5kcyBvbg0KUkZDIDYzNzgsIEkgdGhpbiB3ZSBzaG91bGQgbWFrZSB0aGlzIGV4cGxp Y2l0Lg0KDQpJIHByb3Bvc2UgdGhhdCB0aGUgYWRkIGEgc2VudGVuY2UgZWFybHkgaW4gdGhlIGlu cm9kdWN0aW9uLCBzb21ldGhpbmcNCmxpa2UgIlRoZSByZWFkZXIgb2YgdGhpcyBkb2N1bWVudCBp cyBhc3N1bWVkIHRvIGJlIGZhbWlsaWFyIHdpdGgNClJGQyA2Mzc4Lg0KDQovTG9hDQotLQ0KDQoN CkxvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KU2VuaW9yIE1QTFMg RXhwZXJ0IGxvYUBwaS5udQ0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6 ICs0NiA3MzkgODEgMjEgNjQNCg== --_000_73E555AA235F3846B8051DB38C8776272E6B5125lhreml509mbx_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hello Loa,

 

Thank you for testing the appreciation of this draft.

 

If it helps, I have no objection to add your proposed sentence.

 

Best regards, Huub.

 

 

Huub van Helvoort, = =BA=A3=B8=DF=C3=F7
Senior Consultant, =B8=DF=BC=B6=B9=CB=CE=CA
Huawei Technologies Ltd, =BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE -= European Research Center, =C5=B7=D6=DE=D1=D0=BE=BF=CB=F9
Karspeldreef 4, 1101CJ Amsterdam, The Netherlands
Tel: +31 20 4300 936   Mob: +31 6 49248936

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Always remember that you are unique... just like everyone else...

From: Ryoo, Jeong-dong [ryoo@etri.re.kr] Sent: 23 December 2013 03:16
To: Loa Andersson; Eric Gray; mpls@ietf.org
Cc: draft-ietf-mpls-tp-psc-itu@tools.ietf.org; mpls-chairs@tools.iet= f.org
Subject: RE: Additional comment on draft-ietf-mpls-tp-psc-tu

Loa, thanks for letting us know of the res= ponse from people with different background.
I also appreciate your attention on this d= ocument.
In my opinion, your proposal is quite cons= iderate.

Jeong-dong

 

From : "Loa Andersson" &l= t;loa@pi.nu>
Sent : 2013-12-21 19:55:49 ( +09:00 )
To : Eric Gray <eric.gray@ericsson.com>, Ryoo, Jeong-dong <= ryoo@etri.re.kr>, mpls@ietf.org <mpls@ietf.org>
Cc : draft-ietf-mpls-tp-psc-itu@tools.ietf.org <draft-ietf-mpls-t= p-psc-itu@tools.ietf.org>, mpls-chairs@tools.ietf.org <mpls-chairs@to= ols.ietf.org>
Subject : Additional comment on draft-ietf-mpls-tp-psc-tu

Working Group and Editors,

Over the last two weeks I've had the opportunity to discuss
draft-ietf-mpls-tp-psc-itu with people with different background.
The reaction is mainly very positive :).

However, there is one feedback that I get consistently, there is
a rather high threshold when starting to read the document. Even though
we taken steps to point out that the specification heveily depends on
RFC 6378, I thin we should make this explicit.

I propose that the add a sentence early in the inroduction, something
like "The reader of this document is assumed to be familiar with
RFC 6378.

/Loa
--


Loa Andersson email: loa@mail01.huawei.com
Senior MPLS Expert loa@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64
--_000_73E555AA235F3846B8051DB38C8776272E6B5125lhreml509mbx_-- From loa@pi.nu Mon Dec 23 20:06:48 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 0BD021AE3EB for ; Mon, 23 Dec 2013 20:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.027 X-Spam-Level: X-Spam-Status: No, score=0.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_457=0.011, CN_BODY_832=0.004, MIME_CHARSET_FARAWAY=2.45, 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 YYIaNAHbSIfp for ; Mon, 23 Dec 2013 20:06:45 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 433F31AE3E7 for ; Mon, 23 Dec 2013 20:06:45 -0800 (PST) Received: from [192.168.1.9] (unknown [112.208.91.36]) (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 5FF951800740; Tue, 24 Dec 2013 05:06:38 +0100 (CET) Message-ID: <52B9084D.1030600@pi.nu> Date: Tue, 24 Dec 2013 12:06:37 +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: Huub helvoort , "Ryoo, Jeong-dong" , Eric Gray , "mpls@ietf.org" References: <52B573AA.4060208@pi.nu>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEDB3@SMTP2.etri.info> <73E555AA235F3846B8051DB38C8776272E6B5125@lhreml509-mbx> In-Reply-To: <73E555AA235F3846B8051DB38C8776272E6B5125@lhreml509-mbx> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Additional comment on draft-ietf-mpls-tp-psc-tu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 24 Dec 2013 04:06:48 -0000 Huub, I think this is one of those things tht don't help much once it is there, but can hurt quite a bit if missing :). /Loa On 2013-12-24 04:20, Huub helvoort wrote: > Hello Loa, > > Thank you for testing the appreciation of this draft. > > If it helps, I have no objection to add your proposed sentence. > > Best regards, Huub. > > Huub van Helvoort, º£¸ßÃ÷ > Senior Consultant, ¸ß¼¶¹ËÎÊ > Huawei Technologies Ltd, »ªÎª¼¼ÊõÓÐÏÞ¹«Ë¾ - European Research Center, Å· > ÖÞÑо¿Ëù > Karspeldreef 4, 1101CJ Amsterdam, The Netherlands > Tel: +31 20 4300 936 Mob: +31 6 49248936 > > -- > ================================================================ > Always remember that you are unique... just like everyone else... > > ------------------------------------------------------------------------ > *From:* Ryoo, Jeong-dong [ryoo@etri.re.kr] > *Sent:* 23 December 2013 03:16 > *To:* Loa Andersson; Eric Gray; mpls@ietf.org > *Cc:* draft-ietf-mpls-tp-psc-itu@tools.ietf.org; mpls-chairs@tools.ietf.org > *Subject:* RE: Additional comment on draft-ietf-mpls-tp-psc-tu > > Loa, thanks for letting us know of the response from people with > different background. > I also appreciate your attention on this document. > In my opinion, your proposal is quite considerate. > > Jeong-dong > > > ------------------------------------------------------------------------ > *From : *"Loa Andersson" > *Sent : *2013-12-21 19:55:49 ( +09:00 ) > *To : *Eric Gray , Ryoo, Jeong-dong > , mpls@ietf.org > *Cc : *draft-ietf-mpls-tp-psc-itu@tools.ietf.org > , mpls-chairs@tools.ietf.org > > *Subject : *Additional comment on draft-ietf-mpls-tp-psc-tu > > Working Group and Editors, > > Over the last two weeks I've had the opportunity to discuss > draft-ietf-mpls-tp-psc-itu with people with different background. > The reaction is mainly very positive :). > > However, there is one feedback that I get consistently, there is > a rather high threshold when starting to read the document. Even though > we taken steps to point out that the specification heveily depends on > RFC 6378, I thin we should make this explicit. > > I propose that the add a sentence early in the inroduction, something > like "The reader of this document is assumed to be familiar with > RFC 6378. > > /Loa > -- > > > 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 Dec 24 00:00:26 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 356701AE0BF for ; Tue, 24 Dec 2013 00:00:26 -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 eYn4vc6nE1_S for ; Tue, 24 Dec 2013 00:00:24 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 573061AD75F for ; Tue, 24 Dec 2013 00:00:24 -0800 (PST) Received: from [192.168.1.9] (unknown [112.208.91.36]) (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 AD5171800740; Tue, 24 Dec 2013 09:00:18 +0100 (CET) Message-ID: <52B93F11.7060608@pi.nu> Date: Tue, 24 Dec 2013 16:00: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: "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-ldp-ipv6@tools.ietf.org" Subject: [mpls] Implementations of 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: Tue, 24 Dec 2013 08:00:26 -0000 Working Group, We are preparing the Shepherd write-up for draft-ietf-mpls-ldp-ipv6 and need to know about existing implementations. If you have an implementation please send a mail to the working group mailing list, the working group chairs or the document shepherd to let us know. Mails directly to chairs or shepherd is fully acceptable. /Loa mpls wg co-chair 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 ryoo@etri.re.kr Wed Dec 25 20:51:29 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 D7B3E1AE139 for ; Wed, 25 Dec 2013 20:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.757 X-Spam-Level: X-Spam-Status: No, score=-98.757 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 eCa1AceRD6hL for ; Wed, 25 Dec 2013 20:51:26 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id EB6021AE131 for ; Wed, 25 Dec 2013 20:51:25 -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, 26 Dec 2013 13:51:19 +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, 26 Dec 2013 13:51:14 +0900 From: "Ryoo, Jeong-dong" To: Yaacov Weingarten Thread-Topic: Question regarding SD protection in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHO9ATofTfzY1WrTkK6rDh0YabjsJpMSsLJgAAiYoCAGZTyhA== Date: Thu, 26 Dec 2013 04:51:13 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info> References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info>, 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.44] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39SMTP2etriinfo_" 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, 26 Dec 2013 04:51:30 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFhY292LCB0aGFua3MgZm9yIHlvdXIgZW1haWwuIFNvbWVob3csIEkgZm9yZ290IHRvIHJlc3Bv bmQgYW5kIGFtIHNvcnJ5IGZvciB0aGUgZGVsYXkuDQoNCkZpcnN0IG9mIGFsbCwgWWFhY292LCBp dCBpcyBub3QgdHJ1ZSB0aGF0IHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBvZiBFdGhlcm5ldCBv ciBTREggZGVzY3JpYmVzIHRoZSBvcGVyYXRpb24gb2YgYW55IGxheWVyIGJlbG93LiBSYXRoZXIs IGVhY2ggbGF5ZXIgaXMgc3VwcG9zZWQgdG8gb3BlcmF0ZSBpbmRlcGVuZGVudGx5LiBIb3dldmVy LCB0aGVyZSBhcmUgYSBmZXcgZXhjZXB0aW9ucywgc3VjaCBhcyBob2xkLW9mZiB0aW1lciBhbmQg QUlTIChhcyBhIHRyaWdnZXIgZnJvbSBsb3dlciBsYXllcikuIEV2ZW4gdGhvdWdoIHRoZXJlIGV4 aXN0IHNvbWUgcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRpb25zIHRoYXQgdXNlIG90aGVyIGluZm9y bWF0aW9uIGZyb20gbG93ZXIgbGF5ZXIsIG1vc3Qgb2YgdGhlbSBhcmUgbm90IHJlY29tbWVuZGVk IGluIElUVS1UIHN0YW5kYXJkcy4NCg0KQnJpZGdlIGFuZCBzZWxlY3RvciBhcmUgbm90IGluIHRo ZSBwaHlzaWNhbCBsYXllciwgYnV0IHRoZXkgYXJlIHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hp bmcuIE9uZSBvZiB0aGUgaW1wb3J0YW50IG91dHB1dCBhY3Rpb25zIGZyb20gdGhlIFBTQyBjb250 cm9sIGxvZ2ljIGlzIGNvb3JkaW5hdGluZyB0aGUgcG9zaXRpb25zIG9mIGJyaWRnZSBhbmQgc2Vs ZWN0b3IuIEFsc28sIHRoZSBicmlkZ2Ugb3BlcmF0aW9uIHJlc3BvbmRpbmcgdG8gdGhlIFBTQyBj b250cm9sIGxvZ2ljIGlzIGFsc28gcGFydCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZy4gSG93ZXZl ciwgaG93IHRvIHJlYWxpemUgdGhlIGJyaWRnZSBhbmQgc2VsZWN0b3IgKGZvciBleGFtcGxlLCBo b3cgdG8gbWFuaXB1bGF0ZSBhIHBhY2tldCBmb3J3YXJkaW5nIG1lY2hhbmlzbSkgaXMgYW4gaW1w bGVtZW50YXRpb24gbWF0dGVyLg0KDQpXaGVuIHdlIG1lbnRpb24gMSsxIG9yIDE6MSBpbiBwcm90 ZWN0aW9uIGFyY2hpdGVjdHVyZSwgd2UgZGVhbCB3aXRoIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdl LiBGb3IgMSsxIGFyY2hpdGVjdHVyZSwgdGhlIHRyYWZmaWMgbmVlZHMgdG8gYmUgZHVwbGljYXRl ZCBhdCB0aGUgc2VuZGVyIGFuZCBzZW50IHRvIGJvdGggcGF0aHMgYWxsIHRoZSB0aW1lLCB3aGlj aCBpcyB0aGUgc2FtZSBkZXNjcmlwdGlvbiBhcyB0aGUg4oCccGVybWFuZW50IGJyaWRnZeKAnS4g Rm9yIDE6MSBhcmNoaXRlY3R1cmUsIOKAnHNlbGVjdG9yIGJyaWRnZeKAnSBpcyB1c2VkIHRvIHNl bmQgdGhlIHRyYWZmaWMgb25seSBvbmUgb2YgdGhlIHBhdGhzLiBBcyB0aGUgcHJvdGVjdGlvbiBw YXRoIGNhbiBiZSB1c2VkIGJ5IGJlc3QgdHJhZmZpYyBpbiBwYWNrZXQgbmV0d29ya3MgYW5kIHRo ZSBwYWNrZXQgZHVwbGljYXRpb24gdGFrZXMgbXVjaCBtb3JlIGVmZm9ydC9pbnRlcm5hbCBiYW5k d2lkdGggaW5zaWRlIGEgc3dpdGNoIHRoYW4gdGhlIHRpbWUgc2xvdCBjb3B5IG9mIGNpcmN1aXQg bmV0d29ya3MuIDE6MSBpcyBjb25zaWRlcmVkIGFzIHByZWZlcmFibGUgYXJjaGl0ZWN0dXJlIGlu IHBhY2tldCBuZXR3b3Jrcy4NCg0KQXMgeW91IG1pZ2h0IHJlY2FsbCBmcm9tIEcuODAzMSDigJMg RXRoZXJuZXQgbGluZWFyIHByb3RlY3Rpb24sIHRoZSBzZWxlY3RvciBicmlkZ2UgaXMgbm90IHJl Y29tbWVuZGVkIGR1ZSB0byB0aGUgdHJhZmZpYyBmbGFwcGluZyB1bmRlciBTRCBjb25kaXRpb25z IG9uIGJvdGggcGF0aHMuIEluc3RlYWQg4oCcYnJvYWRjYXN0IGJyaWRnZeKAnSBpcyBpbnRyb2R1 Y2VkIHRvIHN1cHBvcnQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgYWdhaW5zdCBTRC4gQnV0LCB0aGlz IGJyb2FkY2FzdCBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVkIGluIG5vbi1yZXZlcnRpdmUgbW9k ZSBhcyB0aGUgd29ya2luZyBwYXRoIG5lZWRzIHRvIGJlIG9jY3VwaWVkIGJ5IHRyYWZmaWMgYWxs IHRoZSB0aW1lLiBBbHNvIHRoZSBicm9hZGNhc3QgYnJpZGdlIGlzIG5vdCBlZmZpY2llbnQsIHNp bmNlIGJ5IGRlZmluaXRpb24sIHRoZSBwYWNrZXQgZHVwbGljYXRpb24gc2hvdWxkIG9jY3VyIGR1 cmluZyBub3Qgb25seSBTRCBidXQgYWxzbyBTRiwgRlMsIE1TLCBldGMuIEluIHRoaXMgZG9jdW1l bnQsIHdlIGFyZSBpbnRyb2R1Y2luZyBhbiBpbXByb3ZlZCBicmlkZ2UgbWVjaGFuaXNtLCB3aGlj aCBiZWhhdmVzIGxpa2UgYSBzZWxlY3RvciBicmlkZ2UgYnV0IGR1cGxpY2F0ZXMgdGhlIHRyYWZm aWMgb25seSB1bmRlciBTRCBjb25kaXRpb24sIGFuZCB3ZSBiZWxpZXZlIHRoYXQgaXQgYWRkcmVz c2VzIGFsbCB0aGUgaXNzdWVzIHdpdGggZXhpc3RpbmcgYnJpZGdlcy4NCg0KV2hhdCB3ZSBtZWFu IGJ5IFNEIHByb3RlY3Rpb24gaXMgYWdub3N0aWMgdG8gdGhlIFNEIGRldGVjdGlvbiBtZXRob2Qg aXMgdGhhdCB0aGUgcHJvcG9zZWQgU0QgcHJvdGVjdGlvbiBtZXRob2QgKGFnYWluIGhvdyB0byBv cGVyYXRlIGEgYnJpZGdlIG9yIHdoYXQgYnJpZ2UgaXMgdXNlZCBpcyBhIHBhcnQgb2YgcHJvdGVj dGlvbiBzd2l0Y2hpbmcpIGNhbiBiZSB1c2VkIG5vIG1hdHRlciB3aGF0IGtpbmQgb2YgU0QgZGV0 ZWN0aW9uIG1ldGhvZHMgKGRhdGEgcGFja2V0IGNvdW50aW5nLCBDQ00gcGFja2V0IGNvdW50aW5n LCBvciBldmVuIHByb3ByaWV0YXJ5IHNlcnZlciBsYXllciBTRCBkZXRlY3Rpb24pIGlzIHVzZWQu DQoNCkkgdGhpbmsgSSBhbnN3ZXJlZCBhbGwgdGhlIHF1ZXN0aW9ucyBvbiB5b3VyIGVtYWlsLg0K DQpZYWFjb3YsIGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbmNlcm5zIG9yIHF1ZXN0aW9ucywg cGxlYXNlIGxldCBtZSBrbm93Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tIDogIllhYWNvdiBXZWluZ2Fy dGVuIiA8d3lhYWNvdkBnbWFpbC5jb20+DQpTZW50IDogMjAxMy0xMi0xMCAxNjowNDoxNyAoICsw OTowMCApDQpUbyA6IFJ5b28sIEplb25nLWRvbmcgPHJ5b29AZXRyaS5yZS5rcj4NCkNjIDogZHJh ZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcgPGRyYWZ0LWlldGYtbXBscy10 cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPiwgbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4N ClN1YmplY3QgOiBSZTogUXVlc3Rpb24gcmVnYXJkaW5nIFNEIHByb3RlY3Rpb24gaW4gZHJhZnQt aWV0Zi1tcGxzLXRwLXBzYy1pdHUNCg0KSmVvbmctZG9uZywgaGkNCg0KVGhhbmsgeW91IGZvciB5 b3VyIHJlcGx5LiBZb3VyIGFuc3dlciBzZWVtcyB0byBiZSBhbiBhcHByb3ByaWF0ZSBhbnN3ZXIg Zm9yIG90aGVyIFNET3MsIG5vdCBzdXJlIHRoYXQgaXQgaXMgdHJ1ZSBmb3IgdGhlIGNvbnRleHQg b2YgTVBMUyBhbmQgSUVURiB3b3JrLg0KDQoxLiBZb3Ugd3JvdGUgImFueSBwcm90ZWN0aW9uIHN3 aXRjaGluZyAoaW5jbHVkaW5nIFBTQykgaXMgc3VwcG9zZWQgdG8gZGVzY3JpYmUgdGhlIG9wZXJh dGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiIgLSB0aGlzIG1heSBiZSB0cnVlIGZvciBFdGhl cm5ldCBhbmQgU0RIIGFuZCBmb3IgZG9jdW1lbnRzIHRoYXQgYXJlIGRlc2NyaWJpbmcgdGhlIG9w ZXJhdGlvbiBvZiB0aGUgcGh5c2ljYWwgbGF5ZXIuIEhvd2V2ZXIsIHRoZSBJRVRGICh0byBteSB1 bmRlcnN0YW5kaW5nIC0gYW5kIEkgYW0gY2VydGFpbmx5IHdpbGxpbmcgdG8gYmUgY29ycmVjdGVk IG9uIHRoaXMgcG9pbnQpIGlzIGNvbmNlcm5lZCB3aXRoIHRoZSBwcm90b2NvbCBhbmQgbGVhdmUg dGhlIGxvd2VyIGxheWVycyB0byBpbXBsZW1lbnRhdGlvbi4gQWxzbywgSSBhbSBub3Qgc3VyZSB0 aGF0IHRoZSBjb25jZXB0cyBvZiBCcmlkZ2UgYW5kIFNlbGVjdG9yIHJlYWxseSBhcHBseSB0byBN UExTIChhbHRob3VnaCBJIGFkbWl0IHRoYXQgd2UgZGlkIG1lbnRpb24gdGhlbSBpbiB0aGUgb3Jp Z2luYWwgUFNDIGRlZmluaXRpb24pLg0KDQoyLiBZb3UgY2l0ZSB3aGF0IHdhcyB3cml0dGVuIGlu IEc4MDMxIGFzIGp1c3RpZmljYXRpb24gZm9yIGluY2x1ZGluZyBjb250ZW50IGludG8geW91ciBk cmFmdC4gQWdhaW4gaXQgaXMgaGFyZCB0byB0cmFuc2ZlciBtZXRob2RvbG9neSBmcm9tIG9uZSBT RE8gdG8gYW5vdGhlciBhbmQgdGhlcmVmb3JlLCB3aGlsZSBJIGhpZ2hseSByZXNwZWN0IHRoZSB3 b3JrIG9mIHRoZSBJVFUsIEkgZG8gbm90IGZlZWwgdGhhdCB0aGlzIGlzIGEgdmVyeSBjbGVhciBq dXN0aWZpY2F0aW9uIGZvciBpbmNsdXNpb24gaW50byBhbiBpbnRlcm5ldC1kcmFmdC4gRXZlbiB3 aGVuIHRoZSBkcmFmdCBzdGF0ZXMgdGhhdCBpdHMgcHVycG9zZSBpcyB0byBhZGRyZXNzIHRoZSBj b25jZXJucyBvZiB0aGUgSVRVLg0KDQozLiBUbyB0aGUgYWN0dWFsIHBvaW50IG9mIG15IGVhcmxp ZXIgY29tbWVudCwgdGhhdCB5b3UgZG8gbm90IHNlZW0gdG8gYWRkcmVzcyAtIHRoZSBwYXJhZ3Jh cGggaW4gU2VjdGlvbiA3LjMgc2VlbXMgdG8gc3RhdGUgdGhhdCBTRCBwcm90ZWN0aW9uIGNoYW5n ZXMgYWNjb3JkaW5nIHRvIHRoZSBtZXRob2QgdGhhdCBpcyB1c2VkIHRvIGRldGVjdCB0aGUgU0Qu IFRoaXMgbWVhbnMgdGhhdCBTRCBwcm90ZWN0aW9uIGlzIG5vdCBhZ25vc3RpYyB0byB0aGUgbWV0 aG9kIHVzZWQgZm9yIHRoZSBkZXRlY3Rpb24uDQpBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCBicmVh ayB0aGlzIGRlcGVuZGVuY2UgYW5kIHN0YXRlIHRoYXQgU0QgcHJvdGVjdGlvbiBpcyBhbHdheXMg cHJvdmlkZWQgYnkgY2hhbmdpbmcgdGhlIHRyYW5zbWlzc2lvbiBvZiB0aGUgZGF0YSB0byAxKzEg cHJvdGVjdGlvbiBpbiBjYXNlcyBvZiBTRCBkZXRlY3Rpb24sIHdoaWNoIGlzIHdoYXQgdGhlIHBh cmFncmFwaCBpcyBzdWdnZXN0aW5nIHRvIGRvIGZvciBzb21lIGNhc2VzLg0KDQpJIGhvcGUgdGhp cyBmb3JtdWxhdGlvbiBtYWtlIG15IGNvbW1lbnQgY2xlYXJlciBhbmQgd2UgYXJlIGFibGUgdG8g ZGlzY3VzcyB0aGUgdGVjaG5vbG9naWNhbCBhcHByb2FjaCByYXRoZXIgdGhhbiB0aGUgcGhpbG9z b3BoaWNhbCBkaWZmZXJlbmNlcy4NCg0KVGhhbmsgeW91LA0KeWFhY292DQoNCg0KT24gTW9uLCBE ZWMgOSwgMjAxMyBhdCAxMDowNCBQTSwgUnlvbywgSmVvbmctZG9uZyA8cnlvb0BldHJpLnJlLmty PG1haWx0bzpyeW9vQGV0cmkucmUua3I+PiB3cm90ZToNCllhYWNvdiwNCg0KWWVzLCBQU0MgaXMg c3VwcG9zZWQgdG8gYmUgYWdub3N0aWMgdG8gdGhlIG1ldGhvZCB1c2VkIGZvciB0aGUgZGV0ZWN0 aW9uIG9mIFNGL1NELg0KDQpJdCBpcyBhbHNvIHRydWUgdGhhdCBhbnkgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcgKGluY2x1ZGluZyBQU0MpIGlzIHN1cHBvc2VkIHRvIGRlc2NyaWJlIHRoZSBvcGVyYXRp b24gb2YgYnJpZGdlIGFuZCBzZWxlY3Rvci4NCg0KQXMgdGhlcmUgYXJlIG11bHRpcGxlIG9wdGlv bnMgZm9yIGRldGVjdGluZyBTRCwgd2UgbmVlZGVkIHRvIGRlc2NyaWJlIHRoZSBiZWhhdmlvciBv ZiB0aGUgYnJpZGdlIHRvIGNvdmVyIGFsbCB0aGUgcG9zc2libGUgZGV0ZWN0aW9uIG1ldGhvZHMu IERlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgZm9yIFNEIHByb3RlY3Rpb24gaXMg bm90IGEgbmV3IHRoaW5nLiBGb3IgZXhhbXBsZSwgRy44MDMxIC0gRXRoZXJuZXQgbGluZWFyIHBy b3RlY3Rpb24gYWxzbyBkZXNjcmliZXMgd2hhdCBicmlkZ2UgY2FuIGJlIHVzZWQgaW4gb3JkZXIg dG8gcHJvdmlkZSBwcm90ZWN0aW9uIGFnYWluc3QgU0QuDQoNCkJlc3QgcmVnYXJkcywNCg0KSmVv bmctZG9uZw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb20gOiAi WWFhY292IFdlaW5nYXJ0ZW4iIDx3eWFhY292QGdtYWlsLmNvbTxtYWlsdG86d3lhYWNvdkBnbWFp bC5jb20+Pg0KU2VudCA6IDIwMTMtMTItMDggMjA6MDE6NTUgKCArMDk6MDAgKQ0KVG8gOiBkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+IDxkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dUB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMu aWV0Zi5vcmc+PiwgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4gPG1wbHNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Pg0KQ2MgOg0KU3ViamVjdCA6IFF1ZXN0aW9uIHJl Z2FyZGluZyBTRCBwcm90ZWN0aW9uIGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQoNCg0K SGksDQoNCkFmdGVyIHJlYWRpbmcgdGhyb3VnaCB5b3VyIGRyYWZ0IG9uIHRoZSBleHRlbnNpb25z IHRvIFBTQyB0byBzdXBwb3J0IFNEIHNpdHVhdGlvbnMsIEkgaGF2ZSBhIHF1ZXN0aW9uIGZvciBj bGFyaWZpY2F0aW9uIC0NCkluIHlvdXIgaW50cm9kdWN0aW9uIC0geW91IHN0YXRlIHRoYXQgdGhl IG1ldGhvZCB1c2VkIHRvIGRldGVjdCBTRCBzaXR1YXRpb25zIGlzIG91dC1vZi1zY29wZSBvZiB0 aGUgZG9jdW1lbnQuIERvZXMgdGhpcyBtZWFuIHRoYXQgUFNDIGlzIHN1cHBvc2VkIHRvIGJlIGFn bm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhpcyBkZXRlY3Rpb24/IEl0IHNob3VsZCBy ZWFjdCBvbmx5IHRvIHRoZSBpbmRpY2F0aW9uLCBzaW1pbGFybHkgdG8gdGhlIHJlYWN0aW9uIGFu ZCByZWxhdGlvbnNoaXAgdG8gdGhlIG1ldGhvZCBmb3IgZGV0ZWN0aW5nIGFuZCBkZWNsYXJpbmcg YSBTRiBzaXR1YXRpb24uDQpIb3dldmVyLCB3aGVuIHlvdSBleHBsYWluIHRoZSBiZWhhdmlvciBv ZiB0aGUgU0QgcHJvdGVjdGlvbiBpbiBzZWN0aW9uIDcuMyB5b3UgaGF2ZSBhIHBhcmFncmFwaCB0 aGF0IHN0YXJ0cyB3aXRoICJJZiB0aGUgZGV0ZWN0aW9uIG9mIGEgU0QgZGVwZW5kcyBvbiB0aGUg cHJlc2VuY2Ugb2YgdXNlciBkYXRhIHBhY2tldHMgLi4uIiAgdGhhdCBzZWVtcyB0byBpbmRpY2F0 ZSB0aGF0IHRoZSBiZWhhdmlvciBvZiB0aGUgc3lzdGVtIGlzIGRlcGVuZGVudCB1cG9uIHRoZSBk ZXRlY3Rpb24gbWV0aG9kISBDbGFyaWZpY2F0aW9uIHdvdWxkIGJlIGFwcHJlY2lhdGVkLg0KDQot LQ0KVGhhbnggYW5kIEJSLA0KeWFhY292DQoNClN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1 bml0eQ0KDQoNCg0KLS0NClRoYW54IGFuZCBCUiwNCnlhYWNvdg0KDQpTdGlsbCBsb29raW5nIGZv ciBuZXcgb3Bwb3J0dW5pdHkNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPllhYWNvdiwgdGhhbmtzIGZvciB5b3VyIGVtYWlsLiZuYnNwO1NvbWVob3cs IEkgZm9yZ290IHRvIHJlc3BvbmQgYW5kIGFtIHNvcnJ5IGZvciB0aGUgZGVsYXkuPC9mb250Pjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48L2ZvbnQ+ PC9zcGFuPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PkZpcnN0IG9mIGFsbCwgWWFhY292LCBpdCBpcyBub3QgdHJ1ZSB0aGF0IHRoZSBwcm90ZWN0aW9u IHN3aXRjaGluZyBvZiBFdGhlcm5ldCBvciBTREggZGVzY3JpYmVzIHRoZSBvcGVyYXRpb24gb2Yg YW55IGxheWVyIGJlbG93LiBSYXRoZXIsIGVhY2ggbGF5ZXIgaXMgc3VwcG9zZWQgdG8gb3BlcmF0 ZQ0KIGluZGVwZW5kZW50bHkuIEhvd2V2ZXIsIHRoZXJlIGFyZSBhIGZldyBleGNlcHRpb25zLCBz dWNoIGFzIGhvbGQtb2ZmIHRpbWVyIGFuZCBBSVMgKGFzIGEgdHJpZ2dlciBmcm9tIGxvd2VyIGxh eWVyKS4gRXZlbiB0aG91Z2ggdGhlcmUgZXhpc3Qgc29tZSBwcm9wcmlldGFyeSBpbXBsZW1lbnRh dGlvbnMgdGhhdCB1c2Ugb3RoZXIgaW5mb3JtYXRpb24gZnJvbSBsb3dlciBsYXllciwgbW9zdCBv ZiB0aGVtIGFyZSBub3QgcmVjb21tZW5kZWQgaW4gSVRVLVQNCiBzdGFuZGFyZHMuIDwvZm9udD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4g bGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjwvZm9udD48L3NwYW4+PC9m b250Pjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg 65SVIj5CcmlkZ2UgYW5kIHNlbGVjdG9yIGFyZSBub3QgaW4gdGhlIHBoeXNpY2FsIGxheWVyLCBi dXQgdGhleSBhcmUgcGFydCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZy4gT25lIG9mIHRoZSBpbXBv cnRhbnQgb3V0cHV0IGFjdGlvbnMgZnJvbSB0aGUgUFNDIGNvbnRyb2wgbG9naWMgaXMgY29vcmRp bmF0aW5nDQogdGhlIHBvc2l0aW9ucyBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiBBbHNvLCB0aGUg YnJpZGdlIG9wZXJhdGlvbiByZXNwb25kaW5nIHRvIHRoZSBQU0MgY29udHJvbCBsb2dpYyBpcyBh bHNvIHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIEhvd2V2ZXIsIGhvdyB0byByZWFsaXpl IHRoZSBicmlkZ2UgYW5kIHNlbGVjdG9yIChmb3IgZXhhbXBsZSwgaG93IHRvIG1hbmlwdWxhdGUg YSBwYWNrZXQgZm9yd2FyZGluZyBtZWNoYW5pc20pIGlzIGFuDQogaW1wbGVtZW50YXRpb24gbWF0 dGVyLiA8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48L2Zv bnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+V2hlbiB3ZSBtZW50aW9uIDEmIzQzOzEgb3IgMToxIGluIHByb3Rl Y3Rpb24gYXJjaGl0ZWN0dXJlLCB3ZSBkZWFsIHdpdGggdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2Uu IEZvciAxJiM0MzsxIGFyY2hpdGVjdHVyZSwgdGhlIHRyYWZmaWMgbmVlZHMgdG8gYmUgZHVwbGlj YXRlZCBhdCB0aGUgc2VuZGVyIGFuZCBzZW50DQogdG8gYm90aCBwYXRocyBhbGwgdGhlIHRpbWUs IHdoaWNoIGlzIHRoZSBzYW1lIGRlc2NyaXB0aW9uIGFzIHRoZSDigJxwZXJtYW5lbnQgYnJpZGdl 4oCdLiBGb3IgMToxIGFyY2hpdGVjdHVyZSwg4oCcc2VsZWN0b3IgYnJpZGdl4oCdIGlzIHVzZWQg dG8gc2VuZCB0aGUgdHJhZmZpYyBvbmx5IG9uZSBvZiB0aGUgcGF0aHMuDQo8L2ZvbnQ+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5BcyB0aGUgcHJv dGVjdGlvbiBwYXRoIGNhbiBiZSB1c2VkIGJ5Jm5ic3A7YmVzdCB0cmFmZmljIGluIHBhY2tldCBu ZXR3b3JrcyBhbmQgdGhlIHBhY2tldCBkdXBsaWNhdGlvbiB0YWtlcyBtdWNoIG1vcmUgZWZmb3J0 L2ludGVybmFsIGJhbmR3aWR0aCBpbnNpZGUgYSBzd2l0Y2ggdGhhbiB0aGUgdGltZSBzbG90IGNv cHkgb2YgY2lyY3VpdCBuZXR3b3Jrcy4gMToxIGlzDQogY29uc2lkZXJlZCBhcyBwcmVmZXJhYmxl IGFyY2hpdGVjdHVyZSBpbiBwYWNrZXQgbmV0d29ya3MuIDwvZm9udD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj4mbmJz cDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5BcyB5b3UgbWln aHQgcmVjYWxsIGZyb20gRy44MDMxIOKAkyBFdGhlcm5ldCBsaW5lYXIgcHJvdGVjdGlvbiwgdGhl IHNlbGVjdG9yIGJyaWRnZSBpcyBub3QgcmVjb21tZW5kZWQgZHVlIHRvIHRoZSB0cmFmZmljIGZs YXBwaW5nIHVuZGVyIFNEIGNvbmRpdGlvbnMgb24gYm90aCBwYXRocy4gSW5zdGVhZA0KIOKAnGJy b2FkY2FzdCBicmlkZ2XigJ0gaXMgaW50cm9kdWNlZCB0byBzdXBwb3J0IHByb3RlY3Rpb24gc3dp dGNoaW5nIGFnYWluc3QgU0QuIEJ1dCwgdGhpcyBicm9hZGNhc3QgYnJpZGdlIGlzIG5vdCByZWNv bW1lbmRlZCBpbiBub24tcmV2ZXJ0aXZlIG1vZGUgYXMgdGhlIHdvcmtpbmcgcGF0aCBuZWVkcyB0 byBiZSBvY2N1cGllZCBieSB0cmFmZmljIGFsbCB0aGUgdGltZS4gQWxzbyB0aGUgYnJvYWRjYXN0 IGJyaWRnZSBpcyBub3QgZWZmaWNpZW50LCBzaW5jZQ0KIGJ5IGRlZmluaXRpb24sIHRoZSBwYWNr ZXQgZHVwbGljYXRpb24gc2hvdWxkIG9jY3VyIGR1cmluZyBub3Qgb25seSBTRCBidXQgYWxzbyBT RiwgRlMsIE1TLCBldGMuIEluIHRoaXMgZG9jdW1lbnQsIHdlIGFyZSBpbnRyb2R1Y2luZyBhbiBp bXByb3ZlZCBicmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhhdmVzIGxpa2UgYSBzZWxlY3RvciBi cmlkZ2UgYnV0IGR1cGxpY2F0ZXMgdGhlIHRyYWZmaWMgb25seSZuYnNwO3VuZGVyIFNEIGNvbmRp dGlvbiwgYW5kDQogd2UgYmVsaWV2ZSB0aGF0IGl0IGFkZHJlc3NlcyBhbGwgdGhlIGlzc3VlcyB3 aXRoIGV4aXN0aW5nIGJyaWRnZXMuIDwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5XaGF0IHdlIG1lYW4gYnkgU0QgcHJv dGVjdGlvbiBpcyBhZ25vc3RpYyB0byB0aGUgU0QgZGV0ZWN0aW9uIG1ldGhvZCBpcyB0aGF0IHRo ZSBwcm9wb3NlZCBTRCBwcm90ZWN0aW9uIG1ldGhvZCAoYWdhaW4gaG93IHRvIG9wZXJhdGUgYSBi cmlkZ2Ugb3Igd2hhdCZuYnNwO2JyaWdlIGlzIHVzZWQgaXMgYQ0KIHBhcnQgb2YgcHJvdGVjdGlv biBzd2l0Y2hpbmcpIGNhbiBiZSB1c2VkIG5vIG1hdHRlciB3aGF0IGtpbmQgb2YgU0QgZGV0ZWN0 aW9uIG1ldGhvZHMgKGRhdGEgcGFja2V0IGNvdW50aW5nLCBDQ00gcGFja2V0IGNvdW50aW5nLCBv ciBldmVuIHByb3ByaWV0YXJ5IHNlcnZlciBsYXllciBTRCBkZXRlY3Rpb24pIGlzIHVzZWQuPC9m b250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PC9mb250Pjwvc3Bh bj48L2ZvbnQ+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBw dCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9Iuunkeyd gCDqs6DrlJUiPkkgdGhpbmsgSSBhbnN3ZXJlZCBhbGwgdGhlIHF1ZXN0aW9ucyBvbiB5b3VyIGVt YWlsLjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPllhYWNvdiwgaWYgeW91IGhhdmUg YW55IGZ1cnRoZXIgY29uY2VybnMgb3IgcXVlc3Rpb25zLCBwbGVhc2UgbGV0IG1lIGtub3cuPC9m b250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PC9mb250Pjwvc3Bh bj48L2ZvbnQ+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBw dCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9Iuunkeyd gCDqs6DrlJUiPkJlc3QgcmVnYXJkcyw8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJH SU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+SmVvbmctZG9uZzwvZm9udD48L3NwYW4+PC9w Pg0KPGJyPg0KPGJyPg0KPGRpdiBpZD0iTWFpbFNpZ25TZW50Ij48YnI+DQo8L2Rpdj4NCjxociB0 YWJpbmRleD0iLTEiPg0KPGI+RnJvbSA6IDwvYj4mcXVvdDtZYWFjb3YgV2VpbmdhcnRlbiZxdW90 OyAmbHQ7d3lhYWNvdkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U2VudCA6IDwvYj4yMDEzLTEyLTEw IDE2OjA0OjE3ICggJiM0MzswOTowMCApPGJyPg0KPGI+VG8gOiA8L2I+UnlvbywgSmVvbmctZG9u ZyAmbHQ7cnlvb0BldHJpLnJlLmtyJmd0Ozxicj4NCjxiPkNjIDogPC9iPmRyYWZ0LWlldGYtbXBs cy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnICZsdDtkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dUB0b29scy5pZXRmLm9yZyZndDssIG1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5SZTogUXVlc3Rpb24gcmVnYXJkaW5nIFNEIHByb3RlY3Rp b24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHU8YnI+DQo8YnI+DQo8ZGl2IGRpcj0ibHRy Ij5KZW9uZy1kb25nLCBoaQ0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmsgeW91IGZvciB5 b3VyIHJlcGx5LiBZb3VyIGFuc3dlciBzZWVtcyB0byBiZSBhbiBhcHByb3ByaWF0ZSBhbnN3ZXIg Zm9yIG90aGVyIFNET3MsIG5vdCBzdXJlIHRoYXQgaXQgaXMgdHJ1ZSBmb3IgdGhlIGNvbnRleHQg b2YgTVBMUyBhbmQgSUVURiB3b3JrLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+MS4g WW91IHdyb3RlICZxdW90OzxzcGFuIHN0eWxlPSJMSU5FLUhFSUdIVDogMjBweDsgRk9OVC1GQU1J TFk6ICfrp5HsnYDqs6DrlJUnOyBGT05ULVNJWkU6IDEzcHgiPmFueSBwcm90ZWN0aW9uIHN3aXRj aGluZyAoaW5jbHVkaW5nIFBTQykgaXMgc3VwcG9zZWQgdG8gZGVzY3JpYmUgdGhlIG9wZXJhdGlv biBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiZxdW90OyAtDQo8L3NwYW4+PHNwYW4gc3R5bGU9IkxJ TkUtSEVJR0hUOiAyMHB4OyBGT05ULVNJWkU6IDEzcHgiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2 ZXRpY2EsIHNhbnMtc2VyaWYiPnRoaXMgbWF5IGJlIHRydWUgZm9yIEV0aGVybmV0IGFuZDwvZm9u dD48L3NwYW4+PHNwYW4gc3R5bGU9IkxJTkUtSEVJR0hUOiAyMHB4OyBGT05ULUZBTUlMWTogJ+un keydgOqzoOuUlSc7IEZPTlQtU0laRTogMTNweCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJM SU5FLUhFSUdIVDogMjBweDsgRk9OVC1TSVpFOiAxM3B4Ij48Zm9udCBmYWNlPSJhcmlhbCwgaGVs dmV0aWNhLCBzYW5zLXNlcmlmIj5TREgNCiBhbmQgZm9yIGRvY3VtZW50cyB0aGF0IGFyZSBkZXNj cmliaW5nIHRoZSBvcGVyYXRpb24gb2YgdGhlIHBoeXNpY2FsIGxheWVyLiBIb3dldmVyLCB0aGUg SUVURiAodG8gbXkgdW5kZXJzdGFuZGluZyAtIGFuZCBJIGFtIGNlcnRhaW5seSB3aWxsaW5nIHRv IGJlIGNvcnJlY3RlZCBvbiB0aGlzIHBvaW50KSBpcyBjb25jZXJuZWQgd2l0aCB0aGUgcHJvdG9j b2wgYW5kIGxlYXZlIHRoZSBsb3dlciBsYXllcnMgdG8gaW1wbGVtZW50YXRpb24uIEFsc28sDQog SSBhbSBub3Qgc3VyZSB0aGF0IHRoZSBjb25jZXB0cyBvZiBCcmlkZ2UgYW5kIFNlbGVjdG9yIHJl YWxseSBhcHBseSB0byBNUExTIChhbHRob3VnaCBJIGFkbWl0IHRoYXQgd2UgZGlkIG1lbnRpb24g dGhlbSBpbiB0aGUgb3JpZ2luYWwgUFNDIGRlZmluaXRpb24pLjwvZm9udD48L3NwYW4+PC9kaXY+ DQo8ZGl2PjxzcGFuIHN0eWxlPSJMSU5FLUhFSUdIVDogMjBweDsgRk9OVC1TSVpFOiAxM3B4Ij48 Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9z cGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHg7IEZPTlQtU0la RTogMTNweCI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Mi4gWW91 IGNpdGUgd2hhdCB3YXMgd3JpdHRlbiBpbiBHODAzMSBhcyBqdXN0aWZpY2F0aW9uIGZvciBpbmNs dWRpbmcgY29udGVudCBpbnRvIHlvdXIgZHJhZnQuIEFnYWluIGl0IGlzIGhhcmQgdG8gdHJhbnNm ZXIgbWV0aG9kb2xvZ3kgZnJvbSBvbmUgU0RPIHRvIGFub3RoZXIgYW5kDQogdGhlcmVmb3JlLCB3 aGlsZSBJIGhpZ2hseSByZXNwZWN0IHRoZSB3b3JrIG9mIHRoZSBJVFUsIEkgZG8gbm90IGZlZWwg dGhhdCB0aGlzIGlzIGEgdmVyeSBjbGVhciBqdXN0aWZpY2F0aW9uIGZvciBpbmNsdXNpb24gaW50 byBhbiBpbnRlcm5ldC1kcmFmdC4gRXZlbiB3aGVuIHRoZSBkcmFmdCBzdGF0ZXMgdGhhdCBpdHMg cHVycG9zZSBpcyB0byBhZGRyZXNzIHRoZSBjb25jZXJucyBvZiB0aGUgSVRVLjwvZm9udD48L3Nw YW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJMSU5FLUhFSUdIVDogMjBweDsgRk9OVC1TSVpF OiAxM3B4Ij48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48YnI+DQo8 L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHg7 IEZPTlQtU0laRTogMTNweCI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJp ZiI+My4gVG8gdGhlIGFjdHVhbCBwb2ludCBvZiBteSBlYXJsaWVyIGNvbW1lbnQsIHRoYXQgeW91 IGRvIG5vdCBzZWVtIHRvIGFkZHJlc3MgLSB0aGUgcGFyYWdyYXBoIGluIFNlY3Rpb24gNy4zIHNl ZW1zIHRvIHN0YXRlIHRoYXQgU0QgcHJvdGVjdGlvbiBjaGFuZ2VzIGFjY29yZGluZw0KIHRvIHRo ZSBtZXRob2QgdGhhdCBpcyB1c2VkIHRvIGRldGVjdCB0aGUgU0QuIFRoaXMgbWVhbnMgdGhhdCBT RCBwcm90ZWN0aW9uIGlzIG5vdCBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoZSBk ZXRlY3Rpb24uPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9IkxJTkUtSEVJ R0hUOiAyMHB4OyBGT05ULVNJWkU6IDEzcHgiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2Es IHNhbnMtc2VyaWYiPkFsdGVybmF0aXZlbHksIHdlIGNvdWxkIGJyZWFrIHRoaXMgZGVwZW5kZW5j ZSBhbmQgc3RhdGUgdGhhdCBTRCBwcm90ZWN0aW9uIGlzIGFsd2F5cyBwcm92aWRlZCBieSBjaGFu Z2luZyB0aGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBkYXRhIHRvIDEmIzQzOzEgcHJvdGVjdGlvbiBp biBjYXNlcw0KIG9mIFNEIGRldGVjdGlvbiwgd2hpY2ggaXMgd2hhdCB0aGUgcGFyYWdyYXBoIGlz IHN1Z2dlc3RpbmcgdG8gZG8gZm9yIHNvbWUgY2FzZXMuPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9 IkxJTkUtSEVJR0hUOiAyMHB4Ij48YnI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0iTElORS1I RUlHSFQ6IDIwcHgiPkkgaG9wZSB0aGlzIGZvcm11bGF0aW9uIG1ha2UgbXkgY29tbWVudCBjbGVh cmVyIGFuZCB3ZSBhcmUgYWJsZSB0byBkaXNjdXNzIHRoZSB0ZWNobm9sb2dpY2FsIGFwcHJvYWNo IHJhdGhlciB0aGFuIHRoZSBwaGlsb3NvcGhpY2FsIGRpZmZlcmVuY2VzLjwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxz cGFuIHN0eWxlPSJMSU5FLUhFSUdIVDogMjBweCI+PGJyPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+PHNwYW4gc3R5 bGU9IkxJTkUtSEVJR0hUOiAyMHB4Ij5UaGFuayB5b3UsPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9 IkxJTkUtSEVJR0hUOiAyMHB4Ij55YWFjb3Y8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPk9uIE1vbiwgRGVjIDksIDIwMTMgYXQgMTA6MDQgUE0sIFJ5b28sIEplb25nLWRvbmcgPHNw YW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpyeW9vQGV0cmkucmUua3IiIHRhcmdl dD0iX2JsYW5rIj5yeW9vQGV0cmkucmUua3I8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJs b2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZDsgTUFSR0lOOiAwcHgg MHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBGT05ULVNJWkU6IDEwcHQiPg0K PGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5Z YWFjb3YsPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQi IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPlllcywgUFNDIGlzIHN1cHBvc2VkIHRvIGJlIGFnbm9zdGljIHRvIHRoZSBt ZXRob2QgdXNlZCBmb3IgdGhlIGRldGVjdGlvbiBvZiBTRi9TRC4NCjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5JdCBpcyBhbHNv IHRydWUgdGhhdCBhbnkgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGluY2x1ZGluZyBQU0MpIGlzIHN1 cHBvc2VkIHRvIGRlc2NyaWJlIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGFuZCBzZWxlY3Rvci4N CjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQi IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5BcyB0aGVyZSBhcmUgbXVsdGlwbGUgb3B0aW9ucyBmb3IgZGV0ZWN0aW5nIFNELCB3 ZSBuZWVkZWQgdG8gZGVzY3JpYmUgdGhlIGJlaGF2aW9yIG9mIHRoZSBicmlkZ2UgdG8gY292ZXIg YWxsIHRoZSBwb3NzaWJsZSBkZXRlY3Rpb24gbWV0aG9kcy4gRGVzY3JpYmluZyB0aGUgb3BlcmF0 aW9uIG9mDQogYnJpZGdlIGZvciBTRCBwcm90ZWN0aW9uIGlzIG5vdCBhIG5ldyB0aGluZy4gRm9y IGV4YW1wbGUsIEcuODAzMSAtIEV0aGVybmV0IGxpbmVhciBwcm90ZWN0aW9uIGFsc28gZGVzY3Jp YmVzIHdoYXQmbmJzcDticmlkZ2UgY2FuJm5ic3A7YmUgdXNlZCBpbiBvcmRlciB0byBwcm92aWRl IHByb3RlY3Rpb24gYWdhaW5zdCBTRC4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBzdHls ZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5CZXN0IHJlZ2FyZHMsPC9mb250Pjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPkplb25n LWRvbmc8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxicj4NCjxicj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 aHI+DQo8Yj5Gcm9tIDogPC9iPiZxdW90O1lhYWNvdiBXZWluZ2FydGVuJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86d3lhYWNvdkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj53eWFhY292QGdt YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U2VudCA6IDwvYj4yMDEzLTEyLTA4IDIwOjAxOjU1ICgg JiM0MzswOTowMCApPGJyPg0KPGI+VG8gOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYt bXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0 Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86 ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZzwvYT4mZ3Q7LA0KPGEg aHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3Jn PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t cGxzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYyA6IDwvYj48YnI+DQo8Yj5TdWJqZWN0IDog PC9iPlF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9uIGluIGRyYWZ0LWlldGYtbXBscy10 cC1wc2MtaXR1DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPjxicj4NCjxicj4NCjxkaXYgZGlyPSJs dHIiPkhpLA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHlv dXIgZHJhZnQgb24gdGhlIGV4dGVuc2lvbnMgdG8gUFNDIHRvIHN1cHBvcnQgU0Qgc2l0dWF0aW9u cywgSSBoYXZlIGEgcXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb24gLTwvZGl2Pg0KPGRpdj5JbiB5 b3VyIGludHJvZHVjdGlvbiAtIHlvdSBzdGF0ZSB0aGF0IHRoZSBtZXRob2QgdXNlZCB0byBkZXRl Y3QgU0Qgc2l0dWF0aW9ucyBpcyBvdXQtb2Ytc2NvcGUgb2YgdGhlIGRvY3VtZW50LiBEb2VzIHRo aXMgbWVhbiB0aGF0IFBTQyBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9k IHVzZWQgZm9yIHRoaXMgZGV0ZWN0aW9uPyBJdCBzaG91bGQgcmVhY3Qgb25seSB0byB0aGUgaW5k aWNhdGlvbiwgc2ltaWxhcmx5IHRvDQogdGhlIHJlYWN0aW9uIGFuZCByZWxhdGlvbnNoaXAgdG8g dGhlIG1ldGhvZCBmb3IgZGV0ZWN0aW5nIGFuZCBkZWNsYXJpbmcgYSBTRiBzaXR1YXRpb24uPC9k aXY+DQo8ZGl2Pkhvd2V2ZXIsIHdoZW4geW91IGV4cGxhaW4gdGhlIGJlaGF2aW9yIG9mIHRoZSBT RCBwcm90ZWN0aW9uIGluIHNlY3Rpb24gNy4zIHlvdSBoYXZlIGEgcGFyYWdyYXBoIHRoYXQgc3Rh cnRzIHdpdGggJnF1b3Q7PHNwYW4gc3R5bGU9IkxJTkUtSEVJR0hUOiAxLjJlbTsgRk9OVC1TSVpF OiAxM3B4Ij5JZiB0aGUgZGV0ZWN0aW9uIG9mIGEgU0QgZGVwZW5kcyBvbiB0aGUgcHJlc2VuY2Ug b2YgdXNlciBkYXRhIHBhY2tldHMgLi4uJnF1b3Q7ICZuYnNwO3RoYXQgc2VlbXMgdG8NCiBpbmRp Y2F0ZSB0aGF0IHRoZSBiZWhhdmlvciBvZiB0aGUgc3lzdGVtIGlzIGRlcGVuZGVudCB1cG9uIHRo ZSBkZXRlY3Rpb24gbWV0aG9kISBDbGFyaWZpY2F0aW9uIHdvdWxkIGJlIGFwcHJlY2lhdGVkLjwv c3Bhbj48c3BhbiBzdHlsZT0iTElORS1IRUlHSFQ6IDEuMmVtOyBGT05ULVNJWkU6IDEzcHgiPiZu YnNwOzwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQotLSA8YnI+DQo8ZGl2IGRpcj0ibHRyIj5U aGFueCBhbmQgQlIsDQo8ZGl2PnlhYWNvdjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ PGk+U3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5PC9pPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjxiciBjbGVhcj0iYWxs Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQotLSA8YnI+DQo8ZGl2IGRpcj0ibHRyIj5UaGFueCBhbmQg QlIsDQo8ZGl2PnlhYWNvdjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGk+U3RpbGwg bG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5PC9pPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39SMTP2etriinfo_-- From loa@pi.nu Wed Dec 25 23:07:21 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 EFB191AE169 for ; Wed, 25 Dec 2013 23:07:20 -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 x8yes2fizZZq for ; Wed, 25 Dec 2013 23:07:17 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 546F81A8034 for ; Wed, 25 Dec 2013 23:07:17 -0800 (PST) Received: from [192.168.1.9] (unknown [112.208.111.219]) (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 0A98618013E2; Thu, 26 Dec 2013 08:07:09 +0100 (CET) Message-ID: <52BBD59D.8000104@pi.nu> Date: Thu, 26 Dec 2013 15:07:09 +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> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info> Content-Type: text/plain; charset=windows-1252; 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, 26 Dec 2013 07:07:21 -0000 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 From ryoo@etri.re.kr Thu Dec 26 18:41:20 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 216401AE7C4 for ; Thu, 26 Dec 2013 18:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p8F-SrNj5-sL for ; Thu, 26 Dec 2013 18:41: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 62F561AE7CB for ; Thu, 26 Dec 2013 18:41:15 -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; Fri, 27 Dec 2013 11:41:02 +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; Fri, 27 Dec 2013 11:41:06 +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+AgAHUA6o= Date: Fri, 27 Dec 2013 02:41:05 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEFF9@SMTP2.etri.info> References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info>, <52BBD59D.8000104@pi.nu> In-Reply-To: <52BBD59D.8000104@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_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEFF9SMTP2etriinfo_" 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: Fri, 27 Dec 2013 02:41:20 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEFF9SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLA0KDQpJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9uIGNvcnJlY3Rs eSwgYnV0IEkgd291bGQgc2F5IHRoYXQ6DQpFYWNoIGxheWVyIGhhcyBpdHMgb3duIGJyaWRnZSBh bmQgc2VsZWN0b3IgZm9yIHByb3RlY3Rpb24gc3dpdGNoaW5nLCBzbyB0aGF0IGVhY2ggbGF5ZXIg Y2FuIHBlcmZvcm0gcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb2YgaXRzIG93bi4NCkkgYW0gbm90IHN1 cmUgd2hhdCB5b3UgbWVhbiBieSAiYnJpZGdlL3NlbGVjdG9yIGZ1bmN0aW9uIiwgYnV0IGluIElU VS1UIHRlcm1pbm9sb2d5LCB0aGUgYnJpZGdlIGFuZCBzZWxlY3RvciBhcmUgaW5jbHVkZWQgaW4g ImNvbm5lY3Rpb24gZnVuY3Rpb24iIG9mIGl0cyBvd24gbGF5ZXIgIChmb3IgZXhhbXBsZSwgTVRf QyBmb3IgTVBMUy1UUCBjb25uZWN0aW9uIGZ1bmN0aW9uLCB3aGljaCBpbmNsdWRlcyB0aGUgYnJp ZGdlIGFuZCB0aGUgc2VsZWN0b3IgZm9yIHRoZSBNUExTLVRQIGxheWVyKS4NCkZvciB0aGUgUFND IFJGQywgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGludHJvZHVjZSBhbnkgbmV3IHRlcm1pbm9s b2d5IHN1Y2ggYXMgdGhlICJicmlkZ2Uvc2VsZWN0b3IgZnVuY3Rpb24iIG9yICJjb25uZWN0aW9u IGZ1bmN0aW9uIi4NClRoZSBicmlkZ2Uvc2VsZWN0b3IgaGF2ZSBhbHJlYWR5IGJlZW4gaW50cm9k dWNlZCBpbiB0aGUgUkZDNjM3OCAoTVBMUy1UUCBsaW5lYXIgcHJvdGVjdGlvbikuDQoNCkJlc3Qg cmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tIDogIkxvYSBBbmRlcnNzb24iIDxsb2FAcGkubnU+DQpTZW50IDogMjAxMy0xMi0y NiAxNjowNzoxNSAoICswOTowMCApDQpUbyA6IFJ5b28sIEplb25nLWRvbmcgPHJ5b29AZXRyaS5y ZS5rcj4sIFlhYWNvdiBXZWluZ2FydGVuIDx3eWFhY292QGdtYWlsLmNvbT4NCkNjIDogbXBsc0Bp ZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4sIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xz LmlldGYub3JnIDxkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz4NClN1 YmplY3QgOiBSZTogW21wbHNdIFF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9uIGluIGRy YWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQoNCkplb25nLWRvbmcsDQoNCklzIHRoaXMgc2ltcGx5 IGEgbWF0dGVyIG9mIHRlcm1pbm9sb2d5LiBFYWNoIGxheWVyIG5lZWRzIHRvIHBlcmZvcm0gaXRz DQpvd24gcHJvdGVjdGlvbiBzd2l0Y2hpbmcsIGkuZS4gdGhlcmUgaGFzIHRvIGJlIGEgKmJyaWRn ZSBmdW50aW9uKiBhbmQgYQ0KKnNlbGVjdG9yIGZ1bmN0aW9uKiAob24gZWFjaCBsYXllciBkZXBl bmRpbmcgb24gdGhlIGltcGxlbWVudGF0aW9uKTsNCndoaWxlICpicmlkZ2UqIGFuZCAqc2VsZWN0 b3IqIGFyZSB0aGUgcGh5c2ljYWwgbGF5ZXIgZW50aXRpZXM/DQoNCi9Mb2ENCg0KT24gMjAxMy0x Mi0yNiAxMjo1MSwgUnlvbywgSmVvbmctZG9uZyB3cm90ZToNCj4gWWFhY292LCB0aGFua3MgZm9y IHlvdXIgZW1haWwuIFNvbWVob3csIEkgZm9yZ290IHRvIHJlc3BvbmQgYW5kIGFtIHNvcnJ5DQo+ IGZvciB0aGUgZGVsYXkuDQo+DQo+IEZpcnN0IG9mIGFsbCwgWWFhY292LCBpdCBpcyBub3QgdHJ1 ZSB0aGF0IHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBvZg0KPiBFdGhlcm5ldCBvciBTREggZGVz Y3JpYmVzIHRoZSBvcGVyYXRpb24gb2YgYW55IGxheWVyIGJlbG93LiBSYXRoZXIsIGVhY2gNCj4g bGF5ZXIgaXMgc3VwcG9zZWQgdG8gb3BlcmF0ZSBpbmRlcGVuZGVudGx5LiBIb3dldmVyLCB0aGVy ZSBhcmUgYSBmZXcNCj4gZXhjZXB0aW9ucywgc3VjaCBhcyBob2xkLW9mZiB0aW1lciBhbmQgQUlT IChhcyBhIHRyaWdnZXIgZnJvbSBsb3dlcg0KPiBsYXllcikuIEV2ZW4gdGhvdWdoIHRoZXJlIGV4 aXN0IHNvbWUgcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRpb25zIHRoYXQNCj4gdXNlIG90aGVyIGlu Zm9ybWF0aW9uIGZyb20gbG93ZXIgbGF5ZXIsIG1vc3Qgb2YgdGhlbSBhcmUgbm90IHJlY29tbWVu ZGVkDQo+IGluIElUVS1UIHN0YW5kYXJkcy4NCj4NCj4gQnJpZGdlIGFuZCBzZWxlY3RvciBhcmUg bm90IGluIHRoZSBwaHlzaWNhbCBsYXllciwgYnV0IHRoZXkgYXJlIHBhcnQgb2YNCj4gcHJvdGVj dGlvbiBzd2l0Y2hpbmcuIE9uZSBvZiB0aGUgaW1wb3J0YW50IG91dHB1dCBhY3Rpb25zIGZyb20g dGhlIFBTQw0KPiBjb250cm9sIGxvZ2ljIGlzIGNvb3JkaW5hdGluZyB0aGUgcG9zaXRpb25zIG9m IGJyaWRnZSBhbmQgc2VsZWN0b3IuDQo+IEFsc28sIHRoZSBicmlkZ2Ugb3BlcmF0aW9uIHJlc3Bv bmRpbmcgdG8gdGhlIFBTQyBjb250cm9sIGxvZ2ljIGlzIGFsc28NCj4gcGFydCBvZiBwcm90ZWN0 aW9uIHN3aXRjaGluZy4gSG93ZXZlciwgaG93IHRvIHJlYWxpemUgdGhlIGJyaWRnZSBhbmQNCj4g c2VsZWN0b3IgKGZvciBleGFtcGxlLCBob3cgdG8gbWFuaXB1bGF0ZSBhIHBhY2tldCBmb3J3YXJk aW5nIG1lY2hhbmlzbSkNCj4gaXMgYW4gaW1wbGVtZW50YXRpb24gbWF0dGVyLg0KPg0KPiBXaGVu IHdlIG1lbnRpb24gMSsxIG9yIDE6MSBpbiBwcm90ZWN0aW9uIGFyY2hpdGVjdHVyZSwgd2UgZGVh bCB3aXRoIHRoZQ0KPiBvcGVyYXRpb24gb2YgYnJpZGdlLiBGb3IgMSsxIGFyY2hpdGVjdHVyZSwg dGhlIHRyYWZmaWMgbmVlZHMgdG8gYmUNCj4gZHVwbGljYXRlZCBhdCB0aGUgc2VuZGVyIGFuZCBz ZW50IHRvIGJvdGggcGF0aHMgYWxsIHRoZSB0aW1lLCB3aGljaCBpcw0KPiB0aGUgc2FtZSBkZXNj cmlwdGlvbiBhcyB0aGUg4oCccGVybWFuZW50IGJyaWRnZeKAnS4gRm9yIDE6MSBhcmNoaXRlY3R1 cmUsDQo+IOKAnHNlbGVjdG9yIGJyaWRnZeKAnSBpcyB1c2VkIHRvIHNlbmQgdGhlIHRyYWZmaWMg b25seSBvbmUgb2YgdGhlIHBhdGhzLiBBcw0KPiB0aGUgcHJvdGVjdGlvbiBwYXRoIGNhbiBiZSB1 c2VkIGJ5IGJlc3QgdHJhZmZpYyBpbiBwYWNrZXQgbmV0d29ya3MgYW5kDQo+IHRoZSBwYWNrZXQg ZHVwbGljYXRpb24gdGFrZXMgbXVjaCBtb3JlIGVmZm9ydC9pbnRlcm5hbCBiYW5kd2lkdGggaW5z aWRlDQo+IGEgc3dpdGNoIHRoYW4gdGhlIHRpbWUgc2xvdCBjb3B5IG9mIGNpcmN1aXQgbmV0d29y a3MuIDE6MSBpcyBjb25zaWRlcmVkDQo+IGFzIHByZWZlcmFibGUgYXJjaGl0ZWN0dXJlIGluIHBh Y2tldCBuZXR3b3Jrcy4NCj4NCj4gQXMgeW91IG1pZ2h0IHJlY2FsbCBmcm9tIEcuODAzMSDigJMg RXRoZXJuZXQgbGluZWFyIHByb3RlY3Rpb24sIHRoZQ0KPiBzZWxlY3RvciBicmlkZ2UgaXMgbm90 IHJlY29tbWVuZGVkIGR1ZSB0byB0aGUgdHJhZmZpYyBmbGFwcGluZyB1bmRlciBTRA0KPiBjb25k aXRpb25zIG9uIGJvdGggcGF0aHMuIEluc3RlYWQg4oCcYnJvYWRjYXN0IGJyaWRnZeKAnSBpcyBp bnRyb2R1Y2VkIHRvDQo+IHN1cHBvcnQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgYWdhaW5zdCBTRC4g QnV0LCB0aGlzIGJyb2FkY2FzdCBicmlkZ2UgaXMNCj4gbm90IHJlY29tbWVuZGVkIGluIG5vbi1y ZXZlcnRpdmUgbW9kZSBhcyB0aGUgd29ya2luZyBwYXRoIG5lZWRzIHRvIGJlDQo+IG9jY3VwaWVk IGJ5IHRyYWZmaWMgYWxsIHRoZSB0aW1lLiBBbHNvIHRoZSBicm9hZGNhc3QgYnJpZGdlIGlzIG5v dA0KPiBlZmZpY2llbnQsIHNpbmNlIGJ5IGRlZmluaXRpb24sIHRoZSBwYWNrZXQgZHVwbGljYXRp b24gc2hvdWxkIG9jY3VyDQo+IGR1cmluZyBub3Qgb25seSBTRCBidXQgYWxzbyBTRiwgRlMsIE1T LCBldGMuIEluIHRoaXMgZG9jdW1lbnQsIHdlIGFyZQ0KPiBpbnRyb2R1Y2luZyBhbiBpbXByb3Zl ZCBicmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhhdmVzIGxpa2UgYSBzZWxlY3Rvcg0KPiBicmlk Z2UgYnV0IGR1cGxpY2F0ZXMgdGhlIHRyYWZmaWMgb25seSB1bmRlciBTRCBjb25kaXRpb24sIGFu ZCB3ZQ0KPiBiZWxpZXZlIHRoYXQgaXQgYWRkcmVzc2VzIGFsbCB0aGUgaXNzdWVzIHdpdGggZXhp c3RpbmcgYnJpZGdlcy4NCj4NCj4gV2hhdCB3ZSBtZWFuIGJ5IFNEIHByb3RlY3Rpb24gaXMgYWdu b3N0aWMgdG8gdGhlIFNEIGRldGVjdGlvbiBtZXRob2QgaXMNCj4gdGhhdCB0aGUgcHJvcG9zZWQg U0QgcHJvdGVjdGlvbiBtZXRob2QgKGFnYWluIGhvdyB0byBvcGVyYXRlIGEgYnJpZGdlIG9yDQo+ IHdoYXQgYnJpZ2UgaXMgdXNlZCBpcyBhIHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcpIGNh biBiZSB1c2VkIG5vDQo+IG1hdHRlciB3aGF0IGtpbmQgb2YgU0QgZGV0ZWN0aW9uIG1ldGhvZHMg KGRhdGEgcGFja2V0IGNvdW50aW5nLCBDQ00NCj4gcGFja2V0IGNvdW50aW5nLCBvciBldmVuIHBy b3ByaWV0YXJ5IHNlcnZlciBsYXllciBTRCBkZXRlY3Rpb24pIGlzIHVzZWQuDQo+DQo+IEkgdGhp bmsgSSBhbnN3ZXJlZCBhbGwgdGhlIHF1ZXN0aW9ucyBvbiB5b3VyIGVtYWlsLg0KPg0KPiBZYWFj b3YsIGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbmNlcm5zIG9yIHF1ZXN0aW9ucywgcGxlYXNl IGxldCBtZSBrbm93Lg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+DQo+IEplb25nLWRvbmcNCj4NCj4N Cj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICpGcm9tIDogKiJZYWFjb3YgV2VpbmdhcnRlbiIN Cj4gKlNlbnQgOiAqMjAxMy0xMi0xMCAxNjowNDoxNyAoICswOTowMCApDQo+ICpUbyA6ICpSeW9v LCBKZW9uZy1kb25nDQo+ICpDYyA6ICpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5p ZXRmLm9yZw0KPiAsIG1wbHNAaWV0Zi5vcmcNCj4gKlN1YmplY3QgOiAqUmU6IFF1ZXN0aW9uIHJl Z2FyZGluZyBTRCBwcm90ZWN0aW9uIGluDQo+IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQo+ DQo+IEplb25nLWRvbmcsIGhpDQo+DQo+IFRoYW5rIHlvdSBmb3IgeW91ciByZXBseS4gWW91ciBh bnN3ZXIgc2VlbXMgdG8gYmUgYW4gYXBwcm9wcmlhdGUgYW5zd2VyDQo+IGZvciBvdGhlciBTRE9z LCBub3Qgc3VyZSB0aGF0IGl0IGlzIHRydWUgZm9yIHRoZSBjb250ZXh0IG9mIE1QTFMgYW5kDQo+ IElFVEYgd29yay4NCj4NCj4gMS4gWW91IHdyb3RlICJhbnkgcHJvdGVjdGlvbiBzd2l0Y2hpbmcg KGluY2x1ZGluZyBQU0MpIGlzIHN1cHBvc2VkIHRvDQo+IGRlc2NyaWJlIHRoZSBvcGVyYXRpb24g b2YgYnJpZGdlIGFuZCBzZWxlY3Rvci4iIC0gdGhpcyBtYXkgYmUgdHJ1ZSBmb3INCj4gRXRoZXJu ZXQgYW5kU0RIIGFuZCBmb3IgZG9jdW1lbnRzIHRoYXQgYXJlIGRlc2NyaWJpbmcgdGhlIG9wZXJh dGlvbiBvZg0KPiB0aGUgcGh5c2ljYWwgbGF5ZXIuIEhvd2V2ZXIsIHRoZSBJRVRGICh0byBteSB1 bmRlcnN0YW5kaW5nIC0gYW5kIEkgYW0NCj4gY2VydGFpbmx5IHdpbGxpbmcgdG8gYmUgY29ycmVj dGVkIG9uIHRoaXMgcG9pbnQpIGlzIGNvbmNlcm5lZCB3aXRoIHRoZQ0KPiBwcm90b2NvbCBhbmQg bGVhdmUgdGhlIGxvd2VyIGxheWVycyB0byBpbXBsZW1lbnRhdGlvbi4gQWxzbywgSSBhbSBub3QN Cj4gc3VyZSB0aGF0IHRoZSBjb25jZXB0cyBvZiBCcmlkZ2UgYW5kIFNlbGVjdG9yIHJlYWxseSBh cHBseSB0byBNUExTDQo+IChhbHRob3VnaCBJIGFkbWl0IHRoYXQgd2UgZGlkIG1lbnRpb24gdGhl bSBpbiB0aGUgb3JpZ2luYWwgUFNDIGRlZmluaXRpb24pLg0KPg0KPiAyLiBZb3UgY2l0ZSB3aGF0 IHdhcyB3cml0dGVuIGluIEc4MDMxIGFzIGp1c3RpZmljYXRpb24gZm9yIGluY2x1ZGluZw0KPiBj b250ZW50IGludG8geW91ciBkcmFmdC4gQWdhaW4gaXQgaXMgaGFyZCB0byB0cmFuc2ZlciBtZXRo b2RvbG9neSBmcm9tDQo+IG9uZSBTRE8gdG8gYW5vdGhlciBhbmQgdGhlcmVmb3JlLCB3aGlsZSBJ IGhpZ2hseSByZXNwZWN0IHRoZSB3b3JrIG9mIHRoZQ0KPiBJVFUsIEkgZG8gbm90IGZlZWwgdGhh dCB0aGlzIGlzIGEgdmVyeSBjbGVhciBqdXN0aWZpY2F0aW9uIGZvciBpbmNsdXNpb24NCj4gaW50 byBhbiBpbnRlcm5ldC1kcmFmdC4gRXZlbiB3aGVuIHRoZSBkcmFmdCBzdGF0ZXMgdGhhdCBpdHMg cHVycG9zZSBpcw0KPiB0byBhZGRyZXNzIHRoZSBjb25jZXJucyBvZiB0aGUgSVRVLg0KPg0KPiAz LiBUbyB0aGUgYWN0dWFsIHBvaW50IG9mIG15IGVhcmxpZXIgY29tbWVudCwgdGhhdCB5b3UgZG8g bm90IHNlZW0gdG8NCj4gYWRkcmVzcyAtIHRoZSBwYXJhZ3JhcGggaW4gU2VjdGlvbiA3LjMgc2Vl bXMgdG8gc3RhdGUgdGhhdCBTRCBwcm90ZWN0aW9uDQo+IGNoYW5nZXMgYWNjb3JkaW5nIHRvIHRo ZSBtZXRob2QgdGhhdCBpcyB1c2VkIHRvIGRldGVjdCB0aGUgU0QuIFRoaXMNCj4gbWVhbnMgdGhh dCBTRCBwcm90ZWN0aW9uIGlzIG5vdCBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRo ZQ0KPiBkZXRlY3Rpb24uDQo+IEFsdGVybmF0aXZlbHksIHdlIGNvdWxkIGJyZWFrIHRoaXMgZGVw ZW5kZW5jZSBhbmQgc3RhdGUgdGhhdCBTRA0KPiBwcm90ZWN0aW9uIGlzIGFsd2F5cyBwcm92aWRl ZCBieSBjaGFuZ2luZyB0aGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBkYXRhDQo+IHRvIDErMSBwcm90 ZWN0aW9uIGluIGNhc2VzIG9mIFNEIGRldGVjdGlvbiwgd2hpY2ggaXMgd2hhdCB0aGUgcGFyYWdy YXBoDQo+IGlzIHN1Z2dlc3RpbmcgdG8gZG8gZm9yIHNvbWUgY2FzZXMuDQo+DQo+IEkgaG9wZSB0 aGlzIGZvcm11bGF0aW9uIG1ha2UgbXkgY29tbWVudCBjbGVhcmVyIGFuZCB3ZSBhcmUgYWJsZSB0 bw0KPiBkaXNjdXNzIHRoZSB0ZWNobm9sb2dpY2FsIGFwcHJvYWNoIHJhdGhlciB0aGFuIHRoZSBw aGlsb3NvcGhpY2FsDQo+IGRpZmZlcmVuY2VzLg0KPg0KPiBUaGFuayB5b3UsDQo+IHlhYWNvdg0K Pg0KPg0KPiBPbiBNb24sIERlYyA5LCAyMDEzIGF0IDEwOjA0IFBNLCBSeW9vLCBKZW9uZy1kb25n ID4gPiB3cm90ZToNCj4NCj4gWWFhY292LA0KPg0KPiBZZXMsIFBTQyBpcyBzdXBwb3NlZCB0byBi ZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoZQ0KPiBkZXRlY3Rpb24gb2YgU0Yv U0QuDQo+DQo+IEl0IGlzIGFsc28gdHJ1ZSB0aGF0IGFueSBwcm90ZWN0aW9uIHN3aXRjaGluZyAo aW5jbHVkaW5nIFBTQykgaXMNCj4gc3VwcG9zZWQgdG8gZGVzY3JpYmUgdGhlIG9wZXJhdGlvbiBv ZiBicmlkZ2UgYW5kIHNlbGVjdG9yLg0KPg0KPiBBcyB0aGVyZSBhcmUgbXVsdGlwbGUgb3B0aW9u cyBmb3IgZGV0ZWN0aW5nIFNELCB3ZSBuZWVkZWQgdG8NCj4gZGVzY3JpYmUgdGhlIGJlaGF2aW9y IG9mIHRoZSBicmlkZ2UgdG8gY292ZXIgYWxsIHRoZSBwb3NzaWJsZQ0KPiBkZXRlY3Rpb24gbWV0 aG9kcy4gRGVzY3JpYmluZyB0aGUgb3BlcmF0aW9uIG9mIGJyaWRnZSBmb3IgU0QNCj4gcHJvdGVj dGlvbiBpcyBub3QgYSBuZXcgdGhpbmcuIEZvciBleGFtcGxlLCBHLjgwMzEgLSBFdGhlcm5ldCBs aW5lYXINCj4gcHJvdGVjdGlvbiBhbHNvIGRlc2NyaWJlcyB3aGF0IGJyaWRnZSBjYW4gYmUgdXNl ZCBpbiBvcmRlciB0bw0KPiBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCBTRC4NCj4NCj4gQmVz dCByZWdhcmRzLA0KPg0KPiBKZW9uZy1kb25nDQo+DQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiAqRnJvbSA6ICoiWWFhY292IFdlaW5nYXJ0ZW4iID4gPg0KPiAqU2VudCA6ICoyMDEzLTEy LTA4IDIwOjAxOjU1ICggKzA5OjAwICkNCj4gKlRvIDogKmRyYWZ0LWlldGYtbXBscy10cC1wc2Mt aXR1QHRvb2xzLmlldGYub3JnDQo+DQo+ID4gPiwgbXBsc0BpZXRmLm9yZw0KPiA+DQo+ICpDYyA6 ICoNCj4gKlN1YmplY3QgOiAqUXVlc3Rpb24gcmVnYXJkaW5nIFNEIHByb3RlY3Rpb24gaW4NCj4g ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCj4NCj4NCj4gSGksDQo+DQo+IEFmdGVyIHJlYWRp bmcgdGhyb3VnaCB5b3VyIGRyYWZ0IG9uIHRoZSBleHRlbnNpb25zIHRvIFBTQyB0byBzdXBwb3J0 DQo+IFNEIHNpdHVhdGlvbnMsIEkgaGF2ZSBhIHF1ZXN0aW9uIGZvciBjbGFyaWZpY2F0aW9uIC0N Cj4gSW4geW91ciBpbnRyb2R1Y3Rpb24gLSB5b3Ugc3RhdGUgdGhhdCB0aGUgbWV0aG9kIHVzZWQg dG8gZGV0ZWN0IFNEDQo+IHNpdHVhdGlvbnMgaXMgb3V0LW9mLXNjb3BlIG9mIHRoZSBkb2N1bWVu dC4gRG9lcyB0aGlzIG1lYW4gdGhhdCBQU0MNCj4gaXMgc3VwcG9zZWQgdG8gYmUgYWdub3N0aWMg dG8gdGhlIG1ldGhvZCB1c2VkIGZvciB0aGlzIGRldGVjdGlvbj8gSXQNCj4gc2hvdWxkIHJlYWN0 IG9ubHkgdG8gdGhlIGluZGljYXRpb24sIHNpbWlsYXJseSB0byB0aGUgcmVhY3Rpb24gYW5kDQo+ IHJlbGF0aW9uc2hpcCB0byB0aGUgbWV0aG9kIGZvciBkZXRlY3RpbmcgYW5kIGRlY2xhcmluZyBh IFNGIHNpdHVhdGlvbi4NCj4gSG93ZXZlciwgd2hlbiB5b3UgZXhwbGFpbiB0aGUgYmVoYXZpb3Ig b2YgdGhlIFNEIHByb3RlY3Rpb24gaW4NCj4gc2VjdGlvbiA3LjMgeW91IGhhdmUgYSBwYXJhZ3Jh cGggdGhhdCBzdGFydHMgd2l0aCAiSWYgdGhlIGRldGVjdGlvbg0KPiBvZiBhIFNEIGRlcGVuZHMg b24gdGhlIHByZXNlbmNlIG9mIHVzZXIgZGF0YSBwYWNrZXRzIC4uLiIgdGhhdA0KPiBzZWVtcyB0 byBpbmRpY2F0ZSB0aGF0IHRoZSBiZWhhdmlvciBvZiB0aGUgc3lzdGVtIGlzIGRlcGVuZGVudCB1 cG9uDQo+IHRoZSBkZXRlY3Rpb24gbWV0aG9kISBDbGFyaWZpY2F0aW9uIHdvdWxkIGJlIGFwcHJl Y2lhdGVkLg0KPg0KPiAtLQ0KPiBUaGFueCBhbmQgQlIsDQo+IHlhYWNvdg0KPg0KPiAvU3RpbGwg bG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5Lw0KPg0KPg0KPg0KPg0KPiAtLQ0KPiBUaGFueCBh bmQgQlIsDQo+IHlhYWNvdg0KPg0KPiAvU3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5 Lw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPg0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24g ZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KU2VuaW9yIE1QTFMgRXhwZXJ0IGxvYUBwaS5u dQ0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICs0NiA3MzkgODEgMjEg NjQNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEFF9SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+SSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbiBjb3JyZWN0bHksIGJ1 dCBJIHdvdWxkIHNheSB0aGF0OjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQi PkVhY2ggbGF5ZXIgaGFzIGl0cyBvd24gYnJpZGdlIGFuZCBzZWxlY3RvciBmb3IgcHJvdGVjdGlv biBzd2l0Y2hpbmcsJm5ic3A7c28gdGhhdCZuYnNwO2VhY2ggbGF5ZXIgY2FuIHBlcmZvcm0gcHJv dGVjdGlvbiBzd2l0Y2hpbmcgb2YgaXRzIG93bi48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij5JIGFtIG5vdCBzdXJlIHdoYXQmbmJzcDt5b3UgbWVhbiBieSZuYnNwOyZxdW90 O2JyaWRnZS9zZWxlY3RvciBmdW5jdGlvbiZxdW90OywgYnV0IGluIElUVS1UIHRlcm1pbm9sb2d5 LCB0aGUgYnJpZGdlIGFuZCBzZWxlY3RvciBhcmUgaW5jbHVkZWQgaW4gJnF1b3Q7Y29ubmVjdGlv biBmdW5jdGlvbiZxdW90OyBvZiBpdHMmbmJzcDtvd24gbGF5ZXImbmJzcDsgKGZvciBleGFtcGxl LCBNVF9DIGZvciBNUExTLVRQIGNvbm5lY3Rpb24gZnVuY3Rpb24sIHdoaWNoIGluY2x1ZGVzDQog dGhlIGJyaWRnZSBhbmQgdGhlIHNlbGVjdG9yIGZvciB0aGUgTVBMUy1UUCBsYXllcikuJm5ic3A7 Jm5ic3A7PGJyPg0KRm9yIHRoZSBQU0MgUkZDLCBJIGRvbid0IHRoaW5rIHdlJm5ic3A7bmVlZCB0 byBpbnRyb2R1Y2UgYW55IG5ldyB0ZXJtaW5vbG9neSBzdWNoIGFzIHRoZSZuYnNwOyZxdW90O2Jy aWRnZS9zZWxlY3RvciBmdW5jdGlvbiZxdW90OyBvciAmcXVvdDtjb25uZWN0aW9uIGZ1bmN0aW9u JnF1b3Q7Lg0KPGJyPg0KVGhlIGJyaWRnZS9zZWxlY3RvciBoYXZlIGFscmVhZHkgYmVlbiBpbnRy b2R1Y2VkIGluIHRoZSBSRkM2Mzc4IChNUExTLVRQIGxpbmVhciBwcm90ZWN0aW9uKS4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiPkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0Ij5KZW9uZy1kb25nPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5i c3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgaWQ9Ik1haWxTaWduIj48 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxociB0YWJpbmRl eD0iLTEiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGI+RnJvbSA6 IDwvYj4mcXVvdDtMb2EgQW5kZXJzc29uJnF1b3Q7ICZsdDtsb2FAcGkubnUmZ3Q7PGJyPg0KPGI+ U2VudCA6IDwvYj4yMDEzLTEyLTI2IDE2OjA3OjE1ICggJiM0MzswOTowMCApPGJyPg0KPGI+VG8g OiA8L2I+UnlvbywgSmVvbmctZG9uZyAmbHQ7cnlvb0BldHJpLnJlLmtyJmd0OywgWWFhY292IFdl aW5nYXJ0ZW4gJmx0O3d5YWFjb3ZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjIDogPC9iPm1wbHNA aWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dUB0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5SZTogW21wbHNdIFF1ZXN0aW9uIHJlZ2Fy ZGluZyBTRCBwcm90ZWN0aW9uIGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1PGJyPg0KPGJy Pg0KSmVvbmctZG9uZyw8YnI+DQo8YnI+DQpJcyB0aGlzIHNpbXBseSBhIG1hdHRlciBvZiB0ZXJt aW5vbG9neS4gRWFjaCBsYXllciBuZWVkcyB0byBwZXJmb3JtIGl0czxicj4NCm93biBwcm90ZWN0 aW9uIHN3aXRjaGluZywgaS5lLiB0aGVyZSBoYXMgdG8gYmUgYSAqYnJpZGdlIGZ1bnRpb24qIGFu ZCBhPGJyPg0KKnNlbGVjdG9yIGZ1bmN0aW9uKiAob24gZWFjaCBsYXllciBkZXBlbmRpbmcgb24g dGhlIGltcGxlbWVudGF0aW9uKTs8YnI+DQp3aGlsZSAqYnJpZGdlKiBhbmQgKnNlbGVjdG9yKiBh cmUgdGhlIHBoeXNpY2FsIGxheWVyIGVudGl0aWVzPzxicj4NCjxicj4NCi9Mb2E8YnI+DQo8YnI+ DQpPbiAyMDEzLTEyLTI2IDEyOjUxLCBSeW9vLCBKZW9uZy1kb25nIHdyb3RlOjxicj4NCiZndDsg WWFhY292LCB0aGFua3MgZm9yIHlvdXIgZW1haWwuIFNvbWVob3csIEkgZm9yZ290IHRvIHJlc3Bv bmQgYW5kIGFtIHNvcnJ5PGJyPg0KJmd0OyBmb3IgdGhlIGRlbGF5Ljxicj4NCiZndDs8YnI+DQom Z3Q7IEZpcnN0IG9mIGFsbCwgWWFhY292LCBpdCBpcyBub3QgdHJ1ZSB0aGF0IHRoZSBwcm90ZWN0 aW9uIHN3aXRjaGluZyBvZjxicj4NCiZndDsgRXRoZXJuZXQgb3IgU0RIIGRlc2NyaWJlcyB0aGUg b3BlcmF0aW9uIG9mIGFueSBsYXllciBiZWxvdy4gUmF0aGVyLCBlYWNoPGJyPg0KJmd0OyBsYXll ciBpcyBzdXBwb3NlZCB0byBvcGVyYXRlIGluZGVwZW5kZW50bHkuIEhvd2V2ZXIsIHRoZXJlIGFy ZSBhIGZldzxicj4NCiZndDsgZXhjZXB0aW9ucywgc3VjaCBhcyBob2xkLW9mZiB0aW1lciBhbmQg QUlTIChhcyBhIHRyaWdnZXIgZnJvbSBsb3dlcjxicj4NCiZndDsgbGF5ZXIpLiBFdmVuIHRob3Vn aCB0aGVyZSBleGlzdCBzb21lIHByb3ByaWV0YXJ5IGltcGxlbWVudGF0aW9ucyB0aGF0PGJyPg0K Jmd0OyB1c2Ugb3RoZXIgaW5mb3JtYXRpb24gZnJvbSBsb3dlciBsYXllciwgbW9zdCBvZiB0aGVt IGFyZSBub3QgcmVjb21tZW5kZWQ8YnI+DQomZ3Q7IGluIElUVS1UIHN0YW5kYXJkcy48YnI+DQom Z3Q7PGJyPg0KJmd0OyBCcmlkZ2UgYW5kIHNlbGVjdG9yIGFyZSBub3QgaW4gdGhlIHBoeXNpY2Fs IGxheWVyLCBidXQgdGhleSBhcmUgcGFydCBvZjxicj4NCiZndDsgcHJvdGVjdGlvbiBzd2l0Y2hp bmcuIE9uZSBvZiB0aGUgaW1wb3J0YW50IG91dHB1dCBhY3Rpb25zIGZyb20gdGhlIFBTQzxicj4N CiZndDsgY29udHJvbCBsb2dpYyBpcyBjb29yZGluYXRpbmcgdGhlIHBvc2l0aW9ucyBvZiBicmlk Z2UgYW5kIHNlbGVjdG9yLjxicj4NCiZndDsgQWxzbywgdGhlIGJyaWRnZSBvcGVyYXRpb24gcmVz cG9uZGluZyB0byB0aGUgUFNDIGNvbnRyb2wgbG9naWMgaXMgYWxzbzxicj4NCiZndDsgcGFydCBv ZiBwcm90ZWN0aW9uIHN3aXRjaGluZy4gSG93ZXZlciwgaG93IHRvIHJlYWxpemUgdGhlIGJyaWRn ZSBhbmQ8YnI+DQomZ3Q7IHNlbGVjdG9yIChmb3IgZXhhbXBsZSwgaG93IHRvIG1hbmlwdWxhdGUg YSBwYWNrZXQgZm9yd2FyZGluZyBtZWNoYW5pc20pPGJyPg0KJmd0OyBpcyBhbiBpbXBsZW1lbnRh dGlvbiBtYXR0ZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hlbiB3ZSBtZW50aW9uIDEmIzQzOzEg b3IgMToxIGluIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJlLCB3ZSBkZWFsIHdpdGggdGhlPGJyPg0K Jmd0OyBvcGVyYXRpb24gb2YgYnJpZGdlLiBGb3IgMSYjNDM7MSBhcmNoaXRlY3R1cmUsIHRoZSB0 cmFmZmljIG5lZWRzIHRvIGJlPGJyPg0KJmd0OyBkdXBsaWNhdGVkIGF0IHRoZSBzZW5kZXIgYW5k IHNlbnQgdG8gYm90aCBwYXRocyBhbGwgdGhlIHRpbWUsIHdoaWNoIGlzPGJyPg0KJmd0OyB0aGUg c2FtZSBkZXNjcmlwdGlvbiBhcyB0aGUg4oCccGVybWFuZW50IGJyaWRnZeKAnS4gRm9yIDE6MSBh cmNoaXRlY3R1cmUsPGJyPg0KJmd0OyDigJxzZWxlY3RvciBicmlkZ2XigJ0gaXMgdXNlZCB0byBz ZW5kIHRoZSB0cmFmZmljIG9ubHkgb25lIG9mIHRoZSBwYXRocy4gQXM8YnI+DQomZ3Q7IHRoZSBw cm90ZWN0aW9uIHBhdGggY2FuIGJlIHVzZWQgYnkgYmVzdCB0cmFmZmljIGluIHBhY2tldCBuZXR3 b3JrcyBhbmQ8YnI+DQomZ3Q7IHRoZSBwYWNrZXQgZHVwbGljYXRpb24gdGFrZXMgbXVjaCBtb3Jl IGVmZm9ydC9pbnRlcm5hbCBiYW5kd2lkdGggaW5zaWRlPGJyPg0KJmd0OyBhIHN3aXRjaCB0aGFu IHRoZSB0aW1lIHNsb3QgY29weSBvZiBjaXJjdWl0IG5ldHdvcmtzLiAxOjEgaXMgY29uc2lkZXJl ZDxicj4NCiZndDsgYXMgcHJlZmVyYWJsZSBhcmNoaXRlY3R1cmUgaW4gcGFja2V0IG5ldHdvcmtz Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEFzIHlvdSBtaWdodCByZWNhbGwgZnJvbSBHLjgwMzEg4oCT IEV0aGVybmV0IGxpbmVhciBwcm90ZWN0aW9uLCB0aGU8YnI+DQomZ3Q7IHNlbGVjdG9yIGJyaWRn ZSBpcyBub3QgcmVjb21tZW5kZWQgZHVlIHRvIHRoZSB0cmFmZmljIGZsYXBwaW5nIHVuZGVyIFNE PGJyPg0KJmd0OyBjb25kaXRpb25zIG9uIGJvdGggcGF0aHMuIEluc3RlYWQg4oCcYnJvYWRjYXN0 IGJyaWRnZeKAnSBpcyBpbnRyb2R1Y2VkIHRvPGJyPg0KJmd0OyBzdXBwb3J0IHByb3RlY3Rpb24g c3dpdGNoaW5nIGFnYWluc3QgU0QuIEJ1dCwgdGhpcyBicm9hZGNhc3QgYnJpZGdlIGlzPGJyPg0K Jmd0OyBub3QgcmVjb21tZW5kZWQgaW4gbm9uLXJldmVydGl2ZSBtb2RlIGFzIHRoZSB3b3JraW5n IHBhdGggbmVlZHMgdG8gYmU8YnI+DQomZ3Q7IG9jY3VwaWVkIGJ5IHRyYWZmaWMgYWxsIHRoZSB0 aW1lLiBBbHNvIHRoZSBicm9hZGNhc3QgYnJpZGdlIGlzIG5vdDxicj4NCiZndDsgZWZmaWNpZW50 LCBzaW5jZSBieSBkZWZpbml0aW9uLCB0aGUgcGFja2V0IGR1cGxpY2F0aW9uIHNob3VsZCBvY2N1 cjxicj4NCiZndDsgZHVyaW5nIG5vdCBvbmx5IFNEIGJ1dCBhbHNvIFNGLCBGUywgTVMsIGV0Yy4g SW4gdGhpcyBkb2N1bWVudCwgd2UgYXJlPGJyPg0KJmd0OyBpbnRyb2R1Y2luZyBhbiBpbXByb3Zl ZCBicmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhhdmVzIGxpa2UgYSBzZWxlY3Rvcjxicj4NCiZn dDsgYnJpZGdlIGJ1dCBkdXBsaWNhdGVzIHRoZSB0cmFmZmljIG9ubHkgdW5kZXIgU0QgY29uZGl0 aW9uLCBhbmQgd2U8YnI+DQomZ3Q7IGJlbGlldmUgdGhhdCBpdCBhZGRyZXNzZXMgYWxsIHRoZSBp c3N1ZXMgd2l0aCBleGlzdGluZyBicmlkZ2VzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdoYXQgd2Ug bWVhbiBieSBTRCBwcm90ZWN0aW9uIGlzIGFnbm9zdGljIHRvIHRoZSBTRCBkZXRlY3Rpb24gbWV0 aG9kIGlzPGJyPg0KJmd0OyB0aGF0IHRoZSBwcm9wb3NlZCBTRCBwcm90ZWN0aW9uIG1ldGhvZCAo YWdhaW4gaG93IHRvIG9wZXJhdGUgYSBicmlkZ2Ugb3I8YnI+DQomZ3Q7IHdoYXQgYnJpZ2UgaXMg dXNlZCBpcyBhIHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcpIGNhbiBiZSB1c2VkIG5vPGJy Pg0KJmd0OyBtYXR0ZXIgd2hhdCBraW5kIG9mIFNEIGRldGVjdGlvbiBtZXRob2RzIChkYXRhIHBh Y2tldCBjb3VudGluZywgQ0NNPGJyPg0KJmd0OyBwYWNrZXQgY291bnRpbmcsIG9yIGV2ZW4gcHJv cHJpZXRhcnkgc2VydmVyIGxheWVyIFNEIGRldGVjdGlvbikgaXMgdXNlZC48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJIHRoaW5rIEkgYW5zd2VyZWQgYWxsIHRoZSBxdWVzdGlvbnMgb24geW91ciBlbWFp bC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBZYWFjb3YsIGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNv bmNlcm5zIG9yIHF1ZXN0aW9ucywgcGxlYXNlIGxldCBtZSBrbm93Ljxicj4NCiZndDs8YnI+DQom Z3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBKZW9uZy1kb25nPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KJmd0OyAqRnJvbSA6IComcXVvdDtZYWFjb3YgV2VpbmdhcnRlbiZxdW90OyA8V1lBQUNP VkBHTUFJTC5DT00+PGJyPg0KJmd0OyAqU2VudCA6ICoyMDEzLTEyLTEwIDE2OjA0OjE3ICggJiM0 MzswOTowMCApPGJyPg0KJmd0OyAqVG8gOiAqUnlvbywgSmVvbmctZG9uZyA8UllPT0BFVFJJLlJF LktSPjxicj4NCiZndDsgKkNjIDogKmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmll dGYub3JnPGJyPg0KJmd0OyA8RFJBRlQtSUVURi1NUExTLVRQLVBTQy1JVFVAVE9PTFMuSUVURi5P Ukc+LCBtcGxzQGlldGYub3JnIDxNUExTQElFVEYuT1JHPjxicj4NCiZndDsgKlN1YmplY3QgOiAq UmU6IFF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9uIGluPGJyPg0KJmd0OyBkcmFmdC1p ZXRmLW1wbHMtdHAtcHNjLWl0dTxicj4NCiZndDs8YnI+DQomZ3Q7IEplb25nLWRvbmcsIGhpPGJy Pg0KJmd0Ozxicj4NCiZndDsgVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5LiBZb3VyIGFuc3dlciBz ZWVtcyB0byBiZSBhbiBhcHByb3ByaWF0ZSBhbnN3ZXI8YnI+DQomZ3Q7IGZvciBvdGhlciBTRE9z LCBub3Qgc3VyZSB0aGF0IGl0IGlzIHRydWUgZm9yIHRoZSBjb250ZXh0IG9mIE1QTFMgYW5kPGJy Pg0KJmd0OyBJRVRGIHdvcmsuPGJyPg0KJmd0Ozxicj4NCiZndDsgMS4gWW91IHdyb3RlICZxdW90 O2FueSBwcm90ZWN0aW9uIHN3aXRjaGluZyAoaW5jbHVkaW5nIFBTQykgaXMgc3VwcG9zZWQgdG88 YnI+DQomZ3Q7IGRlc2NyaWJlIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGFuZCBzZWxlY3Rvci4m cXVvdDsgLSB0aGlzIG1heSBiZSB0cnVlIGZvcjxicj4NCiZndDsgRXRoZXJuZXQgYW5kU0RIIGFu ZCBmb3IgZG9jdW1lbnRzIHRoYXQgYXJlIGRlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbiBvZjxicj4N CiZndDsgdGhlIHBoeXNpY2FsIGxheWVyLiBIb3dldmVyLCB0aGUgSUVURiAodG8gbXkgdW5kZXJz dGFuZGluZyAtIGFuZCBJIGFtPGJyPg0KJmd0OyBjZXJ0YWlubHkgd2lsbGluZyB0byBiZSBjb3Jy ZWN0ZWQgb24gdGhpcyBwb2ludCkgaXMgY29uY2VybmVkIHdpdGggdGhlPGJyPg0KJmd0OyBwcm90 b2NvbCBhbmQgbGVhdmUgdGhlIGxvd2VyIGxheWVycyB0byBpbXBsZW1lbnRhdGlvbi4gQWxzbywg SSBhbSBub3Q8YnI+DQomZ3Q7IHN1cmUgdGhhdCB0aGUgY29uY2VwdHMgb2YgQnJpZGdlIGFuZCBT ZWxlY3RvciByZWFsbHkgYXBwbHkgdG8gTVBMUzxicj4NCiZndDsgKGFsdGhvdWdoIEkgYWRtaXQg dGhhdCB3ZSBkaWQgbWVudGlvbiB0aGVtIGluIHRoZSBvcmlnaW5hbCBQU0MgZGVmaW5pdGlvbiku PGJyPg0KJmd0Ozxicj4NCiZndDsgMi4gWW91IGNpdGUgd2hhdCB3YXMgd3JpdHRlbiBpbiBHODAz MSBhcyBqdXN0aWZpY2F0aW9uIGZvciBpbmNsdWRpbmc8YnI+DQomZ3Q7IGNvbnRlbnQgaW50byB5 b3VyIGRyYWZ0LiBBZ2FpbiBpdCBpcyBoYXJkIHRvIHRyYW5zZmVyIG1ldGhvZG9sb2d5IGZyb208 YnI+DQomZ3Q7IG9uZSBTRE8gdG8gYW5vdGhlciBhbmQgdGhlcmVmb3JlLCB3aGlsZSBJIGhpZ2hs eSByZXNwZWN0IHRoZSB3b3JrIG9mIHRoZTxicj4NCiZndDsgSVRVLCBJIGRvIG5vdCBmZWVsIHRo YXQgdGhpcyBpcyBhIHZlcnkgY2xlYXIganVzdGlmaWNhdGlvbiBmb3IgaW5jbHVzaW9uPGJyPg0K Jmd0OyBpbnRvIGFuIGludGVybmV0LWRyYWZ0LiBFdmVuIHdoZW4gdGhlIGRyYWZ0IHN0YXRlcyB0 aGF0IGl0cyBwdXJwb3NlIGlzPGJyPg0KJmd0OyB0byBhZGRyZXNzIHRoZSBjb25jZXJucyBvZiB0 aGUgSVRVLjxicj4NCiZndDs8YnI+DQomZ3Q7IDMuIFRvIHRoZSBhY3R1YWwgcG9pbnQgb2YgbXkg ZWFybGllciBjb21tZW50LCB0aGF0IHlvdSBkbyBub3Qgc2VlbSB0bzxicj4NCiZndDsgYWRkcmVz cyAtIHRoZSBwYXJhZ3JhcGggaW4gU2VjdGlvbiA3LjMgc2VlbXMgdG8gc3RhdGUgdGhhdCBTRCBw cm90ZWN0aW9uPGJyPg0KJmd0OyBjaGFuZ2VzIGFjY29yZGluZyB0byB0aGUgbWV0aG9kIHRoYXQg aXMgdXNlZCB0byBkZXRlY3QgdGhlIFNELiBUaGlzPGJyPg0KJmd0OyBtZWFucyB0aGF0IFNEIHBy b3RlY3Rpb24gaXMgbm90IGFnbm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhlPGJyPg0K Jmd0OyBkZXRlY3Rpb24uPGJyPg0KJmd0OyBBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCBicmVhayB0 aGlzIGRlcGVuZGVuY2UgYW5kIHN0YXRlIHRoYXQgU0Q8YnI+DQomZ3Q7IHByb3RlY3Rpb24gaXMg YWx3YXlzIHByb3ZpZGVkIGJ5IGNoYW5naW5nIHRoZSB0cmFuc21pc3Npb24gb2YgdGhlIGRhdGE8 YnI+DQomZ3Q7IHRvIDEmIzQzOzEgcHJvdGVjdGlvbiBpbiBjYXNlcyBvZiBTRCBkZXRlY3Rpb24s IHdoaWNoIGlzIHdoYXQgdGhlIHBhcmFncmFwaDxicj4NCiZndDsgaXMgc3VnZ2VzdGluZyB0byBk byBmb3Igc29tZSBjYXNlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGhvcGUgdGhpcyBmb3JtdWxh dGlvbiBtYWtlIG15IGNvbW1lbnQgY2xlYXJlciBhbmQgd2UgYXJlIGFibGUgdG88YnI+DQomZ3Q7 IGRpc2N1c3MgdGhlIHRlY2hub2xvZ2ljYWwgYXBwcm9hY2ggcmF0aGVyIHRoYW4gdGhlIHBoaWxv c29waGljYWw8YnI+DQomZ3Q7IGRpZmZlcmVuY2VzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5r IHlvdSw8YnI+DQomZ3Q7IHlhYWNvdjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBN b24sIERlYyA5LCAyMDEzIGF0IDEwOjA0IFBNLCBSeW9vLCBKZW9uZy1kb25nIDxSWU9PQEVUUkku UkUuS1I8QlIgLz4mZ3Q7DQo8P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbWFpbHRvIC8+DQogPG1h aWx0bzpyeW9vQGV0cmkucmUua3I+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBZYWFj b3YsPGJyPg0KJmd0Ozxicj4NCiZndDsgWWVzLCBQU0MgaXMgc3VwcG9zZWQgdG8gYmUgYWdub3N0 aWMgdG8gdGhlIG1ldGhvZCB1c2VkIGZvciB0aGU8YnI+DQomZ3Q7IGRldGVjdGlvbiBvZiBTRi9T RC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCBpcyBhbHNvIHRydWUgdGhhdCBhbnkgcHJvdGVjdGlv biBzd2l0Y2hpbmcgKGluY2x1ZGluZyBQU0MpIGlzPGJyPg0KJmd0OyBzdXBwb3NlZCB0byBkZXNj cmliZSB0aGUgb3BlcmF0aW9uIG9mIGJyaWRnZSBhbmQgc2VsZWN0b3IuPGJyPg0KJmd0Ozxicj4N CiZndDsgQXMgdGhlcmUgYXJlIG11bHRpcGxlIG9wdGlvbnMgZm9yIGRldGVjdGluZyBTRCwgd2Ug bmVlZGVkIHRvPGJyPg0KJmd0OyBkZXNjcmliZSB0aGUgYmVoYXZpb3Igb2YgdGhlIGJyaWRnZSB0 byBjb3ZlciBhbGwgdGhlIHBvc3NpYmxlPGJyPg0KJmd0OyBkZXRlY3Rpb24gbWV0aG9kcy4gRGVz Y3JpYmluZyB0aGUgb3BlcmF0aW9uIG9mIGJyaWRnZSBmb3IgU0Q8YnI+DQomZ3Q7IHByb3RlY3Rp b24gaXMgbm90IGEgbmV3IHRoaW5nLiBGb3IgZXhhbXBsZSwgRy44MDMxIC0gRXRoZXJuZXQgbGlu ZWFyPGJyPg0KJmd0OyBwcm90ZWN0aW9uIGFsc28gZGVzY3JpYmVzIHdoYXQgYnJpZGdlIGNhbiBi ZSB1c2VkIGluIG9yZGVyIHRvPGJyPg0KJmd0OyBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCBT RC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0Ozxicj4NCiZndDsg SmVvbmctZG9uZzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgKkZyb20gOiAqJnF1b3Q7WWFhY292IFdlaW5n YXJ0ZW4mcXVvdDsgPFdZQUFDT1ZAR01BSUwuQ09NPEJSIC8+Jmd0OyA8bWFpbHRvOnd5YWFjb3ZA Z21haWwuY29tPg0KJmd0Ozxicj4NCiZndDsgKlNlbnQgOiAqMjAxMy0xMi0wOCAyMDowMTo1NSAo ICYjNDM7MDk6MDAgKTxicj4NCiZndDsgKlRvIDogKmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1 QHRvb2xzLmlldGYub3JnPGJyPg0KJmd0OyA8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy10cC1wc2Mt aXR1QHRvb2xzLmlldGYub3JnPjxicj4NCiZndDsgPERSQUZULUlFVEYtTVBMUy1UUC1QU0MtSVRV QFRPT0xTLklFVEYuT1JHPEJSIC8+Jmd0OyA8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy10cC1wc2Mt aXR1QHRvb2xzLmlldGYub3JnPg0KJmd0OywgbXBsc0BpZXRmLm9yZzxicj4NCiZndDsgPG1haWx0 bzptcGxzQGlldGYub3JnPjxNUExTQElFVEYuT1JHIDxtYWlsdG86bXBsc0BpZXRmLm9yZz0iIj4m Z3Q7PGJyPg0KJmd0OyAqQ2MgOiAqPGJyPg0KJmd0OyAqU3ViamVjdCA6ICpRdWVzdGlvbiByZWdh cmRpbmcgU0QgcHJvdGVjdGlvbiBpbjxicj4NCiZndDsgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1p dHU8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSGksPGJyPg0KJmd0Ozxicj4NCiZndDsg QWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHlvdXIgZHJhZnQgb24gdGhlIGV4dGVuc2lvbnMgdG8gUFND IHRvIHN1cHBvcnQ8YnI+DQomZ3Q7IFNEIHNpdHVhdGlvbnMsIEkgaGF2ZSBhIHF1ZXN0aW9uIGZv ciBjbGFyaWZpY2F0aW9uIC08YnI+DQomZ3Q7IEluIHlvdXIgaW50cm9kdWN0aW9uIC0geW91IHN0 YXRlIHRoYXQgdGhlIG1ldGhvZCB1c2VkIHRvIGRldGVjdCBTRDxicj4NCiZndDsgc2l0dWF0aW9u cyBpcyBvdXQtb2Ytc2NvcGUgb2YgdGhlIGRvY3VtZW50LiBEb2VzIHRoaXMgbWVhbiB0aGF0IFBT Qzxicj4NCiZndDsgaXMgc3VwcG9zZWQgdG8gYmUgYWdub3N0aWMgdG8gdGhlIG1ldGhvZCB1c2Vk IGZvciB0aGlzIGRldGVjdGlvbj8gSXQ8YnI+DQomZ3Q7IHNob3VsZCByZWFjdCBvbmx5IHRvIHRo ZSBpbmRpY2F0aW9uLCBzaW1pbGFybHkgdG8gdGhlIHJlYWN0aW9uIGFuZDxicj4NCiZndDsgcmVs YXRpb25zaGlwIHRvIHRoZSBtZXRob2QgZm9yIGRldGVjdGluZyBhbmQgZGVjbGFyaW5nIGEgU0Yg c2l0dWF0aW9uLjxicj4NCiZndDsgSG93ZXZlciwgd2hlbiB5b3UgZXhwbGFpbiB0aGUgYmVoYXZp b3Igb2YgdGhlIFNEIHByb3RlY3Rpb24gaW48YnI+DQomZ3Q7IHNlY3Rpb24gNy4zIHlvdSBoYXZl IGEgcGFyYWdyYXBoIHRoYXQgc3RhcnRzIHdpdGggJnF1b3Q7SWYgdGhlIGRldGVjdGlvbjxicj4N CiZndDsgb2YgYSBTRCBkZXBlbmRzIG9uIHRoZSBwcmVzZW5jZSBvZiB1c2VyIGRhdGEgcGFja2V0 cyAuLi4mcXVvdDsgdGhhdDxicj4NCiZndDsgc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgYmVo YXZpb3Igb2YgdGhlIHN5c3RlbSBpcyBkZXBlbmRlbnQgdXBvbjxicj4NCiZndDsgdGhlIGRldGVj dGlvbiBtZXRob2QhIENsYXJpZmljYXRpb24gd291bGQgYmUgYXBwcmVjaWF0ZWQuPGJyPg0KJmd0 Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IFRoYW54IGFuZCBCUiw8YnI+DQomZ3Q7IHlhYWNvdjxi cj4NCiZndDs8YnI+DQomZ3Q7IC9TdGlsbCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHkvPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQom Z3Q7IFRoYW54IGFuZCBCUiw8YnI+DQomZ3Q7IHlhYWNvdjxicj4NCiZndDs8YnI+DQomZ3Q7IC9T dGlsbCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHkvPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyBtcGxzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgbXBsc0BpZXRmLm9yZzxicj4NCiZn dDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPGJyPg0KJmd0Ozxi cj4NCjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBt YWlsMDEuaHVhd2VpLmNvbTxicj4NClNlbmlvciBNUExTIEV4cGVydCBsb2FAcGkubnU8YnI+DQpI dWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogJiM0Mzs0NiA3MzkgODEgMjEg NjQ8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9tYWlsdG86bXBsc0BpZXRmLm9yZz48L21haWx0bzpk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz48L21haWx0bzpkcmFmdC1p ZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz48L21haWx0bzp3eWFhY292QGdtYWls LmNvbT48L21haWx0bzpyeW9vQGV0cmkucmUua3I+PC9kaXY+DQo8bWFpbHRvOnJ5b29AZXRyaS5y ZS5rcj48bWFpbHRvOnd5YWFjb3ZAZ21haWwuY29tPjxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXRw LXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+PG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dUB0b29scy5pZXRmLm9yZz48bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PC9tYWlsdG86bXBsc0BpZXRm Lm9yZz48L21haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz48 L21haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz48L21haWx0 bzp3eWFhY292QGdtYWlsLmNvbT48L21haWx0bzpyeW9vQGV0cmkucmUua3I+PC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AEFF9SMTP2etriinfo_-- From huubatwork@gmail.com Fri Dec 27 05:25:48 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 D7ECD1ADE72 for ; Fri, 27 Dec 2013 05:25: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 cRvZK9qgm7Wz for ; Fri, 27 Dec 2013 05:25:44 -0800 (PST) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 946101AE11C for ; Fri, 27 Dec 2013 05:25:44 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id n15so4091385ead.22 for ; Fri, 27 Dec 2013 05:25:39 -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=p1X9EQ5JCXfSExXpaPO5IFJAUOwkP79VtFNfKVn6Xew=; b=Tshu9sXUWP0/oEe6pjoSuUskkIvvdy0aP29rztLTEoLht73Q2byNPsyuJiE1rgiCW8 OiHey2zAWZkw/LiEiCnsza9v991lQCxGvj+TE9tXT5u3ismkDANe4mtYy9QKgHZDno34 ubmeYypv6nO/7QfbB6xEiSnv862c1Ttj0oJ91P1JPSTv3Y2t6vPR5hm0nM5atleNR0kj zX51UWborOar9IyZEnCNTSTkYV4k0hcZWfBdr8UUQAMFFBfwlWM7wadAA1YovL/p8flK JbsCAJOIuRa1m+YnogOaMTRkKoWwlrigi0W05vwzp03/h/m4tIYay3jrqfM9aFrdUwBR qbxw== X-Received: by 10.14.241.130 with SMTP id g2mr11921504eer.106.1388150739394; Fri, 27 Dec 2013 05:25:39 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id j46sm81770591eew.18.2013.12.27.05.25.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Dec 2013 05:25:38 -0800 (PST) Message-ID: <52BD7FD1.90007@gmail.com> Date: Fri, 27 Dec 2013 14:25:37 +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 , "Ryoo, Jeong-dong" , Yaacov Weingarten References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info> <52BBD59D.8000104@pi.nu> In-Reply-To: <52BBD59D.8000104@pi.nu> 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 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, 27 Dec 2013 13:25:49 -0000 Hello Loa, You replied: > Is this simply a matter of terminology. I think it is. > Each layer needs to perform its > own protection switching, i.e. there has to be a *bridge function* and a > *selector function* (on each layer depending on the implementation); I f you want to refer to the functionality, then we should consequently also use *protection switch function*. A *protection switch* is also a physical entity... > while *bridge* and *selector* are the physical layer entities? Best regards. Huub. > 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 >> > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From cpignata@cisco.com Sat Dec 28 12:31:23 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 99A381AE319 for ; Sat, 28 Dec 2013 12:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.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, 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 MwpZ9pB1S3q7 for ; Sat, 28 Dec 2013 12:31:21 -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 841AF1AE21E for ; Sat, 28 Dec 2013 12:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35075; q=dns/txt; s=iport; t=1388262675; x=1389472275; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Kd9aylN59URtWrTT3Gv2FiFZvXRkYH7L+n5MkrTRr9k=; b=hk9L4KH3WkZk8T8oEUT9GbEboulTf0DC0263QQhSWy/3HNoMYoKevyEY POncJEC5TmToYtbxmj5vt8lnuzL/m4DH3kuJlrPJRUZxg4Hy9cWKGICKw 11QWOtuWWhQXZrFhsHTWVYka2hDk+4TESDfXzrCBe9E7yOnhEiREriION M=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYGAIA0v1KtJXG//2dsb2JhbABYgkdEOFWFYKsoiFSBFRZ0giUBAQEDAQEBAWsLBQcEAgEIDgMDAQIhAQ0nCx0IAQEEDgUJBYduCA3IbxeOOwoHAT8NBAcGA4MagRMEkDOBMYYzgTCQZIFAgW2BaAcCFyI X-IronPort-AV: E=Sophos;i="4.95,567,1384300800"; d="asc'?scan'208,217";a="294237019" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 28 Dec 2013 20:31:15 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBSKVEQk011287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Dec 2013 20:31:14 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.18]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Sat, 28 Dec 2013 14:31:14 -0600 From: "Carlos Pignataro (cpignata)" To: Qin Wu Thread-Topic: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6 Thread-Index: Ac76McDT81KeKOoTQciG8BVEHs9hcQKDEk0A Date: Sat, 28 Dec 2013 20:31:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.62] Content-Type: multipart/signed; boundary="Apple-Mail=_EF1784F9-6159-4BE6-B24A-2E254CE7C73E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Short wg last call on 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: Sat, 28 Dec 2013 20:31:23 -0000 --Apple-Mail=_EF1784F9-6159-4BE6-B24A-2E254CE7C73E Content-Type: multipart/alternative; boundary="Apple-Mail=_5AD52D20-E3D6-47E9-BB65-682146CB1D1F" --Apple-Mail=_5AD52D20-E3D6-47E9-BB65-682146CB1D1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Qin, Thanks for the review! Please find some follow-up comments inline. On Dec 16, 2013, at 2:38 AM, Qin Wu wrote: > Hi, all: > Here are my review to draft-ietf-mpls-ldp-ipv6. > 1. Section 5.1 said: > =93 > Additionally, the link-local > IPv6 address MUST be used as the source IP address in IPv6 LDP Link > Hellos. > =20 > =94 > [Qin]: Why the link local multicast IPv6 address MUST be used as the = source address? > Usually multicast IPv6 address is used as destination address for = datagram, what am I missing? > =20 The use of link-local IPv6 address as a source address for packets = destined on-link is perfectly valid, and consistent with other = protocols-for-IPv6. See for example RFC 5340, "OSPF for IPv6", Sections = 2.5 and 4.1.3 (e.g., https://tools.ietf.org/html/rfc5340#section-2.5), = or "VRRP for IPv4 and IPv6" Section 5.1.2.1 (i.e., = http://tools.ietf.org/search/rfc5798#section-5.1.2.1). Further, the document clearly says: Additionally, the link-local IPv6 address MUST be used as the source IP address in IPv6 LDP Link Hellos. But also: The link-local IP addresses MUST NOT be used as the source or destination IPv6 addresses in extended discovery. > 2. Section 5.1, last paragraph said: > =93 > Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the same LDP > identifier (assuming per-platform label space usage). > =20 > =94 > s/must/MUST OK > 3. Section 5.2, 1st paragraph said: > =93 > Suffice to say, the extended discovery mechanism (defined in section > 2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific > consideration, since the targeted LDP Hellos are sent to a pre- > configured (unicast) destination IPv6 address. > =94 > =20 > [Qin]; It is better to clarify the purpose of extended discovery = mechanism? E.g., for > discovery of the LSR that is not directly connected in the LDP = session? > =20 It is not for "discovery of the LSR that is not directly connected in = the LDP session". It is for "LDP discovery between non-directly = connected LSRs." But in any case, there is a pointer to the exact section of RFC 5036 = where this is specified at the source. I would not want to try to = re-define with a one-liner, since RFC 5036 is normative. > 4. Section 6.1, said: > =93 > however, it does not specify the > behavior of LDP if both IPv4 and IPv6 transport address objects > (TLV) are sent in a Hello message or separate Hello messages. > =20 > =94 > [Qin]: It is better to distinct one Hello from two Hello, so suggest = the following change > s/separate Hello/two separate Hello > =20 "messages" in "or separate Hello messages" is plural, I do not see the = need for this change. > 5. Section 6.1,2nd bullet: > =93 > O An LSR SHOULD accept the Hello message that contains both IPv4 > and IPv6 transport address optional objects, but MUST use only > the transport address whose address family is the same as that > of the IP packet carrying Hello. > =20 > =94 > [Qin]: Since LSR is not allowed to send a Hello containing both IPv4 = and IPv6 transport address, why receiving LSR need to process such Hello = message? > =20 Because of the robustness principle. > 6.Section 6.1, 5th bullet: > =93 > An LSR MUST prefer using global unicast IPv6 address for an LDP > session with a remote LSR, if it had to choose between global > unicast IPv6 address and unique-local or link-local IPv6 > address (pertaining to the same LDP Identifier) for the > transport connection. > =94 > [Qin]: Can unique-local or link local IPv6 address be used in IPv6 = transport address optional object? Is bullet 5 contradict with bullet 4? > =20 No contradiction, bullet #4 is about "targeted hellos" only. > 7. Section 6.2 said: > =93 > This document allows an LSR to maintain Rx-side Link Hello adjacency > for only one address family that has been used for the establishment > of the LDP session. > =94 > [Qin]: What does Rx-side mean? > Is there sender side Link Hello? Rx-side means receive-side. This nomenclature is consistent with RFC = 5036. However, reading that sentence, I believe there is a small mistake, that = this sentence did not incorporate an additional change suggested by = Mustapha (missing "however"), and I will clarify that there can be one = or two hello adjacencies maintained. Thanks again for the review. Net-net, these are the upcoming changes: 1. s/must/MUST/ in last para of Section 5.1., from Qin in this email. 2. Section 6.2 last sentence, from Mustapha+Carlos. 3. Additional fixes identified by Loa: add a pre-5378 clause to the = Copyright notice, and fix idnits. Thanks, -- Carlos. > =20 > -----Original Message----- > From: Loa Andersson > Date: Wednesday, December 11, 2013 11:52 PM > To: "mpls at ietf.org" , "mpls-chairs at = tools.ietf.org" > , Martin Vigoureux > , > "draft-ietf-mpls-ldp-ipv6 at tools.ietf.org" > > Subject: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6 > =20 > >Working Group, > >=20 > >This is to start a one week working group last call on > >draft-ietf-mpls-ldp-ipv6-10 > >=20 > >We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good > >comments and the document almost ready to go. At that point a = discussion > >on the number of LDP session needed between a pair LSRs with both = IPv4 > >and IPv6 emerged, it has taken us quite a long time to resolve this. > >=20 > >However, the author, wg chairs and people making the comments now = agree > >that version -10 is resolve those comments. > >=20 > >This working group last call is limited to the changes since the > >previous last call. A diff can be found at: > >=20 > = >http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-ldp-ipv6-07&difftype=3D= --ht > >ml&submit=3DGo%21&url2=3Ddraft-ietf-mpls-ldp-ipv6-10 > >=20 > >Please send you comments to the MPLS wg mailing list (mpls at = ietf.org). > >=20 > >This wglc ends Dec 20, 2013. > >=20 > >/Loa > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_5AD52D20-E3D6-47E9-BB65-682146CB1D1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, = Qin,

Thanks for the review! Please find some = follow-up comments inline.

On Dec 16, 2013, at = 2:38 AM, Qin Wu <bill.wu@huawei.com> = wrote:

Hi, = all:
Here are my review to = draft-ietf-mpls-ldp-ipv6.
1. Section = 5.1 said:
=93
Additionally, the = link-local
IPv6 address MUST = be used as the source IP address in IPv6 LDP = Link
Hellos.
 
=94
[Qin]: Why the link local = multicast IPv6 address MUST be used as the source = address?
Usually = multicast IPv6 address is used as destination address for datagram, what = am I missing?
 

The use of link-local IPv6 address as a source address for = packets destined on-link is perfectly valid, and consistent with other = protocols-for-IPv6. See for example RFC 5340, "OSPF for IPv6", Sections = 2.5 and 4.1.3 (e.g., https://tools.iet= f.org/html/rfc5340#section-2.5), or "VRRP for IPv4 and IPv6" Section = 5.1.2.1 (i.e., http://tools= .ietf.org/search/rfc5798#section-5.1.2.1).

Fu= rther, the document clearly says:

  =  Additionally, the link-local
   IPv6 address = MUST be used as the source IP address in IPv6 LDP Link
  =  Hellos.

But = also:

   The link-local IP = addresses MUST NOT be used as the source or
  =  destination IPv6 addresses in extended = discovery.


2. Section = 5.1, last paragraph said:
=93
Lastly, the IPv6 = and IPv4 LDP Link Hellos must carry the same = LDP
identifier = (assuming per-platform label space usage).
 
=94
s/must/MUST
<= br>
OK

3. Section 5.2, 1st paragraph = said:
=93
Suffice to say, = the extended discovery mechanism (defined in = section
2.4.2 of = [RFC5036]) doesn't require any additional IPv6 = specific
consideration, = since the targeted LDP Hellos are sent to a = pre-
configured = (unicast) destination IPv6 address.
=94
 
[Qin]; It is better to clarify the purpose of = extended discovery mechanism? E.g., for
discovery of the LSR that is not directly = connected in the LDP session?
 

It is not for "discovery of the LSR that is not directly = connected in the LDP session". It is for "LDP discovery between = non-directly connected LSRs."

But in any case, = there is a pointer to the exact section of RFC 5036 where this is = specified at the source. I would not want to try to re-define with a = one-liner, since RFC 5036 is normative.

4. Section = 6.1, said:
=93
however, it does = not specify the
   = behavior of LDP if both IPv4 and IPv6 transport address = objects
   = (TLV) are sent in a Hello message or separate Hello = messages.
 
=94
[Qin]: It is better to distinct = one Hello from two Hello, so suggest the following change
s/separate = Hello/two separate Hello
 

"messages" in "or separate Hello messages" is plural, I do not = see the need for this change.

5. Section = 6.1,2nd bullet:
=93
O An LSR SHOULD = accept the Hello message that contains both = IPv4
and IPv6 = transport address optional objects, but MUST use = only
the transport = address whose address family is the same as = that
of the IP packet = carrying Hello.
 
=94
[Qin]: Since LSR is = not allowed to send a Hello containing both IPv4 and IPv6 transport = address, why receiving LSR need to process such Hello = message?
 

Because of the robustness principle.

6.Section 6.1, = 5th bullet:
=93
An LSR MUST = prefer using global unicast IPv6 address for an = LDP
session with a = remote LSR, if it had to choose between = global
unicast IPv6 = address and unique-local or link-local IPv6
address (pertaining to the same LDP Identifier) for = the
transport = connection.
=94
[Qin]: Can = unique-local or link local IPv6 address be used in IPv6 transport = address optional object? Is bullet 5 contradict with bullet = 4?
 

No contradiction, bullet #4 is about "targeted hellos" = only.

7. Section 6.2 said:
=93
This document = allows an LSR to maintain Rx-side Link Hello = adjacency
for only one = address family that has been used for the = establishment
of the LDP = session.
=94
[Qin]: What does = Rx-side mean?
Is there sender side = Link Hello?

Rx-side = means receive-side. This nomenclature is consistent with RFC = 5036.

However, reading that sentence, I believe = there is a small mistake, that this sentence did not incorporate an = additional change suggested by Mustapha (missing "however"), and I will = clarify that there can be one or two hello adjacencies = maintained.

Thanks again for the = review.

Net-net, these are the upcoming = changes:
1. s/must/MUST/ in last para of Section 5.1., from = Qin in this email.
2. Section 6.2 last sentence, from = Mustapha+Carlos.
3. Additional fixes identified by Loa: add a = pre-5378 clause to the Copyright notice, and fix = idnits.

Thanks,

-- = Carlos.

 
-----Original Message-----
From: Loa Andersson <loa at = pi.nu>
Date: Wednesday, = December 11, 2013 11:52 PM
To: "mpls = at ietf.org" <mpls at ietf.org>, = "mpls-chairs at tools.ietf.org"
<mpls-chairs at tools.ietf.org>, Martin = Vigoureux
<martin.vigoureux = at alcatel-lucent.com>,
"draft-ietf-mpls-ldp-ipv6 at tools.ietf.org"
<draft-ietf-mpls-ldp-ipv6 at tools.ietf.org>
Subject: [mpls] Short wg last call on = draft-ietf-mpls-ldp-ipv6
 
>Working Group,
> 
>This = is to start a one week working group last call on
>draft-ietf-mpls-ldp-ipv6-10
> 
>We did a wglc on draft draft-ietf-mpls-ldp-ipv6 = mid-2011. We had good
>comments and the document almost ready to go. At that = point a discussion
>on the = number of LDP session needed between a pair LSRs with both = IPv4
>and IPv6 emerged, it has = taken us quite a long time to resolve this.
> 
>However, the author, wg chairs and people making the = comments now agree
>that = version -10 is resolve those comments.
> 
>This working group last call is limited to the changes = since the
>previous last = call. A diff can be found at:
> 
>ml&submit=3DGo%21&url2=3Ddraft-ietf-mpls-ldp-ipv6= -10
> 
>Please send you comments to the MPLS wg = mailing list (mpls at ietf.org).
> 
>This = wglc ends Dec 20, 2013.
> 
>/Loa
_______________________________________________
mpl= s mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

= --Apple-Mail=_5AD52D20-E3D6-47E9-BB65-682146CB1D1F-- --Apple-Mail=_EF1784F9-6159-4BE6-B24A-2E254CE7C73E 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 iEYEARECAAYFAlK/NRAACgkQtfDPGTp3USxOHgCfVoV2I1kR8vyrv3iQhvvCW1XN QPAAoLJiCzhHOjjIgiLklG2q3BnphHS6 =de9y -----END PGP SIGNATURE----- --Apple-Mail=_EF1784F9-6159-4BE6-B24A-2E254CE7C73E-- From adrian@olddog.co.uk Sat Dec 28 13:04:34 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 C25D01AE25E for ; Sat, 28 Dec 2013 13:04:34 -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, GB_I_LETTER=-2, J_BACKHAIR_36=1, 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 fkCTqAL4ShiB for ; Sat, 28 Dec 2013 13:04:31 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 569421AE04C for ; Sat, 28 Dec 2013 13:04:30 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBSL4O6S010526; Sat, 28 Dec 2013 21:04:24 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBSL4LvF010500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Dec 2013 21:04:22 GMT From: "Adrian Farrel" To: Date: Sat, 28 Dec 2013 21:04:28 -0000 Message-ID: <065201cf0410$6652e450$32f8acf0$@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: Ac8EEC27yslTAmK5TWy5V5T/TIXwEQ== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-tp-te-mib 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, 28 Dec 2013 21:04:35 -0000 Hello authors, I have performed my usual AD review of your draft on receipt of the publication request. As you can see below, it has generated quite a few comments and as a result I have placed the document into "Revised I-D Needed" state. I have tried to flag where I think my comment might be a function of "I wouldn't have done it like this" and I am open to discussion of all of the points I have raised. Thanks for your work. Adrian === I think Tom may want to change his coordinates. --- It would be nice if someone could do a pass on this document for English and format. It is not essential because the RFC Editor will resolve these issues, but it is wise because the fewer changes the RFC Editor makes, the less chance there is of an accidental error. --- You have the RFC 2119 boilerplate present twice. --- What does it mean to use RFC 2119 language in the examples in Section 9? --- I see a contradiction in In particular, it describes managed objects of Tunnels, Identifiers, Label Switching Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). These MIB modules extend the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP operations, so the MPLS-TP name is not included in the MIB module name. Either the extensions are for MPLS-TP or they are not. Your second sentence says they are for more general applicability, and I agree with that. So why does the first sentence and the document title talk about MPLS-TP? --- I think the Introduction would be made more useful and relevant if it described the purpose and content of this document. Currently it says what the existing documents don't do (although even that is pretty vague). The existing Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) [RFC3812] and Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base [RFC4802] do not support the transport network requirements of NON-IP based management and static bidirectional tunnels. There is also an implication here that this MIB module supports non-IP based management. I looked but didn't see any description of how to run SNMP in the absence of IP. It goes on... These MIB modules should be used in conjunction with [RFC3812] and companion document [RFC3813] for MPLS-TP tunnel configuration and management. What is an "MPLS-TP tunnel"? --- Section 4 might have been an opportunity to provide the information I think is missing from the Introduction. But unfortunately it repeats some of the text form the Introduction and then gives a very scanty description of the purpose of the work. Here, however, I find the text As the existing MPLS- TE-STD-MIB is not sufficient to capture all the characteristics of the tunnels, enhancing the MIB to support MPLS TP tunnels is required. As most of the attributes of MPLS Traffic Engineering tunnels are also applicable to MPLS-TP tunnels, it is optimal to re-use the existing MIB definition instead of a new MIB. This doesn't explain why you don't leverage GMPLS-TE-STD-MIB and GMPLS-LSR-STD-MIB. Naively, it seems that the co-routed case is already handled, and the associated case can be handled with just one cross- pointer (the association) between the forward and reverse entries in MPLS-TE-STD-MIB. I hate to say "I would not have done it this way", but you seem to be introducing a lot of complexity. --- I think the boilerplate in Section 2 is supposed to have the references in square brackets as citations. --- Not sure you need all of your acronyms GMPLS is only used in the same place as it is expanded. IP is surely too well known ITU and ITU-T are "well-known" according to the RFC editor MIB is "well-known" according to the RFC editor MPLS is "well-known" according to the RFC editor OSPF is "well-known" according to the RFC editor --- Why does section 5 only discuss MPLS-TE-EXT-STD-MIB? What about the other MIB modules defined in this document? --- Why does section 6 only discuss MPLS-TE-EXT-STD-MIB? What about the other MIB modules defined in this document? --- Section 6 introduces 5 new tables. Section 8 shows a figure containing only 3 of the new tables. Something missing? --- Section 6 is titled 6. Brief description of MPLS-TE-EXT-STD-MIB Objects but I think it really only describes the tables. --- Section 6.1 has Each ICC_Operator_ID::Node_ID or Global_ID::Node_ID contains one unique entry in the table representing a node. What does this containing relationship mean? --- Section 6.1 As the regular TE tunnels use IP address as LSR ID, the local identifier should be below the first valid IP address, which is 16777216[1.0.0.0]. What does "should" mean in this context? --- There is no clear mention of the dependency on MPLS-TC-STD-MIB. I think this should be added to Section 7. It is probably best to not attempt to add this to the figure. Instead you could add text to say: Note that all of the MB modules shown in the figure also have a dependency on MPLS-TC-STD-MIB. --- I think you could usefully clarify the meanings of "extends" versus "augments" versus "sparse augments". In 6.4 you have: mplsTunnelExtTable extends the mplsTunnelTable In 6.5 you have: This table sparse augments the mplsTunnelTable In Section 7 you have: MPLS-TE-STD-MIB [RFC3812] is extended by MPLS-TE-EXT-STD-MIB MIB module for associating the reverse direction tunnel information. Note that the nature of the 'extends' relationship is a sparse augmentation so that the entry in the mplsTunnelExtTable has the same index values as the in the mplsTunnelTable. MPLS-LSR-STD-MIB [RFC3813] is extended by MPLS-LSR-EXT-STD-MIB MIB module for pointing back to the tunnel entry for easy tunnel access from XC entry. Note that the nature of the 'extends' relationship is a sparse augmentation so that the entry in the mplsXCExtTable has the same index values as the in the mplsXCTable. I think that all of uses of "table A extends table B" mean "sparse augments" so I suggest you just use the latter language and avoid confusion and the need to explain the meaning of "extends". --- There is an awful lot of write-access in these MIB modules. Haven't we moved on from 2004 to a view that SNMP SETs on this type of complex data are not useful? Why did the working group decide that creatable/writeable objects were valuable? --- Section 9 would be a lot clearer if it began with a description of the LSP being "configured". --- Entries in MplsTunnelExtNodeConfigEntry are indexed by mplsTunnelExtNodeConfigLocalId. A combination of [Global_ID and Node_ID] or [CC::ICC and Node_ID] has a unique entry. Suppose I have a new LSP in my hand. It has [CC=AB, ICC=123456]. I want to create an entry or use an existing one. Do I have to read every entry in the table to find out if one already exists? --- The first and only mention of pseudowires is in the Description clause of MPLS-TC-EXT-STD-MIB. This either means you are missing lots of explanations and examples, or that the Description clause (and terminology section) should have PW removed. --- Shouldn't the description and definition of MplsGlobalId be more proscriptive and precise? The Description says... the Global_ID can contain the 2-octet or 4-octet value of the operator's Autonomous System Number (ASN). I.e. "can". Also... It is expected that the Global_ID will be derived from the globally unique ASN of the autonomous system hosting the PEs containing the actual AIIs. I.e. "expected". And... When the Global_ID is derived from a 2-octet AS number, the two high-order octets of this 4-octet identifier MUST be set to zero. I.e. "derived from". And finally a "MUST" but still "derived from" A non-zero Global_ID MUST be derived from an ASN owned by the operator." But the Syntax is given as... SYNTAX OCTET STRING (SIZE (4)) ...and since the mechanism for derivation is not explained and there is no limitation stated that the characters in the Octet String be digits, I can think of many ways to "derive" the Global ID. Furthermore, in... When the Global_ID is derived from a 2-octet AS number, the two high-order octets of this 4-octet identifier MUST be set to zero. ... Does "set to zero" mean set to 0x00 or set to 0x30? --- Why is it necessary to allow a zero length of MplsIccId when you don't allow a zero length of MplsGlobalId or MplsCcId. I don't see why the ICC is special in this respect. --- In MplsIccId what does this mean? Alphabetic characters in the ICC SHOULD be represented with upper case letters. How does that change the implementation? I think it means that it has to accept upper and lower case characters. Furthermore, what might be signaled? I suggest you should be consistent with T.50 for the CC and ICC character sets. --- MplsNodeId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The Node_ID is assigned within the scope of the Global_ID/ICC_Operator_ID. The value 0(or 0.0.0.0 in dotted decimal notation) is reserved and MUST NOT be used. When IPv4 addresses are in use, the value of this object can be derived from the LSR's IPv4 loop back address. When IPv6 addresses are in use, the value of this object can be a 32-bit value unique within the scope of a Global_ID. Is the mention of 0.0.0.0 meaningful? The display hint is "d" and the value might just be a 32 bit number for the IPv6 case or for the non-IP case. --- MplsNodeId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The Node_ID is assigned within the scope of the Global_ID/ICC_Operator_ID. The value 0(or 0.0.0.0 in dotted decimal notation) is reserved and MUST NOT be used. SYNTAX Unsigned32 (0|1..4294967295) If zero MUST NOT be used, why is it allowed in the Syntax? What is it reserved for? --- What is the point of defining -- notifications mplsIdNotifications OBJECT IDENTIFIER ::= { mplsIdStdMIB 0 } if you don't use it? --- I am slightly bothered that MPLS-ID-STD-MIB includes TCs with wider applicability and scalar objects. I suspect that the CC and ICC TCs could be used more generally in the IETF. I suspect that many uses of these TCs would not be interested in the scalar MPLS objects, or that those scalar objects are not limited to MPLS. And I wonder why the scalars are not in the MPLS-LSR-EXT-STD-MIB module as they, like the LSR ID, apply to the local node. --- The objects in MPLS-ID-STD-MIB are read-write (not read-create). Taking one as an example, you have... mplsIdGlobalId OBJECT-TYPE SYNTAX MplsGlobalId MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows the operator to assign a unique operator identifier also called MPLS-TP Global_ID. If this value is used in mplsTunnelExtNodeConfigGlobalId for mapping Global_ID::Node_ID with the local identifier then this object value SHOULD NOT be changed." ::= { mplsIdObjects 1 } Since the object is not read-create, we can assume that it is pre- populated by the node (from configuration). The meaning of "SHOULD NOT be changed" is then in conflict with the writeability of the object. Furthermore, "SHOULD NOT" is not "MUST NOT" so I think you need to explain the circumstances under which it can be changed - that probably really means explaining the consequences if it is changed. And anyway, I think you mean "...SET operations on this object SHOULD be rejected by the node with the return code foo" since the management agent is unlikely to know that the condition applies. But really... Why are any of these objects writeable? --- mplsIdNodeId OBJECT-TYPE SYNTAX MplsNodeId MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows the operator or service provider to assign a unique MPLS-TP Node_ID. Why can operators and service providers assign Node_IDs, but only operators assign Global_IDs in mplsIdGlobalId? --- mplsIdCc OBJECT-TYPE SYNTAX MplsCcId MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows the operator or service provider to assign a unique Country Code (CC). Global uniqueness is assured by concatenating the ICC with a Country Code (CC). "...assign a unique CC" to what? "Global uniqueness" of what? --- mplsIdIcc OBJECT-TYPE SYNTAX MplsIccId MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows the operator or service provider to assign a unique MPLS-TP ITU-T Carrier Code (ICC) to a network. I don't think so! This object is going to be realised on a node, not "on a network". Setting this object will not make a change to the ICC applied to the rest of the network. --- mplsIdModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support the MPLS-ID-STD-MIB module." MODULE -- this module -- The mandatory group has to be implemented by all -- LSRs that originate/terminate MPLS-TP paths. This may be true, but it implies that other nodes do not need to support this module. Surely it is needed for MPLS-TP OAM support. --- The definition of mplsIdModuleReadOnlyCompliance seems to imply that an IP-capable node MUST support mplsIdIcc and mplsIdCc. Why is that? --- Odd, but maybe not important, that the objects in mplsIdModuleReadOnlyCompliance and mplsIdScalarGroup are not in the same order as those in mplsIdObjects. --- I don't see why you need mplsXCExtTable. I think there may be some confusion about how the TE MIB and LSR MIB are related. In 3812 and 3813 it is entirely deliberate that there is no back pointer from the XC to the tunnel. The point being that you do not look up an XC and then try to find out which tunnel it belongs to. Perhaps you were looking at how to associate the forward and reverse XCs, but I note (in your example in 9.2) that you have used the same XC index for the forward and reverse XCs (which is the right way to do it). You should note that the extensions in 4803 give directions to the segments to support this and allow you to distinguish between the forward XC and the reverse XC. You should also note that mplsTunnelXCPointer gives a pointer from tunnel to XC, so all that is missing is the association between forward and reverse tunnels. I would think that the correct way is with an extension to the mplsTunnelTable to point to "associated tunnels" in a generic way that supports all association types not just this one specific association. So I am left wondering what is the purpose of mplsXCExtTable Ah, is it the case that you think the forward and reverse tunnels and their corresponding XCs might be set up *before* you know that they are associated? I don't think this happens. To try to clarify this, I think you have... Tunnel1-->XC1<-------------- A | | | | | |-->InSeg1 | | | |-->OutSeg1 | | v | ------XCext1 | | | v | Tunnel2-->XC2 | A | | | | | |-->InSeg2 | | | |-->OutSeg2 | | v | ------XCext2------------ And it might be useful to show this figure somewhere. But your example doesn't do this. What I was expecting is: Tunnel1-->XC1 A A | | | |-->InSeg1 | | |-->OutSeg1 V V Tunnel2-->XC2 | |-->InSeg2 |-->OutSeg2 Where the only thing that is not already in the existing MIB modules is the pointers associating Tunnel1 and Tunnel2. Noting that for a bidir tunnel what you currently have (in the existing MIB modules) is: Tunnel1-->XC1 A | | |-->InSeg1 | |-->OutSeg1 V XC2 | |-->InSeg2 |-->OutSeg2 And if you insist on knowing the tunnel that applies to an XC (which, as you point out would be read-only information) then your extension table only needs a pointer from XC to tunnel to give: Tunnel1<->XC1 A A | | | |-->InSeg1 | | |-->OutSeg1 V V Tunnel2<->XC2 | |-->InSeg2 |-->OutSeg2 I can't decide how much of this is "I wouldn't have done it this way" and how much is broken. You are certainly failing to take advantage of the fact that all related XCs have the same XCindex value. --- Assuming that you continue with the mplsXCExtTable, what happens when the entry in mplsXCTable corresponding to mplsXCExtOppositeDirXCPtr is deleted? --- When I create a new entry in mplsTunnelExtNodeConfigTable, how do I know what is a suitable value for mplsTunnelExtNodeConfigLocalId? You probably need an mplsTunnelExtNodeConfigLocalIdNextFree scalar. --- The Description clause of mplsTunnelExtOppositeDirPtr is pretty hard to read. It might be easier if used the term "associated bidirectional". "This object is applicable only for the bidirectional tunnel that has the forward and reverse LSPs in the same tunnel or in the different tunnels. ...is quite confusing. The value of zeroDotZero indicates single tunnel entry is used for bidirectional tunnel setup." Surely it is also used when only one of the two tunnels has been set up. That means that you cannot use the value of zeroDotZero to determine that a single bidirectional tunnel is in use. And this is presumably why you have mplsTunnelExtOppositeDirTnlValid --- I have the same problem understanding the Description of mplsTunnelExtDestTnlIndex "This object is applicable only for the bidirectional tunnel that has the forward and reverse LSPs in the same tunnel or in the different tunnels. --- Why did you need to define mplsTunnelExtReversePerfTable? If you have two associated tunnels then each has its own mplsTunnelPerfEntry. If you have a single bidirectional tunnel then GMPLS-TE-STD-MIB has gmplsTunnelReversePerfTable. --- Section 14 should also mention objects with MAX-ACCESS of read-create. From adrian@olddog.co.uk Sat Dec 28 13:39:32 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 0DA141AE363 for ; Sat, 28 Dec 2013 13:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.147 X-Spam-Level: ** X-Spam-Status: No, score=2.147 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RZB-VIGS7qSk for ; Sat, 28 Dec 2013 13:39:30 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 83B331AE35F for ; Sat, 28 Dec 2013 13:39:30 -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 rBSLdOXU007652; Sat, 28 Dec 2013 21:39:24 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBSLdMho007634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Dec 2013 21:39:23 GMT From: "Adrian Farrel" To: Date: Sat, 28 Dec 2013 21:39:28 -0000 Message-ID: <066901cf0415$4a41e310$dec5a930$@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: Ac8EFSDq7xKq0fuuRaSr2vJFI3xe3A== Content-Language: en-gb X-TM-AS-MML: No Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-tp-p2mp-framework 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, 28 Dec 2013 21:39:32 -0000 Thanks for this document. I have done my usual AD review on receiving the publication request and I find just a couple of nits that can be rolled into the IETF last call which I will start forthwith. Thanks, Adrian === 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. From internet-drafts@ietf.org Sat Dec 28 14:12:21 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 3D07A1AE394; Sat, 28 Dec 2013 14:12: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 rKGuhZnGHsTW; Sat, 28 Dec 2013 14:12:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B401AE24A; Sat, 28 Dec 2013 14:12:19 -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: <20131228221219.20577.29058.idtracker@ietfa.amsl.com> Date: Sat, 28 Dec 2013 14:12:19 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-11.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: Sat, 28 Dec 2013 22:12:21 -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 LDP for IPv6 Authors : Rajiv Asati Vishwas Manral Rajiv Papneja Carlos Pignataro Filename : draft-ietf-mpls-ldp-ipv6-11.txt Pages : 18 Date : 2013-12-28 Abstract: The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ipv6-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From loa@pi.nu Sat Dec 28 21:21:15 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 5310F1AE4E8 for ; Sat, 28 Dec 2013 21:21:15 -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 O6u61ejgebGX for ; Sat, 28 Dec 2013 21:21:13 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 01FF01AE13C for ; Sat, 28 Dec 2013 21:21:12 -0800 (PST) Received: from [192.168.1.5] (unknown [49.147.206.252]) (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 6DF8818013E2; Sun, 29 Dec 2013 06:21:03 +0100 (CET) Message-ID: <52BFB141.9000502@pi.nu> Date: Sun, 29 Dec 2013 13:21:05 +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: <52A71923.8090701@pi.nu> In-Reply-To: <52A71923.8090701@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-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: Sun, 29 Dec 2013 05:21:15 -0000 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 From internet-drafts@ietf.org Sat Dec 28 22:41:22 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 2B24E1AE4FF; Sat, 28 Dec 2013 22: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 RewsQnfbzp7H; Sat, 28 Dec 2013 22:41:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDAE1AE283; Sat, 28 Dec 2013 22:41:20 -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: <20131229064120.1838.75648.idtracker@ietfa.amsl.com> Date: Sat, 28 Dec 2013 22:41:20 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: 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: Sun, 29 Dec 2013 06:41: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 : LDP Extensions for Hub & Spoke Multipoint Label S= witched Path Authors : Lizhong Jin Frederic Jounay IJsbrand Wijnands Nicolai Leymann Filename : draft-ietf-mpls-mldp-hsmp-06.txt Pages : 16 Date : 2013-12-28 Abstract: 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. Direct communication among the leaf nodes is not allowed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-hsmp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-mldp-hsmp-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-mldp-hsmp-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 loa@pi.nu Sun Dec 29 02:04:42 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 4CE391ADF5B for ; Sun, 29 Dec 2013 02:04:42 -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 rRWR_wym4Dyh for ; Sun, 29 Dec 2013 02:04:38 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8A62E1ADF4E for ; Sun, 29 Dec 2013 02:04:37 -0800 (PST) Received: from [192.168.1.5] (unknown [49.147.206.252]) (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 5DB8718013E2; Sun, 29 Dec 2013 11:04:27 +0100 (CET) Message-ID: <52BFF3AB.3070609@pi.nu> Date: Sun, 29 Dec 2013 18:04:27 +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> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEFF9@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: Sun, 29 Dec 2013 10:04:42 -0000 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 From internet-drafts@ietf.org Sun Dec 29 11:14:57 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 693311AE269; Sun, 29 Dec 2013 11:14: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 45KTX_5NLgvm; Sun, 29 Dec 2013 11:14:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC051AE1B9; Sun, 29 Dec 2013 11:14:55 -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: <20131229191455.22849.6977.idtracker@ietfa.amsl.com> Date: Sun, 29 Dec 2013 11:14:55 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-special-purpose-labels-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, 29 Dec 2013 19:14:57 -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 : Allocating and Retiring Special Purpose MPLS Labe= ls Authors : Kireeti Kompella Loa Andersson Adrian Farrel Filename : draft-ietf-mpls-special-purpose-labels-04.txt Pages : 13 Date : 2013-12-29 Abstract: Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these special purpose labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines new procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. This document updates a number of previous RFCs that used the term "reserved label". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose-labels/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-special-purpose-labels-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-special-purpose-labels-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 adrian@olddog.co.uk Sun Dec 29 11:17:24 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 39A8B1AE254 for ; Sun, 29 Dec 2013 11:17:24 -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 HCVOaUQhUOqc for ; Sun, 29 Dec 2013 11:17:22 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 131381AE29A for ; Sun, 29 Dec 2013 11:17:21 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBTJHFbN004738 for ; Sun, 29 Dec 2013 19:17:15 GMT Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBTJHDEV004722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 29 Dec 2013 19:17:14 GMT From: "Adrian Farrel" To: References: <20131229191455.22849.51865.idtracker@ietfa.amsl.com> In-Reply-To: <20131229191455.22849.51865.idtracker@ietfa.amsl.com> Date: Sun, 29 Dec 2013 19:17:19 -0000 Message-ID: <06ad01cf04ca$992a12d0$cb7e3870$@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: AQIse+4D1gIgS8Z8U3RQx53i7D9nIJmwnMCw Content-Language: en-gb Subject: [mpls] FW: New Version Notification for draft-ietf-mpls-special-purpose-labels-04.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: Sun, 29 Dec 2013 19:17:24 -0000 Hi, A long time in gestation. Moral: ADs and Chairs and Kireetis are always = too busy to focus on real work. This revision intends to address all WG last call comments. Please shout = if we have messed up. The changes are... - Note in Abstract about updated RFCs. - Minor changes to 3.1 per Mach Chen. - New section 3.1.1 after discussion with Curtis. - Clarify the IANA policy for the reserved extended special purpose = labels per Maria. - Clarification in 3.1 per Alia and Eric. - Drop Note 3 from the IANA Considerations per Curtis. - Introduce acronyms XL and ESPL per Curtis. - Add note on rate-limiting logs to Section 6. - Typos - Added Acknowledgements Chairs, we believe this is now complete. Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 29 December 2013 19:15 > To: Loa Andersson; Kireeti Kompella; Kireeti Kompella; Adrian Farrel; = Adrian > Farrel; Loa Andersson > Subject: New Version Notification for = draft-ietf-mpls-special-purpose-labels- > 04.txt >=20 >=20 > A new version of I-D, draft-ietf-mpls-special-purpose-labels-04.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-ietf-mpls-special-purpose-labels > Revision: 04 > Title: Allocating and Retiring Special Purpose MPLS Labels > Document date: 2013-12-29 > Group: mpls > Pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-mpls-special-purpose- > labels-04.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose- > labels/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-mpls-special-purpose-labels-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-special-purpose- > labels-04 >=20 > Abstract: > Some MPLS labels have been allocated for specific purposes. A = block > of labels (0-15) has been set aside to this end, and are commonly > called "reserved labels". They will be called "special purpose > labels" in this document. >=20 > As there are only 16 of these special purpose labels, caution is > needed in the allocation of new special purpose labels, yet at the > same time allow forward progress when one is called for. >=20 > This memo defines new procedures to follow in the allocation and > retirement of special purpose labels, as well as a method to extend > the special purpose label space. Finally, this memo renames the = IANA > registry for these labels to "Special Purpose MPLS Label Values", = and > creates a new one called the "Extended Special Purpose MPLS Label > Values" registry. >=20 > This document updates a number of previous RFCs that used the term > "reserved label". >=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 bill.wu@huawei.com Sun Dec 29 18:53:23 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 660061AE395 for ; Sun, 29 Dec 2013 18:53:23 -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 YRm2v-OX_V2D for ; Sun, 29 Dec 2013 18:53:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 613161AE392 for ; Sun, 29 Dec 2013 18:53:18 -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 BBZ18929; Mon, 30 Dec 2013 02:53:11 +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; Mon, 30 Dec 2013 02:52:11 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Dec 2013 02:53:09 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 30 Dec 2013 10:53:04 +0800 From: Qin Wu To: "Carlos Pignataro (cpignata)" Thread-Topic: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6 Thread-Index: Ac76McDT81KeKOoTQciG8BVEHs9hcQKDEk0AADMHqjA= Date: Mon, 30 Dec 2013 02:53:03 +0000 Message-ID: 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.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C6F3E4nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Short wg last call on 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 02:53:23 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C6F3E4nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Carlos: Thank for your clarification and proposed changes. Your proposed changes look good to me. Regards! -Qin From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Sunday, December 29, 2013 4:31 AM To: Qin Wu Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6 Hi, Qin, Thanks for the review! Please find some follow-up comments inline. On Dec 16, 2013, at 2:38 AM, Qin Wu > wrote: Hi, all: Here are my review to draft-ietf-mpls-ldp-ipv6. 1. Section 5.1 said: " Additionally, the link-local IPv6 address MUST be used as the source IP address in IPv6 LDP Link Hellos. " [Qin]: Why the link local multicast IPv6 address MUST be used as the source= address? Usually multicast IPv6 address is used as destination address for datagram,= what am I missing? The use of link-local IPv6 address as a source address for packets destined= on-link is perfectly valid, and consistent with other protocols-for-IPv6. = See for example RFC 5340, "OSPF for IPv6", Sections 2.5 and 4.1.3 (e.g., ht= tps://tools.ietf.org/html/rfc5340#section-2.5), or "VRRP for IPv4 and IPv6"= Section 5.1.2.1 (i.e., http://tools.ietf.org/search/rfc5798#section-5.1.2.= 1). Further, the document clearly says: Additionally, the link-local IPv6 address MUST be used as the source IP address in IPv6 LDP Link Hellos. But also: The link-local IP addresses MUST NOT be used as the source or destination IPv6 addresses in extended discovery. 2. Section 5.1, last paragraph said: " Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the same LDP identifier (assuming per-platform label space usage). " s/must/MUST OK 3. Section 5.2, 1st paragraph said: " Suffice to say, the extended discovery mechanism (defined in section 2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific consideration, since the targeted LDP Hellos are sent to a pre- configured (unicast) destination IPv6 address. " [Qin]; It is better to clarify the purpose of extended discovery mechanism?= E.g., for discovery of the LSR that is not directly connected in the LDP session? It is not for "discovery of the LSR that is not directly connected in the L= DP session". It is for "LDP discovery between non-directly connected LSRs." But in any case, there is a pointer to the exact section of RFC 5036 where = this is specified at the source. I would not want to try to re-define with = a one-liner, since RFC 5036 is normative. 4. Section 6.1, said: " however, it does not specify the behavior of LDP if both IPv4 and IPv6 transport address objects (TLV) are sent in a Hello message or separate Hello messages. " [Qin]: It is better to distinct one Hello from two Hello, so suggest the fo= llowing change s/separate Hello/two separate Hello "messages" in "or separate Hello messages" is plural, I do not see the need= for this change. 5. Section 6.1,2nd bullet: " O An LSR SHOULD accept the Hello message that contains both IPv4 and IPv6 transport address optional objects, but MUST use only the transport address whose address family is the same as that of the IP packet carrying Hello. " [Qin]: Since LSR is not allowed to send a Hello containing both IPv4 and IP= v6 transport address, why receiving LSR need to process such Hello message? Because of the robustness principle. 6.Section 6.1, 5th bullet: " An LSR MUST prefer using global unicast IPv6 address for an LDP session with a remote LSR, if it had to choose between global unicast IPv6 address and unique-local or link-local IPv6 address (pertaining to the same LDP Identifier) for the transport connection. " [Qin]: Can unique-local or link local IPv6 address be used in IPv6 transpor= t address optional object? Is bullet 5 contradict with bullet 4? No contradiction, bullet #4 is about "targeted hellos" only. 7. Section 6.2 said: " This document allows an LSR to maintain Rx-side Link Hello adjacency for only one address family that has been used for the establishment of the LDP session. " [Qin]: What does Rx-side mean? Is there sender side Link Hello? Rx-side means receive-side. This nomenclature is consistent with RFC 5036. However, reading that sentence, I believe there is a small mistake, that th= is sentence did not incorporate an additional change suggested by Mustapha = (missing "however"), and I will clarify that there can be one or two hello = adjacencies maintained. Thanks again for the review. Net-net, these are the upcoming changes: 1. s/must/MUST/ in last para of Section 5.1., from Qin in this email. 2. Section 6.2 last sentence, from Mustapha+Carlos. 3. Additional fixes identified by Loa: add a pre-5378 clause to the Copyrig= ht notice, and fix idnits. Thanks, -- Carlos. -----Original Message----- From: Loa Andersson Date: Wednesday, December 11, 2013 11:52 PM To: "mpls at ietf.org" >, "mpls-chairs at tools.ietf.org" >, Martin Vigoureux >, "draft-ietf-mpls-ldp-ipv6 at tools.ietf.org" > Subject: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6 >Working Group, > >This is to start a one week working group last call on >draft-ietf-mpls-ldp-ipv6-10 > >We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good >comments and the document almost ready to go. At that point a discussion >on the number of LDP session needed between a pair LSRs with both IPv4 >and IPv6 emerged, it has taken us quite a long time to resolve this. > >However, the author, wg chairs and people making the comments now agree >that version -10 is resolve those comments. > >This working group last call is limited to the changes since the >previous last call. A diff can be found at: > >http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-ldp-ipv6-07&difftype=3D= --ht >ml&submit=3DGo%21&url2=3Ddraft-ietf-mpls-ldp-ipv6-10 > >Please send you comments to the MPLS wg mailing list (mpls at ietf.org). > >This wglc ends Dec 20, 2013. > >/Loa ________________________________ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_B8F9A780D330094D99AF023C5877DABA43C6F3E4nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Carlos:

Thank for your clarificat= ion and proposed changes.

Your proposed changes loo= k good to me.

 <= /p>

Regards!

-Qin

From: Carlos P= ignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Sunday, December 29, 2013 4:31 AM
To: Qin Wu
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6

 

Hi, Qin,

 

Thanks for the review! Please find some follow-up co= mments inline.

 

On Dec 16, 2013, at 2:38 AM, Qin Wu <bill.wu@huawei.com> wrote:



Hi, all:

Here are my review to draft-ietf-mpls-l= dp-ipv6.

1. Section 5.1 said:<= /p>

“

Additionally, the link-local

IPv6 address MUST be used as the source IP address in IPv6= LDP Link

Hellos.

 

”

[Qin]: Why the link local multicast IPv6 address MUST be used as= the source address?

Usually multicast IPv6 address is used = as destination address for datagram, what am I missing?

 

 

The use of link-local IPv6 address as a source addre= ss for packets destined on-link is perfectly valid, and consistent with oth= er protocols-for-IPv6. See for example RFC 5340, "OSPF for IPv6",= Sections 2.5 and 4.1.3 (e.g., https://tools.ietf.org/html/rfc5340#section-2.5), or "VRRP for IPv4 and IPv6" Section 5.1.2.1 (i.e., http://tools.ietf.org/search/rfc5798#section-5.1.2.1).

 

Further, the document clearly says:

 

   Additionally, the link-local=

   IPv6 address MUST be used as the source= IP address in IPv6 LDP Link

   Hellos.

 

But also:

 

   The link-local IP addresses MUST NOT be= used as the source or

   destination IPv6 addresses in extended = discovery.

 



2. Section 5.1, last paragraph said:

“

Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the s= ame LDP

identifier (assuming per-platform label space usage).

 

”

s/must/MUST

 

OK



3. Section 5.2, 1st paragraph said:=

“

Suffice to say, the extended discovery mechanism (defined = in section

2.4.2 of [RFC5036]) doesn't require any additional IPv6 sp= ecific

consideration, since the targeted LDP Hellos are sent to a= pre-

configured (unicast) destination IPv6 address.

”

 

[Qin]; It is better to clarify the purp= ose of extended discovery mechanism? E.g., for

discovery of the LSR that is not direct= ly connected in the LDP session?

 

 

It is not for "discovery of the LSR that is not= directly connected in the LDP session". It is for "LDP discovery= between non-directly connected LSRs."

 

But in any case, there is a pointer to the exact sec= tion of RFC 5036 where this is specified at the source. I would not want to= try to re-define with a one-liner, since RFC 5036 is normative.=



4. Section 6.1, said:=

“

however, it does not specify the<= /o:p>

   behavior of LDP if both IPv4 and IPv6 transpo= rt address objects

   (TLV) are sent in a Hello message or separate= Hello messages.

 

”

[Qin]: It is better to distinct one Hello from two Hello, so sug= gest the following change
s/separate Hello/two separate Hello

 

 

"messages" in "or separate Hello mess= ages" is plural, I do not see the need for this change.



5. Section 6.1,2nd bullet:

“

O An LSR= SHOULD accept the Hello message that contains both IPv4

and IPv6 transport address optional objects, but MUST use = only

the transport address whose address family is the same as = that

of the IP packet carrying Hello.<= /o:p>

 

”

[Qin]: Since LSR is not allowed to send= a Hello containing both IPv4 and IPv6 transport address, why receiving LSR= need to process such Hello message?

 

 

Because of the robustness principle.



6.Section 6.1, 5th bullet:

“

An LSR MUST prefer using global unicast IPv6 address for a= n LDP

session with a remote LSR, if it had to choose between glo= bal

unicast IPv6 address and unique-local or link-local IPv6

address (pertaining to the same LDP Identifier) for the

transport connection.

”

[Qin]: Can unique-local or link local I= Pv6 address be used in IPv6 transport address optional object? Is bullet 5 = contradict with bullet 4?

 

 

No contradiction, bullet #4 is about "targeted = hellos" only.



7. Section 6.2 said:<= /p>

“

This document allows an LSR to maintain Rx-side Link Hello= adjacency

for only one address family that has been used for the est= ablishment

of the LDP session.<= /p>

”

[Qin]: What does Rx-side mean?

Is there sender side Link Hello?

 

Rx-side means receive-side. This nomenclature is con= sistent with RFC 5036.

 

However, reading that sentence, I believe there is a= small mistake, that this sentence did not incorporate an additional change= suggested by Mustapha (missing "however"), and I will clarify th= at there can be one or two hello adjacencies maintained.

 

Thanks again for the review.

 

Net-net, these are the upcoming changes:<= /p>

1. s/must/MUST/ in last para of Section 5.1., from Q= in in this email.

2. Section 6.2 last sentence, from Mustapha+Carl= os.

3. Additional fixes identified by Loa: add a pre-537= 8 clause to the Copyright notice, and fix idnits.

 

Thanks,

 

-- Carlos.



 

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

From: Loa Andersson <loa at pi.nu>= ;

Date: Wednesday, December 11, 2013 11:5= 2 PM

To: "mpls at ietf.org" <mpls at ietf.org>, "mpls-chairs at tools.ietf.org= "

<mpls-chairs at tools.ietf.org>, Martin Vigoureux

"draft-ietf-mpls-ldp-ipv6 at tools.ietf.org"

<draft-ietf-mpls-ldp-ipv6 at tools.ietf.org>

Subject: [mpls] Short wg last call on d= raft-ietf-mpls-ldp-ipv6

 

>Working Group,

> 

>This is to start a one week working= group last call on

>draft-ietf-mpls-ldp-ipv6-10

> 

>We did a wglc on draft draft-ietf-m= pls-ldp-ipv6 mid-2011. We had good

>comments and the document almost re= ady to go. At that point a discussion

>on the number of LDP session needed= between a pair LSRs with both IPv4

>and IPv6 emerged, it has taken us q= uite a long time to resolve this.

> 

>However, the author, wg chairs and = people making the comments now agree

>that version -10 is resolve those c= omments.

> 

>This working group last call is lim= ited to the changes since the

>previous last call. A diff can be f= ound at:

> 

>ml&submit=3DGo%21&url2=3Ddr= aft-ietf-mpls-ldp-ipv6-10

> 

>Please send you comments to the MPL= S wg mailing list (mpls at ietf.org= ).

> 

>This wglc ends Dec 20, 2013.

> 

>/Loa

______________________________________= _________
mpls mailing list
mpls@ietf.org=
https://www.ietf.org/mailman/listinfo/mpls

 

--_000_B8F9A780D330094D99AF023C5877DABA43C6F3E4nkgeml501mbschi_-- From bill.wu@huawei.com Sun Dec 29 19:48:38 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 B2E581AE3B2 for ; Sun, 29 Dec 2013 19:48:38 -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 LB0L503F0mwZ for ; Sun, 29 Dec 2013 19:48:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 132C11AE3AE for ; Sun, 29 Dec 2013 19:48: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 BBZ22176; Mon, 30 Dec 2013 03:48:26 +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; Mon, 30 Dec 2013 03:47:25 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Dec 2013 03:48:24 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 30 Dec 2013 11:48:21 +0800 From: Qin Wu To: "Ryoo, Jeong-dong" , Yaacov Weingarten Thread-Topic: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHO9ATofTfzY1WrTkK6rDh0YabjsJpMSsLJgAAiYoCAGZTyhIAGNmeQ Date: Mon, 30 Dec 2013 03:48:20 +0000 Message-ID: References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@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_B8F9A780D330094D99AF023C5877DABA43C6F40Ankgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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: Mon, 30 Dec 2013 03:48:38 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C6F40Ankgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgdG8gaW50ZXJydXB0IGluLg0KSSBhbSBhIGxpdHRsZSBiaXQgc3VycHJpc2VkIHRoaXMg ZHJhZnQgaGFzIG5vdCBhbnkgcmVmZXJlbmNlIHRvIElUVSBkb2N1bWVudC4NCkkgYW0gd29uZGVy aW5nIGhvdyBtdWNoIHRoaXMgZHJhZnQgaXMgY29tcGxpYW50IHdpdGggRy44MDMxPyBJcyB0aGVy ZSBhbnkgdHdlYWsgb3Igb3B0aW1pemF0aW9uIHRvIEcuODMxPw0KV2hhdCBpcyB0aGUgY29uY2Vy biBvZiBHLjgzMSB0aGlzIGRyYWZ0IGlzIGRlYWxpbmcgd2l0aD8NCklmIGFueXRoaW5nIGlzIGZy b20gRy44MzEgb3IgYW55IG90aGVyIElUVSBkb2N1bWVudCwgSSB0aGluayBpdCBpcyBmaW5lLCBo b3dldmVyIEcuODMxIG9yIHNvbWUgb3RoZXIgSVRVIGRvY3VtZW50cyBhcmUgd29ydGggYmVpbmcg cmVmZXJlbmNlZC4NCg0KSWYgdGhpcyBkcmFmdCBpcyBmb2N1c2luZyBvbiBhZGRyZXNzaW5nIEcu ODMxLCBpdCBpcyBiZXR0ZXIgdG8gY2xhcmlmeSB0aGlzIGEgbGl0dGxlIGJpdCBpbiB0aGlzIGRy YWZ0Lg0KDQpNeSBmZWVsaW5nIGlzIHRoaXMgZHJhZnQgc2VlbXMgdG8gaW50cm9kdWNlIGNvbWJp bmF0aW9uIG9mIDErMSBhbmQgMToxIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJlIHdoZW4gSSByZWFk DQrigJwNCkFzIHlvdSBtaWdodCByZWNhbGwgZnJvbSBHLjgwMzEg4oCTIEV0aGVybmV0IGxpbmVh ciBwcm90ZWN0aW9uLCB0aGUgc2VsZWN0b3IgYnJpZGdlIGlzIG5vdCByZWNvbW1lbmRlZCBkdWUg dG8gdGhlIHRyYWZmaWMgZmxhcHBpbmcgdW5kZXIgU0QgY29uZGl0aW9ucyBvbiBib3RoIHBhdGhz LiBJbnN0ZWFkIOKAnGJyb2FkY2FzdCBicmlkZ2XigJ0gaXMgaW50cm9kdWNlZCB0byBzdXBwb3J0 IHByb3RlY3Rpb24gc3dpdGNoaW5nIGFnYWluc3QgU0QuIEJ1dCwgdGhpcyBicm9hZGNhc3QgYnJp ZGdlIGlzIG5vdCByZWNvbW1lbmRlZCBpbiBub24tcmV2ZXJ0aXZlIG1vZGUgYXMgdGhlIHdvcmtp bmcgcGF0aCBuZWVkcyB0byBiZSBvY2N1cGllZCBieSB0cmFmZmljIGFsbCB0aGUgdGltZS4gQWxz byB0aGUgYnJvYWRjYXN0IGJyaWRnZSBpcyBub3QgZWZmaWNpZW50LCBzaW5jZSBieSBkZWZpbml0 aW9uLCB0aGUgcGFja2V0IGR1cGxpY2F0aW9uIHNob3VsZCBvY2N1ciBkdXJpbmcgbm90IG9ubHkg U0QgYnV0IGFsc28gU0YsIEZTLCBNUywgZXRjLiBJbiB0aGlzIGRvY3VtZW50LCB3ZSBhcmUgaW50 cm9kdWNpbmcgYW4gaW1wcm92ZWQgYnJpZGdlIG1lY2hhbmlzbSwgd2hpY2ggYmVoYXZlcyBsaWtl IGEgc2VsZWN0b3IgYnJpZGdlIGJ1dCBkdXBsaWNhdGVzIHRoZSB0cmFmZmljIG9ubHkgdW5kZXIg U0QgY29uZGl0aW9uLCBhbmQgd2UgYmVsaWV2ZSB0aGF0IGl0IGFkZHJlc3NlcyBhbGwgdGhlIGlz c3VlcyB3aXRoIGV4aXN0aW5nIGJyaWRnZXMuDQoNCuKAnSwNCkkgdGVuZCB0byBhZ3JlZSBZYWNj b3YgdGhhdCBTRCBwcm90ZWN0aW9uIGlzIG5vdCBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQg Zm9yIHRoZSBkZXRlY3Rpb24uDQpBbHNvIEkgYW0gaW50ZXJlc3RlZCB0byBrbm93IGhvdyB0byBw b3NpdGlvbiBicmlkZ2UgYW5kIHNlbGVjdG9yIGluIHRoZSBNUExTIGFyY2hpdGVjdHVyZT8NCg0K UmVnYXJkcyENCi1RaW4NCg0KRnJvbTogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFJ5b28sIEplb25nLWRvbmcNClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJl ciAyNiwgMjAxMyAxMjo1MSBQTQ0KVG86IFlhYWNvdiBXZWluZ2FydGVuDQpDYzogbXBsc0BpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbbXBsc10gUXVlc3Rpb24gcmVnYXJkaW5nIFNEIHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0 Zi1tcGxzLXRwLXBzYy1pdHUNCg0KWWFhY292LCB0aGFua3MgZm9yIHlvdXIgZW1haWwuIFNvbWVo b3csIEkgZm9yZ290IHRvIHJlc3BvbmQgYW5kIGFtIHNvcnJ5IGZvciB0aGUgZGVsYXkuDQoNCkZp cnN0IG9mIGFsbCwgWWFhY292LCBpdCBpcyBub3QgdHJ1ZSB0aGF0IHRoZSBwcm90ZWN0aW9uIHN3 aXRjaGluZyBvZiBFdGhlcm5ldCBvciBTREggZGVzY3JpYmVzIHRoZSBvcGVyYXRpb24gb2YgYW55 IGxheWVyIGJlbG93LiBSYXRoZXIsIGVhY2ggbGF5ZXIgaXMgc3VwcG9zZWQgdG8gb3BlcmF0ZSBp bmRlcGVuZGVudGx5LiBIb3dldmVyLCB0aGVyZSBhcmUgYSBmZXcgZXhjZXB0aW9ucywgc3VjaCBh cyBob2xkLW9mZiB0aW1lciBhbmQgQUlTIChhcyBhIHRyaWdnZXIgZnJvbSBsb3dlciBsYXllciku IEV2ZW4gdGhvdWdoIHRoZXJlIGV4aXN0IHNvbWUgcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRpb25z IHRoYXQgdXNlIG90aGVyIGluZm9ybWF0aW9uIGZyb20gbG93ZXIgbGF5ZXIsIG1vc3Qgb2YgdGhl bSBhcmUgbm90IHJlY29tbWVuZGVkIGluIElUVS1UIHN0YW5kYXJkcy4NCg0KQnJpZGdlIGFuZCBz ZWxlY3RvciBhcmUgbm90IGluIHRoZSBwaHlzaWNhbCBsYXllciwgYnV0IHRoZXkgYXJlIHBhcnQg b2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIE9uZSBvZiB0aGUgaW1wb3J0YW50IG91dHB1dCBhY3Rp b25zIGZyb20gdGhlIFBTQyBjb250cm9sIGxvZ2ljIGlzIGNvb3JkaW5hdGluZyB0aGUgcG9zaXRp b25zIG9mIGJyaWRnZSBhbmQgc2VsZWN0b3IuIEFsc28sIHRoZSBicmlkZ2Ugb3BlcmF0aW9uIHJl c3BvbmRpbmcgdG8gdGhlIFBTQyBjb250cm9sIGxvZ2ljIGlzIGFsc28gcGFydCBvZiBwcm90ZWN0 aW9uIHN3aXRjaGluZy4gSG93ZXZlciwgaG93IHRvIHJlYWxpemUgdGhlIGJyaWRnZSBhbmQgc2Vs ZWN0b3IgKGZvciBleGFtcGxlLCBob3cgdG8gbWFuaXB1bGF0ZSBhIHBhY2tldCBmb3J3YXJkaW5n IG1lY2hhbmlzbSkgaXMgYW4gaW1wbGVtZW50YXRpb24gbWF0dGVyLg0KDQpXaGVuIHdlIG1lbnRp b24gMSsxIG9yIDE6MSBpbiBwcm90ZWN0aW9uIGFyY2hpdGVjdHVyZSwgd2UgZGVhbCB3aXRoIHRo ZSBvcGVyYXRpb24gb2YgYnJpZGdlLiBGb3IgMSsxIGFyY2hpdGVjdHVyZSwgdGhlIHRyYWZmaWMg bmVlZHMgdG8gYmUgZHVwbGljYXRlZCBhdCB0aGUgc2VuZGVyIGFuZCBzZW50IHRvIGJvdGggcGF0 aHMgYWxsIHRoZSB0aW1lLCB3aGljaCBpcyB0aGUgc2FtZSBkZXNjcmlwdGlvbiBhcyB0aGUg4oCc cGVybWFuZW50IGJyaWRnZeKAnS4gRm9yIDE6MSBhcmNoaXRlY3R1cmUsIOKAnHNlbGVjdG9yIGJy aWRnZeKAnSBpcyB1c2VkIHRvIHNlbmQgdGhlIHRyYWZmaWMgb25seSBvbmUgb2YgdGhlIHBhdGhz LiBBcyB0aGUgcHJvdGVjdGlvbiBwYXRoIGNhbiBiZSB1c2VkIGJ5IGJlc3QgdHJhZmZpYyBpbiBw YWNrZXQgbmV0d29ya3MgYW5kIHRoZSBwYWNrZXQgZHVwbGljYXRpb24gdGFrZXMgbXVjaCBtb3Jl IGVmZm9ydC9pbnRlcm5hbCBiYW5kd2lkdGggaW5zaWRlIGEgc3dpdGNoIHRoYW4gdGhlIHRpbWUg c2xvdCBjb3B5IG9mIGNpcmN1aXQgbmV0d29ya3MuIDE6MSBpcyBjb25zaWRlcmVkIGFzIHByZWZl cmFibGUgYXJjaGl0ZWN0dXJlIGluIHBhY2tldCBuZXR3b3Jrcy4NCg0KQXMgeW91IG1pZ2h0IHJl Y2FsbCBmcm9tIEcuODAzMSDigJMgRXRoZXJuZXQgbGluZWFyIHByb3RlY3Rpb24sIHRoZSBzZWxl Y3RvciBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVkIGR1ZSB0byB0aGUgdHJhZmZpYyBmbGFwcGlu ZyB1bmRlciBTRCBjb25kaXRpb25zIG9uIGJvdGggcGF0aHMuIEluc3RlYWQg4oCcYnJvYWRjYXN0 IGJyaWRnZeKAnSBpcyBpbnRyb2R1Y2VkIHRvIHN1cHBvcnQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcg YWdhaW5zdCBTRC4gQnV0LCB0aGlzIGJyb2FkY2FzdCBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVk IGluIG5vbi1yZXZlcnRpdmUgbW9kZSBhcyB0aGUgd29ya2luZyBwYXRoIG5lZWRzIHRvIGJlIG9j Y3VwaWVkIGJ5IHRyYWZmaWMgYWxsIHRoZSB0aW1lLiBBbHNvIHRoZSBicm9hZGNhc3QgYnJpZGdl IGlzIG5vdCBlZmZpY2llbnQsIHNpbmNlIGJ5IGRlZmluaXRpb24sIHRoZSBwYWNrZXQgZHVwbGlj YXRpb24gc2hvdWxkIG9jY3VyIGR1cmluZyBub3Qgb25seSBTRCBidXQgYWxzbyBTRiwgRlMsIE1T LCBldGMuIEluIHRoaXMgZG9jdW1lbnQsIHdlIGFyZSBpbnRyb2R1Y2luZyBhbiBpbXByb3ZlZCBi cmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhhdmVzIGxpa2UgYSBzZWxlY3RvciBicmlkZ2UgYnV0 IGR1cGxpY2F0ZXMgdGhlIHRyYWZmaWMgb25seSB1bmRlciBTRCBjb25kaXRpb24sIGFuZCB3ZSBi ZWxpZXZlIHRoYXQgaXQgYWRkcmVzc2VzIGFsbCB0aGUgaXNzdWVzIHdpdGggZXhpc3RpbmcgYnJp ZGdlcy4NCg0KV2hhdCB3ZSBtZWFuIGJ5IFNEIHByb3RlY3Rpb24gaXMgYWdub3N0aWMgdG8gdGhl IFNEIGRldGVjdGlvbiBtZXRob2QgaXMgdGhhdCB0aGUgcHJvcG9zZWQgU0QgcHJvdGVjdGlvbiBt ZXRob2QgKGFnYWluIGhvdyB0byBvcGVyYXRlIGEgYnJpZGdlIG9yIHdoYXQgYnJpZ2UgaXMgdXNl ZCBpcyBhIHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcpIGNhbiBiZSB1c2VkIG5vIG1hdHRl ciB3aGF0IGtpbmQgb2YgU0QgZGV0ZWN0aW9uIG1ldGhvZHMgKGRhdGEgcGFja2V0IGNvdW50aW5n LCBDQ00gcGFja2V0IGNvdW50aW5nLCBvciBldmVuIHByb3ByaWV0YXJ5IHNlcnZlciBsYXllciBT RCBkZXRlY3Rpb24pIGlzIHVzZWQuDQoNCkkgdGhpbmsgSSBhbnN3ZXJlZCBhbGwgdGhlIHF1ZXN0 aW9ucyBvbiB5b3VyIGVtYWlsLg0KDQpZYWFjb3YsIGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNv bmNlcm5zIG9yIHF1ZXN0aW9ucywgcGxlYXNlIGxldCBtZSBrbm93Lg0KDQpCZXN0IHJlZ2FyZHMs DQoNCkplb25nLWRvbmcNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv bSA6ICJZYWFjb3YgV2VpbmdhcnRlbiIgPHd5YWFjb3ZAZ21haWwuY29tPg0KU2VudCA6IDIwMTMt MTItMTAgMTY6MDQ6MTcgKCArMDk6MDAgKQ0KVG8gOiBSeW9vLCBKZW9uZy1kb25nIDxyeW9vQGV0 cmkucmUua3I+DQpDYyA6IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3Jn IDxkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz4sIG1wbHNAaWV0Zi5v cmcgPG1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0IDogUmU6IFF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBw cm90ZWN0aW9uIGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQpKZW9uZy1kb25nLCBoaQ0K DQpUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkuIFlvdXIgYW5zd2VyIHNlZW1zIHRvIGJlIGFuIGFw cHJvcHJpYXRlIGFuc3dlciBmb3Igb3RoZXIgU0RPcywgbm90IHN1cmUgdGhhdCBpdCBpcyB0cnVl IGZvciB0aGUgY29udGV4dCBvZiBNUExTIGFuZCBJRVRGIHdvcmsuDQoNCjEuIFlvdSB3cm90ZSAi YW55IHByb3RlY3Rpb24gc3dpdGNoaW5nIChpbmNsdWRpbmcgUFNDKSBpcyBzdXBwb3NlZCB0byBk ZXNjcmliZSB0aGUgb3BlcmF0aW9uIG9mIGJyaWRnZSBhbmQgc2VsZWN0b3IuIiAtIHRoaXMgbWF5 IGJlIHRydWUgZm9yIEV0aGVybmV0IGFuZCBTREggYW5kIGZvciBkb2N1bWVudHMgdGhhdCBhcmUg ZGVzY3JpYmluZyB0aGUgb3BlcmF0aW9uIG9mIHRoZSBwaHlzaWNhbCBsYXllci4gSG93ZXZlciwg dGhlIElFVEYgKHRvIG15IHVuZGVyc3RhbmRpbmcgLSBhbmQgSSBhbSBjZXJ0YWlubHkgd2lsbGlu ZyB0byBiZSBjb3JyZWN0ZWQgb24gdGhpcyBwb2ludCkgaXMgY29uY2VybmVkIHdpdGggdGhlIHBy b3RvY29sIGFuZCBsZWF2ZSB0aGUgbG93ZXIgbGF5ZXJzIHRvIGltcGxlbWVudGF0aW9uLiBBbHNv LCBJIGFtIG5vdCBzdXJlIHRoYXQgdGhlIGNvbmNlcHRzIG9mIEJyaWRnZSBhbmQgU2VsZWN0b3Ig cmVhbGx5IGFwcGx5IHRvIE1QTFMgKGFsdGhvdWdoIEkgYWRtaXQgdGhhdCB3ZSBkaWQgbWVudGlv biB0aGVtIGluIHRoZSBvcmlnaW5hbCBQU0MgZGVmaW5pdGlvbikuDQoNCjIuIFlvdSBjaXRlIHdo YXQgd2FzIHdyaXR0ZW4gaW4gRzgwMzEgYXMganVzdGlmaWNhdGlvbiBmb3IgaW5jbHVkaW5nIGNv bnRlbnQgaW50byB5b3VyIGRyYWZ0LiBBZ2FpbiBpdCBpcyBoYXJkIHRvIHRyYW5zZmVyIG1ldGhv ZG9sb2d5IGZyb20gb25lIFNETyB0byBhbm90aGVyIGFuZCB0aGVyZWZvcmUsIHdoaWxlIEkgaGln aGx5IHJlc3BlY3QgdGhlIHdvcmsgb2YgdGhlIElUVSwgSSBkbyBub3QgZmVlbCB0aGF0IHRoaXMg aXMgYSB2ZXJ5IGNsZWFyIGp1c3RpZmljYXRpb24gZm9yIGluY2x1c2lvbiBpbnRvIGFuIGludGVy bmV0LWRyYWZ0LiBFdmVuIHdoZW4gdGhlIGRyYWZ0IHN0YXRlcyB0aGF0IGl0cyBwdXJwb3NlIGlz IHRvIGFkZHJlc3MgdGhlIGNvbmNlcm5zIG9mIHRoZSBJVFUuDQoNCjMuIFRvIHRoZSBhY3R1YWwg cG9pbnQgb2YgbXkgZWFybGllciBjb21tZW50LCB0aGF0IHlvdSBkbyBub3Qgc2VlbSB0byBhZGRy ZXNzIC0gdGhlIHBhcmFncmFwaCBpbiBTZWN0aW9uIDcuMyBzZWVtcyB0byBzdGF0ZSB0aGF0IFNE IHByb3RlY3Rpb24gY2hhbmdlcyBhY2NvcmRpbmcgdG8gdGhlIG1ldGhvZCB0aGF0IGlzIHVzZWQg dG8gZGV0ZWN0IHRoZSBTRC4gVGhpcyBtZWFucyB0aGF0IFNEIHByb3RlY3Rpb24gaXMgbm90IGFn bm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhlIGRldGVjdGlvbi4NCkFsdGVybmF0aXZl bHksIHdlIGNvdWxkIGJyZWFrIHRoaXMgZGVwZW5kZW5jZSBhbmQgc3RhdGUgdGhhdCBTRCBwcm90 ZWN0aW9uIGlzIGFsd2F5cyBwcm92aWRlZCBieSBjaGFuZ2luZyB0aGUgdHJhbnNtaXNzaW9uIG9m IHRoZSBkYXRhIHRvIDErMSBwcm90ZWN0aW9uIGluIGNhc2VzIG9mIFNEIGRldGVjdGlvbiwgd2hp Y2ggaXMgd2hhdCB0aGUgcGFyYWdyYXBoIGlzIHN1Z2dlc3RpbmcgdG8gZG8gZm9yIHNvbWUgY2Fz ZXMuDQoNCkkgaG9wZSB0aGlzIGZvcm11bGF0aW9uIG1ha2UgbXkgY29tbWVudCBjbGVhcmVyIGFu ZCB3ZSBhcmUgYWJsZSB0byBkaXNjdXNzIHRoZSB0ZWNobm9sb2dpY2FsIGFwcHJvYWNoIHJhdGhl ciB0aGFuIHRoZSBwaGlsb3NvcGhpY2FsIGRpZmZlcmVuY2VzLg0KDQpUaGFuayB5b3UsDQp5YWFj b3YNCg0KT24gTW9uLCBEZWMgOSwgMjAxMyBhdCAxMDowNCBQTSwgUnlvbywgSmVvbmctZG9uZyA8 cnlvb0BldHJpLnJlLmtyPG1haWx0bzpyeW9vQGV0cmkucmUua3I+PiB3cm90ZToNCllhYWNvdiwN Cg0KWWVzLCBQU0MgaXMgc3VwcG9zZWQgdG8gYmUgYWdub3N0aWMgdG8gdGhlIG1ldGhvZCB1c2Vk IGZvciB0aGUgZGV0ZWN0aW9uIG9mIFNGL1NELg0KDQpJdCBpcyBhbHNvIHRydWUgdGhhdCBhbnkg cHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGluY2x1ZGluZyBQU0MpIGlzIHN1cHBvc2VkIHRvIGRlc2Ny aWJlIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGFuZCBzZWxlY3Rvci4NCg0KQXMgdGhlcmUgYXJl IG11bHRpcGxlIG9wdGlvbnMgZm9yIGRldGVjdGluZyBTRCwgd2UgbmVlZGVkIHRvIGRlc2NyaWJl IHRoZSBiZWhhdmlvciBvZiB0aGUgYnJpZGdlIHRvIGNvdmVyIGFsbCB0aGUgcG9zc2libGUgZGV0 ZWN0aW9uIG1ldGhvZHMuIERlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgZm9yIFNE IHByb3RlY3Rpb24gaXMgbm90IGEgbmV3IHRoaW5nLiBGb3IgZXhhbXBsZSwgRy44MDMxIC0gRXRo ZXJuZXQgbGluZWFyIHByb3RlY3Rpb24gYWxzbyBkZXNjcmliZXMgd2hhdCBicmlkZ2UgY2FuIGJl IHVzZWQgaW4gb3JkZXIgdG8gcHJvdmlkZSBwcm90ZWN0aW9uIGFnYWluc3QgU0QuDQoNCkJlc3Qg cmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tIDogIllhYWNvdiBXZWluZ2FydGVuIiA8d3lhYWNvdkBnbWFpbC5jb208bWFpbHRv Ond5YWFjb3ZAZ21haWwuY29tPj4NClNlbnQgOiAyMDEzLTEyLTA4IDIwOjAxOjU1ICggKzA5OjAw ICkNClRvIDogZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPiA8ZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy10cC1w c2MtaXR1QHRvb2xzLmlldGYub3JnPj4sIG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+IDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4NCkNjIDoNClN1YmplY3Qg OiBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAt cHNjLWl0dQ0KDQpIaSwNCg0KQWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHlvdXIgZHJhZnQgb24gdGhl IGV4dGVuc2lvbnMgdG8gUFNDIHRvIHN1cHBvcnQgU0Qgc2l0dWF0aW9ucywgSSBoYXZlIGEgcXVl c3Rpb24gZm9yIGNsYXJpZmljYXRpb24gLQ0KSW4geW91ciBpbnRyb2R1Y3Rpb24gLSB5b3Ugc3Rh dGUgdGhhdCB0aGUgbWV0aG9kIHVzZWQgdG8gZGV0ZWN0IFNEIHNpdHVhdGlvbnMgaXMgb3V0LW9m LXNjb3BlIG9mIHRoZSBkb2N1bWVudC4gRG9lcyB0aGlzIG1lYW4gdGhhdCBQU0MgaXMgc3VwcG9z ZWQgdG8gYmUgYWdub3N0aWMgdG8gdGhlIG1ldGhvZCB1c2VkIGZvciB0aGlzIGRldGVjdGlvbj8g SXQgc2hvdWxkIHJlYWN0IG9ubHkgdG8gdGhlIGluZGljYXRpb24sIHNpbWlsYXJseSB0byB0aGUg cmVhY3Rpb24gYW5kIHJlbGF0aW9uc2hpcCB0byB0aGUgbWV0aG9kIGZvciBkZXRlY3RpbmcgYW5k IGRlY2xhcmluZyBhIFNGIHNpdHVhdGlvbi4NCkhvd2V2ZXIsIHdoZW4geW91IGV4cGxhaW4gdGhl IGJlaGF2aW9yIG9mIHRoZSBTRCBwcm90ZWN0aW9uIGluIHNlY3Rpb24gNy4zIHlvdSBoYXZlIGEg cGFyYWdyYXBoIHRoYXQgc3RhcnRzIHdpdGggIklmIHRoZSBkZXRlY3Rpb24gb2YgYSBTRCBkZXBl bmRzIG9uIHRoZSBwcmVzZW5jZSBvZiB1c2VyIGRhdGEgcGFja2V0cyAuLi4iICB0aGF0IHNlZW1z IHRvIGluZGljYXRlIHRoYXQgdGhlIGJlaGF2aW9yIG9mIHRoZSBzeXN0ZW0gaXMgZGVwZW5kZW50 IHVwb24gdGhlIGRldGVjdGlvbiBtZXRob2QhIENsYXJpZmljYXRpb24gd291bGQgYmUgYXBwcmVj aWF0ZWQuDQoNCi0tDQpUaGFueCBhbmQgQlIsDQp5YWFjb3YNCg0KU3RpbGwgbG9va2luZyBmb3Ig bmV3IG9wcG9ydHVuaXR5DQoNCg0KDQotLQ0KVGhhbnggYW5kIEJSLA0KeWFhY292DQoNClN0aWxs IGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eQ0K --_000_B8F9A780D330094D99AF023C5877DABA43C6F40Ankgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTWFsZ3VuIEdvdGhpYyI7DQoJcGFub3NlLTE6 MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuunkeydgOqz oOuUlTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IlxATWFsZ3VuIEdvdGhpYyI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOunkeydgOqzoOuUlSI7DQoJcGFub3Nl LTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Tb3JyeSB0byBpbnRlcnJ1cHQgaW4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYW0gYSBsaXR0bGUgYml0IHN1cnByaXNlZCB0aGlzIGRyYWZ0IGhhcyBu b3QgYW55IHJlZmVyZW5jZSB0byBJVFUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgYW0gd29uZGVyaW5nIGhvdyBtdWNoIHRoaXMgZHJhZnQgaXMgY29tcGxpYW50IHdp dGggRy44MDMxPyBJcyB0aGVyZSBhbnkgdHdlYWsgb3Igb3B0aW1pemF0aW9uIHRvIEcuODMxPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IGlzIHRoZSBjb25jZXJuIG9mIEcuODMx IHRoaXMgZHJhZnQgaXMgZGVhbGluZyB3aXRoPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JZiBhbnl0aGluZyBpcyBmcm9tIEcuODMxIG9yIGFueSBvdGhlciBJVFUgZG9jdW1lbnQsIEkg dGhpbmsgaXQgaXMgZmluZSwgaG93ZXZlciBHLjgzMSBvciBzb21lIG90aGVyIElUVSBkb2N1bWVu dHMgYXJlIHdvcnRoIGJlaW5nIHJlZmVyZW5jZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB0aGlzIGRyYWZ0IGlz IGZvY3VzaW5nIG9uIGFkZHJlc3NpbmcgRy44MzEsIGl0IGlzIGJldHRlciB0byBjbGFyaWZ5IHRo aXMgYSBsaXR0bGUgYml0IGluIHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBmZWVsaW5nIGlzIHRo aXMgZHJhZnQgc2VlbXMgdG8gaW50cm9kdWNlIGNvbWJpbmF0aW9uIG9mIDEmIzQzOzEgYW5kIDE6 MSBwcm90ZWN0aW9uIGFyY2hpdGVjdHVyZSB3aGVuIEkgcmVhZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj7igJw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+QXMgeW91IG1pZ2h0IHJlY2FsbCBmcm9tIEcuODAzMQ0KPC9zcGFuPuKAkzxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4gRXRoZXJuZXQgbGluZWFyIHByb3RlY3Rpb24sIHRoZSBzZWxlY3RvciBicmlkZ2UgaXMg bm90IHJlY29tbWVuZGVkIGR1ZSB0byB0aGUgdHJhZmZpYyBmbGFwcGluZyB1bmRlciBTRCBjb25k aXRpb25zIG9uIGJvdGggcGF0aHMuIEluc3RlYWQNCjwvc3Bhbj7igJw8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+YnJv YWRjYXN0IGJyaWRnZTwvc3Bhbj7igJ08c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFs Z3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+IGlzIGludHJvZHVjZWQgdG8gc3Vw cG9ydCBwcm90ZWN0aW9uIHN3aXRjaGluZyBhZ2FpbnN0IFNELiBCdXQsIHRoaXMgYnJvYWRjYXN0 IGJyaWRnZSBpcyBub3QgcmVjb21tZW5kZWQgaW4gbm9uLXJldmVydGl2ZSBtb2RlDQogYXMgdGhl IHdvcmtpbmcgcGF0aCBuZWVkcyB0byBiZSBvY2N1cGllZCBieSB0cmFmZmljIGFsbCB0aGUgdGlt ZS4gQWxzbyB0aGUgYnJvYWRjYXN0IGJyaWRnZSBpcyBub3QgZWZmaWNpZW50LCBzaW5jZSBieSBk ZWZpbml0aW9uLCB0aGUgcGFja2V0IGR1cGxpY2F0aW9uIHNob3VsZCBvY2N1ciBkdXJpbmcgbm90 IG9ubHkgU0QgYnV0IGFsc28gU0YsIEZTLCBNUywgZXRjLiBJbiB0aGlzIGRvY3VtZW50LCB3ZSBh cmUgaW50cm9kdWNpbmcgYW4gaW1wcm92ZWQNCiBicmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhh dmVzIGxpa2UgYSBzZWxlY3RvciBicmlkZ2UgYnV0IGR1cGxpY2F0ZXMgdGhlIHRyYWZmaWMgb25s eTwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhp YyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+dW5kZXIgU0QgY29uZGl0aW9uLCBhbmQgd2UgYmVs aWV2ZSB0aGF0IGl0IGFkZHJlc3NlcyBhbGwgdGhlIGlzc3VlcyB3aXRoIGV4aXN0aW5nIGJyaWRn ZXMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPuKAnSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRl bmQgdG8gYWdyZWUgWWFjY292IHRoYXQgU0QgcHJvdGVjdGlvbiBpcyBub3QgYWdub3N0aWMgdG8g dGhlIG1ldGhvZCB1c2VkIGZvciB0aGUgZGV0ZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5BbHNvIEkgYW0gaW50ZXJlc3RlZCB0byBrbm93IGhvdyB0byBwb3NpdGlvbiBicmlk Z2UgYW5kIHNlbGVjdG9yIGluIHRoZSBNUExTIGFyY2hpdGVjdHVyZT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1RaW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5SeW9vLCBKZW9uZy1kb25nPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBEZWNlbWJlciAy NiwgMjAxMyAxMjo1MSBQTTxicj4NCjxiPlRvOjwvYj4gWWFhY292IFdlaW5nYXJ0ZW48YnI+DQo8 Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xz LmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gUXVlc3Rpb24gcmVnYXJk aW5nIFNEIHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJlekZvcm1Qcm9jX2RpdiI+DQo8ZGl2IGlkPSJtc2di b2R5Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPllhYWNvdiwgdGhh bmtzIGZvciB5b3VyIGVtYWlsLjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U29tZWhvdywgSSBm b3Jnb3QgdG8gcmVzcG9uZCBhbmQgYW0gc29ycnkgZm9yIHRoZQ0KIGRlbGF5Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEw LjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPkZpcnN0IG9mIGFsbCwgWWFhY292LCBpdCBpcyBub3QgdHJ1ZSB0aGF0 IHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBvZiBFdGhlcm5ldCBvciBTREggZGVzY3JpYmVzIHRo ZSBvcGVyYXRpb24gb2YgYW55IGxheWVyIGJlbG93LiBSYXRoZXIsDQogZWFjaCBsYXllciBpcyBz dXBwb3NlZCB0byBvcGVyYXRlIGluZGVwZW5kZW50bHkuIEhvd2V2ZXIsIHRoZXJlIGFyZSBhIGZl dyBleGNlcHRpb25zLCBzdWNoIGFzIGhvbGQtb2ZmIHRpbWVyIGFuZCBBSVMgKGFzIGEgdHJpZ2dl ciBmcm9tIGxvd2VyIGxheWVyKS4gRXZlbiB0aG91Z2ggdGhlcmUgZXhpc3Qgc29tZSBwcm9wcmll dGFyeSBpbXBsZW1lbnRhdGlvbnMgdGhhdCB1c2Ugb3RoZXIgaW5mb3JtYXRpb24gZnJvbSBsb3dl ciBsYXllciwgbW9zdA0KIG9mIHRoZW0gYXJlIG5vdCByZWNvbW1lbmRlZCBpbiBJVFUtVCBzdGFu ZGFyZHMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0 O2xpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1 biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJyaWRnZSBhbmQgc2VsZWN0b3IgYXJl IG5vdCBpbiB0aGUgcGh5c2ljYWwgbGF5ZXIsIGJ1dCB0aGV5IGFyZSBwYXJ0IG9mIHByb3RlY3Rp b24gc3dpdGNoaW5nLiBPbmUgb2YgdGhlIGltcG9ydGFudCBvdXRwdXQgYWN0aW9ucyBmcm9tIHRo ZQ0KIFBTQyBjb250cm9sIGxvZ2ljIGlzIGNvb3JkaW5hdGluZyB0aGUgcG9zaXRpb25zIG9mIGJy aWRnZSBhbmQgc2VsZWN0b3IuIEFsc28sIHRoZSBicmlkZ2Ugb3BlcmF0aW9uIHJlc3BvbmRpbmcg dG8gdGhlIFBTQyBjb250cm9sIGxvZ2ljIGlzIGFsc28gcGFydCBvZiBwcm90ZWN0aW9uIHN3aXRj aGluZy4gSG93ZXZlciwgaG93IHRvIHJlYWxpemUgdGhlIGJyaWRnZSBhbmQgc2VsZWN0b3IgKGZv ciBleGFtcGxlLCBob3cgdG8gbWFuaXB1bGF0ZSBhIHBhY2tldA0KIGZvcndhcmRpbmcgbWVjaGFu aXNtKSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhl aWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPldoZW4gd2UgbWVudGlvbiAxJiM0MzsxIG9yIDE6MSBpbiBwcm90ZWN0aW9uIGFyY2hpdGVj dHVyZSwgd2UgZGVhbCB3aXRoIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlLiBGb3IgMSYjNDM7MSBh cmNoaXRlY3R1cmUsIHRoZSB0cmFmZmljIG5lZWRzIHRvIGJlDQogZHVwbGljYXRlZCBhdCB0aGUg c2VuZGVyIGFuZCBzZW50IHRvIGJvdGggcGF0aHMgYWxsIHRoZSB0aW1lLCB3aGljaCBpcyB0aGUg c2FtZSBkZXNjcmlwdGlvbiBhcyB0aGUNCjwvc3Bhbj7igJw8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+cGVybWFuZW50 IGJyaWRnZTwvc3Bhbj7igJ08c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdv dGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+LiBGb3IgMToxIGFyY2hpdGVjdHVyZSwNCjwv c3Bhbj7igJw8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+c2VsZWN0b3IgYnJpZGdlPC9zcGFuPuKAnTxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij4gaXMgdXNlZCB0byBzZW5kIHRoZSB0cmFmZmljIG9ubHkgb25lIG9mIHRoZSBwYXRocy4gQXMg dGhlIHByb3RlY3Rpb24gcGF0aCBjYW4gYmUgdXNlZCBieTwvc3Bhbj4mbmJzcDs8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+YmVzdA0KIHRyYWZmaWMgaW4gcGFja2V0IG5ldHdvcmtzIGFuZCB0aGUgcGFja2V0IGR1cGxp Y2F0aW9uIHRha2VzIG11Y2ggbW9yZSBlZmZvcnQvaW50ZXJuYWwgYmFuZHdpZHRoIGluc2lkZSBh IHN3aXRjaCB0aGFuIHRoZSB0aW1lIHNsb3QgY29weSBvZiBjaXJjdWl0IG5ldHdvcmtzLiAxOjEg aXMgY29uc2lkZXJlZCBhcyBwcmVmZXJhYmxlIGFyY2hpdGVjdHVyZSBpbiBwYWNrZXQgbmV0d29y a3MuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDts aW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4g R290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BcyB5b3UgbWlnaHQgcmVjYWxsIGZyb20g Ry44MDMxDQo8L3NwYW4+4oCTPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBH b3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiBFdGhlcm5ldCBsaW5lYXIgcHJvdGVjdGlv biwgdGhlIHNlbGVjdG9yIGJyaWRnZSBpcyBub3QgcmVjb21tZW5kZWQgZHVlIHRvIHRoZSB0cmFm ZmljIGZsYXBwaW5nIHVuZGVyIFNEIGNvbmRpdGlvbnMgb24gYm90aCBwYXRocy4gSW5zdGVhZA0K PC9zcGFuPuKAnDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5icm9hZGNhc3QgYnJpZGdlPC9zcGFuPuKAnTxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4gaXMgaW50cm9kdWNlZCB0byBzdXBwb3J0IHByb3RlY3Rpb24gc3dpdGNoaW5nIGFnYWlu c3QgU0QuIEJ1dCwgdGhpcyBicm9hZGNhc3QgYnJpZGdlIGlzIG5vdCByZWNvbW1lbmRlZCBpbiBu b24tcmV2ZXJ0aXZlIG1vZGUNCiBhcyB0aGUgd29ya2luZyBwYXRoIG5lZWRzIHRvIGJlIG9jY3Vw aWVkIGJ5IHRyYWZmaWMgYWxsIHRoZSB0aW1lLiBBbHNvIHRoZSBicm9hZGNhc3QgYnJpZGdlIGlz IG5vdCBlZmZpY2llbnQsIHNpbmNlIGJ5IGRlZmluaXRpb24sIHRoZSBwYWNrZXQgZHVwbGljYXRp b24gc2hvdWxkIG9jY3VyIGR1cmluZyBub3Qgb25seSBTRCBidXQgYWxzbyBTRiwgRlMsIE1TLCBl dGMuIEluIHRoaXMgZG9jdW1lbnQsIHdlIGFyZSBpbnRyb2R1Y2luZyBhbiBpbXByb3ZlZA0KIGJy aWRnZSBtZWNoYW5pc20sIHdoaWNoIGJlaGF2ZXMgbGlrZSBhIHNlbGVjdG9yIGJyaWRnZSBidXQg ZHVwbGljYXRlcyB0aGUgdHJhZmZpYyBvbmx5PC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij51bmRl ciBTRCBjb25kaXRpb24sIGFuZCB3ZSBiZWxpZXZlIHRoYXQgaXQgYWRkcmVzc2VzIGFsbCB0aGUg aXNzdWVzIHdpdGggZXhpc3RpbmcgYnJpZGdlcy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdo dDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PldoYXQgd2UgbWVhbiBieSBTRCBwcm90ZWN0aW9uIGlzIGFnbm9zdGljIHRvIHRoZSBTRCBkZXRl Y3Rpb24gbWV0aG9kIGlzIHRoYXQgdGhlIHByb3Bvc2VkIFNEIHByb3RlY3Rpb24gbWV0aG9kIChh Z2FpbiBob3cgdG8gb3BlcmF0ZSBhIGJyaWRnZQ0KIG9yIHdoYXQ8L3NwYW4+Jm5ic3A7PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPmJyaWdlIGlzIHVzZWQgaXMgYSBwYXJ0IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nKSBj YW4gYmUgdXNlZCBubyBtYXR0ZXIgd2hhdCBraW5kIG9mIFNEIGRldGVjdGlvbiBtZXRob2RzIChk YXRhIHBhY2tldCBjb3VudGluZywgQ0NNIHBhY2tldCBjb3VudGluZywgb3IgZXZlbiBwcm9wcmll dGFyeSBzZXJ2ZXIgbGF5ZXIgU0QgZGV0ZWN0aW9uKQ0KIGlzIHVzZWQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0 O2xpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+SSB0aGluayBJIGFuc3dlcmVkIGFsbCB0aGUgcXVlc3Rpb25zIG9uIHlvdXIg ZW1haWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7 bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3Vu IEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+WWFhY292LCBpZiB5b3UgaGF2ZSBhbnkg ZnVydGhlciBjb25jZXJucyBvciBxdWVzdGlvbnMsIHBsZWFzZSBsZXQgbWUga25vdy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDox NS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZXN0IHJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVp Z2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+SmVvbmctZG9uZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9 Ik1haWxTaWduU2VudCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjE1LjBwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+ DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tIDoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7WWFh Y292IFdlaW5nYXJ0ZW4mcXVvdDsgJmx0O3d5YWFjb3ZAZ21haWwuY29tJmd0Ozxicj4NCjxiPlNl bnQgOiA8L2I+MjAxMy0xMi0xMCAxNjowNDoxNyAoICYjNDM7MDk6MDAgKTxicj4NCjxiPlRvIDog PC9iPlJ5b28sIEplb25nLWRvbmcgJmx0O3J5b29AZXRyaS5yZS5rciZndDs8YnI+DQo8Yj5DYyA6 IDwvYj5kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQt aWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmZ3Q7LCBtcGxzQGlldGYub3JnICZs dDttcGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3QgOiA8L2I+UmU6IFF1ZXN0aW9uIHJl Z2FyZGluZyBTRCBwcm90ZWN0aW9uIGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkplb25nLWRvbmcsIGhp DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VGhhbmsgeW91IGZvciB5b3VyIHJlcGx5LiBZb3VyIGFuc3dlciBzZWVtcyB0byBiZSBhbiBhcHBy b3ByaWF0ZSBhbnN3ZXIgZm9yIG90aGVyIFNET3MsIG5vdCBzdXJlIHRoYXQgaXQgaXMgdHJ1ZSBm b3IgdGhlIGNvbnRleHQgb2YgTVBMUyBhbmQgSUVURg0KIHdvcmsuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MS4gWW91IHdyb3Rl ICZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDvrp5HsnYDqs6DrlJUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmFueSBwcm90ZWN0aW9u IHN3aXRjaGluZyAoaW5jbHVkaW5nIFBTQykgaXMgc3VwcG9zZWQgdG8gZGVzY3JpYmUgdGhlDQog b3BlcmF0aW9uIG9mIGJyaWRnZSBhbmQgc2VsZWN0b3IuJnF1b3Q7IC0gPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPnRoaXMgbWF5IGJlIHRydWUgZm9yIEV0aGVybmV0IGFuZDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+U0RIDQogYW5kIGZvciBkb2N1bWVudHMgdGhhdCBhcmUgZGVzY3JpYmluZyB0 aGUgb3BlcmF0aW9uIG9mIHRoZSBwaHlzaWNhbCBsYXllci4gSG93ZXZlciwgdGhlIElFVEYgKHRv IG15IHVuZGVyc3RhbmRpbmcgLSBhbmQgSSBhbSBjZXJ0YWlubHkgd2lsbGluZyB0byBiZSBjb3Jy ZWN0ZWQgb24gdGhpcyBwb2ludCkgaXMgY29uY2VybmVkIHdpdGggdGhlIHByb3RvY29sIGFuZCBs ZWF2ZSB0aGUgbG93ZXIgbGF5ZXJzIHRvIGltcGxlbWVudGF0aW9uLiBBbHNvLA0KIEkgYW0gbm90 IHN1cmUgdGhhdCB0aGUgY29uY2VwdHMgb2YgQnJpZGdlIGFuZCBTZWxlY3RvciByZWFsbHkgYXBw bHkgdG8gTVBMUyAoYWx0aG91Z2ggSSBhZG1pdCB0aGF0IHdlIGRpZCBtZW50aW9uIHRoZW0gaW4g dGhlIG9yaWdpbmFsIFBTQyBkZWZpbml0aW9uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yLiBZb3UgY2l0ZSB3aGF0IHdhcyB3 cml0dGVuIGluIEc4MDMxIGFzIGp1c3RpZmljYXRpb24gZm9yIGluY2x1ZGluZyBjb250ZW50IGlu dG8geW91ciBkcmFmdC4gQWdhaW4gaXQgaXMgaGFyZCB0byB0cmFuc2ZlciBtZXRob2RvbG9neSBm cm9tIG9uZSBTRE8NCiB0byBhbm90aGVyIGFuZCB0aGVyZWZvcmUsIHdoaWxlIEkgaGlnaGx5IHJl c3BlY3QgdGhlIHdvcmsgb2YgdGhlIElUVSwgSSBkbyBub3QgZmVlbCB0aGF0IHRoaXMgaXMgYSB2 ZXJ5IGNsZWFyIGp1c3RpZmljYXRpb24gZm9yIGluY2x1c2lvbiBpbnRvIGFuIGludGVybmV0LWRy YWZ0LiBFdmVuIHdoZW4gdGhlIGRyYWZ0IHN0YXRlcyB0aGF0IGl0cyBwdXJwb3NlIGlzIHRvIGFk ZHJlc3MgdGhlIGNvbmNlcm5zIG9mIHRoZSBJVFUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+My4gVG8gdGhlIGFjdHVhbCBwb2lu dCBvZiBteSBlYXJsaWVyIGNvbW1lbnQsIHRoYXQgeW91IGRvIG5vdCBzZWVtIHRvIGFkZHJlc3Mg LSB0aGUgcGFyYWdyYXBoIGluIFNlY3Rpb24gNy4zIHNlZW1zIHRvIHN0YXRlIHRoYXQgU0QgcHJv dGVjdGlvbiBjaGFuZ2VzDQogYWNjb3JkaW5nIHRvIHRoZSBtZXRob2QgdGhhdCBpcyB1c2VkIHRv IGRldGVjdCB0aGUgU0QuIFRoaXMgbWVhbnMgdGhhdCBTRCBwcm90ZWN0aW9uIGlzIG5vdCBhZ25v c3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoZSBkZXRlY3Rpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWx0ZXJuYXRpdmVseSwg d2UgY291bGQgYnJlYWsgdGhpcyBkZXBlbmRlbmNlIGFuZCBzdGF0ZSB0aGF0IFNEIHByb3RlY3Rp b24gaXMgYWx3YXlzIHByb3ZpZGVkIGJ5IGNoYW5naW5nIHRoZSB0cmFuc21pc3Npb24gb2YgdGhl IGRhdGEgdG8gMSYjNDM7MSBwcm90ZWN0aW9uDQogaW4gY2FzZXMgb2YgU0QgZGV0ZWN0aW9uLCB3 aGljaCBpcyB3aGF0IHRoZSBwYXJhZ3JhcGggaXMgc3VnZ2VzdGluZyB0byBkbyBmb3Igc29tZSBj YXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5JIGhvcGUgdGhpcyBmb3JtdWxhdGlvbiBtYWtlIG15IGNvbW1lbnQgY2xlYXJl ciBhbmQgd2UgYXJlIGFibGUgdG8gZGlzY3VzcyB0aGUgdGVjaG5vbG9naWNhbCBhcHByb2FjaCBy YXRoZXIgdGhhbiB0aGUgcGhpbG9zb3BoaWNhbCBkaWZmZXJlbmNlcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFuayB5b3Us PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ eWFhY292PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7bGluZS1oZWlnaHQ6 MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gTW9uLCBEZWMgOSwgMjAxMyBhdCAx MDowNCBQTSwgUnlvbywgSmVvbmctZG9uZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ5b29AZXRyaS5y ZS5rciIgdGFyZ2V0PSJfYmxhbmsiPnJ5b29AZXRyaS5yZS5rcjwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0 OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPllhYWNvdiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6 MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Z ZXMsIFBTQyBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9y IHRoZSBkZXRlY3Rpb24gb2YgU0YvU0QuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JdCBp cyBhbHNvIHRydWUgdGhhdCBhbnkgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGluY2x1ZGluZyBQU0Mp IGlzIHN1cHBvc2VkIHRvIGRlc2NyaWJlIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGFuZCBzZWxl Y3Rvci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0 O2xpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1 biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFzIHRoZXJlIGFyZSBtdWx0aXBsZSBv cHRpb25zIGZvciBkZXRlY3RpbmcgU0QsIHdlIG5lZWRlZCB0byBkZXNjcmliZSB0aGUgYmVoYXZp b3Igb2YgdGhlIGJyaWRnZSB0byBjb3ZlciBhbGwgdGhlIHBvc3NpYmxlIGRldGVjdGlvbiBtZXRo b2RzLg0KIERlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgZm9yIFNEIHByb3RlY3Rp b24gaXMgbm90IGEgbmV3IHRoaW5nLiBGb3IgZXhhbXBsZSwgRy44MDMxIC0gRXRoZXJuZXQgbGlu ZWFyIHByb3RlY3Rpb24gYWxzbyBkZXNjcmliZXMgd2hhdDwvc3Bhbj4mbmJzcDs8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+YnJpZGdlIGNhbjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+YmUNCiB1c2VkIGluIG9yZGVy IHRvIHByb3ZpZGUgcHJvdGVjdGlvbiBhZ2FpbnN0IFNELiA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1o ZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5CZXN0IHJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SmVvbmctZG9uZzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0 OjE1LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxociBzaXplPSIyIiB3aWR0 aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tIDoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7 WWFhY292IFdlaW5nYXJ0ZW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp3eWFhY292QGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnd5YWFjb3ZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5T ZW50IDogPC9iPjIwMTMtMTItMDggMjA6MDE6NTUgKCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6 IDwvYj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5p ZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dUB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtbXBscy10cC1wc2Mt aXR1QHRvb2xzLmlldGYub3JnPC9hPiZndDssDQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86 bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPkNjIDogPC9iPjxicj4NCjxiPlN1YmplY3QgOiA8L2I+UXVlc3Rpb24gcmVnYXJkaW5nIFNE IHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUgPG86cD4NCjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5IaSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5BZnRlciByZWFkaW5nIHRocm91Z2ggeW91ciBkcmFmdCBvbiB0aGUgZXh0ZW5zaW9u cyB0byBQU0MgdG8gc3VwcG9ydCBTRCBzaXR1YXRpb25zLCBJIGhhdmUgYSBxdWVzdGlvbiBmb3Ig Y2xhcmlmaWNhdGlvbiAtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+SW4geW91ciBpbnRyb2R1Y3Rpb24gLSB5b3Ugc3RhdGUgdGhhdCB0aGUg bWV0aG9kIHVzZWQgdG8gZGV0ZWN0IFNEIHNpdHVhdGlvbnMgaXMgb3V0LW9mLXNjb3BlIG9mIHRo ZSBkb2N1bWVudC4gRG9lcyB0aGlzIG1lYW4gdGhhdCBQU0MgaXMgc3VwcG9zZWQNCiB0byBiZSBh Z25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoaXMgZGV0ZWN0aW9uPyBJdCBzaG91bGQg cmVhY3Qgb25seSB0byB0aGUgaW5kaWNhdGlvbiwgc2ltaWxhcmx5IHRvIHRoZSByZWFjdGlvbiBh bmQgcmVsYXRpb25zaGlwIHRvIHRoZSBtZXRob2QgZm9yIGRldGVjdGluZyBhbmQgZGVjbGFyaW5n IGEgU0Ygc2l0dWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkhvd2V2ZXIsIHdoZW4geW91IGV4cGxhaW4gdGhlIGJlaGF2aW9yIG9m IHRoZSBTRCBwcm90ZWN0aW9uIGluIHNlY3Rpb24gNy4zIHlvdSBoYXZlIGEgcGFyYWdyYXBoIHRo YXQgc3RhcnRzIHdpdGggJnF1b3Q7SWYgdGhlIGRldGVjdGlvbiBvZiBhIFNEIGRlcGVuZHMNCiBv biB0aGUgcHJlc2VuY2Ugb2YgdXNlciBkYXRhIHBhY2tldHMgLi4uJnF1b3Q7ICZuYnNwO3RoYXQg c2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgYmVoYXZpb3Igb2YgdGhlIHN5c3RlbSBpcyBkZXBl bmRlbnQgdXBvbiB0aGUgZGV0ZWN0aW9uIG1ldGhvZCEgQ2xhcmlmaWNhdGlvbiB3b3VsZCBiZSBh cHByZWNpYXRlZC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+VGhhbnggYW5kIEJSLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPnlhYWNvdjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1 bml0eTwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFueCBhbmQgQlIsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+eWFhY292PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3RpbGwgbG9va2luZyBm b3IgbmV3IG9wcG9ydHVuaXR5PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA43C6F40Ankgeml501mbschi_-- From ryoo@etri.re.kr Sun Dec 29 21:19:59 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 68DC41AE3A5 for ; Sun, 29 Dec 2013 21:19:59 -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 dmgNCu7tz8SG for ; Sun, 29 Dec 2013 21:19:55 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0F50E1AE3BB for ; Sun, 29 Dec 2013 21:19:53 -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; Mon, 30 Dec 2013 14:19:44 +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, 30 Dec 2013 14:19:41 +0900 From: "Ryoo, Jeong-dong" To: Qin Wu , Yaacov Weingarten Thread-Topic: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHPBRH/4khHp6ur2EqtLKlbJ1qSCppsINn5 Date: Mon, 30 Dec 2013 05:19:41 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AF30D@SMTP2.etri.info> References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info>, 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_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF30DSMTP2etriinfo_" 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: Mon, 30 Dec 2013 05:19:59 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF30DSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UWluLA0KDQpUaGlzIGRyYWZ0IGlzIGJhc2VkIG9uIFJGQzYzNzggZm9yIHRoZSBwcm90b2NvbCBt ZXNzYWdlIGZvcm1hdCBhbmQgdGhlIGJhc2ljIG9wZXJhdGlvbmFsIHByaWNpcGxlcywgd2hpY2gg YXJlIGRpZmZlcmVudCBmcm9tIEcuODAzMS4NClRoZSBpbnRlbnRpb24gb2YgdGhpcyBkcmFmdCBp cyB0byBtYWtlIFJGQzYzNzggYmUgYWxpZ25lZCB3aXRoIEcuODAzMSAob3Igb3RoZXIgSVRVIHBy b3RlY3Rpb24gdGVjaG5vbG9naWVzKSBpbiB0aGUgYXNwZWN0cyBvZiAibmV0d29yayBvcGVyYXRp b24iLiBJbiBvdGhlciB3b3JkcywgaXQgbG9va3MgbGlrZSBHLjgwMzEgKG9yIG90aGVyIElUVSBw cm90ZWN0aW9uIHRlY2hub2xvZ2llcykgdG8gdGhlIG5ldHdvcmsgb3BlcmF0b3JzLCBidXQgdGhl IGFjdHVhbCBwcm90b2NvbCBvcGVyYXRpb25zIGFuZCB0aGUgYml0cyBvbiB0aGUgd2lyZSBhcmUg ZGlmZmVyZW50Lg0KDQpJIG1lbnRpb25lZCBHLjgwMzEgaW4gbXkgcHJldmlvdXMgZW1haWwgdG8g WWFhY292IGp1c3QgZm9yIGJldHRlciBleHBsYW5hdGlvbiwgYW5kIEkgZG9uJ3QgdGhpbmsgdGhp cyBkb2N1bWVudCBuZWVkcyBHLjgwMzEgYXMgYSByZWZlcmVuY2UuDQpCdXQsIGlmIHlvdSBmaW5k IGFueSBwYXJ0IGluIHRoaXMgZG9jdW1lbnQgdGhhdCBuZWVkcyBhIHJlZmVyZW5jZSB0byBHLjgw MzEsIHBsZWFzZSBsZXQgdXMga25vdy4NCg0KWW91IGFuZCBZYWFjb3YgbWlnaHQgYmUgcmlnaHQg b24gdGhlIHNlbnRlbmNlICJTRCBwcm90ZWN0b24gaXMgbm90IGFnbm9zdGljIHRvIHRoZSBkZXRl Y3Rpb24gbWV0aG9kIi4NCkJ1dCwgYXMgSSBzYWlkLCBteSBvcmlnaW5hbCBpbnRlbnRpb24gYW5k IHdoYXQgd2Ugd2FudGVkIHRvIGFjaGlldmUgaW4gdGhpcyBkb2N1bWVudCBhcmUgdGhhdCB0aGUg cHJvdGVjdGlvbiBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBjb3ZlcnMgU0Qgbm8gbWF0dGVy IHdoYXQga2luZCBvZiBTRCBkZXRlY3Rpb24gbWV0aG9kcyBzaG91ZCBiZSB1c2VkLg0KQnkgdGhl IHdheSwgdGhpcyBkcmFmdCBkb2VzIG5vdCBoYXZlIGEgd29yZCAiYWdub3N0aWMiLg0KDQpCZXN0 IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb20gOiAiUWluIFd1IiA8YmlsbC53dUBodWF3ZWkuY29tPg0KU2VudCA6IDIw MTMtMTItMzAgMTI6NDg6MjcgKCArMDk6MDAgKQ0KVG8gOiBSeW9vLCBKZW9uZy1kb25nIDxyeW9v QGV0cmkucmUua3I+LCBZYWFjb3YgV2VpbmdhcnRlbiA8d3lhYWNvdkBnbWFpbC5jb20+DQpDYyA6 IG1wbHNAaWV0Zi5vcmcgPG1wbHNAaWV0Zi5vcmc+LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5v cmc+DQpTdWJqZWN0IDogUkU6IFttcGxzXSBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlv biBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dQ0KDQpTb3JyeSB0byBpbnRlcnJ1cHQgaW4u DQpJIGFtIGEgbGl0dGxlIGJpdCBzdXJwcmlzZWQgdGhpcyBkcmFmdCBoYXMgbm90IGFueSByZWZl cmVuY2UgdG8gSVRVIGRvY3VtZW50Lg0KSSBhbSB3b25kZXJpbmcgaG93IG11Y2ggdGhpcyBkcmFm dCBpcyBjb21wbGlhbnQgd2l0aCBHLjgwMzE/IElzIHRoZXJlIGFueSB0d2VhayBvciBvcHRpbWl6 YXRpb24gdG8gRy44MzE/DQpXaGF0IGlzIHRoZSBjb25jZXJuIG9mIEcuODMxIHRoaXMgZHJhZnQg aXMgZGVhbGluZyB3aXRoPw0KSWYgYW55dGhpbmcgaXMgZnJvbSBHLjgzMSBvciBhbnkgb3RoZXIg SVRVIGRvY3VtZW50LCBJIHRoaW5rIGl0IGlzIGZpbmUsIGhvd2V2ZXIgRy44MzEgb3Igc29tZSBv dGhlciBJVFUgZG9jdW1lbnRzIGFyZSB3b3J0aCBiZWluZyByZWZlcmVuY2VkLg0KDQpJZiB0aGlz IGRyYWZ0IGlzIGZvY3VzaW5nIG9uIGFkZHJlc3NpbmcgRy44MzEsIGl0IGlzIGJldHRlciB0byBj bGFyaWZ5IHRoaXMgYSBsaXR0bGUgYml0IGluIHRoaXMgZHJhZnQuDQoNCk15IGZlZWxpbmcgaXMg dGhpcyBkcmFmdCBzZWVtcyB0byBpbnRyb2R1Y2UgY29tYmluYXRpb24gb2YgMSsxIGFuZCAxOjEg cHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUgd2hlbiBJIHJlYWQNCuKAnA0KQXMgeW91IG1pZ2h0IHJl Y2FsbCBmcm9tIEcuODAzMSDigJMgRXRoZXJuZXQgbGluZWFyIHByb3RlY3Rpb24sIHRoZSBzZWxl Y3RvciBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVkIGR1ZSB0byB0aGUgdHJhZmZpYyBmbGFwcGlu ZyB1bmRlciBTRCBjb25kaXRpb25zIG9uIGJvdGggcGF0aHMuIEluc3RlYWQg4oCcYnJvYWRjYXN0 IGJyaWRnZeKAnSBpcyBpbnRyb2R1Y2VkIHRvIHN1cHBvcnQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcg YWdhaW5zdCBTRC4gQnV0LCB0aGlzIGJyb2FkY2FzdCBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVk IGluIG5vbi1yZXZlcnRpdmUgbW9kZSBhcyB0aGUgd29ya2luZyBwYXRoIG5lZWRzIHRvIGJlIG9j Y3VwaWVkIGJ5IHRyYWZmaWMgYWxsIHRoZSB0aW1lLiBBbHNvIHRoZSBicm9hZGNhc3QgYnJpZGdl IGlzIG5vdCBlZmZpY2llbnQsIHNpbmNlIGJ5IGRlZmluaXRpb24sIHRoZSBwYWNrZXQgZHVwbGlj YXRpb24gc2hvdWxkIG9jY3VyIGR1cmluZyBub3Qgb25seSBTRCBidXQgYWxzbyBTRiwgRlMsIE1T LCBldGMuIEluIHRoaXMgZG9jdW1lbnQsIHdlIGFyZSBpbnRyb2R1Y2luZyBhbiBpbXByb3ZlZCBi cmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhhdmVzIGxpa2UgYSBzZWxlY3RvciBicmlkZ2UgYnV0 IGR1cGxpY2F0ZXMgdGhlIHRyYWZmaWMgb25seSB1bmRlciBTRCBjb25kaXRpb24sIGFuZCB3ZSBi ZWxpZXZlIHRoYXQgaXQgYWRkcmVzc2VzIGFsbCB0aGUgaXNzdWVzIHdpdGggZXhpc3RpbmcgYnJp ZGdlcy4NCg0K4oCdLA0KSSB0ZW5kIHRvIGFncmVlIFlhY2NvdiB0aGF0IFNEIHByb3RlY3Rpb24g aXMgbm90IGFnbm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhlIGRldGVjdGlvbi4NCkFs c28gSSBhbSBpbnRlcmVzdGVkIHRvIGtub3cgaG93IHRvIHBvc2l0aW9uIGJyaWRnZSBhbmQgc2Vs ZWN0b3IgaW4gdGhlIE1QTFMgYXJjaGl0ZWN0dXJlPw0KDQpSZWdhcmRzIQ0KLVFpbg0KDQpGcm9t Om1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSeW9vLCBK ZW9uZy1kb25nDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjYsIDIwMTMgMTI6NTEgUE0NClRv OiBZYWFjb3YgV2VpbmdhcnRlbg0KQ2M6IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy10 cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIFF1ZXN0aW9uIHJl Z2FyZGluZyBTRCBwcm90ZWN0aW9uIGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQoNCllh YWNvdiwgdGhhbmtzIGZvciB5b3VyIGVtYWlsLiBTb21laG93LCBJIGZvcmdvdCB0byByZXNwb25k IGFuZCBhbSBzb3JyeSBmb3IgdGhlIGRlbGF5Lg0KDQpGaXJzdCBvZiBhbGwsIFlhYWNvdiwgaXQg aXMgbm90IHRydWUgdGhhdCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb2YgRXRoZXJuZXQgb3Ig U0RIIGRlc2NyaWJlcyB0aGUgb3BlcmF0aW9uIG9mIGFueSBsYXllciBiZWxvdy4gUmF0aGVyLCBl YWNoIGxheWVyIGlzIHN1cHBvc2VkIHRvIG9wZXJhdGUgaW5kZXBlbmRlbnRseS4gSG93ZXZlciwg dGhlcmUgYXJlIGEgZmV3IGV4Y2VwdGlvbnMsIHN1Y2ggYXMgaG9sZC1vZmYgdGltZXIgYW5kIEFJ UyAoYXMgYSB0cmlnZ2VyIGZyb20gbG93ZXIgbGF5ZXIpLiBFdmVuIHRob3VnaCB0aGVyZSBleGlz dCBzb21lIHByb3ByaWV0YXJ5IGltcGxlbWVudGF0aW9ucyB0aGF0IHVzZSBvdGhlciBpbmZvcm1h dGlvbiBmcm9tIGxvd2VyIGxheWVyLCBtb3N0IG9mIHRoZW0gYXJlIG5vdCByZWNvbW1lbmRlZCBp biBJVFUtVCBzdGFuZGFyZHMuDQoNCkJyaWRnZSBhbmQgc2VsZWN0b3IgYXJlIG5vdCBpbiB0aGUg cGh5c2ljYWwgbGF5ZXIsIGJ1dCB0aGV5IGFyZSBwYXJ0IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5n LiBPbmUgb2YgdGhlIGltcG9ydGFudCBvdXRwdXQgYWN0aW9ucyBmcm9tIHRoZSBQU0MgY29udHJv bCBsb2dpYyBpcyBjb29yZGluYXRpbmcgdGhlIHBvc2l0aW9ucyBvZiBicmlkZ2UgYW5kIHNlbGVj dG9yLiBBbHNvLCB0aGUgYnJpZGdlIG9wZXJhdGlvbiByZXNwb25kaW5nIHRvIHRoZSBQU0MgY29u dHJvbCBsb2dpYyBpcyBhbHNvIHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIEhvd2V2ZXIs IGhvdyB0byByZWFsaXplIHRoZSBicmlkZ2UgYW5kIHNlbGVjdG9yIChmb3IgZXhhbXBsZSwgaG93 IHRvIG1hbmlwdWxhdGUgYSBwYWNrZXQgZm9yd2FyZGluZyBtZWNoYW5pc20pIGlzIGFuIGltcGxl bWVudGF0aW9uIG1hdHRlci4NCg0KV2hlbiB3ZSBtZW50aW9uIDErMSBvciAxOjEgaW4gcHJvdGVj dGlvbiBhcmNoaXRlY3R1cmUsIHdlIGRlYWwgd2l0aCB0aGUgb3BlcmF0aW9uIG9mIGJyaWRnZS4g Rm9yIDErMSBhcmNoaXRlY3R1cmUsIHRoZSB0cmFmZmljIG5lZWRzIHRvIGJlIGR1cGxpY2F0ZWQg YXQgdGhlIHNlbmRlciBhbmQgc2VudCB0byBib3RoIHBhdGhzIGFsbCB0aGUgdGltZSwgd2hpY2gg aXMgdGhlIHNhbWUgZGVzY3JpcHRpb24gYXMgdGhlIOKAnHBlcm1hbmVudCBicmlkZ2XigJ0uIEZv ciAxOjEgYXJjaGl0ZWN0dXJlLCDigJxzZWxlY3RvciBicmlkZ2XigJ0gaXMgdXNlZCB0byBzZW5k IHRoZSB0cmFmZmljIG9ubHkgb25lIG9mIHRoZSBwYXRocy4gQXMgdGhlIHByb3RlY3Rpb24gcGF0 aCBjYW4gYmUgdXNlZCBieSBiZXN0IHRyYWZmaWMgaW4gcGFja2V0IG5ldHdvcmtzIGFuZCB0aGUg cGFja2V0IGR1cGxpY2F0aW9uIHRha2VzIG11Y2ggbW9yZSBlZmZvcnQvaW50ZXJuYWwgYmFuZHdp ZHRoIGluc2lkZSBhIHN3aXRjaCB0aGFuIHRoZSB0aW1lIHNsb3QgY29weSBvZiBjaXJjdWl0IG5l dHdvcmtzLiAxOjEgaXMgY29uc2lkZXJlZCBhcyBwcmVmZXJhYmxlIGFyY2hpdGVjdHVyZSBpbiBw YWNrZXQgbmV0d29ya3MuDQoNCkFzIHlvdSBtaWdodCByZWNhbGwgZnJvbSBHLjgwMzEg4oCTIEV0 aGVybmV0IGxpbmVhciBwcm90ZWN0aW9uLCB0aGUgc2VsZWN0b3IgYnJpZGdlIGlzIG5vdCByZWNv bW1lbmRlZCBkdWUgdG8gdGhlIHRyYWZmaWMgZmxhcHBpbmcgdW5kZXIgU0QgY29uZGl0aW9ucyBv biBib3RoIHBhdGhzLiBJbnN0ZWFkIOKAnGJyb2FkY2FzdCBicmlkZ2XigJ0gaXMgaW50cm9kdWNl ZCB0byBzdXBwb3J0IHByb3RlY3Rpb24gc3dpdGNoaW5nIGFnYWluc3QgU0QuIEJ1dCwgdGhpcyBi cm9hZGNhc3QgYnJpZGdlIGlzIG5vdCByZWNvbW1lbmRlZCBpbiBub24tcmV2ZXJ0aXZlIG1vZGUg YXMgdGhlIHdvcmtpbmcgcGF0aCBuZWVkcyB0byBiZSBvY2N1cGllZCBieSB0cmFmZmljIGFsbCB0 aGUgdGltZS4gQWxzbyB0aGUgYnJvYWRjYXN0IGJyaWRnZSBpcyBub3QgZWZmaWNpZW50LCBzaW5j ZSBieSBkZWZpbml0aW9uLCB0aGUgcGFja2V0IGR1cGxpY2F0aW9uIHNob3VsZCBvY2N1ciBkdXJp bmcgbm90IG9ubHkgU0QgYnV0IGFsc28gU0YsIEZTLCBNUywgZXRjLiBJbiB0aGlzIGRvY3VtZW50 LCB3ZSBhcmUgaW50cm9kdWNpbmcgYW4gaW1wcm92ZWQgYnJpZGdlIG1lY2hhbmlzbSwgd2hpY2gg YmVoYXZlcyBsaWtlIGEgc2VsZWN0b3IgYnJpZGdlIGJ1dCBkdXBsaWNhdGVzIHRoZSB0cmFmZmlj IG9ubHkgdW5kZXIgU0QgY29uZGl0aW9uLCBhbmQgd2UgYmVsaWV2ZSB0aGF0IGl0IGFkZHJlc3Nl cyBhbGwgdGhlIGlzc3VlcyB3aXRoIGV4aXN0aW5nIGJyaWRnZXMuDQoNCldoYXQgd2UgbWVhbiBi eSBTRCBwcm90ZWN0aW9uIGlzIGFnbm9zdGljIHRvIHRoZSBTRCBkZXRlY3Rpb24gbWV0aG9kIGlz IHRoYXQgdGhlIHByb3Bvc2VkIFNEIHByb3RlY3Rpb24gbWV0aG9kIChhZ2FpbiBob3cgdG8gb3Bl cmF0ZSBhIGJyaWRnZSBvciB3aGF0IGJyaWdlIGlzIHVzZWQgaXMgYSBwYXJ0IG9mIHByb3RlY3Rp b24gc3dpdGNoaW5nKSBjYW4gYmUgdXNlZCBubyBtYXR0ZXIgd2hhdCBraW5kIG9mIFNEIGRldGVj dGlvbiBtZXRob2RzIChkYXRhIHBhY2tldCBjb3VudGluZywgQ0NNIHBhY2tldCBjb3VudGluZywg b3IgZXZlbiBwcm9wcmlldGFyeSBzZXJ2ZXIgbGF5ZXIgU0QgZGV0ZWN0aW9uKSBpcyB1c2VkLg0K DQpJIHRoaW5rIEkgYW5zd2VyZWQgYWxsIHRoZSBxdWVzdGlvbnMgb24geW91ciBlbWFpbC4NCg0K WWFhY292LCBpZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb25jZXJucyBvciBxdWVzdGlvbnMsIHBs ZWFzZSBsZXQgbWUga25vdy4NCg0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb20gOiAiWWFhY292IFdlaW5nYXJ0ZW4i IDx3eWFhY292QGdtYWlsLmNvbT4NClNlbnQgOiAyMDEzLTEyLTEwIDE2OjA0OjE3ICggKzA5OjAw ICkNClRvIDogUnlvbywgSmVvbmctZG9uZyA8cnlvb0BldHJpLnJlLmtyPg0KQ2MgOiBkcmFmdC1p ZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXBz Yy1pdHVAdG9vbHMuaWV0Zi5vcmc+LCBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPg0KU3Vi amVjdCA6IFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRm LW1wbHMtdHAtcHNjLWl0dQ0KSmVvbmctZG9uZywgaGkNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJl cGx5LiBZb3VyIGFuc3dlciBzZWVtcyB0byBiZSBhbiBhcHByb3ByaWF0ZSBhbnN3ZXIgZm9yIG90 aGVyIFNET3MsIG5vdCBzdXJlIHRoYXQgaXQgaXMgdHJ1ZSBmb3IgdGhlIGNvbnRleHQgb2YgTVBM UyBhbmQgSUVURiB3b3JrLg0KDQoxLiBZb3Ugd3JvdGUgImFueSBwcm90ZWN0aW9uIHN3aXRjaGlu ZyAoaW5jbHVkaW5nIFBTQykgaXMgc3VwcG9zZWQgdG8gZGVzY3JpYmUgdGhlIG9wZXJhdGlvbiBv ZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiIgLSB0aGlzIG1heSBiZSB0cnVlIGZvciBFdGhlcm5ldCBh bmQgU0RIIGFuZCBmb3IgZG9jdW1lbnRzIHRoYXQgYXJlIGRlc2NyaWJpbmcgdGhlIG9wZXJhdGlv biBvZiB0aGUgcGh5c2ljYWwgbGF5ZXIuIEhvd2V2ZXIsIHRoZSBJRVRGICh0byBteSB1bmRlcnN0 YW5kaW5nIC0gYW5kIEkgYW0gY2VydGFpbmx5IHdpbGxpbmcgdG8gYmUgY29ycmVjdGVkIG9uIHRo aXMgcG9pbnQpIGlzIGNvbmNlcm5lZCB3aXRoIHRoZSBwcm90b2NvbCBhbmQgbGVhdmUgdGhlIGxv d2VyIGxheWVycyB0byBpbXBsZW1lbnRhdGlvbi4gQWxzbywgSSBhbSBub3Qgc3VyZSB0aGF0IHRo ZSBjb25jZXB0cyBvZiBCcmlkZ2UgYW5kIFNlbGVjdG9yIHJlYWxseSBhcHBseSB0byBNUExTIChh bHRob3VnaCBJIGFkbWl0IHRoYXQgd2UgZGlkIG1lbnRpb24gdGhlbSBpbiB0aGUgb3JpZ2luYWwg UFNDIGRlZmluaXRpb24pLg0KDQoyLiBZb3UgY2l0ZSB3aGF0IHdhcyB3cml0dGVuIGluIEc4MDMx IGFzIGp1c3RpZmljYXRpb24gZm9yIGluY2x1ZGluZyBjb250ZW50IGludG8geW91ciBkcmFmdC4g QWdhaW4gaXQgaXMgaGFyZCB0byB0cmFuc2ZlciBtZXRob2RvbG9neSBmcm9tIG9uZSBTRE8gdG8g YW5vdGhlciBhbmQgdGhlcmVmb3JlLCB3aGlsZSBJIGhpZ2hseSByZXNwZWN0IHRoZSB3b3JrIG9m IHRoZSBJVFUsIEkgZG8gbm90IGZlZWwgdGhhdCB0aGlzIGlzIGEgdmVyeSBjbGVhciBqdXN0aWZp Y2F0aW9uIGZvciBpbmNsdXNpb24gaW50byBhbiBpbnRlcm5ldC1kcmFmdC4gRXZlbiB3aGVuIHRo ZSBkcmFmdCBzdGF0ZXMgdGhhdCBpdHMgcHVycG9zZSBpcyB0byBhZGRyZXNzIHRoZSBjb25jZXJu cyBvZiB0aGUgSVRVLg0KDQozLiBUbyB0aGUgYWN0dWFsIHBvaW50IG9mIG15IGVhcmxpZXIgY29t bWVudCwgdGhhdCB5b3UgZG8gbm90IHNlZW0gdG8gYWRkcmVzcyAtIHRoZSBwYXJhZ3JhcGggaW4g U2VjdGlvbiA3LjMgc2VlbXMgdG8gc3RhdGUgdGhhdCBTRCBwcm90ZWN0aW9uIGNoYW5nZXMgYWNj b3JkaW5nIHRvIHRoZSBtZXRob2QgdGhhdCBpcyB1c2VkIHRvIGRldGVjdCB0aGUgU0QuIFRoaXMg bWVhbnMgdGhhdCBTRCBwcm90ZWN0aW9uIGlzIG5vdCBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVz ZWQgZm9yIHRoZSBkZXRlY3Rpb24uDQpBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCBicmVhayB0aGlz IGRlcGVuZGVuY2UgYW5kIHN0YXRlIHRoYXQgU0QgcHJvdGVjdGlvbiBpcyBhbHdheXMgcHJvdmlk ZWQgYnkgY2hhbmdpbmcgdGhlIHRyYW5zbWlzc2lvbiBvZiB0aGUgZGF0YSB0byAxKzEgcHJvdGVj dGlvbiBpbiBjYXNlcyBvZiBTRCBkZXRlY3Rpb24sIHdoaWNoIGlzIHdoYXQgdGhlIHBhcmFncmFw aCBpcyBzdWdnZXN0aW5nIHRvIGRvIGZvciBzb21lIGNhc2VzLg0KDQpJIGhvcGUgdGhpcyBmb3Jt dWxhdGlvbiBtYWtlIG15IGNvbW1lbnQgY2xlYXJlciBhbmQgd2UgYXJlIGFibGUgdG8gZGlzY3Vz cyB0aGUgdGVjaG5vbG9naWNhbCBhcHByb2FjaCByYXRoZXIgdGhhbiB0aGUgcGhpbG9zb3BoaWNh bCBkaWZmZXJlbmNlcy4NCg0KVGhhbmsgeW91LA0KeWFhY292DQoNCk9uIE1vbiwgRGVjIDksIDIw MTMgYXQgMTA6MDQgUE0sIFJ5b28sIEplb25nLWRvbmcgPHJ5b29AZXRyaS5yZS5rcjxtYWlsdG86 cnlvb0BldHJpLnJlLmtyPj4gd3JvdGU6DQpZYWFjb3YsDQoNClllcywgUFNDIGlzIHN1cHBvc2Vk IHRvIGJlIGFnbm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhlIGRldGVjdGlvbiBvZiBT Ri9TRC4NCg0KSXQgaXMgYWxzbyB0cnVlIHRoYXQgYW55IHByb3RlY3Rpb24gc3dpdGNoaW5nIChp bmNsdWRpbmcgUFNDKSBpcyBzdXBwb3NlZCB0byBkZXNjcmliZSB0aGUgb3BlcmF0aW9uIG9mIGJy aWRnZSBhbmQgc2VsZWN0b3IuDQoNCkFzIHRoZXJlIGFyZSBtdWx0aXBsZSBvcHRpb25zIGZvciBk ZXRlY3RpbmcgU0QsIHdlIG5lZWRlZCB0byBkZXNjcmliZSB0aGUgYmVoYXZpb3Igb2YgdGhlIGJy aWRnZSB0byBjb3ZlciBhbGwgdGhlIHBvc3NpYmxlIGRldGVjdGlvbiBtZXRob2RzLiBEZXNjcmli aW5nIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGZvciBTRCBwcm90ZWN0aW9uIGlzIG5vdCBhIG5l dyB0aGluZy4gRm9yIGV4YW1wbGUsIEcuODAzMSAtIEV0aGVybmV0IGxpbmVhciBwcm90ZWN0aW9u IGFsc28gZGVzY3JpYmVzIHdoYXQgYnJpZGdlIGNhbiBiZSB1c2VkIGluIG9yZGVyIHRvIHByb3Zp ZGUgcHJvdGVjdGlvbiBhZ2FpbnN0IFNELg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbSA6ICJZYWFjb3YgV2Vp bmdhcnRlbiIgPHd5YWFjb3ZAZ21haWwuY29tPG1haWx0bzp3eWFhY292QGdtYWlsLmNvbT4+DQpT ZW50IDogMjAxMy0xMi0wOCAyMDowMTo1NSAoICswOTowMCApDQpUbyA6IGRyYWZ0LWlldGYtbXBs cy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcHNj LWl0dUB0b29scy5pZXRmLm9yZz4gPGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmll dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz4+ LCBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiA8bXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4+DQpDYyA6DQpTdWJqZWN0IDogUXVlc3Rpb24gcmVnYXJkaW5nIFNE IHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCg0KSGksDQoNCkFmdGVy IHJlYWRpbmcgdGhyb3VnaCB5b3VyIGRyYWZ0IG9uIHRoZSBleHRlbnNpb25zIHRvIFBTQyB0byBz dXBwb3J0IFNEIHNpdHVhdGlvbnMsIEkgaGF2ZSBhIHF1ZXN0aW9uIGZvciBjbGFyaWZpY2F0aW9u IC0NCkluIHlvdXIgaW50cm9kdWN0aW9uIC0geW91IHN0YXRlIHRoYXQgdGhlIG1ldGhvZCB1c2Vk IHRvIGRldGVjdCBTRCBzaXR1YXRpb25zIGlzIG91dC1vZi1zY29wZSBvZiB0aGUgZG9jdW1lbnQu IERvZXMgdGhpcyBtZWFuIHRoYXQgUFNDIGlzIHN1cHBvc2VkIHRvIGJlIGFnbm9zdGljIHRvIHRo ZSBtZXRob2QgdXNlZCBmb3IgdGhpcyBkZXRlY3Rpb24/IEl0IHNob3VsZCByZWFjdCBvbmx5IHRv IHRoZSBpbmRpY2F0aW9uLCBzaW1pbGFybHkgdG8gdGhlIHJlYWN0aW9uIGFuZCByZWxhdGlvbnNo aXAgdG8gdGhlIG1ldGhvZCBmb3IgZGV0ZWN0aW5nIGFuZCBkZWNsYXJpbmcgYSBTRiBzaXR1YXRp b24uDQpIb3dldmVyLCB3aGVuIHlvdSBleHBsYWluIHRoZSBiZWhhdmlvciBvZiB0aGUgU0QgcHJv dGVjdGlvbiBpbiBzZWN0aW9uIDcuMyB5b3UgaGF2ZSBhIHBhcmFncmFwaCB0aGF0IHN0YXJ0cyB3 aXRoICJJZiB0aGUgZGV0ZWN0aW9uIG9mIGEgU0QgZGVwZW5kcyBvbiB0aGUgcHJlc2VuY2Ugb2Yg dXNlciBkYXRhIHBhY2tldHMgLi4uIiAgdGhhdCBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IHRoZSBi ZWhhdmlvciBvZiB0aGUgc3lzdGVtIGlzIGRlcGVuZGVudCB1cG9uIHRoZSBkZXRlY3Rpb24gbWV0 aG9kISBDbGFyaWZpY2F0aW9uIHdvdWxkIGJlIGFwcHJlY2lhdGVkLg0KDQotLQ0KVGhhbnggYW5k IEJSLA0KeWFhY292DQoNClN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eQ0KDQoNCg0K DQotLQ0KVGhhbnggYW5kIEJSLA0KeWFhY292DQoNClN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBv cnR1bml0eQ0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF30DSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5RaW4sPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+VGhpcyBkcmFmdCBpcyBiYXNlZCBvbiBSRkM2Mzc4IGZvciB0aGUgcHJvdG9jb2wgbWVzc2Fn ZSBmb3JtYXQgYW5kIHRoZSZuYnNwO2Jhc2ljIG9wZXJhdGlvbmFsIHByaWNpcGxlcywgd2hpY2gm bmJzcDthcmUgZGlmZmVyZW50IGZyb20gRy44MDMxLjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiPlRoZSBpbnRlbnRpb24gb2YgdGhpcyBkcmFmdCBpcyB0byBtYWtlIFJGQzYz NzggYmUgYWxpZ25lZCB3aXRoIEcuODAzMSAob3Igb3RoZXIgSVRVIHByb3RlY3Rpb24gdGVjaG5v bG9naWVzKSBpbiB0aGUgYXNwZWN0cyBvZiAmcXVvdDtuZXR3b3JrIG9wZXJhdGlvbiZxdW90Oy4m bmJzcDtJbiBvdGhlciB3b3JkcywgaXQmbmJzcDtsb29rcyBsaWtlIEcuODAzMSAob3Igb3RoZXIg SVRVIHByb3RlY3Rpb24gdGVjaG5vbG9naWVzKSB0bw0KIHRoZSBuZXR3b3JrIG9wZXJhdG9ycywg YnV0Jm5ic3A7dGhlJm5ic3A7YWN0dWFsIHByb3RvY29sIG9wZXJhdGlvbnMmbmJzcDthbmQgdGhl IGJpdHMgb24gdGhlIHdpcmUgYXJlIGRpZmZlcmVudC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0 Ij5JIG1lbnRpb25lZCBHLjgwMzEgaW4gbXkgcHJldmlvdXMgZW1haWwgdG8gWWFhY292IGp1c3Qg Zm9yIGJldHRlciBleHBsYW5hdGlvbiwmbmJzcDthbmQgSSBkb24ndCB0aGluayZuYnNwO3RoaXMg ZG9jdW1lbnQmbmJzcDtuZWVkcyZuYnNwO0cuODAzMSBhcyBhIHJlZmVyZW5jZS4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkJ1dCwgaWYgeW91Jm5ic3A7ZmluZCBhbnkg cGFydCBpbiB0aGlzIGRvY3VtZW50IHRoYXQmbmJzcDtuZWVkcyBhIHJlZmVyZW5jZSB0byBHLjgw MzEsIHBsZWFzZSBsZXQgdXMga25vdy4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Z b3UgYW5kIFlhYWNvdiBtaWdodCBiZSByaWdodCBvbiB0aGUgc2VudGVuY2UgJnF1b3Q7U0QgcHJv dGVjdG9uIGlzIG5vdCBhZ25vc3RpYyB0byB0aGUgZGV0ZWN0aW9uIG1ldGhvZCZxdW90Oy48L2Rp dj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5CdXQsIGFzIEkgc2FpZCwgbXkgb3Jp Z2luYWwgaW50ZW50aW9uIGFuZCB3aGF0IHdlIHdhbnRlZCB0byBhY2hpZXZlIGluIHRoaXMgZG9j dW1lbnQmbmJzcDthcmUgdGhhdCZuYnNwO3RoZSZuYnNwOzxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPnByb3RlY3Rpb24mbmJzcDtzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCZuYnNwO2NvdmVy cyBTRCZuYnNwO25vDQo8L2ZvbnQ+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3VuIEdv dGhpYycsJ3NlcmlmJyI+bWF0dGVyIHdoYXQga2luZCBvZiBTRCBkZXRlY3Rpb24gbWV0aG9kcyZu YnNwO3Nob3VkIGJlJm5ic3A7dXNlZC4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij5CeSB0aGUgd2F5LCB0aGlzIGRyYWZ0IGRvZXMgbm90IGhhdmUgYSB3b3Jk ICZxdW90O2Fnbm9zdGljJnF1b3Q7LjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkJlc3QgcmVn YXJkcyw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4N CjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5KZW9uZy1kb25nPC9kaXY+DQo8ZGl2IHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+ PGJyPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+DQo8aHIg dGFiaW5kZXg9Ii0xIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxi PkZyb20gOiA8L2I+JnF1b3Q7UWluIFd1JnF1b3Q7ICZsdDtiaWxsLnd1QGh1YXdlaS5jb20mZ3Q7 PGJyPg0KPGI+U2VudCA6IDwvYj4yMDEzLTEyLTMwIDEyOjQ4OjI3ICggJiM0MzswOTowMCApPGJy Pg0KPGI+VG8gOiA8L2I+UnlvbywgSmVvbmctZG9uZyAmbHQ7cnlvb0BldHJpLnJlLmtyJmd0Oywg WWFhY292IFdlaW5nYXJ0ZW4gJmx0O3d5YWFjb3ZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjIDog PC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7LCBkcmFmdC1pZXRmLW1wbHMt dHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVA dG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5SRTogW21wbHNdIFF1ZXN0 aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9uIGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1 PGJyPg0KPGJyPg0KPC9kaXY+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jv c29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT52XDoqIHsKCUJFSEFWSU9S OiB1cmwoI2RlZmF1bHQjVk1MKQp9Cm9cOiogewoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwp Cn0Kd1w6KiB7CglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkKfQouc2hhcGUgewoJQkVIQVZJ T1I6IHVybCgjZGVmYXVsdCNWTUwpCn0KPC9zdHlsZT48c3R5bGU+QGZvbnQtZmFjZSB7Cglmb250 LWZhbWlseTog5a6L5L2TOwp9CkBmb250LWZhY2UgewoJZm9udC1mYW1pbHk6IENhbWJyaWEgTWF0 aDsKfQpAZm9udC1mYWNlIHsKCWZvbnQtZmFtaWx5OiBDYWxpYnJpOwp9CkBmb250LWZhY2UgewoJ Zm9udC1mYW1pbHk6IFRhaG9tYTsKfQpAZm9udC1mYWNlIHsKCWZvbnQtZmFtaWx5OiBA5a6L5L2T Owp9CkBmb250LWZhY2UgewoJZm9udC1mYW1pbHk6IE1hbGd1biBHb3RoaWM7Cn0KQGZvbnQtZmFj ZSB7Cglmb250LWZhbWlseTog66eR7J2A6rOg65SVOwp9CkBmb250LWZhY2UgewoJZm9udC1mYW1p bHk6IEBNYWxndW4gR290aGljOwp9CkBmb250LWZhY2UgewoJZm9udC1mYW1pbHk6IEDrp5HsnYDq s6DrlJU7Cn0KQHBhZ2UgV29yZFNlY3Rpb24xIHtzaXplOiA2MTIuMHB0IDc5Mi4wcHQ7IG1hcmdp bjogNzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0OyB9ClAuTXNvTm9ybWFsIHsKCU1BUkdJTjog MGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOyBGT05U LVNJWkU6IDEycHQKfQpMSS5Nc29Ob3JtYWwgewoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1G QU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7IEZPTlQtU0laRTogMTJwdAp9CkRJVi5N c29Ob3JtYWwgewoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7IEZPTlQtU0laRTogMTJwdAp9CkE6bGluayB7CglDT0xPUjogYmx1ZTsg VEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IG1zby1zdHlsZS1wcmlvcml0eTogOTkKfQpTUEFO Lk1zb0h5cGVybGluayB7CglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7 IG1zby1zdHlsZS1wcmlvcml0eTogOTkKfQpBOnZpc2l0ZWQgewoJQ09MT1I6IHB1cnBsZTsgVEVY VC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IG1zby1zdHlsZS1wcmlvcml0eTogOTkKfQpTUEFOLk1z b0h5cGVybGlua0ZvbGxvd2VkIHsKCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5Cn0KUCB7CglNQVJHSU46IDBjbSAwY20gMHB0 OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgRk9OVC1TSVpFOiAxMnB0 OyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5Cn0KU1BBTi5FbWFpbFN0eWxlMTggewoJRk9OVC1GQU1J TFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IENPTE9SOiAjMWY0OTdkOyBtc28tc3R5bGUtdHlw ZTogcGVyc29uYWwtcmVwbHkKfQouTXNvQ2hwRGVmYXVsdCB7CglGT05ULVNJWkU6IDEwcHQ7IG1z by1zdHlsZS10eXBlOiBleHBvcnQtb25seQp9CkRJVi5Xb3JkU2VjdGlvbjEgewoJcGFnZTogV29y ZFNlY3Rpb24xCn0KPC9zdHlsZT4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0la RTogMTFwdCI+U29ycnkgdG8gaW50ZXJydXB0IGluLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7 IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkkgYW0gYSBsaXR0bGUgYml0IHN1cnBy aXNlZCB0aGlzIGRyYWZ0IGhhcyBub3QgYW55IHJlZmVyZW5jZSB0byBJVFUgZG9jdW1lbnQuPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+ SSBhbSB3b25kZXJpbmcgaG93IG11Y2ggdGhpcyBkcmFmdCBpcyBjb21wbGlhbnQgd2l0aCBHLjgw MzE/IElzIHRoZXJlIGFueSB0d2VhayBvciBvcHRpbWl6YXRpb24gdG8gRy44MzE/PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGli cmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+V2hhdCBp cyB0aGUgY29uY2VybiBvZiBHLjgzMSB0aGlzIGRyYWZ0IGlzIGRlYWxpbmcgd2l0aD88L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2Fs aWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5JZiBh bnl0aGluZyBpcyBmcm9tIEcuODMxIG9yIGFueSBvdGhlciBJVFUgZG9jdW1lbnQsIEkgdGhpbmsg aXQgaXMgZmluZSwgaG93ZXZlciBHLjgzMSBvciBzb21lIG90aGVyIElUVSBkb2N1bWVudHMgYXJl IHdvcnRoIGJlaW5nIHJlZmVyZW5jZWQuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFw dCI+SWYgdGhpcyBkcmFmdCBpcyBmb2N1c2luZyBvbiBhZGRyZXNzaW5nIEcuODMxLCBpdCBpcyBi ZXR0ZXIgdG8gY2xhcmlmeSB0aGlzIGEgbGl0dGxlIGJpdCBpbiB0aGlzIGRyYWZ0Ljwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9S OiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPk15IGZlZWxpbmcgaXMgdGhpcyBkcmFmdCBzZWVt cyB0byBpbnRyb2R1Y2UgY29tYmluYXRpb24gb2YgMSYjNDM7MSBhbmQgMToxIHByb3RlY3Rpb24g YXJjaGl0ZWN0dXJlIHdoZW4gSSByZWFkPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6 ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+4oCcPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3VuIEdvdGhpYycsJ3NlcmlmJyI+QXMgeW91IG1p Z2h0IHJlY2FsbCBmcm9tIEcuODAzMQ0KPC9zcGFuPuKAkzxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPiBFdGhlcm5ldCBsaW5lYXIgcHJvdGVjdGlvbiwg dGhlIHNlbGVjdG9yIGJyaWRnZSBpcyBub3QgcmVjb21tZW5kZWQgZHVlIHRvIHRoZSB0cmFmZmlj IGZsYXBwaW5nIHVuZGVyIFNEIGNvbmRpdGlvbnMgb24gYm90aCBwYXRocy4gSW5zdGVhZA0KPC9z cGFuPuKAnDxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZici PmJyb2FkY2FzdCBicmlkZ2U8L3NwYW4+4oCdPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFs Z3VuIEdvdGhpYycsJ3NlcmlmJyI+IGlzIGludHJvZHVjZWQgdG8gc3VwcG9ydCBwcm90ZWN0aW9u IHN3aXRjaGluZyBhZ2FpbnN0IFNELiBCdXQsIHRoaXMgYnJvYWRjYXN0IGJyaWRnZSBpcyBub3Qg cmVjb21tZW5kZWQgaW4gbm9uLXJldmVydGl2ZSBtb2RlDQogYXMgdGhlIHdvcmtpbmcgcGF0aCBu ZWVkcyB0byBiZSBvY2N1cGllZCBieSB0cmFmZmljIGFsbCB0aGUgdGltZS4gQWxzbyB0aGUgYnJv YWRjYXN0IGJyaWRnZSBpcyBub3QgZWZmaWNpZW50LCBzaW5jZSBieSBkZWZpbml0aW9uLCB0aGUg cGFja2V0IGR1cGxpY2F0aW9uIHNob3VsZCBvY2N1ciBkdXJpbmcgbm90IG9ubHkgU0QgYnV0IGFs c28gU0YsIEZTLCBNUywgZXRjLiBJbiB0aGlzIGRvY3VtZW50LCB3ZSBhcmUgaW50cm9kdWNpbmcg YW4gaW1wcm92ZWQNCiBicmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhhdmVzIGxpa2UgYSBzZWxl Y3RvciBicmlkZ2UgYnV0IGR1cGxpY2F0ZXMgdGhlIHRyYWZmaWMgb25seTwvc3Bhbj4mbmJzcDs8 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj51bmRlciBT RCBjb25kaXRpb24sIGFuZCB3ZSBiZWxpZXZlIHRoYXQgaXQgYWRkcmVzc2VzIGFsbCB0aGUgaXNz dWVzIHdpdGggZXhpc3RpbmcgYnJpZGdlcy4NCjwvc3Bhbj4NCjw/eG1sOm5hbWVzcGFjZSBwcmVm aXggPSBvIG5zID0gInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgLz4N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMt c2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij7igJ0sDQo8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5JIHRlbmQg dG8gYWdyZWUgWWFjY292IHRoYXQgU0QgcHJvdGVjdGlvbiBpcyBub3QgYWdub3N0aWMgdG8gdGhl IG1ldGhvZCB1c2VkIGZvciB0aGUgZGV0ZWN0aW9uLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7 IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkFsc28gSSBhbSBpbnRlcmVzdGVkIHRv IGtub3cgaG93IHRvIHBvc2l0aW9uIGJyaWRnZSBhbmQgc2VsZWN0b3IgaW4gdGhlIE1QTFMgYXJj aGl0ZWN0dXJlPzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywn c2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPlJlZ2FyZHMhPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+ LVFpbjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRp dW0gbm9uZTsgUEFERElORy1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiAwY207IFBBRERJTkct UklHSFQ6IDBjbTsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDog bWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IEZPTlQtU0la RTogMTBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9t YScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPm1wbHMgW21haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJ5b28sIEplb25nLWRvbmc8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDI2LCAyMDEzIDEyOjUxIFBNPGJyPg0KPGI+ VG86PC9iPiBZYWFjb3YgV2VpbmdhcnRlbjxicj4NCjxiPkNjOjwvYj4gbXBsc0BpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFttcGxzXSBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dTwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJlekZvcm1Qcm9j X2RpdiI+DQo8ZGl2IGlkPSJtc2dib2R5Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj5ZYWFjb3YsIHRo YW5rcyBmb3IgeW91ciBlbWFpbC48L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnTWFsZ3VuIEdvdGhpYycsJ3NlcmlmJyI+U29tZWhvdywgSSBmb3Jnb3QgdG8gcmVzcG9uZCBh bmQgYW0gc29ycnkgZm9yIHRoZQ0KIGRlbGF5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7 IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPkZpcnN0IG9mIGFsbCwgWWFhY292LCBp dCBpcyBub3QgdHJ1ZSB0aGF0IHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBvZiBFdGhlcm5ldCBv ciBTREggZGVzY3JpYmVzIHRoZSBvcGVyYXRpb24gb2YgYW55IGxheWVyIGJlbG93LiBSYXRoZXIs DQogZWFjaCBsYXllciBpcyBzdXBwb3NlZCB0byBvcGVyYXRlIGluZGVwZW5kZW50bHkuIEhvd2V2 ZXIsIHRoZXJlIGFyZSBhIGZldyBleGNlcHRpb25zLCBzdWNoIGFzIGhvbGQtb2ZmIHRpbWVyIGFu ZCBBSVMgKGFzIGEgdHJpZ2dlciBmcm9tIGxvd2VyIGxheWVyKS4gRXZlbiB0aG91Z2ggdGhlcmUg ZXhpc3Qgc29tZSBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbnMgdGhhdCB1c2Ugb3RoZXIgaW5m b3JtYXRpb24gZnJvbSBsb3dlciBsYXllciwgbW9zdA0KIG9mIHRoZW0gYXJlIG5vdCByZWNvbW1l bmRlZCBpbiBJVFUtVCBzdGFuZGFyZHMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1B UkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZB TUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPkJyaWRnZSBhbmQgc2VsZWN0b3IgYXJlIG5v dCBpbiB0aGUgcGh5c2ljYWwgbGF5ZXIsIGJ1dCB0aGV5IGFyZSBwYXJ0IG9mIHByb3RlY3Rpb24g c3dpdGNoaW5nLiBPbmUgb2YgdGhlIGltcG9ydGFudCBvdXRwdXQgYWN0aW9ucyBmcm9tIHRoZQ0K IFBTQyBjb250cm9sIGxvZ2ljIGlzIGNvb3JkaW5hdGluZyB0aGUgcG9zaXRpb25zIG9mIGJyaWRn ZSBhbmQgc2VsZWN0b3IuIEFsc28sIHRoZSBicmlkZ2Ugb3BlcmF0aW9uIHJlc3BvbmRpbmcgdG8g dGhlIFBTQyBjb250cm9sIGxvZ2ljIGlzIGFsc28gcGFydCBvZiBwcm90ZWN0aW9uIHN3aXRjaGlu Zy4gSG93ZXZlciwgaG93IHRvIHJlYWxpemUgdGhlIGJyaWRnZSBhbmQgc2VsZWN0b3IgKGZvciBl eGFtcGxlLCBob3cgdG8gbWFuaXB1bGF0ZSBhIHBhY2tldA0KIGZvcndhcmRpbmcgbWVjaGFuaXNt KSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPldoZW4gd2UgbWVudGlvbiAxJiM0 MzsxIG9yIDE6MSBpbiBwcm90ZWN0aW9uIGFyY2hpdGVjdHVyZSwgd2UgZGVhbCB3aXRoIHRoZSBv cGVyYXRpb24gb2YgYnJpZGdlLiBGb3IgMSYjNDM7MSBhcmNoaXRlY3R1cmUsIHRoZSB0cmFmZmlj IG5lZWRzIHRvIGJlDQogZHVwbGljYXRlZCBhdCB0aGUgc2VuZGVyIGFuZCBzZW50IHRvIGJvdGgg cGF0aHMgYWxsIHRoZSB0aW1lLCB3aGljaCBpcyB0aGUgc2FtZSBkZXNjcmlwdGlvbiBhcyB0aGUN Cjwvc3Bhbj7igJw8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2Vy aWYnIj5wZXJtYW5lbnQgYnJpZGdlPC9zcGFuPuKAnTxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J01hbGd1biBHb3RoaWMnLCdzZXJpZiciPi4gRm9yIDE6MSBhcmNoaXRlY3R1cmUsDQo8L3NwYW4+ 4oCcPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3VuIEdvdGhpYycsJ3NlcmlmJyI+c2Vs ZWN0b3IgYnJpZGdlPC9zcGFuPuKAnTxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBH b3RoaWMnLCdzZXJpZiciPiBpcyB1c2VkIHRvIHNlbmQgdGhlIHRyYWZmaWMgb25seSBvbmUgb2Yg dGhlIHBhdGhzLiBBcyB0aGUgcHJvdGVjdGlvbiBwYXRoIGNhbiBiZSB1c2VkIGJ5PC9zcGFuPiZu YnNwOzxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPmJl c3QNCiB0cmFmZmljIGluIHBhY2tldCBuZXR3b3JrcyBhbmQgdGhlIHBhY2tldCBkdXBsaWNhdGlv biB0YWtlcyBtdWNoIG1vcmUgZWZmb3J0L2ludGVybmFsIGJhbmR3aWR0aCBpbnNpZGUgYSBzd2l0 Y2ggdGhhbiB0aGUgdGltZSBzbG90IGNvcHkgb2YgY2lyY3VpdCBuZXR3b3Jrcy4gMToxIGlzIGNv bnNpZGVyZWQgYXMgcHJlZmVyYWJsZSBhcmNoaXRlY3R1cmUgaW4gcGFja2V0IG5ldHdvcmtzLg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJH SU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3VuIEdvdGhpYycsJ3Nl cmlmJyI+QXMgeW91IG1pZ2h0IHJlY2FsbCBmcm9tIEcuODAzMQ0KPC9zcGFuPuKAkzxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPiBFdGhlcm5ldCBsaW5l YXIgcHJvdGVjdGlvbiwgdGhlIHNlbGVjdG9yIGJyaWRnZSBpcyBub3QgcmVjb21tZW5kZWQgZHVl IHRvIHRoZSB0cmFmZmljIGZsYXBwaW5nIHVuZGVyIFNEIGNvbmRpdGlvbnMgb24gYm90aCBwYXRo cy4gSW5zdGVhZA0KPC9zcGFuPuKAnDxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBH b3RoaWMnLCdzZXJpZiciPmJyb2FkY2FzdCBicmlkZ2U8L3NwYW4+4oCdPHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnTWFsZ3VuIEdvdGhpYycsJ3NlcmlmJyI+IGlzIGludHJvZHVjZWQgdG8gc3Vw cG9ydCBwcm90ZWN0aW9uIHN3aXRjaGluZyBhZ2FpbnN0IFNELiBCdXQsIHRoaXMgYnJvYWRjYXN0 IGJyaWRnZSBpcyBub3QgcmVjb21tZW5kZWQgaW4gbm9uLXJldmVydGl2ZSBtb2RlDQogYXMgdGhl IHdvcmtpbmcgcGF0aCBuZWVkcyB0byBiZSBvY2N1cGllZCBieSB0cmFmZmljIGFsbCB0aGUgdGlt ZS4gQWxzbyB0aGUgYnJvYWRjYXN0IGJyaWRnZSBpcyBub3QgZWZmaWNpZW50LCBzaW5jZSBieSBk ZWZpbml0aW9uLCB0aGUgcGFja2V0IGR1cGxpY2F0aW9uIHNob3VsZCBvY2N1ciBkdXJpbmcgbm90 IG9ubHkgU0QgYnV0IGFsc28gU0YsIEZTLCBNUywgZXRjLiBJbiB0aGlzIGRvY3VtZW50LCB3ZSBh cmUgaW50cm9kdWNpbmcgYW4gaW1wcm92ZWQNCiBicmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhh dmVzIGxpa2UgYSBzZWxlY3RvciBicmlkZ2UgYnV0IGR1cGxpY2F0ZXMgdGhlIHRyYWZmaWMgb25s eTwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywn c2VyaWYnIj51bmRlciBTRCBjb25kaXRpb24sIGFuZCB3ZSBiZWxpZXZlIHRoYXQgaXQgYWRkcmVz c2VzIGFsbCB0aGUgaXNzdWVzIHdpdGggZXhpc3RpbmcgYnJpZGdlcy4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBw dCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPldoYXQgd2Ug bWVhbiBieSBTRCBwcm90ZWN0aW9uIGlzIGFnbm9zdGljIHRvIHRoZSBTRCBkZXRlY3Rpb24gbWV0 aG9kIGlzIHRoYXQgdGhlIHByb3Bvc2VkIFNEIHByb3RlY3Rpb24gbWV0aG9kIChhZ2FpbiBob3cg dG8gb3BlcmF0ZSBhIGJyaWRnZQ0KIG9yIHdoYXQ8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnTWFsZ3VuIEdvdGhpYycsJ3NlcmlmJyI+YnJpZ2UgaXMgdXNlZCBpcyBhIHBh cnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcpIGNhbiBiZSB1c2VkIG5vIG1hdHRlciB3aGF0IGtp bmQgb2YgU0QgZGV0ZWN0aW9uIG1ldGhvZHMgKGRhdGEgcGFja2V0IGNvdW50aW5nLCBDQ00gcGFj a2V0IGNvdW50aW5nLCBvciBldmVuIHByb3ByaWV0YXJ5IHNlcnZlciBsYXllciBTRCBkZXRlY3Rp b24pDQogaXMgdXNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9N OiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxn dW4gR290aGljJywnc2VyaWYnIj5JIHRoaW5rIEkgYW5zd2VyZWQgYWxsIHRoZSBxdWVzdGlvbnMg b24geW91ciBlbWFpbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9N OiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxn dW4gR290aGljJywnc2VyaWYnIj5ZYWFjb3YsIGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbmNl cm5zIG9yIHF1ZXN0aW9ucywgcGxlYXNlIGxldCBtZSBrbm93Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPkJlc3QgcmVnYXJkcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJ Ti1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2Vy aWYnIj5KZW9uZy1kb25nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMnB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 L3A+DQo8ZGl2IGlkPSJNYWlsU2lnblNlbnRTZW50Ij4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJU RVhULUFMSUdOOiBjZW50ZXI7IExJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0iY2VudGVyIj4NCjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1z ZXJpZic7IEZPTlQtU0laRTogMTBwdCI+DQo8aHIgYWxpZ249ImNlbnRlciIgc2l6ZT0iMiIgd2lk dGg9IjEwMCUiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBN QVJHSU4tQk9UVE9NOiAxMnB0IiBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPkZyb20gOg0K PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYn OyBGT05ULVNJWkU6IDEwcHQiPiZxdW90O1lhYWNvdiBXZWluZ2FydGVuJnF1b3Q7ICZsdDt3eWFh Y292QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMtMTItMTAgMTY6MDQ6MTcg KCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5SeW9vLCBKZW9uZy1kb25nICZsdDtyeW9v QGV0cmkucmUua3ImZ3Q7PGJyPg0KPGI+Q2MgOiA8L2I+ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1p dHVAdG9vbHMuaWV0Zi5vcmcgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmll dGYub3JnJmd0OywgbXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0IDogPC9iPlJlOiBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dTwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPkplb25nLWRvbmcsIGhpDQo8 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlh bCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPlRoYW5rIHlvdSBmb3IgeW91ciByZXBs eS4gWW91ciBhbnN3ZXIgc2VlbXMgdG8gYmUgYW4gYXBwcm9wcmlhdGUgYW5zd2VyIGZvciBvdGhl ciBTRE9zLCBub3Qgc3VyZSB0aGF0IGl0IGlzIHRydWUgZm9yIHRoZSBjb250ZXh0IG9mIE1QTFMg YW5kIElFVEYNCiB3b3JrLjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0 Ij4xLiBZb3Ugd3JvdGUgJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ+un keydgOqzoOuUlScsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5hbnkgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcgKGluY2x1ZGluZyBQU0MpIGlzIHN1cHBvc2VkIHRvIGRlc2NyaWJlDQogdGhlIG9wZXJh dGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiZxdW90OyAtIDwvc3Bhbj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPnRoaXMg bWF5IGJlIHRydWUgZm9yIEV0aGVybmV0IGFuZDwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6 IDEwcHQiPlNESA0KIGFuZCBmb3IgZG9jdW1lbnRzIHRoYXQgYXJlIGRlc2NyaWJpbmcgdGhlIG9w ZXJhdGlvbiBvZiB0aGUgcGh5c2ljYWwgbGF5ZXIuIEhvd2V2ZXIsIHRoZSBJRVRGICh0byBteSB1 bmRlcnN0YW5kaW5nIC0gYW5kIEkgYW0gY2VydGFpbmx5IHdpbGxpbmcgdG8gYmUgY29ycmVjdGVk IG9uIHRoaXMgcG9pbnQpIGlzIGNvbmNlcm5lZCB3aXRoIHRoZSBwcm90b2NvbCBhbmQgbGVhdmUg dGhlIGxvd2VyIGxheWVycyB0byBpbXBsZW1lbnRhdGlvbi4gQWxzbywNCiBJIGFtIG5vdCBzdXJl IHRoYXQgdGhlIGNvbmNlcHRzIG9mIEJyaWRnZSBhbmQgU2VsZWN0b3IgcmVhbGx5IGFwcGx5IHRv IE1QTFMgKGFsdGhvdWdoIEkgYWRtaXQgdGhhdCB3ZSBkaWQgbWVudGlvbiB0aGVtIGluIHRoZSBv cmlnaW5hbCBQU0MgZGVmaW5pdGlvbikuPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJ WkU6IDEwcHQiPjIuIFlvdSBjaXRlIHdoYXQgd2FzIHdyaXR0ZW4gaW4gRzgwMzEgYXMganVzdGlm aWNhdGlvbiBmb3IgaW5jbHVkaW5nIGNvbnRlbnQgaW50byB5b3VyIGRyYWZ0LiBBZ2FpbiBpdCBp cyBoYXJkIHRvIHRyYW5zZmVyIG1ldGhvZG9sb2d5IGZyb20gb25lIFNETw0KIHRvIGFub3RoZXIg YW5kIHRoZXJlZm9yZSwgd2hpbGUgSSBoaWdobHkgcmVzcGVjdCB0aGUgd29yayBvZiB0aGUgSVRV LCBJIGRvIG5vdCBmZWVsIHRoYXQgdGhpcyBpcyBhIHZlcnkgY2xlYXIganVzdGlmaWNhdGlvbiBm b3IgaW5jbHVzaW9uIGludG8gYW4gaW50ZXJuZXQtZHJhZnQuIEV2ZW4gd2hlbiB0aGUgZHJhZnQg c3RhdGVzIHRoYXQgaXRzIHB1cnBvc2UgaXMgdG8gYWRkcmVzcyB0aGUgY29uY2VybnMgb2YgdGhl IElUVS48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+My4gVG8gdGhl IGFjdHVhbCBwb2ludCBvZiBteSBlYXJsaWVyIGNvbW1lbnQsIHRoYXQgeW91IGRvIG5vdCBzZWVt IHRvIGFkZHJlc3MgLSB0aGUgcGFyYWdyYXBoIGluIFNlY3Rpb24gNy4zIHNlZW1zIHRvIHN0YXRl IHRoYXQgU0QgcHJvdGVjdGlvbiBjaGFuZ2VzDQogYWNjb3JkaW5nIHRvIHRoZSBtZXRob2QgdGhh dCBpcyB1c2VkIHRvIGRldGVjdCB0aGUgU0QuIFRoaXMgbWVhbnMgdGhhdCBTRCBwcm90ZWN0aW9u IGlzIG5vdCBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoZSBkZXRlY3Rpb24uPC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNl cmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5BbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCBicmVhayB0aGlz IGRlcGVuZGVuY2UgYW5kIHN0YXRlIHRoYXQgU0QgcHJvdGVjdGlvbiBpcyBhbHdheXMgcHJvdmlk ZWQgYnkgY2hhbmdpbmcgdGhlIHRyYW5zbWlzc2lvbiBvZiB0aGUgZGF0YSB0byAxJiM0MzsxIHBy b3RlY3Rpb24NCiBpbiBjYXNlcyBvZiBTRCBkZXRlY3Rpb24sIHdoaWNoIGlzIHdoYXQgdGhlIHBh cmFncmFwaCBpcyBzdWdnZXN0aW5nIHRvIGRvIGZvciBzb21lIGNhc2VzLjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdz YW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5JIGhvcGUgdGhpcyBmb3JtdWxhdGlvbiBtYWtl IG15IGNvbW1lbnQgY2xlYXJlciBhbmQgd2UgYXJlIGFibGUgdG8gZGlzY3VzcyB0aGUgdGVjaG5v bG9naWNhbCBhcHByb2FjaCByYXRoZXIgdGhhbiB0aGUgcGhpbG9zb3BoaWNhbCBkaWZmZXJlbmNl cy48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0 IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0i TElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZB TUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+VGhhbmsgeW91LDwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1z ZXJpZic7IEZPTlQtU0laRTogMTBwdCI+eWFhY292PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMnB0 IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdB cmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPk9uIE1vbiwgRGVjIDksIDIwMTMg YXQgMTA6MDQgUE0sIFJ5b28sIEplb25nLWRvbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpyeW9vQGV0 cmkucmUua3IiIHRhcmdldD0iX2JsYW5rIj5yeW9vQGV0cmkucmUua3I8L2E+Jmd0OyB3cm90ZTo8 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0i TElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPllhYWNv diw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1B UkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywn c2VyaWYnIj5ZZXMsIFBTQyBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9k IHVzZWQgZm9yIHRoZSBkZXRlY3Rpb24gb2YgU0YvU0QuDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj5JdCBpcyBhbHNvIHRydWUg dGhhdCBhbnkgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGluY2x1ZGluZyBQU0MpIGlzIHN1cHBvc2Vk IHRvIGRlc2NyaWJlIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGFuZCBzZWxlY3Rvci4NCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJP VFRPTTogMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZici PkFzIHRoZXJlIGFyZSBtdWx0aXBsZSBvcHRpb25zIGZvciBkZXRlY3RpbmcgU0QsIHdlIG5lZWRl ZCB0byBkZXNjcmliZSB0aGUgYmVoYXZpb3Igb2YgdGhlIGJyaWRnZSB0byBjb3ZlciBhbGwgdGhl IHBvc3NpYmxlIGRldGVjdGlvbiBtZXRob2RzLg0KIERlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbiBv ZiBicmlkZ2UgZm9yIFNEIHByb3RlY3Rpb24gaXMgbm90IGEgbmV3IHRoaW5nLiBGb3IgZXhhbXBs ZSwgRy44MDMxIC0gRXRoZXJuZXQgbGluZWFyIHByb3RlY3Rpb24gYWxzbyBkZXNjcmliZXMgd2hh dDwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywn c2VyaWYnIj5icmlkZ2UgY2FuPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J01hbGd1biBHb3RoaWMnLCdzZXJpZiciPmJlDQogdXNlZCBpbiBvcmRlciB0byBwcm92aWRlIHBy b3RlY3Rpb24gYWdhaW5zdCBTRC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lO LUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnTWFsZ3VuIEdvdGhpYycsJ3NlcmlmJyI+QmVzdCByZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPkplb25nLWRvbmc8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJ Ti1CT1RUT006IDEycHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXY+DQo8cCBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVyOyBMSU5FLUhFSUdIVDogMTVwdCIg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPg0KPGhyIGFsaWduPSJj ZW50ZXIiIHNpemU9IjIiIHdpZHRoPSIxMDAlIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5Gcm9tIDoNCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsg Rk9OVC1TSVpFOiAxMHB0Ij4mcXVvdDtZYWFjb3YgV2VpbmdhcnRlbiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnd5YWFjb3ZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3lhYWNvdkBnbWFp bC5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAxMy0xMi0wOCAyMDowMTo1NSAoICYj NDM7MDk6MDAgKTxicj4NCjxiPlRvIDogPC9iPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1w bHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYt bXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0OywNCjxhIGhy ZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwv YT4gJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBs c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2MgOiA8L2I+PGJyPg0KPGI+U3ViamVjdCA6IDwv Yj5RdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAt cHNjLWl0dSA8L3NwYW4+DQo8L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTJwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9w Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpF OiAxMHB0Ij5IaSwNCjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+QWZ0ZXIgcmVh ZGluZyB0aHJvdWdoIHlvdXIgZHJhZnQgb24gdGhlIGV4dGVuc2lvbnMgdG8gUFNDIHRvIHN1cHBv cnQgU0Qgc2l0dWF0aW9ucywgSSBoYXZlIGEgcXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb24gLTwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1z ZXJpZic7IEZPTlQtU0laRTogMTBwdCI+SW4geW91ciBpbnRyb2R1Y3Rpb24gLSB5b3Ugc3RhdGUg dGhhdCB0aGUgbWV0aG9kIHVzZWQgdG8gZGV0ZWN0IFNEIHNpdHVhdGlvbnMgaXMgb3V0LW9mLXNj b3BlIG9mIHRoZSBkb2N1bWVudC4gRG9lcyB0aGlzIG1lYW4gdGhhdCBQU0MgaXMgc3VwcG9zZWQN CiB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoaXMgZGV0ZWN0aW9uPyBJ dCBzaG91bGQgcmVhY3Qgb25seSB0byB0aGUgaW5kaWNhdGlvbiwgc2ltaWxhcmx5IHRvIHRoZSBy ZWFjdGlvbiBhbmQgcmVsYXRpb25zaGlwIHRvIHRoZSBtZXRob2QgZm9yIGRldGVjdGluZyBhbmQg ZGVjbGFyaW5nIGEgU0Ygc2l0dWF0aW9uLjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+SG93ZXZl ciwgd2hlbiB5b3UgZXhwbGFpbiB0aGUgYmVoYXZpb3Igb2YgdGhlIFNEIHByb3RlY3Rpb24gaW4g c2VjdGlvbiA3LjMgeW91IGhhdmUgYSBwYXJhZ3JhcGggdGhhdCBzdGFydHMgd2l0aCAmcXVvdDtJ ZiB0aGUgZGV0ZWN0aW9uIG9mIGEgU0QgZGVwZW5kcw0KIG9uIHRoZSBwcmVzZW5jZSBvZiB1c2Vy IGRhdGEgcGFja2V0cyAuLi4mcXVvdDsgJm5ic3A7dGhhdCBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0 IHRoZSBiZWhhdmlvciBvZiB0aGUgc3lzdGVtIGlzIGRlcGVuZGVudCB1cG9uIHRoZSBkZXRlY3Rp b24gbWV0aG9kISBDbGFyaWZpY2F0aW9uIHdvdWxkIGJlIGFwcHJlY2lhdGVkLiZuYnNwOw0KPC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMt c2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPi0tDQo8L3NwYW4+PC9wPg0KPGRpdj4NCjxwIHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5UaGFueCBhbmQg QlIsDQo8L3NwYW4+PC9wPg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNl cmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij55YWFjb3Y8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7 IEZPTlQtU0laRTogMTBwdCI+U3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5PC9zcGFu PjwvaT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+PGJyPg0KPGJy IGNsZWFyPSJhbGwiPg0KPC9zcGFuPiZuYnNwOzwvcD4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPHAgc3R5 bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPi0tDQo8L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9O VC1TSVpFOiAxMHB0Ij5UaGFueCBhbmQgQlIsDQo8L3NwYW4+PC9wPg0KPGRpdj4NCjxwIHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij55YWFjb3Y8L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+U3RpbGwgbG9va2luZyBm b3IgbmV3IG9wcG9ydHVuaXR5PC9zcGFuPjwvaT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF30DSMTP2etriinfo_-- From bill.wu@huawei.com Sun Dec 29 23:14:38 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 A6A581AE407 for ; Sun, 29 Dec 2013 23:14:38 -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 8qKD3eAgnzHk for ; Sun, 29 Dec 2013 23:14:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE281AE2C0 for ; Sun, 29 Dec 2013 23:14:30 -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 AZM12651; Mon, 30 Dec 2013 07:14:23 +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; Mon, 30 Dec 2013 07:14:17 +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; Mon, 30 Dec 2013 07:14:21 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 30 Dec 2013 15:14:15 +0800 From: Qin Wu To: "Ryoo, Jeong-dong" , Yaacov Weingarten Thread-Topic: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHO9ATofTfzY1WrTkK6rDh0YabjsJpMSsLJgAAiYoCAGZTyhIAGNmeQ//+W2ICAAJwGwA== Date: Mon, 30 Dec 2013 07:14:15 +0000 Message-ID: References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AF30D@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AF30D@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_B8F9A780D330094D99AF023C5877DABA43C6F481nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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: Mon, 30 Dec 2013 07:14:38 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C6F481nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmVvbmctZG9uZzoNClRoYW5rIGZvciB5b3VyIGNsYXJpZmljYXRpb24uDQoNClRoZSB0aXRs ZSBvZiB5b3VyIGRyYWZ0IGlzIOKAnE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApIExp bmVhciBQcm90ZWN0aW9uIGluIFN1cHBvcnQgb2YgSVRVLVQncyBSZXF1aXJlbWVudHPigJ0NCg0K SXQgaXMgb2J2aW91cyB5b3VyIGRyYWZ0IGlzIGNvbXBsaWFudCB3aXRoIFJGQzYzNzguDQoNCkhv d2V2ZXIgSSBhbSB3b25kZXJpbmcgd2hhdCBJVFUtVOKAmXMgcmVxdWlyZW1lbnRzIGFyZT8gQXJl IHRoZXNlIHJlcXVpcmVtZW50cyBmcm9tIElUVS1UIGRvY3VtZW50IEcuODAzMSBvciBzb21lIG90 aGVyIElUVS1UIGRvY3VtZW50cz8NCg0KRnJvbSB0aGlzIHBlcnNwZWN0aXZlLCBJIHRoaW5rIG9u ZSBJVFUtVCBkb2N1bWVudCBkZXNjcmliaW5nIHRoZXNlIHJlcXVpcmVtZW50cyBuZWVkcyB0byBt ZW50aW9uZWQgaW4gdGhpcyBkcmFmdCwgZS5nLiwgaW4gdGhlIGludHJvZHVjdGlvbiBzZWN0aW9u Pw0KDQoNCg0KRm9yIGFnbm9zdGljIGlzc3VlLCBJIHRoaW5rIHRoaXMgaXNzdWUgaXMgYXBwbGll ZCB0byBzZWN0aW9uIDcuMywgYXMgeW91IGNsYXJpZmllZCBlYXJsaWVyLCB0aGUgc2VsZWN0b3Ig aXMgbm90IHJlYWxseSBicmlkZ2Ugc2VsZWN0b3IgYnV0IG9wdGltaXplZCBicmlkZ2Ugc2VsZWN0 b3IuDQoNCkkgYW0gd29uZGVyaW5nIHdoZXRoZXIgaXQgaXMgY29tYmluYXRpb24gb2YgcGVybWFu ZW50IGJyaWRnZSBhbmQgc2VsZWN0b3IgYnJpZGdlIChUd28gdGVybXMgYXJlIGRlZmluZWQgaW4g UkZDNjM3OCkuDQoNCklmIGl0IGlzLCBteSBxdWVzdGlvbiBpcyBjYW4gd2UgYXBwbHkgMToxIHBy b3RlY3Rpb24gYXJjaGl0ZWN0dXJlIGFuZCAxKzEgcHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUgdG8g bGluZWFyIHByb3RlY3Rpb24gbWVjaGFuaXNtIGF0IHRoZSBzYW1lIHRpbWUgb3INCg0KV2Ugc2hv dWxkIHVzZSB0aGVzZSBwZXJtYW5lbnQgYnJpZGdlIGFuZCBzZWxlY3RvciBicmlkZ2Ugc2VwYXJh dGVseT8NCg0KUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZyBvciBtaXNzIHNvbWV0aGlu Zy4NCg0KDQpSZWdhcmRzIQ0KLVFpbg0KRnJvbTogUnlvbywgSmVvbmctZG9uZyBbbWFpbHRvOnJ5 b29AZXRyaS5yZS5rcl0NClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMzAsIDIwMTMgMToyMCBQTQ0K VG86IFFpbiBXdTsgWWFhY292IFdlaW5nYXJ0ZW4NCkNjOiBtcGxzQGlldGYub3JnOyBkcmFmdC1p ZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFttcGxzXSBR dWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNj LWl0dQ0KDQpRaW4sDQoNClRoaXMgZHJhZnQgaXMgYmFzZWQgb24gUkZDNjM3OCBmb3IgdGhlIHBy b3RvY29sIG1lc3NhZ2UgZm9ybWF0IGFuZCB0aGUgYmFzaWMgb3BlcmF0aW9uYWwgcHJpY2lwbGVz LCB3aGljaCBhcmUgZGlmZmVyZW50IGZyb20gRy44MDMxLg0KVGhlIGludGVudGlvbiBvZiB0aGlz IGRyYWZ0IGlzIHRvIG1ha2UgUkZDNjM3OCBiZSBhbGlnbmVkIHdpdGggRy44MDMxIChvciBvdGhl ciBJVFUgcHJvdGVjdGlvbiB0ZWNobm9sb2dpZXMpIGluIHRoZSBhc3BlY3RzIG9mICJuZXR3b3Jr IG9wZXJhdGlvbiIuIEluIG90aGVyIHdvcmRzLCBpdCBsb29rcyBsaWtlIEcuODAzMSAob3Igb3Ro ZXIgSVRVIHByb3RlY3Rpb24gdGVjaG5vbG9naWVzKSB0byB0aGUgbmV0d29yayBvcGVyYXRvcnMs IGJ1dCB0aGUgYWN0dWFsIHByb3RvY29sIG9wZXJhdGlvbnMgYW5kIHRoZSBiaXRzIG9uIHRoZSB3 aXJlIGFyZSBkaWZmZXJlbnQuDQoNCkkgbWVudGlvbmVkIEcuODAzMSBpbiBteSBwcmV2aW91cyBl bWFpbCB0byBZYWFjb3YganVzdCBmb3IgYmV0dGVyIGV4cGxhbmF0aW9uLCBhbmQgSSBkb24ndCB0 aGluayB0aGlzIGRvY3VtZW50IG5lZWRzIEcuODAzMSBhcyBhIHJlZmVyZW5jZS4NCkJ1dCwgaWYg eW91IGZpbmQgYW55IHBhcnQgaW4gdGhpcyBkb2N1bWVudCB0aGF0IG5lZWRzIGEgcmVmZXJlbmNl IHRvIEcuODAzMSwgcGxlYXNlIGxldCB1cyBrbm93Lg0KDQpZb3UgYW5kIFlhYWNvdiBtaWdodCBi ZSByaWdodCBvbiB0aGUgc2VudGVuY2UgIlNEIHByb3RlY3RvbiBpcyBub3QgYWdub3N0aWMgdG8g dGhlIGRldGVjdGlvbiBtZXRob2QiLg0KQnV0LCBhcyBJIHNhaWQsIG15IG9yaWdpbmFsIGludGVu dGlvbiBhbmQgd2hhdCB3ZSB3YW50ZWQgdG8gYWNoaWV2ZSBpbiB0aGlzIGRvY3VtZW50IGFyZSB0 aGF0IHRoZSBwcm90ZWN0aW9uIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGNvdmVycyBTRCBu byBtYXR0ZXIgd2hhdCBraW5kIG9mIFNEIGRldGVjdGlvbiBtZXRob2RzIHNob3VkIGJlIHVzZWQu DQpCeSB0aGUgd2F5LCB0aGlzIGRyYWZ0IGRvZXMgbm90IGhhdmUgYSB3b3JkICJhZ25vc3RpYyIu DQoNCkJlc3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRnJvbSA6ICJRaW4gV3UiIDxiaWxsLnd1QGh1YXdlaS5jb20+DQpT ZW50IDogMjAxMy0xMi0zMCAxMjo0ODoyNyAoICswOTowMCApDQpUbyA6IFJ5b28sIEplb25nLWRv bmcgPHJ5b29AZXRyaS5yZS5rcj4sIFlhYWNvdiBXZWluZ2FydGVuIDx3eWFhY292QGdtYWlsLmNv bT4NCkNjIDogbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4sIGRyYWZ0LWlldGYtbXBscy10 cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnIDxkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29s cy5pZXRmLm9yZz4NClN1YmplY3QgOiBSRTogW21wbHNdIFF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBw cm90ZWN0aW9uIGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQpTb3JyeSB0byBpbnRlcnJ1 cHQgaW4uDQpJIGFtIGEgbGl0dGxlIGJpdCBzdXJwcmlzZWQgdGhpcyBkcmFmdCBoYXMgbm90IGFu eSByZWZlcmVuY2UgdG8gSVRVIGRvY3VtZW50Lg0KSSBhbSB3b25kZXJpbmcgaG93IG11Y2ggdGhp cyBkcmFmdCBpcyBjb21wbGlhbnQgd2l0aCBHLjgwMzE/IElzIHRoZXJlIGFueSB0d2VhayBvciBv cHRpbWl6YXRpb24gdG8gRy44MzE/DQpXaGF0IGlzIHRoZSBjb25jZXJuIG9mIEcuODMxIHRoaXMg ZHJhZnQgaXMgZGVhbGluZyB3aXRoPw0KSWYgYW55dGhpbmcgaXMgZnJvbSBHLjgzMSBvciBhbnkg b3RoZXIgSVRVIGRvY3VtZW50LCBJIHRoaW5rIGl0IGlzIGZpbmUsIGhvd2V2ZXIgRy44MzEgb3Ig c29tZSBvdGhlciBJVFUgZG9jdW1lbnRzIGFyZSB3b3J0aCBiZWluZyByZWZlcmVuY2VkLg0KDQpJ ZiB0aGlzIGRyYWZ0IGlzIGZvY3VzaW5nIG9uIGFkZHJlc3NpbmcgRy44MzEsIGl0IGlzIGJldHRl ciB0byBjbGFyaWZ5IHRoaXMgYSBsaXR0bGUgYml0IGluIHRoaXMgZHJhZnQuDQoNCk15IGZlZWxp bmcgaXMgdGhpcyBkcmFmdCBzZWVtcyB0byBpbnRyb2R1Y2UgY29tYmluYXRpb24gb2YgMSsxIGFu ZCAxOjEgcHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUgd2hlbiBJIHJlYWQNCuKAnA0KQXMgeW91IG1p Z2h0IHJlY2FsbCBmcm9tIEcuODAzMSDigJMgRXRoZXJuZXQgbGluZWFyIHByb3RlY3Rpb24sIHRo ZSBzZWxlY3RvciBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVkIGR1ZSB0byB0aGUgdHJhZmZpYyBm bGFwcGluZyB1bmRlciBTRCBjb25kaXRpb25zIG9uIGJvdGggcGF0aHMuIEluc3RlYWQg4oCcYnJv YWRjYXN0IGJyaWRnZeKAnSBpcyBpbnRyb2R1Y2VkIHRvIHN1cHBvcnQgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcgYWdhaW5zdCBTRC4gQnV0LCB0aGlzIGJyb2FkY2FzdCBicmlkZ2UgaXMgbm90IHJlY29t bWVuZGVkIGluIG5vbi1yZXZlcnRpdmUgbW9kZSBhcyB0aGUgd29ya2luZyBwYXRoIG5lZWRzIHRv IGJlIG9jY3VwaWVkIGJ5IHRyYWZmaWMgYWxsIHRoZSB0aW1lLiBBbHNvIHRoZSBicm9hZGNhc3Qg YnJpZGdlIGlzIG5vdCBlZmZpY2llbnQsIHNpbmNlIGJ5IGRlZmluaXRpb24sIHRoZSBwYWNrZXQg ZHVwbGljYXRpb24gc2hvdWxkIG9jY3VyIGR1cmluZyBub3Qgb25seSBTRCBidXQgYWxzbyBTRiwg RlMsIE1TLCBldGMuIEluIHRoaXMgZG9jdW1lbnQsIHdlIGFyZSBpbnRyb2R1Y2luZyBhbiBpbXBy b3ZlZCBicmlkZ2UgbWVjaGFuaXNtLCB3aGljaCBiZWhhdmVzIGxpa2UgYSBzZWxlY3RvciBicmlk Z2UgYnV0IGR1cGxpY2F0ZXMgdGhlIHRyYWZmaWMgb25seSB1bmRlciBTRCBjb25kaXRpb24sIGFu ZCB3ZSBiZWxpZXZlIHRoYXQgaXQgYWRkcmVzc2VzIGFsbCB0aGUgaXNzdWVzIHdpdGggZXhpc3Rp bmcgYnJpZGdlcy4NCg0K4oCdLA0KSSB0ZW5kIHRvIGFncmVlIFlhY2NvdiB0aGF0IFNEIHByb3Rl Y3Rpb24gaXMgbm90IGFnbm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhlIGRldGVjdGlv bi4NCkFsc28gSSBhbSBpbnRlcmVzdGVkIHRvIGtub3cgaG93IHRvIHBvc2l0aW9uIGJyaWRnZSBh bmQgc2VsZWN0b3IgaW4gdGhlIE1QTFMgYXJjaGl0ZWN0dXJlPw0KDQpSZWdhcmRzIQ0KLVFpbg0K DQpGcm9tOm1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBS eW9vLCBKZW9uZy1kb25nDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjYsIDIwMTMgMTI6NTEg UE0NClRvOiBZYWFjb3YgV2VpbmdhcnRlbg0KQ2M6IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt bXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIFF1ZXN0 aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9uIGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1 DQoNCllhYWNvdiwgdGhhbmtzIGZvciB5b3VyIGVtYWlsLiBTb21laG93LCBJIGZvcmdvdCB0byBy ZXNwb25kIGFuZCBhbSBzb3JyeSBmb3IgdGhlIGRlbGF5Lg0KDQpGaXJzdCBvZiBhbGwsIFlhYWNv diwgaXQgaXMgbm90IHRydWUgdGhhdCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb2YgRXRoZXJu ZXQgb3IgU0RIIGRlc2NyaWJlcyB0aGUgb3BlcmF0aW9uIG9mIGFueSBsYXllciBiZWxvdy4gUmF0 aGVyLCBlYWNoIGxheWVyIGlzIHN1cHBvc2VkIHRvIG9wZXJhdGUgaW5kZXBlbmRlbnRseS4gSG93 ZXZlciwgdGhlcmUgYXJlIGEgZmV3IGV4Y2VwdGlvbnMsIHN1Y2ggYXMgaG9sZC1vZmYgdGltZXIg YW5kIEFJUyAoYXMgYSB0cmlnZ2VyIGZyb20gbG93ZXIgbGF5ZXIpLiBFdmVuIHRob3VnaCB0aGVy ZSBleGlzdCBzb21lIHByb3ByaWV0YXJ5IGltcGxlbWVudGF0aW9ucyB0aGF0IHVzZSBvdGhlciBp bmZvcm1hdGlvbiBmcm9tIGxvd2VyIGxheWVyLCBtb3N0IG9mIHRoZW0gYXJlIG5vdCByZWNvbW1l bmRlZCBpbiBJVFUtVCBzdGFuZGFyZHMuDQoNCkJyaWRnZSBhbmQgc2VsZWN0b3IgYXJlIG5vdCBp biB0aGUgcGh5c2ljYWwgbGF5ZXIsIGJ1dCB0aGV5IGFyZSBwYXJ0IG9mIHByb3RlY3Rpb24gc3dp dGNoaW5nLiBPbmUgb2YgdGhlIGltcG9ydGFudCBvdXRwdXQgYWN0aW9ucyBmcm9tIHRoZSBQU0Mg Y29udHJvbCBsb2dpYyBpcyBjb29yZGluYXRpbmcgdGhlIHBvc2l0aW9ucyBvZiBicmlkZ2UgYW5k IHNlbGVjdG9yLiBBbHNvLCB0aGUgYnJpZGdlIG9wZXJhdGlvbiByZXNwb25kaW5nIHRvIHRoZSBQ U0MgY29udHJvbCBsb2dpYyBpcyBhbHNvIHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIEhv d2V2ZXIsIGhvdyB0byByZWFsaXplIHRoZSBicmlkZ2UgYW5kIHNlbGVjdG9yIChmb3IgZXhhbXBs ZSwgaG93IHRvIG1hbmlwdWxhdGUgYSBwYWNrZXQgZm9yd2FyZGluZyBtZWNoYW5pc20pIGlzIGFu IGltcGxlbWVudGF0aW9uIG1hdHRlci4NCg0KV2hlbiB3ZSBtZW50aW9uIDErMSBvciAxOjEgaW4g cHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUsIHdlIGRlYWwgd2l0aCB0aGUgb3BlcmF0aW9uIG9mIGJy aWRnZS4gRm9yIDErMSBhcmNoaXRlY3R1cmUsIHRoZSB0cmFmZmljIG5lZWRzIHRvIGJlIGR1cGxp Y2F0ZWQgYXQgdGhlIHNlbmRlciBhbmQgc2VudCB0byBib3RoIHBhdGhzIGFsbCB0aGUgdGltZSwg d2hpY2ggaXMgdGhlIHNhbWUgZGVzY3JpcHRpb24gYXMgdGhlIOKAnHBlcm1hbmVudCBicmlkZ2Xi gJ0uIEZvciAxOjEgYXJjaGl0ZWN0dXJlLCDigJxzZWxlY3RvciBicmlkZ2XigJ0gaXMgdXNlZCB0 byBzZW5kIHRoZSB0cmFmZmljIG9ubHkgb25lIG9mIHRoZSBwYXRocy4gQXMgdGhlIHByb3RlY3Rp b24gcGF0aCBjYW4gYmUgdXNlZCBieSBiZXN0IHRyYWZmaWMgaW4gcGFja2V0IG5ldHdvcmtzIGFu ZCB0aGUgcGFja2V0IGR1cGxpY2F0aW9uIHRha2VzIG11Y2ggbW9yZSBlZmZvcnQvaW50ZXJuYWwg YmFuZHdpZHRoIGluc2lkZSBhIHN3aXRjaCB0aGFuIHRoZSB0aW1lIHNsb3QgY29weSBvZiBjaXJj dWl0IG5ldHdvcmtzLiAxOjEgaXMgY29uc2lkZXJlZCBhcyBwcmVmZXJhYmxlIGFyY2hpdGVjdHVy ZSBpbiBwYWNrZXQgbmV0d29ya3MuDQoNCkFzIHlvdSBtaWdodCByZWNhbGwgZnJvbSBHLjgwMzEg 4oCTIEV0aGVybmV0IGxpbmVhciBwcm90ZWN0aW9uLCB0aGUgc2VsZWN0b3IgYnJpZGdlIGlzIG5v dCByZWNvbW1lbmRlZCBkdWUgdG8gdGhlIHRyYWZmaWMgZmxhcHBpbmcgdW5kZXIgU0QgY29uZGl0 aW9ucyBvbiBib3RoIHBhdGhzLiBJbnN0ZWFkIOKAnGJyb2FkY2FzdCBicmlkZ2XigJ0gaXMgaW50 cm9kdWNlZCB0byBzdXBwb3J0IHByb3RlY3Rpb24gc3dpdGNoaW5nIGFnYWluc3QgU0QuIEJ1dCwg dGhpcyBicm9hZGNhc3QgYnJpZGdlIGlzIG5vdCByZWNvbW1lbmRlZCBpbiBub24tcmV2ZXJ0aXZl IG1vZGUgYXMgdGhlIHdvcmtpbmcgcGF0aCBuZWVkcyB0byBiZSBvY2N1cGllZCBieSB0cmFmZmlj IGFsbCB0aGUgdGltZS4gQWxzbyB0aGUgYnJvYWRjYXN0IGJyaWRnZSBpcyBub3QgZWZmaWNpZW50 LCBzaW5jZSBieSBkZWZpbml0aW9uLCB0aGUgcGFja2V0IGR1cGxpY2F0aW9uIHNob3VsZCBvY2N1 ciBkdXJpbmcgbm90IG9ubHkgU0QgYnV0IGFsc28gU0YsIEZTLCBNUywgZXRjLiBJbiB0aGlzIGRv Y3VtZW50LCB3ZSBhcmUgaW50cm9kdWNpbmcgYW4gaW1wcm92ZWQgYnJpZGdlIG1lY2hhbmlzbSwg d2hpY2ggYmVoYXZlcyBsaWtlIGEgc2VsZWN0b3IgYnJpZGdlIGJ1dCBkdXBsaWNhdGVzIHRoZSB0 cmFmZmljIG9ubHkgdW5kZXIgU0QgY29uZGl0aW9uLCBhbmQgd2UgYmVsaWV2ZSB0aGF0IGl0IGFk ZHJlc3NlcyBhbGwgdGhlIGlzc3VlcyB3aXRoIGV4aXN0aW5nIGJyaWRnZXMuDQoNCldoYXQgd2Ug bWVhbiBieSBTRCBwcm90ZWN0aW9uIGlzIGFnbm9zdGljIHRvIHRoZSBTRCBkZXRlY3Rpb24gbWV0 aG9kIGlzIHRoYXQgdGhlIHByb3Bvc2VkIFNEIHByb3RlY3Rpb24gbWV0aG9kIChhZ2FpbiBob3cg dG8gb3BlcmF0ZSBhIGJyaWRnZSBvciB3aGF0IGJyaWdlIGlzIHVzZWQgaXMgYSBwYXJ0IG9mIHBy b3RlY3Rpb24gc3dpdGNoaW5nKSBjYW4gYmUgdXNlZCBubyBtYXR0ZXIgd2hhdCBraW5kIG9mIFNE IGRldGVjdGlvbiBtZXRob2RzIChkYXRhIHBhY2tldCBjb3VudGluZywgQ0NNIHBhY2tldCBjb3Vu dGluZywgb3IgZXZlbiBwcm9wcmlldGFyeSBzZXJ2ZXIgbGF5ZXIgU0QgZGV0ZWN0aW9uKSBpcyB1 c2VkLg0KDQpJIHRoaW5rIEkgYW5zd2VyZWQgYWxsIHRoZSBxdWVzdGlvbnMgb24geW91ciBlbWFp bC4NCg0KWWFhY292LCBpZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb25jZXJucyBvciBxdWVzdGlv bnMsIHBsZWFzZSBsZXQgbWUga25vdy4NCg0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb20gOiAiWWFhY292IFdlaW5n YXJ0ZW4iIDx3eWFhY292QGdtYWlsLmNvbT4NClNlbnQgOiAyMDEzLTEyLTEwIDE2OjA0OjE3ICgg KzA5OjAwICkNClRvIDogUnlvbywgSmVvbmctZG9uZyA8cnlvb0BldHJpLnJlLmtyPg0KQ2MgOiBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxz LXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+LCBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3Jn Pg0KU3ViamVjdCA6IFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dQ0KSmVvbmctZG9uZywgaGkNCg0KVGhhbmsgeW91IGZvciB5 b3VyIHJlcGx5LiBZb3VyIGFuc3dlciBzZWVtcyB0byBiZSBhbiBhcHByb3ByaWF0ZSBhbnN3ZXIg Zm9yIG90aGVyIFNET3MsIG5vdCBzdXJlIHRoYXQgaXQgaXMgdHJ1ZSBmb3IgdGhlIGNvbnRleHQg b2YgTVBMUyBhbmQgSUVURiB3b3JrLg0KDQoxLiBZb3Ugd3JvdGUgImFueSBwcm90ZWN0aW9uIHN3 aXRjaGluZyAoaW5jbHVkaW5nIFBTQykgaXMgc3VwcG9zZWQgdG8gZGVzY3JpYmUgdGhlIG9wZXJh dGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiIgLSB0aGlzIG1heSBiZSB0cnVlIGZvciBFdGhl cm5ldCBhbmQgU0RIIGFuZCBmb3IgZG9jdW1lbnRzIHRoYXQgYXJlIGRlc2NyaWJpbmcgdGhlIG9w ZXJhdGlvbiBvZiB0aGUgcGh5c2ljYWwgbGF5ZXIuIEhvd2V2ZXIsIHRoZSBJRVRGICh0byBteSB1 bmRlcnN0YW5kaW5nIC0gYW5kIEkgYW0gY2VydGFpbmx5IHdpbGxpbmcgdG8gYmUgY29ycmVjdGVk IG9uIHRoaXMgcG9pbnQpIGlzIGNvbmNlcm5lZCB3aXRoIHRoZSBwcm90b2NvbCBhbmQgbGVhdmUg dGhlIGxvd2VyIGxheWVycyB0byBpbXBsZW1lbnRhdGlvbi4gQWxzbywgSSBhbSBub3Qgc3VyZSB0 aGF0IHRoZSBjb25jZXB0cyBvZiBCcmlkZ2UgYW5kIFNlbGVjdG9yIHJlYWxseSBhcHBseSB0byBN UExTIChhbHRob3VnaCBJIGFkbWl0IHRoYXQgd2UgZGlkIG1lbnRpb24gdGhlbSBpbiB0aGUgb3Jp Z2luYWwgUFNDIGRlZmluaXRpb24pLg0KDQoyLiBZb3UgY2l0ZSB3aGF0IHdhcyB3cml0dGVuIGlu IEc4MDMxIGFzIGp1c3RpZmljYXRpb24gZm9yIGluY2x1ZGluZyBjb250ZW50IGludG8geW91ciBk cmFmdC4gQWdhaW4gaXQgaXMgaGFyZCB0byB0cmFuc2ZlciBtZXRob2RvbG9neSBmcm9tIG9uZSBT RE8gdG8gYW5vdGhlciBhbmQgdGhlcmVmb3JlLCB3aGlsZSBJIGhpZ2hseSByZXNwZWN0IHRoZSB3 b3JrIG9mIHRoZSBJVFUsIEkgZG8gbm90IGZlZWwgdGhhdCB0aGlzIGlzIGEgdmVyeSBjbGVhciBq dXN0aWZpY2F0aW9uIGZvciBpbmNsdXNpb24gaW50byBhbiBpbnRlcm5ldC1kcmFmdC4gRXZlbiB3 aGVuIHRoZSBkcmFmdCBzdGF0ZXMgdGhhdCBpdHMgcHVycG9zZSBpcyB0byBhZGRyZXNzIHRoZSBj b25jZXJucyBvZiB0aGUgSVRVLg0KDQozLiBUbyB0aGUgYWN0dWFsIHBvaW50IG9mIG15IGVhcmxp ZXIgY29tbWVudCwgdGhhdCB5b3UgZG8gbm90IHNlZW0gdG8gYWRkcmVzcyAtIHRoZSBwYXJhZ3Jh cGggaW4gU2VjdGlvbiA3LjMgc2VlbXMgdG8gc3RhdGUgdGhhdCBTRCBwcm90ZWN0aW9uIGNoYW5n ZXMgYWNjb3JkaW5nIHRvIHRoZSBtZXRob2QgdGhhdCBpcyB1c2VkIHRvIGRldGVjdCB0aGUgU0Qu IFRoaXMgbWVhbnMgdGhhdCBTRCBwcm90ZWN0aW9uIGlzIG5vdCBhZ25vc3RpYyB0byB0aGUgbWV0 aG9kIHVzZWQgZm9yIHRoZSBkZXRlY3Rpb24uDQpBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCBicmVh ayB0aGlzIGRlcGVuZGVuY2UgYW5kIHN0YXRlIHRoYXQgU0QgcHJvdGVjdGlvbiBpcyBhbHdheXMg cHJvdmlkZWQgYnkgY2hhbmdpbmcgdGhlIHRyYW5zbWlzc2lvbiBvZiB0aGUgZGF0YSB0byAxKzEg cHJvdGVjdGlvbiBpbiBjYXNlcyBvZiBTRCBkZXRlY3Rpb24sIHdoaWNoIGlzIHdoYXQgdGhlIHBh cmFncmFwaCBpcyBzdWdnZXN0aW5nIHRvIGRvIGZvciBzb21lIGNhc2VzLg0KDQpJIGhvcGUgdGhp cyBmb3JtdWxhdGlvbiBtYWtlIG15IGNvbW1lbnQgY2xlYXJlciBhbmQgd2UgYXJlIGFibGUgdG8g ZGlzY3VzcyB0aGUgdGVjaG5vbG9naWNhbCBhcHByb2FjaCByYXRoZXIgdGhhbiB0aGUgcGhpbG9z b3BoaWNhbCBkaWZmZXJlbmNlcy4NCg0KVGhhbmsgeW91LA0KeWFhY292DQoNCk9uIE1vbiwgRGVj IDksIDIwMTMgYXQgMTA6MDQgUE0sIFJ5b28sIEplb25nLWRvbmcgPHJ5b29AZXRyaS5yZS5rcjxt YWlsdG86cnlvb0BldHJpLnJlLmtyPj4gd3JvdGU6DQpZYWFjb3YsDQoNClllcywgUFNDIGlzIHN1 cHBvc2VkIHRvIGJlIGFnbm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhlIGRldGVjdGlv biBvZiBTRi9TRC4NCg0KSXQgaXMgYWxzbyB0cnVlIHRoYXQgYW55IHByb3RlY3Rpb24gc3dpdGNo aW5nIChpbmNsdWRpbmcgUFNDKSBpcyBzdXBwb3NlZCB0byBkZXNjcmliZSB0aGUgb3BlcmF0aW9u IG9mIGJyaWRnZSBhbmQgc2VsZWN0b3IuDQoNCkFzIHRoZXJlIGFyZSBtdWx0aXBsZSBvcHRpb25z IGZvciBkZXRlY3RpbmcgU0QsIHdlIG5lZWRlZCB0byBkZXNjcmliZSB0aGUgYmVoYXZpb3Igb2Yg dGhlIGJyaWRnZSB0byBjb3ZlciBhbGwgdGhlIHBvc3NpYmxlIGRldGVjdGlvbiBtZXRob2RzLiBE ZXNjcmliaW5nIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGZvciBTRCBwcm90ZWN0aW9uIGlzIG5v dCBhIG5ldyB0aGluZy4gRm9yIGV4YW1wbGUsIEcuODAzMSAtIEV0aGVybmV0IGxpbmVhciBwcm90 ZWN0aW9uIGFsc28gZGVzY3JpYmVzIHdoYXQgYnJpZGdlIGNhbiBiZSB1c2VkIGluIG9yZGVyIHRv IHByb3ZpZGUgcHJvdGVjdGlvbiBhZ2FpbnN0IFNELg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25n LWRvbmcNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbSA6ICJZYWFj b3YgV2VpbmdhcnRlbiIgPHd5YWFjb3ZAZ21haWwuY29tPG1haWx0bzp3eWFhY292QGdtYWlsLmNv bT4+DQpTZW50IDogMjAxMy0xMi0wOCAyMDowMTo1NSAoICswOTowMCApDQpUbyA6IGRyYWZ0LWll dGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMt dHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz4gPGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRv b2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRm Lm9yZz4+LCBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiA8bXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+DQpDYyA6DQpTdWJqZWN0IDogUXVlc3Rpb24gcmVnYXJk aW5nIFNEIHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCg0KSGksDQoN CkFmdGVyIHJlYWRpbmcgdGhyb3VnaCB5b3VyIGRyYWZ0IG9uIHRoZSBleHRlbnNpb25zIHRvIFBT QyB0byBzdXBwb3J0IFNEIHNpdHVhdGlvbnMsIEkgaGF2ZSBhIHF1ZXN0aW9uIGZvciBjbGFyaWZp Y2F0aW9uIC0NCkluIHlvdXIgaW50cm9kdWN0aW9uIC0geW91IHN0YXRlIHRoYXQgdGhlIG1ldGhv ZCB1c2VkIHRvIGRldGVjdCBTRCBzaXR1YXRpb25zIGlzIG91dC1vZi1zY29wZSBvZiB0aGUgZG9j dW1lbnQuIERvZXMgdGhpcyBtZWFuIHRoYXQgUFNDIGlzIHN1cHBvc2VkIHRvIGJlIGFnbm9zdGlj IHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhpcyBkZXRlY3Rpb24/IEl0IHNob3VsZCByZWFjdCBv bmx5IHRvIHRoZSBpbmRpY2F0aW9uLCBzaW1pbGFybHkgdG8gdGhlIHJlYWN0aW9uIGFuZCByZWxh dGlvbnNoaXAgdG8gdGhlIG1ldGhvZCBmb3IgZGV0ZWN0aW5nIGFuZCBkZWNsYXJpbmcgYSBTRiBz aXR1YXRpb24uDQpIb3dldmVyLCB3aGVuIHlvdSBleHBsYWluIHRoZSBiZWhhdmlvciBvZiB0aGUg U0QgcHJvdGVjdGlvbiBpbiBzZWN0aW9uIDcuMyB5b3UgaGF2ZSBhIHBhcmFncmFwaCB0aGF0IHN0 YXJ0cyB3aXRoICJJZiB0aGUgZGV0ZWN0aW9uIG9mIGEgU0QgZGVwZW5kcyBvbiB0aGUgcHJlc2Vu Y2Ugb2YgdXNlciBkYXRhIHBhY2tldHMgLi4uIiAgdGhhdCBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0 IHRoZSBiZWhhdmlvciBvZiB0aGUgc3lzdGVtIGlzIGRlcGVuZGVudCB1cG9uIHRoZSBkZXRlY3Rp b24gbWV0aG9kISBDbGFyaWZpY2F0aW9uIHdvdWxkIGJlIGFwcHJlY2lhdGVkLg0KDQotLQ0KVGhh bnggYW5kIEJSLA0KeWFhY292DQoNClN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eQ0K DQoNCg0KDQotLQ0KVGhhbnggYW5kIEJSLA0KeWFhY292DQoNClN0aWxsIGxvb2tpbmcgZm9yIG5l dyBvcHBvcnR1bml0eQ0K --_000_B8F9A780D330094D99AF023C5877DABA43C6F481nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOmR0PSJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1B MjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTWFsZ3VuIEdvdGhpYyI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAg MCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuunkeydgOqzoOuUlTsNCglwYW5v c2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA TWFsZ3VuIEdvdGhpYyI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOunkeydgOqzoOuUlSI7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSmVvbmctZG9uZzo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhhbmsgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGUgdGl0bGUgb2YgeW91ciBkcmFmdCBpcyDigJxNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExT LVRQKSBMaW5lYXIgUHJvdGVjdGlvbiBpbiBTdXBwb3J0IG9mIElUVS1UJ3MgUmVxdWlyZW1lbnRz 4oCdPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JdCBpcyBvYnZpb3VzIHlvdXIgZHJhZnQgaXMgY29tcGxpYW50 IHdpdGggUkZDNjM3OC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIgSSBhbSB3b25kZXJpbmcgd2hh dCBJVFUtVOKAmXMgcmVxdWlyZW1lbnRzIGFyZT8gQXJlIHRoZXNlIHJlcXVpcmVtZW50cyBmcm9t IElUVS1UIGRvY3VtZW50IEcuODAzMSBvciBzb21lIG90aGVyIElUVS1UIGRvY3VtZW50cz88bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkZyb20gdGhpcyBwZXJzcGVjdGl2ZSwgSSB0aGluayBvbmUgSVRVLVQgZG9j dW1lbnQgZGVzY3JpYmluZyB0aGVzZSByZXF1aXJlbWVudHMgPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5uZWVkcyB0bzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+IG1lbnRpb25lZCBpbiB0aGlzIGRyYWZ0LCBl LmcuLCA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmlu IHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Rm9yIGFnbm9zdGljIGlzc3VlLCBJIHRoaW5rIHRoaXMgaXNzdWUgaXMgYXBwbGll ZCB0byBzZWN0aW9uIDcuMywgYXMgeW91IGNsYXJpZmllZCBlYXJsaWVyLCB0aGUgc2VsZWN0b3Ig aXMgbm90IHJlYWxseSBicmlkZ2Ugc2VsZWN0b3IgYnV0IG9wdGltaXplZCBicmlkZ2Ugc2VsZWN0 b3IuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFt IHdvbmRlcmluZyB3aGV0aGVyIGl0IGlzIGNvbWJpbmF0aW9uIG9mIHBlcm1hbmVudCBicmlkZ2Ug YW5kIHNlbGVjdG9yIGJyaWRnZSAoVHdvIHRlcm1zIGFyZSBkZWZpbmVkIGluIFJGQzYzNzgpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgaXQgaXMs IG15IHF1ZXN0aW9uIGlzIGNhbiB3ZSBhcHBseSAxOjEgcHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUg YW5kIDEmIzQzOzEgcHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUgdG8gbGluZWFyIHByb3RlY3Rpb24g bWVjaGFuaXNtIGF0IHRoZSBzYW1lIHRpbWUgb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIHNob3VsZCB1c2UgdGhlc2UgcGVybWFuZW50IGJyaWRn ZSBhbmQgc2VsZWN0b3IgYnJpZGdlIHNlcGFyYXRlbHk/PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25n IG9yIG1pc3Mgc29tZXRoaW5nLjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVFpbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUnlvbywgSmVvbmctZG9uZyBbbWFpbHRvOnJ5b29AZXRy aS5yZS5rcl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIERlY2VtYmVyIDMwLCAyMDEzIDE6 MjAgUE08YnI+DQo8Yj5Ubzo8L2I+IFFpbiBXdTsgWWFhY292IFdlaW5nYXJ0ZW48YnI+DQo8Yj5D Yzo8L2I+IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbbXBsc10gUXVlc3Rpb24gcmVnYXJkaW5n IFNEIHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IGlkPSJlekZvcm1Qcm9jX2RpdiI+DQo8ZGl2IGlkPSJtc2dib2R5 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UWluLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMgZHJhZnQg aXMgYmFzZWQgb24gUkZDNjM3OCBmb3IgdGhlIHByb3RvY29sIG1lc3NhZ2UgZm9ybWF0IGFuZCB0 aGUmbmJzcDtiYXNpYyBvcGVyYXRpb25hbCBwcmljaXBsZXMsIHdoaWNoJm5ic3A7YXJlIGRpZmZl cmVudCBmcm9tIEcuODAzMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5UaGUgaW50ZW50aW9uIG9mIHRoaXMgZHJhZnQgaXMgdG8gbWFrZSBS RkM2Mzc4IGJlIGFsaWduZWQgd2l0aCBHLjgwMzEgKG9yIG90aGVyIElUVSBwcm90ZWN0aW9uIHRl Y2hub2xvZ2llcykgaW4gdGhlIGFzcGVjdHMgb2YgJnF1b3Q7bmV0d29yayBvcGVyYXRpb24mcXVv dDsuJm5ic3A7SW4NCiBvdGhlciB3b3JkcywgaXQmbmJzcDtsb29rcyBsaWtlIEcuODAzMSAob3Ig b3RoZXIgSVRVIHByb3RlY3Rpb24gdGVjaG5vbG9naWVzKSB0byB0aGUgbmV0d29yayBvcGVyYXRv cnMsIGJ1dCZuYnNwO3RoZSZuYnNwO2FjdHVhbCBwcm90b2NvbCBvcGVyYXRpb25zJm5ic3A7YW5k IHRoZSBiaXRzIG9uIHRoZSB3aXJlIGFyZSBkaWZmZXJlbnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBtZW50aW9uZWQgRy44 MDMxIGluIG15IHByZXZpb3VzIGVtYWlsIHRvIFlhYWNvdiBqdXN0IGZvciBiZXR0ZXIgZXhwbGFu YXRpb24sJm5ic3A7YW5kIEkgZG9uJ3QgdGhpbmsmbmJzcDt0aGlzIGRvY3VtZW50Jm5ic3A7bmVl ZHMmbmJzcDtHLjgwMzEgYXMgYSByZWZlcmVuY2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CdXQsIGlmIHlvdSZuYnNwO2ZpbmQgYW55 IHBhcnQgaW4gdGhpcyBkb2N1bWVudCB0aGF0Jm5ic3A7bmVlZHMgYSByZWZlcmVuY2UgdG8gRy44 MDMxLCBwbGVhc2UgbGV0IHVzIGtub3cuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WW91IGFuZCBZYWFjb3YgbWlnaHQg YmUgcmlnaHQgb24gdGhlIHNlbnRlbmNlICZxdW90O1NEIHByb3RlY3RvbiBpcyBub3QgYWdub3N0 aWMgdG8gdGhlIGRldGVjdGlvbiBtZXRob2QmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QnV0LCBhcyBJIHNhaWQsIG15IG9yaWdp bmFsIGludGVudGlvbiBhbmQgd2hhdCB3ZSB3YW50ZWQgdG8gYWNoaWV2ZSBpbiB0aGlzIGRvY3Vt ZW50Jm5ic3A7YXJlIHRoYXQmbmJzcDt0aGUmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+cHJvdGVjdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+c3BlY2lmaWVkDQogaW4g dGhpcyBkb2N1bWVudDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3Vu IEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Y292ZXJzIFNEPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5ubw0KIG1hdHRlciB3aGF0IGtpbmQgb2YgU0QgZGV0ZWN0aW9uIG1ldGhvZHM8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPnNob3VkIGJlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij51c2VkLg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJ5IHRoZSB3YXksIHRoaXMgZHJhZnQgZG9lcyBub3Qg aGF2ZSBhIHdvcmQgJnF1b3Q7YWdub3N0aWMmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmVzdCByZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pkplb25nLWRvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxNS4wcHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIi Pg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbSA6DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZxdW90O1FpbiBXdSZxdW90OyAmbHQ7YmlsbC53dUBodWF3ZWkuY29tJmd0Ozxicj4N CjxiPlNlbnQgOiA8L2I+MjAxMy0xMi0zMCAxMjo0ODoyNyAoICYjNDM7MDk6MDAgKTxicj4NCjxi PlRvIDogPC9iPlJ5b28sIEplb25nLWRvbmcgJmx0O3J5b29AZXRyaS5yZS5rciZndDssIFlhYWNv diBXZWluZ2FydGVuICZsdDt3eWFhY292QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYyA6IDwvYj5t cGxzQGlldGYub3JnICZsdDttcGxzQGlldGYub3JnJmd0OywgZHJhZnQtaWV0Zi1tcGxzLXRwLXBz Yy1pdHVAdG9vbHMuaWV0Zi5vcmcgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xz LmlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3QgOiA8L2I+UkU6IFttcGxzXSBRdWVzdGlvbiBy ZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlNvcnJ5IHRvIGludGVycnVwdCBpbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSBhIGxpdHRsZSBiaXQgc3VycHJpc2VkIHRo aXMgZHJhZnQgaGFzIG5vdCBhbnkgcmVmZXJlbmNlIHRvIElUVSBkb2N1bWVudC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSB3b25k ZXJpbmcgaG93IG11Y2ggdGhpcyBkcmFmdCBpcyBjb21wbGlhbnQgd2l0aCBHLjgwMzE/IElzIHRo ZXJlIGFueSB0d2VhayBvciBvcHRpbWl6YXRpb24gdG8gRy44MzE/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgaXMgdGhlIGNvbmNl cm4gb2YgRy44MzEgdGhpcyBkcmFmdCBpcyBkZWFsaW5nIHdpdGg/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIGFueXRoaW5nIGlzIGZy b20gRy44MzEgb3IgYW55IG90aGVyIElUVSBkb2N1bWVudCwgSSB0aGluayBpdCBpcyBmaW5lLCBo b3dldmVyIEcuODMxIG9yIHNvbWUgb3RoZXIgSVRVIGRvY3VtZW50cyBhcmUgd29ydGggYmVpbmcN CiByZWZlcmVuY2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHRoaXMgZHJhZnQgaXMgZm9jdXNpbmcgb24g YWRkcmVzc2luZyBHLjgzMSwgaXQgaXMgYmV0dGVyIHRvIGNsYXJpZnkgdGhpcyBhIGxpdHRsZSBi aXQgaW4gdGhpcyBkcmFmdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBmZWVsaW5nIGlzIHRoaXMgZHJhZnQg c2VlbXMgdG8gaW50cm9kdWNlIGNvbWJpbmF0aW9uIG9mIDEmIzQzOzEgYW5kIDE6MSBwcm90ZWN0 aW9uIGFyY2hpdGVjdHVyZSB3aGVuIEkgcmVhZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWln aHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+QXMgeW91IG1pZ2h0IHJlY2FsbCBmcm9tIEcuODAzMQ0K PC9zcGFuPuKAkzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4gRXRoZXJuZXQgbGluZWFyIHByb3RlY3Rpb24sIHRoZSBz ZWxlY3RvciBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVkIGR1ZSB0byB0aGUgdHJhZmZpYyBmbGFw cGluZyB1bmRlciBTRCBjb25kaXRpb25zIG9uIGJvdGggcGF0aHMuIEluc3RlYWQNCjwvc3Bhbj7i gJw8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+YnJvYWRjYXN0IGJyaWRnZTwvc3Bhbj7igJ08c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+IGlz IGludHJvZHVjZWQgdG8gc3VwcG9ydCBwcm90ZWN0aW9uIHN3aXRjaGluZyBhZ2FpbnN0IFNELiBC dXQsIHRoaXMgYnJvYWRjYXN0IGJyaWRnZSBpcyBub3QgcmVjb21tZW5kZWQgaW4gbm9uLXJldmVy dGl2ZSBtb2RlDQogYXMgdGhlIHdvcmtpbmcgcGF0aCBuZWVkcyB0byBiZSBvY2N1cGllZCBieSB0 cmFmZmljIGFsbCB0aGUgdGltZS4gQWxzbyB0aGUgYnJvYWRjYXN0IGJyaWRnZSBpcyBub3QgZWZm aWNpZW50LCBzaW5jZSBieSBkZWZpbml0aW9uLCB0aGUgcGFja2V0IGR1cGxpY2F0aW9uIHNob3Vs ZCBvY2N1ciBkdXJpbmcgbm90IG9ubHkgU0QgYnV0IGFsc28gU0YsIEZTLCBNUywgZXRjLiBJbiB0 aGlzIGRvY3VtZW50LCB3ZSBhcmUgaW50cm9kdWNpbmcgYW4gaW1wcm92ZWQNCiBicmlkZ2UgbWVj aGFuaXNtLCB3aGljaCBiZWhhdmVzIGxpa2UgYSBzZWxlY3RvciBicmlkZ2UgYnV0IGR1cGxpY2F0 ZXMgdGhlIHRyYWZmaWMgb25seTwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+dW5kZXIgU0QgY29u ZGl0aW9uLCBhbmQgd2UgYmVsaWV2ZSB0aGF0IGl0IGFkZHJlc3NlcyBhbGwgdGhlIGlzc3VlcyB3 aXRoIGV4aXN0aW5nIGJyaWRnZXMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0sDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0ZW5kIHRvIGFn cmVlIFlhY2NvdiB0aGF0IFNEIHByb3RlY3Rpb24gaXMgbm90IGFnbm9zdGljIHRvIHRoZSBtZXRo b2QgdXNlZCBmb3IgdGhlIGRldGVjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxzbyBJIGFtIGludGVyZXN0ZWQgdG8ga25vdyBo b3cgdG8gcG9zaXRpb24gYnJpZGdlIGFuZCBzZWxlY3RvciBpbiB0aGUgTVBMUyBhcmNoaXRlY3R1 cmU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVFpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1w bHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJ5 b28sIEplb25nLWRvbmc8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDI2LCAy MDEzIDEyOjUxIFBNPGJyPg0KPGI+VG86PC9iPiBZYWFjb3YgV2VpbmdhcnRlbjxicj4NCjxiPkNj OjwvYj4gbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttcGxzXSBRdWVzdGlvbiByZWdhcmRpbmcg U0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImV6Rm9ybVBy b2NfZGl2Ij4NCjxkaXYgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+WWFhY292LCB0aGFua3MgZm9yIHlvdXIgZW1haWwuPC9zcGFuPiZuYnNwOzxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5Tb21laG93LCBJIGZvcmdvdCB0byByZXNwb25kIGFuZCBhbSBzb3JyeSBmb3Ig dGhlDQogZGVsYXkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox MC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Rmlyc3Qgb2YgYWxsLCBZYWFj b3YsIGl0IGlzIG5vdCB0cnVlIHRoYXQgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIG9mIEV0aGVy bmV0IG9yIFNESCBkZXNjcmliZXMgdGhlIG9wZXJhdGlvbiBvZiBhbnkgbGF5ZXIgYmVsb3cuIFJh dGhlciwNCiBlYWNoIGxheWVyIGlzIHN1cHBvc2VkIHRvIG9wZXJhdGUgaW5kZXBlbmRlbnRseS4g SG93ZXZlciwgdGhlcmUgYXJlIGEgZmV3IGV4Y2VwdGlvbnMsIHN1Y2ggYXMgaG9sZC1vZmYgdGlt ZXIgYW5kIEFJUyAoYXMgYSB0cmlnZ2VyIGZyb20gbG93ZXIgbGF5ZXIpLiBFdmVuIHRob3VnaCB0 aGVyZSBleGlzdCBzb21lIHByb3ByaWV0YXJ5IGltcGxlbWVudGF0aW9ucyB0aGF0IHVzZSBvdGhl ciBpbmZvcm1hdGlvbiBmcm9tIGxvd2VyIGxheWVyLCBtb3N0DQogb2YgdGhlbSBhcmUgbm90IHJl Y29tbWVuZGVkIGluIElUVS1UIHN0YW5kYXJkcy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0 OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ QnJpZGdlIGFuZCBzZWxlY3RvciBhcmUgbm90IGluIHRoZSBwaHlzaWNhbCBsYXllciwgYnV0IHRo ZXkgYXJlIHBhcnQgb2YgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIE9uZSBvZiB0aGUgaW1wb3J0YW50 IG91dHB1dCBhY3Rpb25zIGZyb20gdGhlDQogUFNDIGNvbnRyb2wgbG9naWMgaXMgY29vcmRpbmF0 aW5nIHRoZSBwb3NpdGlvbnMgb2YgYnJpZGdlIGFuZCBzZWxlY3Rvci4gQWxzbywgdGhlIGJyaWRn ZSBvcGVyYXRpb24gcmVzcG9uZGluZyB0byB0aGUgUFNDIGNvbnRyb2wgbG9naWMgaXMgYWxzbyBw YXJ0IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nLiBIb3dldmVyLCBob3cgdG8gcmVhbGl6ZSB0aGUg YnJpZGdlIGFuZCBzZWxlY3RvciAoZm9yIGV4YW1wbGUsIGhvdyB0byBtYW5pcHVsYXRlIGEgcGFj a2V0DQogZm9yd2FyZGluZyBtZWNoYW5pc20pIGlzIGFuIGltcGxlbWVudGF0aW9uIG1hdHRlci4g PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1o ZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhp YyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+V2hlbiB3ZSBtZW50aW9uIDEmIzQzOzEgb3IgMTox IGluIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJlLCB3ZSBkZWFsIHdpdGggdGhlIG9wZXJhdGlvbiBv ZiBicmlkZ2UuIEZvciAxJiM0MzsxIGFyY2hpdGVjdHVyZSwgdGhlIHRyYWZmaWMgbmVlZHMgdG8g YmUNCiBkdXBsaWNhdGVkIGF0IHRoZSBzZW5kZXIgYW5kIHNlbnQgdG8gYm90aCBwYXRocyBhbGwg dGhlIHRpbWUsIHdoaWNoIGlzIHRoZSBzYW1lIGRlc2NyaXB0aW9uIGFzIHRoZQ0KPC9zcGFuPuKA nDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5wZXJtYW5lbnQgYnJpZGdlPC9zcGFuPuKAnTxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4uIEZv ciAxOjEgYXJjaGl0ZWN0dXJlLA0KPC9zcGFuPuKAnDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5zZWxlY3RvciBicmlk Z2U8L3NwYW4+4oCdPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiBpcyB1c2VkIHRvIHNlbmQgdGhlIHRyYWZmaWMgb25s eSBvbmUgb2YgdGhlIHBhdGhzLiBBcyB0aGUgcHJvdGVjdGlvbiBwYXRoIGNhbiBiZSB1c2VkIGJ5 PC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGlj JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5iZXN0DQogdHJhZmZpYyBpbiBwYWNrZXQgbmV0d29y a3MgYW5kIHRoZSBwYWNrZXQgZHVwbGljYXRpb24gdGFrZXMgbXVjaCBtb3JlIGVmZm9ydC9pbnRl cm5hbCBiYW5kd2lkdGggaW5zaWRlIGEgc3dpdGNoIHRoYW4gdGhlIHRpbWUgc2xvdCBjb3B5IG9m IGNpcmN1aXQgbmV0d29ya3MuIDE6MSBpcyBjb25zaWRlcmVkIGFzIHByZWZlcmFibGUgYXJjaGl0 ZWN0dXJlIGluIHBhY2tldCBuZXR3b3Jrcy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDox NS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFz IHlvdSBtaWdodCByZWNhbGwgZnJvbSBHLjgwMzENCjwvc3Bhbj7igJM8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+IEV0 aGVybmV0IGxpbmVhciBwcm90ZWN0aW9uLCB0aGUgc2VsZWN0b3IgYnJpZGdlIGlzIG5vdCByZWNv bW1lbmRlZCBkdWUgdG8gdGhlIHRyYWZmaWMgZmxhcHBpbmcgdW5kZXIgU0QgY29uZGl0aW9ucyBv biBib3RoIHBhdGhzLiBJbnN0ZWFkDQo8L3NwYW4+4oCcPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmJyb2FkY2FzdCBi cmlkZ2U8L3NwYW4+4oCdPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3Ro aWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiBpcyBpbnRyb2R1Y2VkIHRvIHN1cHBvcnQgcHJv dGVjdGlvbiBzd2l0Y2hpbmcgYWdhaW5zdCBTRC4gQnV0LCB0aGlzIGJyb2FkY2FzdCBicmlkZ2Ug aXMgbm90IHJlY29tbWVuZGVkIGluIG5vbi1yZXZlcnRpdmUgbW9kZQ0KIGFzIHRoZSB3b3JraW5n IHBhdGggbmVlZHMgdG8gYmUgb2NjdXBpZWQgYnkgdHJhZmZpYyBhbGwgdGhlIHRpbWUuIEFsc28g dGhlIGJyb2FkY2FzdCBicmlkZ2UgaXMgbm90IGVmZmljaWVudCwgc2luY2UgYnkgZGVmaW5pdGlv biwgdGhlIHBhY2tldCBkdXBsaWNhdGlvbiBzaG91bGQgb2NjdXIgZHVyaW5nIG5vdCBvbmx5IFNE IGJ1dCBhbHNvIFNGLCBGUywgTVMsIGV0Yy4gSW4gdGhpcyBkb2N1bWVudCwgd2UgYXJlIGludHJv ZHVjaW5nIGFuIGltcHJvdmVkDQogYnJpZGdlIG1lY2hhbmlzbSwgd2hpY2ggYmVoYXZlcyBsaWtl IGEgc2VsZWN0b3IgYnJpZGdlIGJ1dCBkdXBsaWNhdGVzIHRoZSB0cmFmZmljIG9ubHk8L3NwYW4+ Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPnVuZGVyIFNEIGNvbmRpdGlvbiwgYW5kIHdlIGJlbGlldmUgdGhh dCBpdCBhZGRyZXNzZXMgYWxsIHRoZSBpc3N1ZXMgd2l0aCBleGlzdGluZyBicmlkZ2VzLg0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWln aHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+V2hhdCB3ZSBtZWFuIGJ5IFNEIHByb3RlY3Rpb24gaXMg YWdub3N0aWMgdG8gdGhlIFNEIGRldGVjdGlvbiBtZXRob2QgaXMgdGhhdCB0aGUgcHJvcG9zZWQg U0QgcHJvdGVjdGlvbiBtZXRob2QgKGFnYWluIGhvdyB0byBvcGVyYXRlIGEgYnJpZGdlDQogb3Ig d2hhdDwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdv dGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+YnJpZ2UgaXMgdXNlZCBpcyBhIHBhcnQgb2Yg cHJvdGVjdGlvbiBzd2l0Y2hpbmcpIGNhbiBiZSB1c2VkIG5vIG1hdHRlciB3aGF0IGtpbmQgb2Yg U0QgZGV0ZWN0aW9uIG1ldGhvZHMgKGRhdGEgcGFja2V0IGNvdW50aW5nLCBDQ00gcGFja2V0IGNv dW50aW5nLCBvciBldmVuIHByb3ByaWV0YXJ5IHNlcnZlciBsYXllciBTRCBkZXRlY3Rpb24pDQog aXMgdXNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBw dDtsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxn dW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIHRoaW5rIEkgYW5zd2VyZWQgYWxs IHRoZSBxdWVzdGlvbnMgb24geW91ciBlbWFpbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6 MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Z YWFjb3YsIGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbmNlcm5zIG9yIHF1ZXN0aW9ucywgcGxl YXNlIGxldCBtZSBrbm93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJlc3QgcmVnYXJkcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhl aWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGlj JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5KZW9uZy1kb25nPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2xpbmUt aGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJNYWlsU2lnblNl bnRTZW50Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxNS4wcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUi IGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbSA6DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZxdW90O1lhYWNvdiBXZWluZ2FydGVuJnF1b3Q7ICZsdDt3eWFhY292QGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMtMTItMTAgMTY6MDQ6MTcgKCAmIzQzOzA5OjAw ICk8YnI+DQo8Yj5UbyA6IDwvYj5SeW9vLCBKZW9uZy1kb25nICZsdDtyeW9vQGV0cmkucmUua3Im Z3Q7PGJyPg0KPGI+Q2MgOiA8L2I+ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0 Zi5vcmcgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnJmd0Oywg bXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0IDogPC9i PlJlOiBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMt dHAtcHNjLWl0dTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5KZW9uZy1kb25nLCBoaQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmsgeW91IGZvciB5b3Vy IHJlcGx5LiBZb3VyIGFuc3dlciBzZWVtcyB0byBiZSBhbiBhcHByb3ByaWF0ZSBhbnN3ZXIgZm9y IG90aGVyIFNET3MsIG5vdCBzdXJlIHRoYXQgaXQgaXMgdHJ1ZSBmb3IgdGhlIGNvbnRleHQgb2Yg TVBMUyBhbmQgSUVURg0KIHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xLiBZb3Ug d3JvdGUgJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O+unkeydgOqzoOuUlSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+YW55IHByb3Rl Y3Rpb24gc3dpdGNoaW5nIChpbmNsdWRpbmcgUFNDKSBpcyBzdXBwb3NlZCB0byBkZXNjcmliZSB0 aGUNCiBvcGVyYXRpb24gb2YgYnJpZGdlIGFuZCBzZWxlY3Rvci4mcXVvdDsgLSA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGhpcyBtYXkgYmUgdHJ1ZSBmb3IgRXRoZXJuZXQgYW5k Jm5ic3A7U0RIIGFuZCBmb3IgZG9jdW1lbnRzIHRoYXQgYXJlIGRlc2NyaWJpbmcgdGhlIG9wZXJh dGlvbiBvZiB0aGUgcGh5c2ljYWwgbGF5ZXIuIEhvd2V2ZXIsIHRoZSBJRVRGICh0byBteSB1bmRl cnN0YW5kaW5nDQogLSBhbmQgSSBhbSBjZXJ0YWlubHkgd2lsbGluZyB0byBiZSBjb3JyZWN0ZWQg b24gdGhpcyBwb2ludCkgaXMgY29uY2VybmVkIHdpdGggdGhlIHByb3RvY29sIGFuZCBsZWF2ZSB0 aGUgbG93ZXIgbGF5ZXJzIHRvIGltcGxlbWVudGF0aW9uLiBBbHNvLCBJIGFtIG5vdCBzdXJlIHRo YXQgdGhlIGNvbmNlcHRzIG9mIEJyaWRnZSBhbmQgU2VsZWN0b3IgcmVhbGx5IGFwcGx5IHRvIE1Q TFMgKGFsdGhvdWdoIEkgYWRtaXQgdGhhdCB3ZSBkaWQgbWVudGlvbg0KIHRoZW0gaW4gdGhlIG9y aWdpbmFsIFBTQyBkZWZpbml0aW9uKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIuIFlv dSBjaXRlIHdoYXQgd2FzIHdyaXR0ZW4gaW4gRzgwMzEgYXMganVzdGlmaWNhdGlvbiBmb3IgaW5j bHVkaW5nIGNvbnRlbnQgaW50byB5b3VyIGRyYWZ0LiBBZ2FpbiBpdCBpcyBoYXJkIHRvIHRyYW5z ZmVyIG1ldGhvZG9sb2d5IGZyb20gb25lIFNETw0KIHRvIGFub3RoZXIgYW5kIHRoZXJlZm9yZSwg d2hpbGUgSSBoaWdobHkgcmVzcGVjdCB0aGUgd29yayBvZiB0aGUgSVRVLCBJIGRvIG5vdCBmZWVs IHRoYXQgdGhpcyBpcyBhIHZlcnkgY2xlYXIganVzdGlmaWNhdGlvbiBmb3IgaW5jbHVzaW9uIGlu dG8gYW4gaW50ZXJuZXQtZHJhZnQuIEV2ZW4gd2hlbiB0aGUgZHJhZnQgc3RhdGVzIHRoYXQgaXRz IHB1cnBvc2UgaXMgdG8gYWRkcmVzcyB0aGUgY29uY2VybnMgb2YgdGhlIElUVS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjMuIFRvIHRoZSBhY3R1YWwgcG9pbnQgb2YgbXkgZWFybGllciBj b21tZW50LCB0aGF0IHlvdSBkbyBub3Qgc2VlbSB0byBhZGRyZXNzIC0gdGhlIHBhcmFncmFwaCBp biBTZWN0aW9uIDcuMyBzZWVtcyB0byBzdGF0ZSB0aGF0IFNEIHByb3RlY3Rpb24gY2hhbmdlcw0K IGFjY29yZGluZyB0byB0aGUgbWV0aG9kIHRoYXQgaXMgdXNlZCB0byBkZXRlY3QgdGhlIFNELiBU aGlzIG1lYW5zIHRoYXQgU0QgcHJvdGVjdGlvbiBpcyBub3QgYWdub3N0aWMgdG8gdGhlIG1ldGhv ZCB1c2VkIGZvciB0aGUgZGV0ZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFsdGVybmF0aXZlbHksIHdlIGNvdWxkIGJyZWFrIHRo aXMgZGVwZW5kZW5jZSBhbmQgc3RhdGUgdGhhdCBTRCBwcm90ZWN0aW9uIGlzIGFsd2F5cyBwcm92 aWRlZCBieSBjaGFuZ2luZyB0aGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBkYXRhIHRvIDEmIzQzOzEg cHJvdGVjdGlvbg0KIGluIGNhc2VzIG9mIFNEIGRldGVjdGlvbiwgd2hpY2ggaXMgd2hhdCB0aGUg cGFyYWdyYXBoIGlzIHN1Z2dlc3RpbmcgdG8gZG8gZm9yIHNvbWUgY2FzZXMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5JIGhvcGUgdGhpcyBmb3JtdWxhdGlvbiBtYWtlIG15IGNvbW1lbnQg Y2xlYXJlciBhbmQgd2UgYXJlIGFibGUgdG8gZGlzY3VzcyB0aGUgdGVjaG5vbG9naWNhbCBhcHBy b2FjaCByYXRoZXIgdGhhbiB0aGUgcGhpbG9zb3BoaWNhbCBkaWZmZXJlbmNlcy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rIHlvdSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij55YWFjb3Y8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIE1vbiwgRGVjIDksIDIwMTMgYXQgMTA6MDQg UE0sIFJ5b28sIEplb25nLWRvbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpyeW9vQGV0cmkucmUua3Ii IHRhcmdldD0iX2JsYW5rIj5yeW9vQGV0cmkucmUua3I8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDoxNS4w cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5ZYWFjb3YsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBw dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+WWVzLCBQ U0MgaXMgc3VwcG9zZWQgdG8gYmUgYWdub3N0aWMgdG8gdGhlIG1ldGhvZCB1c2VkIGZvciB0aGUg ZGV0ZWN0aW9uIG9mIFNGL1NELg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SXQgaXMgYWxz byB0cnVlIHRoYXQgYW55IHByb3RlY3Rpb24gc3dpdGNoaW5nIChpbmNsdWRpbmcgUFNDKSBpcyBz dXBwb3NlZCB0byBkZXNjcmliZSB0aGUgb3BlcmF0aW9uIG9mIGJyaWRnZSBhbmQgc2VsZWN0b3Iu DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5l LWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290 aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BcyB0aGVyZSBhcmUgbXVsdGlwbGUgb3B0aW9u cyBmb3IgZGV0ZWN0aW5nIFNELCB3ZSBuZWVkZWQgdG8gZGVzY3JpYmUgdGhlIGJlaGF2aW9yIG9m IHRoZSBicmlkZ2UgdG8gY292ZXIgYWxsIHRoZSBwb3NzaWJsZSBkZXRlY3Rpb24gbWV0aG9kcy4N CiBEZXNjcmliaW5nIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGZvciBTRCBwcm90ZWN0aW9uIGlz IG5vdCBhIG5ldyB0aGluZy4gRm9yIGV4YW1wbGUsIEcuODAzMSAtIEV0aGVybmV0IGxpbmVhciBw cm90ZWN0aW9uIGFsc28gZGVzY3JpYmVzIHdoYXQ8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmJy aWRnZSBjYW48L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1 biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmJlDQogdXNlZCBpbiBvcmRlciB0byBw cm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCBTRC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0 OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ QmVzdCByZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEwLjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTAuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkplb25nLWRvbmc8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTUuMHB0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0i Y2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb20gOg0KPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtZYWFjb3YgV2VpbmdhcnRl biZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnd5YWFjb3ZAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+d3lhYWNvdkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAxMy0x Mi0wOCAyMDowMTo1NSAoICYjNDM7MDk6MDAgKTxicj4NCjxiPlRvIDogPC9iPjxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPC9hPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5v cmc8L2E+Jmd0OywNCjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bXBsc0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2MgOiA8L2I+PGJy Pg0KPGI+U3ViamVjdCA6IDwvYj5RdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dSA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 O2xpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SGksDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BZnRlciByZWFkaW5nIHRocm91 Z2ggeW91ciBkcmFmdCBvbiB0aGUgZXh0ZW5zaW9ucyB0byBQU0MgdG8gc3VwcG9ydCBTRCBzaXR1 YXRpb25zLCBJIGhhdmUgYSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbiAtPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW4geW91ciBpbnRy b2R1Y3Rpb24gLSB5b3Ugc3RhdGUgdGhhdCB0aGUgbWV0aG9kIHVzZWQgdG8gZGV0ZWN0IFNEIHNp dHVhdGlvbnMgaXMgb3V0LW9mLXNjb3BlIG9mIHRoZSBkb2N1bWVudC4gRG9lcyB0aGlzIG1lYW4g dGhhdCBQU0MgaXMgc3VwcG9zZWQNCiB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQg Zm9yIHRoaXMgZGV0ZWN0aW9uPyBJdCBzaG91bGQgcmVhY3Qgb25seSB0byB0aGUgaW5kaWNhdGlv biwgc2ltaWxhcmx5IHRvIHRoZSByZWFjdGlvbiBhbmQgcmVsYXRpb25zaGlwIHRvIHRoZSBtZXRo b2QgZm9yIGRldGVjdGluZyBhbmQgZGVjbGFyaW5nIGEgU0Ygc2l0dWF0aW9uLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhvd2V2ZXIsIHdo ZW4geW91IGV4cGxhaW4gdGhlIGJlaGF2aW9yIG9mIHRoZSBTRCBwcm90ZWN0aW9uIGluIHNlY3Rp b24gNy4zIHlvdSBoYXZlIGEgcGFyYWdyYXBoIHRoYXQgc3RhcnRzIHdpdGggJnF1b3Q7SWYgdGhl IGRldGVjdGlvbiBvZiBhIFNEIGRlcGVuZHMNCiBvbiB0aGUgcHJlc2VuY2Ugb2YgdXNlciBkYXRh IHBhY2tldHMgLi4uJnF1b3Q7ICZuYnNwO3RoYXQgc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUg YmVoYXZpb3Igb2YgdGhlIHN5c3RlbSBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgZGV0ZWN0aW9uIG1l dGhvZCEgQ2xhcmlmaWNhdGlvbiB3b3VsZCBiZSBhcHByZWNpYXRlZC4mbmJzcDsNCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+LS0NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5UaGFueCBhbmQgQlIsDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+eWFhY292PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0Ij48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdGlsbCBsb29r aW5nIGZvciBuZXcgb3Bwb3J0dW5pdHk8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0K PGJyIGNsZWFyPSJhbGwiPg0KPC9zcGFuPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLQ0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW54IGFuZCBCUiwNCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij55YWFjb3Y8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eTwv c3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA43C6F481nkgeml501mbschi_-- From loa@pi.nu Sun Dec 29 23:38:49 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 A423E1AE40C for ; Sun, 29 Dec 2013 23:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.262 X-Spam-Level: X-Spam-Status: No, score=0.262 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 DCoFwFI1slr7 for ; Sun, 29 Dec 2013 23:38:47 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id CFC5C1AE3FF for ; Sun, 29 Dec 2013 23:38:46 -0800 (PST) Received: from [192.168.1.5] (unknown [119.95.140.101]) (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 2501E1800740; Mon, 30 Dec 2013 08:38:35 +0100 (CET) Message-ID: <52C122FE.8090706@pi.nu> Date: Mon, 30 Dec 2013 15:38:38 +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: "vishwas.manral@hp.com" , Rajiv Papneja , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" , Ina Minei , Loa Andersson , Ross Callon , Eric Gray , Eric Rosen , Yakov Rekhter , "mpls@ietf.org" , 'Arun Viswanathan' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" Subject: [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 07:38:49 -0000 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 -- 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 Sun Dec 29 23:49:30 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 8F8891AE429 for ; Sun, 29 Dec 2013 23:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uDkakpfWmJjb for ; Sun, 29 Dec 2013 23:49:26 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4902D1AE264 for ; Sun, 29 Dec 2013 23:49:25 -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; Mon, 30 Dec 2013 16:49:20 +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, 30 Dec 2013 16:49:13 +0900 From: "Ryoo, Jeong-dong" To: Qin Wu , Yaacov Weingarten Thread-Topic: [mpls] Question regarding SD protection in draft-ietf-mpls-tp-psc-itu Thread-Index: AQHPBRH/4khHp6ur2EqtLKlbJ1qSCppsINn5//+boYCAAJkT2Q== Date: Mon, 30 Dec 2013 07:49:12 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AF34E@SMTP2.etri.info> References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AD485@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AEF39@SMTP2.etri.info>, <5B4A6CBE3924BB41A3BEE462A8E0B75A286AF30D@SMTP2.etri.info>, 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_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF34ESMTP2etriinfo_" 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: Mon, 30 Dec 2013 07:49:30 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF34ESMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UWluLA0KDQpUaGUgc2FtZSBhcmd1ZW1lbnQgb24gdGhlIElUVS1UJ3MgcmVxdWlyZW1lbnRzIGhh cyBiZWVuIHJhaXNlZCBhdCB0aGUgcHJldmlvdXMgY29udmVyc2F0aW9ucyB3aXRoIFdHIGNoYWly cy4NClRoZSBhcmd1ZW1lbnQgaXMgdmFsaWQsIGFuZCB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoaXMg ZHJhZnQgd2lsbCBjbGFyaWZ5IGl0Lg0KUmVnYXJkaW5nIHRoZSBicmlkZ2UsIHllcywgeW91ciB1 bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QuIEl0IGlzIGEgY29tYmluYXRpb24gb2YgdGhvc2UgdHdv IGJyaWRnZXMgZGVmaW5lZCBpbiBSRkM2Mzc4Lg0KSG93ZXZlciwgSSBhbSBub3Qgc3VyZSBpZiB3 ZSBuZWVkIHRvIGludHJvZHVjZSBhbnkgbmV3IGFyY2hpdGVjdHVyZSwgYmVjYXVzZSBHLjgwMzEg dXNlcyB0aGUgYnJvYWRjYXN0IGJyaWRnZSBhbmQgZG9lcyBub3QgZGVmaW5lIGFueSBvdGhlciBh cmNoaXRlY3R1cmUgdGhhbiAxKzEgb3IgMToxLiBBY2NvcmRpbmcgdG8gRy44MDMxLCAxKzEgaXMg Zm9yIHBlcm1hbmVudCBicmlkZ2UgYW5kIDE6MSBpcyBmb3Igbm9uIHBlcm1hbmVudCBicmlkZ2Uu IEkgZ3Vlc3MgdGhhdCB3ZSBjYW4gdGhpbmsgdGhlIHNhbWUgd2F5LiBJIHdpbGwgYWxzbyB0cnkg dG8gZmluZCBhcHByb3ByaWF0ZSB0ZXh0IGFuZCBwbGFjZSB0byBjbGFyaWZ5IHRoaXMuDQoNCkJl c3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbSA6ICJRaW4gV3UiIDxiaWxsLnd1QGh1YXdlaS5jb20+DQpTZW50IDog MjAxMy0xMi0zMCAxNjoxNDoyMyAoICswOTowMCApDQpUbyA6IFJ5b28sIEplb25nLWRvbmcgPHJ5 b29AZXRyaS5yZS5rcj4sIFlhYWNvdiBXZWluZ2FydGVuIDx3eWFhY292QGdtYWlsLmNvbT4NCkNj IDogbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4sIGRyYWZ0LWlldGYtbXBscy10cC1wc2Mt aXR1QHRvb2xzLmlldGYub3JnIDxkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRm Lm9yZz4NClN1YmplY3QgOiBSRTogW21wbHNdIFF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0 aW9uIGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQoNCkhpIEplb25nLWRvbmc6DQpUaGFu ayBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLg0KDQpUaGUgdGl0bGUgb2YgeW91ciBkcmFmdCBpcyDi gJxNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBMaW5lYXIgUHJvdGVjdGlvbiBpbiBT dXBwb3J0IG9mIElUVS1UJ3MgUmVxdWlyZW1lbnRz4oCdDQoNCkl0IGlzIG9idmlvdXMgeW91ciBk cmFmdCBpcyBjb21wbGlhbnQgd2l0aCBSRkM2Mzc4Lg0KDQpIb3dldmVyIEkgYW0gd29uZGVyaW5n IHdoYXQgSVRVLVTigJlzIHJlcXVpcmVtZW50cyBhcmU/IEFyZSB0aGVzZSByZXF1aXJlbWVudHMg ZnJvbSBJVFUtVCBkb2N1bWVudCBHLjgwMzEgb3Igc29tZSBvdGhlciBJVFUtVCBkb2N1bWVudHM/ DQoNCkZyb20gdGhpcyBwZXJzcGVjdGl2ZSwgSSB0aGluayBvbmUgSVRVLVQgZG9jdW1lbnQgZGVz Y3JpYmluZyB0aGVzZSByZXF1aXJlbWVudHMgbmVlZHMgdG8gbWVudGlvbmVkIGluIHRoaXMgZHJh ZnQsIGUuZy4sIGluIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbj8NCg0KDQoNCkZvciBhZ25vc3Rp YyBpc3N1ZSwgSSB0aGluayB0aGlzIGlzc3VlIGlzIGFwcGxpZWQgdG8gc2VjdGlvbiA3LjMsIGFz IHlvdSBjbGFyaWZpZWQgZWFybGllciwgdGhlIHNlbGVjdG9yIGlzIG5vdCByZWFsbHkgYnJpZGdl IHNlbGVjdG9yIGJ1dCBvcHRpbWl6ZWQgYnJpZGdlIHNlbGVjdG9yLg0KDQpJIGFtIHdvbmRlcmlu ZyB3aGV0aGVyIGl0IGlzIGNvbWJpbmF0aW9uIG9mIHBlcm1hbmVudCBicmlkZ2UgYW5kIHNlbGVj dG9yIGJyaWRnZSAoVHdvIHRlcm1zIGFyZSBkZWZpbmVkIGluIFJGQzYzNzgpLg0KDQpJZiBpdCBp cywgbXkgcXVlc3Rpb24gaXMgY2FuIHdlIGFwcGx5IDE6MSBwcm90ZWN0aW9uIGFyY2hpdGVjdHVy ZSBhbmQgMSsxIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJlIHRvIGxpbmVhciBwcm90ZWN0aW9uIG1l Y2hhbmlzbSBhdCB0aGUgc2FtZSB0aW1lIG9yDQoNCldlIHNob3VsZCB1c2UgdGhlc2UgcGVybWFu ZW50IGJyaWRnZSBhbmQgc2VsZWN0b3IgYnJpZGdlIHNlcGFyYXRlbHk/DQoNClBsZWFzZSBjb3Jy ZWN0IG1lIGlmIEkgYW0gd3Jvbmcgb3IgbWlzcyBzb21ldGhpbmcuDQoNCg0KUmVnYXJkcyENCi1R aW4NCkZyb206IFJ5b28sIEplb25nLWRvbmcgW21haWx0bzpyeW9vQGV0cmkucmUua3JdDQpTZW50 OiBNb25kYXksIERlY2VtYmVyIDMwLCAyMDEzIDE6MjAgUE0NClRvOiBRaW4gV3U7IFlhYWNvdiBX ZWluZ2FydGVuDQpDYzogbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVA dG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbXBsc10gUXVlc3Rpb24gcmVnYXJkaW5nIFNE IHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUNCg0KUWluLA0KDQpUaGlz IGRyYWZ0IGlzIGJhc2VkIG9uIFJGQzYzNzggZm9yIHRoZSBwcm90b2NvbCBtZXNzYWdlIGZvcm1h dCBhbmQgdGhlIGJhc2ljIG9wZXJhdGlvbmFsIHByaWNpcGxlcywgd2hpY2ggYXJlIGRpZmZlcmVu dCBmcm9tIEcuODAzMS4NClRoZSBpbnRlbnRpb24gb2YgdGhpcyBkcmFmdCBpcyB0byBtYWtlIFJG QzYzNzggYmUgYWxpZ25lZCB3aXRoIEcuODAzMSAob3Igb3RoZXIgSVRVIHByb3RlY3Rpb24gdGVj aG5vbG9naWVzKSBpbiB0aGUgYXNwZWN0cyBvZiAibmV0d29yayBvcGVyYXRpb24iLiBJbiBvdGhl ciB3b3JkcywgaXQgbG9va3MgbGlrZSBHLjgwMzEgKG9yIG90aGVyIElUVSBwcm90ZWN0aW9uIHRl Y2hub2xvZ2llcykgdG8gdGhlIG5ldHdvcmsgb3BlcmF0b3JzLCBidXQgdGhlIGFjdHVhbCBwcm90 b2NvbCBvcGVyYXRpb25zIGFuZCB0aGUgYml0cyBvbiB0aGUgd2lyZSBhcmUgZGlmZmVyZW50Lg0K DQpJIG1lbnRpb25lZCBHLjgwMzEgaW4gbXkgcHJldmlvdXMgZW1haWwgdG8gWWFhY292IGp1c3Qg Zm9yIGJldHRlciBleHBsYW5hdGlvbiwgYW5kIEkgZG9uJ3QgdGhpbmsgdGhpcyBkb2N1bWVudCBu ZWVkcyBHLjgwMzEgYXMgYSByZWZlcmVuY2UuDQpCdXQsIGlmIHlvdSBmaW5kIGFueSBwYXJ0IGlu IHRoaXMgZG9jdW1lbnQgdGhhdCBuZWVkcyBhIHJlZmVyZW5jZSB0byBHLjgwMzEsIHBsZWFzZSBs ZXQgdXMga25vdy4NCg0KWW91IGFuZCBZYWFjb3YgbWlnaHQgYmUgcmlnaHQgb24gdGhlIHNlbnRl bmNlICJTRCBwcm90ZWN0b24gaXMgbm90IGFnbm9zdGljIHRvIHRoZSBkZXRlY3Rpb24gbWV0aG9k Ii4NCkJ1dCwgYXMgSSBzYWlkLCBteSBvcmlnaW5hbCBpbnRlbnRpb24gYW5kIHdoYXQgd2Ugd2Fu dGVkIHRvIGFjaGlldmUgaW4gdGhpcyBkb2N1bWVudCBhcmUgdGhhdCB0aGUgcHJvdGVjdGlvbiBz cGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBjb3ZlcnMgU0Qgbm8gbWF0dGVyIHdoYXQga2luZCBv ZiBTRCBkZXRlY3Rpb24gbWV0aG9kcyBzaG91ZCBiZSB1c2VkLg0KQnkgdGhlIHdheSwgdGhpcyBk cmFmdCBkb2VzIG5vdCBoYXZlIGEgd29yZCAiYWdub3N0aWMiLg0KDQpCZXN0IHJlZ2FyZHMsDQoN Ckplb25nLWRvbmcNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b20gOiAiUWluIFd1IiA8YmlsbC53dUBodWF3ZWkuY29tPg0KU2VudCA6IDIwMTMtMTItMzAgMTI6 NDg6MjcgKCArMDk6MDAgKQ0KVG8gOiBSeW9vLCBKZW9uZy1kb25nIDxyeW9vQGV0cmkucmUua3I+ LCBZYWFjb3YgV2VpbmdhcnRlbiA8d3lhYWNvdkBnbWFpbC5jb20+DQpDYyA6IG1wbHNAaWV0Zi5v cmcgPG1wbHNAaWV0Zi5vcmc+LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRm Lm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0 IDogUkU6IFttcGxzXSBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1p ZXRmLW1wbHMtdHAtcHNjLWl0dQ0KU29ycnkgdG8gaW50ZXJydXB0IGluLg0KSSBhbSBhIGxpdHRs ZSBiaXQgc3VycHJpc2VkIHRoaXMgZHJhZnQgaGFzIG5vdCBhbnkgcmVmZXJlbmNlIHRvIElUVSBk b2N1bWVudC4NCkkgYW0gd29uZGVyaW5nIGhvdyBtdWNoIHRoaXMgZHJhZnQgaXMgY29tcGxpYW50 IHdpdGggRy44MDMxPyBJcyB0aGVyZSBhbnkgdHdlYWsgb3Igb3B0aW1pemF0aW9uIHRvIEcuODMx Pw0KV2hhdCBpcyB0aGUgY29uY2VybiBvZiBHLjgzMSB0aGlzIGRyYWZ0IGlzIGRlYWxpbmcgd2l0 aD8NCklmIGFueXRoaW5nIGlzIGZyb20gRy44MzEgb3IgYW55IG90aGVyIElUVSBkb2N1bWVudCwg SSB0aGluayBpdCBpcyBmaW5lLCBob3dldmVyIEcuODMxIG9yIHNvbWUgb3RoZXIgSVRVIGRvY3Vt ZW50cyBhcmUgd29ydGggYmVpbmcgcmVmZXJlbmNlZC4NCg0KSWYgdGhpcyBkcmFmdCBpcyBmb2N1 c2luZyBvbiBhZGRyZXNzaW5nIEcuODMxLCBpdCBpcyBiZXR0ZXIgdG8gY2xhcmlmeSB0aGlzIGEg bGl0dGxlIGJpdCBpbiB0aGlzIGRyYWZ0Lg0KDQpNeSBmZWVsaW5nIGlzIHRoaXMgZHJhZnQgc2Vl bXMgdG8gaW50cm9kdWNlIGNvbWJpbmF0aW9uIG9mIDErMSBhbmQgMToxIHByb3RlY3Rpb24gYXJj aGl0ZWN0dXJlIHdoZW4gSSByZWFkDQrigJwNCkFzIHlvdSBtaWdodCByZWNhbGwgZnJvbSBHLjgw MzEg4oCTIEV0aGVybmV0IGxpbmVhciBwcm90ZWN0aW9uLCB0aGUgc2VsZWN0b3IgYnJpZGdlIGlz IG5vdCByZWNvbW1lbmRlZCBkdWUgdG8gdGhlIHRyYWZmaWMgZmxhcHBpbmcgdW5kZXIgU0QgY29u ZGl0aW9ucyBvbiBib3RoIHBhdGhzLiBJbnN0ZWFkIOKAnGJyb2FkY2FzdCBicmlkZ2XigJ0gaXMg aW50cm9kdWNlZCB0byBzdXBwb3J0IHByb3RlY3Rpb24gc3dpdGNoaW5nIGFnYWluc3QgU0QuIEJ1 dCwgdGhpcyBicm9hZGNhc3QgYnJpZGdlIGlzIG5vdCByZWNvbW1lbmRlZCBpbiBub24tcmV2ZXJ0 aXZlIG1vZGUgYXMgdGhlIHdvcmtpbmcgcGF0aCBuZWVkcyB0byBiZSBvY2N1cGllZCBieSB0cmFm ZmljIGFsbCB0aGUgdGltZS4gQWxzbyB0aGUgYnJvYWRjYXN0IGJyaWRnZSBpcyBub3QgZWZmaWNp ZW50LCBzaW5jZSBieSBkZWZpbml0aW9uLCB0aGUgcGFja2V0IGR1cGxpY2F0aW9uIHNob3VsZCBv Y2N1ciBkdXJpbmcgbm90IG9ubHkgU0QgYnV0IGFsc28gU0YsIEZTLCBNUywgZXRjLiBJbiB0aGlz IGRvY3VtZW50LCB3ZSBhcmUgaW50cm9kdWNpbmcgYW4gaW1wcm92ZWQgYnJpZGdlIG1lY2hhbmlz bSwgd2hpY2ggYmVoYXZlcyBsaWtlIGEgc2VsZWN0b3IgYnJpZGdlIGJ1dCBkdXBsaWNhdGVzIHRo ZSB0cmFmZmljIG9ubHkgdW5kZXIgU0QgY29uZGl0aW9uLCBhbmQgd2UgYmVsaWV2ZSB0aGF0IGl0 IGFkZHJlc3NlcyBhbGwgdGhlIGlzc3VlcyB3aXRoIGV4aXN0aW5nIGJyaWRnZXMuDQoNCuKAnSwN CkkgdGVuZCB0byBhZ3JlZSBZYWNjb3YgdGhhdCBTRCBwcm90ZWN0aW9uIGlzIG5vdCBhZ25vc3Rp YyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoZSBkZXRlY3Rpb24uDQpBbHNvIEkgYW0gaW50ZXJl c3RlZCB0byBrbm93IGhvdyB0byBwb3NpdGlvbiBicmlkZ2UgYW5kIHNlbGVjdG9yIGluIHRoZSBN UExTIGFyY2hpdGVjdHVyZT8NCg0KUmVnYXJkcyENCi1RaW4NCg0KRnJvbTptcGxzIFttYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUnlvbywgSmVvbmctZG9uZw0KU2Vu dDogVGh1cnNkYXksIERlY2VtYmVyIDI2LCAyMDEzIDEyOjUxIFBNDQpUbzogWWFhY292IFdlaW5n YXJ0ZW4NCkNjOiBtcGxzQGlldGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29s cy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBRdWVzdGlvbiByZWdhcmRpbmcgU0QgcHJv dGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dQ0KDQpZYWFjb3YsIHRoYW5rcyBm b3IgeW91ciBlbWFpbC4gU29tZWhvdywgSSBmb3Jnb3QgdG8gcmVzcG9uZCBhbmQgYW0gc29ycnkg Zm9yIHRoZSBkZWxheS4NCg0KRmlyc3Qgb2YgYWxsLCBZYWFjb3YsIGl0IGlzIG5vdCB0cnVlIHRo YXQgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIG9mIEV0aGVybmV0IG9yIFNESCBkZXNjcmliZXMg dGhlIG9wZXJhdGlvbiBvZiBhbnkgbGF5ZXIgYmVsb3cuIFJhdGhlciwgZWFjaCBsYXllciBpcyBz dXBwb3NlZCB0byBvcGVyYXRlIGluZGVwZW5kZW50bHkuIEhvd2V2ZXIsIHRoZXJlIGFyZSBhIGZl dyBleGNlcHRpb25zLCBzdWNoIGFzIGhvbGQtb2ZmIHRpbWVyIGFuZCBBSVMgKGFzIGEgdHJpZ2dl ciBmcm9tIGxvd2VyIGxheWVyKS4gRXZlbiB0aG91Z2ggdGhlcmUgZXhpc3Qgc29tZSBwcm9wcmll dGFyeSBpbXBsZW1lbnRhdGlvbnMgdGhhdCB1c2Ugb3RoZXIgaW5mb3JtYXRpb24gZnJvbSBsb3dl ciBsYXllciwgbW9zdCBvZiB0aGVtIGFyZSBub3QgcmVjb21tZW5kZWQgaW4gSVRVLVQgc3RhbmRh cmRzLg0KDQpCcmlkZ2UgYW5kIHNlbGVjdG9yIGFyZSBub3QgaW4gdGhlIHBoeXNpY2FsIGxheWVy LCBidXQgdGhleSBhcmUgcGFydCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZy4gT25lIG9mIHRoZSBp bXBvcnRhbnQgb3V0cHV0IGFjdGlvbnMgZnJvbSB0aGUgUFNDIGNvbnRyb2wgbG9naWMgaXMgY29v cmRpbmF0aW5nIHRoZSBwb3NpdGlvbnMgb2YgYnJpZGdlIGFuZCBzZWxlY3Rvci4gQWxzbywgdGhl IGJyaWRnZSBvcGVyYXRpb24gcmVzcG9uZGluZyB0byB0aGUgUFNDIGNvbnRyb2wgbG9naWMgaXMg YWxzbyBwYXJ0IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nLiBIb3dldmVyLCBob3cgdG8gcmVhbGl6 ZSB0aGUgYnJpZGdlIGFuZCBzZWxlY3RvciAoZm9yIGV4YW1wbGUsIGhvdyB0byBtYW5pcHVsYXRl IGEgcGFja2V0IGZvcndhcmRpbmcgbWVjaGFuaXNtKSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0 ZXIuDQoNCldoZW4gd2UgbWVudGlvbiAxKzEgb3IgMToxIGluIHByb3RlY3Rpb24gYXJjaGl0ZWN0 dXJlLCB3ZSBkZWFsIHdpdGggdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UuIEZvciAxKzEgYXJjaGl0 ZWN0dXJlLCB0aGUgdHJhZmZpYyBuZWVkcyB0byBiZSBkdXBsaWNhdGVkIGF0IHRoZSBzZW5kZXIg YW5kIHNlbnQgdG8gYm90aCBwYXRocyBhbGwgdGhlIHRpbWUsIHdoaWNoIGlzIHRoZSBzYW1lIGRl c2NyaXB0aW9uIGFzIHRoZSDigJxwZXJtYW5lbnQgYnJpZGdl4oCdLiBGb3IgMToxIGFyY2hpdGVj dHVyZSwg4oCcc2VsZWN0b3IgYnJpZGdl4oCdIGlzIHVzZWQgdG8gc2VuZCB0aGUgdHJhZmZpYyBv bmx5IG9uZSBvZiB0aGUgcGF0aHMuIEFzIHRoZSBwcm90ZWN0aW9uIHBhdGggY2FuIGJlIHVzZWQg YnkgYmVzdCB0cmFmZmljIGluIHBhY2tldCBuZXR3b3JrcyBhbmQgdGhlIHBhY2tldCBkdXBsaWNh dGlvbiB0YWtlcyBtdWNoIG1vcmUgZWZmb3J0L2ludGVybmFsIGJhbmR3aWR0aCBpbnNpZGUgYSBz d2l0Y2ggdGhhbiB0aGUgdGltZSBzbG90IGNvcHkgb2YgY2lyY3VpdCBuZXR3b3Jrcy4gMToxIGlz IGNvbnNpZGVyZWQgYXMgcHJlZmVyYWJsZSBhcmNoaXRlY3R1cmUgaW4gcGFja2V0IG5ldHdvcmtz Lg0KDQpBcyB5b3UgbWlnaHQgcmVjYWxsIGZyb20gRy44MDMxIOKAkyBFdGhlcm5ldCBsaW5lYXIg cHJvdGVjdGlvbiwgdGhlIHNlbGVjdG9yIGJyaWRnZSBpcyBub3QgcmVjb21tZW5kZWQgZHVlIHRv IHRoZSB0cmFmZmljIGZsYXBwaW5nIHVuZGVyIFNEIGNvbmRpdGlvbnMgb24gYm90aCBwYXRocy4g SW5zdGVhZCDigJxicm9hZGNhc3QgYnJpZGdl4oCdIGlzIGludHJvZHVjZWQgdG8gc3VwcG9ydCBw cm90ZWN0aW9uIHN3aXRjaGluZyBhZ2FpbnN0IFNELiBCdXQsIHRoaXMgYnJvYWRjYXN0IGJyaWRn ZSBpcyBub3QgcmVjb21tZW5kZWQgaW4gbm9uLXJldmVydGl2ZSBtb2RlIGFzIHRoZSB3b3JraW5n IHBhdGggbmVlZHMgdG8gYmUgb2NjdXBpZWQgYnkgdHJhZmZpYyBhbGwgdGhlIHRpbWUuIEFsc28g dGhlIGJyb2FkY2FzdCBicmlkZ2UgaXMgbm90IGVmZmljaWVudCwgc2luY2UgYnkgZGVmaW5pdGlv biwgdGhlIHBhY2tldCBkdXBsaWNhdGlvbiBzaG91bGQgb2NjdXIgZHVyaW5nIG5vdCBvbmx5IFNE IGJ1dCBhbHNvIFNGLCBGUywgTVMsIGV0Yy4gSW4gdGhpcyBkb2N1bWVudCwgd2UgYXJlIGludHJv ZHVjaW5nIGFuIGltcHJvdmVkIGJyaWRnZSBtZWNoYW5pc20sIHdoaWNoIGJlaGF2ZXMgbGlrZSBh IHNlbGVjdG9yIGJyaWRnZSBidXQgZHVwbGljYXRlcyB0aGUgdHJhZmZpYyBvbmx5IHVuZGVyIFNE IGNvbmRpdGlvbiwgYW5kIHdlIGJlbGlldmUgdGhhdCBpdCBhZGRyZXNzZXMgYWxsIHRoZSBpc3N1 ZXMgd2l0aCBleGlzdGluZyBicmlkZ2VzLg0KDQpXaGF0IHdlIG1lYW4gYnkgU0QgcHJvdGVjdGlv biBpcyBhZ25vc3RpYyB0byB0aGUgU0QgZGV0ZWN0aW9uIG1ldGhvZCBpcyB0aGF0IHRoZSBwcm9w b3NlZCBTRCBwcm90ZWN0aW9uIG1ldGhvZCAoYWdhaW4gaG93IHRvIG9wZXJhdGUgYSBicmlkZ2Ug b3Igd2hhdCBicmlnZSBpcyB1c2VkIGlzIGEgcGFydCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZykg Y2FuIGJlIHVzZWQgbm8gbWF0dGVyIHdoYXQga2luZCBvZiBTRCBkZXRlY3Rpb24gbWV0aG9kcyAo ZGF0YSBwYWNrZXQgY291bnRpbmcsIENDTSBwYWNrZXQgY291bnRpbmcsIG9yIGV2ZW4gcHJvcHJp ZXRhcnkgc2VydmVyIGxheWVyIFNEIGRldGVjdGlvbikgaXMgdXNlZC4NCg0KSSB0aGluayBJIGFu c3dlcmVkIGFsbCB0aGUgcXVlc3Rpb25zIG9uIHlvdXIgZW1haWwuDQoNCllhYWNvdiwgaWYgeW91 IGhhdmUgYW55IGZ1cnRoZXIgY29uY2VybnMgb3IgcXVlc3Rpb25zLCBwbGVhc2UgbGV0IG1lIGtu b3cuDQoNCkJlc3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tIDogIllhYWNvdiBXZWluZ2FydGVuIiA8d3lhYWNvdkBnbWFp bC5jb20+DQpTZW50IDogMjAxMy0xMi0xMCAxNjowNDoxNyAoICswOTowMCApDQpUbyA6IFJ5b28s IEplb25nLWRvbmcgPHJ5b29AZXRyaS5yZS5rcj4NCkNjIDogZHJhZnQtaWV0Zi1tcGxzLXRwLXBz Yy1pdHVAdG9vbHMuaWV0Zi5vcmcgPGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmll dGYub3JnPiwgbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4NClN1YmplY3QgOiBSZTogUXVl c3Rpb24gcmVnYXJkaW5nIFNEIHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1p dHUNCkplb25nLWRvbmcsIGhpDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXBseS4gWW91ciBhbnN3 ZXIgc2VlbXMgdG8gYmUgYW4gYXBwcm9wcmlhdGUgYW5zd2VyIGZvciBvdGhlciBTRE9zLCBub3Qg c3VyZSB0aGF0IGl0IGlzIHRydWUgZm9yIHRoZSBjb250ZXh0IG9mIE1QTFMgYW5kIElFVEYgd29y ay4NCg0KMS4gWW91IHdyb3RlICJhbnkgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgKGluY2x1ZGluZyBQ U0MpIGlzIHN1cHBvc2VkIHRvIGRlc2NyaWJlIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGFuZCBz ZWxlY3Rvci4iIC0gdGhpcyBtYXkgYmUgdHJ1ZSBmb3IgRXRoZXJuZXQgYW5kIFNESCBhbmQgZm9y IGRvY3VtZW50cyB0aGF0IGFyZSBkZXNjcmliaW5nIHRoZSBvcGVyYXRpb24gb2YgdGhlIHBoeXNp Y2FsIGxheWVyLiBIb3dldmVyLCB0aGUgSUVURiAodG8gbXkgdW5kZXJzdGFuZGluZyAtIGFuZCBJ IGFtIGNlcnRhaW5seSB3aWxsaW5nIHRvIGJlIGNvcnJlY3RlZCBvbiB0aGlzIHBvaW50KSBpcyBj b25jZXJuZWQgd2l0aCB0aGUgcHJvdG9jb2wgYW5kIGxlYXZlIHRoZSBsb3dlciBsYXllcnMgdG8g aW1wbGVtZW50YXRpb24uIEFsc28sIEkgYW0gbm90IHN1cmUgdGhhdCB0aGUgY29uY2VwdHMgb2Yg QnJpZGdlIGFuZCBTZWxlY3RvciByZWFsbHkgYXBwbHkgdG8gTVBMUyAoYWx0aG91Z2ggSSBhZG1p dCB0aGF0IHdlIGRpZCBtZW50aW9uIHRoZW0gaW4gdGhlIG9yaWdpbmFsIFBTQyBkZWZpbml0aW9u KS4NCg0KMi4gWW91IGNpdGUgd2hhdCB3YXMgd3JpdHRlbiBpbiBHODAzMSBhcyBqdXN0aWZpY2F0 aW9uIGZvciBpbmNsdWRpbmcgY29udGVudCBpbnRvIHlvdXIgZHJhZnQuIEFnYWluIGl0IGlzIGhh cmQgdG8gdHJhbnNmZXIgbWV0aG9kb2xvZ3kgZnJvbSBvbmUgU0RPIHRvIGFub3RoZXIgYW5kIHRo ZXJlZm9yZSwgd2hpbGUgSSBoaWdobHkgcmVzcGVjdCB0aGUgd29yayBvZiB0aGUgSVRVLCBJIGRv IG5vdCBmZWVsIHRoYXQgdGhpcyBpcyBhIHZlcnkgY2xlYXIganVzdGlmaWNhdGlvbiBmb3IgaW5j bHVzaW9uIGludG8gYW4gaW50ZXJuZXQtZHJhZnQuIEV2ZW4gd2hlbiB0aGUgZHJhZnQgc3RhdGVz IHRoYXQgaXRzIHB1cnBvc2UgaXMgdG8gYWRkcmVzcyB0aGUgY29uY2VybnMgb2YgdGhlIElUVS4N Cg0KMy4gVG8gdGhlIGFjdHVhbCBwb2ludCBvZiBteSBlYXJsaWVyIGNvbW1lbnQsIHRoYXQgeW91 IGRvIG5vdCBzZWVtIHRvIGFkZHJlc3MgLSB0aGUgcGFyYWdyYXBoIGluIFNlY3Rpb24gNy4zIHNl ZW1zIHRvIHN0YXRlIHRoYXQgU0QgcHJvdGVjdGlvbiBjaGFuZ2VzIGFjY29yZGluZyB0byB0aGUg bWV0aG9kIHRoYXQgaXMgdXNlZCB0byBkZXRlY3QgdGhlIFNELiBUaGlzIG1lYW5zIHRoYXQgU0Qg cHJvdGVjdGlvbiBpcyBub3QgYWdub3N0aWMgdG8gdGhlIG1ldGhvZCB1c2VkIGZvciB0aGUgZGV0 ZWN0aW9uLg0KQWx0ZXJuYXRpdmVseSwgd2UgY291bGQgYnJlYWsgdGhpcyBkZXBlbmRlbmNlIGFu ZCBzdGF0ZSB0aGF0IFNEIHByb3RlY3Rpb24gaXMgYWx3YXlzIHByb3ZpZGVkIGJ5IGNoYW5naW5n IHRoZSB0cmFuc21pc3Npb24gb2YgdGhlIGRhdGEgdG8gMSsxIHByb3RlY3Rpb24gaW4gY2FzZXMg b2YgU0QgZGV0ZWN0aW9uLCB3aGljaCBpcyB3aGF0IHRoZSBwYXJhZ3JhcGggaXMgc3VnZ2VzdGlu ZyB0byBkbyBmb3Igc29tZSBjYXNlcy4NCg0KSSBob3BlIHRoaXMgZm9ybXVsYXRpb24gbWFrZSBt eSBjb21tZW50IGNsZWFyZXIgYW5kIHdlIGFyZSBhYmxlIHRvIGRpc2N1c3MgdGhlIHRlY2hub2xv Z2ljYWwgYXBwcm9hY2ggcmF0aGVyIHRoYW4gdGhlIHBoaWxvc29waGljYWwgZGlmZmVyZW5jZXMu DQoNClRoYW5rIHlvdSwNCnlhYWNvdg0KDQpPbiBNb24sIERlYyA5LCAyMDEzIGF0IDEwOjA0IFBN LCBSeW9vLCBKZW9uZy1kb25nIDxyeW9vQGV0cmkucmUua3I8bWFpbHRvOnJ5b29AZXRyaS5yZS5r cj4+IHdyb3RlOg0KWWFhY292LA0KDQpZZXMsIFBTQyBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3Rp YyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoZSBkZXRlY3Rpb24gb2YgU0YvU0QuDQoNCkl0IGlz IGFsc28gdHJ1ZSB0aGF0IGFueSBwcm90ZWN0aW9uIHN3aXRjaGluZyAoaW5jbHVkaW5nIFBTQykg aXMgc3VwcG9zZWQgdG8gZGVzY3JpYmUgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgYW5kIHNlbGVj dG9yLg0KDQpBcyB0aGVyZSBhcmUgbXVsdGlwbGUgb3B0aW9ucyBmb3IgZGV0ZWN0aW5nIFNELCB3 ZSBuZWVkZWQgdG8gZGVzY3JpYmUgdGhlIGJlaGF2aW9yIG9mIHRoZSBicmlkZ2UgdG8gY292ZXIg YWxsIHRoZSBwb3NzaWJsZSBkZXRlY3Rpb24gbWV0aG9kcy4gRGVzY3JpYmluZyB0aGUgb3BlcmF0 aW9uIG9mIGJyaWRnZSBmb3IgU0QgcHJvdGVjdGlvbiBpcyBub3QgYSBuZXcgdGhpbmcuIEZvciBl eGFtcGxlLCBHLjgwMzEgLSBFdGhlcm5ldCBsaW5lYXIgcHJvdGVjdGlvbiBhbHNvIGRlc2NyaWJl cyB3aGF0IGJyaWRnZSBjYW4gYmUgdXNlZCBpbiBvcmRlciB0byBwcm92aWRlIHByb3RlY3Rpb24g YWdhaW5zdCBTRC4NCg0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb20gOiAiWWFhY292IFdlaW5nYXJ0ZW4iIDx3eWFh Y292QGdtYWlsLmNvbTxtYWlsdG86d3lhYWNvdkBnbWFpbC5jb20+Pg0KU2VudCA6IDIwMTMtMTIt MDggMjA6MDE6NTUgKCArMDk6MDAgKQ0KVG8gOiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0 b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0 Zi5vcmc+IDxkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZzxtYWlsdG86 ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+PiwgbXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4gPG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+Pg0KQ2MgOg0KU3ViamVjdCA6IFF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9uIGlu IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1DQoNCkhpLA0KDQpBZnRlciByZWFkaW5nIHRocm91 Z2ggeW91ciBkcmFmdCBvbiB0aGUgZXh0ZW5zaW9ucyB0byBQU0MgdG8gc3VwcG9ydCBTRCBzaXR1 YXRpb25zLCBJIGhhdmUgYSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbiAtDQpJbiB5b3VyIGlu dHJvZHVjdGlvbiAtIHlvdSBzdGF0ZSB0aGF0IHRoZSBtZXRob2QgdXNlZCB0byBkZXRlY3QgU0Qg c2l0dWF0aW9ucyBpcyBvdXQtb2Ytc2NvcGUgb2YgdGhlIGRvY3VtZW50LiBEb2VzIHRoaXMgbWVh biB0aGF0IFBTQyBpcyBzdXBwb3NlZCB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQg Zm9yIHRoaXMgZGV0ZWN0aW9uPyBJdCBzaG91bGQgcmVhY3Qgb25seSB0byB0aGUgaW5kaWNhdGlv biwgc2ltaWxhcmx5IHRvIHRoZSByZWFjdGlvbiBhbmQgcmVsYXRpb25zaGlwIHRvIHRoZSBtZXRo b2QgZm9yIGRldGVjdGluZyBhbmQgZGVjbGFyaW5nIGEgU0Ygc2l0dWF0aW9uLg0KSG93ZXZlciwg d2hlbiB5b3UgZXhwbGFpbiB0aGUgYmVoYXZpb3Igb2YgdGhlIFNEIHByb3RlY3Rpb24gaW4gc2Vj dGlvbiA3LjMgeW91IGhhdmUgYSBwYXJhZ3JhcGggdGhhdCBzdGFydHMgd2l0aCAiSWYgdGhlIGRl dGVjdGlvbiBvZiBhIFNEIGRlcGVuZHMgb24gdGhlIHByZXNlbmNlIG9mIHVzZXIgZGF0YSBwYWNr ZXRzIC4uLiIgIHRoYXQgc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgYmVoYXZpb3Igb2YgdGhl IHN5c3RlbSBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgZGV0ZWN0aW9uIG1ldGhvZCEgQ2xhcmlmaWNh dGlvbiB3b3VsZCBiZSBhcHByZWNpYXRlZC4NCg0KLS0NClRoYW54IGFuZCBCUiwNCnlhYWNvdg0K DQpTdGlsbCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHkNCg0KDQoNCg0KLS0NClRoYW54IGFu ZCBCUiwNCnlhYWNvdg0KDQpTdGlsbCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHkNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF34ESMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5RaW4sPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+VGhlIHNhbWUgYXJndWVtZW50IG9uIHRoZSBJVFUtVCdzIHJlcXVpcmVtZW50cyBoYXMgYmVl biByYWlzZWQgYXQmbmJzcDt0aGUgcHJldmlvdXMgY29udmVyc2F0aW9ucyB3aXRoIFdHIGNoYWly cy48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5UaGUgYXJndWVtZW50IGlz IHZhbGlkLCBhbmQgdGhlIG5leHQgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IHdpbGwgY2xhcmlmeSBp dC4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPlJlZ2FyZGlu ZyB0aGUgYnJpZGdlLCB5ZXMsIHlvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LiBJdCBpcyBh IGNvbWJpbmF0aW9uIG9mIHRob3NlIHR3byBicmlkZ2VzIGRlZmluZWQgaW4gUkZDNjM3OC48L2Rp dj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Ib3dldmVyLCBJIGFtIG5vdCBzdXJl IGlmIHdlIG5lZWQgdG8gaW50cm9kdWNlIGFueSBuZXcgYXJjaGl0ZWN0dXJlLCBiZWNhdXNlIEcu ODAzMSB1c2VzIHRoZSBicm9hZGNhc3QgYnJpZGdlIGFuZCZuYnNwO2RvZXMgbm90IGRlZmluZSZu YnNwO2FueSBvdGhlciBhcmNoaXRlY3R1cmUgdGhhbiAxJiM0MzsxJm5ic3A7b3IgMToxLiBBY2Nv cmRpbmcgdG8gRy44MDMxLCAxJiM0MzsxIGlzIGZvciBwZXJtYW5lbnQgYnJpZGdlIGFuZCAxOjEN CiBpcyBmb3Igbm9uIHBlcm1hbmVudCBicmlkZ2UuIEkgZ3Vlc3MgdGhhdCZuYnNwO3dlIGNhbiB0 aGluayB0aGUgc2FtZSB3YXkuIEkgd2lsbCBhbHNvIHRyeSB0byBmaW5kIGFwcHJvcHJpYXRlIHRl eHQgYW5kJm5ic3A7cGxhY2UgdG8gY2xhcmlmeSB0aGlzLg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCI+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQi PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRvbmc8 L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij48YnI+DQombmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdCI+PGI+RnJvbSA6IDwvYj4mcXVvdDtRaW4gV3UmcXVvdDsgJmx0O2JpbGwud3VA aHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMtMTItMzAgMTY6MTQ6MjMgKCAm IzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5SeW9vLCBKZW9uZy1kb25nICZsdDtyeW9vQGV0 cmkucmUua3ImZ3Q7LCBZYWFjb3YgV2VpbmdhcnRlbiAmbHQ7d3lhYWNvdkBnbWFpbC5jb20mZ3Q7 PGJyPg0KPGI+Q2MgOiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssIGRy YWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnICZsdDtkcmFmdC1pZXRmLW1w bHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0IDogPC9iPlJF OiBbbXBsc10gUXVlc3Rpb24gcmVnYXJkaW5nIFNEIHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHU8YnI+DQo8YnI+DQo8L2Rpdj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPnZc OiogewoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpCn0Kb1w6KiB7CglCRUhBVklPUjogdXJs KCNkZWZhdWx0I1ZNTCkKfQp3XDoqIHsKCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQp9Ci5z aGFwZSB7CglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkKfQo8L3N0eWxlPjxzdHlsZT5AZm9u dC1mYWNlIHsKCWZvbnQtZmFtaWx5OiDlrovkvZM7Cn0KQGZvbnQtZmFjZSB7Cglmb250LWZhbWls eTogQ2FtYnJpYSBNYXRoOwp9CkBmb250LWZhY2UgewoJZm9udC1mYW1pbHk6IENhbGlicmk7Cn0K QGZvbnQtZmFjZSB7Cglmb250LWZhbWlseTogVGFob21hOwp9CkBmb250LWZhY2UgewoJZm9udC1m YW1pbHk6IEDlrovkvZM7Cn0KQGZvbnQtZmFjZSB7Cglmb250LWZhbWlseTogTWFsZ3VuIEdvdGhp YzsKfQpAZm9udC1mYWNlIHsKCWZvbnQtZmFtaWx5OiDrp5HsnYDqs6DrlJU7Cn0KQGZvbnQtZmFj ZSB7Cglmb250LWZhbWlseTogQE1hbGd1biBHb3RoaWM7Cn0KQGZvbnQtZmFjZSB7Cglmb250LWZh bWlseTogQOunkeydgOqzoOuUlTsKfQpAcGFnZSBXb3JkU2VjdGlvbjEge3NpemU6IDYxMi4wcHQg NzkyLjBwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7IH0KUC5Nc29Ob3Jt YWwgewoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7IEZPTlQtU0laRTogMTJwdAp9CkxJLk1zb05vcm1hbCB7CglNQVJHSU46IDBjbSAw Y20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgRk9OVC1TSVpF OiAxMnB0Cn0KRElWLk1zb05vcm1hbCB7CglNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlM WTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgRk9OVC1TSVpFOiAxMnB0Cn0KQTpsaW5rIHsK CUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9y aXR5OiA5OQp9ClNQQU4uTXNvSHlwZXJsaW5rIHsKCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJ T046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQp9CkE6dmlzaXRlZCB7CglDT0xP UjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5 OiA5OQp9ClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgewoJQ09MT1I6IHB1cnBsZTsgVEVYVC1E RUNPUkFUSU9OOiB1bmRlcmxpbmU7IG1zby1zdHlsZS1wcmlvcml0eTogOTkKfQpQIHsKCU1BUkdJ TjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOyBG T05ULVNJWkU6IDEycHQ7IG1zby1zdHlsZS1wcmlvcml0eTogOTkKfQpQUkUgewoJTUFSR0lOOiAw Y20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJDb3VyaWVyIE5ldyI7IEZPTlQtU0laRTogMTJwdDsg bXNvLXN0eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLWxpbms6ICJIVE1MIOmihOiuvuagvOW8 jyBDaGFyIgp9ClNQQU4uRW1haWxTdHlsZTE4IHsKCUZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOyBDT0xPUjogIzFmNDk3ZDsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsCn0KU1BB Ti5FbWFpbFN0eWxlMTkgewoJRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IENP TE9SOiAjMWY0OTdkOyBtc28tc3R5bGUtdHlwZTogcGVyc29uYWwtcmVwbHkKfQpTUEFOLkhUTUxD aGFyIHsKCUZPTlQtRkFNSUxZOiAiQ291cmllciBOZXciOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5 OyBtc28tc3R5bGUtbGluazogIkhUTUwg6aKE6K6+5qC85byPIjsgbXNvLXN0eWxlLW5hbWU6ICJI VE1MIOmihOiuvuagvOW8jyBDaGFyIgp9Ci5Nc29DaHBEZWZhdWx0IHsKCUZPTlQtU0laRTogMTBw dDsgbXNvLXN0eWxlLXR5cGU6IGV4cG9ydC1vbmx5Cn0KRElWLldvcmRTZWN0aW9uMSB7CglwYWdl OiBXb3JkU2VjdGlvbjEKfQo8L3N0eWxlPg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQi IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9O VC1TSVpFOiAxMXB0Ij5IaSBKZW9uZy1kb25nOg0KPD94bWw6bmFtZXNwYWNlIHByZWZpeCA9IG8g bnMgPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiAvPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpF OiAxMXB0Ij5UaGFuayBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwcmU+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYn OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5UaGUgdGl0bGUgb2YgeW91ciBkcmFm dCBpcyDigJxNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBMaW5lYXIgUHJvdGVjdGlv biBpbiBTdXBwb3J0IG9mIElUVS1UJ3MgUmVxdWlyZW1lbnRz4oCdPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNl cmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+SXQgaXMgb2J2aW91cyB5b3Vy IGRyYWZ0IGlzIGNvbXBsaWFudCB3aXRoIFJGQzYzNzguPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsg Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+SG93ZXZlciBJIGFtIHdvbmRlcmluZyB3 aGF0IElUVS1U4oCZcyByZXF1aXJlbWVudHMgYXJlPyBBcmUgdGhlc2UgcmVxdWlyZW1lbnRzIGZy b20gSVRVLVQgZG9jdW1lbnQgRy44MDMxIG9yIHNvbWUgb3RoZXIgSVRVLVQgZG9jdW1lbnRzPzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD YWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkZy b20gdGhpcyBwZXJzcGVjdGl2ZSwgSSB0aGluayBvbmUgSVRVLVQgZG9jdW1lbnQgZGVzY3JpYmlu ZyB0aGVzZSByZXF1aXJlbWVudHMgPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nh bGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+bmVl ZHMgdG88L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2Vy aWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij4gbWVudGlvbmVkIGluIHRoaXMg ZHJhZnQsIGUuZy4sIDwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywn c2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPmluIHRoZSBpbnRy b2R1Y3Rpb24gc2VjdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsg Rk9OVC1TSVpFOiAxMXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFm NDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5Gb3IgYWdub3N0aWMgaXNzdWUsIEkgdGhpbmsgdGhpcyBp c3N1ZSBpcyBhcHBsaWVkIHRvIHNlY3Rpb24gNy4zLCBhcyB5b3UgY2xhcmlmaWVkIGVhcmxpZXIs IHRoZSBzZWxlY3RvciBpcyBub3QgcmVhbGx5IGJyaWRnZSBzZWxlY3RvciBidXQgb3B0aW1pemVk IGJyaWRnZSBzZWxlY3Rvci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IlBB R0UtQlJFQUstQkVGT1JFOiBhbHdheXMiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGli cmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+SSBhbSB3 b25kZXJpbmcgd2hldGhlciBpdCBpcyBjb21iaW5hdGlvbiBvZiBwZXJtYW5lbnQgYnJpZGdlIGFu ZCBzZWxlY3RvciBicmlkZ2UgKFR3byB0ZXJtcyBhcmUgZGVmaW5lZCBpbiBSRkM2Mzc4KS48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IlBBR0UtQlJFQUstQkVGT1JFOiBhbHdh eXMiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09M T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+SWYgaXQgaXMsIG15IHF1ZXN0aW9uIGlzIGNh biB3ZSBhcHBseSAxOjEgcHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUgYW5kIDEmIzQzOzEgcHJvdGVj dGlvbiBhcmNoaXRlY3R1cmUgdG8gbGluZWFyIHByb3RlY3Rpb24gbWVjaGFuaXNtIGF0IHRoZSBz YW1lIHRpbWUgb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IlBBR0UtQlJF QUstQkVGT1JFOiBhbHdheXMiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdz YW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+V2Ugc2hvdWxkIHVz ZSB0aGVzZSBwZXJtYW5lbnQgYnJpZGdlIGFuZCBzZWxlY3RvciBicmlkZ2Ugc2VwYXJhdGVseT88 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IlBBR0UtQlJFQUstQkVGT1JFOiBh bHdheXMiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsg Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+UGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBh bSB3cm9uZyBvciBtaXNzIHNvbWV0aGluZy48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtU0laRTog MTBwdCIgbGFuZz0iRU4iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z LXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+UmVnYXJkcyE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6 IDExcHQiPi1RaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iQk9S REVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElO Ry1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiAwY207IFBBRERJTkctUklHSFQ6IDBjbTsgQk9S REVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBB RERJTkctVE9QOiAzcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYn OyBGT05ULVNJWkU6IDEwcHQiPiBSeW9vLCBKZW9uZy1kb25nIFttYWlsdG86cnlvb0BldHJpLnJl LmtyXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRGVjZW1iZXIgMzAsIDIwMTMgMToyMCBQ TTxicj4NCjxiPlRvOjwvYj4gUWluIFd1OyBZYWFjb3YgV2VpbmdhcnRlbjxicj4NCjxiPkNjOjwv Yj4gbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFttcGxzXSBRdWVzdGlvbiByZWdhcmRpbmcgU0Qg cHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4NCjxkaXYgaWQ9Im1zZ2JvZHkiPg0K PGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQt U0laRTogMTBwdCI+UWluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+VGhpcyBkcmFmdCBpcyBiYXNl ZCBvbiBSRkM2Mzc4IGZvciB0aGUgcHJvdG9jb2wgbWVzc2FnZSBmb3JtYXQgYW5kIHRoZSZuYnNw O2Jhc2ljIG9wZXJhdGlvbmFsIHByaWNpcGxlcywgd2hpY2gmbmJzcDthcmUgZGlmZmVyZW50IGZy b20gRy44MDMxLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5UaGUgaW50ZW50 aW9uIG9mIHRoaXMgZHJhZnQgaXMgdG8gbWFrZSBSRkM2Mzc4IGJlIGFsaWduZWQgd2l0aCBHLjgw MzEgKG9yIG90aGVyIElUVSBwcm90ZWN0aW9uIHRlY2hub2xvZ2llcykgaW4gdGhlIGFzcGVjdHMg b2YgJnF1b3Q7bmV0d29yayBvcGVyYXRpb24mcXVvdDsuJm5ic3A7SW4NCiBvdGhlciB3b3Jkcywg aXQmbmJzcDtsb29rcyBsaWtlIEcuODAzMSAob3Igb3RoZXIgSVRVIHByb3RlY3Rpb24gdGVjaG5v bG9naWVzKSB0byB0aGUgbmV0d29yayBvcGVyYXRvcnMsIGJ1dCZuYnNwO3RoZSZuYnNwO2FjdHVh bCBwcm90b2NvbCBvcGVyYXRpb25zJm5ic3A7YW5kIHRoZSBiaXRzIG9uIHRoZSB3aXJlIGFyZSBk aWZmZXJlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwn LCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5JIG1lbnRpb25lZCBHLjgwMzEgaW4gbXkg cHJldmlvdXMgZW1haWwgdG8gWWFhY292IGp1c3QgZm9yIGJldHRlciBleHBsYW5hdGlvbiwmbmJz cDthbmQgSSBkb24ndCB0aGluayZuYnNwO3RoaXMgZG9jdW1lbnQmbmJzcDtuZWVkcyZuYnNwO0cu ODAzMSBhcyBhIHJlZmVyZW5jZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0 Ij5CdXQsIGlmIHlvdSZuYnNwO2ZpbmQgYW55IHBhcnQgaW4gdGhpcyBkb2N1bWVudCB0aGF0Jm5i c3A7bmVlZHMgYSByZWZlcmVuY2UgdG8gRy44MDMxLCBwbGVhc2UgbGV0IHVzIGtub3cuJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdB cmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNl cmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5Zb3UgYW5kIFlhYWNvdiBtaWdodCBiZSByaWdodCBvbiB0 aGUgc2VudGVuY2UgJnF1b3Q7U0QgcHJvdGVjdG9uIGlzIG5vdCBhZ25vc3RpYyB0byB0aGUgZGV0 ZWN0aW9uIG1ldGhvZCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+ QnV0LCBhcyBJIHNhaWQsIG15IG9yaWdpbmFsIGludGVudGlvbiBhbmQgd2hhdCB3ZSB3YW50ZWQg dG8gYWNoaWV2ZSBpbiB0aGlzIGRvY3VtZW50Jm5ic3A7YXJlIHRoYXQmbmJzcDt0aGUmbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3VuIEdvdGhpYycsJ3NlcmlmJzsg Rk9OVC1TSVpFOiAxMHB0Ij5wcm90ZWN0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZic7IEZPTlQtU0la RTogMTBwdCI+c3BlY2lmaWVkDQogaW4gdGhpcyBkb2N1bWVudDwvc3Bhbj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYn OyBGT05ULVNJWkU6IDEwcHQiPmNvdmVycyBTRDwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnOyBGT05ULVNJ WkU6IDEwcHQiPm5vDQogbWF0dGVyIHdoYXQga2luZCBvZiBTRCBkZXRlY3Rpb24gbWV0aG9kczwv c3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05U LVNJWkU6IDEwcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxn dW4gR290aGljJywnc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPnNob3VkIGJlPC9zcGFuPjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBw dCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMn LCdzZXJpZic7IEZPTlQtU0laRTogMTBwdCI+dXNlZC4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdz YW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5CeSB0aGUgd2F5LCB0aGlzIGRyYWZ0IGRvZXMg bm90IGhhdmUgYSB3b3JkICZxdW90O2Fnbm9zdGljJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsg Rk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBw dCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+SmVvbmctZG9uZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdz YW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZP TlQtU0laRTogMTBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQi Pjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9IlRFWFQtQUxJR046IGNlbnRlcjsgTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiPg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwn LCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxociBhbGlnbj0iY2VudGVyIiBzaXpl PSIyIiB3aWR0aD0iMTAwJSI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEycHQiIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZP TlQtU0laRTogMTBwdCI+RnJvbSA6DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+JnF1b3Q7UWluIFd1JnF1 b3Q7ICZsdDtiaWxsLnd1QGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+U2VudCA6IDwvYj4yMDEzLTEy LTMwIDEyOjQ4OjI3ICggJiM0MzswOTowMCApPGJyPg0KPGI+VG8gOiA8L2I+UnlvbywgSmVvbmct ZG9uZyAmbHQ7cnlvb0BldHJpLnJlLmtyJmd0OywgWWFhY292IFdlaW5nYXJ0ZW4gJmx0O3d5YWFj b3ZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjIDogPC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21wbHNA aWV0Zi5vcmcmZ3Q7LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyAm bHQ7ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdCA6IDwvYj5SRTogW21wbHNdIFF1ZXN0aW9uIHJlZ2FyZGluZyBTRCBwcm90ZWN0aW9u IGluIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5 N2Q7IEZPTlQtU0laRTogMTFwdCI+U29ycnkgdG8gaW50ZXJydXB0IGluLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjog IzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5JIGFtIGEgbGl0dGxlIGJpdCBzdXJwcmlzZWQgdGhp cyBkcmFmdCBoYXMgbm90IGFueSByZWZlcmVuY2UgdG8gSVRVIGRvY3VtZW50Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xP UjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5JIGFtIHdvbmRlcmluZyBob3cgbXVjaCB0aGlz IGRyYWZ0IGlzIGNvbXBsaWFudCB3aXRoIEcuODAzMT8gSXMgdGhlcmUgYW55IHR3ZWFrIG9yIG9w dGltaXphdGlvbiB0byBHLjgzMT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFw dCI+V2hhdCBpcyB0aGUgY29uY2VybiBvZiBHLjgzMSB0aGlzIGRyYWZ0IGlzIGRlYWxpbmcgd2l0 aD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z LXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+SWYgYW55dGhpbmcgaXMg ZnJvbSBHLjgzMSBvciBhbnkgb3RoZXIgSVRVIGRvY3VtZW50LCBJIHRoaW5rIGl0IGlzIGZpbmUs IGhvd2V2ZXIgRy44MzEgb3Igc29tZSBvdGhlciBJVFUgZG9jdW1lbnRzIGFyZSB3b3J0aCBiZWlu Zw0KIHJlZmVyZW5jZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1T SVpFOiAxMXB0Ij5JZiB0aGlzIGRyYWZ0IGlzIGZvY3VzaW5nIG9uIGFkZHJlc3NpbmcgRy44MzEs IGl0IGlzIGJldHRlciB0byBjbGFyaWZ5IHRoaXMgYSBsaXR0bGUgYml0IGluIHRoaXMgZHJhZnQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2Fs aWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5NeSBm ZWVsaW5nIGlzIHRoaXMgZHJhZnQgc2VlbXMgdG8gaW50cm9kdWNlIGNvbWJpbmF0aW9uIG9mIDEm IzQzOzEgYW5kIDE6MSBwcm90ZWN0aW9uIGFyY2hpdGVjdHVyZSB3aGVuIEkgcmVhZDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBD T0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij7igJw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdz ZXJpZiciPkFzIHlvdSBtaWdodCByZWNhbGwgZnJvbSBHLjgwMzENCjwvc3Bhbj7igJM8c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj4gRXRoZXJuZXQgbGlu ZWFyIHByb3RlY3Rpb24sIHRoZSBzZWxlY3RvciBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVkIGR1 ZSB0byB0aGUgdHJhZmZpYyBmbGFwcGluZyB1bmRlciBTRCBjb25kaXRpb25zIG9uIGJvdGggcGF0 aHMuIEluc3RlYWQNCjwvc3Bhbj7igJw8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4g R290aGljJywnc2VyaWYnIj5icm9hZGNhc3QgYnJpZGdlPC9zcGFuPuKAnTxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPiBpcyBpbnRyb2R1Y2VkIHRvIHN1 cHBvcnQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgYWdhaW5zdCBTRC4gQnV0LCB0aGlzIGJyb2FkY2Fz dCBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVkIGluIG5vbi1yZXZlcnRpdmUgbW9kZQ0KIGFzIHRo ZSB3b3JraW5nIHBhdGggbmVlZHMgdG8gYmUgb2NjdXBpZWQgYnkgdHJhZmZpYyBhbGwgdGhlIHRp bWUuIEFsc28gdGhlIGJyb2FkY2FzdCBicmlkZ2UgaXMgbm90IGVmZmljaWVudCwgc2luY2UgYnkg ZGVmaW5pdGlvbiwgdGhlIHBhY2tldCBkdXBsaWNhdGlvbiBzaG91bGQgb2NjdXIgZHVyaW5nIG5v dCBvbmx5IFNEIGJ1dCBhbHNvIFNGLCBGUywgTVMsIGV0Yy4gSW4gdGhpcyBkb2N1bWVudCwgd2Ug YXJlIGludHJvZHVjaW5nIGFuIGltcHJvdmVkDQogYnJpZGdlIG1lY2hhbmlzbSwgd2hpY2ggYmVo YXZlcyBsaWtlIGEgc2VsZWN0b3IgYnJpZGdlIGJ1dCBkdXBsaWNhdGVzIHRoZSB0cmFmZmljIG9u bHk8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3VuIEdvdGhpYycs J3NlcmlmJyI+dW5kZXIgU0QgY29uZGl0aW9uLCBhbmQgd2UgYmVsaWV2ZSB0aGF0IGl0IGFkZHJl c3NlcyBhbGwgdGhlIGlzc3VlcyB3aXRoIGV4aXN0aW5nIGJyaWRnZXMuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1z ZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPuKAnSwNCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xP UjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5JIHRlbmQgdG8gYWdyZWUgWWFjY292IHRoYXQg U0QgcHJvdGVjdGlvbiBpcyBub3QgYWdub3N0aWMgdG8gdGhlIG1ldGhvZCB1c2VkIGZvciB0aGUg ZGV0ZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5BbHNvIEkg YW0gaW50ZXJlc3RlZCB0byBrbm93IGhvdyB0byBwb3NpdGlvbiBicmlkZ2UgYW5kIHNlbGVjdG9y IGluIHRoZSBNUExTIGFyY2hpdGVjdHVyZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0 OTdkOyBGT05ULVNJWkU6IDExcHQiPlJlZ2FyZHMhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05U LVNJWkU6IDExcHQiPi1RaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9IkJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDog bWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwY207IFBBRERJTkctTEVGVDogMGNtOyBQQURE SU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklH SFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxwIHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn VGFob21hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6 IDEwcHQiPm1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlJ5b28sIEplb25nLWRvbmc8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2Vt YmVyIDI2LCAyMDEzIDEyOjUxIFBNPGJyPg0KPGI+VG86PC9iPiBZYWFjb3YgV2VpbmdhcnRlbjxi cj4NCjxiPkNjOjwvYj4gbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVA dG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttcGxzXSBRdWVzdGlvbiBy ZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0i ZXpGb3JtUHJvY19kaXYiPg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3VuIEdvdGhpYycsJ3NlcmlmJyI+ WWFhY292LCB0aGFua3MgZm9yIHlvdXIgZW1haWwuPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPlNvbWVob3csIEkgZm9yZ290IHRv IHJlc3BvbmQgYW5kIGFtIHNvcnJ5IGZvciB0aGUNCiBkZWxheS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj5GaXJzdCBvZiBhbGws IFlhYWNvdiwgaXQgaXMgbm90IHRydWUgdGhhdCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb2Yg RXRoZXJuZXQgb3IgU0RIIGRlc2NyaWJlcyB0aGUgb3BlcmF0aW9uIG9mIGFueSBsYXllciBiZWxv dy4gUmF0aGVyLA0KIGVhY2ggbGF5ZXIgaXMgc3VwcG9zZWQgdG8gb3BlcmF0ZSBpbmRlcGVuZGVu dGx5LiBIb3dldmVyLCB0aGVyZSBhcmUgYSBmZXcgZXhjZXB0aW9ucywgc3VjaCBhcyBob2xkLW9m ZiB0aW1lciBhbmQgQUlTIChhcyBhIHRyaWdnZXIgZnJvbSBsb3dlciBsYXllcikuIEV2ZW4gdGhv dWdoIHRoZXJlIGV4aXN0IHNvbWUgcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRpb25zIHRoYXQgdXNl IG90aGVyIGluZm9ybWF0aW9uIGZyb20gbG93ZXIgbGF5ZXIsIG1vc3QNCiBvZiB0aGVtIGFyZSBu b3QgcmVjb21tZW5kZWQgaW4gSVRVLVQgc3RhbmRhcmRzLiA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj5CcmlkZ2UgYW5kIHNlbGVj dG9yIGFyZSBub3QgaW4gdGhlIHBoeXNpY2FsIGxheWVyLCBidXQgdGhleSBhcmUgcGFydCBvZiBw cm90ZWN0aW9uIHN3aXRjaGluZy4gT25lIG9mIHRoZSBpbXBvcnRhbnQgb3V0cHV0IGFjdGlvbnMg ZnJvbSB0aGUNCiBQU0MgY29udHJvbCBsb2dpYyBpcyBjb29yZGluYXRpbmcgdGhlIHBvc2l0aW9u cyBvZiBicmlkZ2UgYW5kIHNlbGVjdG9yLiBBbHNvLCB0aGUgYnJpZGdlIG9wZXJhdGlvbiByZXNw b25kaW5nIHRvIHRoZSBQU0MgY29udHJvbCBsb2dpYyBpcyBhbHNvIHBhcnQgb2YgcHJvdGVjdGlv biBzd2l0Y2hpbmcuIEhvd2V2ZXIsIGhvdyB0byByZWFsaXplIHRoZSBicmlkZ2UgYW5kIHNlbGVj dG9yIChmb3IgZXhhbXBsZSwgaG93IHRvIG1hbmlwdWxhdGUgYSBwYWNrZXQNCiBmb3J3YXJkaW5n IG1lY2hhbmlzbSkgaXMgYW4gaW1wbGVtZW50YXRpb24gbWF0dGVyLiA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQi IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj5XaGVuIHdlIG1l bnRpb24gMSYjNDM7MSBvciAxOjEgaW4gcHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUsIHdlIGRlYWwg d2l0aCB0aGUgb3BlcmF0aW9uIG9mIGJyaWRnZS4gRm9yIDEmIzQzOzEgYXJjaGl0ZWN0dXJlLCB0 aGUgdHJhZmZpYyBuZWVkcyB0byBiZQ0KIGR1cGxpY2F0ZWQgYXQgdGhlIHNlbmRlciBhbmQgc2Vu dCB0byBib3RoIHBhdGhzIGFsbCB0aGUgdGltZSwgd2hpY2ggaXMgdGhlIHNhbWUgZGVzY3JpcHRp b24gYXMgdGhlDQo8L3NwYW4+4oCcPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3VuIEdv dGhpYycsJ3NlcmlmJyI+cGVybWFuZW50IGJyaWRnZTwvc3Bhbj7igJ08c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj4uIEZvciAxOjEgYXJjaGl0ZWN0dXJl LA0KPC9zcGFuPuKAnDxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdz ZXJpZiciPnNlbGVjdG9yIGJyaWRnZTwvc3Bhbj7igJ08c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdNYWxndW4gR290aGljJywnc2VyaWYnIj4gaXMgdXNlZCB0byBzZW5kIHRoZSB0cmFmZmljIG9u bHkgb25lIG9mIHRoZSBwYXRocy4gQXMgdGhlIHByb3RlY3Rpb24gcGF0aCBjYW4gYmUgdXNlZCBi eTwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywn c2VyaWYnIj5iZXN0DQogdHJhZmZpYyBpbiBwYWNrZXQgbmV0d29ya3MgYW5kIHRoZSBwYWNrZXQg ZHVwbGljYXRpb24gdGFrZXMgbXVjaCBtb3JlIGVmZm9ydC9pbnRlcm5hbCBiYW5kd2lkdGggaW5z aWRlIGEgc3dpdGNoIHRoYW4gdGhlIHRpbWUgc2xvdCBjb3B5IG9mIGNpcmN1aXQgbmV0d29ya3Mu IDE6MSBpcyBjb25zaWRlcmVkIGFzIHByZWZlcmFibGUgYXJjaGl0ZWN0dXJlIGluIHBhY2tldCBu ZXR3b3Jrcy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEw cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBH b3RoaWMnLCdzZXJpZiciPkFzIHlvdSBtaWdodCByZWNhbGwgZnJvbSBHLjgwMzENCjwvc3Bhbj7i gJM8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj4gRXRo ZXJuZXQgbGluZWFyIHByb3RlY3Rpb24sIHRoZSBzZWxlY3RvciBicmlkZ2UgaXMgbm90IHJlY29t bWVuZGVkIGR1ZSB0byB0aGUgdHJhZmZpYyBmbGFwcGluZyB1bmRlciBTRCBjb25kaXRpb25zIG9u IGJvdGggcGF0aHMuIEluc3RlYWQNCjwvc3Bhbj7igJw8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdNYWxndW4gR290aGljJywnc2VyaWYnIj5icm9hZGNhc3QgYnJpZGdlPC9zcGFuPuKAnTxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPiBpcyBpbnRyb2R1 Y2VkIHRvIHN1cHBvcnQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgYWdhaW5zdCBTRC4gQnV0LCB0aGlz IGJyb2FkY2FzdCBicmlkZ2UgaXMgbm90IHJlY29tbWVuZGVkIGluIG5vbi1yZXZlcnRpdmUgbW9k ZQ0KIGFzIHRoZSB3b3JraW5nIHBhdGggbmVlZHMgdG8gYmUgb2NjdXBpZWQgYnkgdHJhZmZpYyBh bGwgdGhlIHRpbWUuIEFsc28gdGhlIGJyb2FkY2FzdCBicmlkZ2UgaXMgbm90IGVmZmljaWVudCwg c2luY2UgYnkgZGVmaW5pdGlvbiwgdGhlIHBhY2tldCBkdXBsaWNhdGlvbiBzaG91bGQgb2NjdXIg ZHVyaW5nIG5vdCBvbmx5IFNEIGJ1dCBhbHNvIFNGLCBGUywgTVMsIGV0Yy4gSW4gdGhpcyBkb2N1 bWVudCwgd2UgYXJlIGludHJvZHVjaW5nIGFuIGltcHJvdmVkDQogYnJpZGdlIG1lY2hhbmlzbSwg d2hpY2ggYmVoYXZlcyBsaWtlIGEgc2VsZWN0b3IgYnJpZGdlIGJ1dCBkdXBsaWNhdGVzIHRoZSB0 cmFmZmljIG9ubHk8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3Vu IEdvdGhpYycsJ3NlcmlmJyI+dW5kZXIgU0QgY29uZGl0aW9uLCBhbmQgd2UgYmVsaWV2ZSB0aGF0 IGl0IGFkZHJlc3NlcyBhbGwgdGhlIGlzc3VlcyB3aXRoIGV4aXN0aW5nIGJyaWRnZXMuDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1C T1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYn Ij5XaGF0IHdlIG1lYW4gYnkgU0QgcHJvdGVjdGlvbiBpcyBhZ25vc3RpYyB0byB0aGUgU0QgZGV0 ZWN0aW9uIG1ldGhvZCBpcyB0aGF0IHRoZSBwcm9wb3NlZCBTRCBwcm90ZWN0aW9uIG1ldGhvZCAo YWdhaW4gaG93IHRvIG9wZXJhdGUgYSBicmlkZ2UNCiBvciB3aGF0PC9zcGFuPiZuYnNwOzxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPmJyaWdlIGlzIHVz ZWQgaXMgYSBwYXJ0IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nKSBjYW4gYmUgdXNlZCBubyBtYXR0 ZXIgd2hhdCBraW5kIG9mIFNEIGRldGVjdGlvbiBtZXRob2RzIChkYXRhIHBhY2tldCBjb3VudGlu ZywgQ0NNIHBhY2tldCBjb3VudGluZywgb3IgZXZlbiBwcm9wcmlldGFyeSBzZXJ2ZXIgbGF5ZXIg U0QgZGV0ZWN0aW9uKQ0KIGlzIHVzZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFS R0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnTWFsZ3VuIEdvdGhpYycsJ3NlcmlmJyI+SSB0aGluayBJIGFuc3dlcmVkIGFsbCB0aGUg cXVlc3Rpb25zIG9uIHlvdXIgZW1haWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFS R0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnTWFsZ3VuIEdvdGhpYycsJ3NlcmlmJyI+WWFhY292LCBpZiB5b3UgaGF2ZSBhbnkgZnVy dGhlciBjb25jZXJucyBvciBxdWVzdGlvbnMsIHBsZWFzZSBsZXQgbWUga25vdy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006 IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj5CZXN0 IHJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBw dCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3VuIEdv dGhpYycsJ3NlcmlmJyI+SmVvbmctZG9uZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTJwdCIgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJNYWlsU2lnblNlbnRTZW50U2VudCI+ DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJURVhULUFMSUdOOiBjZW50ZXI7IExJ TkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIj4NCjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBw dCI+DQo8aHIgYWxpZ249ImNlbnRlciIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiPg0KPC9zcGFuPjwv ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMnB0IiBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3Nh bnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPkZyb20gOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZx dW90O1lhYWNvdiBXZWluZ2FydGVuJnF1b3Q7ICZsdDt3eWFhY292QGdtYWlsLmNvbSZndDs8YnI+ DQo8Yj5TZW50IDogPC9iPjIwMTMtMTItMTAgMTY6MDQ6MTcgKCAmIzQzOzA5OjAwICk8YnI+DQo8 Yj5UbyA6IDwvYj5SeW9vLCBKZW9uZy1kb25nICZsdDtyeW9vQGV0cmkucmUua3ImZ3Q7PGJyPg0K PGI+Q2MgOiA8L2I+ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcgJmx0 O2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnJmd0OywgbXBsc0BpZXRm Lm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0IDogPC9iPlJlOiBRdWVz dGlvbiByZWdhcmRpbmcgU0QgcHJvdGVjdGlvbiBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywn c2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+SmVvbmctZG9uZywgaGkNCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPlRoYW5rIHlvdSBm b3IgeW91ciByZXBseS4gWW91ciBhbnN3ZXIgc2VlbXMgdG8gYmUgYW4gYXBwcm9wcmlhdGUgYW5z d2VyIGZvciBvdGhlciBTRE9zLCBub3Qgc3VyZSB0aGF0IGl0IGlzIHRydWUgZm9yIHRoZSBjb250 ZXh0IG9mIE1QTFMgYW5kIElFVEYNCiB3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Fy aWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+MS4gWW91IHdyb3RlICZxdW90Ozwv c3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICfrp5HsnYDqs6DrlJUnLCdzZXJpZic7IEZP TlQtU0laRTogMTBwdCI+YW55IHByb3RlY3Rpb24gc3dpdGNoaW5nIChpbmNsdWRpbmcgUFNDKSBp cyBzdXBwb3NlZCB0byBkZXNjcmliZQ0KIHRoZSBvcGVyYXRpb24gb2YgYnJpZGdlIGFuZCBzZWxl Y3Rvci4mcXVvdDsgLSA8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdz YW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij50aGlzIG1heSBiZSB0cnVlIGZvciBFdGhlcm5l dCBhbmQmbmJzcDtTREggYW5kIGZvciBkb2N1bWVudHMgdGhhdCBhcmUgZGVzY3JpYmluZyB0aGUg b3BlcmF0aW9uIG9mIHRoZSBwaHlzaWNhbCBsYXllci4gSG93ZXZlciwgdGhlIElFVEYgKHRvIG15 IHVuZGVyc3RhbmRpbmcNCiAtIGFuZCBJIGFtIGNlcnRhaW5seSB3aWxsaW5nIHRvIGJlIGNvcnJl Y3RlZCBvbiB0aGlzIHBvaW50KSBpcyBjb25jZXJuZWQgd2l0aCB0aGUgcHJvdG9jb2wgYW5kIGxl YXZlIHRoZSBsb3dlciBsYXllcnMgdG8gaW1wbGVtZW50YXRpb24uIEFsc28sIEkgYW0gbm90IHN1 cmUgdGhhdCB0aGUgY29uY2VwdHMgb2YgQnJpZGdlIGFuZCBTZWxlY3RvciByZWFsbHkgYXBwbHkg dG8gTVBMUyAoYWx0aG91Z2ggSSBhZG1pdCB0aGF0IHdlIGRpZCBtZW50aW9uDQogdGhlbSBpbiB0 aGUgb3JpZ2luYWwgUFNDIGRlZmluaXRpb24pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Fy aWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+Mi4gWW91IGNpdGUgd2hhdCB3YXMg d3JpdHRlbiBpbiBHODAzMSBhcyBqdXN0aWZpY2F0aW9uIGZvciBpbmNsdWRpbmcgY29udGVudCBp bnRvIHlvdXIgZHJhZnQuIEFnYWluIGl0IGlzIGhhcmQgdG8gdHJhbnNmZXIgbWV0aG9kb2xvZ3kg ZnJvbSBvbmUgU0RPDQogdG8gYW5vdGhlciBhbmQgdGhlcmVmb3JlLCB3aGlsZSBJIGhpZ2hseSBy ZXNwZWN0IHRoZSB3b3JrIG9mIHRoZSBJVFUsIEkgZG8gbm90IGZlZWwgdGhhdCB0aGlzIGlzIGEg dmVyeSBjbGVhciBqdXN0aWZpY2F0aW9uIGZvciBpbmNsdXNpb24gaW50byBhbiBpbnRlcm5ldC1k cmFmdC4gRXZlbiB3aGVuIHRoZSBkcmFmdCBzdGF0ZXMgdGhhdCBpdHMgcHVycG9zZSBpcyB0byBh ZGRyZXNzIHRoZSBjb25jZXJucyBvZiB0aGUgSVRVLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+My4gVG8gdGhlIGFjdHVhbCBw b2ludCBvZiBteSBlYXJsaWVyIGNvbW1lbnQsIHRoYXQgeW91IGRvIG5vdCBzZWVtIHRvIGFkZHJl c3MgLSB0aGUgcGFyYWdyYXBoIGluIFNlY3Rpb24gNy4zIHNlZW1zIHRvIHN0YXRlIHRoYXQgU0Qg cHJvdGVjdGlvbiBjaGFuZ2VzDQogYWNjb3JkaW5nIHRvIHRoZSBtZXRob2QgdGhhdCBpcyB1c2Vk IHRvIGRldGVjdCB0aGUgU0QuIFRoaXMgbWVhbnMgdGhhdCBTRCBwcm90ZWN0aW9uIGlzIG5vdCBh Z25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoZSBkZXRlY3Rpb24uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMt c2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPkFsdGVybmF0aXZlbHksIHdlIGNvdWxkIGJyZWFrIHRo aXMgZGVwZW5kZW5jZSBhbmQgc3RhdGUgdGhhdCBTRCBwcm90ZWN0aW9uIGlzIGFsd2F5cyBwcm92 aWRlZCBieSBjaGFuZ2luZyB0aGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBkYXRhIHRvIDEmIzQzOzEg cHJvdGVjdGlvbg0KIGluIGNhc2VzIG9mIFNEIGRldGVjdGlvbiwgd2hpY2ggaXMgd2hhdCB0aGUg cGFyYWdyYXBoIGlzIHN1Z2dlc3RpbmcgdG8gZG8gZm9yIHNvbWUgY2FzZXMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5JIGhv cGUgdGhpcyBmb3JtdWxhdGlvbiBtYWtlIG15IGNvbW1lbnQgY2xlYXJlciBhbmQgd2UgYXJlIGFi bGUgdG8gZGlzY3VzcyB0aGUgdGVjaG5vbG9naWNhbCBhcHByb2FjaCByYXRoZXIgdGhhbiB0aGUg cGhpbG9zb3BoaWNhbCBkaWZmZXJlbmNlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlh bCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPlRoYW5rIHlvdSw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1z ZXJpZic7IEZPTlQtU0laRTogMTBwdCI+eWFhY292PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1C T1RUT006IDEycHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0 Ij5PbiBNb24sIERlYyA5LCAyMDEzIGF0IDEwOjA0IFBNLCBSeW9vLCBKZW9uZy1kb25nICZsdDs8 YSBocmVmPSJtYWlsdG86cnlvb0BldHJpLnJlLmtyIiB0YXJnZXQ9Il9ibGFuayI+cnlvb0BldHJp LnJlLmtyPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJ Ti1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPllhYWNvdiw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj5ZZXMsIFBTQyBpcyBzdXBw b3NlZCB0byBiZSBhZ25vc3RpYyB0byB0aGUgbWV0aG9kIHVzZWQgZm9yIHRoZSBkZXRlY3Rpb24g b2YgU0YvU0QuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4tQk9UVE9NOiAx MHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4g R290aGljJywnc2VyaWYnIj5JdCBpcyBhbHNvIHRydWUgdGhhdCBhbnkgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcgKGluY2x1ZGluZyBQU0MpIGlzIHN1cHBvc2VkIHRvIGRlc2NyaWJlIHRoZSBvcGVyYXRp b24gb2YgYnJpZGdlIGFuZCBzZWxlY3Rvci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7 IE1BUkdJTi1CT1RUT006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZiciPkFzIHRoZXJlIGFyZSBtdWx0aXBsZSBv cHRpb25zIGZvciBkZXRlY3RpbmcgU0QsIHdlIG5lZWRlZCB0byBkZXNjcmliZSB0aGUgYmVoYXZp b3Igb2YgdGhlIGJyaWRnZSB0byBjb3ZlciBhbGwgdGhlIHBvc3NpYmxlIGRldGVjdGlvbiBtZXRo b2RzLg0KIERlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbiBvZiBicmlkZ2UgZm9yIFNEIHByb3RlY3Rp b24gaXMgbm90IGEgbmV3IHRoaW5nLiBGb3IgZXhhbXBsZSwgRy44MDMxIC0gRXRoZXJuZXQgbGlu ZWFyIHByb3RlY3Rpb24gYWxzbyBkZXNjcmliZXMgd2hhdDwvc3Bhbj4mbmJzcDs8c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdNYWxndW4gR290aGljJywnc2VyaWYnIj5icmlkZ2UgY2FuPC9zcGFu PiZuYnNwOzxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01hbGd1biBHb3RoaWMnLCdzZXJpZici PmJlDQogdXNlZCBpbiBvcmRlciB0byBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCBTRC4gPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU4t Qk9UVE9NOiAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTWFsZ3VuIEdvdGhpYycsJ3Nlcmlm JyI+QmVzdCByZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RU T006IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ01h bGd1biBHb3RoaWMnLCdzZXJpZiciPkplb25nLWRvbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTi1CT1RUT006IDEycHQiIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9IlRFWFQtQUxJR046IGNlbnRlcjsgTElORS1IRUlHSFQ6IDE1cHQiIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiPg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxociBhbGlnbj0iY2Vu dGVyIiBzaXplPSIyIiB3aWR0aD0iMTAwJSI+DQo8L3NwYW4+PC9kaXY+DQo8cCBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJGT05ULUZB TUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+RnJvbSA6DQo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZP TlQtU0laRTogMTBwdCI+JnF1b3Q7WWFhY292IFdlaW5nYXJ0ZW4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzp3eWFhY292QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnd5YWFjb3ZAZ21haWwu Y29tPC9hPiZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMtMTItMDggMjA6MDE6NTUgKCAmIzQz OzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxz LXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRmLW1w bHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRy YWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPC9hPiZndDssDQo8YSBocmVm PSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+ ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjIDogPC9iPjxicj4NCjxiPlN1YmplY3QgOiA8L2I+ UXVlc3Rpb24gcmVnYXJkaW5nIFNEIHByb3RlY3Rpb24gaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBz Yy1pdHUgPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOLUJPVFRPTTogMTJwdCIgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0 IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3Nh bnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPkhpLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFs Jywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+QWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHlv dXIgZHJhZnQgb24gdGhlIGV4dGVuc2lvbnMgdG8gUFNDIHRvIHN1cHBvcnQgU0Qgc2l0dWF0aW9u cywgSSBoYXZlIGEgcXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb24gLTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlm JzsgRk9OVC1TSVpFOiAxMHB0Ij5JbiB5b3VyIGludHJvZHVjdGlvbiAtIHlvdSBzdGF0ZSB0aGF0 IHRoZSBtZXRob2QgdXNlZCB0byBkZXRlY3QgU0Qgc2l0dWF0aW9ucyBpcyBvdXQtb2Ytc2NvcGUg b2YgdGhlIGRvY3VtZW50LiBEb2VzIHRoaXMgbWVhbiB0aGF0IFBTQyBpcyBzdXBwb3NlZA0KIHRv IGJlIGFnbm9zdGljIHRvIHRoZSBtZXRob2QgdXNlZCBmb3IgdGhpcyBkZXRlY3Rpb24/IEl0IHNo b3VsZCByZWFjdCBvbmx5IHRvIHRoZSBpbmRpY2F0aW9uLCBzaW1pbGFybHkgdG8gdGhlIHJlYWN0 aW9uIGFuZCByZWxhdGlvbnNoaXAgdG8gdGhlIG1ldGhvZCBmb3IgZGV0ZWN0aW5nIGFuZCBkZWNs YXJpbmcgYSBTRiBzaXR1YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQi Pkhvd2V2ZXIsIHdoZW4geW91IGV4cGxhaW4gdGhlIGJlaGF2aW9yIG9mIHRoZSBTRCBwcm90ZWN0 aW9uIGluIHNlY3Rpb24gNy4zIHlvdSBoYXZlIGEgcGFyYWdyYXBoIHRoYXQgc3RhcnRzIHdpdGgg JnF1b3Q7SWYgdGhlIGRldGVjdGlvbiBvZiBhIFNEIGRlcGVuZHMNCiBvbiB0aGUgcHJlc2VuY2Ug b2YgdXNlciBkYXRhIHBhY2tldHMgLi4uJnF1b3Q7ICZuYnNwO3RoYXQgc2VlbXMgdG8gaW5kaWNh dGUgdGhhdCB0aGUgYmVoYXZpb3Igb2YgdGhlIHN5c3RlbSBpcyBkZXBlbmRlbnQgdXBvbiB0aGUg ZGV0ZWN0aW9uIG1ldGhvZCEgQ2xhcmlmaWNhdGlvbiB3b3VsZCBiZSBhcHByZWNpYXRlZC4mbmJz cDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+LS0N Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywn c2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+VGhhbnggYW5kIEJSLA0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsg Rk9OVC1TSVpFOiAxMHB0Ij55YWFjb3Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlh bCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPlN0aWxsIGxvb2tpbmcgZm9yIG5ldyBv cHBvcnR1bml0eTwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7 IEZPTlQtU0laRTogMTBwdCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPC9zcGFuPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4tLQ0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsg Rk9OVC1TSVpFOiAxMHB0Ij5UaGFueCBhbmQgQlIsDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEw cHQiPnlhYWNvdjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJN c29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJp Zic7IEZPTlQtU0laRTogMTBwdCI+U3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5PC9z cGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AF34ESMTP2etriinfo_-- From adrian@olddog.co.uk Mon Dec 30 06:47:35 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 2B3A71AE0E7 for ; Mon, 30 Dec 2013 06:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.847 X-Spam-Level: X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 pMGRAUJo9EmU for ; Mon, 30 Dec 2013 06:47:33 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id C0FE11ADFA6 for ; Mon, 30 Dec 2013 06:47:32 -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 rBUElOVk019003; Mon, 30 Dec 2013 14:47:24 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 rBUElM6i018997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Dec 2013 14:47:24 GMT From: "Adrian Farrel" To: Date: Mon, 30 Dec 2013 14:47:29 -0000 Message-ID: <076901cf056e$1165a810$3430f830$@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: Ac8FbdU+kbRU2QJhQdC1zLTDeF95Xg== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-moving-iana-registries 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, 30 Dec 2013 14:47:35 -0000 Loa and Carlos, Thanks for this piece of housekeeping. I think we need to be crystal clear so that IANA can easily get this right, and I struggled a bit in 2.2. and 2.3 with the difference between "registry" and "registration". I think that *everything* that you describe is a "registry" (or possibly "sub-registry") and nothing you reference is a "registration". Can you tidy that up and I will issue the IETF last call. Thanks, Adrian PS Well done getting Amanda to review the content early. From internet-drafts@ietf.org Mon Dec 30 08:14:04 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 2D73E1AE521; Mon, 30 Dec 2013 08:14:04 -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 M7WKcIMVGoSW; Mon, 30 Dec 2013 08:14:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8438B1AE4F5; Mon, 30 Dec 2013 08:14: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 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131230161402.18293.78786.idtracker@ietfa.amsl.com> Date: Mon, 30 Dec 2013 08:14:02 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-moving-iana-registries-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: Mon, 30 Dec 2013 16:14: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 : 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-03.txt Pages : 8 Date : 2013-12-30 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-moving-iana-registries-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 cpignata@cisco.com Mon Dec 30 08:18:52 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 C61F31AE2BA for ; Mon, 30 Dec 2013 08:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.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, 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 BBM0uQEiZUoj for ; Mon, 30 Dec 2013 08:18:51 -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 DCF2F1AE516 for ; Mon, 30 Dec 2013 08:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4593; q=dns/txt; s=iport; t=1388420324; x=1389629924; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y3nI4M35m5OEGdFSIWCxI9xUys3zR2Md/kXCcnQHSfk=; b=i9Ingo62BNaDxiCAL6yDbtWFV/epUCjPe6+Z4uv38Y/7zWxzdUuertC8 ikCAaVrpet90myJuzUvBme1ZUqBKYvCk0l6dgENs5C1hRSLG2B4lXw31q 8w/bwZvKBvNjT9Xzrmton2VssN/3TClUbv0r+iQUqnlITwhAIOYkdpOwh k=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEHAL6bwVKtJV2c/2dsb2JhbABYgws4CUYGsRGIVIEbFnSCJQEBAQMBeQULAgEIBEIyJQEBBA4FCQWHbggIBcggF48dB4MjgRMEkDOBMYYzgTCQZIMtgio X-IronPort-AV: E=Sophos;i="4.95,574,1384300800"; d="asc'?scan'208,217";a="294256565" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 30 Dec 2013 16:18:44 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBUGIhUY007140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Dec 2013 16:18:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.18]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Mon, 30 Dec 2013 10:18:43 -0600 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: AD review of draft-ietf-mpls-moving-iana-registries Thread-Index: Ac8FbdU+kbRU2QJhQdC1zLTDeF95XgAP0LuA Date: Mon, 30 Dec 2013 16:18:43 +0000 Message-ID: <0BEC3FB7-51D9-4043-9BCE-672C0D7A6147@cisco.com> References: <076901cf056e$1165a810$3430f830$@olddog.co.uk> In-Reply-To: <076901cf056e$1165a810$3430f830$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.216.37] Content-Type: multipart/signed; boundary="Apple-Mail=_AE06142B-BF51-44FB-8019-8C4495959A38"; 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] AD 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: Mon, 30 Dec 2013 16:18:53 -0000 --Apple-Mail=_AE06142B-BF51-44FB-8019-8C4495959A38 Content-Type: multipart/alternative; boundary="Apple-Mail=_60DD17DF-E4BB-4294-8D5F-0060C3BDB97C" --Apple-Mail=_60DD17DF-E4BB-4294-8D5F-0060C3BDB97C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Many thanks, Adrian. You are correct -- the use of "registration" was a bit careless. All of = those should be "registry/registries", they are not "registrations". I also agree that we need to be crystal clear -- I went through the doc = and also fixed some capitalizations and completed a couple of instances = of the registry name to be completely unambiguous. Here's the updated doc: Htmlized: = http://tools.ietf.org/html/draft-ietf-mpls-moving-iana-registries-03 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-moving-iana-registries-= 03 Loa, I hope all these changes make sense -- please let me know if = there's something I missed or broke. Thanks, -- Carlos. On Dec 30, 2013, at 9:47 AM, Adrian Farrel wrote: > Loa and Carlos, >=20 > Thanks for this piece of housekeeping. >=20 > I think we need to be crystal clear so that IANA can easily get this > right, and I struggled a bit in 2.2. and 2.3 with the difference=20 > between "registry" and "registration". I think that *everything* that > you describe is a "registry" (or possibly "sub-registry") and nothing=20= > you reference is a "registration". >=20 > Can you tidy that up and I will issue the IETF last call. >=20 > Thanks, > Adrian >=20 > PS Well done getting Amanda to review the content early. >=20 --Apple-Mail=_60DD17DF-E4BB-4294-8D5F-0060C3BDB97C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Many = thanks, Adrian.

You are correct -- the use of = "registration" was a bit careless. All of those should be = "registry/registries", they are not "registrations".
I also = agree that we need to be crystal clear -- I went through the doc and = also fixed some capitalizations and completed a couple of instances of = the registry name to be completely unambiguous.
Here's the = updated doc:

Loa, I hope all these = changes make sense -- please let me know if there's something I missed = or broke.

Thanks,

-- = Carlos.

On Dec 30, 2013, at 9:47 AM, Adrian = Farrel <adrian@olddog.co.uk> = wrote:

Loa and Carlos,

Thanks for this piece of = housekeeping.

I think we need to be crystal clear so that IANA = can easily get this
right, and I struggled a bit in 2.2. and 2.3 with = the difference
between "registry" and "registration". I think that = *everything* that
you describe is a "registry" (or possibly = "sub-registry") and nothing
you reference is a = "registration".

Can you tidy that up and I will issue the IETF = last call.

Thanks,
Adrian

PS Well done getting Amanda = to review the content = early.


= --Apple-Mail=_60DD17DF-E4BB-4294-8D5F-0060C3BDB97C-- --Apple-Mail=_AE06142B-BF51-44FB-8019-8C4495959A38 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 iEYEARECAAYFAlLBnOEACgkQtfDPGTp3USwnPQCggrR8PXed7sckwMU2EAAXSr21 yMAAn0HJUg7Mr9C+M13H1jxfGJkeFZMq =QqBr -----END PGP SIGNATURE----- --Apple-Mail=_AE06142B-BF51-44FB-8019-8C4495959A38-- From loa@pi.nu Mon Dec 30 18:28:36 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 A6B7A1AE575 for ; Mon, 30 Dec 2013 18:28:36 -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 W3s_I-WA-sKx for ; Mon, 30 Dec 2013 18:28:31 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 33D6F1AE576 for ; Mon, 30 Dec 2013 18:28:31 -0800 (PST) Received: from [192.168.1.5] (unknown [119.95.140.101]) (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 47E821802A16; Tue, 31 Dec 2013 03:28:22 +0100 (CET) Message-ID: <52C22BC8.9010500@pi.nu> Date: Tue, 31 Dec 2013 10:28: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: "Carlos Pignataro (cpignata)" , Adrian Farrel References: <076901cf056e$1165a810$3430f830$@olddog.co.uk> <0BEC3FB7-51D9-4043-9BCE-672C0D7A6147@cisco.com> In-Reply-To: <0BEC3FB7-51D9-4043-9BCE-672C0D7A6147@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "draft-ietf-mpls-moving-iana-registries.all@tools.ietf.org" Subject: Re: [mpls] AD 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, 31 Dec 2013 02:28:36 -0000 Carlos, Yes this is OK. One thing I never understood is the capitalization of "New" and "Moving" in the titles of section 2.1. and 2.2. I guess it will pas the RFC Editor unchanged if it how it should be or the will change it otherwise. &Loa On 2013-12-31 00:18, Carlos Pignataro (cpignata) wrote: > Many thanks, Adrian. > > You are correct -- the use of "registration" was a bit careless. All of > those should be "registry/registries", they are not "registrations". > I also agree that we need to be crystal clear -- I went through the doc > and also fixed some capitalizations and completed a couple of instances > of the registry name to be completely unambiguous. > Here's the updated doc: > Htmlized: > http://tools.ietf.org/html/draft-ietf-mpls-moving-iana-registries-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-moving-iana-registries-03 > > Loa, I hope all these changes make sense -- please let me know if > there's something I missed or broke. > > Thanks, > > -- Carlos. > > On Dec 30, 2013, at 9:47 AM, Adrian Farrel > wrote: > >> Loa and Carlos, >> >> Thanks for this piece of housekeeping. >> >> I think we need to be crystal clear so that IANA can easily get this >> right, and I struggled a bit in 2.2. and 2.3 with the difference >> between "registry" and "registration". I think that *everything* that >> you describe is a "registry" (or possibly "sub-registry") and nothing >> you reference is a "registration". >> >> Can you tidy that up and I will issue the IETF last call. >> >> Thanks, >> Adrian >> >> PS Well done getting Amanda to review the content early. >> > > > > _______________________________________________ > 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 rcallon@juniper.net Tue Dec 31 11:56:48 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 378201AE1D5 for ; Tue, 31 Dec 2013 11:56:48 -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 Ugpjv_-Da4x0 for ; Tue, 31 Dec 2013 11:56:46 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0AADF1AE37E for ; Tue, 31 Dec 2013 11:56:41 -0800 (PST) Received: from mail98-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Tue, 31 Dec 2013 19:56:35 +0000 Received: from mail98-tx2 (localhost [127.0.0.1]) by mail98-tx2-R.bigfish.com (Postfix) with ESMTP id 955463E0158; Tue, 31 Dec 2013 19:56:35 +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: -22 X-BigFish: VPS-22(zz62a3I9371I542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail98-tx2: 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)(252514010)(164054003)(13464003)(199002)(377454003)(189002)(47976001)(49866001)(85852003)(46102001)(81542001)(66066001)(74706001)(4396001)(80976001)(47736001)(80022001)(81686001)(65816001)(87936001)(33646001)(81816001)(2656002)(50986001)(53806001)(63696002)(54316002)(19580405001)(19580395003)(83072002)(85306002)(76482001)(76576001)(74876001)(81342001)(74366001)(76796001)(47446002)(76786001)(74662001)(74502001)(79102001)(69226001)(83322001)(87266001)(51856001)(56816005)(59766001)(54356001)(56776001)(77982001)(74316001)(31966008)(90146001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB747; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.18; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail98-tx2 (localhost.localdomain [127.0.0.1]) by mail98-tx2 (MessageSwitch) id 1388519793991911_16723; Tue, 31 Dec 2013 19:56:33 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.248]) by mail98-tx2.bigfish.com (Postfix) with ESMTP id E2044440031; Tue, 31 Dec 2013 19:56:33 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 31 Dec 2013 19:56:33 +0000 Received: from CO2PR05MB747.namprd05.prod.outlook.com (10.141.227.147) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Tue, 31 Dec 2013 19:56:33 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB747.namprd05.prod.outlook.com (10.141.227.147) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 31 Dec 2013 19:56:30 +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; Tue, 31 Dec 2013 19:56:30 +0000 From: Ross Callon To: Loa Andersson Thread-Topic: bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 Thread-Index: AQHPBTI+C2O4TWNXcUuCz5uE4pDPX5puuO8Q Date: Tue, 31 Dec 2013 19:56:30 +0000 Message-ID: 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: [66.129.241.18] x-forefront-prvs: 00770C4423 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: "vishwas.manral@hp.com" , "mpls@ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" , Ina Minei , Arun Viswanathan , Ina Minei , "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: Tue, 31 Dec 2013 19:56:48 -0000 I am not sure whether or not I need to reply as a person acknowledged in 30= 36 and 5036, but I am happy to grant my BCP 78 rights for RFC 3036 and 5036 to the IETF trust. Thanks, Ross -----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 arunvn@juniper.net Tue Dec 31 15:26:43 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 DDA831AE42D for ; Tue, 31 Dec 2013 15:26:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_jp9m-8iAhT for ; Tue, 31 Dec 2013 15:26:41 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 747A11AE3D4 for ; Tue, 31 Dec 2013 15:26:40 -0800 (PST) Received: from mail149-db8-R.bigfish.com (10.174.8.249) by DB8EHSOBE013.bigfish.com (10.174.4.76) with Microsoft SMTP Server id 14.1.225.22; Tue, 31 Dec 2013 23:26:33 +0000 Received: from mail149-db8 (localhost [127.0.0.1]) by mail149-db8-R.bigfish.com (Postfix) with ESMTP id 537E4401C9; Tue, 31 Dec 2013 23:26:33 +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: -22 X-BigFish: VPS-22(zz62a3I9371I542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzc2hz1de098h1033IL8275bh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail149-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=arunvn@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(164054003)(13464003)(377454003)(252514010)(199002)(189002)(74316001)(80976001)(81686001)(81816001)(56816005)(90146001)(74366001)(46102001)(83072002)(85852003)(33646001)(51856001)(53806001)(54316002)(76482001)(1941001)(54356001)(79102001)(74706001)(76576001)(76796001)(76786001)(77982001)(59766001)(49866001)(47736001)(50986001)(47976001)(66066001)(65816001)(80022001)(63696002)(56776001)(4396001)(74876001)(74662001)(31966008)(81342001)(74502001)(47446002)(85306002)(69226001)(87936001)(87266001)(19580395003)(19580405001)(83322001)(2656002)(81542001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB637; H:DM2PR05MB750.namprd05.prod.outlook.com; CLIP:66.129.239.11; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail149-db8 (localhost.localdomain [127.0.0.1]) by mail149-db8 (MessageSwitch) id 1388532390763698_26237; Tue, 31 Dec 2013 23:26:30 +0000 (UTC) Received: from DB8EHSMHS005.bigfish.com (unknown [10.174.8.226]) by mail149-db8.bigfish.com (Postfix) with ESMTP id B3251180047; Tue, 31 Dec 2013 23:26:30 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS005.bigfish.com (10.174.4.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 31 Dec 2013 23:26:30 +0000 Received: from DM2PR05MB637.namprd05.prod.outlook.com (10.141.157.145) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Tue, 31 Dec 2013 23:26:25 +0000 Received: from DM2PR05MB750.namprd05.prod.outlook.com (10.141.178.144) by DM2PR05MB637.namprd05.prod.outlook.com (10.141.157.145) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 31 Dec 2013 23:26:23 +0000 Received: from DM2PR05MB750.namprd05.prod.outlook.com ([10.141.178.144]) by DM2PR05MB750.namprd05.prod.outlook.com ([10.141.178.144]) with mapi id 15.00.0842.003; Tue, 31 Dec 2013 23:26:23 +0000 From: Arun Viswanathan To: Ross Callon , Loa Andersson Thread-Topic: bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 Thread-Index: AQHPBTI+omEO7LjXRE2XgcWnVZCvoppuumYAgAA57TA= Date: Tue, 31 Dec 2013 23:26:22 +0000 Message-ID: References: <52C122FE.8090706@pi.nu> 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.11] x-forefront-prvs: 00770C4423 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: "vishwas.manral@hp.com" , "mpls@ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" , Ina Minei , Ina Minei , "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: Tue, 31 Dec 2013 23:26:44 -0000 Likewise, not sure I need to respond to this being cited in the acknowledgm= ent section, nonetheless I grant my BCP 78 rights for RFC 3036 and 5036 to = IETF trust. Thx .-arun -----Original Message----- From: Ross Callon=20 Sent: Tuesday, December 31, 2013 11:57 AM To: Loa Andersson 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; Yakov Rekhter; mpls@ietf.org; Arun Viswanathan; Ina Min= ei Subject: RE: bcp 78 rights for RFC 3036 and 5036 + draft-ietf-mpls-ldp-ipv6 I am not sure whether or not I need to reply as a person acknowledged in 30= 36 and 5036, but I am happy to grant my BCP 78 rights for RFC 3036 and 5036= 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; 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" 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 Tue Dec 31 22:17:02 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 828DD1AE4AF for ; Tue, 31 Dec 2013 22:17:02 -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 Vdi1Z0pPBaJ4 for ; Tue, 31 Dec 2013 22:16:59 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 61C681AE3CB for ; Tue, 31 Dec 2013 22:16:59 -0800 (PST) Received: from [192.168.1.5] (unknown [112.208.41.43]) (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 7C6A518013E2; Wed, 1 Jan 2014 07:16:46 +0100 (CET) Message-ID: <52C3B2D0.5030604@pi.nu> Date: Wed, 01 Jan 2014 14:16:48 +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: Arun Viswanathan , Ross Callon References: <52C122FE.8090706@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 01 Jan 2014 06:17:02 -0000 Folks, The devils is in details - it is the way that the acknowledgement were phrased "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 78 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 acknowledgment section, nonetheless I grant my BCP 78 rights for RFC 3036 and 5036 to 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); vishwas.manral@hp.com; Rajiv Papneja; draft-ietf-mpls-ldp-ipv6@tools.ietf.org; Ina Minei; Eric Gray; Eric Rosen; Yakov Rekhter; mpls@ietf.org; Arun Viswanathan; Ina Minei > Subject: RE: bcp 78 rights for RFC 3036 and 5036 + 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 5036 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; draft-ietf-mpls-ldp-ipv6@tools.ietf.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 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64