From l3vpn-bounces@ietf.org Wed Jun 01 16:07:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZUT-0007Y1-Gu; Wed, 01 Jun 2005 16:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZUP-0007Wp-IS; Wed, 01 Jun 2005 16:06:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25778; Wed, 1 Jun 2005 16:06:55 -0400 (EDT) Message-Id: <200506012006.QAA25778@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 01 Jun 2005 16:06:54 -0400 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-2547bis-mcast-00.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Multicast in MPLS/BGP IP VPNs Author(s) : E. Rosen, R. Aggarwal Filename : draft-ietf-l3vpn-2547bis-mcast-00.txt Pages : 58 Date : 2005-6-1 In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-2547bis-mcast-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-2547bis-mcast-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-2547bis-mcast-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-1154727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-2547bis-mcast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-2547bis-mcast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-1154727.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Thu Jun 02 01:13:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddi1l-0001SV-05; Thu, 02 Jun 2005 01:13:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddi1i-0001R7-R4 for l3vpn@megatron.ietf.org; Thu, 02 Jun 2005 01:13:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11686 for ; Thu, 2 Jun 2005 01:13:53 -0400 (EDT) Received: from [218.249.29.198] (helo=center.njtu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdiLN-00055U-OP for l3vpn@ietf.org; Thu, 02 Jun 2005 01:34:32 -0400 Received: from zhanghk (remotehost [127.0.0.1]) by mail.student.njtu.edu.cn (ecMail) with ESMTP id 635E218C077 for ; Thu, 2 Jun 2005 13:27:00 +0800 (CST) Date: Thu, 2 Jun 2005 13:14:18 +0800 From: "HKzhang@center.njtu.edu.cn" To: "l3vpn" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon282608173886_=====" Message-Id: <20050602052700.635E218C077@mail.student.njtu.edu.cn> X-Spam-Score: 1.1 (+) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad Subject: Re:draft-zhang-l3vpn-vr-mcast-00.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org This is a multi-part message in MIME format. --=====001_Dragon282608173886_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksZXZlcnlvbmU6DQpJIGFtIEhvbmctS2UgWmhhbmcgYW5kIGdsYWQgdG8gY29udHJpYnV0ZSBv dXIgZHJhZnQgdG8gZ2V0IHlvdXIgY29tbWVudHMuIEZpcnN0LCBJIGdpdmUgYW4gaW50cm9kdWN0 aW9uIGFzIGZvbGxvd3M6DQogSXQgaXMga25vd24gdGhhdCB0aGUgY29tbXVuaWNhdGlvbiBjb3N0 cyBjYW4gYmUgcmVkdWNlZCBhbmQgdGhlIHdvcmsgZWZmaWNpZW5jeSBjYW4gYmUgaW1wcm92ZWQg Z3JlYXRseSB0byBhIGNvbXBhbnkgdGhyb3VnaCB1c2luZyBWUE4uIFRoZSBWUE4gd2lsbCBhY3Qg YXMgYW4gaW1wb3J0YW50IHJvbGUgaW4gbmV4dCBnZW5lcmF0aW9uIG5ldHdvcmsuIE11bHRpY2Fz dCBpcyBhbHNvIGEgaG90IHBvaW50IGFuZCBtYW55IHJlc2VhcmNoIGhhdmUgYmVlbiBzdHVkeWVk IGluIGl0LiBUaGUgY2xpZW50IGFsc28gbmVlZCBtdWx0aWNhc3Qgc2VydmljZSBpbiBWUE4gbmV0 d29yaywgc28gaXQgaXMgbmVjZXNzYXJ5IHRvIGNvbXBsZXRlIG11bHRpY2FzdCBpbiBWTlAuIEFs b25nIHdpdGggdGhlIEwzVlBOIHdvcmsgZ3JvdXAgYmVnaW4gdG8gdGhpbmsgb2YgbXVsdGljYXN0 LCB0aGUgbXVsdGljYXN0IHJlc2VhcmNoIGJlY29tZXMgbW9yZSBhbmQgbW9yZSBpbXBvcnRhbnQg aW4gTDNWUE4gd29yayBncm91cC4NCiBBdCBwcmVzZW50LCB0d28gbWFpbiBzb2x1dGlubyBtZXRo b2RzIGFib3V0IFZQTiBoYXZlIGJlZW4gcHJvcG9zZWQsIGkuZS4gdGhlIGFwcHJvYWNoIG9mIEJH UC9NUExTIFZQTiBhbmQgdGhlIGFwcHJvYWNoIG9mIFZSLUJhc2VkIFZQTi4gU29tZSBkcmFmdHMg aGF2ZSBiZWVuIHByb3Bvc2VkIGJhc2VkIG9uIHRoZSBhcHByb2FjaCBvZiBCR1AvTVBMUyBWUE4g dG8gcHJvdmlkZSBtdWx0aWNhc3Qgc2VydmUuIEJ1dCB0aGVyZSBpcyBmZXcgZHJhZnQgYmFzZWQg b24gVlIgVlBOLiBUaGUgVlIgVlBOIGhhcyB0aGUgYWR2YW5nZSBvZiBpbmRlcGVuZGVuY2UgYW5k IHNjYWxhYmlsaXR5LiBTbyB3ZSBwcm9wb3NlIGEgZHJhZnQgZm9yIG11bHRpY2FzdCBiYXNlZCBv biBWUiBWUE4uDQpCZWNhdXNlIHRoZSBmdW5jdGlvbiBvZiBWUiBjYW4gYmUgY29uc2lkZXIgYXMg YW4gYWN0dWFsIHJvdXRlciBhbmQgdGhlIG1ldGhvZCBvZiBWUiBWUE4gaXMgaW5kZXBlbmRlbnQg ZnJvbSBwcmVzZW50IHJvdXRlIHByb3RvY29sLCBpdCBzaG91bGQgYmUgbm8gcHJvYmxlbSB0byBk ZXBsb3kgdGhlIG11bHRpY2FzdCBwcm90b2NvbCBzdWNoIGFzIFBJTS1TTSBvciBQSU0tU1NNIGlu IFZSLg0KIFRoZSBhcHByb2FjaCBpbiBvdXIgZHJhZnQgZml0cyBmb3IgdGhvc2Ugc2VydmljZSBw cm92aWRlciBuZXR3b3JrIHdpdGhvdXQgYmFja29uZSBWUiBvciB3aXRob3V0IG5lZWQgZm9yIGVm ZmVjdCBvZiBiYWNrb25lIFZSLiBUaGUgaWRlYSBvZiBvdXIgYXBwcm9hY2ggaXMgdXRpbGl6aW5n IHByZXNlbnQgcm91dGUgcHJvdG9jb2wgc3VjaCBhcyBQSU0tRE0gb3IgTVBMUyBQMk1QIHN1ZmZp Y2llbnRseSB0byByZWFsaXplIG11bHRpY2FzdCBzZXJ2aWNlIGluIFZQTiBuZXR3b3JrLiBUaGUg ZGV0YWlsIG9mIG91ciBkcmFmdCBhcmUgZGVzY3JpYmVkIGluY2x1ZGluZyBhdXRvLWRpc2NvdmVy eSwgZW5jYXBzdWxhdGlvbiwgaW50ZXJvcGVyYWJpbGl0eSwgcm91dGluZyB0YWJsZSBhbmQgZXRj Li4gVGhlIHBlcmZvcm1hbmNlIGFuYWx5c2lzIGlzIGFsc28gc2F0aXNmeWluZy4gDQpBYm92ZSBh bGwsIEkgaG9wZSB5b3UgY2FuIGdpdmUgbWUgdGhlIGhlbHAgYW5kIHlvdXIgY29tbWVudHMuDQpC ZXN0IHJlZ2FyZHMgd2l0aCBtYW55IHRoYW5rcyANCkhvbmctS2UgWmhhbmcgDQoNCiAJCQkJDQoN CqGhoaGhoaGhoaGhoaGhoaFIS3poYW5nDQqhoaGhoaGhoaGhoaGhoaGhSEt6aGFuZ0BjZW50ZXIu bmp0dS5lZHUuY24NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNS0wNi0wMg0K --=====001_Dragon282608173886_===== Content-Type: application/octet-stream; name="draft-zhang-l3vpn-vr-mcast-00.txt" Content-Disposition: attachment; filename="draft-zhang-l3vpn-vr-mcast-00.txt" Content-Transfer-Encoding: base64 DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSG9u Zy1LZSBaaGFuZw0KRG9jdW1lbnQ6IGRyYWZ0LXpoYW5nLWwzdnBuLXZyLW1jYXN0LTAwLnR4dCAg ICAgICBDaHVuLVl1ZSBaaG91DQpFeHBpcmF0aW9uIERhdGU6IE5vdmVtYmVyIDIwMDUgICAgICAg ICAgICAgICAgICAgIEJpbmctWWkgWmhhbmcgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQmVpamluZyBKaWFvdG9uZyBVbml2ZXJzaXR5DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KICAgICAgICAgICBN dWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAgVlBOcyANCg0KICAgICAgICAgICAg ICAgICBkcmFmdC16aGFuZy1sM3Zwbi12ci1tY2FzdC0wMC50eHQNCg0KDQoNCg0KU3RhdHVzIG9m IHRoaXMgTWVtbw0KDQoNCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFj aCBhdXRob3IgcmVwcmVzZW50cyB0aGF0DQogICBhbnkgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3Ro ZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMNCiAgIGF3YXJlIGhhdmUgYmVlbiBv ciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUNCiAgIGJlY29t ZXMgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYg b2YNCiAgIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50 cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMg YXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuIE5vdGUgdGhhdCBvdGhlcg0KICAgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRz Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiBJdCBpcyBpbmFw cHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAg IFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0K ICAgaHR0cDovL3d3dy5pZXRmLm9yZy8xaWQtYWJzdHJhY3RzLmh0bWwNCg0KICAgVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0K ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KDQoNCkFic3RyYWN0IA0KDQog ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgcHJvY2VkdXJlcyByZXF1aXJlZCB0byBpbXBs ZW1lbnQgDQogIA0KSG9uZy1LZSBaaGFuZywgZXQgYWwuICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg MjAwNSAgICAgICAgICAgICAgIFtQYWdlIDFdDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgTXVsdGlj YXN0IGluIFZpcnR1YWwgUm91dGVyLWJhc2VkIElQIFZQTnMgICAgIE1heSAyMDA1DQoNCm11bHRp Y2FzdCBmb3IgYW4gSVAgbXVsdGljYXN0IFZQTiBiYXNlZCBvbiBWaXJ0dWFsIFJvdXRlcnMuIEl0 IA0KICAgZGV0YWlscyB0aGUgc29sdXRpb24gYWNjb3JkaW5nIHRvIHByb2Nlc3MgaW4gbG9jYWwg Y3VzdG9tZXIgc2l0ZXMsDQogICBtZXRob2Qgb2YgZXN0YWJsaXNoaW5nIG11bHRpY2FzdCBkaXN0 cmlidXRpb24gdHJlZXMgaW4gU1AgbmV0d29ya3MNCiAgIGFuZCBmb3J3YXJkaW5nIGZsb3cgb2Yg bXVsdGljYXN0IGRhdGEgcGFja2V0cy4gVGhpcyBkb2N1bWVudCBpcyANCiAgIGJhc2VkIG9uIHBy aW9yIHJlcXVpcmVtZW50cyBmb3IgTXVsdGljYXN0IGluIEwzIFByb3ZpZGVyLVByb3Zpc2lvbmVk DQogICBWUE5zIFtNUkVRVF0gYW5kIHNwZWNpZmljYXRpb24gb2YgbmV0d29yayBiYXNlZCBJUCBW UE4gQXJjaGl0ZWN0dXJlIA0KICAgdXNpbmcgVmlydHVhbCBSb3V0ZXJzIFtWUi1WUE5dIHRoYXQg aGF2ZSBiZWVuIGltcGxlbWVudGVkIGFuZCANCiAgIGRlcGxveWVkLg0KDQpDb252ZW50aW9ucyB1 c2VkIGluIHRoaXMgZG9jdW1lbnQNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQog ICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQy0yMTE5 IFtLRVlXT1JEU10uDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgIDEgICAgICBJbnRyb2R1 Y3Rpb24gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yDQog ICAgMiAgICAgIFRlcm1pbm9sb2d5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjMgIA0KICAgIDMgICAgICBWUiBkZXBsb3ltZW50IHNjZW5hcmlvIC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQogICAgNCAgICAgIEF1dG8tZGlzY292 ZXJ5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgICA1 ICAgICAgUHJvY2VkdXJlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNQ0KICAgIDUuMSAgICBFbmNhcHN1bGF0aW9uIC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICAgNS4xLjEgIEVuY2Fwc3VsYXRpb24gaW4g R1JFIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgICA1LjEuMiAg RW5jYXBzdWxhdGlvbiBpbiBJUCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uNg0KICAgIDUuMS4zICBFbmNhcHN1bGF0aW9uIGluIE1QTFMgLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi42DQogICAgNS4xLjQgIEludGVyb3BlcmFiaWxpdHkgLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCiAgICA1LjIgICAgTXVsdGlj YXN0IHNvdXJjZSByb3V0aW5nIHRhYmxlIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNw0K ICAgIDUuMyAgICBSb3V0aW5nIGluIHRoZSBWUE4gc2l0ZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLiA3DQogICAgNS40ICAgIFJvdXRpbmcgaW4gdGhlIFNQIE5ldHdvcmsgLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDgNCiAgICA1LjUgICAgTXVsdGljYXN0IFZQ TiBEYXRhIEZvcndhcmRpbmcgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOA0KICAgIDYg ICAgICBzY2FsYWJpbGl0eSBDb25zaWRlcmF0aW9ucyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi45DQogICAgNyAgICAgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkNCiAgICA4ICAgICAgQWNrbm93bGVkZ21lbnRzIC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KICAgIDkgICAgICBO b3JtYXRpdmUgUmVmZXJlbmNlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjEwDQogICAgMTAgICAgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTANCiAgICAxMSAgICAgQXV0aG9ycyBBZGRyZXNzIC4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KICAgIDEyICAgICBJbnRlbGxl Y3R1YWwgUHJvcGVydHkgU3RhdGVtZW50IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjExDQoN Cg0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KSG9uZy1LZSBaaGFuZywgZXQgYWwuICAgICAgIEV4cGly ZXMgTm92ZW1iZXIgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDJdDQoNCg0KSW50ZXJuZXQgRHJh ZnQgICAgTXVsdGljYXN0IGluIFZpcnR1YWwgUm91dGVyLWJhc2VkIElQIFZQTnMgICAgIE1heSAy MDA1DQoNCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHByb2NlZHVyZXMgcmVxdWly ZWQgdG8gaW1wbGVtZW50IA0KICAgbXVsdGljYXN0IGZvciBhbiBJUCBtdWx0aWNhc3QgVlBOIGJh c2VkIG9uIFZpcnR1YWwgUm91dGVycy4gSXQgDQogICBkZXRhaWxzIHRoZSBzb2x1dGlvbiBhY2Nv cmRpbmcgdG8gcHJvY2VzcyBpbiBsb2NhbCBzaXRlcywgbWV0aG9kIG9mIA0KICAgZXN0YWJsaXNo aW5nIG11bHRpY2FzdCBkaXN0cmlidXRpb24gdHJlZXMgaW4gU1AgbmV0d29ya3MgYW5kIA0KICAg Zm9yd2FyZGluZyBmbG93IG9mIG11bHRpY2FzdCBkYXRhIHBhY2tldHMuIEl0IGlzIGJhc2VkIG9u IHByaW9yIA0KICAgcmVxdWlyZW1lbnRzIGZvciBNdWx0aWNhc3QgaW4gTDMgUHJvdmlkZXItUHJv dmlzaW9uZWQgVlBOc1tNUkVRVF0gYW5kIA0KICAgc3BlY2lmaWNhdGlvbnMgb2YgbmV0d29yayBi YXNlZCBJUCBWUE4gQXJjaGl0ZWN0dXJlIHVzaW5nIFZpcnR1YWwgDQogICBSb3V0ZXJzW1ZSLVZQ Tl0gdGhhdCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkLiBJdCANCiAgIGVzdGFi bGlzaGVzIHJldmVyc2Ugc2hvcnRlc3QgcGF0aCB0cmVlcyBpbiBTUCBuZXR3b3JrLCB0aG9zZSBW UnMgdGhhdA0KICAgaGF2ZSBtdWx0aWNhc3QgcmVxdWlyZW1lbnRzIGFjdCBhcyB0aGUgdHJlZSdz IGxlYWYgbm9kZXMgYW5kIGpvaW4gIA0KICAgbXVsdGljYXN0IGdyb3VwcyBkeW5hbWljYWxseS4g VGhpcyBzb2x1dGlvbiBpcyBhIHRyYWRlb2ZmIGJldHdlZW4gDQogICBzY2FsYWJpbGl0eSBhbmQg ZmxleGliaWxpdHkgb2Ygcm91dGVyIG9wdGltaXphdGlvbiwgd2hpY2ggZW5zdXJlcw0KICAgYmFu ZHdpZHRoIHJlc291cmNlIHV0aWxpemF0aW9uLg0KDQoyLiBUZXJtaW5vbG9neQ0KDQogICBIZXJl IHdlIHByb3Bvc2Ugc29tZSBnZW5lcmFsIHRlcm1zIGZvciBjb25jZXB0IHRoYXQgYXBwZWFyIGlu IHRoZSANCiAgIG11bHRpY2FzdCBzb2x1dGlvbiBvZiBWaXJ0dWFsIFJvdXRlci1iYXNlZCBJUCBW UE5zLiANCiAgICANCiAgIFBsZWFzZSByZWZlciB0byB0aGUgW1BQVlBOLVRFUk1dIGRvY3VtZW50 IGZvciBkZXRhaWxzIGFib3V0IA0KICAgdGVybWlub2xvZ3kgc3BlY2lmaWNhbGx5IHJlbGV2YW50 IHRvIFZQTiBhc3BlY3RzLiAgICANCg0KICAgSW4gYWRkaXRpb24gdG8gdGhlIHRlcm1pbm9sb2d5 IHVzZWQgaW4gW01SRVFUXSwgdGhpcyBkb2N1bWVudCANCiAgIGludHJvZHVjZXMgdGhlIGZvbGxv d2luZyB0ZXJtczoNCg0KDQogICAtIEdSRTogR2VuZXJpYyBSb3V0ZSBFbmNhcHN1bGF0aW9uLCB3 aGljaCBzcGVjaWZpZXMgYSBwcm90b2NvbCBmb3IgDQogICAgICAgICAgZW5jYXBzdWxhdGlvbiBv ZiBhbiBhcmJpdHJhcnkgbmV0d29yayBsYXllciBwcm90b2NvbCBvdmVyIA0KICAgICAgICAgIGFu b3RoZXIgYXJiaXRyYXJ5IG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wuDQoNCiAgIC0gUEUgOiBQcm92 aWRlciBFZGdlDQoNCiAgIC0gQ0UgOiBDdXN0b21lciBFZGdlDQoNCiAgIC0gU1AgOiBTZXJ2aWNl IFByb3ZpZGVyDQoNCiAgIC0gUElNOiBQcm90b2NvbCBJbmRlcGVuZGVudCBNdWx0aWNhc3QNCg0K ICAgLSBSUDogIFJlbmRlenZvdXMgUG9pbnQsIHdoaWNoIGlzIGEgc2hhcmVkIHJvb3QgZm9yIGV2 ZXJ5IG11bHRpY2FzdCANCiAgICAgICAgICBncm91cCwgc291cmNlcyBvbiB0aGUgc2FtZSBncm91 cCBzZW5kIHRoZWlyIHRyYWZmaWMgdG8gdGhlIFJQDQogICAgICAgICAgYW5kIHRoZW4gZm9yd2Fy ZGVkIHRvIHJlY2VpdmVycyBkb3duIGEgc2hhcmVkIGRpc3RyaWJ1dGlvbiANCiAgICAgICAgICB0 cmVlLg0KDQpIb25nLUtlIFpoYW5nLCBldCBhbC4gICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA1 ICAgICAgICAgICAgICAgW1BhZ2UgM10NCiANCg0KSW50ZXJuZXQgRHJhZnQgICAgTXVsdGljYXN0 IGluIFZpcnR1YWwgUm91dGVyLWJhc2VkIElQIFZQTnMgICAgIE1heSAyMDA1DQoNCg0KICAgLSBH IDogIGRlbm90ZXMgYSBtdWx0aWNhc3QgZ3JvdXAuICAgDQogDQogICAtIFMgOiAgZGVub3RlcyBh IG11bHRpY2FzdCBzb3VyY2UuIA0KDQogICAtIFAtR3JvdXA6IGEgZ3JvdXAgYWRkcmVzcyBpbiB0 aGUgU1AncyBhZGRyZXNzIHNwYWNlLg0KDQogICAtIEMtR3JvdXA6IGEgZ3JvdXAgYWRkcmVzcyBp biBhIFZQTidzIGFkZHJlc3Mgc3BhY2UuDQoNCg0KDQozLiBWUiBkZXBsb3ltZW50IHNjZW5hcmlv DQoNCiAgIE9uIFZSLVZQTiBuZXR3b3JrLCBWUE4gY3VzdG9tZXIgc2l0ZXMgYWNjZXNzIHRvIHNl cnZpY2UgcHJvdmlkZXIgDQogICBiYWNrYm9uZSB2aWEgdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBD dXN0b21lciBFZGdlKENFKSBlcXVpcG1lbnQgYW5kIA0KICAgVlIuIENFIGNhbiBjb25uZWN0IHRv IFZSIHZpYSBhbnkgYWNjZXNzIGxpbmssIHRoZW4gZm9yd2FyZCBhbGwgbm9uLQ0KICAgbG9jYWwg c2VydmljZSB0byBWUi4gVlJzIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBWUE4gZG9tYWluIG11c3Qg DQogICBkaXNjb3ZlciBWUE4gbWVtYmVyc2hpcCBhbmQgZGlzdHJpYnV0ZSByZWFjaGFiaWxpdHkg aW5mb3JtYXRpb24uIFZScyANCiAgIG9ubHkgbWFpbnRhaW4gcm91dGUgc3RhdGUgb2YgVlBOIHRo ZXkgYmVsb25nIHRvLiBUaGVyZSBjYW4gZXhpc3QgDQogICBtdWx0aXBsZSBWUnMgb24gb25lIFBy b3ZpZGVyIEVkZ2UoUEUpIGVxdWlwbWVudC4NCg0KICAgVGhyZWUgbWFpbiBWUiBkZXBsb3ltZW50 IHNjZW5hcmlvcyBjYW4gYmUgdXNlZCBmb3IgYnVpbGRpbmcgdmlydHVhbCANCiAgIHByaXZhdGUg bmV0d29ya3MgYXMgZGVzY3JpYmVkIGluIFtWUi1WUE5dOg0KDQoNCiAgICAgIDEpIFZSIHRvIFZS IGNvbm5lY3Rpdml0eSBvdmVyIGEgbGF5ZXIgMiBjb25uZWN0aW9uOw0KICAgICAgMikgVlIgdG8g VlIgY29ubmVjdGl2aXR5IHR1bm5lbGVkIG92ZXIgYW4gSVAgb3IgTVBMUyBuZXR3b3JrOw0KICAg ICAgMykgQWdncmVnYXRpbmcgbXVsdGlwbGUgdmlydHVhbCByb3V0ZXJzIG92ZXIgYSBiYWNrYm9u ZSB2aXJ0dWFsIA0KICAgcm91dGVyLiANCg0KICAgVGhlIGFib3ZlIFZSIGRlcGxveW1lbnQgc2Nl bmFyaW9zIGNhbiBjb2V4aXN0IG9uIGEgc2luZ2xlIFBFIGFuZCB0aGV5DQogICBhcmUgbm90IG11 dHVhbGx5IGV4Y2x1c2l2ZS4gIA0KDQogICBGb3IgbXVsdGljYXN0IHJlYWxpemF0aW9uLCB0aGUg dmlydHVhbCByb3V0ZXIgaGFzIGV4YWN0bHkgdGhlIHNhbWUgDQogICBtZWNoYW5pc21zIGFzIGEg cGh5c2ljYWwgcm91dGVyIGVudGlyZWx5LiBBbGwgZXhpc3Rpbmcgcm91dGluZyANCiAgIHByb3Rv Y29scyBjYW4gYmUgdXNlZCB1bm1vZGlmaWVkIG9uIFZSLCBiZXR3ZWVuIFZScyBvciBiZXR3ZWVu IFZSIGFuZA0KICAgQ0UuIE1vcmVvdmVyLCBtdWx0aWNhc3QgdHJhZmZpYyBjYW4gYmUgZm9yd2Fy ZGVkIHRocm91Z2ggSVAgb3IgTVBMUyANCiAgIGJhc2VkIHR1bm5lbHMuICANCiAgIA0KICAgVGhp cyBzb2x1dGlvbiBmaXRzIGZvciB0aG9zZSBTUCBuZXR3b3JrIHdpdGhvdXQgYmFja2JvbmUgVlIg b3IgZG8gbm90DQogICBuZWVkIHRvIGNvbnNpZGVyIGVmZmVjdCBvZiBiYWNrYm9uZSBWUi4NCg0K DQoNCkhvbmctS2UgWmhhbmcsIGV0IGFsLiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDUgICAg ICAgICAgICAgICBbUGFnZSA0XQ0KDQoNCkludGVybmV0IERyYWZ0ICAgIE11bHRpY2FzdCBpbiBW aXJ0dWFsIFJvdXRlci1iYXNlZCBJUCBWUE5zICAgICBNYXkgMjAwNQ0KDQo0LiBBdXRvLURpc2Nv dmVyeQ0KDQoNCiAgVGhlIGZpcnN0IHN0ZXAgdG8gcmVhbGl6ZSBWUE4gbXVsdGljYXN0IGlzIEF1 dG8tRGlzY292ZXJ5IG9mIFZQTiANCiAgbWVtYmVyc2hpcCwgdmFsaWRhdGlvbiBhbmQgZGlzdHJp YnV0aW9uIG9mIHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbi4NCiAgSXQgaXMgcmVxdWlyZWQgdG8g c2VsZWN0IGFwcHJvcHJpYXRlIFBFIGZvciBjdXN0b21lciBzaXRlcywgZGlzdHJpYnV0ZQ0KICBp ZGVudGlmaWVyIGZvciBWUE4sIGNvbmZpZ3VyZSBWUiBvbiBjb3JyZWxhdGl2ZSBQRSwgbWFrZSB0 aGUgVlIgYmUgDQogIG1lbWJlciBvZiBWUE4gY29ubmVjdGVkLCBhbmQgaGFuZGxlIHRoZSBpbmZv cm1hdGlvbiBvZiB0aGF0LiBUaGUgDQogIG1lY2hhbmlzbSB0byBkaXN0cmlidXRlIG1lbWJlcnNo aXAsIHRvcG9sb2d5LCBhbmQgdHVubmVsIGluZm9ybWF0aW9uIA0KICBhbW9uZyBWUnMgd2hpY2gg YXJlIG1lbWJlcnMgb2YgdGhlIHNhbWUgVlBOIGlzIHRoZSBzYW1lIGFzIHVuaWNhc3QNCiAgW1ZS LVZQTl0uICJBdXRvLWRpc2NvdmVyeSIgY2FuIGJlIGFjaGlldmVkIHRocm91Z2ggZXhwbGljaXQN CiAgY29uZmlndXJhdGlvbiwgZGlyZWN0b3J5IHNlcnZlciBhcHByb2FjaCwgcGlnZ3liYWNraW5n IGluZm9ybWF0aW9uIA0KICB1c2luZyBleHRlbmRlZCBCR1AgcHJvdG9jb2xzIG9yIG90aGVyIGFw cHJvYWNoZXMuDQoNCg0KNS4gUHJvY2VkdXJlcw0KDQo1LjEgRW5jYXBzdWxhdGlvbg0KDQogICBU aGlzIHNvbHV0aW9uIHVzZXMgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbiBtZXRob2RzIGFzIFtNVlBO LTddLiBUaGVzZSANCiAgIGFwcGx5IGFsc28gdG8gdGhlIE1QTFMtaW4tSVAgYW5kIE1QTFMtaW4t R1JFIGVuY2Fwc3VsYXRpb25zLg0KDQo1LjEuMSBFbmNhcHN1bGF0aW9uIGluIEdSRQ0KDQogICBH UkUgZW5jYXBzdWxhdGlvbiBjYW4gYmUgdXNlZCB3aGVuIGZvcndhcmRpbmcgbXVsdGljYXN0IHRy YWZmaWMgDQogICB0aHJvdWdoIFNQIG5ldHdvcmsuIFRoZSBJUCBQcm90b2NvbCBOdW1iZXIgZmll bGQgaW4gdGhlIFAtSVAgSGVhZGVyIA0KICAgYW5kIHRoZSBQcm90b2NvbCBUeXBlIGZpZWxkIG9m IHRoZSBHUkUgSGVhZGVyIG11c3QgZm9sbG93ICBbTVZQTi03XS4NCiAgIFRoZSBmb2xsb3dpbmcg ZGlhZ3JhbSBzaG93cyB0aGUgcHJvZ3Jlc3Npb24gb2YgdGhlIHBhY2tldCBhcyBpdCANCiAgIGVu dGVycyBhbmQgbGVhdmVzIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmsuDQoNCiAgIFBhY2tl dHMgcmVjZWl2ZWQgICAgICAgIFBhY2tldHMgaW4gdHJhbnNpdCAgICAgIFBhY2tldHMgZm9yd2Fy ZGVkDQogICBhdCBpbmdyZXNzIFBFICAgICAgICAgICBpbiB0aGUgc2VydmljZSAgICAgICAgICBi eSBlZ3Jlc3MgUEVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICBwcm92aWRlciBuZXR3b3Jr DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rDQogICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICBQLUlQIEhlYWRlciAgfA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICBHUkUgICAgICB8DQogICArKz09PT09PT09PT09PT0rKyAgICAgICArKz09PT09PT09PT09 PT0rKyAgICAgICArKz09PT09PT09PT09PT0rKw0KICAgfHwgQy1JUCBIZWFkZXIgfHwgICAgICAg fHwgQy1JUCBIZWFkZXIgfHwgICAgICAgfHwgQy1JUCBIZWFkZXIgfHwNCiAgICsrPT09PT09PT09 PT09PSsrID4+Pj4+ICsrPT09PT09PT09PT09PSsrID4+Pj4+ICsrPT09PT09PT09PT09PSsrDQog ICB8fCBDLVBheWxvYWQgICB8fCAgICAgICB8fCBDLVBheWxvYWQgICB8fCAgICAgICB8fCBDLVBh eWxvYWQgICB8fA0KICAgKys9PT09PT09PT09PT09KysgICAgICAgKys9PT09PT09PT09PT09Kysg ICAgICAgKys9PT09PT09PT09PT09KysNCg0KSG9uZy1LZSBaaGFuZywgZXQgYWwuICAgICAgIEV4 cGlyZXMgTm92ZW1iZXIgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDVdDQoNCg0KSW50ZXJuZXQg RHJhZnQgICAgTXVsdGljYXN0IGluIFZpcnR1YWwgUm91dGVyLWJhc2VkIElQIFZQTnMgICAgIE1h eSAyMDA1DQoNCjUuMS4yIEVuY2Fwc3VsYXRpb24gaW4gSVANCg0KICAgSVAtaW4tSVAgZW5jYXBz dWxhdGlvbiBjYW4gYWxzbyBiZSB1c2VkLiBUaGUgcGFyYW1ldGVyIGFib3V0IElQIA0KICAgUHJv dG9jb2wgTnVtYmVyIGZpZWxkIGZvbGxvd3MgW01WUE4tN10uIFRoZSBmb2xsb3dpbmcgZGlhZ3Jh bSBzaG93cw0KICAgdGhlIHByb2dyZXNzaW9uIG9mIHRoZSBwYWNrZXQgYXMgaXQgZW50ZXJzIGFu ZCBsZWF2ZXMgdGhlIHNlcnZpY2UNCiAgIHByb3ZpZGVyIG5ldHdvcmsuDQoNCiAgIFBhY2tldHMg cmVjZWl2ZWQgICAgICAgIFBhY2tldHMgaW4gdHJhbnNpdCAgICAgIFBhY2tldHMgZm9yd2FyZGVk DQogICBhdCBpbmdyZXNzIFBFICAgICAgICAgICBpbiB0aGUgc2VydmljZSAgICAgICAgICBieSBl Z3Jlc3MgUEVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICBwcm92aWRlciBuZXR3b3JrDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICBQLUlQIEhlYWRlciAgfA0KICAgKys9PT09PT09PT09PT09Kysg ICAgICAgKys9PT09PT09PT09PT09KysgICAgICAgKys9PT09PT09PT09PT09KysNCiAgIHx8IEMt SVAgSGVhZGVyIHx8ICAgICAgIHx8IEMtSVAgSGVhZGVyIHx8ICAgICAgIHx8IEMtSVAgSGVhZGVy IHx8DQogICArKz09PT09PT09PT09PT0rKyA+Pj4+PiArKz09PT09PT09PT09PT0rKyA+Pj4+PiAr Kz09PT09PT09PT09PT0rKw0KICAgfHwgQy1QYXlsb2FkICAgfHwgICAgICAgfHwgQy1QYXlsb2Fk ICAgfHwgICAgICAgfHwgQy1QYXlsb2FkICAgfHwNCiAgICsrPT09PT09PT09PT09PSsrICAgICAg ICsrPT09PT09PT09PT09PSsrICAgICAgICsrPT09PT09PT09PT09PSsrDQoNCg0KNS4xLjMgRW5j YXBzdWxhdGlvbiBpbiBNUExTDQoNCiAgIElmIHRoZSBQIHJvdXRlcyBvbiBTUCBuZXR3b3JrIHN1 cHBvcnQgTVBMUyBhbmQgZXh0ZW5kZWQgUlNWUCANCiAgIHByb3RvY29sLCBNUExTIGVuY2Fwc3Vs YXRpb24gY2FuIGJlIHVzZWQuIFRoZSBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uDQogICB0cmVlcyBj YW4gYmUgY29uc3RydWN0ZWQgYnkgUDJNUCBNUExTIExTUCBtZWNoYW5pc20sIGFuZCBhZGRpdGlv bmFsIA0KICAgTVBMUyBlbmNhcHN1bGF0aW9uIHByb2NlZHVyZXMgYXJlIHVzZWQsIGFzIHNwZWNp ZmllZCBpbiANCiAgIFtSU1ZQLVRFLVAyTVBdLg0KDQogICBQYWNrZXRzIHJlY2VpdmVkICAgICAg ICBQYWNrZXRzIGluIHRyYW5zaXQgICAgICBQYWNrZXRzIGZvcndhcmRlZA0KICAgIGF0IGluZ3Jl c3MgUEUgICAgICAgICAgIGluIHRoZSBzZXJ2aWNlICAgICAgICAgIGJ5IGVncmVzcyBQRXMNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBwcm92aWRlciBuZXR3b3JrDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAg ICAgICB8IFAtTVBMUyBIZWFkZXIgfA0KICAgKys9PT09PT09PT09PT09KysgICAgICAgKys9PT09 PT09PT09PT09KysgICAgICAgKys9PT09PT09PT09PT09KysNCiAgIHx8IEMtSVAgSGVhZGVyIHx8 ICAgICAgIHx8IEMtSVAgSGVhZGVyIHx8ICAgICAgIHx8IEMtSVAgSGVhZGVyIHx8DQogICArKz09 PT09PT09PT09PT0rKyA+Pj4+PiArKz09PT09PT09PT09PT0rKyA+Pj4+PiArKz09PT09PT09PT09 PT0rKw0KICAgfHwgQy1QYXlsb2FkICAgfHwgICAgICAgfHwgQy1QYXlsb2FkICAgfHwgICAgICAg fHwgQy1QYXlsb2FkICAgfHwNCiAgICsrPT09PT09PT09PT09PSsrICAgICAgICsrPT09PT09PT09 PT09PSsrICAgICAgICsrPT09PT09PT09PT09PSsrDQoNCjUuMS40IEludGVyb3BlcmFiaWxpdHkN Cg0KICAgSW4gVlItVlBOIG5ldHdvcmssIGV2ZXJ5IFZpcnR1YWwgUm91dGVyIGluIFBFIG11c3Qg YWdyZWUgb24gdGhlIA0KICANCkhvbmctS2UgWmhhbmcsIGV0IGFsLiAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDQogIA0KSW50ZXJuZXQgRHJhZnQg ICAgTXVsdGljYXN0IGluIFZpcnR1YWwgUm91dGVyLWJhc2VkIElQIFZQTnMgICAgIE1heSAyMDA1 DQoNCiAgIG1ldGhvZCBvZiBlbmNhcHN1bGF0aW9uIG1lbnRpb25lZCBhYm92ZS4gSXQgY2FuIGJl IGltcGxlbWVudGVkDQogICBlaXRoZXIgYnkgY29uZmlndXJhdGlvbiBvciBtZWFucyBvZiBzb21l IGRpc2NvdmVyeSBwcm90b2NvbHMuIA0KICAgSGVyZSwgR1JFIGVuY2Fwc3VsYXRpb24gaXMgc3Vn Z2VzdGVkIHRvIGJlIHVzZWQgZHVlIHRvIGl0cyBzaW1wbGUgDQogICBhbmQgbG93ZXIgcGF5bG9h ZC4NCg0KDQo1LjIgTXVsdGljYXN0IHNvdXJjZSByb3V0aW5nIHRhYmxlDQoNCiAgIEFjY29yZGlu ZyB0byBmb3J3YXJkIG1vZGVsIG9mIFZSLVZQTiwgZXZlcnkgVlIgc2hvdWxkIHN0b3JlIGEgDQog ICBtdWx0aWNhc3Qgc291cmNlIHJvdXRpbmcgdGFibGUgY29uc3RydWN0ZWQgYnkgcmVhY2hhYmls aXR5IA0KICAgaW5mb3JtYXRpb24gZGlzdHJpYnV0ZWQgYnkgVlJzIHRocm91Z2ggZGlmZmVyZW50 IG1lY2hhbmlzbXMgc3VjaCANCiAgIGFzIHN0YXRpYyByb3V0aW5nLCB0cmFkaXRpb25hbCB1bmlj YXN0IHJvdXRpbmcgb3IgbXVsdGljYXN0IA0KICAgcHJvdG9jb2wuIFRoaXMgdGFibGUgcmVjb3Jk cyByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24gb2YgZXZlcnkgDQogICBtdWx0aWNhc3Qgc291cmNl IFMgd2hpY2ggdGhlIFZSIGlzIGludGVyZXN0ZWQgaW4gYW5kIHRoZSByZWxhdGl2ZSANCiAgIFZS LCB0aGF0IGlzIChTLCBWUikuIA0KDQoNCjUuMyBSb3V0aW5nIGluIHRoZSBWUE4gc2l0ZXMgDQoN CiAgIEl0IGlzIG5lY2Vzc2FyeSB0byBkZXBsb3kgbG9jYWwgbXVsdGljYXN0IHJvdXRpbmcgcHJv dG9jb2xzIGluIHRoZSANCiAgIFZQTiBzaXRlcy4gQ29uc2lkZXJpbmcgdGhlIHN1cGVyaW9yaXR5 IGFuZCBnZW5lcmFsaXR5IG9mIFBJTSANCiAgIHByb3RvY29sLCBjZXJ0YWluIFBJTSAoUElNLVNN LCBCaWRpcmVjdGlvbmFsIFBJTSwgb3IgUElNLVNTTSkgYXJlIA0KICAgc3VnZ2VzdGVkLiBUaGVy ZSBpcyBhbiBpbXBvcnRhbnQgY2hhcmFjdGVyaXN0aWMgaW4gVlIgVlBOcyB0aGF0IGVhY2ggDQog ICBWUiBiZWNvbWVzIGEgUElNIGFkamFjZW5jeSBvZiB0aGUgQ0Ugcm91dGVyIGNvbm5lY3RlZCwg YnV0IENFIHJvdXRlcnMNCiAgIGF0IGRpZmZlcmVudCBzaXRlcyBkbyBub3QgYmVjb21lIFBJTSBh ZGphY2VuY2llcyBvZiBlYWNoIG90aGVyLCBhbmQgDQogICBWUnMgaW4gdGhlIHNhbWUgUEUgZG8g bm90IGhhdmUgUElNIGFkamFjZW5jaWVzIHRvIGVhY2ggb3RoZXIsIGVpdGhlci4NCg0KICAgSW4g dGhpcyBzb2x1dGlvbiwgYWxsIFZScyBjb25uZWN0aW5nIHRvIFZQTiBzaXRlcyBhcmUgZGVwbG95 ZWQgYXMgDQogICBwcm94eSBTb3VyY2UvUlBzIGZvciB0aGF0IFZQTiBzaXRlLiBUaGlzIHByb3h5 IFNvdXJjZS9SUCBjb25uZWN0IHRvIA0KICAgdGhlIG11bHRpY2FzdCBzb3VyY2UgaW4gdGhlIFZQ TiBkaXJlY3RseSBvciB2aWEgYSBDRSByb3V0ZXIuIFNpbmNlIA0KICAgZWFjaCBWUiBhY3RzIGFz IGEgcHJveHktU291cmNlL1JQIG9mIGl0cyBWUE4sIGl0IGNhbiBmb3JtIGFuIA0KICAgaW5kZXBl bmRlbnQgbXVsdGljYXN0IHRyZWUgd2l0aGluIHRoZSBjdXN0b21lciBzaXRlIHJlZ2FyZGxlc3Mg b2YgDQogICBtdWx0aWNhc3QgdHJlZSBmb3JtYXRpb25zIGluIG90aGVyIHNpdGVzLiANCg0KICAg RnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBTUCwgUHJveHkgU291cmNlL1JQIGlzIHRoZSBkZXB1 dGF0aW9uIG9mIA0KICAgbG9jYWwgVlBOIHNpdGUgLiBPbiB0aGUgb3RoZXIgaGFuZCwgaXQgaXMg dGhlIFJQIG9mIGFsbCBtdWx0aWNhc3QNCiAgIHRyZWVzIGluIGxvY2FsIFZQTiBzaXRlIGZyb20g dGhlIHN0YW5kcG9pbnQgb2YgVlBOIHNpdGUsIGFsbCByb3V0ZSANCiAgIHN0YXRlcyBzdWNoIGFz IChDLVNvdXJjZSxDLUdyb3VwKSBhbmQgKCosQy1Hcm91cCkgYXNzZW1ibGUgdG8gUlAgdmlhDQog ICBQSU0gSm9pbi9QcnVuZSBtZXNzYWdlcy4gSGVyZSBhIFAtZ3JvdXAgYWRkcmVzcyB3b3VsZCBi ZSBhIGdyb3VwIA0KICAgYWRkcmVzcyBpbiB0aGUgU1AncyBhZGRyZXNzIHNwYWNlLCBhbmQgYSBD LWdyb3VwIGFkZHJlc3Mgd291bGQgYmUgDQogICBhIGdyb3VwIGFkZHJlc3MgaW4gYSBWUE4ncyBh ZGRyZXNzIHNwYWNlLg0KDQogICBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGN1c3RvbWVyIFZQ TiBzaXRlcywgVlIgbXVzdCBiZSB0aGUgZWdyZXNzIA0KICAgDQpIb25nLUtlIFpoYW5nLCBldCBh bC4gICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgN10NCg0K DQpJbnRlcm5ldCBEcmFmdCAgICBNdWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAg VlBOcyAgICAgTWF5IDIwMDUNCg0KICAgb2YgYWxsIHRyYWZmaWMuIEFjdGluZyBhcyBSUCBtZWFu cyB0aGF0IG11bHRpY2FzdCBzb3VyY2VzIGluIHRoZSBWUE4NCiAgIHNpdGVzIG11c3QgcmVnaXN0 ZXIgdG8gVlIsIHRoZW4gZm9yd2FyZCBtdWx0aWNhc3QgcGFja2V0cyB0byByZW1vdGUgDQogICBz aXRlcy4gSXQgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBkaXJlY3Rpb24gb2YgbG9jYWwgc2l0ZXMn IHRyYWZmaWMuIA0KDQoNCjUuNCAgICBSb3V0aW5nIGluIHRoZSBTUCBOZXR3b3JrDQoNCiAgIEZp cnN0IHRoZXJlIGlzIGEgZGVmaW5pdGlvbiBvZiB0aGF0IFNvdXJjZS1WUiBpcyBhIFZSIGNvbm5l Y3RlZCB0byANCiAgIGEgY3VzdG9tZXIgVlBOIHNpdGUgd2hpY2ggaGFzIG11bHRpY2FzdCBzb3Vy Y2UgdHJhZmZpYy4gQWNjb3JkaW5nIHRvIA0KICAgVlBOIG1lbWJlcnNoaXAgYW5kIHJlYWNoYWJp bGl0eSBpbmZvcm1hdGlvbiwgaXQgY2FuIGNvbnN0cnVjdCBhIA0KICAgU2hvcnRlc3QgUGF0aCBU cmVlIHJvb3RlZCBhdCBldmVyeSBTb3VyY2UtVlIgYW5kIGFkZHJlc3NlZCBvbiBQLUdyb3VwDQog ICBpbiB0aGUgU1AncyBhZGRyZXNzIHNwYWNlLiBUaGUgc2hvcnRlc3QgcGF0aCB0cmVlIChTb3Vy Y2UtVlIsIA0KICAgUC1Hcm91cCkgY2FuIGJlIHNldHVwIHVzaW5nIFBJTS1ETSBvciBNUExTIFAy TVAgdHVubmVsLiAgQWxsIHRyYWZmaWMNCiAgIGZyb20gVlJzIHNoYXJlIHRoZSB0cmVlIChTb3Vy Y2UtVlIgLFAtR3JvdXApLg0KDQogICBXaGVuIHRoZXJlIGlzIGEgU291cmNlLVZSIGFjdGluZyBh cyBhIHByb3h5LVJQIG9mIGN1c3RvbWVyIHNpdGUgdG8NCiAgIHJlY2VpdmUgbXVsdGljYXN0IHBh Y2tldHMgZnJvbSBsb2NhbCBjdXN0b21lciBzaXRlLCBpdCBlbmNhcHN1bGF0ZXMgDQogICB0aGUg cGFja2V0cyBpbiBHUkUgb3IgaW4gSVAsIHRoZSB0cmFmZmljIHdpbGwgYnJvYWRjYXN0IHRvIGFs bCBWUnMgDQogICBhY3RpbmcgYXMgbGVhZiBub2RlcyBpbiB0aGUgc2FtZSBWUE4gYWxvbmcgdGhl IFNob3J0ZXN0IFBhdGggVHJlZS4NCg0KDQoNCjUuNSAgICBNdWx0aWNhc3QgVlBOIERhdGEgRm9y d2FyZGluZw0KDQogICBBZnRlciBWUnMgYWN0aW5nIGFzIGxlYWYgbm9kZXMgaGF2ZSByZWNlaXZl ZCB0aGUgZmlyc3QgcGFja2V0IGZyb20gDQogICBTb3VyY2UtVlIsIHRoZXkgZXh0cmFjdCBiYXNp YyBpbmZvcm1hdGlvbiBpbiBlbmNhcHN1bGF0ZWQgcGFja2V0cywgDQogICB0aGF0IGlzIFZSIGFu ZCBQLUdyb3VwLCB0aGVuIGRlY2lkZSB3aGV0aGVyIGl0IGhhcyBtdWx0aWNhc3QgDQogICByZXF1 aXJlbWVudCBmcm9tIFZScy4gSWYgdGhlcmUgaXMgbm8gcmVjZWl2ZXIgaW50ZXJlc3RlZCBpbiB0 aGlzDQogICBWUiwgaXQgZGlzY2FyZHMgbXVsdGljYXN0IHBhY2tldHMgYW5kIHBydW5lcyBmcm9t IG11bHRpY2FzdCB0cmVlIA0KICAgKFNvdXJjZS1WUiwgUC1Hcm91cCkgdG8gcmVqZWN0IHRyYWZm aWMgZnJvbSB0aGlzIFZSLiBUaG9zZSBsZWFmIFZScyANCiAgIHdoaWNoIGhhdmUgYmVlbiBwcnVu ZWQgZnJvbSB0cmVlcyB3aWxsIHN0b3JlIHN0YXRlIGluZm9ybWF0aW9uIG9mIA0KICAgKFNvdXJj ZS1WUiAsUC1Hcm91cCkuIEFzIHNvb24gYXMgbG9jYWwgc2l0ZSBoYXMgcmVxdWlyZW1lbnRzIG9m IGFueSANCiAgIEMtU291cmNlIGluIFZQTiBzaXRlIHdoaWNoIHRoaXMgVlIgY29ubmVjdGluZyB0 bywgdGhlIHBydW5lZCBsZWFmIA0KICAgbm9kZXMgc2hvdWxkIGV4cGxpY2l0bHkgam9pbiB0aGUg dHJlZSBhZ2FpbiwgdGhlbiByZWNlaXZlIG11bHRpY2FzdCANCiAgIHBhY2tldHMgZnJvbSB0aGlz IFZSLiBFdmVyeSBWUiBhY3RpbmcgYXMgbGVhZiBub2RlcyByZXBlYXRzIHRoZXNlIA0KICAgb3Bl cmF0aW9ucywgdGh1cyBtdWx0aWNhc3QgcGFja2V0cyBmcm9tIFNvdXJjZS1WUiBoYXZlIGJlZW4g Zm9yd2FyZGVkDQogICBvbmx5IHRvIHRob3NlIFZScyB3aGljaCBoYXZlIHJlcXVpcmVtZW50cyBv ZiBtdWx0aWNhc3Qgc291cmNlLiBFdmVyeQ0KICAgVlIgY2FuIGJlIHNvdXJjZSAocm9vdCkgb3Ig cmVjZWl2ZXIgKGxlYWYpLCBkaWZmZXJlbnQgdHJlZXMgYXJlIA0KICAgaWRlbnRpZmllZCBieSAo U291cmNlLVZSLCBQLUdyb3VwKS4NCg0KICAgV2hlbiBhIGNlcnRhaW4gbGVhZiBWUiBoYXMgbmV3 IG11bHRpY2FzdCByZXF1aXJlbWVudHMgdG8gbXVsdGljYXN0DQogICBzb3VyY2UgUywgaXQgY2hl Y2tzIHRoZSBtdWx0aWNhc3Qgc291cmNlIHJvdXRpbmcgdGFibGUgdG8gZ2V0IHRoZSANCiAgIHJl bGF0aW9uIGJldHdlZW4gUyBhbmQgU291cmNlLVZSLiBJZiB0aGUgbGVhZiBWUiBoYXMgYmVlbiBv biB0aGUgdHJlZQ0KICANCkhvbmctS2UgWmhhbmcsIGV0IGFsLiAgICAgICBFeHBpcmVzIE5vdmVt YmVyIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDQoNCiAgDQpJbnRlcm5ldCBEcmFmdCAg ICBNdWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAgVlBOcyAgICAgTWF5IDIwMDUN Cg0KICAoU291cmNlLVZSLCBQLUdyb3VwKSwgaXQgY29udGludWVzIHJlY2VpdmluZyBwYWNrZXRz IGZyb20gU291cmNlLVZSIA0KICAgd2l0aG91dCBleHRyYSBwcm9jZXNzaW5nLiBJZiB0aGlzIGxl YWYgVlIgaGFzIHBydW5lZCBpdHNlbGYgZnJvbSB0aGUgDQogICB0cmVlIHJvb3RlZCBvbiBTb3Vy Y2UtVlIsIGl0IHNlbmRzIGpvaW4gbWVzc2FnZSB0byB0aGUgdHJlZSwgdGhlbiANCiAgIGJlZ2lu cyB0byByZWNlaXZlIGVuY2Fwc3VsYXRlZCBwYWNrZXRzIGZyb20gU291cmNlLVZSLg0KDQoNCiAg IEFmdGVyIHJlY2VpdmluZyBwYWNrZXRzLCBWUiBkZWNhcHN1bGF0ZXMgYW5kIHJlY292ZXJzIG11 bHRpY2FzdCANCiAgIHBhY2tldHMsIHRoZW4gZm9yd2FyZHMgdGhlbSB0byBsb2NhbCByZWNlaXZl cnMgb3IgZGlzY2FyZHMgdGhlbSANCiAgIGFjY29yZGluZyB0byBsb2NhbCBtdWx0aWNhc3QgZm9y d2FyZGluZyB0YWJsZS4gDQoNCg0KICAgRnJvbSB0aGUgYWJvdmUtbWVudGlvbmVkLCBlYWNoIHBy b2Nlc3Mgb2YgbXVsdGljYXN0IHRyZWVzIGFuZCANCiAgIG11bHRpY2FzdCBwYWNrZXRzIGlzIGJh c2VkIG9uIHJlcXVpcmVtZW50cyBvZiBzb3VyY2UgKGxvY2FsIEMtU291cmNlDQogICBvZiBWUnMg KSBmcm9tIGxlYWYgVlJzLCB3aGlsZSBpbmRlcGVuZGVudCBvZiBDLUdyb3VwLiBPbmx5IHdoZW4g YWxsIA0KICAgdHJhZmZpYyBmcm9tIFNvdXJjZS1WUiBoYXZlIHJlYWNoZWQgdG8gbGVhZiBWUnMg d2hpY2ggaGF2ZSANCiAgIHJlcXVpcmVtZW50cyB0aHJvdWdoIG11bHRpY2FzdCB0cmVlcywgZG8g bGVhZiBWUnMgZGVjaWRlIHdoZXRoZXIgdG8NCiAgIGRpc2NhcmQgb3IgZm9yd2FyZCBtdWx0aWNh c3QgcGFja2V0cyBhY2NvcmRpbmcgdG8gbG9jYWwgc3RhdGUgDQogICAoQy1Tb3VyY2UsQy1Hcm91 cCkuDQoNCg0KDQo2LiBTY2FsYWJpbGl0eSBTb2x1dGlvbg0KDQogICBTY2FsYWJpbGl0eSBpcyBh IGtleSByZXF1aXJlbWVudCBmb3IgbXVsdGljYXN0IFZQTiBzb2x1dGlvbnMuIA0KICAgR2VuZXJh bGx5LCBlZmZpY2llbnQgbXVsdGljYXN0IHJvdXRpbmcgYW5kIHNjYWxhYmlsaXR5IGFyZSBjb21w ZXRpbmcNCiAgIGdvYWxzLiBUaGUgU1AgaGFzIG5vIGNvbnRyb2wgb24gdGhlIG51bWJlciBvZiBt dWx0aWNhc3QgZ3JvdXBzIGluIHRoZQ0KICAgVlBOcyBhbmQgYW1vdW50IG9mIHN0YXRlcyBpbiB0 aGUgcm91dGVzLiBJbiB0aGlzIHNvbHV0aW9uLCBNdWx0aWNhc3QgDQogICB0cmVlcyBpbiBTUCBu ZXR3b3JrIGFyZSBhbGwgU2hvcnRlc3QgUGF0aCB0cmVlcy4gVGhlIG51bWJlciBvZiB0cmVlcyAN CiAgIHJvb3RlZCBvbiBWUnMgaXMgcmVsYXRpdmVseSBzdGF0aWMuIFRoZSBncm91cCBhZGRyZXNz IGNhbiBiZSANCiAgIGNvbmZpZ3VyZWQgYnkgYWRtaW5pc3RyYXRvciBvciBhdXRvLXNlbGVjdGlv biBpbiBjZXJ0YWluIHJhbmdlIGFuZCANCiAgIHRoZSBhZGRyZXNzIGNhbiBiZSB0aGUgc2FtZSBm b3IgZGlmZmVyZW50IHNvdXJjZSBWUnMuIFRodXMgbnVtYmVyIG9mIA0KICAgdHJlZXMgb24gU1Ag bmV0d29yayB3aWxsIG5laXRoZXIgZXhjZWVkIHRvdGFsIG9mIFZScyBub3IgY2hhbmdlIHdpdGgg DQogICB0aGUgbnVtYmVyIG9mIGN1c3RvbWVycywgdGhlIG51bWJlciBvZiBjbGllbnQgbXVsdGlj YXN0IGNoYW5uZWxzIGFuZCANCiAgIHZhcnlpbmcgb2YgdG9wb2xvZ3kuIFNvIGl0IG5vdCBvbmx5 IHJlZHVjZXMgcGF5bG9hZCBvbiBTUCBuZXR3b3JrIA0KICAgZWZmZWN0aXZlbHkgYnV0IGFsc28g aW1wcm92ZXMgc2NhbGFiaWxpdHkuIA0KDQoNCjcuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQog DQogICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkaXNjdXNzZWQgaW4gW1ZSLVZQTl0gYXBwbHkg dG8gdGhpcyBkb2N1bWVudC4NCiAgIEZyb20gYSByb3V0ZSBkZXBsb3ltZW50IHN0YW5kcG9pbnQs IHRoZSBpc29sYXRpb24gZGVncmVlIGJldHdlZW4gDQogICBkaWZmZXJlbnQgVlBOcyBpcyBjcnVj aWFsIHRvIGEgZ3JlYXQgZXh0ZW50LiBJbiB0aGlzIHNvbHV0aW9uLCANCiAgIA0KSG9uZy1LZSBa aGFuZywgZXQgYWwuICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwNSAgICAgICAgICAgICAgIFtQ YWdlIDldDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgTXVsdGljYXN0IGluIFZpcnR1YWwgUm91dGVy LWJhc2VkIElQIFZQTnMgICAgIE1heSAyMDA1DQoNCiAgIHByb2Nlc3NpbmcgaW4gU1AgbmV0d29y ayB3aWxsIGJlIGltcGxlbWVudGVkIGluIHRob3NlIFZScyBiZWxvbmdpbmcgDQogICB0byB0aGUg c2FtZSBWUE4uIEl0IGNhbiBnZXQgZ29vZCBpc29sYXRpb24gcGVyZm9ybWFuY2UgYmVjYXVzZSBl dmVyeQ0KICAgVlBOIGhhcyBwcml2YXRlIG11bHRpY2FzdCBhZGRyZXNzIHNwYWNlLiBJZiBvbmx5 IHRoZSB3aG9sZSBzeXN0ZW0gDQogICBpc29sYXRlcyBWUnMgaW4gdGhlIHNhbWUgUEUgcmVsaWFi bHksIHRoZSBzZWN1cml0eSB3aWxsIHJlYWNoIGEgDQogICBwcmVmZXJhYmxlIGxldmVsLiANCg0K DQo4LiBBY2tub3dsZWRnbWVudA0KDQogICBXZSB3b3VsZCBsaWtlIHRvIHRoYW5rIFF1YW4tTGlu IExpLEVuLUh1aSBMaXUsIFl1ZSBaaGFuZywgU2h1YWkgR2FvIGFuZCANCiAgIFlhLWp1YW4gUWlu IGZvciB0aGVpciB2YWx1YWJsZSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbiBvbiB0aGlzIGRvY3Vt ZW50Lg0KICAgDQoNCjkuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQogICBbUFBWUE4tVEVSTV0gICJQ cm92aWRlciBQcm92aXNpb25lZCBWUE4gdGVybWlub2xvZ3kiLCBMLiBBbmRlcnNzb28sIA0KICAg ICAgICAgICAgICAgVC4gTWFkc2VuLCBTZXB0ZW1iZXIgMjAwNCwgDQogICAgICAgICAgICAgICBk cmFmdC1pZXRmLWwzdnBuLXBwdnBuLXRlcm1pbm9sb2d5LTA0DQogICANCjEwLiBJbmZvcm1hdGl2 ZSBSZWZlcmVuY2VzDQogICBbTVJFUVRdICAgICJSZXF1aXJlbWVudHMgZm9yIE11bHRpY2FzdCBp biBMMyBQcm92aWRlci1Qcm92aXNpb25lZA0KICAgICAgICAgICAgICBWUE5zIiwgVC4gTW9yaW4s IEVkLiAsRnJhbmNlIFRlbGVjb20gUiZELCBGZWJydWFyeSAyMDA1LA0KICAgICAgICAgICAgICBk cmFmdC1pZXRmLWwzdnBuLXBwdnBuLW1jYXN0LXJlcXRzLTAwLnR4dA0KICAgW1ZSLVZQTl0gICAi TmV0d29yayBiYXNlZCBJUCBWUE4gQXJjaGl0ZWN0dXJlIHVzaW5nIFZpcnR1YWwgUm91dGVycyIs IA0KICAgICAgICAgICAgICBQYXVsIEtuaWdodCwgSGFtaWQgT3VsZC1CcmFoaW0sIEJyeWFuIEds ZWVzb24sIA0KICAgICAgICAgICAgICBBcHJpbCAyMDA0LCBkcmFmdC1pZXRmLWwzdnBuLXZwbi12 ci0wMi50eHQgDQogICBbTVZQTi03XSAgICJNdWx0aWNhc3QgaW4gTVBMUy9CR1AgVlBOcyIsIEUu IFJvc2VuLiBldC4gYWwuLA0KICAgICAgICAgICAgICBkcmFmdC1yb3Nlbi12cG4tbWNhc3QtMDcu dHh0DQoNCjExLkF1dGhvciBJbmZvcm1hdGlvbg0KDQogICBIb25nLUtlIFpoYW5nDQogICBJUCBs YWINCiAgIEJlaWppbmcgSmlhb1RvbmcgVW5pdi4NCiAgIENoaW5hLCAxMDAwNDQNCiAgIEVtYWls OiBoa3poYW5nQGNlbnRlci5uanR1LmVkdS5jbg0KDQogICBDaHVuLVl1ZSBaaG91LCBCaW5nLVlp IFpoYW5nDQogICBJUCBsYWINCiAgIEJlaWppbmcgSmlhb1RvbmcgVW5pdi4NCiAgIENoaW5hLCAx MDAwNDQNCiAgIENodW4tWXVlIFpob3U6IHpob3VjaHVueXVlQGhvdG1haWwuY29tDQogICBCaW5n LVlpIFpoYW5nOiBiaW5neWl6aGFuZ0Bob3RtYWlsLmNvbQ0KDQpIb25nLWtlIFpoYW5nLCBldCBh bC4gICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA1ICAgICAgICAgICAgICBbUGFnZSAxMF0NCg0K DQpJbnRlcm5ldCBEcmFmdCAgICBNdWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAg VlBOcyAgICAgTWF5IDIwMDUNCg0KMTIuIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQN Cg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBv ciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIg cmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVt ZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBk b2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmln aHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXBy ZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVu dGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMg d2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQg aW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFk ZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vu c2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0 IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1 c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2Vy cyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRG IG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0K DQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0 cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNh dGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVj aG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRh cmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQgaWV0Zi0N CiAgIGlwckBpZXRmLm9yZy4NCg0KDQoNCg0KRnVsbCBDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENv cHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLiAgVGhpcyBkb2N1bWVudCBp cyANCiAgIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBj b250YWluZWQgaW4gQkNQDQogICA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwg dGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpcg0KICAgcmlnaHRzLg0KDQogICBUaGlzIGRvY3Vt ZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQNCiAg IG9uIGFuICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElP TiBIRS9TSEUNCiAgIFJFUFJFU0VOVFMgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUg SU5URVJORVQgU09DSUVUWSBBTkQNCiAgIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUQVNLIEZP UkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLA0KICAgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNM VURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUDQogICBUSEUgVVNFIE9G IFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUg0K ICAgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBG T1IgQQ0KICAgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkhvbmctS2UgWmhhbmcsIGV0IGFsLiAg ICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDQo= --=====001_Dragon282608173886_=====-- From l3vpn-bounces@ietf.org Tue Jun 07 11:05:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dffdo-0005JS-Td; Tue, 07 Jun 2005 11:05:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfec3-0001Wf-Ve for l3vpn@megatron.ietf.org; Tue, 07 Jun 2005 09:59:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24558 for ; Tue, 7 Jun 2005 09:59:25 -0400 (EDT) Received: from web305.biz.mail.mud.yahoo.com ([68.142.199.181]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dfex5-0003ae-PY for l3vpn@ietf.org; Tue, 07 Jun 2005 10:21:13 -0400 Message-ID: <20050607135909.33947.qmail@web305.biz.mail.mud.yahoo.com> Received: from [47.153.135.97] by web305.biz.mail.mud.yahoo.com via HTTP; Tue, 07 Jun 2005 06:59:09 PDT Date: Tue, 7 Jun 2005 06:59:09 -0700 (PDT) From: Joseph Laria To: internet-drafts@ietf.org, l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-181447919-1118152749=:33761" X-Spam-Score: 0.0 (/) X-Scan-Signature: 66c1f4b8ef7d9911c5b16e6767030a3e X-Mailman-Approved-At: Tue, 07 Jun 2005 11:05:18 -0400 Cc: Subject: draft-ietf-l3vpn-vr-mib-06 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --0-181447919-1118152749=:33761 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline Hi, Attached is the latest version of draft-ietf-l3vpn-vr-mib. The Virtual Router MIB is a work item of the Provider Provisioned Virtual Private Networks (L3) Working Group. Title: Virtual Router Management Information Base Using SMIv2 Author(s): Elwin Stelzer, Sam Hancock, Benson Schliesser, Joseph Laria Filename: draft-ietf-l3vpn-vr-mib-06.txt Pages: XX Date: June 2005 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). The changes which have been made include: 1. Modify vrRPTrigger syntax to use BITS construct in place of integer. Thanks. Joe Laria --0-181447919-1118152749=:33761 Content-Type: text/plain; name="draft-ietf-l3vpn-vr-mib-06.txt" Content-Description: 1774939154-draft-ietf-l3vpn-vr-mib-06.txt Content-Disposition: inline; filename="draft-ietf-l3vpn-vr-mib-06.txt" INTERNET-DRAFT Elwin Stelzer draft-ietf-l3vpn-vr-mib-06.txt Corona Networks, Inc. Expires: December 2005 Sam Hancock ACM Systems Benson Schliesser SAVVIS Communications Joseph Laria (Ed.) Level Stream Research June 2005 Virtual Router Management Information Base Using SMIv2 Status of this Memo This document is an Internet-Draft. By submitting this document, each author certifies that any applicable patent or other IPR claims of which he or she is aware has been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a product of the IETF's Layer 3 Virtual Private Network (l3vpn) working group. Comments should be addressed to WG's mailing list at l3vpn@ietf.org. The charter for l3vpn may be found at http://www.ietf.org/html.charters/l3vpn-charter.html Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). Layer-3 VPN Group Expires December 2005 [Page 1] Draft Virtual Router MIB June 2005 Table of Contents 1.0 Terminology 2.0 Introduction 3.0 The Internet-Standard Management Framework 4.0 Overview of the Virtual Router MIB 4.1 SNMP Contexts for Management for Virtual Routers 4.2 VR Indexing 4.3 Creation and Deletion of VRs 4.4 Administrative and Operational Status of VRs 4.5 Binding interfaces to a VR 4.6 Setting per VR limits 4.7 Per VR Statistics 4.8 Traps 4.9 Usability Considerations 4.9.1 Multiple Agents 4.9.2 Provisioning vs. Monitoring 5.0 Sample VR MIB Configuration Scenario 5.1 Creation of a VR 6.0 Definition of the Virtual Router MIB 7.0 Acknowledgments 8.0 Security Considerations 9.0 References 9.1 Normative References 9.2 Informative References 10.0 Authors' Addresses 11.0 Intellectual Property Considerations 12.0 Full Copyright Statement 13.0 IANA Considerations for L3VPN-VR-MIB 1.0 Terminology This document uses terminology defined in [PPVPN-FW] and [PPVPN-VR]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [RFC2119]. 2.0 Introduction This memo defines a MIB for the Virtual Router [PPVPN-VR, PPVPN-VR-AS] model of Provider Provisioned VPNs [PPVPN-FW]. Following are the goals, in defining this MIB: - To have a means for Service Providers to provision VPN service for subscribers, at the PE device. - To make the agent-side implementation simple, by not modifying the existing standard MIBs. - Define all the gluing tables that are needed toward this end. Layer-3 VPN Group Expires December 2005 [Page 2] Draft Virtual Router MIB June 2005 3.0 The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4.0 Overview of the Virtual Router MIB 4.1 SNMP Contexts for Management for Virtual Routers There is a need for a single agent to manage multiple Virtual Routers. The Architecture for describing SNMP Management Frameworks [RFC3411] provides a way to support such cases. Managing multiple virtual routers requires that the PE management plane be subdivided into logical VR management domains. In the VR model of PPVPNs a single PE device may contain many virtual routers. Different management entities SHOULD be able to manage specific virtual routers and associated services. The Service Provider MUST be able to manage all virtual routers and associated services. Using SNMP contexts to group a collection of management information provides the following benefits: (1) Uses a standard framework defined by the IETF, allowing the product to remain flexible to all implementations of virtual router devices. (a) Use SNMPv2c Community String's (b) Use SNMPv3 contextName's (2) Prevents vendors from having to modify the standard MIBs, allowing the implementation to remain standards compliant. (3) Provides a framework that will work for RIP, OSPF, IS-IS, BGP, IP-FORWARDING, MPLS, and any other MIB that can be administratively grouped with a VR. Layer-3 VPN Group Expires December 2005 [Page 3] Draft Virtual Router MIB June 2005 The SNMP context for the Virtual Router instance can be specified in the VrConfigTable. The VrContextName columnar object is used to set the SNMPv2c Community String or the SNMPv3 contextName for a given VR. A virtual router context represents the set of MIB objects that could be administratively grouped within a VR. For example, each VR would maintain its own instance of routing protocol MIB tables. However, the ADMIN context would contain single instances of objects and tables that pertain to system wide configuration such as the Entity, Interfaces, and ATM MIBs. A management system using the SNMP context of a particular virtual router MUST be able to manage the virtual router without disrupting other virtual routers in the same PE device. For example, a PE can be subdivided into two 2 VRs running the OSPF routing protocol. Each VR will maintain a unique instance of the OSPF-MIB. Therefore, the ospfAreaTable of VR-A is distinct from the ospfAreaTable of VR-B. +-----------------------------------------------------------------+ | +------------------------------------------------------------+ | | | SNMP entity (including Engine, Applications) | | | | | | | | example contextNames: | | | | | | | | "vr01" "vr09" "admin" | | | | --------- --------- ------------ | | | | | | | | | | +------|------------------|-------------------|--------------+ | | | | | | | +------|------------------|-------------------|--------------+ | | | MIB | instrumentation | | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | context=vr01 | | context=vr09 | | context=admin | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | OSPF MIB | | | | OSPF MIB | | | | VR MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | BGP MIB | | | | BGP MIB | | | | ATM MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | IP MIB | | | | IP MIB | | | | ENTITY MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | other MIB | | | | other MIB | | | | IF MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | ... | | ... | | ... | | | +-----------------------------------------------------------------+ Layer-3 VPN Group Expires December 2005 [Page 4] Draft Virtual Router MIB June 2005 Filtering mechanisms based on the SNMP context of a particular virtual router may implemented to allow different management entities to manage those objects and services provisioned the 'Admin' context. 4.2 VR Indexing While the standard protocol MIB tables are instantiated in the context specified using SNMP contexts, there may be tables that are defined with the VRID as index. The VRID is of local significance to a particular PE device, and need not be globally unique. Thus a particular VRID value assigned to a VR in one PE device may indicate a different VR in another PE device. The VRID has an Unsigned32 value, and this value is assigned by the management station. To aid the management station in assigning a VRID without conflict, the management station can get the 'NextAvailableVRID' from the PE device. A SNMP manager SHOULD NOT assume global significance of any VRID value other than 0. For those MIB tables instantiated in the virtual router context, indexing can only be assumed unique for that particular VR. However those indices in the "ADMIN" context are unique across the entire system, including all VRs. 4.3 Creation and Deletion of VRs The VR Config Table is used for this purpose. This is a read-create table and adding an entry into this table will create a VR. Removing an entry from this table marks the deletion of a VR. VRID 0 is assigned to the Administrative VR, which exists by default, and need not be created. Deletion of the Administrative VR will not be permitted. The VRID of the Administrative VR (VRID 0) should be a reserved VRID number. VRID 0 could be termed the "null VR" and it could be the context that manages the resource pool of unattached interfaces. Routing would then not exist in the context of Administrative VR. 4.4 Administrative and Operational Status of VRs VRs can be administratively turned down. When this is done, no packet forwarding via the VR takes place. VrOperStatus denotes the operational status of a VR. Currently the VrOperStatus is expected to change along the VrAdminStatus unless an error condition exists. Layer-3 VPN Group Expires December 2005 [Page 5] Draft Virtual Router MIB June 2005 4.5 Binding interfaces to a VR Interfaces are bound to a VR, using vrIfConfigTable. This is a read-write table, and note that interfaces are not created through this table. The vrIfConfigTable MIB table is used to indicated the relationship between interfaces and virtual router IDs. For each interface present in the system, this table is used to provide the mapping from IfIndex to a unique VR. The table show which interfaces are ?attached or connected? to a virtual router. An interface can not be attached to more than one VR. The "Admin" VR could be used to manage the resource pool of unattached interfaces. However interfaces would not be attached to VRID 0. 4.6 Setting per VR limits VRs consume resources on a device, and hence the following parameters defined in vrConfigTable are used to specify an upper bound of resource utilization: VrMaxRoutes - Specify the maximum number of routes that will be permitted in VR. This includes all routes, such as the statically configured routes, and the routes learnt via dynamic routing protocols. 4.7 Per VR Statistics In addition to those statistics available through the VR instantiated MIB tables, there are some per-VR statistics available through vrStatTable. 4.8 Traps This memo defines that VrUp and VrDown traps are generated just after VrOperStatus leaves, or just before it enters, the down state, respectively. (1) A transition into the down state will occur when an error is detected on a VR instance. (2) Departing the down state generally indicates that the VR is going to up, which is considered a "healthy" state. An exception to the above generation of VrUp/VrDown traps on changes in VrOperStatus, occurs when an VR is "flapping", i.e., when it is rapidly oscillating between the up and down states. If traps were generated for each such oscillation, the network and the network management system would be flooded with unnecessary traps. In such a situation, the agent should limit the rate at which it generates traps. This memo defines that enabling and disabling the VR traps is achieved by setting the VrTrapEnable to true(1) or false(2), respectively. By default, this object should have the value true(1). Layer-3 VPN Group Expires December 2005 [Page 6] Draft Virtual Router MIB June 2005 4.9 Usability Considerations 4.9.1 Multiple Agents The MIB is based upon the premise that a single SNMP agent should represent every virtual router on a physical router. An alternative approach would be to deploy a separate SNMP agent for each virtual router. Creating multiple agents for use by the administrator (Service Provider) could be done, for instance by binding to different ports or addresses on the P-node. However from a resource perspective, it is more efficient to use a single agent and multiplex based on the community/context as described in this document. In either case, though, a VR-MIB is needed to map each VR to its respective agent or context. There could be a case where a separate agent per VR may be useful, though not as a replacement for the VR-MIB. If the platform supports instantiation of an agent *within* the VR then the VPN user could query stats, etc., from that agent. This would not be a replacement for the VR-MIB because (in addition to the above points) the SP may very well not have reachability/connectivity (not to mention uniqueness in addressing) into the VPN. For example, the Service Provider may not have management-network access to the customers' networks. 4.9.2 Provisioning vs. Monitoring The vr-mib goes to some length the support configuration using SNMP. Other MIBs tend to be for monitoring purposes, with an occasional read-write variable. There is value in having configuration capabilities in this MIB. The VR-MIB fills in a gap, allowing for creation of the VR, while the VR context MIBs allow for configuration of the VR itself. This might prove useful, perhaps even allowing for interoperable management tools. Some Service Provider may intend to use it only for monitoring. This is because there may be other mechanisms available to them for configuration of a specific platforms, such as Corba or XML interfaces that they may find more valuable for this function. 5.0 Sample VR MIB Configuration Scenario 5.1 Creation of a VR Creating VR instances can be achieved using the following example. (1) Get the next available Virtual Router Id using the NextAvailableVrId, to create a VR: Using a context with 'read' access for system level entities. GetRequest { NextAvailableVrId.0 } Response { NextAvailableVrId.0 = 5555 } (2) In VrConfigTable, create VR Instance using VrRowStatus: Using a context with 'read-write' access for system level entities SetRequest { VrRowStatus.5555 createAndGo(4), VrName.5555 "BigTelcoVR", VrContextName.5555 "vr5555", VrTrapEnable.5555 true(1), VrAdminStatus.5555 up(1) } 6.0 Definition of the Virtual Router MIB -- -- VIRTUAL-ROUTER-MIB -- VIRTUAL-ROUTER-MIB DEFINITIONS ::= BEGIN IMPORTS InterfaceIndex FROM IF-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- RFC Ed.: VPN-TC-MIB in Last Call in L3VPN WG VPNId FROM VPN-TC-MIB OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF experimental, Unsigned32, OBJECT-TYPE, MODULE-IDENTITY, TimeTicks, NOTIFICATION-TYPE FROM SNMPv2-SMI TruthValue, DisplayString, RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC; virtualRouterMIB MODULE-IDENTITY LAST-UPDATED "200506101200Z" ORGANIZATION "IETF L3VPN WG" CONTACT-INFO Layer-3 VPN Group Expires December 2005 [Page 7] Draft Virtual Router MIB June 2005 " Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 USA Phone: +1-408-519-3832 Email: elwinietf@yahoo.com Samuel Hancock ACM Systems 3034 Gold Canal Drive Rancho Cordova, CA 95670 USA Phone: +1-916-463-7949 Email: hancoc_s@yahoo.com Benson Schliesser SAVVIS Communications 1 Savvis Parkway Town and Country, MO 63017 USA Phone: +1-314-628-7036 Email: bensons@savvis.net Joseph Laria Level Stream Research Wilmington, MA 01887 USA Phone: +1-978-884-3537 Emain: jlaria@levelstream.com " DESCRIPTION "The MIB is the definition of the managed objects for the Virtual Router." REVISION "200506101200Z" -- 10 June 2005 12:00:00 GMT DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { experimental xxxx } -- To be assigned -- RFC Ed.: replace xxxx with IANA-assigned number & remove this note -- -- Textual conventions -- VrIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Virtual Router Identifier. Layer-3 VPN Group Expires December 2005 [Page 8] Draft Virtual Router MIB June 2005 VRID 0 is reserved for the Administrative VR and cannot be used to create VR's. " SYNTAX Unsigned32 -- -- Node definitions -- vrMIBObjects OBJECT IDENTIFIER ::= { virtualRouterMIB 1 } vrConfig OBJECT IDENTIFIER ::= { vrMIBObjects 1 } vrConfigScalars OBJECT IDENTIFIER ::= { vrConfig 1 } vrConfigNextAvailableVrId OBJECT-TYPE SYNTAX VrIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "The next available Virtual Router Id (index). This object provides a hint for the vrID value to use when administratively creating a new vrConfigEntry. A GET of this object returns the next available vrId value to be used to create an entry in the associated vrConfigTable; or zero, if no valid vrId value is available. A value of zero(0) indicates that it is not possible to create a new vrConfigEntry This object also returns a value of zero when it is the lexicographic successor of a varbind presented in an SNMP GETNEXT or GETBULK request, for which circumstance it is assumed that ifIndex allocation is unintended. Successive GETs will typically return different values, thus avoiding collisions among cooperating management clients seeking to create table entries simultaneously. Unless specified otherwise by its MAX-ACCESS and DESCRIPTION clauses, an object of this type is read-only, and a SET of such an object returns a notWritable error." ::= { vrConfigScalars 1 } vrConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF VrConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is for creating the new Virtual Routers." ::= { vrConfig 2 } Layer-3 VPN Group Expires December 2005 [Page 9] Draft Virtual Router MIB June 2005 vrConfigEntry OBJECT-TYPE SYNTAX VrConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries in this table can be added/deleted using the vrRowStatus." INDEX { vrId } ::= { vrConfigTable 1 } VrConfigEntry ::= SEQUENCE { vrId VrIdentifier, vrRowStatus RowStatus, vrName DisplayString, vrContextName DisplayString, vrTrapEnable TruthValue, vrMaxRoutes Unsigned32, vrAdminStatus INTEGER, vrVpnId VPNId, vrRpTrigger Unsigned32 } vrId OBJECT-TYPE SYNTAX VrIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique id of this virtual router instance. A Virtual Router cannot not be created with vrId = 0. VRID 0 is reserved for the Administrative VR. " ::= { vrConfigEntry 1 } vrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status column has three defined values: - `active', which indicates that the conceptual row is available for use by the managed device; Layer-3 VPN Group Expires December 2005 [Page 10] Draft Virtual Router MIB June 2005 - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row." ::= { vrConfigEntry 2 } vrName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The Name of the Virtual Router.. " ::= { vrConfigEntry 3 } vrContextName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The SNMPv2 Community String or SNMPv3 contextName denotes the VR 'context' and is used to logically separate the MIB management." ::= { vrConfigEntry 4 } vrTrapEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This objects is used to enable the generation of the VrUp and VrDown traps. true(1) - VR Traps Enabled false(2) - VR Traps Disabled" DEFVAL { true } ::= { vrConfigEntry 5 } vrMaxRoutes OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the maximum number of routes that this VR can support. The default value is 4 Gig (meaning unlimited)." DEFVAL { 4294967295 } ::= { vrConfigEntry 6 } Layer-3 VPN Group Expires December 2005 [Page 11] Draft Virtual Router MIB June 2005 vrAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), testing(3), unknown(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the Virtual Router." DEFVAL { down } ::= { vrConfigEntry 7 } vrVpnId OBJECT-TYPE SYNTAX VPNId MAX-ACCESS read-create STATUS current DESCRIPTION "The Virtual Private Network Identifier of the Virtual Router." ::= { vrConfigEntry 8 } vrRpTrigger OBJECT-TYPE SYNTAX BITS { RIP (1), OSPF(2), BGP (3), ISIS (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents Routing Protocol (RP) Triggers on a Virtual Router and it meant to be used to initiate or shutdown routing protocols on a VR. Multiple RPs can be acted on simultaneously. Also, individual RPs can be brought up in steps, which should not affect the RPs that were running. The BITS represent an Action-code that specifies what action is to be performed for the RPs. The actions are: initiate or shutdown. The running status of an RP shall be available in the VR stats table's vrRpStatus, which has a similar format, but represents the status. Bits 1-4 may be specified in any combination. Individual routing protocols may be enabled and disabled independently. Protocols are enabled by setting the respective BIT and are disabled by resetting the BIT. Bits 5-8 are reserved for future use. Layer-3 VPN Group Expires December 2005 [Page 12] Draft Virtual Router MIB June 2005 When encoding an object described using the BITS construct, the value is actually encoded as an OCTET STRING where bit 1 is the highest bit of the octet. So, for example, to enable RIP and BGP protocols the vrRpTrigger bits 1 and 3 need to be set, and as encoded as an octet string it would be 10100000" ::= { vrConfigEntry 9 } vrStat OBJECT IDENTIFIER ::= { vrMIBObjects 2 } vrStatScalars OBJECT IDENTIFIER ::= { vrStat 1 } vrConfiguredVRs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRs configured on this network element." ::= { vrStatScalars 1 } vrActiveVRs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRs that are active on the network element. These are VRs for which the vrStatOperationalStatus = up(1)" ::= { vrStatScalars 2 } vrStatTable OBJECT-TYPE SYNTAX SEQUENCE OF VrStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains statistics for the Virtual Router." ::= { vrStat 2 } vrStatEntry OBJECT-TYPE SYNTAX VrStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table a per vrId." INDEX { vrId } ::= { vrStatTable 1 } VrStatEntry ::= SEQUENCE { Layer-3 VPN Group Expires December 2005 [Page 13] Draft Virtual Router MIB June 2005 vrStatRouteEntries Unsigned32, vrStatFIBEntries Unsigned32, vrStatUpTime TimeTicks, vrOperStatus INTEGER, vrRpStatus Unsigned32, vrRouterAddressType InetAddressType, vrRouterAddress InetAddress } vrStatRouteEntries OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of routes for this VR." ::= { vrStatEntry 1 } vrStatFIBEntries OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of FIB Entries for this VR." ::= { vrStatEntry 2 } vrStatUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time in (in hundredths of a second) since this VR entry has been operational." ::= { vrStatEntry 3 } vrOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), unknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational state of the Virtual Router." ::= { vrStatEntry 4 } Layer-3 VPN Group Expires December 2005 [Page 14] Draft Virtual Router MIB June 2005 vrRpStatus OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "List of Routing Protocols on this VR." ::= { vrStatEntry 5 } vrRouterAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Router Address Type of this VR." ::= { vrStatEntry 6 } vrRouterAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Router Address of this VR. It is derived from one of the interfaces. If loopback interface is present, the loopback interface address can be used. However, loopback interface is optional." ::= { vrStatEntry 7 } vrIfConfig OBJECT IDENTIFIER ::= { vrMIBObjects 3 } vrIfConfigScalars OBJECT IDENTIFIER ::= { vrIfConfig 1 } vrIfConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF VrIfConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is for configuring VR Interfaces." ::= { vrIfConfig 2 } vrIfConfigEntry OBJECT-TYPE SYNTAX VrIfConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table correspond to the entries in the ifTable that apply to the Virtual Router." INDEX { vrId, vrIfId } ::= { vrIfConfigTable 1 } Layer-3 VPN Group Expires December 2005 [Page 15] Draft Virtual Router MIB June 2005 VrIfConfigEntry ::= SEQUENCE { vrIfId InterfaceIndex, vrIfConfigRowStatus RowStatus } vrIfId OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Virtual Router Interface Index." ::= { vrIfConfigEntry 1 } vrIfConfigRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION " This object is used to create, delete or modify a row in this table." ::= { vrIfConfigEntry 2 } -- ******************************************************************* -- Module Traps/Notifications -- ******************************************************************* vrNotificationsPrefix OBJECT IDENTIFIER ::= { vrMIBObjects 4 } vrNotifications OBJECT IDENTIFIER ::= { vrNotificationsPrefix 0 } vrUp NOTIFICATION-TYPE OBJECTS { vrRowStatus } STATUS current DESCRIPTION "This notification is generated when the specified VR is about to initialized or change the status from down to up." ::= { vrNotifications 1 } vrDown NOTIFICATION-TYPE OBJECTS { vrRowStatus } STATUS current DESCRIPTION "This notification is generated when the specified VR is about to go down." ::= { vrNotifications 2 } Layer-3 VPN Group Expires December 2005 [Page 16] Draft Virtual Router MIB June 2005 vrMaxRoutesExceeded NOTIFICATION-TYPE OBJECTS { vrRowStatus, vrMaxRoutes, vrStatRouteEntries } STATUS current DESCRIPTION "This notification is generated when the specified VR has exceeded the maximum number of routes specified" ::= { vrNotifications 3 } -- ******************************************************************* -- Module Compliance/Conformance Statements -- ******************************************************************* vrConformance OBJECT IDENTIFIER ::= { virtualRouterMIB 2 } vrCompliances OBJECT IDENTIFIER ::= { vrConformance 1 } vrMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the VIRTUAL-ROUTER-MIB. Implementation of this MIB is strongly recommended for any platform targeted for a carrier-class environment. When this MIB is implemented with support for read-create, then such an implementation can claim full compliance. Such devices can then be both monitored and configured with this MIB." MODULE -- this module MANDATORY-GROUPS { vrConfigGroup, vrStatGroup, vrIfGroup, vrNotificationGroup } ::= { vrCompliances 1 } vrGroups OBJECT IDENTIFIER ::= { vrConformance 2 } vrConfigGroup OBJECT-GROUP OBJECTS { vrRowStatus, vrName, vrContextName, vrTrapEnable, vrMaxRoutes, vrAdminStatus, vrVpnId, vrRpTrigger, vrConfigNextAvailableVrId } STATUS current DESCRIPTION "A collection of attributes that support provisioning of a virtual router." ::= { vrGroups 1 } vrStatGroup OBJECT-GROUP OBJECTS { vrConfiguredVRs, vrActiveVRs, vrStatRouteEntries, vrStatFIBEntries, vrStatUpTime, vrOperStatus, vrRpStatus, vrRouterAddress, vrRouterAddressType } STATUS current DESCRIPTION "A collection of attributes that contain stats about the virtual router." ::= { vrGroups 2 } Layer-3 VPN Group Expires December 2005 [Page 17] Draft Virtual Router MIB June 2005 vrIfGroup OBJECT-GROUP OBJECTS { vrIfConfigRowStatus } STATUS current DESCRIPTION "A collection of attributes that support provisioning of a virtual router interfaces." ::= { vrGroups 3 } vrNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { vrUp, vrDown, vrMaxRoutesExceeded } STATUS current DESCRIPTION "A collection of traps that are supported by the VR." ::= { vrGroups 4 } END 7.0 Acknowledgments Special thanks to Joan Cucchiara for providing valuable comments on this MIB. 8.0 Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: The Administrative VR provides visibility into and control over multiple VPNs. As such, security considerations for implementations of the Administrative VR and associated control plane(s) are critical to the security of the VPNs supported on each PE device. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Use of any vrContextName MUST be allowed in the Administrative VR. Additional authentication and security mechanisms SHOULD be used for SNMP access in the Administrative VR. Layer-3 VPN Group Expires December 2005 [Page 18] Draft Virtual Router MIB June 2005 VRs other than the Administrative VR MUST NOT have access to other VR's Instantiated MIBs, and MAY have access to their own instantiated MIBs. In VRs other than the Administrative VR, access to that VR's instantiated MIBs MAY be permitted via that VR's vrContextName. Use of any vrContextName other than that assigned to the accessed VR MUST result in an error, and implementations SHOULD provide a logging mechanism for such events. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9.0 References 9.1 Normative References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Layer-3 VPN Group Expires December 2005 [Page 19] Draft Virtual Router MIB June 2005 9.2 Informative References [RFC2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [VPNTCMIB] B. Schliesser, and T. Nadeau, "Definition of Textual Conventions for Provider Provisioned Virtual Private Network (PPVPN) Management.", Internet Draft , May 2004. [PPVPN-FW] R. Callon, et al., "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf-l3vpn-framework-00.txt, March 2003. [PPVPN-VR] P. Knight, et al., "Network based IP VPN Architecture using Virtual Routers", draft-ietf-l3vpn-vpn-vr-02.txt, April 2004. [PPVPN-VR-AS] A. Nagarajan, et al., "Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches", draft-ietf-l3vpn-as-vr-01.txt, March 2004. 10.0 Authors' Addresses Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 USA Phone: +1-408-519-3832 Email: elwinietf@yahoo.com Samuel Hancock ACM Systems 3034 Gold Canal Drive Rancho Cordova, CA 94123 USA Phone: +1-916-463-7949 Email: hancoc_s@yahoo.com Benson Schliesser SAVVIS Communications 1 Savvis Parkway Town and Country, MO 63017 USA Phone: +1-314-628-7036 Email: bensons@savvis.net Joseph Laria Level Stream Research Wilmington, MA 01887 USA Phone: +1-978-884-3537 Emain: jlaria@levelstream.com Layer-3 VPN Group Expires December 2005 [Page 20] Draft Virtual Router MIB June 2005 11.0 Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and and assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 12.0 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13.0 IANA Considerations for L3VPN-VR-MIB The IANA is requested to assign { experimental XXXX } to the L3VPN-VR-MIB module specified in this document. Layer-3 VPN Group Expires December 2005 [Page 21] --0-181447919-1118152749=:33761-- From l3vpn-bounces@ietf.org Wed Jun 08 17:44:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg8Le-0004fp-Hc; Wed, 08 Jun 2005 17:44:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg8LZ-0004ey-0z; Wed, 08 Jun 2005 17:44:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20049; Wed, 8 Jun 2005 17:44:22 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg8gQ-0002yr-2C; Wed, 08 Jun 2005 18:05:58 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Dg8Kp-0005L6-GA; Wed, 08 Jun 2005 17:43:39 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 08 Jun 2005 17:43:39 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: l3vpn@ietf.org Subject: Last Call: 'BGP-MPLS VPN extension for IPv6 VPN' to Proposed Standard X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org The IESG has received a request from the Layer 3 Virtual Private Networks WG to consider the following document: - 'BGP-MPLS VPN extension for IPv6 VPN ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-06-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-06.txt From l3vpn-bounces@ietf.org Fri Jun 17 15:51:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjMrq-0006fL-45; Fri, 17 Jun 2005 15:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjMrp-0006fD-2X for l3vpn@megatron.ietf.org; Fri, 17 Jun 2005 15:51:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17497 for ; Fri, 17 Jun 2005 15:51:01 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjNEw-0006T1-N6 for l3vpn@ietf.org; Fri, 17 Jun 2005 16:15:00 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j5HJop905427 for ; Fri, 17 Jun 2005 12:50:51 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.24.236.53]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j5HJojj88503 for ; Fri, 17 Jun 2005 12:50:45 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20050617154939.03787e60@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 17 Jun 2005 15:50:41 -0400 To: l3vpn@ietf.org From: Ross Callon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: Reminder: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org >From: ietf-secretariat@ietf.org >Date: Fri, 17 Jun 2005 00:00:02 -0400 > > >There are two (2) Internet-Draft cutoff dates for the 63rd >IETF Meeting in Paris, France: > >July 11th: Cutoff Date for Initial (i.e., version -00) >Internet-Draft Submissions > >All initial Internet-Drafts (version -00) must be submitted by Monday, >July 11th at 9:00 AM ET. As always, all initial submissions with a >filename beginning with "draft-ietf" must be approved by the >appropriate WG Chair before they can be processed or announced. The >Secretariat would appreciate receiving WG Chair approval by Tuesday, >July 5th at 9:00 AM ET. > >July 18th: Cutoff Date for Revised (i.e., version -01 and higher) >Internet-Draft Submissions > >All revised Internet-Drafts (version -01 and higher) must be submitted >by Monday, July 18th at 9:00 AM ET. > >Initial and revised Internet-Drafts received after their respective >cutoff dates will not be made available in the Internet-Drafts >directory or announced until on or after Monday, August 1st at 9:00 >AM ET, when Internet-Draft posting resumes. Please do not wait until >the last minute to submit. > >PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or >revised Internet-Draft after their respective cutoff deadlines, then >your document will be retained and posted when Internet-Draft >processing resumes. You will no longer be required to resubmit the >document. > >Thank you for your understanding and cooperation. If you have any >questions or concerns, then please send a message to >internet-drafts@ietf.org. > >The IETF Secretariat > >FYI: The Internet-Draft cutoff dates as well as other significant dates >for the 63rd IETF Meeting can be found at >http://www.ietf.org/meetings/cutoff_dates_63.html. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce From l3vpn-bounces@ietf.org Tue Jun 21 11:27:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkkfI-00032J-R2; Tue, 21 Jun 2005 11:27:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkkfG-000329-O2 for l3vpn@megatron.ietf.org; Tue, 21 Jun 2005 11:27:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00334 for ; Tue, 21 Jun 2005 11:27:48 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkl3B-0008SP-Fi for l3vpn@ietf.org; Tue, 21 Jun 2005 11:52:35 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 17:27:46 +0200 Received: from l-dhcp-5153-1.rd.francetelecom.fr ([10.193.15.66]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 17:27:46 +0200 From: Thomas Morin To: l3vpn@ietf.org Content-Type: multipart/alternative; boundary="=-C09cbFxCJBZQcAh3s4sb" Organization: France Telecom R&D CORE-CPN-MTM Date: Tue, 21 Jun 2005 17:27:46 +0200 Message-Id: <1119367666.14878.46.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-OriginalArrivalTime: 21 Jun 2005 15:27:46.0598 (UTC) FILETIME=[C6A68460:01C57675] X-Spam-Score: 0.9 (/) X-Scan-Signature: c8e71861e926d70c1bd2436e580ecf31 Subject: Multicast VPN Survey X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --=-C09cbFxCJBZQcAh3s4sb Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, As suggested last IETF in march, we are proposing a short survey about multicast VPN uses. The survey results would be used in draft-ietf-l3vpn-ppvpn-mcast-reqts, to express use cases and their corresponding requirements, especially in terms of scalability numbers. Here is the draft version of the survey that already was discussed on the multicast VPN requirements mailing list. We'd like to have the WG feedback about this document before proceeding (i.e before sending it to those who may answer it). Thank you for your feedback, -Thomas ------------------->8---------------------->8---------------------- ***************************************************************************** DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT FT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - ***************************************************************************** Multicast VPN Survey - 2005-06 1. Presentation 1.1 Context and goal Current work in the l3vpn IETF Working group include the definition of requirements for Multicast in L3 VPNs and specification of a multicast VPN solution. In this perspective, the authors of the requirement draft [draft-ietf-l3vpn-ppvpn-mcast-reqts] are initiating a survey to better express requirements, and especially scalability requirements. A summary of the results of this survey will be included in the requirements document which should serve as guidelines for solution design. The scope of this survey is multicast in L3VPNs: the mechanisms setup by a VPN provider to carry customer multicast traffic of customers. 1.2 Answering this survey This survey will hopefuly be answered by ISPs planing to offer a multicast VPN service, and possibly by VPN customers having a need for such a service (not all questions of this survey will be relevant in that later case). The answers should relate not to what you'd expect today, but more to what you see as a longer term target for such a service. For scalability figures, please answer what you think you may need/like to support in the longer term. Please answer as much questions as possible, but feel free to ommit answers if the question aren't relevant for you. If you expectd different kinds of significantly different deployments, it is better to answer the survey multiple times. 1.3 Sending the results Once completed, we'd appreciate that you send the document to . [or, depending on the degree of anonymization required...] Once completed, we'd appreciate that you send the document to , which will anonymize the survey result before forwarding them to the L3VPN WG multicast VPN requirement drafts authors. 2. Questions This survey is divided into three parts. The first one relates to quantitative questions that can be quickly answered by a simple figure (numbers of multicast PEs, of multicast VPNs,...), and the second one is made of qualitative questions regarding the expected use of the service (features, dynamicity, client application use case patterns...). In the last part you can express more in detail considerations you may have about multicast VPN deployments, including for instance specific use cases you think may highlight specific important points. 2.1 Quantitative questions Here, we are just expecting rough figures and orders of magnitude, such as: 20k, tens of thousands, hundreds, O(10^2), etc. 2.1.1 Deployment and offer 1. Number of VPNs for which multicast is made available * total: ....... * per PE: ....... * per AS, per provider : ...... (inter-AS or inter-provider context) 2. CEs per VPN per PE, for which multicast is enabled: .......... 3. number of PEs per VPN with multicast enabled (source or receiver): .......... 4. number of PEs with multicast service enabled: .......... 2.1.2 Parameters related to customer applications and usage patterns 1. Number of PEs connected to multicast receivers: .......... 2. Number of PEs connected to multicast sources: .......... 3. Number of multicast (*,G) or (S,G) sourced ... * ...per VPN: .......... * ...per PE: .......... * ...per CE: .......... 2.2 Qualitative questions 2.2.1 Expected VPN customer applications 1. Type of multicast applications Mutlicast applications deployed over a multicast VPN can be differentiated depending on many criterias, such as, for instance: real-time or not, bandwidth, receiver-source structure (one-to-many, many-to-many, many-to-few...), sensitivity to packet loss, number of streams... Please give examples of some possible application, in the form of eg.: o "real-time / few-to-many / tens of Mbps" o "non real time / multiple few-to-few streams / known sources, unknown receivers / hundreds of Mbps" a) ........ b) ........ c) ......... ... 2. Dynamics * Do you expect customer applications that are sensitive to multicast join/latency (time to receive/leave a stream) ? ........ * What kind of frequency do you expect for mcast routing changes, at the PE level ? (eg. "not more than XX leave and joins per hour") ........ * Predictability of sources and receivers locations: do you expect to be able, for each said multicast VPN customer, to have an a priori on the location of customer sources and/or receivers ? ........ 3. Customer side protocols: among the following, please chose which you'd expect to support at the CE-PE level (y/n) ? * PIM-SM: * PIM-SSM: * Bidir PIM: * IGMP(v2/v3): * MLDv2: * PIM-DM: 4. Would you plan to support multicast in a carrier's carrier context ? ........ 2.2.1 Network Considerations 1. Do you have PE for which reachability is less good than others (costly or scarce bandwidth) ? ........ 2. Do you think some VPNs of your customers may have same or close sets of PEs, and may thus possibly benefit from using the same PE-to-PE point to multipoint tunnels ? ........ 3. Do you plan to deploy multicast VPNs in a multi-AS context ? ........ 4. Do you plan to deploy multicast VPNs in a multi-provider context ? ........ 2.2.1 Relative Importance on different aspects Please rate the following items according to their relative importance - from 1 (Unimportant) to 5 (Important). * Seem-less interoperability with the current unicast model: ... * Multicast VPN must not impose additional requirements on CE devices: ... * Re-use of existing multicast protocols for multcast traffic transport over the provider core network: ... * Support of TE features such as bandwidth reservation and admission control: ... * Provide the same level of security for both the customer and the SP as available with unicast VPNs: ... * Support for global Internet multicast (emission/reception): ... * Support for Extranet (having a VRF in more than one multicast VPN): ... 3. Specific considerations you may want to express ........... Thank you very much ! --=-C09cbFxCJBZQcAh3s4sb Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

As suggested last IETF in march, we are proposing a short survey about mult= icast VPN uses.
The survey results would be used in draft-ietf-l3vpn-ppvpn-mcast-reqts, to = express use cases and their corresponding requirements, especially in terms= of scalability numbers.

Here is the draft version of the survey that already was discussed on the m= ulticast VPN requirements mailing list.
We'd like to have the WG feedback about this document before proceeding (i.= e before sending it to those who may answer it).

Thank you for your feedback,

-Thomas

------------------->8---------------------->8----------------------
***************************************************************************= **
DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRA= FT
FT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT = -
***************************************************************************= **

Multicast VPN Survey - 2005-06

  1. Presentation

      1.1 Context and goal

         Current work in the l3vpn = IETF Working group include the definition
         of requirements for Multic= ast in L3 VPNs and specification of a
         multicast VPN solution. In= this perspective, the authors of the
         requirement draft [draft-i= etf-l3vpn-ppvpn-mcast-reqts] are
         initiating a survey to bet= ter express requirements, and especially
         scalability requirements.<= BR>
         A summary of the results o= f this survey will be included in
         the requirements document = which should serve as guidelines for
         solution design.

         The scope of this survey i= s multicast in L3VPNs: the mechanisms
         setup by a VPN provider to= carry customer multicast traffic of
         customers.

      1.2 Answering this survey

         This survey will hopefuly = be answered by ISPs planing to offer
         a multicast VPN service, a= nd possibly by VPN customers having a
         need for such a service (n= ot all questions of this survey will
         be relevant in that later = case).

         The answers should relate = not to what you'd expect today,
         but more to what you see a= s a longer term target for such a
         service. For scalability f= igures, please answer what you think
         you may need/like to suppo= rt in the longer term.=0D
         Please answer as much ques= tions as possible, but feel free to
         ommit answers if the quest= ion aren't relevant for you.

         If you expectd different k= inds of significantly different
         deployments, it is better = to answer the survey multiple times.

      1.3 Sending the results

         Once completed, we'd appre= ciate that you send the document
         to <thomas.morin@rd.francetelecom.com>= .

[or, depending on the degree of anonymization required...]

         Once completed, we'd appre= ciate that you send the document
         to <x@x>, which will= anonymize the survey result before forwarding
         them to the L3VPN WG multi= cast VPN requirement drafts authors.

   2. Questions

     This survey is divided into three parts.

     The first one relates to quantitative questions th= at can be quickly
     answered by a simple figure (numbers of multicast = PEs, of multicast
     VPNs,...), and the second one is made of qualitati= ve questions
     regarding the expected use of the service (feature= s, dynamicity,
     client application use case patterns...).

     In the last part you can express more in detail co= nsiderations you
     may have about multicast VPN deployments, includin= g for instance
     specific use cases you think may highlight specifi= c important points.

      2.1 Quantitative questions

         Here, we are just expectin= g rough figures and orders of magnitude,
         such as: 20k, tens of thou= sands, hundreds, O(10^2), etc.

         2.1.1 Deployment and offer=

            1. Numbe= r of VPNs for which multicast is made available

            &nb= sp; * total:   .......

            &nb= sp; * per PE:  .......

            &nb= sp; * per AS, per provider : ......
            &nb= sp;  (inter-AS or inter-provider context)

            2. CEs p= er VPN per PE, for which multicast is enabled:

            ........= ..

            3. numbe= r of PEs per VPN with multicast enabled (source or
            receiver= ):

            ........= ..

            4. numbe= r of PEs with multicast service enabled:

            ........= ..

         2.1.2 Parameters related t= o customer applications and usage
         patterns

            1. Numbe= r of PEs connected to multicast receivers:

            ........= ..

            2. Numbe= r of PEs connected to multicast sources:

            ........= ..

            3. Numbe= r of multicast (*,G) or (S,G) sourced ...

            &nb= sp; * ...per VPN:  ..........

            &nb= sp; * ...per PE:   ..........

            &nb= sp; * ...per CE:   ..........

      2.2 Qualitative questions

         2.2.1 Expected VPN custome= r applications

            1. Type = of multicast applications

            &nb= sp;  Mutlicast applications deployed over a multicast VPN can
            &nb= sp;  be differentiated depending on many criterias, such as,
            &nb= sp;  for instance: real-time or not, bandwidth, receiver-source
            &nb= sp;  structure (one-to-many, many-to-many, many-to-few...),
            &nb= sp;  sensitivity to packet loss, number of streams...

            &nb= sp;  Please give examples of some possible application, in
            &nb= sp;  the form of eg.:

            &nb= sp;    o "real-time / few-to-many / tens of Mbps"<= BR>             &nb= sp;    o "non real time / multiple few-to-few streams /= known
            &nb= sp;       sources, unknown receivers / hundre= ds of Mbps"

            &nb= sp;  a) ........

            &nb= sp;  b) ........

            &nb= sp;  c) .........

            &nb= sp;  ...

            2. Dynam= ics

            &nb= sp; * Do you expect customer applications that are sensitive to
            &nb= sp;  multicast join/latency (time to receive/leave a stream) ?

            &nb= sp;  ........

            &nb= sp; * What kind of frequency do you expect for mcast routing
            &nb= sp;  changes, at the PE level ?  (eg. "not more than XX leav= e and
            &nb= sp;  joins per hour")

            &nb= sp;  ........

            &nb= sp; * Predictability of sources and receivers locations: do you
            &nb= sp;  expect to be able, for each said multicast VPN customer, to
            &nb= sp;  have an a priori on the location of customer sources and/or
            &nb= sp;  receivers ?

            &nb= sp;  ........

            3. Custo= mer side protocols: among the following, please
            chose wh= ich you'd expect to support at the CE-PE level (y/n) ?

            &nb= sp; * PIM-SM:
            &nb= sp; * PIM-SSM:
            &nb= sp; * Bidir PIM:
            &nb= sp; * IGMP(v2/v3):
            &nb= sp; * MLDv2:
            &nb= sp; * PIM-DM:

            4. Would= you plan to support multicast in a carrier's carrier
            context = ?

            ........=

        2.2.1 Network Considerations

            1. Do yo= u have PE for which reachability is less good than
            others (= costly or scarce bandwidth) ?

            ........=

            2. Do yo= u think some VPNs of your customers may have same
            or close= sets of PEs, and may thus possibly benefit from
            using th= e same PE-to-PE point to multipoint tunnels ?

            ........=

            3. Do yo= u plan to deploy multicast VPNs in a multi-AS
            context = ?

            ........=

            4. Do yo= u plan to deploy multicast VPNs in a multi-provider
            context = ?

            ........=

        2.2.1 Relative Importance on dif= ferent aspects

            Please r= ate the following items according to their relative
            importan= ce - from 1 (Unimportant) to 5 (Important).

            * Seem-l= ess interoperability with the current unicast model: ...

            * Multic= ast VPN must not impose additional
             re= quirements on CE devices: ...

            * Re-use= of existing multicast protocols for multcast traffic
            &nb= sp; transport over the provider core network: ...

            * Suppor= t of TE features such as bandwidth reservation and
            &nb= sp; admission control: ...

            * Provid= e the same level of security for both the customer and
             th= e SP as available with unicast VPNs: ...

            * Suppor= t for global Internet multicast (emission/reception): ...

            * Suppor= t for Extranet (having a VRF in more than one
            &nb= sp; multicast VPN): ...

   3. Specific considerations you may want to express

   ...........


Thank you very much !


--=-C09cbFxCJBZQcAh3s4sb-- From l3vpn-bounces@ietf.org Tue Jun 21 23:32:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkvyx-0004Pm-MK; Tue, 21 Jun 2005 23:32:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkvyw-0004PM-3R for l3vpn@megatron.ietf.org; Tue, 21 Jun 2005 23:32:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14956 for ; Tue, 21 Jun 2005 23:32:51 -0400 (EDT) Received: from [218.249.29.198] (helo=center.njtu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkwMy-00009d-P5 for l3vpn@ietf.org; Tue, 21 Jun 2005 23:57:45 -0400 Received: from zhanghk (remotehost [127.0.0.1]) by mail.student.njtu.edu.cn (ecMail) with ESMTP id 10DD318C065 for ; Wed, 22 Jun 2005 11:47:28 +0800 (CST) Date: Wed, 22 Jun 2005 11:34:02 +0800 From: "HKzhang@center.njtu.edu.cn" To: "l3vpn" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Message-Id: <20050622034728.10DD318C065@mail.student.njtu.edu.cn> X-Spam-Score: 1.1 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: base64 Subject: Re:draft-zhang-l3vpn-vr-multicast-00 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org SGksIGV2ZXJ5b25lDQpXZSBzZW50IHRoZSBkcmFmdC16aGFuZy1sM3Zwbi12ci1tdWx0aWNhc3Qt MDAgdmVyc2lvbiB0byBMM1ZQTiBncm91cCBzZXZlcmFsIHdlZWtzIGFnbywgYnV0IG5vIHJlc3Bv bnNlcyB3YXMgcmVjZWl2ZWQuDQpXaHk/IENvdWxkIHlvdSBwbGVhc2Ugc2VlIGl0IGFuZCBnaXZl IHNvbWUgY29tbWVudCBhYm91dCBpdD8gDQoNCqGhoaGhoaGhoaGhoaGhoaFIS3poYW5nDQqhoaGh oaGhoaGhoaGhoaGhSEt6aGFuZ0BjZW50ZXIubmp0dS5lZHUuY24NCqGhoaGhoaGhoaGhoaGhoaGh oaGhMjAwNS0wNi0yMg0K From l3vpn-bounces@ietf.org Wed Jun 22 05:30:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl1Yj-0007mE-Jl; Wed, 22 Jun 2005 05:30:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl1Yi-0007m6-08; Wed, 22 Jun 2005 05:30:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17586; Wed, 22 Jun 2005 05:30:09 -0400 (EDT) Received: from [218.249.29.198] (helo=center.njtu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl1wb-0000il-DY; Wed, 22 Jun 2005 05:55:06 -0400 Received: from zhanghk (remotehost [127.0.0.1]) by mail.student.njtu.edu.cn (ecMail) with ESMTP id 845CF18C16D; Wed, 22 Jun 2005 17:44:31 +0800 (CST) Date: Wed, 22 Jun 2005 17:31:04 +0800 From: "HKzhang@center.njtu.edu.cn" To: "pim" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon680547021541_=====" Message-Id: <20050622094431.845CF18C16D@mail.student.njtu.edu.cn> X-Spam-Score: 1.1 (+) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 Cc: l3vpn , pusateri , mcbride Subject: Re:draft-zhang-l3vpn-vr-mcast-00.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org This is a multi-part message in MIME format. --=====001_Dragon680547021541_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 ICANCkhpLCBldmVyeW9uZQ0KIEkgYW0gSG9uZy1LZSBaaGFuZyBhbmQgZ2xhZCB0byBjb250cmli dXRlIGEgZHJhZnQgZm9yIHRoaXMgZ3JvdXAuIA0KIFNvbWUgZHJhZnRzIGhhdmUgYmVlbiBwcm9w b3NlZCBiYXNlZCBvbiB0aGUgYXBwcm9hY2ggb2YgQkdQL01QTFMgVlBOIHRvIHByb3ZpZGUgbXVs dGljYXN0IHNlcnZlLiBIZXJlIHdlIHByb3Bvc2UgYSBkcmFmdCBmb3IgbXVsdGljYXN0IGJhc2Vk IG9uIFZSIFZQTi4NCiBJbiBvdXIgZHJhZnQsIGl0IHNob3VsZCBiZSBubyBwcm9ibGVtIHRvIGRl cGxveSB0aGUgbXVsdGljYXN0IHByb3RvY29sIHN1Y2ggYXMgUElNLVNNIG9yIFBJTS1TU00gaW4g VlIuDQogVGhlIGlkZWEgb2Ygb3VyIGFwcHJvYWNoIGlzIHRvIGNvbXBsZXRlIG11bHRpY2FzdCBz ZXJ2aWNlIGluIFZQTiBuZXR3b3JrIGJhc2VkIG9uIFBJTS1ETS4gDQogSSBob3BlIHlvdSBjYW4g Y29uc2lkZXIgb3VyIGRyYWZ0IGFuZCBnaXZlIHlvdXIgY29tbWVudCBmb3IgaXQuDQoNCiBCZXN0 IHJlZ2FyZHMgd2l0aCBtYW55IHRoYW5rcyANCiBIb25nLUtlIFpoYW5nIA0KDQoNCqGhoaGhoaGh oaGhoaGhoaFIS3poYW5nDQqhoaGhoaGhoaGhoaGhoaGhSEt6aGFuZ0BjZW50ZXIubmp0dS5lZHUu Y24NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNS0wNi0yMg0K --=====001_Dragon680547021541_===== Content-Type: application/octet-stream; name="draft-zhang-l3vpn-vr-mcast-00.txt" Content-Disposition: attachment; filename="draft-zhang-l3vpn-vr-mcast-00.txt" Content-Transfer-Encoding: base64 DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSG9u Zy1LZSBaaGFuZw0KRG9jdW1lbnQ6IGRyYWZ0LXpoYW5nLWwzdnBuLXZyLW1jYXN0LTAwLnR4dCAg ICAgICBDaHVuLVl1ZSBaaG91DQpFeHBpcmF0aW9uIERhdGU6IE5vdmVtYmVyIDIwMDUgICAgICAg ICAgICAgICAgICAgIEJpbmctWWkgWmhhbmcgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQmVpamluZyBKaWFvdG9uZyBVbml2ZXJzaXR5DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVuLUh1aSBMaXUNCiAgICAgICAgICAg IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuLCBSJkQgQmVpamluZyBpbnN0aXR1dGUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMDUN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K DQogICAgICAgICAgIE11bHRpY2FzdCBpbiBWaXJ0dWFsIFJvdXRlci1iYXNlZCBJUCBWUE5zIA0K DQogICAgICAgICAgICAgICAgIGRyYWZ0LXpoYW5nLWwzdnBuLXZyLW1jYXN0LTAwLnR4dA0KDQoN Cg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVy bmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQNCiAgIGFueSBhcHBsaWNhYmxl IHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcw0KICAgYXdh cmUgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9y IHNoZQ0KICAgYmVjb21lcyBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3 aXRoIFNlY3Rpb24gNiBvZg0KICAgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdv cmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3Jj ZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0IG90 aGVyDQogICBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJ bnRlcm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVk LCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRp bWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVu Y2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHBy b2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJl IGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnLzFpZC1hYnN0cmFjdHMuaHRtbA0K DQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJl IGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQoNCg0K QWJzdHJhY3QgDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBwcm9jZWR1cmVzIHJl cXVpcmVkIHRvIGltcGxlbWVudCANCiAgDQpIb25nLUtlIFpoYW5nLCBldCBhbC4gICAgICAgRXhw aXJlcyBOb3ZlbWJlciAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMV0NCg0KDQpJbnRlcm5ldCBE cmFmdCAgICBNdWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAgVlBOcyAgICAgTWF5 IDIwMDUNCg0KbXVsdGljYXN0IGZvciBhbiBJUCBtdWx0aWNhc3QgVlBOIGJhc2VkIG9uIFZpcnR1 YWwgUm91dGVycy4gSXQgDQogICBkZXRhaWxzIHRoZSBzb2x1dGlvbiBhY2NvcmRpbmcgdG8gcHJv Y2VzcyBpbiBsb2NhbCBjdXN0b21lciBzaXRlcywNCiAgIG1ldGhvZCBvZiBlc3RhYmxpc2hpbmcg bXVsdGljYXN0IGRpc3RyaWJ1dGlvbiB0cmVlcyBpbiBTUCBuZXR3b3Jrcw0KICAgYW5kIGZvcndh cmRpbmcgZmxvdyBvZiBtdWx0aWNhc3QgZGF0YSBwYWNrZXRzLiBUaGlzIGRvY3VtZW50IGlzIA0K ICAgYmFzZWQgb24gcHJpb3IgcmVxdWlyZW1lbnRzIGZvciBNdWx0aWNhc3QgaW4gTDMgUHJvdmlk ZXItUHJvdmlzaW9uZWQNCiAgIFZQTnMgW01SRVFUXSBhbmQgc3BlY2lmaWNhdGlvbiBvZiBuZXR3 b3JrIGJhc2VkIElQIFZQTiBBcmNoaXRlY3R1cmUgDQogICB1c2luZyBWaXJ0dWFsIFJvdXRlcnMg W1ZSLVZQTl0gdGhhdCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgYW5kIA0KICAgZGVwbG95ZWQuDQoN CkNvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudA0KDQogICBUaGUga2V5IHdvcmRzICJN VVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAi U0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFuZCAiT1BUSU9O QUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmli ZWQgaW4gUkZDLTIxMTkgW0tFWVdPUkRTXS4NCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAg MSAgICAgIEludHJvZHVjdGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjINCiAgICAyICAgICAgVGVybWlub2xvZ3kgLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyAgDQogICAgMyAgICAgIFZSIGRlcGxveW1lbnQg c2NlbmFyaW8gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQNCiAgICA0ICAg ICAgQXV0by1kaXNjb3ZlcnkgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uNQ0KICAgIDUgICAgICBQcm9jZWR1cmVzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICAgNS4xICAgIEVuY2Fwc3VsYXRpb24gLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgICA1LjEuMSAgRW5j YXBzdWxhdGlvbiBpbiBHUkUgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u NQ0KICAgIDUuMS4yICBFbmNhcHN1bGF0aW9uIGluIElQIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi42DQogICAgNS4xLjMgIEVuY2Fwc3VsYXRpb24gaW4gTVBMUyAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCiAgICA1LjEuNCAgSW50ZXJvcGVy YWJpbGl0eSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KICAg IDUuMiAgICBNdWx0aWNhc3Qgc291cmNlIHJvdXRpbmcgdGFibGUgLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi43DQogICAgNS4zICAgIFJvdXRpbmcgaW4gdGhlIFZQTiBzaXRlcyAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDcNCiAgICA1LjQgICAgUm91dGluZyBpbiB0aGUg U1AgTmV0d29yayAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gOA0KICAgIDUuNSAg ICBNdWx0aWNhc3QgVlBOIERhdGEgRm9yd2FyZGluZyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi44DQogICAgNiAgICAgIHNjYWxhYmlsaXR5IENvbnNpZGVyYXRpb25zIC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjkNCiAgICA3ICAgICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOQ0KICAgIDggICAgICBBY2tu b3dsZWRnbWVudHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEw DQogICAgOSAgICAgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMTANCiAgICAxMCAgICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KICAgIDExICAgICBBdXRob3JzIEFk ZHJlc3MgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwDQogICAg MTIgICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQgLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTENCg0KDQoNCjEuIEludHJvZHVjdGlvbg0KDQpIb25nLUtlIFpoYW5nLCBldCBh bC4gICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMl0NCg0K DQpJbnRlcm5ldCBEcmFmdCAgICBNdWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAg VlBOcyAgICAgTWF5IDIwMDUNCg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgcHJv Y2VkdXJlcyByZXF1aXJlZCB0byBpbXBsZW1lbnQgDQogICBtdWx0aWNhc3QgZm9yIGFuIElQIG11 bHRpY2FzdCBWUE4gYmFzZWQgb24gVmlydHVhbCBSb3V0ZXJzLiBJdCANCiAgIGRldGFpbHMgdGhl IHNvbHV0aW9uIGFjY29yZGluZyB0byBwcm9jZXNzIGluIGxvY2FsIHNpdGVzLCBtZXRob2Qgb2Yg DQogICBlc3RhYmxpc2hpbmcgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiB0cmVlcyBpbiBTUCBuZXR3 b3JrcyBhbmQgDQogICBmb3J3YXJkaW5nIGZsb3cgb2YgbXVsdGljYXN0IGRhdGEgcGFja2V0cy4g SXQgaXMgYmFzZWQgb24gcHJpb3IgDQogICByZXF1aXJlbWVudHMgZm9yIE11bHRpY2FzdCBpbiBM MyBQcm92aWRlci1Qcm92aXNpb25lZCBWUE5zW01SRVFUXSBhbmQgDQogICBzcGVjaWZpY2F0aW9u cyBvZiBuZXR3b3JrIGJhc2VkIElQIFZQTiBBcmNoaXRlY3R1cmUgdXNpbmcgVmlydHVhbCANCiAg IFJvdXRlcnNbVlItVlBOXSB0aGF0IGhhdmUgYmVlbiBpbXBsZW1lbnRlZCBhbmQgZGVwbG95ZWQu IEl0IA0KICAgZXN0YWJsaXNoZXMgcmV2ZXJzZSBzaG9ydGVzdCBwYXRoIHRyZWVzIGluIFNQIG5l dHdvcmssIHRob3NlIFZScyB0aGF0DQogICBoYXZlIG11bHRpY2FzdCByZXF1aXJlbWVudHMgYWN0 IGFzIHRoZSB0cmVlJ3MgbGVhZiBub2RlcyBhbmQgam9pbiAgDQogICBtdWx0aWNhc3QgZ3JvdXBz IGR5bmFtaWNhbGx5LiBUaGlzIHNvbHV0aW9uIGlzIGEgdHJhZGVvZmYgYmV0d2VlbiANCiAgIHNj YWxhYmlsaXR5IGFuZCBmbGV4aWJpbGl0eSBvZiByb3V0ZXIgb3B0aW1pemF0aW9uLCB3aGljaCBl bnN1cmVzDQogICBiYW5kd2lkdGggcmVzb3VyY2UgdXRpbGl6YXRpb24uDQoNCjIuIFRlcm1pbm9s b2d5DQoNCiAgIEhlcmUgd2UgcHJvcG9zZSBzb21lIGdlbmVyYWwgdGVybXMgZm9yIGNvbmNlcHQg dGhhdCBhcHBlYXIgaW4gdGhlIA0KICAgbXVsdGljYXN0IHNvbHV0aW9uIG9mIFZpcnR1YWwgUm91 dGVyLWJhc2VkIElQIFZQTnMuIA0KICAgIA0KICAgUGxlYXNlIHJlZmVyIHRvIHRoZSBbUFBWUE4t VEVSTV0gZG9jdW1lbnQgZm9yIGRldGFpbHMgYWJvdXQgDQogICB0ZXJtaW5vbG9neSBzcGVjaWZp Y2FsbHkgcmVsZXZhbnQgdG8gVlBOIGFzcGVjdHMuICAgIA0KDQogICBJbiBhZGRpdGlvbiB0byB0 aGUgdGVybWlub2xvZ3kgdXNlZCBpbiBbTVJFUVRdLCB0aGlzIGRvY3VtZW50IA0KICAgaW50cm9k dWNlcyB0aGUgZm9sbG93aW5nIHRlcm1zOg0KDQoNCiAgIC0gR1JFOiBHZW5lcmljIFJvdXRlIEVu Y2Fwc3VsYXRpb24sIHdoaWNoIHNwZWNpZmllcyBhIHByb3RvY29sIGZvciANCiAgICAgICAgICBl bmNhcHN1bGF0aW9uIG9mIGFuIGFyYml0cmFyeSBuZXR3b3JrIGxheWVyIHByb3RvY29sIG92ZXIg DQogICAgICAgICAgYW5vdGhlciBhcmJpdHJhcnkgbmV0d29yayBsYXllciBwcm90b2NvbC4NCg0K ICAgLSBQRSA6IFByb3ZpZGVyIEVkZ2UNCg0KICAgLSBDRSA6IEN1c3RvbWVyIEVkZ2UNCg0KICAg LSBTUCA6IFNlcnZpY2UgUHJvdmlkZXINCg0KICAgLSBQSU06IFByb3RvY29sIEluZGVwZW5kZW50 IE11bHRpY2FzdA0KDQogICAtIFJQOiAgUmVuZGV6dm91cyBQb2ludCwgd2hpY2ggaXMgYSBzaGFy ZWQgcm9vdCBmb3IgZXZlcnkgbXVsdGljYXN0IA0KICAgICAgICAgIGdyb3VwLCBzb3VyY2VzIG9u IHRoZSBzYW1lIGdyb3VwIHNlbmQgdGhlaXIgdHJhZmZpYyB0byB0aGUgUlANCiAgICAgICAgICBh bmQgdGhlbiBmb3J3YXJkZWQgdG8gcmVjZWl2ZXJzIGRvd24gYSBzaGFyZWQgZGlzdHJpYnV0aW9u IA0KICAgICAgICAgIHRyZWUuDQoNCkhvbmctS2UgWmhhbmcsIGV0IGFsLiAgICAgICBFeHBpcmVz IE5vdmVtYmVyIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAzXQ0KIA0KDQpJbnRlcm5ldCBEcmFm dCAgICBNdWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAgVlBOcyAgICAgTWF5IDIw MDUNCg0KDQogICAtIEcgOiAgZGVub3RlcyBhIG11bHRpY2FzdCBncm91cC4gICANCiANCiAgIC0g UyA6ICBkZW5vdGVzIGEgbXVsdGljYXN0IHNvdXJjZS4gDQoNCiAgIC0gUC1Hcm91cDogYSBncm91 cCBhZGRyZXNzIGluIHRoZSBTUCdzIGFkZHJlc3Mgc3BhY2UuDQoNCiAgIC0gQy1Hcm91cDogYSBn cm91cCBhZGRyZXNzIGluIGEgVlBOJ3MgYWRkcmVzcyBzcGFjZS4NCg0KDQoNCjMuIFZSIGRlcGxv eW1lbnQgc2NlbmFyaW8NCg0KICAgT24gVlItVlBOIG5ldHdvcmssIFZQTiBjdXN0b21lciBzaXRl cyBhY2Nlc3MgdG8gc2VydmljZSBwcm92aWRlciANCiAgIGJhY2tib25lIHZpYSB0aGUgY29ubmVj dGlvbiBiZXR3ZWVuIEN1c3RvbWVyIEVkZ2UoQ0UpIGVxdWlwbWVudCBhbmQgDQogICBWUi4gQ0Ug Y2FuIGNvbm5lY3QgdG8gVlIgdmlhIGFueSBhY2Nlc3MgbGluaywgdGhlbiBmb3J3YXJkIGFsbCBu b24tDQogICBsb2NhbCBzZXJ2aWNlIHRvIFZSLiBWUnMgYmVsb25naW5nIHRvIHRoZSBzYW1lIFZQ TiBkb21haW4gbXVzdCANCiAgIGRpc2NvdmVyIFZQTiBtZW1iZXJzaGlwIGFuZCBkaXN0cmlidXRl IHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbi4gVlJzIA0KICAgb25seSBtYWludGFpbiByb3V0ZSBz dGF0ZSBvZiBWUE4gdGhleSBiZWxvbmcgdG8uIFRoZXJlIGNhbiBleGlzdCANCiAgIG11bHRpcGxl IFZScyBvbiBvbmUgUHJvdmlkZXIgRWRnZShQRSkgZXF1aXBtZW50Lg0KDQogICBUaHJlZSBtYWlu IFZSIGRlcGxveW1lbnQgc2NlbmFyaW9zIGNhbiBiZSB1c2VkIGZvciBidWlsZGluZyB2aXJ0dWFs IA0KICAgcHJpdmF0ZSBuZXR3b3JrcyBhcyBkZXNjcmliZWQgaW4gW1ZSLVZQTl06DQoNCg0KICAg ICAgMSkgVlIgdG8gVlIgY29ubmVjdGl2aXR5IG92ZXIgYSBsYXllciAyIGNvbm5lY3Rpb247DQog ICAgICAyKSBWUiB0byBWUiBjb25uZWN0aXZpdHkgdHVubmVsZWQgb3ZlciBhbiBJUCBvciBNUExT IG5ldHdvcms7DQogICAgICAzKSBBZ2dyZWdhdGluZyBtdWx0aXBsZSB2aXJ0dWFsIHJvdXRlcnMg b3ZlciBhIGJhY2tib25lIHZpcnR1YWwgDQogICByb3V0ZXIuIA0KDQogICBUaGUgYWJvdmUgVlIg ZGVwbG95bWVudCBzY2VuYXJpb3MgY2FuIGNvZXhpc3Qgb24gYSBzaW5nbGUgUEUgYW5kIHRoZXkN CiAgIGFyZSBub3QgbXV0dWFsbHkgZXhjbHVzaXZlLiAgDQoNCiAgIEZvciBtdWx0aWNhc3QgcmVh bGl6YXRpb24sIHRoZSB2aXJ0dWFsIHJvdXRlciBoYXMgZXhhY3RseSB0aGUgc2FtZSANCiAgIG1l Y2hhbmlzbXMgYXMgYSBwaHlzaWNhbCByb3V0ZXIgZW50aXJlbHkuIEFsbCBleGlzdGluZyByb3V0 aW5nIA0KICAgcHJvdG9jb2xzIGNhbiBiZSB1c2VkIHVubW9kaWZpZWQgb24gVlIsIGJldHdlZW4g VlJzIG9yIGJldHdlZW4gVlIgYW5kDQogICBDRS4gTW9yZW92ZXIsIG11bHRpY2FzdCB0cmFmZmlj IGNhbiBiZSBmb3J3YXJkZWQgdGhyb3VnaCBJUCBvciBNUExTIA0KICAgYmFzZWQgdHVubmVscy4g IA0KICAgDQogICBUaGlzIHNvbHV0aW9uIGZpdHMgZm9yIHRob3NlIFNQIG5ldHdvcmsgd2l0aG91 dCBiYWNrYm9uZSBWUiBvciBkbyBub3QNCiAgIG5lZWQgdG8gY29uc2lkZXIgZWZmZWN0IG9mIGJh Y2tib25lIFZSLg0KDQoNCg0KSG9uZy1LZSBaaGFuZywgZXQgYWwuICAgICAgIEV4cGlyZXMgTm92 ZW1iZXIgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDRdDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAg TXVsdGljYXN0IGluIFZpcnR1YWwgUm91dGVyLWJhc2VkIElQIFZQTnMgICAgIE1heSAyMDA1DQoN CjQuIEF1dG8tRGlzY292ZXJ5DQoNCg0KICBUaGUgZmlyc3Qgc3RlcCB0byByZWFsaXplIFZQTiBt dWx0aWNhc3QgaXMgQXV0by1EaXNjb3Zlcnkgb2YgVlBOIA0KICBtZW1iZXJzaGlwLCB2YWxpZGF0 aW9uIGFuZCBkaXN0cmlidXRpb24gb2YgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uLg0KICBJdCBp cyByZXF1aXJlZCB0byBzZWxlY3QgYXBwcm9wcmlhdGUgUEUgZm9yIGN1c3RvbWVyIHNpdGVzLCBk aXN0cmlidXRlDQogIGlkZW50aWZpZXIgZm9yIFZQTiwgY29uZmlndXJlIFZSIG9uIGNvcnJlbGF0 aXZlIFBFLCBtYWtlIHRoZSBWUiBiZSANCiAgbWVtYmVyIG9mIFZQTiBjb25uZWN0ZWQsIGFuZCBo YW5kbGUgdGhlIGluZm9ybWF0aW9uIG9mIHRoYXQuIFRoZSANCiAgbWVjaGFuaXNtIHRvIGRpc3Ry aWJ1dGUgbWVtYmVyc2hpcCwgdG9wb2xvZ3ksIGFuZCB0dW5uZWwgaW5mb3JtYXRpb24gDQogIGFt b25nIFZScyB3aGljaCBhcmUgbWVtYmVycyBvZiB0aGUgc2FtZSBWUE4gaXMgdGhlIHNhbWUgYXMg dW5pY2FzdA0KICBbVlItVlBOXS4gIkF1dG8tZGlzY292ZXJ5IiBjYW4gYmUgYWNoaWV2ZWQgdGhy b3VnaCBleHBsaWNpdA0KICBjb25maWd1cmF0aW9uLCBkaXJlY3Rvcnkgc2VydmVyIGFwcHJvYWNo LCBwaWdneWJhY2tpbmcgaW5mb3JtYXRpb24gDQogIHVzaW5nIGV4dGVuZGVkIEJHUCBwcm90b2Nv bHMgb3Igb3RoZXIgYXBwcm9hY2hlcy4NCg0KDQo1LiBQcm9jZWR1cmVzDQoNCjUuMSBFbmNhcHN1 bGF0aW9uDQoNCiAgIFRoaXMgc29sdXRpb24gdXNlcyB0aGUgc2FtZSBlbmNhcHN1bGF0aW9uIG1l dGhvZHMgYXMgW01WUE4tN10uIFRoZXNlIA0KICAgYXBwbHkgYWxzbyB0byB0aGUgTVBMUy1pbi1J UCBhbmQgTVBMUy1pbi1HUkUgZW5jYXBzdWxhdGlvbnMuDQoNCjUuMS4xIEVuY2Fwc3VsYXRpb24g aW4gR1JFDQoNCiAgIEdSRSBlbmNhcHN1bGF0aW9uIGNhbiBiZSB1c2VkIHdoZW4gZm9yd2FyZGlu ZyBtdWx0aWNhc3QgdHJhZmZpYyANCiAgIHRocm91Z2ggU1AgbmV0d29yay4gVGhlIElQIFByb3Rv Y29sIE51bWJlciBmaWVsZCBpbiB0aGUgUC1JUCBIZWFkZXIgDQogICBhbmQgdGhlIFByb3RvY29s IFR5cGUgZmllbGQgb2YgdGhlIEdSRSBIZWFkZXIgbXVzdCBmb2xsb3cgIFtNVlBOLTddLg0KICAg VGhlIGZvbGxvd2luZyBkaWFncmFtIHNob3dzIHRoZSBwcm9ncmVzc2lvbiBvZiB0aGUgcGFja2V0 IGFzIGl0IA0KICAgZW50ZXJzIGFuZCBsZWF2ZXMgdGhlIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29y ay4NCg0KICAgUGFja2V0cyByZWNlaXZlZCAgICAgICAgUGFja2V0cyBpbiB0cmFuc2l0ICAgICAg UGFja2V0cyBmb3J3YXJkZWQNCiAgIGF0IGluZ3Jlc3MgUEUgICAgICAgICAgIGluIHRoZSBzZXJ2 aWNlICAgICAgICAgIGJ5IGVncmVzcyBQRXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHBy b3ZpZGVyIG5ldHdvcmsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFAtSVAgSGVhZGVyICB8DQogICAg ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgIEdSRSAgICAgIHwNCiAgICsrPT09PT09PT09PT09PSsrICAgICAg ICsrPT09PT09PT09PT09PSsrICAgICAgICsrPT09PT09PT09PT09PSsrDQogICB8fCBDLUlQIEhl YWRlciB8fCAgICAgICB8fCBDLUlQIEhlYWRlciB8fCAgICAgICB8fCBDLUlQIEhlYWRlciB8fA0K ICAgKys9PT09PT09PT09PT09KysgPj4+Pj4gKys9PT09PT09PT09PT09KysgPj4+Pj4gKys9PT09 PT09PT09PT09KysNCiAgIHx8IEMtUGF5bG9hZCAgIHx8ICAgICAgIHx8IEMtUGF5bG9hZCAgIHx8 ICAgICAgIHx8IEMtUGF5bG9hZCAgIHx8DQogICArKz09PT09PT09PT09PT0rKyAgICAgICArKz09 PT09PT09PT09PT0rKyAgICAgICArKz09PT09PT09PT09PT0rKw0KDQpIb25nLUtlIFpoYW5nLCBl dCBhbC4gICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgNV0N Cg0KDQpJbnRlcm5ldCBEcmFmdCAgICBNdWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQg SVAgVlBOcyAgICAgTWF5IDIwMDUNCg0KNS4xLjIgRW5jYXBzdWxhdGlvbiBpbiBJUA0KDQogICBJ UC1pbi1JUCBlbmNhcHN1bGF0aW9uIGNhbiBhbHNvIGJlIHVzZWQuIFRoZSBwYXJhbWV0ZXIgYWJv dXQgSVAgDQogICBQcm90b2NvbCBOdW1iZXIgZmllbGQgZm9sbG93cyBbTVZQTi03XS4gVGhlIGZv bGxvd2luZyBkaWFncmFtIHNob3dzDQogICB0aGUgcHJvZ3Jlc3Npb24gb2YgdGhlIHBhY2tldCBh cyBpdCBlbnRlcnMgYW5kIGxlYXZlcyB0aGUgc2VydmljZQ0KICAgcHJvdmlkZXIgbmV0d29yay4N Cg0KICAgUGFja2V0cyByZWNlaXZlZCAgICAgICAgUGFja2V0cyBpbiB0cmFuc2l0ICAgICAgUGFj a2V0cyBmb3J3YXJkZWQNCiAgIGF0IGluZ3Jlc3MgUEUgICAgICAgICAgIGluIHRoZSBzZXJ2aWNl ICAgICAgICAgIGJ5IGVncmVzcyBQRXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb3Zp ZGVyIG5ldHdvcmsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFAtSVAgSGVhZGVyICB8DQogICArKz09 PT09PT09PT09PT0rKyAgICAgICArKz09PT09PT09PT09PT0rKyAgICAgICArKz09PT09PT09PT09 PT0rKw0KICAgfHwgQy1JUCBIZWFkZXIgfHwgICAgICAgfHwgQy1JUCBIZWFkZXIgfHwgICAgICAg fHwgQy1JUCBIZWFkZXIgfHwNCiAgICsrPT09PT09PT09PT09PSsrID4+Pj4+ICsrPT09PT09PT09 PT09PSsrID4+Pj4+ICsrPT09PT09PT09PT09PSsrDQogICB8fCBDLVBheWxvYWQgICB8fCAgICAg ICB8fCBDLVBheWxvYWQgICB8fCAgICAgICB8fCBDLVBheWxvYWQgICB8fA0KICAgKys9PT09PT09 PT09PT09KysgICAgICAgKys9PT09PT09PT09PT09KysgICAgICAgKys9PT09PT09PT09PT09KysN Cg0KDQo1LjEuMyBFbmNhcHN1bGF0aW9uIGluIE1QTFMNCg0KICAgSWYgdGhlIFAgcm91dGVzIG9u IFNQIG5ldHdvcmsgc3VwcG9ydCBNUExTIGFuZCBleHRlbmRlZCBSU1ZQIA0KICAgcHJvdG9jb2ws IE1QTFMgZW5jYXBzdWxhdGlvbiBjYW4gYmUgdXNlZC4gVGhlIG11bHRpY2FzdCBkaXN0cmlidXRp b24NCiAgIHRyZWVzIGNhbiBiZSBjb25zdHJ1Y3RlZCBieSBQMk1QIE1QTFMgTFNQIG1lY2hhbmlz bSwgYW5kIGFkZGl0aW9uYWwgDQogICBNUExTIGVuY2Fwc3VsYXRpb24gcHJvY2VkdXJlcyBhcmUg dXNlZCwgYXMgc3BlY2lmaWVkIGluIA0KICAgW1JTVlAtVEUtUDJNUF0uDQoNCiAgIFBhY2tldHMg cmVjZWl2ZWQgICAgICAgIFBhY2tldHMgaW4gdHJhbnNpdCAgICAgIFBhY2tldHMgZm9yd2FyZGVk DQogICAgYXQgaW5ncmVzcyBQRSAgICAgICAgICAgaW4gdGhlIHNlcnZpY2UgICAgICAgICAgYnkg ZWdyZXNzIFBFcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb3ZpZGVyIG5ldHdvcmsN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgUC1NUExTIEhlYWRlciB8DQogICArKz09PT09PT09PT09PT0r KyAgICAgICArKz09PT09PT09PT09PT0rKyAgICAgICArKz09PT09PT09PT09PT0rKw0KICAgfHwg Qy1JUCBIZWFkZXIgfHwgICAgICAgfHwgQy1JUCBIZWFkZXIgfHwgICAgICAgfHwgQy1JUCBIZWFk ZXIgfHwNCiAgICsrPT09PT09PT09PT09PSsrID4+Pj4+ICsrPT09PT09PT09PT09PSsrID4+Pj4+ ICsrPT09PT09PT09PT09PSsrDQogICB8fCBDLVBheWxvYWQgICB8fCAgICAgICB8fCBDLVBheWxv YWQgICB8fCAgICAgICB8fCBDLVBheWxvYWQgICB8fA0KICAgKys9PT09PT09PT09PT09KysgICAg ICAgKys9PT09PT09PT09PT09KysgICAgICAgKys9PT09PT09PT09PT09KysNCg0KNS4xLjQgSW50 ZXJvcGVyYWJpbGl0eQ0KDQogICBJbiBWUi1WUE4gbmV0d29yaywgZXZlcnkgVmlydHVhbCBSb3V0 ZXIgaW4gUEUgbXVzdCBhZ3JlZSBvbiB0aGUgDQogIA0KSG9uZy1LZSBaaGFuZywgZXQgYWwuICAg ICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDZdDQoNCiAgDQpJ bnRlcm5ldCBEcmFmdCAgICBNdWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAgVlBO cyAgICAgTWF5IDIwMDUNCg0KICAgbWV0aG9kIG9mIGVuY2Fwc3VsYXRpb24gbWVudGlvbmVkIGFi b3ZlLiBJdCBjYW4gYmUgaW1wbGVtZW50ZWQNCiAgIGVpdGhlciBieSBjb25maWd1cmF0aW9uIG9y IG1lYW5zIG9mIHNvbWUgZGlzY292ZXJ5IHByb3RvY29scy4gDQogICBIZXJlLCBHUkUgZW5jYXBz dWxhdGlvbiBpcyBzdWdnZXN0ZWQgdG8gYmUgdXNlZCBkdWUgdG8gaXRzIHNpbXBsZSANCiAgIGFu ZCBsb3dlciBwYXlsb2FkLg0KDQoNCjUuMiBNdWx0aWNhc3Qgc291cmNlIHJvdXRpbmcgdGFibGUN Cg0KICAgQWNjb3JkaW5nIHRvIGZvcndhcmQgbW9kZWwgb2YgVlItVlBOLCBldmVyeSBWUiBzaG91 bGQgc3RvcmUgYSANCiAgIG11bHRpY2FzdCBzb3VyY2Ugcm91dGluZyB0YWJsZSBjb25zdHJ1Y3Rl ZCBieSByZWFjaGFiaWxpdHkgDQogICBpbmZvcm1hdGlvbiBkaXN0cmlidXRlZCBieSBWUnMgdGhy b3VnaCBkaWZmZXJlbnQgbWVjaGFuaXNtcyBzdWNoIA0KICAgYXMgc3RhdGljIHJvdXRpbmcsIHRy YWRpdGlvbmFsIHVuaWNhc3Qgcm91dGluZyBvciBtdWx0aWNhc3QgDQogICBwcm90b2NvbC4gVGhp cyB0YWJsZSByZWNvcmRzIHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiBvZiBldmVyeSANCiAgIG11 bHRpY2FzdCBzb3VyY2UgUyB3aGljaCB0aGUgVlIgaXMgaW50ZXJlc3RlZCBpbiBhbmQgdGhlIHJl bGF0aXZlIA0KICAgVlIsIHRoYXQgaXMgKFMsIFZSKS4gDQoNCg0KNS4zIFJvdXRpbmcgaW4gdGhl IFZQTiBzaXRlcyANCg0KICAgSXQgaXMgbmVjZXNzYXJ5IHRvIGRlcGxveSBsb2NhbCBtdWx0aWNh c3Qgcm91dGluZyBwcm90b2NvbHMgaW4gdGhlIA0KICAgVlBOIHNpdGVzLiBDb25zaWRlcmluZyB0 aGUgc3VwZXJpb3JpdHkgYW5kIGdlbmVyYWxpdHkgb2YgUElNIA0KICAgcHJvdG9jb2wsIGNlcnRh aW4gUElNIChQSU0tU00sIEJpZGlyZWN0aW9uYWwgUElNLCBvciBQSU0tU1NNKSBhcmUgDQogICBz dWdnZXN0ZWQuIFRoZXJlIGlzIGFuIGltcG9ydGFudCBjaGFyYWN0ZXJpc3RpYyBpbiBWUiBWUE5z IHRoYXQgZWFjaCANCiAgIFZSIGJlY29tZXMgYSBQSU0gYWRqYWNlbmN5IG9mIHRoZSBDRSByb3V0 ZXIgY29ubmVjdGVkLCBidXQgQ0Ugcm91dGVycw0KICAgYXQgZGlmZmVyZW50IHNpdGVzIGRvIG5v dCBiZWNvbWUgUElNIGFkamFjZW5jaWVzIG9mIGVhY2ggb3RoZXIsIGFuZCANCiAgIFZScyBpbiB0 aGUgc2FtZSBQRSBkbyBub3QgaGF2ZSBQSU0gYWRqYWNlbmNpZXMgdG8gZWFjaCBvdGhlciwgZWl0 aGVyLg0KDQogICBJbiB0aGlzIHNvbHV0aW9uLCBhbGwgVlJzIGNvbm5lY3RpbmcgdG8gVlBOIHNp dGVzIGFyZSBkZXBsb3llZCBhcyANCiAgIHByb3h5IFNvdXJjZS9SUHMgZm9yIHRoYXQgVlBOIHNp dGUuIFRoaXMgcHJveHkgU291cmNlL1JQIGNvbm5lY3QgdG8gDQogICB0aGUgbXVsdGljYXN0IHNv dXJjZSBpbiB0aGUgVlBOIGRpcmVjdGx5IG9yIHZpYSBhIENFIHJvdXRlci4gU2luY2UgDQogICBl YWNoIFZSIGFjdHMgYXMgYSBwcm94eS1Tb3VyY2UvUlAgb2YgaXRzIFZQTiwgaXQgY2FuIGZvcm0g YW4gDQogICBpbmRlcGVuZGVudCBtdWx0aWNhc3QgdHJlZSB3aXRoaW4gdGhlIGN1c3RvbWVyIHNp dGUgcmVnYXJkbGVzcyBvZiANCiAgIG11bHRpY2FzdCB0cmVlIGZvcm1hdGlvbnMgaW4gb3RoZXIg c2l0ZXMuIA0KDQogICBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIFNQLCBQcm94eSBTb3VyY2Uv UlAgaXMgdGhlIGRlcHV0YXRpb24gb2YgDQogICBsb2NhbCBWUE4gc2l0ZSAuIE9uIHRoZSBvdGhl ciBoYW5kLCBpdCBpcyB0aGUgUlAgb2YgYWxsIG11bHRpY2FzdA0KICAgdHJlZXMgaW4gbG9jYWwg VlBOIHNpdGUgZnJvbSB0aGUgc3RhbmRwb2ludCBvZiBWUE4gc2l0ZSwgYWxsIHJvdXRlIA0KICAg c3RhdGVzIHN1Y2ggYXMgKEMtU291cmNlLEMtR3JvdXApIGFuZCAoKixDLUdyb3VwKSBhc3NlbWJs ZSB0byBSUCB2aWENCiAgIFBJTSBKb2luL1BydW5lIG1lc3NhZ2VzLiBIZXJlIGEgUC1ncm91cCBh ZGRyZXNzIHdvdWxkIGJlIGEgZ3JvdXAgDQogICBhZGRyZXNzIGluIHRoZSBTUCdzIGFkZHJlc3Mg c3BhY2UsIGFuZCBhIEMtZ3JvdXAgYWRkcmVzcyB3b3VsZCBiZSANCiAgIGEgZ3JvdXAgYWRkcmVz cyBpbiBhIFZQTidzIGFkZHJlc3Mgc3BhY2UuDQoNCiAgIEZyb20gdGhlIHBvaW50IG9mIHZpZXcg b2YgY3VzdG9tZXIgVlBOIHNpdGVzLCBWUiBtdXN0IGJlIHRoZSBlZ3Jlc3MgDQogICANCkhvbmct S2UgWmhhbmcsIGV0IGFsLiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDUgICAgICAgICAgICAg ICBbUGFnZSA3XQ0KDQoNCkludGVybmV0IERyYWZ0ICAgIE11bHRpY2FzdCBpbiBWaXJ0dWFsIFJv dXRlci1iYXNlZCBJUCBWUE5zICAgICBNYXkgMjAwNQ0KDQogICBvZiBhbGwgdHJhZmZpYy4gQWN0 aW5nIGFzIFJQIG1lYW5zIHRoYXQgbXVsdGljYXN0IHNvdXJjZXMgaW4gdGhlIFZQTg0KICAgc2l0 ZXMgbXVzdCByZWdpc3RlciB0byBWUiwgdGhlbiBmb3J3YXJkIG11bHRpY2FzdCBwYWNrZXRzIHRv IHJlbW90ZSANCiAgIHNpdGVzLiBJdCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGRpcmVjdGlvbiBv ZiBsb2NhbCBzaXRlcycgdHJhZmZpYy4gDQoNCg0KNS40ICAgIFJvdXRpbmcgaW4gdGhlIFNQIE5l dHdvcmsNCg0KICAgRmlyc3QgdGhlcmUgaXMgYSBkZWZpbml0aW9uIG9mIHRoYXQgU291cmNlLVZS IGlzIGEgVlIgY29ubmVjdGVkIHRvIA0KICAgYSBjdXN0b21lciBWUE4gc2l0ZSB3aGljaCBoYXMg bXVsdGljYXN0IHNvdXJjZSB0cmFmZmljLiBBY2NvcmRpbmcgdG8gDQogICBWUE4gbWVtYmVyc2hp cCBhbmQgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uLCBpdCBjYW4gY29uc3RydWN0IGEgDQogICBT aG9ydGVzdCBQYXRoIFRyZWUgcm9vdGVkIGF0IGV2ZXJ5IFNvdXJjZS1WUiBhbmQgYWRkcmVzc2Vk IG9uIFAtR3JvdXANCiAgIGluIHRoZSBTUCdzIGFkZHJlc3Mgc3BhY2UuIFRoZSBzaG9ydGVzdCBw YXRoIHRyZWUgKFNvdXJjZS1WUiwgDQogICBQLUdyb3VwKSBjYW4gYmUgc2V0dXAgdXNpbmcgUElN LURNIG9yIE1QTFMgUDJNUCB0dW5uZWwuICBBbGwgdHJhZmZpYw0KICAgZnJvbSBWUnMgc2hhcmUg dGhlIHRyZWUgKFNvdXJjZS1WUiAsUC1Hcm91cCkuDQoNCiAgIFdoZW4gdGhlcmUgaXMgYSBTb3Vy Y2UtVlIgYWN0aW5nIGFzIGEgcHJveHktUlAgb2YgY3VzdG9tZXIgc2l0ZSB0bw0KICAgcmVjZWl2 ZSBtdWx0aWNhc3QgcGFja2V0cyBmcm9tIGxvY2FsIGN1c3RvbWVyIHNpdGUsIGl0IGVuY2Fwc3Vs YXRlcyANCiAgIHRoZSBwYWNrZXRzIGluIEdSRSBvciBpbiBJUCwgdGhlIHRyYWZmaWMgd2lsbCBi cm9hZGNhc3QgdG8gYWxsIFZScyANCiAgIGFjdGluZyBhcyBsZWFmIG5vZGVzIGluIHRoZSBzYW1l IFZQTiBhbG9uZyB0aGUgU2hvcnRlc3QgUGF0aCBUcmVlLg0KDQoNCg0KNS41ICAgIE11bHRpY2Fz dCBWUE4gRGF0YSBGb3J3YXJkaW5nDQoNCiAgIEFmdGVyIFZScyBhY3RpbmcgYXMgbGVhZiBub2Rl cyBoYXZlIHJlY2VpdmVkIHRoZSBmaXJzdCBwYWNrZXQgZnJvbSANCiAgIFNvdXJjZS1WUiwgdGhl eSBleHRyYWN0IGJhc2ljIGluZm9ybWF0aW9uIGluIGVuY2Fwc3VsYXRlZCBwYWNrZXRzLCANCiAg IHRoYXQgaXMgVlIgYW5kIFAtR3JvdXAsIHRoZW4gZGVjaWRlIHdoZXRoZXIgaXQgaGFzIG11bHRp Y2FzdCANCiAgIHJlcXVpcmVtZW50IGZyb20gVlJzLiBJZiB0aGVyZSBpcyBubyByZWNlaXZlciBp bnRlcmVzdGVkIGluIHRoaXMNCiAgIFZSLCBpdCBkaXNjYXJkcyBtdWx0aWNhc3QgcGFja2V0cyBh bmQgcHJ1bmVzIGZyb20gbXVsdGljYXN0IHRyZWUgDQogICAoU291cmNlLVZSLCBQLUdyb3VwKSB0 byByZWplY3QgdHJhZmZpYyBmcm9tIHRoaXMgVlIuIFRob3NlIGxlYWYgVlJzIA0KICAgd2hpY2gg aGF2ZSBiZWVuIHBydW5lZCBmcm9tIHRyZWVzIHdpbGwgc3RvcmUgc3RhdGUgaW5mb3JtYXRpb24g b2YgDQogICAoU291cmNlLVZSICxQLUdyb3VwKS4gQXMgc29vbiBhcyBsb2NhbCBzaXRlIGhhcyBy ZXF1aXJlbWVudHMgb2YgYW55IA0KICAgQy1Tb3VyY2UgaW4gVlBOIHNpdGUgd2hpY2ggdGhpcyBW UiBjb25uZWN0aW5nIHRvLCB0aGUgcHJ1bmVkIGxlYWYgDQogICBub2RlcyBzaG91bGQgZXhwbGlj aXRseSBqb2luIHRoZSB0cmVlIGFnYWluLCB0aGVuIHJlY2VpdmUgbXVsdGljYXN0IA0KICAgcGFj a2V0cyBmcm9tIHRoaXMgVlIuIEV2ZXJ5IFZSIGFjdGluZyBhcyBsZWFmIG5vZGVzIHJlcGVhdHMg dGhlc2UgDQogICBvcGVyYXRpb25zLCB0aHVzIG11bHRpY2FzdCBwYWNrZXRzIGZyb20gU291cmNl LVZSIGhhdmUgYmVlbiBmb3J3YXJkZWQNCiAgIG9ubHkgdG8gdGhvc2UgVlJzIHdoaWNoIGhhdmUg cmVxdWlyZW1lbnRzIG9mIG11bHRpY2FzdCBzb3VyY2UuIEV2ZXJ5DQogICBWUiBjYW4gYmUgc291 cmNlIChyb290KSBvciByZWNlaXZlciAobGVhZiksIGRpZmZlcmVudCB0cmVlcyBhcmUgDQogICBp ZGVudGlmaWVkIGJ5IChTb3VyY2UtVlIsIFAtR3JvdXApLg0KDQogICBXaGVuIGEgY2VydGFpbiBs ZWFmIFZSIGhhcyBuZXcgbXVsdGljYXN0IHJlcXVpcmVtZW50cyB0byBtdWx0aWNhc3QNCiAgIHNv dXJjZSBTLCBpdCBjaGVja3MgdGhlIG11bHRpY2FzdCBzb3VyY2Ugcm91dGluZyB0YWJsZSB0byBn ZXQgdGhlIA0KICAgcmVsYXRpb24gYmV0d2VlbiBTIGFuZCBTb3VyY2UtVlIuIElmIHRoZSBsZWFm IFZSIGhhcyBiZWVuIG9uIHRoZSB0cmVlDQogIA0KSG9uZy1LZSBaaGFuZywgZXQgYWwuICAgICAg IEV4cGlyZXMgTm92ZW1iZXIgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDhdDQoNCg0KICANCklu dGVybmV0IERyYWZ0ICAgIE11bHRpY2FzdCBpbiBWaXJ0dWFsIFJvdXRlci1iYXNlZCBJUCBWUE5z ICAgICBNYXkgMjAwNQ0KDQogIChTb3VyY2UtVlIsIFAtR3JvdXApLCBpdCBjb250aW51ZXMgcmVj ZWl2aW5nIHBhY2tldHMgZnJvbSBTb3VyY2UtVlIgDQogICB3aXRob3V0IGV4dHJhIHByb2Nlc3Np bmcuIElmIHRoaXMgbGVhZiBWUiBoYXMgcHJ1bmVkIGl0c2VsZiBmcm9tIHRoZSANCiAgIHRyZWUg cm9vdGVkIG9uIFNvdXJjZS1WUiwgaXQgc2VuZHMgam9pbiBtZXNzYWdlIHRvIHRoZSB0cmVlLCB0 aGVuIA0KICAgYmVnaW5zIHRvIHJlY2VpdmUgZW5jYXBzdWxhdGVkIHBhY2tldHMgZnJvbSBTb3Vy Y2UtVlIuDQoNCg0KICAgQWZ0ZXIgcmVjZWl2aW5nIHBhY2tldHMsIFZSIGRlY2Fwc3VsYXRlcyBh bmQgcmVjb3ZlcnMgbXVsdGljYXN0IA0KICAgcGFja2V0cywgdGhlbiBmb3J3YXJkcyB0aGVtIHRv IGxvY2FsIHJlY2VpdmVycyBvciBkaXNjYXJkcyB0aGVtIA0KICAgYWNjb3JkaW5nIHRvIGxvY2Fs IG11bHRpY2FzdCBmb3J3YXJkaW5nIHRhYmxlLiANCg0KDQogICBGcm9tIHRoZSBhYm92ZS1tZW50 aW9uZWQsIGVhY2ggcHJvY2VzcyBvZiBtdWx0aWNhc3QgdHJlZXMgYW5kIA0KICAgbXVsdGljYXN0 IHBhY2tldHMgaXMgYmFzZWQgb24gcmVxdWlyZW1lbnRzIG9mIHNvdXJjZSAobG9jYWwgQy1Tb3Vy Y2UNCiAgIG9mIFZScyApIGZyb20gbGVhZiBWUnMsIHdoaWxlIGluZGVwZW5kZW50IG9mIEMtR3Jv dXAuIE9ubHkgd2hlbiBhbGwgDQogICB0cmFmZmljIGZyb20gU291cmNlLVZSIGhhdmUgcmVhY2hl ZCB0byBsZWFmIFZScyB3aGljaCBoYXZlIA0KICAgcmVxdWlyZW1lbnRzIHRocm91Z2ggbXVsdGlj YXN0IHRyZWVzLCBkbyBsZWFmIFZScyBkZWNpZGUgd2hldGhlciB0bw0KICAgZGlzY2FyZCBvciBm b3J3YXJkIG11bHRpY2FzdCBwYWNrZXRzIGFjY29yZGluZyB0byBsb2NhbCBzdGF0ZSANCiAgIChD LVNvdXJjZSxDLUdyb3VwKS4NCg0KDQoNCjYuIFNjYWxhYmlsaXR5IFNvbHV0aW9uDQoNCiAgIFNj YWxhYmlsaXR5IGlzIGEga2V5IHJlcXVpcmVtZW50IGZvciBtdWx0aWNhc3QgVlBOIHNvbHV0aW9u cy4gDQogICBHZW5lcmFsbHksIGVmZmljaWVudCBtdWx0aWNhc3Qgcm91dGluZyBhbmQgc2NhbGFi aWxpdHkgYXJlIGNvbXBldGluZw0KICAgZ29hbHMuIFRoZSBTUCBoYXMgbm8gY29udHJvbCBvbiB0 aGUgbnVtYmVyIG9mIG11bHRpY2FzdCBncm91cHMgaW4gdGhlDQogICBWUE5zIGFuZCBhbW91bnQg b2Ygc3RhdGVzIGluIHRoZSByb3V0ZXMuIEluIHRoaXMgc29sdXRpb24sIE11bHRpY2FzdCANCiAg IHRyZWVzIGluIFNQIG5ldHdvcmsgYXJlIGFsbCBTaG9ydGVzdCBQYXRoIHRyZWVzLiBUaGUgbnVt YmVyIG9mIHRyZWVzIA0KICAgcm9vdGVkIG9uIFZScyBpcyByZWxhdGl2ZWx5IHN0YXRpYy4gVGhl IGdyb3VwIGFkZHJlc3MgY2FuIGJlIA0KICAgY29uZmlndXJlZCBieSBhZG1pbmlzdHJhdG9yIG9y IGF1dG8tc2VsZWN0aW9uIGluIGNlcnRhaW4gcmFuZ2UgYW5kIA0KICAgdGhlIGFkZHJlc3MgY2Fu IGJlIHRoZSBzYW1lIGZvciBkaWZmZXJlbnQgc291cmNlIFZScy4gVGh1cyBudW1iZXIgb2YgDQog ICB0cmVlcyBvbiBTUCBuZXR3b3JrIHdpbGwgbmVpdGhlciBleGNlZWQgdG90YWwgb2YgVlJzIG5v ciBjaGFuZ2Ugd2l0aCANCiAgIHRoZSBudW1iZXIgb2YgY3VzdG9tZXJzLCB0aGUgbnVtYmVyIG9m IGNsaWVudCBtdWx0aWNhc3QgY2hhbm5lbHMgYW5kIA0KICAgdmFyeWluZyBvZiB0b3BvbG9neS4g U28gaXQgbm90IG9ubHkgcmVkdWNlcyBwYXlsb2FkIG9uIFNQIG5ldHdvcmsgDQogICBlZmZlY3Rp dmVseSBidXQgYWxzbyBpbXByb3ZlcyBzY2FsYWJpbGl0eS4gDQoNCg0KNy4gU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMNCiANCiAgIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRpc2N1c3NlZCBpbiBb VlItVlBOXSBhcHBseSB0byB0aGlzIGRvY3VtZW50Lg0KICAgRnJvbSBhIHJvdXRlIGRlcGxveW1l bnQgc3RhbmRwb2ludCwgdGhlIGlzb2xhdGlvbiBkZWdyZWUgYmV0d2VlbiANCiAgIGRpZmZlcmVu dCBWUE5zIGlzIGNydWNpYWwgdG8gYSBncmVhdCBleHRlbnQuIEluIHRoaXMgc29sdXRpb24sIA0K ICAgDQpIb25nLUtlIFpoYW5nLCBldCBhbC4gICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA1ICAg ICAgICAgICAgICAgW1BhZ2UgOV0NCg0KDQpJbnRlcm5ldCBEcmFmdCAgICBNdWx0aWNhc3QgaW4g VmlydHVhbCBSb3V0ZXItYmFzZWQgSVAgVlBOcyAgICAgTWF5IDIwMDUNCg0KICAgcHJvY2Vzc2lu ZyBpbiBTUCBuZXR3b3JrIHdpbGwgYmUgaW1wbGVtZW50ZWQgaW4gdGhvc2UgVlJzIGJlbG9uZ2lu ZyANCiAgIHRvIHRoZSBzYW1lIFZQTi4gSXQgY2FuIGdldCBnb29kIGlzb2xhdGlvbiBwZXJmb3Jt YW5jZSBiZWNhdXNlIGV2ZXJ5DQogICBWUE4gaGFzIHByaXZhdGUgbXVsdGljYXN0IGFkZHJlc3Mg c3BhY2UuIElmIG9ubHkgdGhlIHdob2xlIHN5c3RlbSANCiAgIGlzb2xhdGVzIFZScyBpbiB0aGUg c2FtZSBQRSByZWxpYWJseSwgdGhlIHNlY3VyaXR5IHdpbGwgcmVhY2ggYSANCiAgIHByZWZlcmFi bGUgbGV2ZWwuIA0KDQoNCjguIEFja25vd2xlZGdtZW50DQoNCiAgIFdlIHdvdWxkIGxpa2UgdG8g dGhhbmsgUXVhbi1MaW4gTGksRW4tSHVpIExpdSwgWXVlIFpoYW5nLCBTaHVhaSBHYW8gYW5kIA0K ICAgWWEtanVhbiBRaW4gZm9yIHRoZWlyIHZhbHVhYmxlIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9u IG9uIHRoaXMgZG9jdW1lbnQuDQogICANCg0KOS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMNCiAgIFtQ UFZQTi1URVJNXSAgIlByb3ZpZGVyIFByb3Zpc2lvbmVkIFZQTiB0ZXJtaW5vbG9neSIsIEwuIEFu ZGVyc3NvbywgDQogICAgICAgICAgICAgICBULiBNYWRzZW4sIFNlcHRlbWJlciAyMDA0LCANCiAg ICAgICAgICAgICAgIGRyYWZ0LWlldGYtbDN2cG4tcHB2cG4tdGVybWlub2xvZ3ktMDQNCiAgIA0K MTAuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCiAgIFtNUkVRVF0gICAgIlJlcXVpcmVtZW50cyBm b3IgTXVsdGljYXN0IGluIEwzIFByb3ZpZGVyLVByb3Zpc2lvbmVkDQogICAgICAgICAgICAgIFZQ TnMiLCBULiBNb3JpbiwgRWQuICxGcmFuY2UgVGVsZWNvbSBSJkQsIEZlYnJ1YXJ5IDIwMDUsDQog ICAgICAgICAgICAgIGRyYWZ0LWlldGYtbDN2cG4tcHB2cG4tbWNhc3QtcmVxdHMtMDAudHh0DQog ICBbVlItVlBOXSAgICJOZXR3b3JrIGJhc2VkIElQIFZQTiBBcmNoaXRlY3R1cmUgdXNpbmcgVmly dHVhbCBSb3V0ZXJzIiwgDQogICAgICAgICAgICAgIFBhdWwgS25pZ2h0LCBIYW1pZCBPdWxkLUJy YWhpbSwgQnJ5YW4gR2xlZXNvbiwgDQogICAgICAgICAgICAgIEFwcmlsIDIwMDQsIGRyYWZ0LWll dGYtbDN2cG4tdnBuLXZyLTAyLnR4dCANCiAgIFtNVlBOLTddICAgIk11bHRpY2FzdCBpbiBNUExT L0JHUCBWUE5zIiwgRS4gUm9zZW4uIGV0LiBhbC4sDQogICAgICAgICAgICAgIGRyYWZ0LXJvc2Vu LXZwbi1tY2FzdC0wNy50eHQNCg0KMTEuQXV0aG9yIEluZm9ybWF0aW9uDQoNCiAgIEhvbmctS2Ug WmhhbmcNCiAgIElQIGxhYg0KICAgQmVpamluZyBKaWFvVG9uZyBVbml2Lg0KICAgQ2hpbmEsIDEw MDA0NA0KICAgRW1haWw6IGhremhhbmdAY2VudGVyLm5qdHUuZWR1LmNuDQoNCiAgIENodW4tWXVl IFpob3UsIEJpbmctWWkgWmhhbmcNCiAgIElQIGxhYg0KICAgQmVpamluZyBKaWFvVG9uZyBVbml2 Lg0KICAgQ2hpbmEsIDEwMDA0NA0KICAgQ2h1bi1ZdWUgWmhvdTogemhvdWNodW55dWVAaG90bWFp bC5jb20NCiAgIEJpbmctWWkgWmhhbmc6IGJpbmd5aXpoYW5nQGhvdG1haWwuY29tDQoNCkhvbmct a2UgWmhhbmcsIGV0IGFsLiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDUgICAgICAgICAgICAg IFtQYWdlIDEwXQ0KDQoNCkludGVybmV0IERyYWZ0ICAgIE11bHRpY2FzdCBpbiBWaXJ0dWFsIFJv dXRlci1iYXNlZCBJUCBWUE5zICAgICBNYXkgMjAwNQ0KDQoxMi4gSW50ZWxsZWN0dWFsIFByb3Bl cnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcg dGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJp Z2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWlu IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVk IGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2Ug dW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5v ciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQg ZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0 aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2Fu IGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBk aXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3Vy YW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2Yg YW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlz c2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVt ZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVk IGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkg dG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3Ig cGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0 IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0K ICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUg SUVURiBhdCBpZXRmLQ0KICAgaXByQGlldGYub3JnLg0KDQoNCg0KDQpGdWxsIENvcHlyaWdodCBO b3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuICBU aGlzIGRvY3VtZW50IGlzIA0KICAgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQg cmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1ANCiAgIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBm b3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyDQogICByaWdodHMuDQoN CiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFy ZSBwcm92aWRlZA0KICAgb24gYW4gIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBU SEUgT1JHQU5JWkFUSU9OIEhFL1NIRQ0KICAgUkVQUkVTRU5UUyBPUiBJUyBTUE9OU09SRUQgQlkg KElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORA0KICAgVEhFIElOVEVSTkVUIEVOR0lO RUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsDQogICBFWFBSRVNTIE9S IElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQN CiAgIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBB TlkgUklHSFRTIE9SDQogICBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElU WSBPUiBGSVRORVNTIEZPUiBBDQogICBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KSG9uZy1LZSBa aGFuZywgZXQgYWwuICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwNSAgICAgICAgICAgICAgW1Bh Z2UgMTFdDQoNCg== --=====001_Dragon680547021541_=====-- From l3vpn-bounces@ietf.org Wed Jun 22 06:29:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl2Ty-0003o9-3z; Wed, 22 Jun 2005 06:29:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl2Tw-0003o4-F4 for l3vpn@megatron.ietf.org; Wed, 22 Jun 2005 06:29:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22171 for ; Wed, 22 Jun 2005 06:29:17 -0400 (EDT) Received: from tcmail21.telekom.de ([217.6.95.235]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl2rz-0002Cf-Vu for l3vpn@ietf.org; Wed, 22 Jun 2005 06:54:15 -0400 Received: from g9jbr.mgb01.telekom.de (g9jbr.mgb01.telekom.de [164.20.31.6]) by tcmail21.dmz.telekom.de with ESMTP; Wed, 22 Jun 2005 12:28:57 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jun 2005 12:28:57 +0200 Message-Id: From: "Leymann, Nicolai" To: HKzhang@center.njtu.edu.cn, l3vpn@ietf.org Date: Wed, 22 Jun 2005 12:28:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: draft-zhang-l3vpn-vr-multicast-00 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hi, I've some questions regarding the scalability of the solution. Chapter 6 states that the number of trees in the core does not exceed the number of VRs. Therefor every VR is the root of a single (shortest path) tree. This tree is used to encapsulate all (customers) traffic from this VR. How well does this scale if a customer is sending to different Multicast groups? Consider two streams from a customer. A low bandwidth stream which has to received by all other VRs and a high bandwidth=20 stream which has to be received by only a subset of the=20 VRs. Because all VRs are member of a single core tree all VRs receive the high bandwidth stream as well (even if they don't have local receivers in the customers VPN).=20 As far as I understand you prefer PIM-DM as a core routing protocol. Why the focus on Dense-Mode? best regards Nic > -----Urspr=A8=B9ngliche Nachricht----- > Von: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org]Im=20 > Auftrag von HKzhang@center.njtu.edu.cn > Gesendet: Mittwoch, 22. Juni 2005 05:34 > An: l3vpn > Betreff: Re:draft-zhang-l3vpn-vr-multicast-00 >=20 >=20 > Hi, everyone > We sent the draft-zhang-l3vpn-vr-multicast-00 version to=20 > L3VPN group several weeks ago, but no responses was received. > Why? Could you please see it and give some comment about it?=20 >=20 > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1HKzhang > = =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1HKzhang@center.njtu.edu.= cn > = =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12005-06-22 >=20 From l3vpn-bounces@ietf.org Wed Jun 22 15:50:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBF8-0007u3-CJ; Wed, 22 Jun 2005 15:50:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBEe-0007kz-HO; Wed, 22 Jun 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23298; Wed, 22 Jun 2005 15:50:06 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlBco-0000CS-Ai; Wed, 22 Jun 2005 16:15:06 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DlBEX-0004XF-Qw; Wed, 22 Jun 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Jun 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-vr-mib-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Virtual Router Management Information Base Using SMIv2 Author(s) : E. Stelzer, et al. Filename : draft-ietf-l3vpn-vr-mib-03.txt Pages : 21 Date : 2005-6-22 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-vr-mib-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-vr-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-vr-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-22144956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-vr-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-vr-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-22144956.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Wed Jun 22 17:17:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlCb4-0007MZ-6Q; Wed, 22 Jun 2005 17:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlCb1-0007MU-Qi for l3vpn@megatron.ietf.org; Wed, 22 Jun 2005 17:17:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06278 for ; Wed, 22 Jun 2005 17:17:16 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlCzC-0002nx-9s for l3vpn@ietf.org; Wed, 22 Jun 2005 17:42:20 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 22:17:02 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 22:17:02 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Jun 2005 17:17:00 -0400 Received: from [172.24.235.4] ([172.24.235.4]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 17:17:00 -0400 Message-ID: <42B9D54A.1010908@juniper.net> Date: Wed, 22 Jun 2005 17:16:58 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2005 21:17:00.0706 (UTC) FILETIME=[BAAF6820:01C5776F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Folks, This message begins a working group last call on draft-ietf-l3vpn-vr-mib. The last call will end on July 8. Ron -------- Original Message -------- Subject: I-D ACTION:draft-ietf-l3vpn-vr-mib-03.txt Date: Wed, 22 Jun 2005 15:50:01 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: l3vpn@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Virtual Router Management Information Base Using SMIv2 Author(s) : E. Stelzer, et al. Filename : draft-ietf-l3vpn-vr-mib-03.txt Pages : 21 Date : 2005-6-22 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-vr-mib-03.txt From l3vpn-bounces@ietf.org Thu Jun 23 01:43:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlKUY-00060F-6B; Thu, 23 Jun 2005 01:43:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlKUV-000603-W6 for l3vpn@megatron.ietf.org; Thu, 23 Jun 2005 01:43:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13331 for ; Thu, 23 Jun 2005 01:43:07 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlKsi-00084s-BC for l3vpn@ietf.org; Thu, 23 Jun 2005 02:08:09 -0400 Received: by zproxy.gmail.com with SMTP id 18so813263nzp for ; Wed, 22 Jun 2005 22:42:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Nxgn42zbjpSQ2M3XqxhoIGGDYzl1OgMZl7bNowvegs80AMXEkKDEauNSsVkySUH31NrasgANcsWWSER79Srv7umAgxvTtZyVFrwZNwmh2uFOlL3y5czGYpyRcUs0uW6u8BcjoAF/y3ALKYfBddQ2XRZw8KbdONcpgA7OMZkKt0s= Received: by 10.36.84.13 with SMTP id h13mr1051861nzb; Wed, 22 Jun 2005 22:42:53 -0700 (PDT) Received: by 10.36.91.17 with HTTP; Wed, 22 Jun 2005 22:42:53 -0700 (PDT) Message-ID: Date: Thu, 23 Jun 2005 08:42:53 +0300 From: Petteri Hallikainen To: l3vpn@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: MPLS VPN MIB draft status ? X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Petteri Hallikainen List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hello All, I have one question regarding draft , what's the status at the moment, is it on WGLC ? If it is, how does it feel, is it going forward ? Thanks, Petteri From l3vpn-bounces@ietf.org Thu Jun 23 10:22:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSao-0003mz-FB; Thu, 23 Jun 2005 10:22:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSam-0003kS-Mp for l3vpn@megatron.ietf.org; Thu, 23 Jun 2005 10:22:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15850 for ; Thu, 23 Jun 2005 10:22:07 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlSz5-0006T5-32 for l3vpn@ietf.org; Thu, 23 Jun 2005 10:47:18 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 15:21:55 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 15:21:55 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Jun 2005 10:21:54 -0400 Received: from [172.25.42.166] ([172.25.42.166]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 10:21:53 -0400 Message-ID: <42BAC581.40705@juniper.net> Date: Thu, 23 Jun 2005 10:21:53 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Petteri Hallikainen References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2005 14:21:53.0943 (UTC) FILETIME=[E782BA70:01C577FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: MPLS VPN MIB draft status ? X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Petteri, draft-ietf-l3vpn-mpls-vpn-mib-07 is with the IESG and it is in the "approved" state. This means that "the IESG has approved the document for publication, and the Secretariat has sent out the official approval message to the RFC editor." If you want to know that status of any draft in the L3VPN WG, see https://datatracker.ietf.org/public/pidtracker.cgi. Ron Petteri Hallikainen wrote: > Hello All, > > I have one question regarding draft > , what's the status at the > moment, is it on WGLC ? If it is, how does it feel, is it going > forward ? > > > Thanks, > Petteri > From l3vpn-bounces@ietf.org Thu Jun 23 11:05:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTGW-0005Fa-0K; Thu, 23 Jun 2005 11:05:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTGU-0005FS-7S for l3vpn@megatron.ietf.org; Thu, 23 Jun 2005 11:05:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21260 for ; Thu, 23 Jun 2005 11:05:12 -0400 (EDT) Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTeo-0000JD-Ns for l3vpn@ietf.org; Thu, 23 Jun 2005 11:30:24 -0400 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 24 Jun 2005 01:30:04 +1000 Received: from [24.234.206.133] (syd-vpn-client-254-30.cisco.com [10.66.254.30]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5NF4O91026425; Fri, 24 Jun 2005 01:04:25 +1000 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5ED7B224-0F8E-4F0E-9B47-520083D105B1@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Thu, 23 Jun 2005 08:04:49 -0700 To: Petteri Hallikainen X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: MPLS VPN MIB draft status ? X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org It is in the RFC editor's queue basically waiting for editing attention from the editor. It is not being held up for any references as far as I know. http://www.rfc-editor.org/queue.html --Tom > Hello All, > > I have one question regarding draft > , what's the status at the > moment, is it on WGLC ? If it is, how does it feel, is it going > forward ? > > > Thanks, > Petteri > From l3vpn-bounces@ietf.org Thu Jun 23 15:50:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlXig-0004jI-VU; Thu, 23 Jun 2005 15:50:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlXiC-0004YU-PT; Thu, 23 Jun 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21254; Thu, 23 Jun 2005 15:50:06 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlY6W-0006eO-Df; Thu, 23 Jun 2005 16:15:16 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DlXi5-0008HM-Nr; Thu, 23 Jun 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 23 Jun 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-rt-constrain-02.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Constrained VPN Route Distribution Author(s) : P. Marques, et al. Filename : draft-ietf-l3vpn-rt-constrain-02.txt Pages : 19 Date : 2005-6-23 This document defines MP-BGP procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of VPN NLRI (such as VPN-IPv4, VPN-IPv6 or L2-VPN NLRI) between different autonomous systems or distinct clusters of the same autonomous system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-rt-constrain-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-23145255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-rt-constrain-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-23145255.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Fri Jun 24 02:29:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlhgj-0002Tc-UB; Fri, 24 Jun 2005 02:29:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlhgh-0002TX-To for l3vpn@megatron.ietf.org; Fri, 24 Jun 2005 02:29:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07065 for ; Fri, 24 Jun 2005 02:29:14 -0400 (EDT) Received: from [218.249.29.198] (helo=center.njtu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dli59-0007E7-D8 for l3vpn@ietf.org; Fri, 24 Jun 2005 02:54:33 -0400 Received: from zhanghk (remotehost [127.0.0.1]) by mail.student.njtu.edu.cn (ecMail) with ESMTP id 5023C18C11D; Fri, 24 Jun 2005 14:43:50 +0800 (CST) Date: Fri, 24 Jun 2005 14:30:14 +0800 From: "HKzhang@center.njtu.edu.cn" To: "nicolai.leymann" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Message-Id: <20050624064350.5023C18C11D@mail.student.njtu.edu.cn> X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: base64 Cc: l3vpn Subject: Re:explanation for draft-zhang-l3vpn-vr-multicast-00 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org SGksIE5pYywNCg0KSSBhbSBnbGFkIHRvIHJlY2VpdmUgeW91ciByZXBseS4gVGhhbmsgeW91IGZv ciB5b3VyIGRldGFpbGVkIGNvbW1lbnRzLiBTZWUgbXkgcmVzcG9uc2VzIGlubGluZS4NCg0KPkkn dmUgc29tZSBxdWVzdGlvbnMgcmVnYXJkaW5nIHRoZSBzY2FsYWJpbGl0eSBvZiB0aGUgc29sdXRp b24uDQo+Q2hhcHRlciA2IHN0YXRlcyB0aGF0IHRoZSBudW1iZXIgb2YgdHJlZXMgaW4gdGhlIGNv cmUgZG9lcyBub3QNCj5leGNlZWQgdGhlIG51bWJlciBvZiBWUnMuIFRoZXJlZm9yIGV2ZXJ5IFZS IGlzIHRoZSByb290IG9mIGENCj5zaW5nbGUgKHNob3J0ZXN0IHBhdGgpIHRyZWUuIFRoaXMgdHJl ZSBpcyB1c2VkIHRvIGVuY2Fwc3VsYXRlDQo+YWxsIChjdXN0b21lcnMpIHRyYWZmaWMgZnJvbSB0 aGlzIFZSLiBIb3cgd2VsbCBkb2VzIHRoaXMgc2NhbGUNCj5pZiBhIGN1c3RvbWVyIGlzIHNlbmRp bmcgdG8gZGlmZmVyZW50IE11bHRpY2FzdCBncm91cHM/IENvbnNpZGVyDQo+dHdvIHN0cmVhbXMg ZnJvbSBhIGN1c3RvbWVyLiBBIGxvdyBiYW5kd2lkdGggc3RyZWFtDQo+d2hpY2ggaGFzIHRvIHJl Y2VpdmVkIGJ5IGFsbCBvdGhlciBWUnMgYW5kIGEgaGlnaCBiYW5kd2lkdGggDQo+c3RyZWFtIHdo aWNoIGhhcyB0byBiZSByZWNlaXZlZCBieSBvbmx5IGEgc3Vic2V0IG9mIHRoZSANCj5WUnMuIEJl Y2F1c2UgYWxsIFZScyBhcmUgbWVtYmVyIG9mIGEgc2luZ2xlIGNvcmUgdHJlZSBhbGwgVlJzDQo+ cmVjZWl2ZSB0aGUgaGlnaCBiYW5kd2lkdGggc3RyZWFtIGFzIHdlbGwgKGV2ZW4gaWYgdGhleSBk b24ndA0KPmhhdmUgbG9jYWwgcmVjZWl2ZXJzIGluIHRoZSBjdXN0b21lcnMgVlBOKS4gDQoNClJl OiBZZXMsIEluIG91ciBhcHByb2FjaCBhbGwgbXVsdGljYXN0IHRyYWZmaWMgZnJvbSBvbmUgVlIg d2lsbCBzaGFyZSB0aGUgc2FtZSB0cmVlIChTb3VyY2UtVlIgLFAtR3JvdXApLCBzbyB0aGUgbXVt YmVyIG9mIA0KdHJlZXMgaW4gdGhlIGNvcmUgbmV0d29yayBkb2VzIG5vdCBleGNlZWQgdGhlIG51 bWJlciBvZiBWUnMuIEhvdyB0byBpZGVudGlmeSB0aGUgZGlmZmVyZW50IG11bHRpY2FzdCBncm91 cHMgd2lsbCBiZSBkb25lIGJ5IHRoZSBsZWFmIFZScy4gVGhlIGxlYWYgVlJzIGlzIHRoZSBSUCBv ZiBsb2NhbCBjdXN0b21lcnMgVlBOLiAgVGhlcmUgYXJlIGFsbCByb3V0ZSBzdGF0ZXMgc3VjaCBh cyAoQy1Tb3VyY2UsQy1Hcm91cCkgYW5kICgqLEMtR3JvdXApIGluIHRoZSBSUC4gU28gdGhpcyBS UCBjYW4gcmVxdWVzdC9yZWplY3QgdGhlIGFib3ZlIGhpZ2ggYmFuZHdpZHRoIHN0cmVhbSBiYXNl ZCBvbiBQSU0gSm9pbi9QcnVuZSBtZXNzYWdlcy4gVGhlIGxlYWYgVlIgd2lsbCBvbmx5IHJlY2Vp dmUgaXRzIHJlcXVlc3RlZCBoaWdoIGJhbmR3aWR0aCBzdHJlYW0uIEluIG91ciBjaGFwdGVyIDUu NSAsYWZ0ZXIgcmVjZWl2aW5nIHRoZSBmaXJzdCBwYWNrZXRzIGZyb20gc291cmNlIFZSLCBsZWFm IFZScyB3aGljaCBoYXZlIG5vIHJlY2VpdmVycyBpbiBpdCB3aWxsIGRpc2NhcmQgbXVsdGljYXN0 IHBhY2tldHMgYW5kIHBydW5lIGZyb20gbXVsdGljYXN0IHRyZWUuDQoNCj5BcyBmYXIgYXMgSSB1 bmRlcnN0YW5kIHlvdSBwcmVmZXIgUElNLURNIGFzIGEgY29yZSByb3V0aW5nDQo+cHJvdG9jb2wu IFdoeSB0aGUgZm9jdXMgb24gRGVuc2UtTW9kZT8NCg0KUmU6IEl0J3MgYSBtaXN0YWtlLiBNYXli ZSB0aGlzIGRyYWZ0LTAwIGRvZXMgbm90IGRlc2NyaWJlIGNsZWFybHkuIEluIG91ciBhcHByb2Fj aCwgYWxsIG11bHRpY2FzdCByb3V0aW5nIHByb3RvY29scyB3aXRoIHRoZSBtZWNoYW5pc20gb2Yg Sm9pbiBhbmQgUHJ1bmUgKHN1Y2ggYXMgUElNLURNLCBQSU0tU00gb3IgUElNLVNTTSkgaW4gY29y ZSBuZXR3b3JrIGNhbiBiZSB1c2VkIC4NCg0KQmVzdCByZWdhcmRzLA0KSG9uZy1LZSBaaGFuZw0K IAkJCQkNCg0KoaGhoaGhoaGhoaGhoaGhoUhLemhhbmcNCqGhoaGhoaGhoaGhoaGhoaFIS3poYW5n QGNlbnRlci5uanR1LmVkdS5jbg0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA1LTA2LTI0DQo= From l3vpn-bounces@ietf.org Fri Jun 24 13:22:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlrss-0004G8-BR; Fri, 24 Jun 2005 13:22:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlrsr-0004Fr-3b for l3vpn@megatron.ietf.org; Fri, 24 Jun 2005 13:22:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26584 for ; Fri, 24 Jun 2005 13:22:26 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlsHQ-0002Wd-KD for l3vpn@ietf.org; Fri, 24 Jun 2005 13:47:52 -0400 Received: from du-069-0069.access.clara.net ([217.158.132.69] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1Dlrsm-000JfM-6T; Fri, 24 Jun 2005 18:22:24 +0100 Message-ID: <0d1401c578e1$9dac59e0$7f849ed9@Puppy> From: "Adrian Farrel" To: References: <42B9D54A.1010908@juniper.net> Date: Fri, 24 Jun 2005 16:30:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: jlaria@levelstream.com Subject: Re: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hi, A few brief comments. Nothing very important. I-D should indicate intended status. Since you have suggested that the OID is "experimental" perhaps this I-D is also Experimental? Most mentions of "MIB" should read "MIB module" Nice to indicate (in a comment and not using square brackets) the RFC number of imports. (e.g. see draft-ietf-ccamp-gmpls-te-mib-09.txt) vrName Description clause has spare period and line break. vrRpTrigger Description appears to repeat itself. vrRpTrigger "Bits 4-7 are reserved for future use." I think the BITS syntax is not constrained to be exactly 8 bits. So you don't need this sentence. vrActiveVRs "vrStatOperationalStatus" should read "vrOperStatus" vrRpStatus Shouldn't this have Syntax BITS and a back pointer to vrRpTrigger? Better still would be to define a Textual Convention for them both to use. vrRouterAddress Are you sure that this cannot be configured per VR? All Notifications return vrRowStatus. I would have expected vrOperStatus. Seems, however, to be unnecessary as the status can be deduced from the trap type. vrUp and vrDown The Description clauses should refer explicitly to vrOperStatus vrMaxRoutesExceeded Isn't there a danger of Notification storms with this Notification? The definition of vrMaxRoutes is such that vrStatRouteEntries could never exceed it. So when you reach vrMaxRoutes, each new attempt to add a route will cause a new Notification. You should probably reference as normative the RFCs from which you import things. That will include the new RFC4001. Also VPN-TC-STD-MIB in draft-ietf-l3vpn-tc-mib. This is pretty important as this I-D must not go to RFC before that one does. Cheers, Adrian ----- Original Message ----- From: "Ron Bonica" To: Sent: Wednesday, June 22, 2005 10:16 PM Subject: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 > Folks, > > This message begins a working group last call on > draft-ietf-l3vpn-vr-mib. The last call will end on > July 8. > > Ron > > > -------- Original Message -------- > Subject: I-D ACTION:draft-ietf-l3vpn-vr-mib-03.txt > Date: Wed, 22 Jun 2005 15:50:01 -0400 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: l3vpn@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Layer 3 Virtual Private Networks > Working Group of the IETF. > > Title : Virtual Router Management Information Base Using SMIv2 > Author(s) : E. Stelzer, et al. > Filename : draft-ietf-l3vpn-vr-mib-03.txt > Pages : 21 > Date : 2005-6-22 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in TCP/IP based internets. > In particular, it defines objects for managing networks using Virtual > Routers (VR). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-vr-mib-03.txt > > > > > From l3vpn-bounces@ietf.org Fri Jun 24 15:50:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluC0-0005FW-UH; Fri, 24 Jun 2005 15:50:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluBi-00059J-SL; Fri, 24 Jun 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08801; Fri, 24 Jun 2005 15:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DluaH-0007x4-FP; Fri, 24 Jun 2005 16:15:29 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DluBd-00056g-K3; Fri, 24 Jun 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Jun 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-ipsec-2547-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs Author(s) : E. Rosen, et al. Filename : draft-ietf-l3vpn-ipsec-2547-04.txt Pages : 18 Date : 2005-6-24 In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets traveling from one Provider Edge (PE) router to another generally carry two MPLS labels, an "inner" label that corresponds to a VPN- specific route, and an "outer" label that corresponds to a Label Switched Path (LSP) between the PE routers. In some circumstances, it is desirable to support the same type of VPN architecture, but using an IPsec Security Association in place of that LSP. The "outer" MPLS label would thus be replaced by an IP/IPsec header. This enables the VPN packets to be carried securely over non-MPLS networks, using standard IPsec authentication and/or encryption functions to protect them. This draft specifies the procedures which are specific to support of BGP/MPLS IP VPNs using the IPsec encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ipsec-2547-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-ipsec-2547-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-ipsec-2547-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-24150751.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-ipsec-2547-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-ipsec-2547-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-24150751.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Mon Jun 27 11:16:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvLV-00084Z-9R; Mon, 27 Jun 2005 11:16:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvLT-00084U-BN for l3vpn@megatron.ietf.org; Mon, 27 Jun 2005 11:16:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01696 for ; Mon, 27 Jun 2005 11:16:20 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmvkb-0007Vq-Ef for l3vpn@ietf.org; Mon, 27 Jun 2005 11:42:24 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-4.cisco.com with ESMTP; 27 Jun 2005 08:16:10 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5RFGAZs025568; Mon, 27 Jun 2005 11:16:10 -0400 (EDT) Message-Id: <200506271516.j5RFGAZs025568@rtp-core-2.cisco.com> To: Mark Duffy In-reply-to: Your message of Wed, 06 Oct 2004 00:04:11 -0400. <6.1.2.0.2.20041005225652.02f8fcf8@localhost> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 27 Jun 2005 11:16:09 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Ronald Bonica , l3vpn@ietf.org Subject: Re: Last call: draft-ietf-l3vpn-ipsec-2547-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org > At 11:44 AM 9/22/2004, Ronald Bonica wrote: >Folks, > >This email begins a WG Last Call on draft-ietf-l3vpn-ipsec-2547-02. The >authors have recommended that this draft be published as an Experimental >RFC. Last call will end on October 5, 2004. Mark> It's great to see this document move forward! For some value of "move", I guess ;-) Mark> I have several comments, below. (They are relative to the -03 draft, Mark> which appeared shortly after the last call was issued.) Well, sorry about the long delay to respond ;-( The -04 version of the draft is now available, containing modifications (as indicated below) in response to the last call comments. Some of the issues have to do with the fact that the document does not always specify enough detail to do interoperable implementations. For example, it calls for the use of a BGP Extended Communities attribute, but doesn't define it. But I don't think it is worthwhile pinning down all these details unless and until an implementation is actually to be done. Therefore I propose to rename the draft to "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", and to omit the specification of additional details at this time. Mark> In sect. 2.2, 2nd paragraph, it says "In an RFC2547 VPN environment, Mark> it makes most sense to place control of the policies with the egress Mark> PE router." I don't necessarily disagree with this but I believe the Mark> document should offer some arguments in support of this statement, Mark> since it is the basis for much of what follows. Just because this is Mark> convenient to implement doesn't necessarily mean it is the most Mark> desirable. Mark> In 2.2, 3rd paragraph, I don't understand what the last sentence Mark> means: "(However, in this sort of application the ingress PE and the Mark> egress PE are NOT really independent entities which might conceivably Mark> have different security policies.)" Perhaps it can be reworded. This section of the document does appear to be a bit confusing. Basically, we are trying to deal with three situations: 1. Ingress PE A is configured to use policy P on traffic to egress PE B, and egress PE B is configured to use policy P on traffic from ingress PE A. In this case no special signaling of policy is needed. 2. Ingress PE A is configured to use policy P on traffic to egress PE B, but PE B has no policy configuration with respect to traffic from PE A. In this case, no special signaling of policy is needed, as the ingress will apply its configured policy, and the egress will either go along with it, or else will not be able to receive the traffic. 3. Egress PE B is configured to use policy P on traffic from ingress PE A, but PE A has no policy configuration with respect to traffic to PE B. In this case, the only way to get traffic to flow is to have B signal its policy to A. So we propose to have BGP-based signaling for this case. I've tried to clear this up. Mark> The document calls (sect. 2.3) for using an Extended Community to Mark> signal the requirement to use IPsec for certain VPN routes. But it is Mark> vague on exactly what the semantics should be and there is no Mark> allocation of a community type. As such this does not do much to Mark> encourage interoperable implementations. I don't know, maybe this is Mark> par for the course for Experimental RFC status? Or should it be Mark> specified further now? I don't think this is worth specifying unless and until an implementation is underway. Mark> Besides using the (rather blunt, IMO) technique of not accepting labeled Mark> packets from outside the SP's network, it is difficult (impossible?) Mark> to create a mixed environment where some traffic is protected by IPsec Mark> and some is not. This is because there is no way of knowing which PE Mark> the unprotected traffic came from, and hence no way of making sure Mark> traffic that was supposed to be protected isn't slipped in with the Mark> unprotected. If the draft could address this problem in some way Mark> (perhaps a lowered expectation of supporting such a mixed environment) Mark> it would be more credible. I've tried to make it clearer that if one does not use the "blunt" technique, one has to protect intra-provider PE-PE tunnels as well as inter-provider tunnels with IPsec. Mark> In sect 2.6 para 3, discussing whether IPsec SAs should be per-PE-pair Mark> or per-VPN it says "Since the SA is PE-to-PE, NOT CE-to-CE, having a Mark> different SA for each VPN does not provide any additional security." Mark> While I agree that per-PE-pair seems to be the right granularity for Mark> other reasons, I disagree with the statement about not providing Mark> additional security. Sharing an SA across multiple VPNs allows an Mark> adversary who can send traffic within one VPN and also sniff the PE-PE Mark> link to mount a known-plaintext attack against the encryption. Interesting. I've rewritten the paragraph as follows: A number of different VPNs might need to have traffic carried from a particular ingress PE to a particular egress PE. It is thus natural to ask whether there should be one SA between the pair of PEs, or n SAs between the pair of PEs, where n is the number of VPNs. Clearly, scalability is improved by having only a single SA for each pair of PEs. So the question is whether there is a significant security advantage to having a distinct SA for each VPN. Since the SA is PE-to-PE, NOT CE-to-CE, having a different SA for each VPN does not provide any additional privacy. On the other hand, when multiple VPNs share an SA, the compromise of a key has a greater impact, and an attack on the security of one VPN may become an attack on the security of all the VPNs sharing the SA. Nevertheless, the use of one SA for multiple VPNs seems to be a reasonable tradeoff of additional overhead against additional security. Mark> In sect 2.6 para 6 it says that the PE router should deliver the Mark> MPLS-in-IP (or GRE) packet to the IPsec module, along with the Mark> corresponding IPsec Extended Community value. What is reason for Mark> passing the extended community? What information does it convey that Mark> the IPsec module would need? I think this is just an error, so I've removed the requirement that the IPsec Extended Community value be passed. Mark> Re sect 2.6: Assuming a given PE device implements IPsec for other Mark> applications, how is the IKE Responder to determine the purpose of a Mark> given SA (so that it knows how to process packets received from the Mark> SA, and so it knows that it can send VPN packets on the SA)? If the Mark> negotiated traffic selectors are for protocol MPLS-in-IP, it could Mark> *perhaps* deduce this. But that's an even bigger stretch if the SA is Mark> negotiated for protocol GRE. There are other possible solutions, Mark> perhaps deducing the SA is for BGP/MPLS VPN use if the signalling is Mark> directed to the IP address that is advertised as the BGP next hop Mark> address. Another possibility might be to define an IKE payload to Mark> convey this. In any event, calling out one specific mechanism would Mark> encourage interoperable implementations. I'm not sure I understand why the egress PE needs to know that a particular SA is for BGP/MPLS VPN use. The packets that emerge from the IPsec tunnel are MPLS packets which are then processed normally. The MPLS label indicates the disposition of the packet. Mark> In sect. 2.7, item b.iii, it describes case iii relative to item b.ii Mark> ("... but case ii does not apply"). I suspect that not every reader Mark> ;-) would reach the same conclusion as to what case this actually Mark> covers. Can the case be spelled out more specifically? I think Mark> replacing "but case ii does not apply" with "indicating that IPsec is Mark> to be used in all cases" would do the trick. Fixed. Mark> The last 2 paragraphs of sect. 2.7 are very implementation-oriented. Mark> I don't see that they really add much to the document; I'd consider Mark> removing them. I think they emphasize cautions that need to be taken by the implementation to avoid errors that would defeat the security measures provided by the protocols. So I prefer to leave them in if there is no strong objection to them. Mark> Nits: Mark> Many of the references to RFC2547 VPNs have been replaced by Mark> references to BGP/MPLS IP VPNs. It would be nice to fix the rest. Fixed. Mark> In the 6th paragraph of sect. 1, where it is discussing ingress and Mark> egress PEs directly adjacent and says "... even in the case where a Mark> backbone route label would not be used" it seems to assume that PHP Mark> must always be used. "... even in the case where a backbone route Mark> label *might* not be used" would be more appropriate. Fixed. Mark> In sect 1.4 para 2, Mark> s/is the one way/is one way/ Mark> s/to connecting a/to connect a/ Fixed. From l3vpn-bounces@ietf.org Tue Jun 28 15:57:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnMCh-0002Vo-EA; Tue, 28 Jun 2005 15:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnMCU-0002OW-7W; Tue, 28 Jun 2005 15:56:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13364; Tue, 28 Jun 2005 15:56:50 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnMVL-0004J4-3o; Tue, 28 Jun 2005 16:16:23 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DnM5q-00088C-NI; Tue, 28 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-06.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs Author(s) : H. Ould-Brahim, et al. Filename : draft-ietf-l3vpn-bgpvpn-auto-06.txt Pages : 15 Date : 2005-6-28 In any Layer-3 and Layer-2 VPN scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The main purpose of an auto-discovery mechanism is to enable a PE to dynamically discover the set of remote PEs having VPN members in common. The auto-discovery mechanism proceeds by having a PE advertises to other PEs, at a minimum, its own IP address and the list of VPN members configured on that PE. Once that information is received the remote PEs will then identify the list of VPN members they have in common with the advertising PE, and use the information carried within the discovery mechanism to either establish layer-2/3 VPN connectivity or to learn remote site VPN routes. This draft defines a BGP based auto-discovery mechanism for layer-2 VPN architectures and Virtual router-based layer-3 VPNs. This mechanism is based on the approach used by BGP/MPLS-IP-VPN for distributing VPN routing information within the service provider(s). In the context of L2VPNs, an auto-discovery mechanism enables a PE to determine the set of other PEs having VPN members in common along with information relative to each specific L2VPN endpoints such as attachment circuit identifier, topology information, etc. Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-bgpvpn-auto-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-28150747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgpvpn-auto-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-28150747.I-D@ietf.org> --OtherAccess-- --NextPart--