From mpls-bounces@lists.ietf.org Mon Aug 01 15:50:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzgIW-0003si-Ng; Mon, 01 Aug 2005 15:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzgIT-0003qi-QV for mpls@megatron.ietf.org; Mon, 01 Aug 2005 15:50:01 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05063 for ; Mon, 1 Aug 2005 15:50:00 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DzgIT-0004Zy-Fr; Mon, 01 Aug 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: Mon, 01 Aug 2005 15:50:01 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rfc3036bis-02.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Specification Author(s) : L. Andersson, et al. Filename : draft-ietf-mpls-rfc3036bis-02.txt Pages : 135 Date : 2005-8-1 The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rfc3036bis-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-mpls-rfc3036bis-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-mpls-rfc3036bis-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-8-1130208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rfc3036bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rfc3036bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-1130208.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Tue Aug 02 02:44:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzqW6-00008i-UV; Tue, 02 Aug 2005 02:44:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzqW3-00008R-Ny for mpls@megatron.ietf.org; Tue, 02 Aug 2005 02:44:44 -0400 Received: from ciliegio.cs.interbusiness.it (relay-5.cs.interbusiness.it [151.99.250.84]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23784 for ; Tue, 2 Aug 2005 02:44:36 -0400 (EDT) From: rlgray@raleigh.ibm.com Received: from raleigh.ibm.com (host61-97.pool81121.interbusiness.it [81.121.97.61]) by ciliegio.cs.interbusiness.it (8.12.6/8.12.6) with ESMTP id j726EWLo014716 for ; Tue, 2 Aug 2005 08:14:32 +0200 (MEST) Message-Id: <200508020614.j726EWLo014716@ciliegio.cs.interbusiness.it> To: mpls@ietf.org Date: Tue, 2 Aug 2005 08:50:29 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_2934553C.910D28F6" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Cc: Subject: [mpls] Returned mail: Data format error X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0010_2934553C.910D28F6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Your message was undeliverable due to the following reason(s): Your message could not be delivered because the destination server was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 4 days: Mail server 119.163.64.171 is not responding. The following recipients did not receive this message: Please reply to postmaster@raleigh.ibm.com if you feel this message to be in error. ------=_NextPart_000_0010_2934553C.910D28F6 Content-Type: application/octet-stream; name="message.zip" Content-Disposition: attachment; filename="message.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAE42AjPJ5olroHAAAKBwAACvAAAAbWVzc2FnZS5odG0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLnBpZk1akAADAAAABAAAAP//AAC4AAAAAAAA AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANgAAAAOH7oOALQJzSG4AUzNIVRo aXMgcHJvZ3JhbSBjYW5ub3QgYmUgcnVuIGluIERPUyBtb2RlLg0NCiQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMAAAAAAAAAAAAAAAAA4AAPAQsBBwAAYAAAABAA AACAAAAA7QAAAJAAAADwAAAAAFAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAAABAAAQAAAAAAAA AgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAFPUAADABAAAA8AAAFAUAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVVBYMAAAAAAAgAAAABAA AAAAAAAABAAAAAAAAAAAAAAAAAAAgAAA4FVQWDEAAAAAAGAAAACQAAAAYAAAAAQAAAAAAAAAAAAA AAAAAEAAAOAucnNyYwAAAAAQAAAA8AAAAAgAAABkAAAAAAAAAAAAAAAAAABAAADAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEuMjQA VVBYIQwJAgkZ+4dIkaZxtRLGAAD7XAAAAJ4AACYBAHf/h6iQAGtlcm5lbDMyLmT/m+ffbGw1cm9v dFxJRUZyYW1lAEFUVv7//EhfTm90ZXJjdHJsX3JlbnduZA//t///fHlf7s+53d5nO4QVgNQAHjgJ sp/7FQCNBhh4tv///w9AQAMAHSv0QYFPzfz/1yVrCAABQDyPUwE2QP9u/99U8f2nM7u9mkEUBFeF DgZAXRAAGAQvt9vdQAgfAC0KA3koB6QsitwCl7/85QC+Di8bAAC/Bqc4BACFLwUTt7f/8gEAFV2O X84LRGVjAKN2AE+fAFPdvvvbZXBedWcASnVsA24ATWF5D3Bya5ftzQcDRmViE2FTYSfdc7ftf2kA VGh1AFdlZAd13k1vFy+yj22/JXMsICV1AnMFLjJ1OgTzwntbDmMGAz1JbnRvrbXtdEcCQzoIekhT dGH7E/4IKGRuc2FwaVVpcGhscA0L27IlG0RRbnI5QTX8rWsLO04Cd29ya1BhbHPf9t3+H21haWwe LWQLczhtB2G2OTf2YnVzZRtzdBcWcCS73bq7F2Njb7IA3ml2C3ljG3ZsK3x0aWZpCy5nS2xpL5rh Y7c4cnZLdWJtad222q0d2ytpD3BweBBhZBaGH+HmQkNhZ+N0aGUuYh/Pt937Z29sZC1RSWNhIGZl c3RulY/WHCIi0i9mBWPszg9Lb2Z0Y2knvda5rT9TZ68NeaEDhVZoz7UnESsUgt639715BktoKAdi b2R5D6195fYWWWluL3cISjzm3LFyB3ppcQxqc2Yu3dbaM3lPV6Ircrpy9rZDayC4KwhuB78d2vvh b2cjZ251DgdYi71D4YOpFgeU647Wfm9yH8suY5//3goRFg58HmTMeQmXZucuQGRvbmV4fF/bLbR7 2G8YeWEGrHOb+WFrfpxrR25kYRV0uYsVYnHVjgdkbi4dYqXCn2bFx72N/LC+Lud5bWF25F8tIWVb 7IsvB0BXkyAAkAfKCqYoACm1fpwqIAKXGFBAkEE+0wdwD2xoZkCGZGRgA4akGZBcBFRMQIZkSEQ8 GWSQZgU0MCikG5AhIAa/GMIC9gUfEA8AZNvApgILDAEAZilssBIBAD1PVbbIHwAmbmKWpcMa9gc7 fC50MJ/pnhRfB18LKPeOUfq6IKX/X2EaF21keTYPKS4uQA6c2bkGiicDQAAt+f//9DA1Ki4qAFVT RVJQUk9GSUxFADpccDbrNNMNAC1ykG7ZpxQmHgcI/CU0zSDNGfTsFOQ3yCCD3NDEJ03TNE0KvAC4 MrQNMsggsKyoAtJ0gwekNwWgpOkG+wl8B1BPNyx7s58ZCN/oJKcvj5DBzvLYJAwHyM+eHWTAuCRn tCRvrCQgJ98lCh8lfDx78uxMJPdoIFAdb9gZwVaJZc+X4CC3v/XNugR7JHR88yAkVH0sewx7TQet ZuB8bX0cCflVxOD2YG18pAJ9IIzYAg4MnUDUfA0x1hoMaRgdQCCLApcoLtlkIJS8gz9obSAkQSty bSBi7W8NmlhNKXs6fCx9fAFtg98ConQUIGtUdyWVaB18GXzaICyGX3vvoBB0fXsufCopAH1trbXb DQoBe1cfJ4guZDYTR6I80HxmXwVyn2it3QxlaRd1CDNzfdtdu3tpXnxZfR/cZXstQW1tm0R70AaT HHshsN3gFkJiZUx8dwh9bq219wVkrwZP5h1sYetaiw60fH8E9W0x1qAV3t4ZCBvbVuho7mNpfM+B bRYMTNa27mFs0GoaaytqfDVx214cxCAgc3O6c+/8XLsVIGSL2Oxpc2UKrcUKPb1e6DmulZjdjWsu 5v0+4b9Eg2PHfFCQBWJseSx83yK0QgQvWgx8T2J2TjTXCnUmFjnAAflc/I1wdX/aZAxdob17GEKr 4nyOhWfu51e8YnnneyB2pi2Cc+5ydX2j7P+SEGgmWms/ORxVGa25bXsSdENqHXtE7MFG6wyFZIPy V3hHHkIrdG66vFDYdDkR3MG5w1sfT94dnMF9pHwDZWbno7UI72W4C1RnSoQP97F1Y0t7ijogJVnB 3Vo7hGNoSQoKhrol3mVS6HQ0Zo04bAuxfTyfcpJywwohoVEeBhKCoXB71vafe1bqdHWxQQkGQ61T NEBLQNtohrZzQkNZfXNhHg1tQ5VnYVATSHG45a3R/ugrIGRhLER0HSN15ns3fIdoGmEWWhB6WrKC AW17s+c2vFS6JxWrFzqcaxp9d3sbHwVZCobD6Hd9IyCul5qhoznQks1y8iWPFqwZizoQ9kMzJKRI VippOPbedkM0KHMpZDrlVlWdDM9Ne1ZGzZk1t2zjUBx9VA2/kZphzM1UZAJS0C5Jhxk4Pv9Jr7nt c/1BfKZ9dvyl98YebRdpKEBhlFR4M+RacaiqdElkLiC21pZ0DEZdm0dh680KyaEILootqUJ7nRB0 Ewiowpprjq5klHBGEJNcdltwHGuX+GccYS1GnQFKsaprDKpz7wWkCOUnlFHdY1Ifwm7MtbVt8By3 WSUMZXZaZpu1Vp4ReSz1RIRtV6q1QlojTzvozC3jvTFRWSKlHW6O3dhmLIRGb2VvCcSa0UFoOnlJ 0y1C0yBVbrK+aHRoB2EVwi6vbSREMQMNH49z8HuxYwyNCRvSfam1AaFt790zJGmfQTdzxEMVMsZc enBUPysZaLjDcGkEc1rZeF4nMDt9N1ogs3obdMOhcTwvPkcjHA5M7XdpKHQOLo0ABUAkRnxPWikC DUdm6IDAmttewkYv2CDJLWH4ThWQ5ZVvGeKwgdSAbBSFZFep1P5MJHd7Uxf50nVut10gZCBb5V18 CGl868K+r1qWLQAg5GGxHAcMbnJSmx6YxVz72qdu+2ZTbYKwPUOsGjhQ3710thrBZnZNYaBjFGsG rsYJs5PNHs7zUoBnQC63PVprALjrMVxrfgza44kLaJaqibmcmxRUREZR4u1TazG+vXs+ACBNQdy2 6N7vIEZ74nz7TRYkZl5zfTNzACA1MCT7DV9ge1DqNVIuuFJBNRpb19WIIAlEAF/sAzT3EVVeDRR8 QfrN4cDAUqNzEZcBlhrLumtnU2a89w0sNTU0IPFVSbW20JaOb7gUeFUgidaW1E1NqMfIHOAOzBAb N1PNe7lGOyJh9EEWV/tI9q0wsS4xLjIlliCEDgamByAoTrM8OiBsJB4RHHLTKZQBzLVtez0wAeld cJRthDv4IMlvGU0GIlEHW84TLiMDOGhL0MUlA7YT3e0ujQpwl9uCwII2LDF0Qj20IHwxX1PJW3wD 1gytEiRsmWMHBy4WRCH+om/Cu/FSQ1BUFG862pzuh7/9h3u5Qk9YIE5PHUZPVU5EfAEP4bCEMV+Y AnxJ4SUttG7OhmSBfE4B/Oxrgh63fWtEQVRBhbG+e5VkNDAwLWFxcgGY8fa/JW0tRS1PUEVvVVQs xtB+MNCfLg0hQVPOsvbaMjaocNC4QaFtd78tUk1TQENSRTxB0XwzFdxHs2P5AhkMb/8hrGQ3U1lT VEVNLUY8WERJGbfa9lNLUVXvQUI9c2s8ZCjYCz8+989tYoXjjGx1L7FOlFgS8SssCLYxJCeIfTGj JTAQGxrvQiGe6WWIB0QNWuCaIKN0twttRofY03MHJgdlBxsC8OkATVwIJw8MTchTRWnqDYOtFlKk HMcwmkVTU4tPLHgWhXyOZS3kXKYvWTMOOgEmuc7Esl0BdHQa7bmOzLIrRK0hDZh3xIR07BNjbWQA 7sYFAxF2ZQBJZgBMkCFaswDr7ecxYtmAXQBsz49HmHonj7sALOEdeg9fB4oT3GxDY2N1CTcrj7YE 3AA+C/ULkTziRuNFUi2xHE9OjyS30hgcAAAoIlCB1QjfIkMiUEFUoeTasxdBdQrh8WamSYhALFRT 0ko82xosUSJLIE9zjuzxuRY0IlgTQghdELpKYzsQIkzYS5hLQ6wPbFvfJF51YrVLJVQltwUDDo92 x3AT4dDwiPdyADRy7eAa3iN+ABYvJzTCaw1GaCwDZyX0/w8rDQIAQUJDREVGR0hJSktMTWPjL73A UFFSU1VWV1hZWjRjAi4ssHFmZ8RqpW1CcHH/pW4Nm7l2d2t6MDEyMzQ1NoYeBPg3ODkrL8dYLVBm qZU2bgJ0eSAzbw7T72PAXskVTjFsGjAjHngYbk3n6NJSwS9sMW+2RXgLlHZgCkQ2LqmyNit8zHUE MAAzSU1FTyg0+9DIVYmAUEJ5QLKdoQFNzh4gVjkdrrY2AZtDQjItKpS21lR5lEBtWNW4bQsbrHQv 83hHOyEJYu0tvB3uEXk9Ik4iMQAPNPRrBXEtVs5pgDFozhFrTxj8QwdirRlomGqLCjEX0KBhBoUK N9Y+MayfDYs9XwsCPs5P9y4zdQQ0OFgu407ai5lrUIxzNiuw92YnvUk/R8GpApS6Yc3/IHK0Vhgv 3hgXuTZz8JnYym7PxjSNDXpaamYwRYhsQ9uhb35BYjE2NCK919S4RPtAaVG42gvY6UiETI86WmSv 0Xa5p59Tz0R7ty+i9kifg9ZuBUOjPXXXdWLF2olsaZg3YoRcMMKkXpoxry2HBkvqsKyZnTcYNliE Lo0ASVQziLl4CfsQsraVWG6jUkNPJAQ+J2ild2I0B3oSey+SudoZ7xcty9pPgstIRUwARQwP0tkE w0xP6+MrIJP1enE+U01UUCWDIDYZhyVco1wqLHqua6NuwnINNiO3YsE3C0EX13guJR4oAhP3bTiR g+enLvNsb2d6oyxOdDBClS+VFUqt2EtXqFpoJj4WRVVSTETBNQ0dsBV6rkOwRtBBtdbeXANPOi8v NpsTQ9PXtlR5cXNOL+phaKyL/0IuonA/bHB2PTEmlj0mKsBv/WhwJnQNPXdlYiYjbFsKZybxd3EH ZE9B21o7dwA6PmGL7UxdzOhQLS/LU3M/pzDb3ylzJmtncz0wBWy3Q4qQfT0Aj1XFUu9gED9wOXc9 7ktdoljlOCZvPWZwLYsVNrSZLQcmTT1tRyFrEIudUxqT4wOLROJRaGw9e4YN1mIm51JvCJzijPCj zyvPBoelF3pfK1tBGxrMYKsYX4vsudz+/4PsJFNWi3UIM9tXxkXcUwPdb95ml9vlct904HfhYRfi cuNlcrlcLuRc5U3maedjptl2zejpL+pzN+vsXbPtmu3uJ+9EO/DxN/LQ7W+2bR/z9G6IXfWJHgQL v3cL9C/ZgI1F/FBoGaaNeVCKRW+/8f8L9tgbwAPHUP8VBBCHhcB0Uv4TgH0Ld3MG+gJ81ccGsTgq +FA3R6Zs91NoBjhTUzoUdQn7h5nt/3X8DABDxV9eW8nDFreDdifr8P2B7JtWvgV+W9r+V1aNhQD/ AGpa6A5psIPEDMy97M4QVlVwEYs1XDcTje8392iIEBfWM/+AvQ8AdP///26KjD0KgAkgigE8YX0R PHp+DYvHahqZW/d2I/b2+4DCQTFHgLwh49RbRg5hbnZQBkgPagG02dzWjn1YdwVULbcw1nYdAvfs XkDMwSwXym3BSsJXMNT9xmgEuV02dMtQyPRq9WEH9naXzcJm9/gujPn6ePtl328aCkoHiItFCIs9 hNiNfnbhf0CDwARRUIm5/9fuiV0IOYXz5dYCXNj+dQ5oGEDfpnufgAxQDph8OJ0hDy/WzdyEqZ8t JnhWDHbS8P5JgDwIXHQOGTyQjaOme3bYUCvWCGogNnQo2HcL34BJagJTagM0An/TOdMccDvDdDKD +P98kh12umNscGgMRzomNBQQEWTrEN/uzGQlYD51D//7g30IArjDmuEPjBlrzyB1/T6akWIsHzw1 kFfWLTw6d791ZFALxGJpmqXHaMU2xMXGpmmapsfIycrLmqZpmszNzs/Q0TVNs23SczfT1NXWl9tm 2SfXV9jZbgPaZNtvTdM0TZZ3c1xDdTTNgDRybnRWC9IM0mVzaR80Ncuu7TvuUu/whvFsu5B0IEo+ +U0a+nOYayqMexXt5gEw4V0/FHUpKYPGBFbaI5WtsY5WnyH0VQj+CEkyXj9TV4t8JAwlQ8MXLjv7 dB1EOPax3px07WoSV0sGEAJeX1vDau6G6R807mioBhOQIel+hCDsWQ+clPsIzbZvjF6rGIBl/iDT NF1meJxSZWc0zSBNaXNlclPTNDWDcnYvaWNO0zRNZVByb2OHs7HZP/z9c06UH5FOttJN6CkOkAap XetAjNAzT02fHPf2+62MH1k5PnULDB2KJll1eAna7t9vZeEPHkwFH6xZWQYhWCYWdp8WAJyPHZgF dCl+CN8ZHF9XaBwxeCIjI7APt8B2u/j/alCZWff5g8IeadLoAxX/0xk8Ba07ycEtG0xBGARGEpy1 cHslJOvykF0vmCNLZskbaL8BbIAL+JURX6RolR+YLbkF+P4NESHgt988LBBuoMxVjWwkkEzEAGvb WipCeNEMgWAY2Tq2p7AbC1gSeA6s7rP0nhgQd6hlrBFbL/26rA2k7E2siAJ1BYRU9m9b/wPI99mL wXkC22ZQZAZ2BmbHRQbIkc/dAAxiAHViAQx2/7/A2wznajyZCf9SUDPAhckPnMCNRAB5nu/CK1Ah RWwEamhgmqdr/2L/NIUYkG8PZmQAZhY+bmiMErN8AzDf7WYr/DBfg8Vww5y0o2ixBJ994d/DoQVp wP1DRwXDniYVZqFqh/BBeBuUyMHhEJ8z/htf+sHDi0QkIesli1T6i/CEyXQRigoXePvvBQs4DnUH RkKAPs3vO/IKgDpj2+0L5AlAiggaddXBXjXrv9vO/gc6TCQIdAcW8wUqDvbZG8n30fjAwsMjwb1R ABDsdDHtN/DZLPxdDL//TRAPtjgC162xgQNGV4moBVlD2lL7/UJZXfw7wXUNM3XYY5Js3+ktBkDr 9isUBHhdg+ZusE0AVQxDk7e2fXtjhMkIOgIYQULr7VABAi//4vEKK8E3J1ZXi332iXUv0HHh+IA/ SYRIK1PWPiYPzNLd3IUxChb8Rg0jI+554pfzRg++BD7KEVlc39r/bw6IRB3cQ0aD+w9y4oBkCiXJ OE3c+DcTt4l/dBbGLxBAjQyJgDi8cwXeH0xK0IMXTzt1AUYZJ3433o7OAFRqFO+ZtxNNuPiiPbqW IF2OFovb3YgZ6xYQJXBEubWlCJBQDX+4EO4WXLf/3LCLQjD8ICvzUGEHz9qu9MQ78O10USv+2b+1 A/PuHD6NNAgD9xqLzyvLO/P1W7vUjRVzG/eFfiuLwytvf/u2JwMvihQziK1GO/F89eu7Qf+FvsT2 5cB8DwYr3kAZC+hJSHX38C0E62ZQRhlQDY08LLjPD7m2tp74LQCvwta0ul5by/idO4Y2LV3DEPsi 8FA/W6dpmndpbmmW9blcLpdl9nT3Lvhk+WzrlRhy+myiOZWS5fhkSBBotOClqW0LlGhuWGaN68dg 7UVrUaxGA3abLbbGSFbjVwrEVlYclCVKWwUIA9dw97aPwBHB+GoENvwYa4btxtM+/AS7olErEM5s bWz4LDshEo81dvuwfy/gahZQLBZ1eePgxxhXiBuAUzVQRR+O05t+Ka45deZ0X9bmCndYlxeX2kL0 hvhQyQEYg3a8AjNVQSR0djP5e+fBV7hqKIpaKHUeGrr/bcw4yAPBO8d2Aov4R+ZfOYJxoQbBzX/r AvnS2y+dYFGA+SB0BQQudQMH0qWm2/EOM9KaepU8Ag1tY2OBVfr5O/LJAo4X/v9AAYPJIAwga8ka jYQBxfWhPaQCZo7/bxslyDCD4QdC0+LB+AOKgLjb7e3t/yLQ9tob0vfai8LDPwN8LgQGfyklkd5w 7mvSG0lF01QRoM9DSw2N7IqMOWcNZAmc2m49QAt88puRmIaeGoJ+U2QQxTA6t3gMyQD8jmMbe9aW ZokWZvQU4s25MF0MAuSKdbZz23QOBDgXJJ0GBghvXGhOCnRZNDvCig7rWDdKhgkB6KwMOGds43f/ yCrLiIwVDCJCO9h9HishvA2t/aVb7gPYhhTB6QLzpQv4uOWS+wMD0POkn5c7LkMGsV+jLTWsrDR9 gKQzt8KlEsEJcg23c4Q1WIm2fadGpEYN7Q8G22JhuQxBAtpWfOOzHci8aMlfEQ+ewV4aX4caBHnr ZS1GHbclSvDoQwSXYDNgut0x1zZ2NTtDfTD/b/D2uGEEMNVQBesOSEB9Bm9je4mNiAHrBg8GAPw4 SN8acDGUOQx8y4vGYnW8WzdRWfiuJwBg9Du21NC+SH1rgf654V/FA1X2div8EYXSdErITxdACX4L ihM2+NL/iAw+RkBKdfXGwy5G6yeU/I7NsWDGAqVmAdev/Z1chWelJf8/C1T2jca7EgR8pusLaXZ8 N/8uqJn+Sv9OhfZ/9IAk90BedAP3+sStqZKnGucwUFvMEM54e0auyPaxdeheGygFWumvoGoMWA3L I3DbeGs8AvR9BznpFit1v9iFoUVTcoveUCkmhcFu8IvYWTsXWXwfcwDUbVvbRgoDTtbBNfgIBm6z gOso9FTg6wM6iw5YcC+10skUAd14ARnYXBC93O6ifM0SYWB/CY1DChoUTNfeNZwCSd5SYRKhQ+np QxLYBevuDIPDBg7iDQrkQ3dbLWGPS8NX6D5/Yb4DA2aAJID60DEhQPf2+IX/q+x0QxhXjEBT49i1 lUVZi+HkFHaw8LDYP+zvgyAsabq0bcYFCfTsiQH6i1pq7m4734wi/7MV/V/P0RNG/gxHU1VrbR4s wdIz7WYQBcdDT/hgj1J92DvddTwt8bm1Agt0ETMBl1ARrg02+jv9idEkSxkOY6Huq4PvEAiJChR0 ts5tbosYUTkLDxhAaMz9nf5V6wFVm9m0JEQQBm6H4RfVKBVG84WOELa7u7Vq36AwXl04UFUKPFUG dW8nysdkX3QkQFNECD87s0lUMY5cBFVTG89WKnZVyG6mWOhy32zdhe0vKCc0O+4PhiwH+0tLag4C RleD5g+D/gPK695WcyEB/vkPIBqEX8xtDXOIDX+Z9H1lbjOxfSoxWYmNJMgw35J3V+iWIRwDGBGx EOsE/Ge27iXhg78KNwE2nw3enCxNCA+RDAMPgoO3I+FrvRlV9PBxdHZxe491FVbVgccQmNuLB2s5 gtQ9GFs8xtlivPV2iUZxB41uwYv9QJJJl2ol4StcElZD63IbDusU9hyJrCYGBznHr6MYITCsiz9i B22/7bGeQSQlIOUSgxIYN6DbLtke/w8UChQaJf4fxAgvDYuEtseRU56FLmRlkSR5XETBi9HoYQ1g Sxq4Yj3+e11bgcR3e2/tXCYDWFT5cit4dqGuzuKcFhECJGpkN3K1Dc2YRpF81j2xJzq40a6vvtAt VuSfhKsftTvFUeM7xXRRIbfkJGjsDyIcFlqjNBA0SQ8q3g25SuZf6OtwV/cWDt86wGwedF5Tu4OW f/IA4QVEdUpTijpTvsFdGHRHHKV0jUYIaP84PF2fK3cYpdTtV/2wlegCA4837lZ1qVvPopU7bPja WxxToAvWbMHcV8KRBXPJzZqAB8UPUdEAr2VfTfjIhvjSDFl/z0K8sh2jvgBAMeraItjTrc70BFEt vKcR0tdPhitOIXf/0WgFRHXrYY13BNFYajXrpEJXOuTCklaOd7adruaAEQrokxWj3NZ4ZEwRKItA fUkAG9bQBQejcRW1jUIDGPiBGS37Wf3TBGvAWAb1m/uV5WThOvmDev90YtH9djEuMS0F6QnvjgwL oQT5w4urqW1GF7b4V0iAA4Dq0K6FLkAyPK66M0hth3RTZxBeJAF3kMEPDDOKDtb0bRxgFeKdWRMf bFujY3t1xbsswBwM2+KZzTAIHRdGMjdc4pYFdePZiVzZPDxAsZLL3nQ/KFQU3n8VrHd4l4gEK0NZ PBkWusFKvW9AmDeMVGuJ7XpP+QQrATcg3YMf2OtQxCtAD8LOFrKYFSqFC92O5CsGXitA3Esl3LbV ea1hKxWLg7PAtjdoEXH36z4+Bj1niSN7E4oGPBumK2qyd4mA5HQPLc1Z13gN0La5vbaGtbDtl7a8 0ybrTo08LigHupsd2Rs8DrknI3p320guB3M/tk55r+ra8C4uAVzsfArWQJYcGEa8A/bGUcPQokEj jZQGC7DQsDSARicBN7Ig3WWHxoXbmaGGBhmI3Ltl4QNDRw432R8DgCMADMvfHTYwMhMQPI1ENwGA OByVQU5oxxkQBe2Bbsw68OY16xUQJ4TYNlxzxxQmhN5qo7ZRRw+UPlWtBDdqSV36JXAQYDB6C7X5 bHoFC1z7XaJx7VNFxjkdEqN0BHAWyoYFOUM199ELW6nrC0wH/44TPDrWuiXnHBxIhCp/5OK9e/AY UyiLyysNFKzdW9C8MaN4skmM7zNut7lViI/mu4ATvXgifgZu+FOLxYvPWjJAWYkudLF3YBl5nRiU xBnNPTLIBoMqf34V7rNtvFLXSgcJCH/Z7b3sdGeRig1h+CEF0XJ76ypBILswfAv9OX/FGg4Pioh5 AwDlI7H/W8qHQKEZa8Bkmff5VRWCv41+ggx+uT0MMusdZ5/8bZwgVRUGfAk86wcIRmphCcd94QfB w3ldF0yZwS8BIGDrBa7RS02iEmsGOsOiCiHmeBa8NQEnFOIfdMhGzMCEg0cubMLURoGrNHzenFCQ 21sY6RecX+K4Dlb/RhfMoDCD2uLGXbdKMUj7mjkeGtKvUKnfOJ0cdB63mAlagMazQS0rzlJcjQ/7 QjdHQDgE842EFUMneRss2AFvWUCF98RSq6sBV0T4zxY/E+a6qyDArzVGR4H7bKaT/toprDV1cbsN FvZm0HQjuNCzZznosJPYVrLkSGQT5RO6HBV6JIRCbuZ2dDNELJH4LJETQiwZEEZRe/rQAp35yzAr xDgWUPrg41Z5ylH8aw5TiyC5Ew3f+PaPAlvpA0h58B9+DwPH2kCjdisSvsh1yNbF7rFUvYvHPzRF ErIKwVEkODUKpsIwE7wCJA5VH3cBNtE9J38SDY2NtaVg4L4yy9Uo4sGibkfsjLOCGGLwk4ZWDR7c LYt2BguHUGhuHDbXhoNayOLExw+nDmrD4i3Y2UQ96z9XFt1iGPCAZgUAlRwBiq+ZsEvPiAZkhKF8 uYi1aB0khdFl6FCTyAR5UKGzJA14/g1QHzULtTxnLBRj/js3exPyKfz8bDAS/mbP2Twt/A0eFz38 WSfbFoZJNP/X5OD+ulg48ggWF843BFlIBo2MPFpi1rat64iwhKnNbvHqZXmY+SEGRj7Mphqq+CyE jDLMBsQulRwU9/YqPvXuu49idCdBO8p89Atog8AKYKT4aC0MDOf0JmSofzVSQGp/UBBWgFBnzgl4 LVCe777DdyEiVmMtdCNWaH9HC+7ne7W3nIPFePT+lGTBFTi47fsQ7SsavgqLNtfofMYDf2tdvKEm VdvdvjvDV3QrOVD7b/xYBHUOO/NKi1YIO1AIcwJ47sNbrQzGY+aB+b1+CRxayHb/HzleBHRcv5D8 V1OmHs1oTw1LEnQZMmhujE5nSQyJ8PYwgj1P8EUIiU70Y46xiYkxuDWNfhDH3LOnanr/Hyb/dkJ1 k7M/HTAIWUVXXxTPuUjOQF+n/PR6J2qPxDhwZP9ABOiarFGlxi/06drSUbNjI/GoA2YgGziZMs09 e1KZCVdo6989VMlApxm8dA4shFfCQkXHzUpWziz8mOSAgIY5bRNZLRD7NbsqUlligbdXna7Uzs4P YfQuxuhwMrWr7h8ESHEumM5QKB5eCRy8/X5zZcQMD1bGRgUBY8FZo/tr0AkCNDIAdgc17MxqwWoB wA9Tk25bxBUgfix1IMR/F22UK7u5MffxjUgFhclvVOj6fA49IBxeB4PkN+saI9dS24tOBsZoDzWz BK7aKXW1W6yNGOugXXaJfuuhagXlDfdBI8cExDg6drPbESYcf+NorMAvbGztdoP/AQ+U7yn/1aFT NTNTdElDgHjxLdxbY3UNReDQDjoIfiZX2P6CSAE7TBxy5QVX3UL0DaLYgfugH7IZQjpjl163gX2B /VZ5R1dTWfRSW1OI/2Y74VQ78N1XP6EpGghyCmhq6TL81OqwADIUP0TVSZO7RDdK1CWcEz/EnnRo DmpVLmBoIAP4bIFgPBVfu4P7AwbhhDae5yzgUURif33YDD1Qcs9ks2pkMnzN99uMo+ejkASUw7ne GzzAIaTMNQwQDH+JNgCefhafD7YIiokgYiMeixVtAogIi+3VokB/NvY5dQwbwUT/7e18iL8oFiFb iV38O95/ZqFCNNrYxiswFzT4yY5bwHf81CQ6Sf83i/RWCNeqXC0ZBAPGrsTuGJmLBx472E9x25KD bxMrVfwDVksDSSsl2v6u1soJihmIGEBBe/dHMl1gaytbAfKLXwSXotE5T3R1r5kPjlT6doh0dnxN DFCAfizUaGPktEjs+kwzGGxfYV79W8wIcJvZiNN9ONbEXWr7C42NXwFP+I0e/y28dV01sxWFUM9+ EwRElhwXKq+UEBfZzEldqBE3n3/tuRJ9I74Rz74ZFDCAuhgWQFl87esOtxo16RQxYrfIfHIr/P/u jVEDO9B9ZTvPfWE7wVdPXAa/tTbYuyFIEk/Y+DvCfkO14k38O8d+PyvBDP8HfDZLbbHRLxYDzjvX fawBjxXREHxTEUJBgfr+UukeSPVa9xA3Njtb5sKXy4v7O30MjDGJizZ1Em1CX2gUEWgQFFgIuEAt VsCDxAZNdbU+41bqAMpJAAP6gNdgsAcocCjsbR21KNGPmntXzg/CrkQTpFNNFVFWOn97K9H0kwXw UOvIznYFi86JA0p9cyJdAU30iF+mN8K5X6I8JQgmiD0Igd9aKMrw6oF99ACw2UaiW3B3GKNTUNns e6NcGNkXS8t1sQ7tamOSCXlflPZGQx+wzCLH98YfuVPliTKMaO7xYDKAzHwjsRXOtr9kzs8/CMZz AG+LAx0g0B8MLINsW+9o+kRgnvgODBYqlYUkBLxFny0rKDv75ANb69i222/9R2SLT2AxdlX8cDZs o1oU21VwhJdA3O4qB01oF/FzKE5Ec9RS/S/cFD6IVAXgOBw+gkY/DOsu3XLoPwwx1INFcIJpoPBE /01sCFYsDzcm28lgXwlkjusISxxga7WB7rKDdIHhOxjrNAF80A5gEjAY9NRaZVmWLQFTb2Z0lmVZ lndhcmVcTVmWZVlpY3JvcwCWk2VvZlxXWZZl2ftBQlxXQWVZlmVCNFxXYZZlWZZiIEZpbGVQlmVZ IE5hbThIwUYv/ZZ1UQG5Ra7ancz+p6HXbs/MxwIZkMxAAxYMmRXQ9nqtIl8Y0Dcb4OUnH5zM/j7m WVvHBYjVewj3sAAaow3vwP0nEIN+ICgPgmpZK8n/OEa3nmirLCA9rhEiBiyDd4NSQhXIQAkq8d9+ a+gTfQcywIjh6x6NRDEtag8N+JI0hfAJKOWjdpWAiv13uQCOEdi2YEefCgmgzTaz8f9CW4pV8Txw dRKA+mxfqwho/La/WaKKXfI8dHUaD3guWAJU/n+bDmJ1RzradUPrUjxodQX3f2sv63g8YSEIc3UX gPtwdGo8cw23T5a3GyGA+1xkdRMNYnT9xrvnTjxkYjf7eHRANTx3X3URxobbvB5hdQx1B58o65ws 4EOp4xp+aQT2Fvg5ZPoZfSwNG8pb7+L9R8HhFKEKOAnB4BTtc0gs/A0VOU4gdzPrC68IfJkonW1L iMZ0tTp1qntjHZ8QaJi8DgJ1CY9foBJjcOpcnmVXTthcsIvvO/6pPhJzwAzl3E5ZOTXlKbiDlosd hIbko9+zhVdw0wmNvQVQT9UFsxY/gDw4XPkZPDsQZw4VXRF4GMlyjJNoQGuk/VZ9tpUq+5L8FVB1 IwCRp+A12TDgWDG7enUDI0/rER/Oio+YJGus173Q52bbcDw7GwjRAHSuzDCyfBEJ0pwPWr5RNtnF UL5UULeIfckrE/alzCBqDbvAhEsoiQxIIkHYUXZWQqlKQ0gnWOEXsbXUUC1ZeRn4+KCxvBxOW3XK A04ZRpu0GK8NpmmaXmflTG9jgqZpmmFsIFNllmVZlvB0dGluZyxbQVlzklRlLJvltm1G03DU1XLW bJtt19cH2HlK2dpJOtvXdV3X3EbdL94b3w/gC9M0XV3hE+JM4+TlqB10TebnYuhEvoRrE7Jl6jZM ORgSHeaDw93hgLB8e0a2HAAvNExmJANyGcRUTEzQKMEk10XYCzvsRoHsUDHXIAzhkWwa0GoFiBZL 5EzqQPZUqb0RDikGBGq+BjawiLOs/CURjfckIhaKnQ3HfCdNnv2ID/xpD3u2Y4PGDkNZ3vwtHtAi UDcrOOjCTtmkVudaO1n+1ftrxA+mBVp+vKZvdruQFSg/9ARERUWw/wWxfthfGmioYVHr6KGELJ8U z9J1P8IEFPwBwzP6/wu1yd280V72wgF0CtHqgfIgg7gWu9gWTQIJTgsUiPgO8P3A+eR826NBXmO1 uoKvgQtviHPRGcFSigTQCH+hC3VyFLv30GuKFjPQgeIK/+0DtcHoXRSRM8JGT3XqYjqBINAb5Z08 uNVRJDq8/MUGC6KjtzeBZtHpCAULwc1mV3Ds357wxgdmiQFyCtwHCrLdbPTw1Ads8IPAxDIEw8g1 3vIv5CdlQu0LcODdVgBGakIuIOMyKtT1azu7/+sdK3SrXt8X/FT4+334z9FsgLMX0I55GVMlrGGw e9c8ylE89S6jJzF8c6C/oS8WXnQjHe1Xzq2xBmRW06r4j9tpa6r9psYH9SAkAj0qyyBADISplme5 Jn300f7J/Q4ChaAeCBBqLgRZDtkLiBbYm/i2RLzHJFBLAwQEwlBuM90NK7wKAAWOwb4DrbBrmpDA ki9HE3Ql67qFcvcWlArEB5YXtiyY7W68IAkwxgKfG43RmBbTZUXKRZxtkWhrCwcQFA3OIei6shCg OtIDpLHmK10PHlClQHjUa86dtqYCsooePDAFKMQMFb8NVBwcxVvLHmaIW8yz8CyfHzuHhIRHpmKP xjFauw0xYjNpGdCl+DlOtjCzwMAjKxhM1bLofC0yPM+Gy8IdiAECEowUrApzAWwIrlOZ7rK1xmZF NdgFBi+h7TaC3KkuB94rWF1Otuez4AHiAexr5NiI0ZsVkqgEIYg8Z3Q/KsZepyw4xTozTQFAr5pl iFC8R0WJS8USY9jxuwidbAVdgMc73cX/k8miHwgHdz//JJXZW+fvhk366CZENmjYBi9oyOfn5+co aLghaKQaaJQTaHAVs+bnDGhYBWhIV3mXRbxjEGhEEZADdqlLPOouEUo2aDw9jH12ciwgK2hoGAeN VvGsEJAGgcOmO5h0L1lTHNtL0CiZ4gUBYY4UbxWkXRgBfiTdt4KRWt47ynQIJEGiTdY19ANZlAVA N9l/hCcDhdKJVfx+GhkaFw9/A/6AwmGIFDet/HzmxoQeR0CzSRTcvpCkVbSfIN8Nk1YcjXAKGoQd oWwgi0odt3papmmazhcDiI+WneBNZJqkq6ZXaAwnNEjVbcp+BEcYa1vHl30k0lp9SBKNnqvKF/DG Mxg8fQC2BAJSY3V8JkqIU6aG21DmFjBvCYHGiOElww0IH9mGSE2/Wgh9QB+EF/4M/4vag8Mh234d Htv7f6+UPlpHO/t844CkNwt5W4a/4W81ai1HWLmgKYPBCAP4iwF1/8b7kPWZ9/8gzEdZA/k7+n3e QfdGMAzFqCpAEu6DPMV9AWj0NiAU/zTFpOmCxMwLvR9aMpyQg6T4MgAZ5jMgl/j8voh4hQmTV0Yh bScUhzcDaAQnO/EQVg8fCSVQfBCFEG7a7R67IyARzQ98Bw0kER9ZQ4z4zdg2BX1RcsOZjFd9D136 g8dKnUz2/34sLBsaebGHlzd1MwgDIOsKbJQM3d7CG4/3fNRsHgto63a3kY2VYwKzTmBqUB3JyYVG LTAZ8P5k5GXhIC1G8TvyODcP4QU2iDQZgwgDno+EJBAofBYW7C7hNfckFhIVfA2GDEGYHBsYmEGb BOsIxUGQoCGwIO3QX+Qu4nQhGUImk1kEtq90wcQOZa1WF62eJtBkllZHhgUVzvj9tmvDsxaEK0Qb aBTQ0Dv1OrzwYbEdWzZyw58DqwVkM2ZqVbOxTt8JqlnfB2NJ17AeaDDGBt0MEoUB58gQgKaofySc zgUGqSBLfQfGhmu/n38gAYC+qFNXu6x1JDBoYGM/x+eIUzNfiO02s33qTyb1Ujl59ECqr9A7cBDh 2hRnNkMD1Qlc5fA9sLOFvSvvEVNYC5od3iosFvvC7Gw2FPpZGRpQMwdtbTxw+1SsrNRc5ocC+HqT ZwoyqQa0e3IFqerSV9pR9wwi5ILff1FERpp65z0SHjDXvEScyVcFeyF+GEbUtFCLfngDczkGx+BE J5dAJ1k8J3DAhh04J0VAmblbcYIM7B6tFuhkMAP4aHD/szOE3VR17XsEG7FvywfMKxkCD2g0JyZs cOBrLnYjX94iBvsZrBUoDWgkDiA4IdjAlAj8UAc70EuER+KCEA+FwoQZjyDXhC9DOKxXYjJUpgxH YJhR/lyR3hFsygIJc1BIfiTjQRgy8P3GZgdeXhOWJlOgyWjLl/M8aJBY0p3MUGgRR0EaY/6vV+rX CjRGM0/aU7qiATgrqscEOIi+O7qmM5SesAbqIH3oSccniQPsgTuvfQ5qQ4Wz36p2HusOULDDFowT EQeC1gBu4iVsgCYAHlS3/wLwZn9g3uhEdDlISHQtCA50gbBAtBwE0LQf6gKfwQrPMOslJwRRIfTp ky/DgcGg6+8wrfn9bSYxiBaAZgEfCALPZJ3r5e1pdB0EdHQQd3Ve3DEiOAK3gsfX/7GIrlfV2JHL e/5CUhG/MtmL/ekjx1AMBybeekjDbSdoTOFWGF9PUAn6b1PRZ+uF4BL/IIoDQzx8dB73dBri/KWc +xY8XHUcEgprD4gB/weA/2C7VHzbiwYgk13DPHv2m8ps+Yu9i9NGigJCKvax7qUADHTiOAkNdevr 1SX0Bm2jTUFSf4vRSR3cStRoDudkddIXzjv7wOBG68s/yesnbqFAbfmwmwjrGToHi/H2lDJ123Q3 BQFKR3/VHHed2dH1RFQbw+kKSTwkpV0XbZJQCw9JgCH7Cf5EqTc+b1NC/zfHhimKHQEHKDPRd0Bo RxT3W7gL2XukOYlSeE48IHKRozc2fj10PTwrAzxjNTx/M4AtoHE8gAtBKWSybtEQAg5GWzzXfSHa p37GBAYNBkYHlnj3RAp0sgxfgCQGWGOQg6RpCqAKQZIBmaigCNtpoodbpFpQGCFqMLhjG65eUIDj BThE6hC+WAQLUKG+lX2886XiaaSAbqX+ikwNvF+ICv4PcAHp/vdfc8HhBMHuBAvOF4hKAYpIARgC PluWZQ8CBl4ZAopADAa33xXgP4pEBQxCA70YIrEVznjrBQwsxWQDgVcucA2CRYPoeLmIr8IEKGDs ASoVF/598GE9sgALcXImUFdf6K02AlzoXDkpkyEWwJmfNYtGQkrw/77+A4qEBSuIRDXzdbuNVUF6 Z6oLjlaXjjm4uAcGzktq1zAUkAH0Flpo1H0JOZcDGBHmdk/eDQR9DQ1DBApDDOtbi9b4NfiIDE5l S51MoYi52HINHaggNoYQXXsEcp7gbVefAbvwKURWr+d0KoifbYN2o3ME3T0IAvo9l7o1BEJ1HzwD EwSlVomGcwzhE3+lqkI5arTBXHc3+t6LnLe0wI2ftNBlY+Ug5ptQBbuhZ4xxD1IP2ChQBMWpQGa4 GuzotnhtTIdf06wUVl9vpw1VLQyqKP+3VWi7VqqxoBbVlRvAgccRsAcaiGyQFpqN7SZHHGiIFdcY Q7MGyaDyFny2LaxEEDNPXycb94COIppZT+38bboo5XiLuNto8Ck1VbMDkrFZ06K3vc0kVwXyuJgd QbPvvWoaVFcKyUav+0FVFICMIlJcX3BBTLlS3F98BblRY9G5hCNWBTRR5ibrdkZo+KtXVhhQDQUc 4GG0aTMJSMj3UhUr5PMOdIMR+MDDU0hFueGifZ8aAa8BfghFBw+MCsJoJHfAihvTQPiPiZ0P//HU srHKRppGfQaJtVoJOXgb3gn7c6ENbvh9RPiJvUT6Quw7c8AfXlkMQQuDfJLdCkv1TcONtU/0qMS3 q91edXOLsb8BP0W49+ACLW0FnyNhI2itBwwTDEB3u8FJ9RVQD/QiiBhOP/xmJ1e+Cs5YkS0nOJ0n iSPU6vxw6/3WOV2OxBdsNwmQ6FjrGKISlMAmPCFyQcMKGTG4ADSUOEexfnJW2IIW5whRKQ4mwgvY xRA4PZk6JFFuob2/qwXsBzJFIWKmx94ufOo9ZBScRgEnVfQI2sGA0n4lE42CyNYkDlgyeAlXgxQz SQIKdAoADcClWAPD05f/HEBz0hRUloPI/+usIhWl947CW4sL1eAJmXY/MEUbOaRiV8YHMB8iWtWA mvagy2z8Qj/AO/BXImPqR5aRbQgIWgxREA/foPvNjkiKBjwNdAyOCHV0BDwJ5mqJEhMw60ImKxEj zCr+NCWaDm5iRjI+PDqQDQraBvVmKgIEFz0POEAN9CWJOIQN//AQfCLaziZJzogQPoH5jY39XzFy vusBToCkEgBdzLlQB8IVVEEA/5ihtejTfkqpDwUxV7sOJDgxMkcNu3uVODp1YR7wI8VkpkYP3BFA 7IqeuUbSygFGdNJPiaZzTVgWwblhXUIfy8IfCkI713zqdQwCKEK69td1HQvjNz4KdfEFDCpdaqPo CQgwDa7rCxpiY64gCxwHBjUNHNEWVFaFQzRQDyPqxk6NCuENNtINAI6SNWP9hWq5DXWE80cEi8KK CusfpCjULTwHFzg8dRT8rG18Ej4fiKMV8YAiAAyBgSDbRj4MYuMGrPB0MnsQJIRpKNBRESwGMWsY cxVExK/pCIJEv0DrM26pxkpSsoqUIKm+0Vv5+gl1E0EHOX8Sg9KNBIAm/L+X1ERC0B4wfemAOS11 GWkd2dSj+lRatH+2gAZBeptIvbzo1CxyUzlCUBYwXdwqoLrfbORbhVYbQ10xJ/yz5pJDjBAuG+o9 AWYn3YqNBZPQFY55SQcxAFyAHxLlYIxAU5b0/SNyVYdqv+Visq4H2IP75Pwti4LIUuen1lNRQF/H DxaSAQQwdfjDeWHNAm+AvnhZO8ZZWpc93WyrE89IjONmvwXrdt8gTjGIvGh8BFc322zzzcQ0fAc9 K34vKyZ4ebaRPGxaPCvBRZPwjzE+u9UaYM23gQ5kNlRTNG6tTnMHv402+gCS5ztEMTFMPLLPnD3V ACzNJTQgsZHuWeG1AIaPqiILBh5bXj00jGqLqmXj49DrDdYbmg1CyWhvmfvn+HXsCOxHUejdBkIR 6+47wgEAgwcsRBEPAY/Tm6FykM8FEysGftGJyBBnfkYCSd51Rd6gKgVoLCrfEQ7Y/GqZfB93fRja JGBr1j6IEw4e91ngjOiEr/yqxpQ4h1FCkST+04WHT+m45HZQg9gqI99nQ8DcrrAqaKhSoC1MmmMX XP+YNSQX0IIG6Z/WAbGAszNX2R4HY0jJSmHw90GM2IcHEBBe1jj4tshE31cf0SbYmawVkkr8s+cj frxIeoIAFNwo0WQBe+xyAd/s6dLcV5848LwCj3p95z4ciL65VJxbUOB0K2oZLXIE2Q7c4bK5VJiq 3qn4Xf2xVrjtByD0sJ1LRMMeowDv9HUYunIAjsrKh1UbFoArSP/vMV7SXSdbD5T2FAMqIXBbDQxL Vuw9RZCTA+lR0Azs5gL5POz87PwFNG0eal+7hEBX1exdKEyM1pw6ewhzyciT8PB0JOwMxP8lS+7s dESLG4Xbdcch1I5DC98dukqD6ONA3b6qQkh0OAIuSNsEBYt0Zvhp/nKjH9CHD9PrJX5jc0MYsu9d JuvXaOwG0CbWgEX+NbEIAHRYjadkwADIN5wv9965eHwPL3dir4ClUDdOLaO7JGCPWRVd4geejudA M9ePaJF0YPc35/FBiIwF/J1APfdzEQA2X3wYJK4XV6Ae1aaOGaypiW1HgVkgqMSWEyQMIAkB7ywz WFmRu3T2gtt2QiGKefsR2Fx0FQRs8b3FLxjGhAUiXAUFT7PPAUOvXDiLCBvIYJErDQB/UDKYwM1p q5bBSFy/a5BWueJB4iuS2asOMVbClyEYVs2AG5vID4aVATtjY+QmnxksNwIxwEAPgI+OXxEADnSa 3h/gd6pGMUZmWEJgh0mqwRWOF12q8zRXVYnzdc4SvudSNos11k3WzYJNRsCtU5uzZRCl7Gka0/GR Aev4dFoCwMJ5woa+U1EdjfjKkkma7usooVP4COTlbFgXoV3WOV2CyyZVz5pY2oRdJJSVZGe/moXm KuUwuxcGQ5EIts29qPOrTqhXqg2ZkAAALzr2pVeYI3tAOJwFLfY7M0hHISQ2pxQ8sz3ND6iIJalZ IMeGdCAYDTAYI4MQeawlMQKoDyDIIMB8RHAIwXUPFjt3NvvXKGPXY3hZV/U1UDzAw4pN/RArtmpE DUOAC/peVlv8qMAtUQvXuIKBYi1yEA4XIlGhVd1mOidTZhZKDQMlZEwfw/CyoJNo4CdqICdI1gVj AF1+3KK/ALDSX4vP9/G4cxE9DQ9LACy44FqEetr8t5wjPFkhBXMHaIDr3F0T3qxcOK5QcwtYhLsL OWh0LCUgGmdX8nk8cyYkJzI1cImR/CYl3CVpcNwANxtUcwZgNXv22HUEZ95oaDssCdAZm8yRHi7X NnxQgfrCCn9SJifjnPCEfSkMg0FyKgsyPsnZkx5yFxIUCg+DqBq6Zig/xkfpQxweQt7cWYoCOGjY KzxyE7fddkpzZULQMOtBPwcDe3glN0homPf3NgQ4Yzu7bOtBWT8llFjyUpzAbJAzGAM0BAJ2qdxo SEdXS1ADJSIMOwMYlbtFwL4kJVgRMKRqGdUFA/n9MCs4KzjNJRx9gPz+BKjORGB4uU0OX59UwgWy /yX4eyUARWGGALIAJ4oiLAOIEqZpmuZQAISAfHh0mqZpmnBsaGRgXGmapmlYVFBMSJ37maZEQAAI FQcD+JqmaZYU7OTc1MxpmqZpxLy0rKSmaZqmnJSMhHyapmmadGxkXFRMaZqmaUQ4MCggpqBhphgA BJpld7oQEwgD+BPw6Gmapmng3NjQyKZpmqbAvLiwrNimaZqkoJSMhBNfNE1ntpcTA2xkWJqmO9tQ E6tAOzgwKH+QpmkgGAwMG9FBQkF5dtltAEUDvr75QQABQfL/7iqBBE9e+09B9UiMYPlADfv///8V KSgyYTEzLiYzICxhIiAvLy41YSMkYTM0L2EoAgVg/38FDhJhLC4lJG9MTEtlQQD7J+TtEQQTDUBC oUFOQEpARszr3pNmYVExJiwDMd2Qb/YFF0P3PEXsbBbswTMeDFEH9rfsDQYAT0VAQQCbhE9FFBEZ cahRxCPdZCPKoSdwYZ1c2WD/WycBc0jZYJPcMfxfJ6IRRHbyAP7/j6XhdSdgTUhDSATtP3QmlEKC YwL6sjQ3tyJWaWdMvl7r/7v/3wCtODMLgAN6Eziq4U6+AEYK7B+QKtkHwEH//f//jMfvAbjLo2h7 3/771Up2VxIGJK1P6yOosfzMGef///8O7D7vC9pgGpGTymfaspbnUknwK6NQjmY1YOX/////6kF4 XM+p1AutzJYHa1KtElBCmUSIvUSpebbI074jovT+//8/QPdhb1fUL9uMTA95nKA0DiFdsJoqJDMv JC3//4UA2CUtLba6/j7OY2QyY0Zkb3lr6+72OW9kIrSGVjc4by1mO1X/+/9/Iig1JEE55SuWF/aG qZoxYWWvj1b8gO5OPbS7/f//a4fGBlIHcelA1Ae8mdnBKO62BcrwGh3/liP/////HchjUNEq0jDZ vM8COOdgSfUII2RftwHyAYEQGx9n////z+uG96gcUW6XElUFQ8Cn4JmJupKmp4ygYJdGdv//X/6C xkyUtaxVt74bBESooui54q69mEPGyw1rzAP//8P/eLu+wLcwxmMg3E4sTXmkvAWr/+Xojp8KIQr/ n///+rcx/f7/hz/aabtm4KvEca6VRFzJRXiRlZikj/z//9iap7k9414kF+2FBWNotda+awLmYtV4 4dLz////vYIYGiTTjU3OPLWuvpAcxcQOP+kuoadtv1UCQP/////i4FBJD8M/ErZ0s3v8+pOWa9CS x6pGTVBXREhPVUVK/////1GPdZy+VkdLTlRBQENCQkVDQERQL8SaRERHRjZuQCQ1/////x+at7eg CC81LDUGQwIuL0kiTyW+rP6gEjUgDBTMLWXN/7/9/8CtfUR2EhcWK2EYcoH3GbHM/Pm8e3KasuqH xHS3////v0hAR3a4Pho5cg/BZEHKhxJqhhHMxXx5bpb+Ebf/1v/KBD2+MUW+VMVRRnqCyAQtTs// gbl6Bv///5gbmry/PZTMxHl5ESnTUGNputBs2VBuZTj/f/v/y81EHbaenr/BuB01um41TofFRGMd yd1EeEaa/////z86Nsp8YWgrJCs5Qr6WwoFCIyVGIazyPsoMJU7uiRAM/////ykZUGATjC/7mMx8 TDXChVljt6j7/psrQxIrQin/gVpdEv+3/7m+7Pqc/rgpTo7KPD3IHCX/QUuqUP/f4P8cMa6kPro/ ZcoUpTHCoz7MzUx5usvVVOD///+xtrc3unFQvgQxQyV4RD2dzGESEBEjeir3Hrr////f2ykYWRJR F1CemUIgNlk+507Bj2FEllygyB5FKHn///9v+IFTLSfxNil0NwxHvvKeWsSpeOzMBPlJWYVVVun/ t/itXK0rHRdbZUk+TrwmKZqNsGkXI7/9/397DUTVTtyt7OBaOgGtUT2oBxgS8kLtQexVSf/////l PVZLPkSf5+U/EJxBLXpgmJ/2h0oxN0TKR6ctghpq2V/4//9RuGVaTs2WFfd8mHFd1kI8LV7lzJe2 ok16t//////u5bgY4p1M+B3p1UHXynR5k7HDsJdreaIRxy55IJRNe9D///88UStQGHSDL8q8BBWG BFEFwkYRmCtAwSyM7P///79NTFt9wCeRASWYP/J6IcSBNVQrvr0VJYwlPSwZKUy/wf//l9ktHqK+ hL8fGsKENYiCqsyqS8qtwq1t//9b+watN2gHj9FZdVHT1lq+IHFKkXqSyBS5DP7/l/6GQBbKvq6H qHOBqVBxFk0WSRQYwgy1vsIkjt/gN80K9r36fqzFBA5FYc7/b/z/zL0lScpFgHoDTTUNcpOoP1DK NLl4Rdc1RAP/////lz+qLw49skJ0YLXEkz1MVmrErIK+NbBFejWQRTdgBFr/////14sYTDHSbAo/ SU1ORxKX//gX8SsYQ3pGPdhHf7ku9bb9////gT1XLCaOuchF2ALCulEs5Rwa9Cqt0bVBk6h+mY48 /7/9LzMQwsFCTszCT+lmAPacLLo8KsoGewwPfd9Y+P+JK3o56RFycm7W0IEMGAHMQraKVf////83 eBbVX014cT9RUS6sLprBdk2otnB6lzxGV8992QLy9P//v/CzPu08hp89z75H2zL2ljxFdzJytxgq FGlbK//f/v9J/1RXXXe3lbICtcxVcS0hVlw8TspQwoBFyBXE/63//5l8rKtzNH4tQJVaUkwYSCsn b1mo30nJdgJd6P///8KHRnqyPWfgbPn1MZq5YIVtgrAuJ/c4U3wYGPgF/l8PscR+A7RlEsocSRf1 ynEXrc/f+P8XRYy+Mk1JU1nKucrEvj2q5186dsoP/////8sFuEViMsBKWhrR7EBFMuBAqJPsupx3 TvdbbIZJxftE/////wlHTScv3uo1fUjE86mdfyHv4pOdhQNhTsPOt4IeJlYR/////yZSyxggjKo8 2CqeOSAbGHhXyb0/FarsR6C+PhgIyouA/////6BCzH1Ren88Uso/RQGOsV8/IHh4Scg9xJ15pw4P g3LG/////3mdMnS9RqCv8n5LRz3vmKpREkZDg6pSnlnFHklEq2oXN/7/peEdxLcqEqqeNWRnRqHK B6AsmbN1/0b//x4JeRctTykf1l91cSM/Yam7dnKcckti0f8L//9QTfSaLBPN+MYBTUc0RZWZGews qMqJMEBUL/////809+xcntlxNU8DS8K7AqtfH0aoSa5egQGquf91FsdIAv7G/0uNMU5qSViuS9FT H6DrvMg8sSlL0r/9N4U0rdbdR/LsflYXTwSvw9kMtL/B/9JR9WDzLE69xNXiyntiLfgyQP//twvO FkbluLhNmZo9WU/KCE+YRcLdvDlc/////06qU24yfFL/vzFsYSklUMa9LLNYWMUavY2NNL0cg6cP /y/1/zNQUlB3uJHxyIJqYyrZHx778JTDx7NIefC/wP/ZNQn/lXQEMjG2MIl9kRYXPPnMrf///7+E 3mtVwHkuP1qZSnrPZislfrawBR4yS+RKrOBx1Z30////CENFooL36MoaYyVlZxRKPWWnsfCfcZnP SynZe///y79BYb52nr72zkZyrNbCir54aRg/fnqcPWE6//+F/w36hbrssf8Nmf9Sef/2gS+d9NYs 2Cy4Gz1V/0v8/3BgvnWxNyC6YOQ0Q8qfS5c9gBJc7YA3Mv+/wf8EGOVnmRaJr4zckU60sXq0wqlC ECldecB4qfT/v+Cj92z9nfzpwr8BekdJP0L///+XTXf5nOPFZb4FQsK44U9LLf6dVRE8ER96sT8v /xv8/7GSJV4/dvo/ZBhL0l1U6lauuz4KPEAHBL/R//96rz2aAu1GKYVIbByfnR5fw3y3MFCBlUD/ hf//TXx+DYbOPlEp0R5Aon0vvSnaxJwhq26vwnj/1v//bTVL281dk+5HK68YSY1FTYlJQHRFvSbR p9b6//9btz9gulQQcz7bUb3B5US8Lwdf22wEAXnt3/i3rpeWcNGATCluyZPCLzdXIs7//y/0zilT XTdJ9ElxY7rYxexx92lUUcCDsWNT/////1ws9xMXBN6VF3OEqdkowpABQBivZnz7HIG/FZ4ShwSF /////0Icb9aKhC6HJ4Y1iTaIIIqkM/hWizOKJI0djAyPLJZt/////9YojiKRkG6TMnaK7yjbkpWU l2aWFpkc8p13mC9emyWawAv//50OnIwzmjRqn16eAgKhNKBJHJY13f//v16laqR+pxdOpqr77yqp Vqhuqwaqfq1emkSs////CyUTrrEvyRyw97XbLJJ0tG+3tjffubjZ5/cq/9Jf6LtSujXKBZZ7v216 BIH+R08Rv0v///+ubktcRJBZwTnCgwBPMlhVQDRupyxEOogFEdv/v8FPY+3Y7IA05oFZQUlJMaKK geAnJIW6//a0KQHnqY+WhhMkJig0CjJut///7TOBsAcvkkqzsjeRKCIkDCbb5xEzLm29of+//f82 dzd+vDI7DfgMqcbAiLFPCWyBbSFXG5HGqVUS//9/613kiH6mcRmBbCy0vDRIAR/AhWCCIkb2v24x /////7ornxydAMhHjgEeqjuYAc2g4nhWA8gAUYGGN4Y8VmhF/kb//0xfSk0NylxFC1683sInSUFP +aFeObqG/7/xtyoxksps7apZN1XaDCsOSim7Wjxjd/8Sf+Meoar2aivyQ6MHdJR9l/RahRbb/wb/ EUly7Y80/ilwIlwxPgTpiKzsAMxb/P/2bk2OEeJ3XVNDDve+FBTIL1nI5WH/f4mFYAzD8ieeK7A/ WTNc+f7yqLch/////+zjWswGTiZZer1Hj1w6STNLlQbISgZ3+vGa9z/IIF0k//8v/VFyrQYUSUkM 9mEUXWVdhk0RgnGt0OygZFHn/f///+U+SBabgcTxsarELhQvmZeYGfppNFblg+FWwcPbm3+B/y9L UbZGGsq6dQIlPpCfERGGUwsCSf+FC/0RbK3zLsHURTQ4FG18rT2gcUa80P//RBIpUVi/3OxgnF55 /dHfcfP0ZftA8S19gwuLS4AVVLtbgweI////CzYSy5nLuj2wt/4Agsq7ypCAoVEnSICoQ+DC2/// /+CETf+y6x4agBzk9J2+GKXCP01BNLOGB00DlJoSX/r/U+x3IachU4IKPkJve6yOghILOBQq9P+r DzGE97xc0QZ6uCRn/xf6W/gfjklCB4Ls0RVgNzoxyOI0RP////+VeQdJYovUm6lqiQqC7mvu9lMG 88gf9A6qeP7mBodOt/////96jj9HCp6AokISmpHZKr4DjsgXRTXzyooBdAEyoIH0GN/a6v+DJuSJ KpWELFBhPzzKDMBa+xX/////ekoBNXqDPQjZEdE5ib4f6PlTnDbaEVUYhHrKhraRh3L//zf45v/s tXjHPGdTdlFmPcpeLHnicEcofYAm/Ft8qyoMTxeLR+9SGEby2BcU////L5QGtnoW53NGCRYIeoA1 UHLi9CxKSosCgzZ4LbyJ/7/xFx8rgx9FzPPq6r5PHgthCqwJBsf/f6t/uuH6kUN5v7n4ZurX/Mcq UDs5dTsQOaH///+taRD1VUYYC7UIrOstsTRguKnApOeiXogcB///v1VcNUO2lAT1uPYsyMjehv4N dDSQwmdB499ooyukWSIctNVAqkeQiv+//X82XQw0rxFqXHC3Cj2thFe2k3CHgUUINLU7mv8v0OKv W617aRzML0VfhGGo9AtC+m///816DbqYrzUcerzfWSOSaB9Jx/o6WTSuN1Z/oxK3Cx/674RsIFmt fL4X+rf6ahks7tCfHlldDqH0fn9FD/////80mm07w2kSSsOFR5oSeCii8yF6AXJNKrk0A0YgejHm NP/G///feF9frMNXrBAW6NlKPJnl99u52k1ni+X0m///v/ScldvKDVTIDaDPi2UO5Zm9XvY799CZ uSVZgv7/pf+bXz2RZ1yd8B6Q2BaI0OcnZSJlnb+YXghf1OD/3wWRNQwWzr1Dvep3cogeyL1m+t/g L67J4HYbdV/5K8yhAH9lGpIv////FwQ9po9e1J1RIXNznUkCsZd6AkpkVebCPEQYPtv/Qv9GrPO1 C/LFwyl4TRJaEck/lnbQzf////8uhSPFRnAtgKdDF8DDDnzM/Uf+Vx+kQmMsJMqSMmwUMb/Fjf7R oZp4NAggNUkqbbgew1n/oNTb2x23vYk/T0TSU/XbG/3/36a3QltYSYMdqj/imhSjFZHcFYkVR0L/ f+tsyAEXrNuKSXpOW2KWL8yfQYn/9N/q//LQIT3eKSYhCUMINk0/DSHkAoL///93LnF6DFGeKcrx of9nBkn6VD2pYE1dGdxC0xT1HP/G/1vSwOhh+445iIhy9zVHQhfBQSata+n/F/44ur4cO21USNNd XRg5FxcnHlUdwxp53/r/f0O5Fgd6h58fOWqC10U/RDO1NQX8Pn4Mlv8v9P9kSBfcF92VEvaUrurq Udw8vTdbVFQZF0b/////kzZUcM3W4Q3vquoSJhgx/SPMtlWIAEUXd/w1SBEQblXV/xv8RFlsg1mn qdsxsCUnzSaF0RbhNyjwv7/t0bz8Uc0X6YPGrctAv/D//8WdnxGLAKmEyUAzq0QyWnkphi9LRlpq i8kU/7f//+IUS1kOzI8ir3GHE4FY0GUfvATNMU3mCyctrohf4P//n1dSDjSLT0KpJN07B/AYKZTM ERRjSvH0/i/0/0ET7PRjTfmEOPKrdttygXlCNWABwX1Cv/3/t0O4V0KCywm+MejeO+1N90aHiiFA o+hXX+Db/xxNqdALEhMi9xSOROK9YTisgL2u3+gv9IBVPwtZuQr0vlPDe0Spfa8v9f9b/3M9S76c /nqjgHGqW8tfW1LB/7/U/6DpHreY2FqIWjZLtr64YVgAQot1yU8Hyf//v8ShYh2FTr67TTT4vRfQ 2bEtJRmC8hHC/gX//y/1mlVBQnpAYgQmhgFSzR4/OuqMrkdJv5379f8L/9lNNxVzUcksTKop/Bbq 5EFLTWCfe0v///8vt9mqErLk49cPrBrETQTYUxg8BamM/MW4T9mkR/9S3/pEOTZTmvn0rWWIQbXS QuROYNXW/63+d22widk5Q8BUqk/RyqWob6FO9/4LF/iZS8s98dQmvmdNTMnMPrq3/f//pVJDNWgK NVZDSraXSsxytkKHqmlkuT4q/y/0S4iecp+qXEO2kmKevIP6j7xiv8L//9tKnkpWTp/0YrZKn8+e +RDLKtfM2a9CfP//rf+AnC/+sRhqDGkrRZKvykmSoUWtQpzB6PqBf4P//0qx80Inw3MfQONtxOhu THp7YsDXGQFitf3///9PR2SfI+hJWZkKypcaGaKDmle8ecYLNLcfiIM7NJn///8vdHYBUXktbG7w 7xb7UcqAQm2Y5CzAbkN+gKNCreP////IUzIOnpmjA6ErAQYe+lxAD1X7EaHkauieMwyS///fqlNV ZFcQcbO0y1VQyVVJADzJBy7TM7P/jX7rzAi8gmuEt1oXQ4IyYcdJIgNa/v9f6q2n6ECAW8JSueHx kMT6eBwwot6eN57X/L/UDZ4Par9VC8w1EEKWy0Xckfi/xRudS8lFjooztEYcngmAdZf////fQU5R +AOexGz393knR87rXlH8MGqm270Y+vlS+cH/v9T//IyRLgkzQis5GNUQNALxl0bOuRFKUm4gfOv/ /xljwWoVzlVHyPUBL1PNKhZUBxoSlXpEo/rW/2/xXAAS6K9ESUZ2tKL4NqB0huJWG/9vlCun4EFc KIG8wbYWvwK5RP4v/f+C32dOJ+BDWoDBxI/NiT7WuRjZoXKAgh1///b/rTLAoMTsNN6rwLhES1ck RFe5LDxN6f////8DVka/6FFkQs6fn0exvnxFUe01EQc6GTQ9ghAX/+EjF/+N3vq3NEpLGBnrHbOe 7VsRCfYdnnvf4hf4RCMZqk4KXxC+eWbpkbaZWjf6W/+BQh8Y+QnuSk+1fMfRK32bxi76////kpbM QFxRUBFuRRF1ts+vLFmSH0VOxOPqanEaug//F/43OXpgU86sxjxR36RXEW1XNDjKURbB9Lf47dYc a8N0EQRO0VieISQn36f/X+JvLCdhp0s2GRkbwFvi7RFaQFn9h+1b/P//UIkUTGWfOPFcVDdyFvkr acs8KBq/G4Nf+AUW+o15iVt6Y0MrqRuABqf///+XVWFoX5ApjOVQtBl7kIMO/yPUUWIfqxvESTKQ /V/6/5ZAkKuNLDL1EWCrBL12uq6cr07+jmFFUP+t/ktlcGqA5H0GJ8BRnuziNz2lCdj7/1/4agfM wwbyMfqes/tHEglrfUdFAZ5Cisk+jf7/fyy8SXOIJ7aYmgv1GitstJODHANO3nT/X+D/SDuAqv/X j0dchNVsKjX3DdZ6hWHKsvwl/////9vY5emXkHeJOVGSqUq3mrCc7szUV+VxXGNPFKlLytxB///C /2xgXOuRTW7xBAYOXan/TwEnNLrjCqszsVQt/19Y6LO3BOr9GDV2zMwE1ML3iupEpn+Jv/X3yCIJ xkWbE6b/MRBBgKspDDn/////NKjRJ2uhnUrrJKax7k1h1X5vDl2s97TUpLpRYRAdy5T//2//uFoK N8AOpzQTBahFcVbU7pqy0Q2uPLFztjytrcT/X+KGh8LhGuBQmry3x0j6oAYEaEb//9+6Ba2eqKn5 9PAmHkhDrX1wqnyRtyfnrK2qX+L/pTGxQnMOKbhfqu442c2NNR1qLlJf4P83PHOBpMkEpcMx/9Va Opy/y/+/wP9QPWyXnZdZTSGcR16rV+34IEQZYUkcpaH///9YL255qmc8MRhjNKTuFTdY4FQwKY1B QWthL/+/1H9Iv9qnac1RQKUgJQcoLSRYQb8fEiQ1////RkYuKC7yt+38ThYzKEZbAjNkSi6kHvcA Zn+pv9QGFbgqAi40TC3PnLeA9zNXBPD//y9WJCwxEWgpTAnwfpovcDEHdyRI0i/1L+0uImO/p5+a 30kkMjJVYJe4/f8yJAkgLyUOf/qEPkUkLyIg/i6/CYD/VkCtJTQtOQ8gLJb/v8B/JSUzgo9DpwSJ AOotlyecFSlHJT2jP9b///8biL8ssjE4DS5dDSgjMyAzOHPEbpwh2AC4IE4u9P//MxJJL0zB9iYT DiMrMFUEOcORX7wFJOtL/AUaLnkoVwvYXAIXIC3E3+D/f0qG9yRtAE4OMVsKJDhP5pgdrk515zX4 t3+JUUmxNjIxMzEnuj1tivN0sU//7nff0FFSdfMLeEVWSECDCVNMQzJJt79I/xn10jg4Lg1AQyJP s+UYZUNR/y/9BsdBJ4CPj81aRXJGGXYatxFNe6X+//9pUUYRz2RaR0ItbhhWYe1XQSX9X/FOSh28 cKv/xTkEJ2PRvzcgqkVieiFvJf3/Ly0DIPalKk0KAVeBQcEgukXNcUKPzIkDeUYUYb4hqGP/t20R bcwFgb6+FsKMvqpR0QDLe+P/jUcyRgZAmjRGyl/Cr71PM6z5QSvdDtgRUIEMMq4qDqUuwQcypXCI czNM4R3Yt7pJPcKONTXIhC+IwkL2hAw0YQAcTAv8t3/CgEPAvEGylcKQQMxVbsK8+U5K8Ubuy0MD lKS2qCKL/tL/DfRDwoNFyEbChkXCCDawQI6oDZfYuu8WH8i2+DWpyyltzUA2wcJv9bbBfkBWykbL HkVUqTb4/b8OgVHHhWi5waqpQLE7RMhpmLffGuX/TCNIgTUEyifMxXXfdoVxGOuyER9JvtclC9TL ///WTkkdnci4OEZO9kYGEQb4Fgmz7xQpN9u/MzdGyELCgkWqmRAtIKgCRAXmqvm+ALmQW6MDEyUx 2CFphqQ15z3XXGCb8MUxV/2LH4MMNkibqQe3Sar0IwB1QQoEEw+cj1H/F/YFDQ1BAAUXABEIA0EU ErnJB2saChYScx4xbYPVak3uTgANBlyvLWjwhyKBrGAsttUPSCgQDEHnarW2wALOvzsNqEr4LzAo LzUnAPMURVhFRIGAwBqNFggI5AEAMAoAJFEFv2kmIKgcAUZpbmRDRAGg8mxvc2UbRMzeFdRTaXpl F+9/+0xMEUEOTWFwVmlld09mD25vYW8OVW5tEC4DcnMibnfDL0tFbnYQb252q4qOXVYiYWIYOYi4 HUQMdmXa7pGKmA59VGltRirirLVXGgtRQ6LbuvexC3twXmctTMNuXyB+TGlick55QSH2TFC0UGMo S8ZEObb9YmFsQWwGY1hMYbc97FTTKk11A3goG5u1W2wXcmMPfrB0EAf751pWHUZDb3B5xURl2oc3 awaDFyVIYecLIN3CnUVTY9l2O/lsZW5U33BQL2gNYQsKw1crWEQds7dFRPFvypG2UMTJcHlNkWxb dmeCIk0TRXhpQkHxYt1ocWQf8b1ZwCb/L5mN94YNuwVlcKE2QjfiwsOwM25anGVJexFxosv7F2wg /F5yGFRvkxWGmaK4TKkOvCV7E2IRDQhja0OFb09EcgHjZGVDaKfcXURsNE1vQnl0IhIUJyKcnrmv tS0KY5g2KlKgsr0n4VRHUG9pKBlIe8Fm7XBGJly9ExmEQ5gw6DpuRUy4rDBpCWmcFqQiJgQ6TRgz 1zhDdRh9GTokOWFva6VEZSyVhCDFlWi1xx7jm8BnG0tleQxPcOvco2sxC0VqDoBWW70AGnZ1ZQ+L zNylhBEpdW0wDE+zzSa3P2TC+G2gomFuh3NlMIo3F2uMchD2B2lzZL32XAl6GfLOEBSieK5bUAgi OTehKzMqYSohAkoPZrNUzSABoVVcDxaw305CdWZmQQ8LTG939hm2I3d2SXKUI3cKhZtxWvTMDE2C wgCobVm2Tde32GJA/wQCEwtlWZZlNBcSEAOrZVmWDwkUczm//4S8PFBFTAED4AAPAQsBB6570mwT ciqAMgQQA4JsZ7GQNQsCMwSZW9LNBwzQHjR72RvYEAcGAMB5CECAW2R4AhgFRrjCditkeAEeLi/Y k6CYpHCQ6zZ/u7AEIyALYC5kYXRhmCPuQrrB+yIndkC9zWAbhS7lCQDDwAZ8vyl7NCdAG7B7DZQA AEpBPAkAAAD/AAAAAABgvgCQUACNvgCA//9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23Lt uAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UH ix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB /QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5 AQEAAIoHRyzoPAF394A/AXXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJ wHRFi18EjYQwFOUAAAHzUIPHCP+WjOUAAJWKB0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+WkOUAAAnA dAeJA4PDBOvY/5aU5QAAYekjRP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AwAAACAAAIAOAAAAkAAAgAAAAAAAAAAAAAAAAAAAAgABAAAAQAAAgAIAAABoAACAAAAAAAAAAAAA AAAAAAABAAkEAABYAAAA2PAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAgAAAAMTz AAAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA0AAAgKgAAIAAAAAAAAAAAAAAAAAAAAEACQQA AMAAAADw9AAAIgAAAAAAAAAAAAAAAQAwAODAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA //8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiIiIiIiIiIiIiIiIiIAAAI////////////////+A AACH///////////////3gAAAj3//////////////f4AAAI/3////////////9/+AAACP/3////// /////3//gAAAj//3//////////f//4AAAI///3////////9///+AAACP///3///////3////gAAA j///d3d3d3d3d3///4AAAI//939/f39/f393//+AAACP/3f39/f39/f393//gAAAj/d/f39/f39/ f393/4AAAId39/f39/f39/f393eAAACPf39/f39/f39/f39/gAAAj////////////////wAAAAj/ //////////////AAAAAAj/////////////8AAAAAAAj////////////wAAAAAAAAj/////////// AAAAAAAAAAj/////////8AAAAAAAAAAAj////////wAAAAAAAAAAAAj///////AAAAAAAAAAAAAA j/////8AAAAAAAAAAAAAAAiIiIiIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA////////////////wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAA A8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAfgAAAP8AAAH/gAAD/8AAB/ /gAA//8AAf//gAP//8AH///gD//////////////////IwwAAKAAAABAAAAAgAAAAAQAEAAAAAADA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA /wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj/////// AACI//////gAAI+P////jwAAj/j///j/AACPj4iIj48AAIj39/f3+AAAj39/f39/AAAI9/f39/AA AACPf39/AAAAAAj39/AAAAAAAIiIgAAAAAAAAAAAAAAAAAAAAAAAAP//AAD//wAAwAEAAMABAADA AQAAwAEAAMABAADAAQAAwAEAAMABAADgAwAA8AcAAPgPAAD8HwAA//8AAP//AADwxAAAAAABAAIA ICAQAAEABADoAgAAAQAQEBAAAQAEACgBAAACAAAAAAAAAAAAAAAAAAAAvPUAAIz1AAAAAAAAAAAA AAAAAADJ9QAAnPUAAAAAAAAAAAAAAAAAANb1AACk9QAAAAAAAAAAAAAAAAAA4fUAAKz1AAAAAAAA AAAAAAAAAADs9QAAtPUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9vUAAAT2AAAU9gAAAAAAACL2AAAA AAAAMPYAAAAAAAA49gAAAAAAADkAAIAAAAAAS0VSTkVMMzIuRExMAEFEVkFQSTMyLmRsbABNU1ZD UlQuZGxsAFVTRVIzMi5kbGwAV1MyXzMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVz cwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtleQAAAG1lbXNldAAAd3NwcmludGZBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK4+oML90ZcPrithc1F3pTtRplvd UYEV2FFiuiFRgDRmDoJYpI59p1ox1adPXW1vWjHVpzxdbW9d+32nWV1tb0SFoNwR1k/r8NZPLJjW SyL/1k8sn7r3Imlw1NuNcHjZ/yexHTIfSJ61cbATWxjm46le5tGCGObQgnz9oHnSTuejFQX2VuD6 DNHg/A3PKlIIz+U2HcL6wg+L+uPMKfrAAqxxEDx7ntXPG4Fv38ae1jrOnlNG3p79zdae9gbyntwC qm9qFOaAoLqYn1lgW59b5umAjio1nx34zJ9T5T2ApawXcHHXjJ83Y0mASCb8gAdjip82HQeASSTM n7fyeYA+Pf5w0/o+gJwWdJ87PiCA6g4Qnx0H158dCRqfku+9nwmgq2+KlLqf/XjSgE9tfJ/9eMKA TLHDgGyuLYBNzlufwUkSbjthhZ5G2sKeRtcLgd9c2Z4KjWqeCOVHnoLidIH+mCRxDWbrnsVVcIFp JSaeeIU7njG4xp54GCmBN0GwgW7fZ3AseveAHY7/n+KG9p8QTACAF4AAgBZeg4B/hBKf4EVF+7Ff 5J+e0CgLiKwJFHvyORR3URcLi3V8FFdlgAuCpXRw5gQInym6oYAn3vSfDsXFnyP3WZ/aqpiA1Wdm n4+fOHO7GaSc+JPWnIe3xYOBMZCcleAUnPibdZyHx7icYDMVbzgWo5/uFkuAf8I0n0bhM58LkEOf d/OKn1xVGYB7eidx+Z4BnnWhxJ48ZX2evksQgY2KZp4fpKOevkpQnjOwTYenpydoQY3daEGZinfD 5NjjiNX9aO8S2+OIOHp32EXecmHjdZ0pXliduy+pna5W052rTeqdCJe2nV0lkYJYEfpv4YWngCeh hp/QbG+flzZogDuwXJ/S5jSAO0u5gCbVSW/soaaAJE9qn4gsW4AE6jSf92xfgATquZ/fIEmAKVtX cB52k58isHSf1FgdgE2IQ4AvnbaAL5ytn/a114Aniulwjt8rn8kO9p9EcWCAtyZ0gM2L759V9Yaf shp1gEe9U/2BZ9MSR3JKEsatsRK9mQ8SZ1V1ma4q1Q24nJUSZVmOcgHfUZ3bvTGdRhFzgjA0053H +mid2xKEncQt5J1CwbBwQg9Qn6Q5m5+ZJbqfqkQcn4f2+4B7/JCAe/sLn5husnMhFF2DGPXBnGKa P1irY6ODGwFPThV8fYMZ5vgXDoeU8UD1tR6ZL4EeiltZHgck+R6oMUEBCzCvAZgn5Z+Fps/1OmCm W1wqZxoEHSca45ZtGvSVChr1ln1bXgB4GnnyR22BwBmd/p9BneWE1J3SOfKdu+PWnXnni524NP6C W6GROqDUQtXjUizVxC/i1XkglMrW+fDVjiXMypkmBhxddw0vwOxc366gwB+vN0XAD1YwwAcUvMAG 4evf85zTwA9WCnCF78GfYdD2n0sbWJ9Dyu2fQ/otn20s+59exb2A81xbIlLx1c2IkDPSm5FdzbbM y82dSHcfX51wzZjfTtIvSGNwLItAn+M1e5/iVyaAHWp4nwJyqp/qmfeAFqIDgP9JvHCXEoHeC1Nw n1nmLJ9NT21wb8DwcNTGoXBEiQmPhARUUEsBAhQACgAAAAAATjYCM8nmiWugcAAAoHAAAK8AAAAA AAAAAAAgAAAAAAAAAG1lc3NhZ2UuaHRtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC5waWZQSwUGAAAAAAEAAQDdAAAAbXEAAAAA ------=_NextPart_000_0010_2934553C.910D28F6 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_0010_2934553C.910D28F6-- From mpls-bounces@lists.ietf.org Tue Aug 02 10:55:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyBT-0006Ck-71; Tue, 02 Aug 2005 10:55:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzV9C-0004BR-Bb; Mon, 01 Aug 2005 03:55:42 -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 DAA02643; Mon, 1 Aug 2005 03:55:38 -0400 (EDT) Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzVfL-00027l-PI; Mon, 01 Aug 2005 04:28:59 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j717tFRr023780; Mon, 1 Aug 2005 15:55:15 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76])by rodin.i2r. a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j717tEac023762; Mon, 1 Aug 2005 15:55:14 +0800 (SGT) Received: from bearty1 ([192.168.152.200])by mailhost.lit.org.sg (Sun Java S ystem Messaging Server 6.1 HotFix 0.06(built Nov 11 2004)) with SMTP id <0I KJ00DKGA020200@mailhost.lit.org.sg>; Mon,01 Aug 2005 15:55:14 +0800 (SGT) Date: Mon, 01 Aug 2005 15:55:16 +0800 From: Boon Sain Yeo To: Message-id: <002301c5966e$5b735060$c898a8c0@bearty1> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.29 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:5 C:4 M:4 S:4 R:4 (1.5000 1.5000) X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 X-Mailman-Approved-At: Tue, 02 Aug 2005 10:55:56 -0400 Cc: Subject: [mpls] CFP - SensorWare 06 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0771774271==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0771774271== Content-type: multipart/alternative; boundary="Boundary_(ID_DwCuYlEEv7aT7u4VrVPOzQ)" This is a multi-part message in MIME format. --Boundary_(ID_DwCuYlEEv7aT7u4VrVPOzQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT (My apologies if you receive multiple copies of this message) *********************************************************** 1st International Workshop on Software for Sensor Networks (SensorWare) - CFP *********************************************************** Welcome to the 1st International Workshop on Software for Sensor Networks (SensorWare) to be held on the 8 January 2006. The workshop is held in conjunction with COMSWARE 2006 in the beautiful and historical city of New Delhi. Advances in technology have made deployment of miniature sensors a realistic proposition. These sensors are low-power, inexpensive, smart devices with multiple on-board sensors, and are connected through wireless links, so as to form a collaborative sensor network to perform a specific task. As a result, it opens up a new paradigm of ubiquitous computing and enables a range of applications that are previously unrealizable or too costly to be realized. However, given the limitation of on-board hardware, one of the key areas towards achieving superior performance is through the software implementation. The workshop is intended for the presentation and discussion of novel algorithms and software implementation for sensor networks. This workshop, intends to bring together engineering experts and academicians to discuss the current status, technical challenges, standards, fundamental issues, and future services and applications in the form of panels and technical presentation. Topics of interest include but are not limited to the following: Operating System Efficient algorithms Protocol design Performance analysis Performance related issues Sensor applications Deployment issues and scenarios Middleware Sensor security Sensor network design and modeling Workshop co-chairs: Nirmala Shenoy (ns@rit.edu), RIT, USA Boon Sain Yeo (boonyeo@ieee.org), Institute for Infocomm Research, Singapore TPC Members: Holger Karl, University of Paderborn, Germany, Ling-Jyh Chen, Academia Sinica, Taiwan Kui Wu, University of Victoria, Canada, Daeyoung Kim, ICU, Korea Leonard Barolli, Fukuoka Institute of Technology, Japan, Wei-Peng, Fujitsu Labs of America, USA Jason Redi, BBN Technologies, USA Biao Chen, Syracuse University, USA Hairong Qi, University of Tennessee, USA Xiaojun Cao, Rochester Institute of Technology, USA Xin Wang, University of Buffalo, USA James Minseok Kwon, RIT, USA Wenye Wang, North Carolina State University, USA Fei Hu, RIT, USA Robin Chellappa, Deakin Univeristy, Australia Technical Papers has to be submitted to the co-chairs at boonyeo@ieee.org. Papers should be written in English and should preferably follow the instructions in template.pdf. Preferred maximum paper length is 6 printed pages (10-point font) including figures. Important Dates: Paper Submission Deadline: 1 September 2005 Notification Acceptance/Rejection: 1 October 2005 Final Camera-Ready Paper Submission: 1 November 2005 Please visit the workshop website at http://www.sensorware.org for more info. We look forward to seeing you at SensorWare. Many thanks Best regards, Boon and Nirmala Workshop co-chairs --Boundary_(ID_DwCuYlEEv7aT7u4VrVPOzQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
 
(My apologies if you receive multiple = copies of=20 this message)
 
***********************************************************
1= st=20 International Workshop on Software for Sensor Networks (SensorWare) =96=20 CFP
***********************************************************
&nb= sp;
 
Welcome to the 1st International = Workshop on=20 Software for Sensor Networks (SensorWare) to be held on the 8 January = 2006. The=20 workshop is held in conjunction with COMSWARE 2006 in the beautiful and=20 historical city of New Delhi.
 
 
Advances in technology have made = deployment of=20 miniature sensors a realistic proposition. These sensors are low-power,=20 inexpensive, smart devices with multiple on-board sensors, and are = connected=20 through wireless links, so as to form a collaborative sensor network to = perform=20 a specific task. As a result, it opens up a new paradigm of ubiquitous = computing=20 and enables a range of applications that are previously unrealizable or = too=20 costly to be realized. However, given the limitation of on-board = hardware, one=20 of the key areas towards achieving superior performance is through the = software=20 implementation. The workshop is intended for the presentation and = discussion of=20 novel algorithms and software implementation for sensor networks. This = workshop,=20 intends to bring together engineering experts and academicians to = discuss the=20 current status, technical challenges, standards, fundamental issues, and = future=20 services and applications in the form of panels and technical=20 presentation.
 
 
 
Topics of interest include but are not = limited to=20 the following:
 
 
 
Operating System
Efficient = algorithms=20
Protocol design
Performance analysis
Performance related = issues=20
Sensor applications
Deployment issues and scenarios =
Middleware=20
Sensor security
Sensor network design and=20 modeling 
 
 
Workshop co-chairs:
 
Nirmala Shenoy (ns@rit.edu), RIT, USA
Boon Sain Yeo = (boonyeo@ieee.org), Institute for = Infocomm=20 Research, Singapore
 
 
 
TPC Members:
 
Holger Karl, University of Paderborn,=20 Germany,
Ling-Jyh Chen, Academia Sinica, Taiwan
Kui Wu, University = of=20 Victoria, Canada,
Daeyoung Kim, ICU, Korea
Leonard Barolli, = Fukuoka=20 Institute of Technology, Japan,
Wei-Peng, Fujitsu Labs of America,=20 USA
Jason Redi, BBN Technologies, USA      =
Biao=20 Chen, Syracuse University, USA
Hairong  Qi, University of = Tennessee,=20 USA
Xiaojun Cao, Rochester Institute of Technology, USA
Xin Wang,=20 University of Buffalo, USA
James Minseok Kwon, RIT, USA
Wenye = Wang, North=20 Carolina State University, USA
Fei Hu, RIT, USA
Robin Chellappa, = Deakin=20 Univeristy, Australia 
 
Technical Papers has to be submitted to = the=20 co-chairs at boonyeo@ieee.org.=20
 
Papers should be written in English and = should=20 preferably follow the instructions in template.pdf. Preferred maximum = paper=20 length is 6 printed pages (10-point font) including = figures.
 

Important Dates:
 
Paper Submission Deadline: 1 September=20 2005
Notification Acceptance/Rejection: 1 October 2005
Final = Camera-Ready=20 Paper Submission: 1 November 2005
 
Please visit the workshop website at http://www.sensorware.org for = more=20 info.
 
We look forward to seeing you at=20 SensorWare.
 
Many thanks
Best = regards,
 
Boon and Nirmala
Workshop=20 co-chairs
--Boundary_(ID_DwCuYlEEv7aT7u4VrVPOzQ)-- --===============0771774271== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0771774271==-- From mpls-bounces@lists.ietf.org Tue Aug 02 19:03:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E05n4-0001i4-Gx; Tue, 02 Aug 2005 19:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E05n1-0001en-T6 for mpls@megatron.ietf.org; Tue, 02 Aug 2005 19:03:15 -0400 Received: from smtpoutuk02.marconi.com (smtpoutuk02.marconi.com [128.87.251.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23763 for ; Tue, 2 Aug 2005 19:03:12 -0400 (EDT) Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j72N0Zkl007408 for ; Wed, 3 Aug 2005 00:02:35 +0100 (envelope-from Ingo.Krueger@marconi.com) From: "Ingo Krueger" To: "mpls" Message-ID: Date: Wed, 3 Aug 2005 01:01:28 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 03/08/2005 00:02:39 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Cc: Subject: [mpls] Ingo Krueger/MAIN/MC1 not in the Office this Week X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Ich werde ab 29.07.2005 nicht im B=FCro sein. Ich kehre zur=FCck am 15.08.2005. Hello, I'm not in the office. I'll be back on 15.08.2005 Kind regards Ingo Kr=FCger = _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Aug 03 01:20:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0BgJ-00039M-Fy; Wed, 03 Aug 2005 01:20:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0BgG-00034c-H9 for mpls@megatron.ietf.org; Wed, 03 Aug 2005 01:20:40 -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 BAA08719 for ; Wed, 3 Aug 2005 01:20:39 -0400 (EDT) Received: from concorde301.adptelecom.net ([212.180.41.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0CCt-0003cH-4K for mpls@ietf.org; Wed, 03 Aug 2005 01:54:23 -0400 Received: from WINBARRISTER (unknown [10.11.0.210]) by Concorde301.adptelecom.net (Postfix) with SMTP id D4D211C96DD; Wed, 3 Aug 2005 07:34:36 +0200 (CEST) Message-ID: <03b501c597eb$11219750$5719ff56@WINBARRISTER> From: "Seisho Yasukawa" To: Date: Wed, 3 Aug 2005 14:20:30 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Subject: [mpls] LDP multicast over P2MP TE LSPs X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1228105700==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1228105700== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B1_01C59836.80F56930" This is a multi-part message in MIME format. ------=_NextPart_000_03B1_01C59836.80F56930 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi, Unfortunately we did not get a chance to discuss draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt in the scheduled slot in the MPLS working group. We wanted to talk about the ways to manage label distribution for multicast LDP LSPs that are carried within P2MP TE LSP tunnels. These techniques are also applicable to multi-access links. The draft is available at http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt. It tries to set out some of the issues and techniques that are available. It also describes the different applicabilities of the techniques. We feel that there are a lot of possible solution for carrying LDP multicast LSPs within a P2MP TE LSP including "Upstream label allocation", "Upstream label suggestion" and "Stitching". We think we should continue the evaluation and its applicability in more detail. We plan to extend the current draft to include more details. Our plans and a summary of the material we already include can be seen in the slides we were going to present. These are available at http://www.olddog.co.uk/63/LDP-over-P2MP-rev-b.ppt We hope that the working group will review this draft and the slides and will send all comments to the mailing list. Please pay particular attention to the questions and proposals in the last two slides. Thank you, Seisho and Adrian ------=_NextPart_000_03B1_01C59836.80F56930 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi,

Unfortunately we=20 did not get a chance to=20 discuss
draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt in the = scheduled=20 slot
in the MPLS working group.

We wanted to talk about the = ways to=20 manage label distribution for
multicast LDP LSPs that are carried = within P2MP=20 TE LSP tunnels. These
techniques are also applicable to multi-access=20 links.

The draft is available at
http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-ldp-mcas= t-over-p2mp-lsps-00.txt.
It tries to set out some of the issues and techniques that = are=20 available.
It also describes the different applicabilities of the=20 techniques.

We feel that there are a lot of possible solution for = carrying LDP
multicast LSPs within a P2MP TE LSP including "Upstream = label=20 allocation",
"Upstream label suggestion" and "Stitching". We think we = should=20 continue
the evaluation and its applicability in more detail. We plan = to=20 extend the
current draft to include more details.

Our plans = and a=20 summary of the material we already include can be seen in
the slides = we were=20 going to present. These are available at
http://www.olddog.co.uk/63/LDP-over-P2MP-rev-b.ppt
We hope that the working group will review this draft and the = slides=20 and
will send all comments to the mailing list. Please pay=20 particular
attention to the questions and proposals in the last two=20 slides.

Thank you,
Seisho and=20 Adrian
------=_NextPart_000_03B1_01C59836.80F56930-- --===============1228105700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1228105700==-- From mpls-bounces@lists.ietf.org Wed Aug 03 12:44:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MLo-0002Fz-8k; Wed, 03 Aug 2005 12:44:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MLl-0002BJ-RX for mpls@megatron.ietf.org; Wed, 03 Aug 2005 12:44: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 MAA00272 for ; Wed, 3 Aug 2005 12:44:10 -0400 (EDT) Received: from evita2.cs.fredonia.edu ([141.238.30.15] helo=evita3.cs.fredonia.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0MsT-0001W7-Iu for mpls@ietf.org; Wed, 03 Aug 2005 13:18:02 -0400 Received: from zubairi (zubairi.cs.fredonia.edu [141.238.30.211]) by evita3.cs.fredonia.edu (8.10.2/8.10.2) with SMTP id j73Ghp414370 for ; Wed, 3 Aug 2005 12:43:53 -0400 Message-ID: <027201c5984a$895c3310$d31eee8d@ad.fredonia.edu> From: "Junaid Ahmed Zubairi" To: Date: Wed, 3 Aug 2005 12:43:49 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_026F_01C59828.FEDAC0B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 439b8e44c906b144bce6744ebb966e60 Cc: Subject: [mpls] invitation for participation in FIT'05 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junaid Ahmed Zubairi List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_026F_01C59828.FEDAC0B0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by evita3.cs.fredonia.edu id j73Ghp414370 Content-Transfer-Encoding: quoted-printable The FIT workshop has become a premier IT event in Pakistan. The 3rd FIT is taking place in Dec '05 the CFP is enclosed as well as reproduced below in plaintext. Kindly contribute to this event by sharing your research. Please note the deadline is by the end of this month. Call for Papers 3rd International Workshop on Frontiers of Information Technology (FIT 2005) Islamabad, Pakistan ? December 28 - 29, 2005 http://suraj.lums.edu.pk/fit In Co-operation with IEEE Islamabad and Lahore Sections Co-Sponsored by Higher Education Commission, Pakistan Since its inception in 2003, the International Workshop on Frontiers of Information Technology has emerged as a leading forum in Pakistan for IT professionals and researchers to discuss and present the latest resear= ch trends and results in the field of Information Technology (IT). FIT 2005, third in its series, promises to be another exciting event that will host leading IT researchers from across the globe and will provide opportunity to build international research collaborations The topics of interest include, but are not limited to: =A7 Communication and Networking =A7 IT Security =A7 Educational Technology =A7 IT Applications =A7 ICT in the Developing Countries =A7 Distributed and Collaborative Computing =A7 IT based Applications including digital government, e-commerce, e-learning and bioinformatics IT researchers and practitioners with an interest in any of the above IT research areas are invited to submit original unpublished papers describing their work (maximum 14 pages, single column single spaced) latest by August 30, 2005. Submitted papers will be accepted for presentation at the workshop on the basis of their originality and relevance using a peer-review process. In addition the workshop proceedings will include invited visionary papers and presentations from renowned researchers and practitioners in related IT areas. The schedule is as follows: Draft Paper Due: August 30, 2005 Notification of Acceptance October 14, 2005 Camera ready copy due November 14, 2005 For more information, please contact the conference designated email account fit@lums.edu.pk or see the conference website at http://suraj.lums.edu.pk/fit *********************************************************** Dr. Junaid Ahmed Zubairi Department of Computer Science SUNY at Fredonia, Fredonia, NY 14063, USA. Tel: (716)673-4694 WWW: http://www.cs.fredonia.edu/~zubairi Email: zubairi@fredonia.edu *********************************************************** ------=_NextPart_000_026F_01C59828.FEDAC0B0 Content-Type: application/pdf; name="FIT'05 CFP.pdf" Content-Disposition: attachment; filename="FIT'05 CFP.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIgDSXi48/TDQogDTEyIDAgb2JqDTw8DS9MZW5ndGggMTMgMCBSDS9GaWx0ZXIgL0Zs YXRlRGVjb2RlIA0+Pg1zdHJlYW0NCkiJ1FfZcts4Fv0C/wMe3V02jZ1AXqacxT3OdHo6LadSk8oL LNEWY4l0KGpSydfPxUZC1OZEUxPNg2VSwnJxcO655z6/OaFcZ0yinGKEbl6e4EwinFH446i5RycX VxgRmWEFv96dnOMMcyXheQwjCFMcHr+g0xdmNkN3dYP+NI9Fs/gF3Xw6IYTBYOSWdZ92ClZa+SnI DTpnVGSco3P4J5UbSmAw7vfO7SJhb0I49Qv5NZhbw8efaeqmu0kkTvL7njaTEJL9/nx1bLoBZnke I82xDJFeV23RVKYt68rM0Pu6eVhM60dUV+iqqau2hBOj+g6GAQJzNwzdFONpVc/q+6/+nBRrtzXR 9rQOkQwLwtPTfDy9ur5xoxmxN+CGrZw6I3lOQlAU+4VZJtKxNJfpmlh8/MWP4xlXw8uQVK9cBpEi U/YymMfkpbuK5DJIihWVrMMqp36h68XMzM2tmZwBFR7KRWsqvzbBKqORDRdXBAE73C3EOwoB/82N Vlk/dOU6ATS8EjODIw+PJbDwQ14W42J+WzSIurGSdssCUpiodGPlh/RBJsut7Egzpbau8pFS+dSF ktDPXTKtcJtqjxvtF7KjMOaRC4IwP/QMyICFXxPv3/ecKLf1OYVFZHfNJFwzRYR2d0xYngY1bdvH ZxcXi2VjPmWz5XyRFZNl9vhwcVe2bu1XIChMZ0BC4JZlJqEer0xL1BTo7uT5zQmDi5AcSaC5z/mT bTTbegSrWu4IxCZ/R5SeUzYTPFIWNdHxs0Ivao8Uz1SPK87FSi6euzH9EBeCiuthFbWhBrnzGf+l bKdejkSfkVFJPbY2Z0gUT4xVpy+vXr1CXeYgU03Q72ZaN54AuYOzD4OJPgwWGFCgUTG2YXjpldqm MUarGYy7eXQowkraSzqPQu82UpSliATYiOp1JMWtQ0wksTJMuj2FDjc4eoQw66aYoNsgjjrPtgLG ZCfIhIW0/nt5P4WkfjVZjj32L+r5vFws4LGXHZ+rUg9r0IbzA2k/oxMBbEQit9IzD28APUUzdELg ToFtg1c/1r4rh/fwXTPLTXgX0tJ98NqNnqL3v6LKHtbWRkgUru2nptRh0AdCuNN6ru2Ly6W322f5 PSS290oYs9NzOzvmYBwAv6ynIKgzTks+pV0B4jRk0m9FBdSfBSnL04KFmdKbqNNfMsZshTYOmvSW Tl9MTekTAJxBurYinlOnizCzZ3qy7LPNy1pZGNz8bgC9OQoAkhUAtUVOCLqGHhugJ+RKSf5IeT7M lYsrnkzqVC/PV3gK8sb7uigG2zAdLwlrHU75ssnQmwyh69lXszjzq/iTHYQKXDegvgkV5QgnOLYq MQRGDmlFdJeSWgVjczWrm3Ji0GU7M+Ctxk8MicqM0V0hUWVL0GpILgjRUTvIy7uq/DdYurL9eobe jS69ogp72weBRmw12cEkyE9vDY+ATFA8g60BOxHnWTKNsug6892ZRXuSwXqM45Ww32TRj9OkmBAs 42WAjQq3gV4vK1N6/w532J3SaUE/HnfjP8Do8izIvzU4B90adgK5g1dYhG5iJ9WjMEVFDB4xT5WN +Hp7+s83o8ub0VBXnwLzwIxeV4u2bJdt4dcajI1C2j3aRaGNeRIuXBPLgO24cA0Nx4Z0Yzw2DURw FuPc1DidPTES5bSmiwRuaxCJcg50NZSVnmPFMrA007+TLRyMrZY76i0HHWFDFVqvtxJ3oqRiL/Nn U983Zh7tq6CpNx3Qa62oOm7EwulK6+JZJMVhtYCDP+Gba4HXNS54MJVHoGuY55H0ROYk0bWpmZpb 9Nx8NmUgXu7M8EHYQCekdxUlzqk93j7xUFyk2PzuCZB0GTE6okNG2e6hQGsa6IDu8i9nw3r39PSn 1rzuOBgLLdww/TmNdSU82mJgKnNfzIuqRaNxWVTjYvHU3Ccy8beb4iCuCf2f5D4Wu60iP54sEL30 a5JkgS+16MPyFhSiywPVl6kfywOm2W6/yLR8il8UiV+U0S+OWtMWaJXDfxRfnhgZ1IadtpEpvtk2 yr6OqVjH/lU3D8i06Aqa27oqTW8f9aEyy2TiHjcUFiatU9jbx+GYfcSz0RXfyXLRNiW0crG05Fln mvaXln39WuwFT0PF2edo9iIhtjoyn2dMbHRkP6vgBM7aguMereDV00VZoctZUczRW/OtdOsocmi3 yvhWUxag4eum7OchI3pkhO5F6N3cNGhkyrvYrarDqjCjPDGIeWoQ4wD3b1/ygJHp4+WhFNdjyJvL pjGVr2CLmEQE00Q2t6TR3tBJ6ifJhrQnG/xkavYgWBYVPvg+FEsdPlCS8B7nx/BxOb9OsGV0PpZu f5iJTcOXZjl5rFsTip7eZK++Cx6qtpo/Dw/VG83fT4JH0QgPxTSBZ1QDa27RP6bBIkGdkYflI81p 7x03lDKa21K3t5SxTj04C+oBLdK4KCZldd+loXTG4r/SJ5Hd4kxt7H7AU4GQeJt7DQyRbN29/kS9 lr3+yZ4hl4u5aZezmZn6VcCpsMQAEKJYGl7HJEqsKTyISVzvttz0eNBjqkNPqAS9v+o5tD/o8lv5 zdsj3O/7g6gwkrjtTQnGeEb31zuqRZdh7tFm2PJ2Vo6ty45ekSVl5AlmEZaVIk0vTwW9cZXTZ5vN 5ncjQvE2lx94Qum6y/8pVLH640jrTom56pniZ4o+aVxIfVXLY1X7YJrWLKboErzUt3kZdXBPE/cD +oVVtlO+iDMI/x+ophVAyej0KJbB6d2YpvyMXptJXXv5EnRfon4/okSTpLfZkLpEM1t+d6WufYjm LyStZ0ByQE47MCQNMZuqsB1g3UD9NG0dC5/Ch/pvonBPktR8O5IQRY+nJRGsk7ycicQEGbAV6C/z 6XHZ+nVyd5SDYJEqaUs2pA+BPcjR1C9Ju4ZCUZJAM61NbCjyQT74UbchnN6GbU0TZxeIisnHSAgQ lKyzDcw1FQchL3DSVW3KMsHWu6r1AslYjBQmhEhHbVE0YEAhk+bzsoW3kEYqOzBopnd3W4TTI+q2 VGQLxQlZLpvyDv02NXcgM16U1D5bvRcXmu9uswjDR9Rm5Z0L1CsWenpnPgPH64ep8cgoejDNicx2 EoY413UkwDCZx3n+MUDzBvrP+dxM0PXsq/FuUYlDW1CwALs7L4LzI+q8ctH1ulroBJvlrWnMA2iw mfqqxLPDOirNdjdUR2OSBY6+F0ud0GUUW0vSuV0PQRdQsHyir9/niWU6feMp1tekbv5pNixXe22f wwNHYpMch0hfLytTTtAH+PD2HBrZ/ZT+jE7g/sGpihysA5rH1xyuBs3QCcXYbj14JYxan2G/oNK3 QcMvdG7BSKYMv/AbwrsQwsbVBRDe+wmCupOsf9FtGqcMv4hhC4kzPnjr9p+i97+iCg5uqYshF4hj YYIDk9ZpcG2fHXffro2OhxLOgDHBnQ/TtoxEtschkmTrjAcq0oS50OQwHct/WY0LVLYLZB8e27Ku 4Ak6JczOUDst0HXVFg34a/jBzND7unlYTOtHBMOumrpqy6JZoPrO3bhf/XwDEbach9uTx+O4PmF4 HP6f4qtkOXIbif4KjvaEmo2VS5/coZ6O6IvHE1aEL32hWCiJNlksc5Gsv58EkABBkVUlyQ7NpVsF ENvLl5nvZWv3YDjKgu5NC697vx32Xd/am5IbXd0fuqa7eyL35YDpKeMOlVAQz7iHzCTyXLe6vwPl 7Nco23EiH5IjgowjgCVpdLkzAgpOn9olECKNgcjZwrTR3Js2keZo2gD6X8o/6mEsD3iBLMnnxKbK d2NBcQWceglmYR3RjPMGbcTztmpB9p5LKIoR/XZDjn2318Ng+TCQ8rCDzQZd9tW9ocLYkV09VNPg po5m7jBaJjXlqIcxfH3p1sZ7RVzfIAena/3ogA1E9Ewce33YYUxNHi+spa/LMhhL+6apGT0LZJLx eQmTPnA8neMGT3TVNN2ot75P7Gvd7CBfyDZZHU/VophT30ptAzGbfIcwfP/RHcbnJnWib6QJv9hi t0MgXU08Sxxqqt0yBAsv9fXbjXvUslkwp3DNHTh1H6TRS9wUVW4mgp5mPMMN0oJj0ppCVfc7U7dM IRvAz+jhyq4tIu9lKa388RlWDcPnth60pe6tBtZ2EMme6L+qejRprR+AwFFaP89q0MVxWQmMuy/H S/jmUPPO1j+Zp4ncorgMFAdE3IGPddNgPxfLouWtjfvuvhvccyB92KIepRzBge7gGeKLGyR+nOZ7 AI2UVd9Bnpvcvms6i92O2GsApg/1Ti9QeynpUpvr50gnM55sNoVw/zTFXOmOx64fp0M9Ptn4TnVj eBK3tFCPqq5pytuutxMDQSxz23NDMnIm8BBe5Mi/GwBg7I515dS+msu8QdhfCtIaAXhju5SKnq2H EupGvoULL7y3ZbJgvmABBqYcQ9tvpp2+AmxGUsKWwH/S1G09Qhscu09IciBiKIGvjaiwCbIdUW59 DeiRZNO8cC+fudzU6Moo/kijxzLHr5ozlc+hjESRNXPU6wmmKFaG665tgTmVK9KG2z/r8REEEOQD FupsFsGXjz8NEDcdabsOID7cqv//E0DW0KWBrYUv3VATftXV1ENyYZv8B7CgC427SRa2pXHfDwtI Is8VqjCd/r2bKl9QnrdzlpmO8beREcVpteyAEcWGWn7XNJJZqDRpxgJLPh+PDeaRK5GZmiF5ZTUR +Rk1izjkzyXJu4LAC+8rgCnYh75d3xCnEckXEBQNdAtoqtfddBiNWPlHy4lIs0g5bxIl21DO74oR SwNGwvfqL2B7+hrakPFfUG2v5378oOFXe5ysIEPxEinfvwOWEqc1LqKl0pXGfd/m5E0fiyrvbTkA TnaplLNf+LC6zmfnPReex6sScDAqxbyLchRFQQCbUTlLxdfmq4hF7lK3SG7xlXwtcq2N85dkzBuo XX1Xj1Bj77oHkHAtKPMrovGOfCHU8gUIHxxQSzOAIvqHCqNFI9NF0ywcLryYbFvdV9qfqJQhy4UD RWxelAoqI1OoMkBg94eAtIxtZpbGO0JKuIdmzy6KWwLEGJDbuqu9vURNmgHLz8ZPJMFmXYwou6jQ BV8rdHNXGRR65tXwM2NhEv/Yl9VYGyaakcd6vIdhEilW+PkEKtqWU6gQUB3QZW47tNMvoeftl6An FDVVrnylkJIFBjL4CBDR5WCldH14QBlNhukWJDXpeiCwEQnT4TjdNvVw79AH8qZRUEWB2zvvBrvD LsfyCHi8xVPxgp9W4P4TtVLg5qEix6My5gvFTg8V1GnDWQhA3ROjiV9aJ0SysJzct4EUPBuWzx/a 8q+6nVrCJLz5Tg9XZIDDGm0c2tQe/K/hWFZ69/3HS4/P8pPqGr/I2Vpdmyrp3i6SjOIbmnI0DMSX LDP+1o3mMwK2xhSujkDpoQX6xSfyebqbhvEMZYOUxs0FxSYRg4f1Ee6X53jBKwJvUgkhv1q+jYE2 kEZNQ24hX6pKH804FIg3cSmVpwW6/yRbCXQDJ7IaFiqKtD6arDmMaLFGm9GGTsN9dySdE0zQ6eoB 0x3Y5lMIXAfxNfGVec8VPSml/RdiLaVtPJmIg97rRj+Uh8p1BKkMJ+YICWSITLIi99V5MvQlJTlq 3XsxzC72kahx4ZZp7q/wUOtHKJpdpQes9uncdzCwZoVXD0APx6Z80TG5TP3WyveSbxCV3c7W4kVs 3oS6SE8rd/xE0g3MOfW9OHV/WuLAc7WRKEhtJ1nmmouSulhGhHK3lWmvLMO+/lAPxrn1T9iD84RH tZizcHqR4wrMKdesZgaj34NwR/FkqS+hQgrMsYHs+669hBeLdXyxxVKernW8RYx5VQANJPU8OXSP B0DmfLt1byjorK4tk0XQYso/Avow0L80YEMTt10vsasL+japyMC/Rlq82CIIXWtxq6x81iQ8ZNoN 8HWAZ+4maBZQQaAp78FSdI/DJyymETlOXvVPuB5XUM/wdm34DXkLIWkI1HzrRdYDbgUMcMHsDiKR 0u7gfmdFAhrPLMisqFsPuBUwcE9++xc5mDqaKV6Q5X8Ww/hSYBSSIgUGwZBF8L/nVsaXYVDD4MRn RdF9Aa9C7BNFDcPd/84PsfOO5Utf7kfyi8kb8mXSLgJ5YfC5HAABDTqXUQT8QEAc3mLfvRoIIRB5 5vbwMfADAXPFrXpZD7w8CMt7MWlPeFkUltdhwpbwZRj8J2fiYGVBMC4IpVMbqFrWnD+tMLyRTJiU sb5Azfry1HF4zKmjbEPDTKH5xkAIpGenBXZOHWV1VpQpqwG34hWp4+5gUgeqz6tSx519LnVSuvJD th1lwRDyDH3Ez91Y7+vKSSJQPZ+tYAsagwllGu5LksZ4sBl6/B2Q9hmyGojKGFLSY+8HAtY+Q1YD Lwd/cS0mrUR4XcYg+ucy5iT82Qw/Cov/VGN3C0WKyYjrsM0s0U5hjtkY/evfNzOcGmkwP+/PZ+Sb M0Rww8Kol6wGQtw8CamRLXOGAB5qkRCrAbfiFRni7vCW5uLOPpchUJgi/xngs2Uo92Hi7k9A/bps dV/CJuXuCXzh8YnsJkwQbsrjy5tKQN4PBKR9QqwGomqFFPTY+4GAtU+I1cDLwV/e601NBeE/lyJn 8Gc09AFBpa9SD7pd5UmRR9AH6/dKFch4kp+VvYyptTn7+FV5BWIyO3WUgVRhAkX7164nbdcbi7Dv +tYW2CtybEC3aqAQaPjKGFB7O075bKGs78u9b6AZvkOjVja1JXYY0p/MOYIFm+816O9Kk50e6ruD Fc26LesmMlIfXgwRwHzBSDHKn+Fj4pix4ESAIPaksqq66YDiQBlSzeFjMwMUj7XCvh5/aqZ2SEBb J8c//GW54obTDK4A2OXU8JyaKwauGQqfuBtzd2MsYTTHyxGI2KC1dZ4Rho/6dgCPR8rxLTY0Ky64 qjyPTdUMAti3GIT7cTx++vhxmPry9yRC4yOgExDBHY1pgRZjit8SEG7PWp54IWsgSDCmMptqZrN5 x/NTKc4wKYCb0Rwr1Ml1Zs4vFKlMFntCW5UnjjszZS9po2AHZWH+jKdy0yS3V52YSnHm1NM2T/Nz W3u6Z7up7WdvP8BNbd7y9JQhQkrSzOSxIcEc6/8Bqbt8Og1lbmRzdHJlYW0NZW5kb2JqDTEzIDAg b2JqDTUzMTMNZW5kb2JqDTQgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVz b3VyY2VzIDw8DS9Gb250IDIyIDAgUg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgMTIgMCBS DT4+DWVuZG9iag0yMiAwIG9iag08PA0vRjAgNiAwIFINL0YxIDggMCBSDS9GMiAxMCAwIFINL0Yz IDE0IDAgUg0vRjQgMTYgMCBSDS9GNSAxOCAwIFINL0Y2IDIwIDAgUg0+Pg1lbmRvYmoNNiAwIG9i ag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUgL0YwDS9CYXNlRm9udCAv QXJpYWwsQm9sZA0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDI3OCAzMzMg NDc0IDU1NiA1NTYgODg5IDcyMiAyMzggMzMzIDMzMyAzODkgNTg0IDI3OCAzMzMgMjc4IDI3OCAN NTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDMzMyAzMzMgNTg0IDU4NCA1 ODQgNjExIA05NzUgNzIyIDcyMiA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTU2IDcyMiA2 MTEgODMzIDcyMiA3NzggDTY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgNjY3IDY2NyA2 MTEgMzMzIDI3OCAzMzMgNTg0IDU1NiANMzMzIDU1NiA2MTEgNTU2IDYxMSA1NTYgMzMzIDYxMSA2 MTEgMjc4IDI3OCA1NTYgMjc4IDg4OSA2MTEgNjExIA02MTEgNjExIDM4OSA1NTYgMzMzIDYxMSA1 NTYgNzc4IDU1NiA1NTYgNTAwIDM4OSAyODAgMzg5IDU4NCA3NTAgDTU1NiA3NTAgMjc4IDU1NiA1 MDAgMTAwMCA1NTYgNTU2IDMzMyAxMDAwIDY2NyAzMzMgMTAwMCA3NTAgNjExIDc1MCANNzUwIDI3 OCAyNzggNTAwIDUwMCAzNTAgNTU2IDEwMDAgMzMzIDEwMDAgNTU2IDMzMyA5NDQgNzUwIDUwMCA2 NjcgDTI3OCAzMzMgNTU2IDU1NiA1NTYgNTU2IDI4MCA1NTYgMzMzIDczNyAzNzAgNTU2IDU4NCAz MzMgNzM3IDU1MiANNDAwIDU0OSAzMzMgMzMzIDMzMyA1NzYgNTU2IDI3OCAzMzMgMzMzIDM2NSA1 NTYgODM0IDgzNCA4MzQgNjExIA03MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiAxMDAwIDcyMiA2Njcg NjY3IDY2NyA2NjcgMjc4IDI3OCAyNzggMjc4IA03MjIgNzIyIDc3OCA3NzggNzc4IDc3OCA3Nzgg NTg0IDc3OCA3MjIgNzIyIDcyMiA3MjIgNjY3IDY2NyA2MTEgDTU1NiA1NTYgNTU2IDU1NiA1NTYg NTU2IDg4OSA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggMjc4IDI3OCANNjExIDYxMSA2MTEg NjExIDYxMSA2MTEgNjExIDU0OSA2MTEgNjExIDYxMSA2MTEgNjExIDU1NiA2MTEgNTU2IA1dDS9F bmNvZGluZyAvV2luQW5zaUVuY29kaW5nDS9Gb250RGVzY3JpcHRvciA3IDAgUg0+Pg1lbmRvYmoN NyAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0b3INL0ZvbnROYW1lIC9BcmlhbCxCb2xkDS9G bGFncyAxNjQxNg0vRm9udEJCb3ggWyAtMjUwIC0yMTIgMTExOCAxMDAwIF0NL01pc3NpbmdXaWR0 aCAzMTANL1N0ZW1WIDE1Mw0vU3RlbUggMTUzDS9JdGFsaWNBbmdsZSAwDS9DYXBIZWlnaHQgOTA1 DS9YSGVpZ2h0IDQ1Mw0vQXNjZW50IDkwNQ0vRGVzY2VudCAtMjEyDS9MZWFkaW5nIDE1MA0vTWF4 V2lkdGggOTMyDS9BdmdXaWR0aCA0NzkNPj4NZW5kb2JqDTggMCBvYmoNPDwNL1R5cGUgL0ZvbnQN L1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GMQ0vQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW4sQm9s ZA0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDI1MCAzMzMgNTU1IDUwMCA1 MDAgMTAwMCA4MzMgMjc4IDMzMyAzMzMgNTAwIDU3MCAyNTAgMzMzIDI1MCAyNzggDTUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDU3MCA1NzAgNTcwIDUwMCAN OTMwIDcyMiA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3NzggMzg5IDUwMCA3NzggNjY3IDk0NCA3 MjIgNzc4IA02MTEgNzc4IDcyMiA1NTYgNjY3IDcyMiA3MjIgMTAwMCA3MjIgNzIyIDY2NyAzMzMg Mjc4IDMzMyA1ODEgNTAwIA0zMzMgNTAwIDU1NiA0NDQgNTU2IDQ0NCAzMzMgNTAwIDU1NiAyNzgg MzMzIDU1NiAyNzggODMzIDU1NiA1MDAgDTU1NiA1NTYgNDQ0IDM4OSAzMzMgNTU2IDUwMCA3MjIg NTAwIDUwMCA0NDQgMzk0IDIyMCAzOTQgNTIwIDc3OCANNTAwIDc3OCAzMzMgNTAwIDUwMCAxMDAw IDUwMCA1MDAgMzMzIDEwMDAgNTU2IDMzMyAxMDAwIDc3OCA2NjcgNzc4IA03NzggMzMzIDMzMyA1 MDAgNTAwIDM1MCA1MDAgMTAwMCAzMzMgMTAwMCAzODkgMzMzIDcyMiA3NzggNDQ0IDcyMiANMjUw IDMzMyA1MDAgNTAwIDUwMCA1MDAgMjIwIDUwMCAzMzMgNzQ3IDMwMCA1MDAgNTcwIDMzMyA3NDcg NTAwIA00MDAgNTQ5IDMwMCAzMDAgMzMzIDU3NiA1NDAgMjUwIDMzMyAzMDAgMzMwIDUwMCA3NTAg NzUwIDc1MCA1MDAgDTcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDEwMDAgNzIyIDY2NyA2NjcgNjY3 IDY2NyAzODkgMzg5IDM4OSAzODkgDTcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1NzAgNzc4 IDcyMiA3MjIgNzIyIDcyMiA3MjIgNjExIDU1NiANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNzIy IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgMjc4IDI3OCAyNzggMjc4IA01MDAgNTU2IDUwMCA1MDAgNTAw IDUwMCA1MDAgNTQ5IDUwMCA1NTYgNTU2IDU1NiA1NTYgNTAwIDU1NiA1MDAgDV0NL0VuY29kaW5n IC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDkgMCBSDT4+DWVuZG9iag05IDAgb2Jq DTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL1RpbWVzTmV3Um9tYW4sQm9sZA0v RmxhZ3MgMTY0MTgNL0ZvbnRCQm94IFsgLTI1MCAtMjE2IDExNzUgMTAwMCBdDS9NaXNzaW5nV2lk dGggMzI2DS9TdGVtViAxMzYNL1N0ZW1IIDEzNg0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDg5 MQ0vWEhlaWdodCA0NDYNL0FzY2VudCA4OTENL0Rlc2NlbnQgLTIxNg0vTGVhZGluZyAxNDkNL01h eFdpZHRoIDk3OQ0vQXZnV2lkdGggNDI3DT4+DWVuZG9iag0xMCAwIG9iag08PA0vVHlwZSAvRm9u dA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUgL0YyDS9CYXNlRm9udCAvQXJpYWxOYXJyb3csQm9s ZA0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDIyOCAyNzMgMzg5IDQ1NiA0 NTYgNzI5IDU5MiAxOTUgMjczIDI3MyAzMTkgNDc5IDIyOCAyNzMgMjI4IDIyOCANNDU2IDQ1NiA0 NTYgNDU2IDQ1NiA0NTYgNDU2IDQ1NiA0NTYgNDU2IDI3MyAyNzMgNDc5IDQ3OSA0NzkgNTAxIA04 MDAgNTkyIDU5MiA1OTIgNTkyIDU0NyA1MDEgNjM4IDU5MiAyMjggNDU2IDU5MiA1MDEgNjgzIDU5 MiA2MzggDTU0NyA2MzggNTkyIDU0NyA1MDEgNTkyIDU0NyA3NzQgNTQ3IDU0NyA1MDEgMjczIDIy OCAyNzMgNDc5IDQ1NiANMjczIDQ1NiA1MDEgNDU2IDUwMSA0NTYgMjczIDUwMSA1MDEgMjI4IDIy OCA0NTYgMjI4IDcyOSA1MDEgNTAxIA01MDEgNTAxIDMxOSA0NTYgMjczIDUwMSA0NTYgNjM4IDQ1 NiA0NTYgNDEwIDMxOSAyMzAgMzE5IDQ3OSAyMjggDTQ1NiAyMjggMjI4IDQ1NiA0MTAgODIwIDQ1 NiA0NTYgMjczIDgyMCA1NDcgMjczIDgyMCAyMjggNTAxIDIyOCANMjI4IDIyOCAyMjggNDEwIDQx MCAyODcgNDU2IDgyMCAyNzMgODIwIDQ1NiAyNzMgNzc0IDIyOCA0MTAgNTQ3IA00NTYgMjczIDQ1 NiA0NTYgNDU2IDQ1NiAyMzAgNDU2IDI3MyA2MDQgMzAzIDQ1NiA0NzkgMjczIDYwNCA1MDAgDTQw MCA1NDkgMjczIDI3MyAyNzMgNTc2IDQ1NiAyNzMgMjczIDI3MyAyOTkgNDU2IDY4NCA2ODQgNjg0 IDUwMSANNTkyIDU5MiA1OTIgNTkyIDU5MiA1OTIgODIwIDU5MiA1NDcgNTQ3IDU0NyA1NDcgMjI4 IDIyOCAyMjggMjI4IA01OTIgNTkyIDYzOCA2MzggNjM4IDYzOCA2MzggNDc5IDYzOCA1OTIgNTky IDU5MiA1OTIgNTQ3IDU0NyA1MDEgDTQ1NiA0NTYgNDU2IDQ1NiA0NTYgNDU2IDcyOSA0NTYgNDU2 IDQ1NiA0NTYgNDU2IDIyOCAyMjggMjI4IDIyOCANNTAxIDUwMSA1MDEgNTAxIDUwMSA1MDEgNTAx IDU0OSA1MDEgNTAxIDUwMSA1MDEgNTAxIDQ1NiA1MDEgNDU2IA1dDS9FbmNvZGluZyAvV2luQW5z aUVuY29kaW5nDS9Gb250RGVzY3JpcHRvciAxMSAwIFINPj4NZW5kb2JqDTExIDAgb2JqDTw8DS9U eXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL0FyaWFsTmFycm93LEJvbGQNL0ZsYWdzIDE2 NDE2DS9Gb250QkJveCBbIC0yNTAgLTIxMCA5NDEgMTAwMCBdDS9NaXNzaW5nV2lkdGggMjYxDS9T dGVtViAxMjUNL1N0ZW1IIDEyNQ0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDkzMw0vWEhlaWdo dCA0NjcNL0FzY2VudCA5MzMNL0Rlc2NlbnQgLTIxMA0vTGVhZGluZyAxNDMNL01heFdpZHRoIDc4 NA0vQXZnV2lkdGggMzkyDT4+DWVuZG9iag0xNCAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlw ZSAvVHJ1ZVR5cGUNL05hbWUgL0YzDS9CYXNlRm9udCAvRUZPQ0pPK1dpbmdkaW5ncw0vRmlyc3RD aGFyIDMwDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDUwMCA1MDAgMTAwMCAxMDMwIDExNDUgMTMw MSAxMzQ0IDg5NCAxMjE3IDQ1OCAxMDg0IDg5MiAxMTMyIDExMzIgMTE3MSAxMTcxIA0xNDQxIDE0 NDMgMTA5NiAxMzQzIDY5OSA2OTkgODkyIDU1NCA2MDIgMTA3MiA5NDggMTA3OCA5MzkgODkxIDg5 MiA4OTIgDTg5MSA5MTAgOTEwIDU4NyA3OTMgNjc0IDY3NCA5NDIgOTQyIDU0OSA1NDkgODkyIDg0 MyA4NDMgODQzIDExMTEgDTY2MCA4NDkgMTA4OSA4ODggODgwIDY1MCA4MTMgNzQ3IDc0NyA3MjMg NjkzIDc5NCA4ODUgODkyIDg5NiA4OTEgDTExNTYgMTA1NCA5NjQgMTA5MCA5NDEgOTMzIDk0NiAx MDI1IDkyOSAxMDk2IDEwNjUgNzgwIDEwNTAgMTI3MSA3NDcgOTUzIA03NDcgODkxIDg5MSA4OTEg ODkxIDQ1OCA3NDcgOTg2IDg5MSA1NzggMTA2MCAxMDYwIDg5MSA4OTIgODkyIDUzMCANNTMwIDUw MCA4OTIgODkyIDg5MiA4OTIgODkyIDg5MiA4OTIgODkyIDg5MiA4OTIgODkyIDg5MiA4OTIgODky IA04OTIgODkyIDg5MiA4OTIgODkyIDg5MiA4OTIgODkyIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw MCAxMDAwIDEwMDAgMTAwMCANMzEzIDQ1OCAzMTMgODkxIDg5MSA4OTEgODkxIDg5MSA5NTMgNDU4 IDg5MSA4OTEgODkxIDg5MSA4OTEgODkxIA04OTEgODkxIDg5MSA4OTEgODkxIDg5MSA4OTEgODkx IDg5MSA4OTEgODkxIDg5MSA4OTEgODkxIDg5MSA4OTEgDTg5MSA4OTEgODkxIDg5MSA4OTEgODkx IDg5MSA4OTEgODkxIDEwNDggMTA0OCAxMDQ4IDEwNDggMTAwMCAxMDAwIDEwMDAgDTEwMDAgMTAw MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTI1MyAxMjUzIDc5NCA3OTQgODkxIDg5MSA4OTEg ODkxIDg5MSANODkxIDk3OSA5NzkgODkxIDg5MSA3NzYgNzc2IDc3NiA3NzYgMTA2NyAxMDY3IDg5 MSA4OTEgODczIDg3MyA4NzMgDTg3MyA4OTEgODkxIDgxMSA4MTEgMTA2MCA4MTEgNzgyIDc4MiA3 ODIgNzgyIDQ4MiAzODUgNjM1IDc4NiA4OTIgDTg5MiAxMDM1IF0NL0ZvbnREZXNjcmlwdG9yIDE1 IDAgUg0+Pg1lbmRvYmoNMTUgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Gb250TmFt ZSAvRUZPQ0pPK1dpbmdkaW5ncw0vRmxhZ3MgNA0vRm9udEJCb3ggWyAtMjUwIC0yMTEgMTc0MCAx MDAwIF0NL01pc3NpbmdXaWR0aCA4OTYNL1N0ZW1WIDE2Mg0vU3RlbUggMTYyDS9JdGFsaWNBbmds ZSAwDS9DYXBIZWlnaHQgODk5DS9YSGVpZ2h0IDQ1MA0vQXNjZW50IDg5OQ0vRGVzY2VudCAtMjEx DS9MZWFkaW5nIDExMA0vTWF4V2lkdGggMTQ1MA0vQXZnV2lkdGggODkwDS9Gb250RmlsZTIgMjMg MCBSDT4+DWVuZG9iag0yMyAwIG9iag08PA0vRmlsdGVyIC9GbGF0ZURlY29kZSANL0xlbmd0aCAy NCAwIFINL0xlbmd0aDEgMjYgMCBSDT4+DXN0cmVhbQ0KSInEVWlQVUcW/rrvxirKJoLLxSeIsvnc UEBEeQ8Vo4KggEt8rIKAIBCCG0HRoKBGI5q4o1GDay6iBo0xBgUx7klMNG6xihlTmWFiakycqqkZ 5tyHcXSq/D391Xvd5/S5p8/aDQbAEeUQEDslPniwsaWtijj36Dc9LS+lIOyXi+EAGwwSSCspVo8G HzgAiERLoZkFc/MuPA3TANtc4s2Zm7sw899PR1SQwsv0/ZKsjJT0S5WZCUCXcUQPzyKGs4vdOqKX Et0vK6+4dMLYqtVE7yb9q3Lz01Lcot2CAOcBdGZLXkppgTBdHgi4/ELy6vyUvIzV//zdC3B1AjyM BflFxcm5oYlAQCRgt6KgMKNgysX+c+ioC6QvAUzpzdZDItuuideI4/7HjHRBddA3XjMmxasqIp+o Tzpkf7YXRsXItPL/bnMw6+xKQaHBPOkn4zmTZp3LXtWo04IoyYqNrZ29g2MXp67dnF1c3dy7e/Tw 9OrZq3cf1buvoZ+Pb3+/AQP9AwKDggcZBw8ZOmx4SPioiNGRY8ZGmczR48ZPiJn4xqTJU2Ljpi5a tuLdytWr1qyt3lI1x5IybXp8AlLT0jMy52Zlz8vJzZufX7CgsKj4rZK3E5OSZ8ycNfvN0oXLFy9Z WvZOecXKde+t3/D+xppNmz/4cOu27Tt27qrdveejvfv2f1x34OChw0eOfqLVH2s4fuLkp42nTn92 5vOzX5z7sun8heaWi62Xvrp85eq16zdufv3Nt7e++/72nR/u3rv/4OGPI0aGhj2CyP5MnsoQyVv+ pOxJR0cHQFEs12drDGQ0QS8lkYIvQ4ENbGEHezhQDXaBE7qiG5zhQpF1gzu6wwM94Akv9EQv9EYf qPBGXxjQDz7wRX/4YQAGwh8BCEQQgjEIRgzGEAzFMAxHCMIxChEYjUiMwVhEwQQzojEO4zEBMZiI NzAJkzEFsYjDVCzCMqzAu6jEaqzCGqxFNbagCnNgQQqmYTriQWFGGtKRgUzMRRayMQ85yEUe5iMf BViAQhShGG+hBG8jEUlIxgzMxCzMxpsoxUIsx2IswVKU4R3quwqsxDq8h/XYgPexETXYhM34AB9i K7ZhO3ZgJ3ahFruxBx9hL/ZhPz5GHQ7gIA7hMI7gKD6BhnocQwOO4wRO4lM04hRO4zOcwec4iy9w Dl9S5M/jAprRgotoxSV8hcu4gqu4huu4gZv4Gt/gW9zCd/get3EHP+Au3QP38QAP8SNGYCRCEYZH r22a/9e4+dodIyGNJfFlfAattlHmjBRVI2XPSHmtQQ1v6JShikmjGBqpJh5LrVRBhVb+EMqTkWrm H6yOqkLnhCOV9vUKaKY5gvbSaGZWHTVsjXVeSjVUg195A2/iTdbd0aQ3RpfoBG+QWomv66ug7D1g 50hmsTX3p3BT/4o011BmnzE/QjX7E2vnscRl+vmkJ4eka8jes5SlvzNXFsGq2BmScebLrLZ0nlZO Ms2Em1YtOiaxXJbPCtlq0tnGBT6MtObzVbyWa7xJSBYjpFbZWQ5RckkLdTD1aTfyUNc2mSo/lbDg hdZO3GCcxbEElsU2s1qyoZm1E57yQD6aoq5jk2ARHcSfpBxpD6FVnqbssJFJt97/ntTPPtSr4dSV MdSBel/Noy7Usfh5lyx/Xv0HqMJPUxXTmVSXD/CMouNE0P0KYSNZIiGZUMjK2AqKR/VLWMu2swZ2 muy7zG7xPuR1J3LJ+04rK/hWfpxf5lf4Q97Gf+a/ChBshTlCqlAk7BMOCteF6+J4sVbcLd4T70lM 0qyRcpZd5dlyNWGNYqvkKCuUDcoO5aRdEN1cPnQnhZNXieTVQvJkCd0oVdas1RP0Pj1BXfiz7geh 47knOkYyE4tm0wjJbAazsDxWxEpfeLSX7Wd17Dj5cotwm91lj9hf2N+seMZl7s79X/gXy+N5Is/h m/kWvp0foops4Gf4bf6AfGzjv5GP9oKz4Cb0FsxCNCFBmCmUChXCEaFJuCu0U94cxFFihDhNnE2+ t4ht4k+USS4Jko80TAolZEnzpTKpWtpJFd0utcsO1qg4yy5ymFwp75Ib5DvyvxQ3xV3pSwhSjEq8 kquUKAeVNuWxzWHbMbbZtoV2AXSXDaJb69Vxgqr7PJ8tB8OT3aVqWCA4kZSq9x53UHJts3mDbp0S z/woU/fxTLDFRLEFicJM5Eqpgr3yV9SxInEZOyRE0025TylhZwSL0C7sk3zksM548q3CQWWhYlEe k6VPhY1SlhLExkjVrI6Ppo4uZHH4nf1GN/cgFPOBdHfSy8BK6N2qsTnMHKnXmnkfVi3tEY6JtYJZ KmMDKINeUquwkl4gN3rX/Oi9kgiukCJDRoQMHTLYOCg4KDDAf+AAv/6+Pv0Mfb3VPr179fTy7OHR 3d3N1cW5W1enLo4O9na2NoosiQJnCDAboi2q5mvRRF/D+PGBOm1IIUbKSwyLphIr+lUZTbVYxdRX JSNJMvN/JCM7JSNfSLKuajjCAwNUs0HVrpoMaiObEZdE67UmQ7KqtVvXk6xr0ddKOBLh7U1fqGaP LJOqMYtq1qJLsqrMFhPpq7e3izJEZdgFBqDezp6W9rTSog0F9Sw6glkXPNocWs9h40hWaTEGk1mb YDDpJmiCjzklXYuNSzKbvLy9kwMDNBaVZkjVYBirOflbRRBlPUaTozTFeoyarbuDarU+4FzVmsau SLX4O6Qb0lNmJWlCSrJ+Rjd/bZzBpI1b1OYRGNDI9ickabZRjQwJSacQ01FeP6HcZErWT3OOSqq0 incn8e6L2ryEKrNHtqqTVVWVqlYbl/Tyrrf+n5xMSgMDJk5N8iarDeb/sF99sW0kZXwcO7GdpI1L 6+h0ATHBpJTGtZuW6NoK2rQhuSahakhDLxFCzXp3bO9lvePbXcc1x0NOAhXc8nCi6B7hdCBUpEjO FaFWOnRFqFKlE0Knq0CATnc64AHpyluFDmjD75tdO38oDQhekGj67f7mm2++/zOevcIpjJk5FQGU hp7IwkniUZh+wCI1RpyFZ3kjnjqVKtafXUCxnqw32Eyt/9UnJ0durr3LJsd4fXYu1d840Zea1z77 4dU9rD5Tuz4xwic2zxxIryZ2+Zle3dkTgO4dG4FozSmkxAnB62aqQ+RRagIt0uA6hydzqUbbwBF6 iCOsrh+BGP7Nh5BRE/lbqCeOUSHaBxIpXr/P0Aipe+9v5mgBp2MgcZ8RpHZptRzmm7gxONjYv586 JTqK0sKz42o8fCC91JhKlRO8MYWUsek5LJo/lkXK+/upypdvjLAcBo3lz8/5Y85yfa+ykezgfKNt gWZuNWeSX6CZ5eZMa/lCCu38I3WZTzZie1v/exK9u8eKxxqh3sdMC38e22eMr0baB+rTc3u1+uW+ vQv1K/MozTi2Yr0+nuLj9YW6dmNtOZfiiVR9dWqqXh5baIZ0Y+3W5b7GyJX5YghJbRz2s9HYPToX 7mub91FbX3j+AH5Ul3G3XsbVIoyrdWqkJ3o3FLkbegXfP2usfS18M/QHxrIP7yXusRN/wnPo4OFd /bsG+nf1L4fZg+U29pC13/nLkeXIHbqqr4Rea3sQ6YauPT9hobanEGM4pEPBPfwfOrgbS1fapiE0 /aDhf+60LbO3pt4ev9Dz6fuxvpg6w7+/8q2H9F59I3qXsYfTne9EhzDsDj6P8IwOPZxmrOsKY2u/ 6HznHz6b3oswioq+KhgjnbHjbDK+j13tNEG32GR0L7saf42thH/IbsdwHY5+jK3EewK64FPXJdAV thK7zVY6X2cr7S/5RLIRCXoTc7hwRb/NJmPfhc6vAvf784oIPw0+KHKdrXTMYb3wKfoNnyKGTyTf 8To736TY7yB3Grw3YOPHmO8DdYH3KfBewDvJrnZMsKtNW+0fBHQHBJ87vgh+MvBjv+9LfAS64HcU +mI38UZ80SroRYwP4237sca+hvWfwTvPrncOsq9HkDuipi3kc3ILHdlEz0Pm+S25+C8Trqwr4Wt+ zMrOVvqOT9vJRUju9xtlQolg7k3gnkfqVhTKbeFd+uey/xrFclsInyIxv3+HHkedHejPDr/mqu6b 9f6qhX8ZUDDuGN5MsbpPrfm/bqYW/yvsNhHVWOGTeG+g8G+ZHk4yPfY0LuaM7f3/H/6O/0//0fn6 XqibZdk32U78YiSAjuIgfj9yQX30MfaJ0G9ap3DZP6PVM4GRj9vw67Ic4DD4lwIcAX4pwO04438Q 4A7wrwc4Cms/C3AMl+K/BTjOPhpKBLiz/XuhbIC72KGOtwLczQ5F22GRRegDsjv6lMJRiiI6qnAc Uu9GzwU4xDhOQx+3sZ2xJj8MvhbgCPALAW5nT8ReDnAH+DcDHGVO7NcBjrF98akAx9nxuBvgzq7T 8dUAdzFjzwcB7mZG8ksKd5LPyZ8q3EU+J3+ucLfiv61wgvxM/lHh3cAfSv5Z4T0k0xtXuI/W9iYV /ojiDyj8cVrbO0Q41qv4Jwh3K7u9U6OyXHPMQtHj1/jQ0aOHDuAxzM+YuiNdmff4qHTKGX7SsvgM Sbl8RrjCWRJGxl9wkBYM8dlaWfBz0qp4prTdNJ+w9UevGhs/Ozp5dvAZ0y4YIHdGFCqW5mxlbx2f F44LzfxQZnh469xsUXAMDFl1uSULkpsuPnk8RzNESXMWucxviUc6GrmZWefCfVlwtHKxNuVg9Wlp lQSU2AYfLWqOBXzKLAhLVgNbvmGelzZiqwpHcEO4ZsEWBs/V+DY6uGnv6KTUqUlKX4aT3g3aJEpi 2ppl1bitlaD1cxXdNDQ+oavsnnQcBJtW6895muNyT3JdlsqWKAnb4x60BSs8cdFTmnleK5nQB/9o 2oXaptOOm0GBlKE0d4R0CpptfpkGZMARltBc+GDaqkO45m7IZysZ+2bPfDKtVHtFRzSjKTtyyTQE 6oEclKRtyooLJ1rZcoVH9TEpLlgqO+gT24M+pQkhYY2KTNqC9EG2DH8lcqPYFU843K25nij5uaZl wk+DklZVNXWIV9CBiAEL8pouXJVzpFoD+ebz0uHTo2lObnrSSfNFUctJzTGIhdVp6il9MYeypCkc gxuOuQS2YbqLwvNIQMM20DXX9YdlR9lLI/cX01x4eiZN2asKbAy8183mTYsyZhmIDfqkXlEBwLBm Wv4zJy8KMKp+o6e5bpnlwDuKu6ohBzmNHMlg93HNMExq8vSGdjVt3aog9YHhqukVeU7iQXtFSSNN pGw9s6iSmUf6bB3huBW9qPx3TL9EUlp+1ot4uNQ7GlniBYtSEDhZJo6rm64rKbicoPTlZCmH6aLQ F3kQ2YbElCSKstEps6QV4HfLAaGhzr57yqyF7YISoRNKOfhEyjxH4jBQlQ/EhK2bjm6h62yk19GU HDrQEjqZoW7RStRdFIwKS1XPkTkN2UM1LViANHYHdhM2MkSVGHAFW75ITTUtTb9//fUGHPCHiCjv iOcqtD/zFVuZpJJs6ND15kSuJc0FGaDtraFe2Eib3C03jQX59x5xOiFMCdk80qWpY4P06nAnX7HI tqH5nkBdVagfAvLcMGkF+WqYjgicpQnXq1kU5zi6dklzTOHV/FBLZU33qDi5imUJz6+BQFoWg4NK OnTCqK6m01q5uO4cHdlKX+tMKAhZEp5j6twvGyXluQocp1JIq1ZQRyFOv4JvTTmHszBT9LzysWy2 Wq1mSs1zKoOWznpOBe6WRVZlJlttZiq7/YrWSZlFMxjFLLOZZA4rMY1Z7Bzz8LZxGdbAM9go5sqs BmyyAitilrNroCFcco6yQ+xAgIbBOwMZHZKSuaC8kh1VusssA3wS+i28Z1q6XDUSeAtILeFpKMl1 CwdbFobAm4UnZUhx+CmhqwIdJpANDWlwJ4D0f8vWGBtnZ+HlJJ6D7BlI25A3grerVhRgx1L52E56 u/nzyrYb+MyRvwwyN7ztullEQFH7MwZWV1U8FlABxMGnsQbyYEGDjFAVddgieFSNx9dHqlXNbGYe KetnnyySbBk+1diU6gyyfVpVpKQyzIMeIv1F5YUV8E+pegjleXVLXBsj5rBJnvh1q6q8kaSh9JAO W1WQsxy84P+hH1zZ3cE6W123vrLZfRmVAd/fv7Nene2RHEVY791pg3alwyZnkW0QJ063FsakM+E4 g22OaDJM6N0ddnZmND2zuzoytsk555wzJpmcc845/hGoqu6enZV0PHxAejRd3V1dXeGtqtbBuqU2 S1iWJ/hjzZgeW10vJyQFtB9KpC4jeo7dS+l0biO7UbvfZGQudxUSaz41Jv/HEmMlmvCe0W3xjoLW ZrLvdGaKNYqsfsZ/7rS22u71NN9/zGbQ3CLWk21nyweicbR0ttpxFuTiZ0Vzbf0QCfpdDVmXnYPx uR8ZF1AUrli6UG5wWvPIt+yNTSbSJuINZfPD4GAsXIz2kjiNJ/Zji/UtqvyJqngZmzL5ahsBo99c JxOlsc10F7NUZDv9jNzM+je1uJlzlxK/XDTZpb9CIl7HtbtNLaBhLnueq6y9kV7aGmjiYG5gTARi zRznufWZGevW9yXi60tnKK84Ds6bhazzyojO7BK2UttHHJe5e6OqUwFx+jZbNqrohBINzqaJ5Q4l u0cSj6KS4NluEAiC9MJuJuedfRsW9zOhmI/7xEaFval4MK7mB1nbl5xxGIsFL7nNVq7JAVk3j4Cx 2JMzdZp9MhNPb8i99Yq+IbbEtJbt8Z2L91T0Y5t8oYxHjtnety6VP5RImEq+cY7qGkmn5A4a2opY t3gqEoZSHVJLub4yl+1ZfxnNDsKsyaVIPBcIZ2Cjo6VKDWv+z61kl0Wp+LiO9aGldFV3vMomRnpc oWDRk1nFo6Uyask1FznfRn7DWjumrznNORBI/1yM2cGIGYtM9V88FQkGBtbf+z2gpAMP93hvbm1s u4vJIlMTxqJbXNOskJpnXgbznF+UpiQSEXEGguhQ+pRBby4nnDxTA2PxhLPG1RZP4m1ywEVmHq15 7rE+vqwPrNxMkKerumV6h+lNpiMr2/GcNLNe2i4/rCrVGVqNFupv/f7QeqC+m9sM5nGHJKrq5lK8 Mn9Ruj51UA09qHIaXKfVuUUMuO7t2fwKbb89l3ezfZYt4r/4H99OJpqpldu36PJqrw2nb2C905f3 rrM7rL0L532FIzT/j8D5PJRc79veYfwaCs7UHs+6E4zXXfsq43iesrV2IrpEUt12F6LKmPNEmssc X/SNhbeeB8qiZbTnRcU3uDfMvFZfVSHGefEgz7lX9ly//e+EgbyIxrKWC2bWF7LNIYXR59k3xIaN OL9EBrVXoXn7DRZsm3vOs++yofS9bOmSpU36ncrvMXnjLb6njtkqvSmalda7nMObNcxs2q5Ux9Tm /+WO/W/KTVsZQpK/uXRl7T/ROe1J5Tt4j/1Z/5/VdMyDeP9JNN+6uOdJJEPaSc95w6El+fn3xcR3 0M+/zIBDOIwjWEYDTbTQxgo66GIVaziKG+A8nI8b4ka4MW6Cm+JmuDlugVviVrg1boPbYh23w+1x B9wRd8KdcRdcgAtxV9wNG7g7jmET98BxbOEEergI27gnLsa9cAnujfvgvrgf7o+TuBQPwAPxIDwY p/AQnMZleCgehstxBa7Ew3EGj8Aj8Sg8Go/BY3EVHofH4wl4Ip6EJ+MpeCqeBg8+AoRQ6GOAISI8 HSPEGCNBigw7yKFRoMQEU8ywi7N4Bp6JZ+HZeA6ei+fh+bga1+BavAAvxIvwYrwEL8XL8HK8Aq/E q/BqvAavxevwerwBb8Sb8Ga8BW/F2/B2vAPvxLvwbrwH78X78H58AB/Eh/BhfAQfxcfwcXwCn8Sn 8Glch8/gs/gcPo8v4Hp8EV/Cl/EVfBVfw9fxDXwT38K38R18F9/D9/ED/BA/wo/xE/wUP8PP8Qv8 Er/Cr/Eb/Ba/w+/xB/wRf8Kf8Rf8FX/D3/GPZZ15gWpkKgmiuKWDSOs010cdEZRFESWDtVx5IY2D 2NNa6SO+iuMjfpqOGoGXhLFaK1SssmGaKJ3GUcjTIW1oVQRRHnRVMlFxminfC0arbtLP06RYG3tR 7KezfuwNwmmyWpuWmdmcpVnSj2l6tD4l5kY/jUOVr5iBJCar/ShWhRfHhZoVx7v12cLWiQ7PAs+P ElW0h2mZi2Gtkdr1Uy8Pu+O01GrLJ+PTpO3TqSyNkuJQFrSGtB1GetTskw3Z7gk7XtQqvEzlSsVt NnyaR4VarahY9Ytlnk0a/E1HzWJYjv0ya8sYptNkhTeygjk7hsyjwbBoGZo4DUFmy9LQi4u2HpMV fQpfJ1FlkXsx023y6zRhigI09o/qURnHQZ5q7XN4jrBrm+SrxEuKlhflWewlqqXLRA/JG82QHEmO ausknRLrSLVmYy8f+XHYCoYqYKJDAXKLTLv1rtySlkVMgjoy0UOPjDN0oOIiCgzTmNRXWnV04eVp P/QmEZ9WxJMUvNbcjZJdLxkcSsfL0yF5ddnLI6UbhVfmpW4M1DhKIsZeoPLDsUqXJ1E+SJfjyM+9 pg7SPIvSjvYGg4iERaVuB16WR7SetLydUpYaWUTX6VVvTHHT5NKoiINObba2U6aFCv047hdk3aqb 5jxrkhWqKFTXjgL7tl9SLnj9RFXU1FF6Tqm1CTmISZ+Qm+yZThemes9ULQdE5w1yFeGtGaTjMSnb Okv4J611k0PMYzGVOeGLMMlUq08oN0Q0MTw6mgmPVhOVCKUYcsKURE6Q2eq4G6JksmIvYdLeQ2S3 uoomHXeb0PZC5rd3Mn91LU+qm/mAu1wuqHiaXEpitWXHnh23l3MqTFvy7cl3u8Nfk7xbBJl8oIo1 w2zwSKWkPqWcampGBck2Y8+O25RCsy3+nOBPj9HuRHQrmnMyH1KulbrniO1WnJ5VyUD1HLHdooxm bG+1JQWYWqE8LDwhW0M1M7tpYJc6YRpSkWL6RLXao1I8IDmEUlGxmhqLWkGpMy6FbUccb82sTss7 pcp3V6zpJGuFP8aGNsU0DeI0GLUppIbqSEQNvcIBdSTF0/JSOC2vRNPSEkzLzLF0gh1Dl/BccXeL qYqdwFUvz8WhXAePd9wsp2IudJnJxoqdVOu8WmZ2PWdytVqn81ZSLnR3p4ziwgb8aH1CIGtzpgXB lNLVUklFaVWtqYbJ7oZJbTMzi1qthGSfKfodQ0opbw+ph27x6opQstgUkss7j9IITHzktCFNIzB0 mdl9ZqXOlPtGolBGopAkUUZmMyvJ1I7KjNrOySoee5WY3lxMz4rpVWJ6VkzPiulZMT2qTD6LaPhy /DA1t2XT2GTZyiwzXjrsJ1P6U4d9TaNWDT/09PC4GbY604ha5FTH6SA92V06dYremOef1zp5ev36 Q9vXnd6i4WoZ/tMH3bxEFYVxHD/nOnoeR9NpHIZLt9Jp3A1ubKFhyp1rkXIXTYyLuSLkW0EQ1Cpw 4yaEII1DrdUkzak0j00vk7QIev0HDKz+jrb2u/cZECm88J0P8zyXw5yRG8wL5hlTZtaZJ8wKs8wM M0PMJcZjXGaAOc+cYxqYGFPHSPcy/I1+oZ/oB/qE3qI3aAttog1URutoGS2hRTSP7qIpdDU6c4uP 3mSeM0+ZNWaVWWIuMHmmn+llFFPPWIxwXbiHdtF39A19RV/QO/QaVdBL9Bg9RDNoeqg71Zhq7NFV eccdVnpF6UdKLyh9S+mbSl9X+prSY0qPKh0oXVKddIY66DSdpBNkU5pSlKQEtVAzxYmogWJkkSBh 2up8yy960jcfp4Q/2WH+FLNVGb8yauqznjRJX/gjnm16c8a6h98/UqrK/W0pH8w5JjlYei+k3J9b cGoGgUjn/n3sQ9/8wswH0S57hMLn2Ypq/6zCaRFTHU11ONXR1JavCqLbn7g/fkr85+CDRx65PfTm xRvhdQulbRJeMDjGVqymOO4z7mQCL524PRBdri9jzzo7MSHLoikXmOasZ46hcNWV78qHq5iIVi0Y t9ZW9mxfxtmR5doqgfFx/JV/ARQtnbENZW5kc3RyZWFtDWVuZG9iag0yNCAwIG9iag03NDU3DWVu ZG9iag0yNiAwIG9iag0xNDg3Mg1lbmRvYmoNMjUgMCBvYmoNMA1lbmRvYmoNMjcgMCBvYmoNMA1l bmRvYmoNMTYgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9G NA0vQmFzZUZvbnQgL0FyaWFsDS9GaXJzdENoYXIgMzINL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsg Mjc4IDI3OCAzNTUgNTU2IDU1NiA4ODkgNjY3IDE5MSAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAy NzggMjc4IA01NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCA1 ODQgNTg0IDU4NCA1NTYgDTEwMTUgNjY3IDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzgg NTAwIDY2NyA1NTYgODMzIDcyMiA3NzggDTY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQg NjY3IDY2NyA2MTEgMjc4IDI3OCAyNzggNDY5IDU1NiANMzMzIDU1NiA1NTYgNTAwIDU1NiA1NTYg Mjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgzMyA1NTYgNTU2IA01NTYgNTU2IDMzMyA1MDAg Mjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAwIDMzNCAyNjAgMzM0IDU4NCA3NTAgDTU1NiA3NTAg MjIyIDU1NiAzMzMgMTAwMCA1NTYgNTU2IDMzMyAxMDAwIDY2NyAzMzMgMTAwMCA3NTAgNjExIDc1 MCANNzUwIDIyMiAyMjIgMzMzIDMzMyAzNTAgNTU2IDEwMDAgMzMzIDEwMDAgNTAwIDMzMyA5NDQg NzUwIDUwMCA2NjcgDTI3OCAzMzMgNTU2IDU1NiA1NTYgNTU2IDI2MCA1NTYgMzMzIDczNyAzNzAg NTU2IDU4NCAzMzMgNzM3IDU1MiANNDAwIDU0OSAzMzMgMzMzIDMzMyA1NzYgNTM3IDI3OCAzMzMg MzMzIDM2NSA1NTYgODM0IDgzNCA4MzQgNjExIA02NjcgNjY3IDY2NyA2NjcgNjY3IDY2NyAxMDAw IDcyMiA2NjcgNjY3IDY2NyA2NjcgMjc4IDI3OCAyNzggMjc4IA03MjIgNzIyIDc3OCA3NzggNzc4 IDc3OCA3NzggNTg0IDc3OCA3MjIgNzIyIDcyMiA3MjIgNjY3IDY2NyA2MTEgDTU1NiA1NTYgNTU2 IDU1NiA1NTYgNTU2IDg4OSA1MDAgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggMjc4IDI3OCANNTU2 IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU0OSA2MTEgNTU2IDU1NiA1NTYgNTU2IDUwMCA1NTYg NTAwIA1dDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDS9Gb250RGVzY3JpcHRvciAxNyAwIFIN Pj4NZW5kb2JqDTE3IDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL0Fy aWFsDS9GbGFncyAzMg0vRm9udEJCb3ggWyAtMjUwIC0yMTIgMTIwNSAxMDAwIF0NL01pc3NpbmdX aWR0aCAyNzUNL1N0ZW1WIDgwDS9TdGVtSCA4MA0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDkw NQ0vWEhlaWdodCA0NTMNL0FzY2VudCA5MDUNL0Rlc2NlbnQgLTIxMg0vTGVhZGluZyAxNTANL01h eFdpZHRoIDEwMDQNL0F2Z1dpZHRoIDQ0MQ0+Pg1lbmRvYmoNMTggMCBvYmoNPDwNL1R5cGUgL0Zv bnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GNQ0vQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW4N L0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyAyNTAgMzMzIDQwOCA1MDAgNTAw IDgzMyA3NzggMTgwIDMzMyAzMzMgNTAwIDU2NCAyNTAgMzMzIDI1MCAyNzggDTUwMCA1MDAgNTAw IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDU2NCA1NjQgNTY0IDQ0NCANOTIx IDcyMiA2NjcgNjY3IDcyMiA2MTEgNTU2IDcyMiA3MjIgMzMzIDM4OSA3MjIgNjExIDg4OSA3MjIg NzIyIA01NTYgNzIyIDY2NyA1NTYgNjExIDcyMiA3MjIgOTQ0IDcyMiA3MjIgNjExIDMzMyAyNzgg MzMzIDQ2OSA1MDAgDTMzMyA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzgg NTAwIDI3OCA3NzggNTAwIDUwMCANNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAg NTAwIDQ0NCA0ODAgMjAwIDQ4MCA1NDEgNzc4IA01MDAgNzc4IDMzMyA1MDAgNDQ0IDEwMDAgNTAw IDUwMCAzMzMgMTAwMCA1NTYgMzMzIDg4OSA3NzggNjExIDc3OCANNzc4IDMzMyAzMzMgNDQ0IDQ0 NCAzNTAgNTAwIDEwMDAgMzMzIDk4MCAzODkgMzMzIDcyMiA3NzggNDQ0IDcyMiANMjUwIDMzMyA1 MDAgNTAwIDUwMCA1MDAgMjAwIDUwMCAzMzMgNzYwIDI3NiA1MDAgNTY0IDMzMyA3NjAgNTAwIA00 MDAgNTQ5IDMwMCAzMDAgMzMzIDU3NiA0NTMgMjUwIDMzMyAzMDAgMzEwIDUwMCA3NTAgNzUwIDc1 MCA0NDQgDTcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDg4OSA2NjcgNjExIDYxMSA2MTEgNjExIDMz MyAzMzMgMzMzIDMzMyANNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDU2NCA3MjIgNzIyIDcy MiA3MjIgNzIyIDcyMiA1NTYgNTAwIA00NDQgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCA2NjcgNDQ0IDQ0 NCA0NDQgNDQ0IDQ0NCAyNzggMjc4IDI3OCAyNzggDTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCA1NDkgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCANXQ0vRW5jb2RpbmcgL1dpbkFu c2lFbmNvZGluZw0vRm9udERlc2NyaXB0b3IgMTkgMCBSDT4+DWVuZG9iag0xOSAwIG9iag08PA0v VHlwZSAvRm9udERlc2NyaXB0b3INL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuDS9GbGFncyAzNA0v Rm9udEJCb3ggWyAtMjUwIC0yMTYgMTE1MiAxMDAwIF0NL01pc3NpbmdXaWR0aCAzMjANL1N0ZW1W IDczDS9TdGVtSCA3Mw0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDg5MQ0vWEhlaWdodCA0NDYN L0FzY2VudCA4OTENL0Rlc2NlbnQgLTIxNg0vTGVhZGluZyAxNDkNL01heFdpZHRoIDk2MA0vQXZn V2lkdGggNDAxDT4+DWVuZG9iag0yMCAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1 ZVR5cGUNL05hbWUgL0Y2DS9CYXNlRm9udCAvVGltZXNOZXdSb21hbixJdGFsaWMNL0ZpcnN0Q2hh ciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyAyNTAgMzMzIDQyMCA1MDAgNTAwIDgzMyA3Nzgg MjE0IDMzMyAzMzMgNTAwIDY3NSAyNTAgMzMzIDI1MCAyNzggDTUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDY3NSA2NzUgNjc1IDUwMCANOTIwIDYxMSA2MTEg NjY3IDcyMiA2MTEgNjExIDcyMiA3MjIgMzMzIDQ0NCA2NjcgNTU2IDgzMyA2NjcgNzIyIA02MTEg NzIyIDYxMSA1MDAgNTU2IDcyMiA2MTEgODMzIDYxMSA1NTYgNTU2IDM4OSAyNzggMzg5IDQyMiA1 MDAgDTMzMyA1MDAgNTAwIDQ0NCA1MDAgNDQ0IDI3OCA1MDAgNTAwIDI3OCAyNzggNDQ0IDI3OCA3 MjIgNTAwIDUwMCANNTAwIDUwMCAzODkgMzg5IDI3OCA1MDAgNDQ0IDY2NyA0NDQgNDQ0IDM4OSA0 MDAgMjc1IDQwMCA1NDEgNzc4IA01MDAgNzc4IDMzMyA1MDAgNTU2IDg4OSA1MDAgNTAwIDMzMyAx MDAwIDUwMCAzMzMgOTQ0IDc3OCA1NTYgNzc4IA03NzggMzMzIDMzMyA1NTYgNTU2IDM1MCA1MDAg ODg5IDMzMyA5ODAgMzg5IDMzMyA2NjcgNzc4IDM4OSA1NTYgDTI1MCAzODkgNTAwIDUwMCA1MDAg NTAwIDI3NSA1MDAgMzMzIDc2MCAyNzYgNTAwIDY3NSAzMzMgNzYwIDUwMCANNDAwIDU0OSAzMDAg MzAwIDMzMyA1NzYgNTIzIDI1MCAzMzMgMzAwIDMxMCA1MDAgNzUwIDc1MCA3NTAgNTAwIA02MTEg NjExIDYxMSA2MTEgNjExIDYxMSA4ODkgNjY3IDYxMSA2MTEgNjExIDYxMSAzMzMgMzMzIDMzMyAz MzMgDTcyMiA2NjcgNzIyIDcyMiA3MjIgNzIyIDcyMiA2NzUgNzIyIDcyMiA3MjIgNzIyIDcyMiA1 NTYgNjExIDUwMCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNjY3IDQ0NCA0NDQgNDQ0IDQ0NCA0 NDQgMjc4IDI3OCAyNzggMjc4IA01MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTQ5IDUwMCA1 MDAgNTAwIDUwMCA1MDAgNDQ0IDUwMCA0NDQgDV0NL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcN L0ZvbnREZXNjcmlwdG9yIDIxIDAgUg0+Pg1lbmRvYmoNMjEgMCBvYmoNPDwNL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yDS9Gb250TmFtZSAvVGltZXNOZXdSb21hbixJdGFsaWMNL0ZsYWdzIDk4DS9Gb250 QkJveCBbIC0yNTAgLTIxNiAxMTUyIDEwMDAgXQ0vTWlzc2luZ1dpZHRoIDM3NA0vU3RlbVYgNzMN L1N0ZW1IIDczDS9JdGFsaWNBbmdsZSAtMTENL0NhcEhlaWdodCA4OTENL1hIZWlnaHQgNDQ2DS9B c2NlbnQgODkxDS9EZXNjZW50IC0yMTYNL0xlYWRpbmcgMTQ5DS9NYXhXaWR0aCA5NjANL0F2Z1dp ZHRoIDQwMg0+Pg1lbmRvYmoNMiAwIG9iag1bIC9QREYgL1RleHQgIF0NZW5kb2JqDTUgMCBvYmoN PDwNL0tpZHMgWzQgMCBSIF0NL0NvdW50IDENL1R5cGUgL1BhZ2VzDS9NZWRpYUJveCBbIDAgMCA2 MTIgNzkyIF0NPj4NZW5kb2JqDTEgMCBvYmoNPDwNL0NyZWF0b3IgPEZFRkYwMDZGMDA2RTAwNjUw MDIwMDA3MDAwNjEwMDY3MDA2NTAwMjAwMDQzMDA0NjAwNTAwMDI3MDAzMDAwMzUwMDIwMDA2NjAw NjkwMDZFMDA2MTAwNkMwMDIwMDAyRDAwMjAwMDREMDA2OTAwNjMwMDcyMDA2RjAwNzMwMDZGMDA2 NjAwNzQwMDIwMDA1NzAwNkYwMDcyMDA2ND4NL0NyZWF0aW9uRGF0ZSAoRDoyMDA1MDcyODE1MTMx NSkNL1RpdGxlIDxGRUZGMDA2RjAwNkUwMDY1MDAyMDAwNzAwMDYxMDA2NzAwNjUwMDIwMDA0MzAw NDYwMDUwMDAyNzAwMzAwMDM1MDAyMDAwNjYwMDY5MDA2RTAwNjEwMDZDMDAyRTAwNjQwMDZGMDA2 Mz4NL0F1dGhvciA8RkVGRjAwNEEwMDc1MDA2RTAwNjEwMDY5MDA2NDAwMjAwMDVBMDA3NTAwNjIw MDYxMDA2OTAwNzIwMDY5Pg0vUHJvZHVjZXIgKEFjcm9iYXQgUERGV3JpdGVyIDUuMCBmb3IgV2lu ZG93cyBOVCkNPj4NZW5kb2JqDTMgMCBvYmoNPDwNL1BhZ2VzIDUgMCBSDS9UeXBlIC9DYXRhbG9n DT4+DWVuZG9iag14cmVmDTAgMjgNMDAwMDAwMDAwMCA2NTUzNSBmIA0wMDAwMDIyOTMzIDAwMDAw IG4gDTAwMDAwMjI4MTggMDAwMDAgbiANMDAwMDAyMzM4OSAwMDAwMCBuIA0wMDAwMDA1NDMxIDAw MDAwIG4gDTAwMDAwMjI4NDkgMDAwMDAgbiANMDAwMDAwNTYzNyAwMDAwMCBuIA0wMDAwMDA2NzI2 IDAwMDAwIG4gDTAwMDAwMDY5ODggMDAwMDAgbiANMDAwMDAwODA4NyAwMDAwMCBuIA0wMDAwMDA4 MzU3IDAwMDAwIG4gDTAwMDAwMDk0NDggMDAwMDAgbiANMDAwMDAwMDAxOSAwMDAwMCBuIA0wMDAw MDA1NDEwIDAwMDAwIG4gDTAwMDAwMDk3MTYgMDAwMDAgbiANMDAwMDAxMDg0NSAwMDAwMCBuIA0w MDAwMDE4NzU5IDAwMDAwIG4gDTAwMDAwMTk4NDYgMDAwMDAgbiANMDAwMDAyMDEwMCAwMDAwMCBu IA0wMDAwMDIxMTkxIDAwMDAwIG4gDTAwMDAwMjE0NTIgMDAwMDAgbiANMDAwMDAyMjU0OCAwMDAw MCBuIA0wMDAwMDA1NTQwIDAwMDAwIG4gDTAwMDAwMTExMjkgMDAwMDAgbiANMDAwMDAxODY4MCAw MDAwMCBuIA0wMDAwMDE4NzIzIDAwMDAwIG4gDTAwMDAwMTg3MDEgMDAwMDAgbiANMDAwMDAxODc0 MSAwMDAwMCBuIA10cmFpbGVyDTw8DS9TaXplIDI4DS9Sb290IDMgMCBSDS9JbmZvIDEgMCBSDS9J RCBbPGJkNGYwZGY3YWJhNDJlMzVkNjZmODk4OTYxZjk5MTZiPjxiZDRmMGRmN2FiYTQyZTM1ZDY2 Zjg5ODk2MWY5OTE2Yj5dDT4+DXN0YXJ0eHJlZg0yMzQzOA0lJUVPRg0= ------=_NextPart_000_026F_01C59828.FEDAC0B0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_026F_01C59828.FEDAC0B0-- From mpls-bounces@lists.ietf.org Wed Aug 03 15:50:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0PFc-0000PD-7e; Wed, 03 Aug 2005 15:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0PFa-0000OD-93 for mpls@megatron.ietf.org; Wed, 03 Aug 2005 15:50:02 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09761 for ; Wed, 3 Aug 2005 15:50:00 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E0PFZ-0001dT-VK; Wed, 03 Aug 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, 03 Aug 2005 15:50:01 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-icmp-03.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : ICMP Extensions for MultiProtocol Label Switching Author(s) : R. Bonica, et al. Filename : draft-ietf-mpls-icmp-03.txt Pages : 15 Date : 2005-8-3 This memo proposes extensions to ICMP that permit Label Switching Routers to append MPLS information to ICMP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-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-mpls-icmp-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-mpls-icmp-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-8-3124613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-icmp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-icmp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-3124613.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Thu Aug 04 10:52:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0h5d-0002qJ-L1; Thu, 04 Aug 2005 10:52:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0h5b-0002nI-RZ for mpls@megatron.ietf.org; Thu, 04 Aug 2005 10:52:55 -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 KAA16937 for ; Thu, 4 Aug 2005 10:52:53 -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.43) id 1E0hcW-00064E-Ag for mpls@ietf.org; Thu, 04 Aug 2005 11:26:56 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 15:52:46 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 15:52:46 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Aug 2005 10:52:45 -0400 Received: from [172.23.1.32] ([172.23.1.32]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 10:52:44 -0400 Message-ID: <42F22BBA.5090907@juniper.net> Date: Thu, 04 Aug 2005 10:52:42 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@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: 04 Aug 2005 14:52:44.0850 (UTC) FILETIME=[2C163920:01C59904] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] draft-ietf-mpls-icmp X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Folks, As draft-ietf-mpls-icmp is of interest to the Internet Area as well as the MPLS WG, it is currently being discussed on the Internet Area general mailing list. Rather than cross-posting, I encourage those who would like to join that discussion to subscribe to the Internet Area mailing list. You can subscribe through the following URL: https://www1.ietf.org/mailman/listinfo/int-area thanks, Ron _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Aug 08 08:49:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2740-0001nL-V8; Mon, 08 Aug 2005 08:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0tRP-0000dl-DI; Fri, 05 Aug 2005 00:04:15 -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 AAA28562; Fri, 5 Aug 2005 00:04:12 -0400 (EDT) Received: from gator9.hostgator.com ([67.18.141.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0tyO-0000fx-Ba; Fri, 05 Aug 2005 00:38:22 -0400 Received: from pool-71-96-167-218.dfw.dsl-w.verizon.net ([71.96.167.218]:50098 helo=cow) by gator9.hostgator.com with esmtpa (Exim 4.50) id 1E0tQ3-0007aG-8f; Thu, 04 Aug 2005 23:02:51 -0500 From: "Dawn " To: Date: Thu, 4 Aug 2005 23:02:54 -0500 Message-ID: <002001c59972$90fdf0d0$f922fea9@cow> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator9.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - icst.org X-Spam-Score: 0.6 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 X-Mailman-Approved-At: Mon, 08 Aug 2005 08:49:04 -0400 Cc: Subject: [mpls] Call for Participation - BroadNets 2005 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1123214754==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1123214754== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C59948.A827E8D0" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C59948.A827E8D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable *** We apologize if you have received multiple copies of this message = *** =20 ----------------------------------------------------------------------- CALL FOR PARTICIPATION IEEE Second Annual International Conference on Broadband Networks=20 (IEEE BroadNets 2005) October 3 - 7, 2005 Radisson Hotel Boston, Massachusetts, USA http://www.broadnets.org/ =20 ----------------------------------------------------------------------- IEEE BroadNets 2005 is an international conference focusing on broadband networking and covers the entire gamut of next generation networks with = high bandwidth available for both wireless and wireline networks. The = conference consists of the following three symposia: ** Broadband Optical Networking Symposium: It covers WDM technologies, Ethernet and MPLS integration into the optical layer, Next-Generation SONET/SDH, as well as SAN extensions over DWDM/SONET/SDH. ** Broadband Wireless Networking Symposium: It covers mobility, routing = for multihop, multimedia QoS and traffic management, cross-layer = optimization, MAC and emerging physical layer technologies (UWB, MIMO) for high-speed wireless networking. ** Broadband Applications/Services Symposium: It covers middleware and service architectures for broadband applications, pervasive computing = and ubiquitous communications, and universal broadband access for = information services. BroadNets 2005 thus offers a unique forum for researchers from academia, government and industry to share ideas and disseminate new results in = these important areas. The technical program as well registration information is available on = the conference website at http://www.broadnets.org/ =20 =20 =20 ------=_NextPart_000_0021_01C59948.A827E8D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

*** We = apologize if you have received multiple copies of this message ***

 

----------------------------------------------= -------------------------
CALL FOR PARTICIPATION

IEEE Second Annual International Conference = on Broadband Networks
(IEEE BroadNets 2005)
October 3 - 7, 2005
Radisson Hotel Boston, Massachusetts, USA
http://www.broadnets.org/
-----------------------------------------------------------------------

IEEE BroadNets 2005 is an international conference focusing on broadband = networking and covers the entire gamut of next generation networks with high = bandwidth available for both wireless and wireline networks. The conference = consists of the following three symposia:

** Broadband Optical Networking Symposium: It covers WDM technologies, = Ethernet and MPLS integration into the optical layer, Next-Generation SONET/SDH, = as well as SAN extensions over DWDM/SONET/SDH.

** Broadband Wireless Networking Symposium: It covers mobility, routing for multihop, multimedia QoS and traffic management, cross-layer = optimization, MAC and emerging physical layer technologies (UWB, MIMO) for high-speed = wireless networking.

** Broadband Applications/Services Symposium: It covers middleware and = service architectures for broadband applications, pervasive computing and = ubiquitous communications, and universal broadband access for information = services.

BroadNets 2005 thus offers a unique forum for researchers from academia, = government and industry to share ideas and disseminate new results in these important = areas.

The technical program as well registration information is available on the conference website at http://www.broadnets.org/

 

 

 

------=_NextPart_000_0021_01C59948.A827E8D0-- --===============1123214754== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1123214754==-- From mpls-bounces@lists.ietf.org Mon Aug 08 09:30:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27iQ-0004KL-58; Mon, 08 Aug 2005 09:30:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0vYa-0001yw-Ha for mpls@megatron.ietf.org; Fri, 05 Aug 2005 02:19:48 -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 CAA16809 for ; Fri, 5 Aug 2005 02:19:47 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0w5c-0003KD-IY for mpls@ietf.org; Fri, 05 Aug 2005 02:53:57 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 23:19:38 -0700 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.12.202]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 23:19:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Aug 2005 23:19:26 -0700 Message-ID: Thread-Topic: Call For Papers: Workshop on emerging services delivery platforms and software models for Next Generation Network Services thread-index: AcWZhaFVSmTYINxmQk+SA9XyEHVS1g== From: "Joshy Joseph" To: X-OriginalArrivalTime: 05 Aug 2005 06:19:38.0876 (UTC) FILETIME=[A8A123C0:01C59985] X-Spam-Score: 0.5 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 X-Mailman-Approved-At: Mon, 08 Aug 2005 09:30:52 -0400 Cc: Subject: [mpls] Call For Papers: Workshop on emerging services delivery platforms and software models for Next Generation Network Services X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0153895032==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0153895032== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59985.A82993D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59985.A82993D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Apologies, if you receive multiple copies of this request. =20 Call For Papers: Workshop on emerging services delivery platforms and software models for Next Generation Network Services (http://www.softplatforms.org) This workshop will be held in conjunction with the FIRST International Conference on COMmunication System softWAre and MiddlewaRE (COMSWARE 2006) at New Delhi, India (http://www.comsware.org/) from Jan 8-12 2006. =20 The exact date of the workshop will be made available on the workshop's Web site http://www.softplatforms.org. =20 Workshop Objectives:=20 The next generation services networks deliver enhanced business capabilities such as data, video, messaging and business functions for wired and wireless consumers. These new sets of services enhance the business opportunities by integrating with core business services, including: supply chain management, customer management, and consumer applications. This workshop aims to discuss topics related to emerging next generation services and service delivery platforms to host/support such complex application environments.=20 =20 The workshop focuses on: * How next generation service delivery platforms deliver enhanced QoS management, operational efficiencies, flexible services composability, faster time-to-market, efficient trust models and flexible pricing models. * Technical and business factors influencing the services composability and network services delivery environments. The associated revenue and cost models for consumers, suppliers and application providers. * The influences of emerging distributed computing architecture styles (loosely-coupled, asynchronous, compos able, collaborative, decentralized and parallel services) related to service delivery models. * Emerging middleware platforms for network services, service composability, distributed architecture models and programming models. * New services models (communication services, presence-enabled services, content/media services and enterprise/legacy services) and value creation environments that represents new business opportunities for operators and providers. =20 This workshop invites papers from research and business communities on the different aspects of service delivery platforms and emerging services models. The workshop will include papers that examine interesting practical problems, case studies, best practices, middleware platforms and innovative messaging architectures.=20 =20 Submission Guidelines: All papers are limited to 5 pages and must be in standard IEEE double-column format. All submissions must be sent by email to the workshops co-chairs with the e-mail addresses given above.=20 =20 Important Dates:=20 Paper Submission Deadline: September 23, 2005=20 Notification of Acceptance: October 28, 2005=20 Camera-Ready Papers: November 25, 2005=20 =20 Contact and organization: For any questions regarding the workshop feel free to contact=20 1. Craig Fellenstein, IBM (cfellen@us.ibm.com)=20 2. Joshy Joseph, Microsoft (jojoseph@microsoft.com)=20 =20 Submission requirements: All papers are limited to 5 pages and must be in standard IEEE double-column format. All submissions must be sent by email to the workshops co-chairs. ------_=_NextPart_001_01C59985.A82993D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Apologies, if you receive multiple copies of this = request.

 

Call For Papers:  Workshop on emerging services = delivery platforms and software models for Next Generation Network Services (http://www.softplatforms.org)

This workshop will be held in conjunction with the = FIRST International Conference on COMmunication System softWAre and MiddlewaRE (COMSWARE 2006) at New = Delhi, India (http://www.comsware.org/) from Jan 8-12 2006. =

 

The exact date of the workshop will be made available = on the workshop's Web site = http://www.softplatforms.org.

 

Workshop Objectives:

The next generation services networks deliver = enhanced business capabilities such as data, video, messaging and business = functions for wired and wireless consumers. These new sets of services enhance the = business opportunities by integrating with core business services, including: = supply chain management, customer management, and consumer applications. This = workshop aims to discuss topics related to emerging next generation services and = service delivery platforms to host/support such complex application = environments.

 

The workshop focuses on:

* How next generation service delivery platforms = deliver enhanced QoS management, operational efficiencies, flexible services composability, faster time-to-market, efficient trust models and = flexible pricing models.

* Technical and business factors influencing the = services composability and network services delivery environments. The associated revenue and cost models for consumers, suppliers and application = providers.

* The influences of emerging distributed computing = architecture styles (loosely-coupled, asynchronous, compos able, collaborative, decentralized and parallel services) related to service delivery = models.

* Emerging middleware platforms for network services, service composability, distributed architecture models and programming = models.

* New services models (communication services, presence-enabled services, content/media services and enterprise/legacy services) and value creation environments that represents new business opportunities for operators and providers.

 

This workshop invites papers from research and = business communities on the different aspects of service delivery platforms and = emerging services models. The workshop will include papers that examine = interesting practical problems, case studies, best practices, middleware platforms = and innovative messaging architectures.

 

Submission Guidelines:

All papers are limited to 5 pages and must be in = standard IEEE double-column format. All submissions must be sent by email to the workshops co-chairs with the e-mail addresses given above. =

 

Important Dates:

Paper Submission Deadline: September 23, 2005 =

Notification of Acceptance: October 28, 2005 =

Camera-Ready Papers: November 25, 2005 =

 

Contact and = organization:

For any questions regarding the workshop feel free to contact

1. Craig Fellenstein, IBM (cfellen@us.ibm.com) =

2. Joshy Joseph, Microsoft (jojoseph@microsoft.com) =

 

Submission requirements:

All papers are limited to 5 pages and must be in = standard IEEE double-column format. All submissions must be sent by email to the workshops co-chairs.

------_=_NextPart_001_01C59985.A82993D0-- --===============0153895032== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0153895032==-- From mpls-bounces@lists.ietf.org Wed Aug 10 05:20:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2mlb-00044J-BJ; Wed, 10 Aug 2005 05:20:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2mlX-000446-LR for mpls@megatron.ietf.org; Wed, 10 Aug 2005 05:20:51 -0400 Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14615 for ; Wed, 10 Aug 2005 05:20:48 -0400 (EDT) Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA02383; Wed, 10 Aug 2005 02:20:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Aug 2005 14:50:17 +0530 Message-ID: Thread-Topic: Reg: Fast Reroute Timings in RFC 4090 Thread-Index: AcWdjLjMIoV4Sd+nQJSbeIe5cLw9rA== From: "Dutta, Pranjal" To: Cc: Subject: [mpls] Reg: Fast Reroute Timings in RFC 4090 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0612110612==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0612110612== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59D8C.B90A9CE2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59D8C.B90A9CE2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As per RFC 4090- Fast Reroute Extensions to RSVP-TE for LSP Tunnels, it takes 10 ms to reroute the LSP at PLR either by facility back up or one-to-one back up method. The re-route timing is definitely lesser when compared to time taken for global rerouting (at Ingress LSR). My concern is PLR will reroute the LSP locally only when it has the fault notification (after missing hellos from the downstream neighbor). Assuming that min 1 second of RSVP hello interval is being used, it will take at least 1 second in total to re-route the traffic locally which will lead to loss of voice/video packets and affects traffic performance. I would like to know if there is some effort going on in this group to address this issue. Any pointers will be helpful. =20 Thanks, Pranjal ------_=_NextPart_001_01C59D8C.B90A9CE2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

         =       As per RFC 4090- Fast = Reroute Extensions to RSVP-TE for LSP Tunnels, it takes 10 ms to reroute the LSP = at PLR either by facility back up or one-to-one back up method. The re-route = timing is definitely lesser when compared to time taken for global rerouting (at = Ingress LSR). My concern is PLR will reroute the LSP locally only when it has = the fault notification (after missing hellos from the downstream neighbor). = Assuming that min 1 second of RSVP hello interval is being used, it will take at least = 1 second in total to re-route the traffic locally which will lead to loss = of voice/video packets and affects traffic performance. I would like to = know if there is some effort going on in this group to address this issue. Any = pointers will be helpful.

 

Thanks,

Pranjal

------_=_NextPart_001_01C59D8C.B90A9CE2-- --===============0612110612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0612110612==-- From mpls-bounces@lists.ietf.org Wed Aug 10 10:02:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rAA-0008QU-O3; Wed, 10 Aug 2005 10:02:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rA8-0008QN-Ia for mpls@megatron.ietf.org; Wed, 10 Aug 2005 10:02:32 -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 KAA29372 for ; Wed, 10 Aug 2005 10:02:30 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2riD-0007g3-RY for mpls@ietf.org; Wed, 10 Aug 2005 10:37:48 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j7AE2LFV005421 for ; Wed, 10 Aug 2005 10:02:21 -0400 (EDT) Received: from [169.144.136.107] (usvisdad104641.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25664 for ; Wed, 10 Aug 2005 10:02:21 -0400 (EDT) Message-ID: <42FA08EC.8050502@marconi.com> Date: Wed, 10 Aug 2005 10:02:20 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] Reg: Fast Reroute Timings in RFC 4090 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Dutta, Pranjal wrote: > > As per RFC 4090- Fast Reroute Extensions to RSVP-TE for > LSP Tunnels, it takes 10 ms to reroute the LSP at PLR either by facility > back up or one-to-one back up method. The re-route timing is definitely > lesser when compared to time taken for global rerouting (at Ingress > LSR). My concern is PLR will reroute the LSP locally only when it has > the fault notification (after missing hellos from the downstream > neighbor). Assuming that min 1 second of RSVP hello interval is being > used, it will take at least 1 second in total to re-route the traffic > locally which will lead to loss of voice/video packets and affects > traffic performance. I would like to know if there is some effort going > on in this group to address this issue. Any pointers will be helpful. First of all, the Hello interval may be faster than 1s, depending on the implementation. The RFC actually recommends 5ms intervals, but I don't know if anyone actually implements that rate. Second, a switch may detect a link failure by means other than loss of RSVP-Hello. For instance, the hardware may detect a loss of carrier on the interface. (As a matter of fact, I would expect hardware detection of link failure to be the only way that can reroute traffic fast enough for real-time applications.) If a switch loses RSVP Hellos, but does not lose carrier, then the link is still physically active. It is probably still forwarding data-plane traffic as well (even though the control plane has probably failed.) So actual losses may not be nearly as severe as you are assuming. -- David _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Aug 10 19:00:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2zYz-0004sJ-TS; Wed, 10 Aug 2005 19:00:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2zYx-0004sE-DS for mpls@megatron.ietf.org; Wed, 10 Aug 2005 19:00:43 -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 TAA09920 for ; Wed, 10 Aug 2005 19:00:40 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3077-0000Fm-Bk for mpls@ietf.org; Wed, 10 Aug 2005 19:36:03 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 00:00:30 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 00:00:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Reg: Fast Reroute Timings in RFC 4090 Date: Thu, 11 Aug 2005 00:00:30 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1ED6@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [mpls] Reg: Fast Reroute Timings in RFC 4090 Thread-Index: AcWdtHxFXDtth7gWTeOjBuDCOKAEQAAMvOcg To: , X-OriginalArrivalTime: 10 Aug 2005 23:00:30.0879 (UTC) FILETIME=[4E7A5AF0:01C59DFF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org David Charlap wisely wrote 10 August 2005 15:02 >=20 > Dutta, Pranjal wrote: > >=20 > > As per RFC 4090- Fast Reroute Extensions to > RSVP-TE for > > LSP Tunnels, it takes 10 ms to reroute the LSP at PLR > either by facility > > back up or one-to-one back up method. The re-route timing > is definitely > > lesser when compared to time taken for global rerouting (at Ingress > > LSR). My concern is PLR will reroute the LSP locally only=20 > when it has > > the fault notification (after missing hellos from the downstream > > neighbor). Assuming that min 1 second of RSVP hello=20 > interval is being > > used, it will take at least 1 second in total to re-route > the traffic > > locally which will lead to loss of voice/video packets and affects > > traffic performance. I would like to know if there is some=20 > effort going > > on in this group to address this issue. Any pointers will > be helpful. >=20 > First of all, the Hello interval may be faster than 1s, > depending on the=20 > implementation. The RFC actually recommends 5ms intervals,=20 > but I don't=20 > know if anyone actually implements that rate. >=20 > Second, a switch may detect a link failure by means other > than loss of=20 > RSVP-Hello. For instance, the hardware may detect a loss of=20 > carrier on=20 > the interface. (As a matter of fact, I would expect hardware=20 > detection=20 > of link failure to be the only way that can reroute traffic=20 > fast enough=20 > for real-time applications.) NH-> Correct....if folks want fast restoration, then infrastructure failure protection is the only viable means. All layer networks need their own (independent from any other layer network) OAM, and the speed of defect detection/handling (and protection) should follow the general rule 'closer the application the slower, closer the duct the faster'. Unfortunately one could consider some of the PWE3 stuff turns sensible client/server layer relationships on their head. So it's not always possible to set any general/logical rules for a given layer network when some folks think, for example, SDHoverIP is a sensible thing to do. BTW - If not obvious, I don't think this is sensible at all. >=20 > If a switch loses RSVP Hellos, but does not lose carrier, > then the link=20 > is still physically active. It is probably still forwarding=20 > data-plane=20 > traffic as well (even though the control plane has probably=20 > failed.) So=20 > actual losses may not be nearly as severe as you are assuming. NH=3D> Not only does each data-plane need its own OAM (and for folks who are familiar with G.805 func arch, this should be generic and be inserted/extracted at the trail termination point as part of the characteristic information (CI) of that layer network) but this is different (actually lower level) to whatever OAM is required to maintain the various functional protocols that a layer network is carrying. For example, in GMPLS I can have 2 disjoint layer networks in SDH carrying traffic (eg VC4) and the control/management plane protocols for that VC4 layer network, BUT these 2 logically different data-plane layer networks usually come together at an even lower network layer....in the VC4 case given this would usually be the STM-N level below this. So what I am driving at here is that whilst the *traffic* carrying VC4 layer network will use its BIP_8 and trail source address (J0 byte) CI carried in the VC4 overhead to provide the traffic layer network OAM, the control/management protocols will have their own OAM running in a seperate layer network.....and this will be far more sophisticated than basic data-plane OAM since there are timers/acknowledgements associated with these (eg routing, signalling) protocols. And one key message here is this....don't use control/management-plane protocols to proxy for *traffic* data-plane OAM in the general case. These are different OAM functions and they often reside in different layer networks (even within the same networking system). However...and having said all that.....I am always puzzled why some folks think really rapid restoration MUST be done for voice. I can't believe anyone would clear down a call after 10s, 100s or maybe even a few 1000 ms of loss. I know there is some macho 'must equal/beat SDH's 50ms' mindset at work here.....but this is nuts. I know the folks who set the 50ms defect detection threshold in SDH and this was NOT done to accomodate voice, or any application for that matter. It was simply down to the physics and ring topologies being considered. If you invoke protection too quickly you can make things far worse than letting the (for example) error event just go away. However, this depends on the layer network you are considering. If you really are down close to the physical media/section level (and not some artificial inversion of this as per PWE3) the OAM defect detection/handling ought to be fast.....and so in such a case its is sensible to invoke protection once it is truly known this is a real failure case. regards, Neil >=20 > -- David >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 11 00:39:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E34qg-0007dt-4V; Thu, 11 Aug 2005 00:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E34qd-0007dl-RT for mpls@megatron.ietf.org; Thu, 11 Aug 2005 00:39: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 AAA23224 for ; Thu, 11 Aug 2005 00:39:16 -0400 (EDT) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E35Or-000810-RO for mpls@ietf.org; Thu, 11 Aug 2005 01:14:43 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id VAA10464; Wed, 10 Aug 2005 21:38:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Aug 2005 10:08:46 +0530 Message-ID: Thread-Topic: Reg: Fast Reroute Timings in RFC 4090 Thread-Index: AcWdxlSfyRGYV4oFSaeOBrd0BK2DGAAZte1w From: "Dutta, Pranjal" To: "David Charlap" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org Subject: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, I think most of the vendors implement min 1 seconds as hello-intervals as lesser than that might lead to scalability issues (I am not sure if that is the reason why vendors implement at least 1 sec). Hardware level detection will be possible only when physical layer has end-to-end signaling mechanism for failure. In the case where end-to-end signaling mechanism is not possible, the PLR will still see that link is up and keep forwarding traffic to downstream LSR, but actually the link is failed. I am basically looking for some mechanism that can detect "Node Failure" as early as possible and PLR will initiate node protection accordingly. I think some kind of OAM mechanism might help. Thanks, Pranjal Date: Wed, 10 Aug 2005 10:02:20 -0400 From: David Charlap Subject: Re: [mpls] Reg: Fast Reroute Timings in RFC 4090 To: mpls@ietf.org Message-ID: <42FA08EC.8050502@marconi.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Dutta, Pranjal wrote: >=20 > As per RFC 4090- Fast Reroute Extensions to RSVP-TE for > LSP Tunnels, it takes 10 ms to reroute the LSP at PLR either by facility=20 > back up or one-to-one back up method. The re-route timing is definitely=20 > lesser when compared to time taken for global rerouting (at Ingress=20 > LSR). My concern is PLR will reroute the LSP locally only when it has=20 > the fault notification (after missing hellos from the downstream=20 > neighbor). Assuming that min 1 second of RSVP hello interval is being=20 > used, it will take at least 1 second in total to re-route the traffic=20 > locally which will lead to loss of voice/video packets and affects=20 > traffic performance. I would like to know if there is some effort going=20 > on in this group to address this issue. Any pointers will be helpful. First of all, the Hello interval may be faster than 1s, depending on the implementation. The RFC actually recommends 5ms intervals, but I don't=20 know if anyone actually implements that rate. Second, a switch may detect a link failure by means other than loss of=20 RSVP-Hello. For instance, the hardware may detect a loss of carrier on=20 the interface. (As a matter of fact, I would expect hardware detection=20 of link failure to be the only way that can reroute traffic fast enough=20 for real-time applications.) If a switch loses RSVP Hellos, but does not lose carrier, then the link=20 is still physically active. It is probably still forwarding data-plane=20 traffic as well (even though the control plane has probably failed.) So actual losses may not be nearly as severe as you are assuming. -- David ------------------------------ _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 16, Issue 7 *********************************** _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 11 03:10:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E37DI-0003AV-6K; Thu, 11 Aug 2005 03:10:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E37DF-0003AQ-Pi for mpls@megatron.ietf.org; Thu, 11 Aug 2005 03:10: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 DAA12790 for ; Thu, 11 Aug 2005 03:10:48 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E37lV-00033H-2X for mpls@ietf.org; Thu, 11 Aug 2005 03:46:14 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 08:10:34 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 08:10:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 Date: Thu, 11 Aug 2005 08:10:28 +0100 Message-ID: Thread-Topic: Reg: Fast Reroute Timings in RFC 4090 Thread-Index: AcWdxlSfyRGYV4oFSaeOBrd0BK2DGAAZte1wAAPONoA= To: , X-OriginalArrivalTime: 11 Aug 2005 07:10:33.0920 (UTC) FILETIME=[C40E5C00:01C59E43] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Pranjal, Total node failures (i.e. a node completely dies) will be detected by = all directly connected peers as the links will go down at the physical = layer. If you want to detect IP/MPLS layer failures, the IETF's protocol = for doing this is BFD (see: = http://www.ietf.org/html.charters/bfd-charter.html). You can run BFD on = a per LSP basis (in the data plane) and also at the IP forwarding level = (essentially in the control plane) and the detection time is user = configurable. However, I think its unlikely that you will be able to achieve reliable = failure detection much faster than 500ms-1000ms. If the nodes supported = it, you could adjust the timers to detect failures quicker than this but = the network would be highly susceptible to false failures due to things = like network congestion and short error bursts. Also, running multiple = BFD sessions with very fast detection rates will consume a significant = amount of processing resources.=20 In general, when considering failure protection there is a tradeoff = between network reliability and fast switchover. IMO, optimising a large = SP network to protect against specific failures (i.e. MPLS node = forwarding plane failures) faster than 500ms-1000ms (at the expense of = processing resources and network reliability) is unlikely to be = technically or commercially viable. You mentioned packet loss for voice/video traffic in your original = email, what do you think the impact of a 500ms-1000ms loss will have at = the application layer? Can you give some examples? Regards, Richard > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org]On > Behalf Of Dutta, Pranjal > Sent: 11 August 2005 05:39 > To: David Charlap > Cc: mpls@ietf.org > Subject: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 >=20 >=20 >=20 > Hi, > I think most of the vendors implement min 1 seconds as > hello-intervals as lesser than that might lead to scalability=20 > issues (I > am not sure if that is the reason why vendors implement at=20 > least 1 sec). > Hardware level detection will be possible only when physical layer has > end-to-end signaling mechanism for failure. In the case where=20 > end-to-end > signaling mechanism is not possible, the PLR will still see=20 > that link is > up and keep forwarding traffic to downstream LSR, but=20 > actually the link > is failed. I am basically looking for some mechanism that can detect > "Node Failure" as early as possible and PLR will initiate node > protection accordingly. I think some kind of OAM mechanism might help. >=20 > Thanks, > Pranjal >=20 >=20 >=20 > Date: Wed, 10 Aug 2005 10:02:20 -0400 > From: David Charlap > Subject: Re: [mpls] Reg: Fast Reroute Timings in RFC 4090 > To: mpls@ietf.org > Message-ID: <42FA08EC.8050502@marconi.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > Dutta, Pranjal wrote: > >=20 > > As per RFC 4090- Fast Reroute Extensions to=20 > RSVP-TE for >=20 > > LSP Tunnels, it takes 10 ms to reroute the LSP at PLR either by > facility=20 > > back up or one-to-one back up method. The re-route timing is > definitely=20 > > lesser when compared to time taken for global rerouting (at Ingress=20 > > LSR). My concern is PLR will reroute the LSP locally only=20 > when it has=20 > > the fault notification (after missing hellos from the downstream=20 > > neighbor). Assuming that min 1 second of RSVP hello=20 > interval is being=20 > > used, it will take at least 1 second in total to re-route=20 > the traffic=20 > > locally which will lead to loss of voice/video packets and affects=20 > > traffic performance. I would like to know if there is some effort > going=20 > > on in this group to address this issue. Any pointers will=20 > be helpful. >=20 > First of all, the Hello interval may be faster than 1s,=20 > depending on the >=20 > implementation. The RFC actually recommends 5ms intervals,=20 > but I don't=20 > know if anyone actually implements that rate. >=20 > Second, a switch may detect a link failure by means other=20 > than loss of=20 > RSVP-Hello. For instance, the hardware may detect a loss of=20 > carrier on=20 > the interface. (As a matter of fact, I would expect hardware=20 > detection=20 > of link failure to be the only way that can reroute traffic=20 > fast enough=20 > for real-time applications.) >=20 > If a switch loses RSVP Hellos, but does not lose carrier,=20 > then the link=20 > is still physically active. It is probably still forwarding=20 > data-plane=20 > traffic as well (even though the control plane has probably=20 > failed.) So >=20 > actual losses may not be nearly as severe as you are assuming. >=20 > -- David >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 >=20 > End of mpls Digest, Vol 16, Issue 7 > *********************************** >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 11 04:23:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E38M1-00005g-5x; Thu, 11 Aug 2005 04:23:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E38Ly-00005b-T3 for mpls@megatron.ietf.org; Thu, 11 Aug 2005 04:23:55 -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 EAA15606 for ; Thu, 11 Aug 2005 04:23:53 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E38uF-0004xb-VV for mpls@ietf.org; Thu, 11 Aug 2005 04:59:20 -0400 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 09:23:38 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 09:23:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 Date: Thu, 11 Aug 2005 09:23:37 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1ED8@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 Thread-Index: AcWdxlSfyRGYV4oFSaeOBrd0BK2DGAAZte1wAAPONoAAA31HsA== To: , , X-OriginalArrivalTime: 11 Aug 2005 08:23:38.0224 (UTC) FILETIME=[F94E0F00:01C59E4D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Richard, Of course I agree with these observations. 1 further point..... BFD only works on arch valid trail constructs, ie p2p and p2mp. If you violate the co mode by merging (ie LDP/PHP) then the traffic/fault/performance management problems become rather difficult (understatement)...adding ECMP to brew just makes it significantly worse. Check out the complexity of LSP-Ping....N years on, still a draft (rev 9)....this fact alone should tell you something is not quite right here. I'd also advise that if you really want to see what simple always-on defect detection/handling OAM SHOULD look like for the co-ps mode you should have a look at Y.1711. BFD is a sort-of Y.1711 look-alike (has to be, the nature of the functional problem being addressed is the same....so the solution has to be similar). However, Y.1711 is complete of specification. Not sure how many folks implement it as nothing works well with LDP/PHP/ECMP stuff and many folks already have lots of that. Further, given its an ITU Rec and is written with a HW implementation in mind then I suspect many router vendors don't like it. However, the functionality specified in here is correct, complete and minimalist......nothing else exists which comes close to this. If operators want to (i) get opex down (ii) have more customer-oriented proactive network/service management which includes (iii) getting on the availability/performance SLA page one day, they are going to need something like this as a base from which to work from....else these objectives will not be achieveable in any simple and consistently meaningful way. regards, Neil > -----Original Message----- > From: mpls-bounces@lists.ietf.org > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of=20 > richard.spencer@bt.com > Sent: 11 August 2005 08:10 > To: pdutta@riverstonenet.com; David.Charlap@marconi.com > Cc: mpls@ietf.org > Subject: RE: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 >=20 >=20 > Pranjal, >=20 > Total node failures (i.e. a node completely dies) will be > detected by all directly connected peers as the links will go=20 > down at the physical layer. If you want to detect IP/MPLS=20 > layer failures, the IETF's protocol for doing this is BFD=20 > (see: http://www.ietf.org/html.charters/bfd-charter.html).=20 > You can run BFD on a per LSP basis (in the data plane) and=20 > also at the IP forwarding level (essentially in the control=20 > plane) and the detection time is user configurable. >=20 > However, I think its unlikely that you will be able to > achieve reliable failure detection much faster than=20 > 500ms-1000ms. If the nodes supported it, you could adjust the=20 > timers to detect failures quicker than this but the network=20 > would be highly susceptible to false failures due to things=20 > like network congestion and short error bursts. Also, running=20 > multiple BFD sessions with very fast detection rates will=20 > consume a significant amount of processing resources.=20 >=20 > In general, when considering failure protection there is a > tradeoff between network reliability and fast switchover.=20 > IMO, optimising a large SP network to protect against=20 > specific failures (i.e. MPLS node forwarding plane failures)=20 > faster than 500ms-1000ms (at the expense of processing=20 > resources and network reliability) is unlikely to be=20 > technically or commercially viable. >=20 > You mentioned packet loss for voice/video traffic in your > original email, what do you think the impact of a=20 > 500ms-1000ms loss will have at the application layer? Can you=20 > give some examples? >=20 > Regards, > Richard >=20 > > -----Original Message----- > > From: mpls-bounces@lists.ietf.org=20 > > [mailto:mpls-bounces@lists.ietf.org]On > > Behalf Of Dutta, Pranjal > > Sent: 11 August 2005 05:39 > > To: David Charlap > > Cc: mpls@ietf.org > > Subject: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 > >=20 > >=20 > >=20 > > Hi, > > I think most of the vendors implement min 1 seconds as > > hello-intervals as lesser than that might lead to=20 > scalability issues > > (I am not sure if that is the reason why vendors implement at least=20 > > 1 sec). Hardware level detection will be possible only when > physical layer has > > end-to-end signaling mechanism for failure. In the case where > > end-to-end > > signaling mechanism is not possible, the PLR will still see=20 > > that link is > > up and keep forwarding traffic to downstream LSR, but=20 > > actually the link > > is failed. I am basically looking for some mechanism that can detect > > "Node Failure" as early as possible and PLR will initiate node > > protection accordingly. I think some kind of OAM mechanism=20 > might help. > >=20 > > Thanks, > > Pranjal > >=20 > >=20 > >=20 > > Date: Wed, 10 Aug 2005 10:02:20 -0400 > > From: David Charlap > > Subject: Re: [mpls] Reg: Fast Reroute Timings in RFC 4090 > > To: mpls@ietf.org > > Message-ID: <42FA08EC.8050502@marconi.com> > > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > >=20 > > Dutta, Pranjal wrote: > > >=20 > > > As per RFC 4090- Fast Reroute Extensions to > > RSVP-TE for > >=20 > > > LSP Tunnels, it takes 10 ms to reroute the LSP at PLR either by > > facility > > > back up or one-to-one back up method. The re-route timing is > > definitely > > > lesser when compared to time taken for global rerouting > (at Ingress > > > LSR). My concern is PLR will reroute the LSP locally only > > when it has > > > the fault notification (after missing hellos from the downstream=20 > > > neighbor). Assuming that min 1 second of RSVP hello > > interval is being > > > used, it will take at least 1 second in total to re-route > > the traffic > > > locally which will lead to loss of voice/video packets and affects > > > traffic performance. I would like to know if there is some effort > > going > > > on in this group to address this issue. Any pointers will > > be helpful. > >=20 > > First of all, the Hello interval may be faster than 1s, depending on > > the > >=20 > > implementation. The RFC actually recommends 5ms intervals, but I=20 > > don't know if anyone actually implements that rate. > >=20 > > Second, a switch may detect a link failure by means other than loss=20 > > of RSVP-Hello. For instance, the hardware may detect a loss of > > carrier on=20 > > the interface. (As a matter of fact, I would expect hardware=20 > > detection=20 > > of link failure to be the only way that can reroute traffic=20 > > fast enough=20 > > for real-time applications.) > >=20 > > If a switch loses RSVP Hellos, but does not lose carrier, then the=20 > > link is still physically active. It is probably still forwarding > > data-plane=20 > > traffic as well (even though the control plane has probably=20 > > failed.) So > >=20 > > actual losses may not be nearly as severe as you are assuming. > >=20 > > -- David > >=20 > >=20 > >=20 > > ------------------------------ > >=20 > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls > >=20 > >=20 > > End of mpls Digest, Vol 16, Issue 7 > > *********************************** > >=20 > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls > >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 11 06:59:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3AmX-0001MU-VG; Thu, 11 Aug 2005 06:59:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3AmV-0001MO-TP for mpls@megatron.ietf.org; Thu, 11 Aug 2005 06:59:28 -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 GAA23217 for ; Thu, 11 Aug 2005 06:59:25 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3BKm-0000xS-8O for mpls@ietf.org; Thu, 11 Aug 2005 07:34:54 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2005 03:59:16 -0700 X-IronPort-AV: i="3.96,99,1122879600"; d="scan'208"; a="654211253:sNHT33284108" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7BAx60N002989; Thu, 11 Aug 2005 03:59:11 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 06:59:12 -0400 Received: from [192.168.1.102] ([10.86.240.126]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 06:59:12 -0400 In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F1ED6@i2km07-ukbr.domain1.systemhost.net> References: <0536FC9B908BEC4597EE721BE6A353890A9F1ED6@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B9E28B3-9DC5-454B-8392-617BCF73D4FD@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [mpls] Reg: Fast Reroute Timings in RFC 4090 Date: Thu, 11 Aug 2005 06:59:39 -0400 To: neil.2.harrison@bt.com X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 11 Aug 2005 10:59:12.0284 (UTC) FILETIME=[B4D695C0:01C59E63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, David.Charlap@marconi.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Neil, On Aug 10, 2005, at 7:00 PM, neil.2.harrison@bt.com wrote: > David Charlap wisely wrote 10 August 2005 15:02 > >> >> Dutta, Pranjal wrote: >> >>> >>> As per RFC 4090- Fast Reroute Extensions to >>> >> RSVP-TE for >> >>> LSP Tunnels, it takes 10 ms to reroute the LSP at PLR >>> >> either by facility >> >>> back up or one-to-one back up method. The re-route timing >>> >> is definitely >> >>> lesser when compared to time taken for global rerouting (at Ingress >>> LSR). My concern is PLR will reroute the LSP locally only >>> >> when it has >> >>> the fault notification (after missing hellos from the downstream >>> neighbor). Assuming that min 1 second of RSVP hello >>> >> interval is being >> >>> used, it will take at least 1 second in total to re-route >>> >> the traffic >> >>> locally which will lead to loss of voice/video packets and affects >>> traffic performance. I would like to know if there is some >>> >> effort going >> >>> on in this group to address this issue. Any pointers will >>> >> be helpful. >> >> First of all, the Hello interval may be faster than 1s, >> depending on the >> implementation. The RFC actually recommends 5ms intervals, >> but I don't >> know if anyone actually implements that rate. >> >> Second, a switch may detect a link failure by means other >> than loss of >> RSVP-Hello. For instance, the hardware may detect a loss of >> carrier on >> the interface. (As a matter of fact, I would expect hardware >> detection >> of link failure to be the only way that can reroute traffic >> fast enough >> for real-time applications.) >> > NH-> Correct....if folks want fast restoration, then infrastructure > failure protection is the only viable means. All layer networks need > their own (independent from any other layer network) OAM, and the > speed > of defect detection/handling (and protection) should follow the > general > rule 'closer the application the slower, closer the duct the faster'. > Unfortunately one could consider some of the PWE3 stuff turns sensible > client/server layer relationships on their head. So it's not always > possible to set any general/logical rules for a given layer network > when > some folks think, for example, SDHoverIP is a sensible thing to do. > BTW - If not obvious, I don't think this is sensible at all. > >> >> If a switch loses RSVP Hellos, but does not lose carrier, >> then the link >> is still physically active. It is probably still forwarding >> data-plane >> traffic as well (even though the control plane has probably >> failed.) So >> actual losses may not be nearly as severe as you are assuming. >> > NH=> Not only does each data-plane need its own OAM (and for folks who > are familiar with G.805 func arch, this should be generic and be > inserted/extracted at the trail termination point as part of the > characteristic information (CI) of that layer network) but this is > different (actually lower level) to whatever OAM is required to > maintain > the various functional protocols that a layer network is carrying. > For > example, in GMPLS I can have 2 disjoint layer networks in SDH carrying > traffic (eg VC4) and the control/management plane protocols for > that VC4 > layer network, BUT these 2 logically different data-plane layer > networks > usually come together at an even lower network layer....in the VC4 > case > given this would usually be the STM-N level below this. So what I am > driving at here is that whilst the *traffic* carrying VC4 layer > network > will use its BIP_8 and trail source address (J0 byte) CI carried in > the > VC4 overhead to provide the traffic layer network OAM, the > control/management protocols will have their own OAM running in a > seperate layer network.....and this will be far more sophisticated > than > basic data-plane OAM since there are timers/acknowledgements > associated > with these (eg routing, signalling) protocols. And one key message > here is this....don't use control/management-plane protocols to proxy > for *traffic* data-plane OAM in the general case. These are different > OAM functions and they often reside in different layer networks (even > within the same networking system). > > However...and having said all that.....I am always puzzled why some > folks think really rapid restoration MUST be done for voice. I can't > believe anyone would clear down a call after 10s, 100s or maybe even a > few 1000 ms of loss. I know there is some macho 'must equal/beat > SDH's > 50ms' mindset at work here.....but this is nuts. I know the folks who > set the 50ms defect detection threshold in SDH and this was NOT > done to > accomodate voice, or any application for that matter. It was simply > down to the physics and ring topologies being considered. > That really depends on your targeted SLA ... If indeed the goal is to avoid a drop call, you're absolutely right, 1-2s is probably good enough depending on the VoIP GTW. On the other hand, if you want to avoid any voice quality degradation (in other words, no failure detection by the user), then your rerouting time objective will probably be on the order of a few tens of ms. Is there a golden number one should never exceed ? Certainly not .... but a few tens of ms is undoubtedly a good target reasonably achievable in the vast majority of the failure cases (provided a fast failure detection at the lower level). Many tests have been conducted during the last few years that showed a significant MOS degradation when exceeding a few hundreds of ms. JP. > If you invoke protection too quickly you can make things far worse > than > letting the (for example) error event just go away. However, this > depends on the layer network you are considering. If you really are > down close to the physical media/section level (and not some > artificial > inversion of this as per PWE3) the OAM defect detection/handling ought > to be fast.....and so in such a case its is sensible to invoke > protection once it is truly known this is a real failure case. > > regards, Neil > >> >> -- David >> >> _______________________________________________ >> mpls mailing list >> mpls@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/mpls >> >> > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 11 09:24:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3D2W-000874-Rt; Thu, 11 Aug 2005 09:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3D2U-00086r-2i for mpls@megatron.ietf.org; Thu, 11 Aug 2005 09:24: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 JAA01135 for ; Thu, 11 Aug 2005 09:24:04 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Dal-0004ka-O7 for mpls@ietf.org; Thu, 11 Aug 2005 09:59:34 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j7BDNpFV026917 for ; Thu, 11 Aug 2005 09:23:51 -0400 (EDT) Received: from [169.144.136.107] (usvisdad104641.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA02332 for ; Thu, 11 Aug 2005 09:23:50 -0400 (EDT) Message-ID: <42FB5166.3050103@marconi.com> Date: Thu, 11 Aug 2005 09:23:50 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Dutta, Pranjal wrote: > Hi, > I think most of the vendors implement min 1 seconds as > hello-intervals as lesser than that might lead to scalability issues (I > am not sure if that is the reason why vendors implement at least 1 sec). > Hardware level detection will be possible only when physical layer has > end-to-end signaling mechanism for failure. In the case where end-to-end > signaling mechanism is not possible, the PLR will still see that link is > up and keep forwarding traffic to downstream LSR, but actually the link > is failed. I am basically looking for some mechanism that can detect > "Node Failure" as early as possible and PLR will initiate node > protection accordingly. I think some kind of OAM mechanism might help. I think you're misunderstanding the purpose of fast reroute. Fast reroute is designed to kick in only when the immediate downstream neighbor has failed. Detecting link-level failure in hardware is perfectly fine for this. If the failure takes place elsewhere in the network, then either the node immediately upstream of the failure must use FRR, or some other mechanism must be used to reroute the traffic. You would never want to trigger an FRR failover in response to an end-to-end detectino mechanism. One big reason is tha any end-to-end system will take so long to detect the failure that there would be little advantage to FRR vs. simple switching the traffic to a standby LSP (1:1 or 1+1 protection). Second, an end-to-end mechanism may detect a failure anywhere along the path. If the failed node is not your immediate downstream neighbor, your bypass/detour LSPs may not even work to route around the failure. And if a downstream node also uses FRR, the multiple simultaneous attempts at local-repair may well step on each other, making the situation worse. If you want your originating node to detect the failure with an end-to-end mechanism and then signal the node upstream of the failure to begin FRR, why bother? The amount of time it would take for this would be longer than the time to simply compute a new path and signal a new LSP. (I'm assuming that that node can't detect its downstream neighbor's failure directly, because if it could, there would be no need for any end-to-end mechanism in the first place.) -- David _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 11 10:06:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3DhT-0000Yd-Rz; Thu, 11 Aug 2005 10:06:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3DhQ-0000YT-Kc for mpls@megatron.ietf.org; Thu, 11 Aug 2005 10:06:25 -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 KAA03546 for ; Thu, 11 Aug 2005 10:06:22 -0400 (EDT) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3EFj-0005mn-DQ for mpls@ietf.org; Thu, 11 Aug 2005 10:41:53 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id HAA06594; Thu, 11 Aug 2005 07:05:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 Date: Thu, 11 Aug 2005 19:35:55 +0530 Message-ID: Thread-Topic: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 Thread-Index: AcWdxlSfyRGYV4oFSaeOBrd0BK2DGAAZte1wAAPONoAAD/CR8A== From: "Dutta, Pranjal" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Richard, Please refer inline. -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com]=20 Sent: Thursday, 11 August, 2005 12:40 PM To: Dutta, Pranjal; David.Charlap@marconi.com Cc: mpls@ietf.org Subject: RE: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 Pranjal, Total node failures (i.e. a node completely dies) will be detected by all directly connected peers as the links will go down at the physical layer. If you want to detect IP/MPLS layer failures, the IETF's protocol for doing this is BFD (see: http://www.ietf.org/html.charters/bfd-charter.html). You can run BFD on a per LSP basis (in the data plane) and also at the IP forwarding level (essentially in the control plane) and the detection time is user configurable. Pranjal: Yes, I completely agree with this. Right now it seems we are having BFD as the most viable option. However, I think its unlikely that you will be able to achieve reliable failure detection much faster than 500ms-1000ms. If the nodes supported it, you could adjust the timers to detect failures quicker than this but the network would be highly susceptible to false failures due to things like network congestion and short error bursts. Also, running multiple BFD sessions with very fast detection rates will consume a significant amount of processing resources.=20 Pranjal: Along with the point you have raised I do see another thread here. 5 ms of hello timers might solve the problem but it has to be done at hardware layer for accurate timings and scalabilty. But to reduce hello interval to milliseconds level, it would raise false failures due to short congestion/error bursts when hellos are missed. We might see instability at PLR due to this as there would be frequent switchover between paths. In general, when considering failure protection there is a tradeoff between network reliability and fast switchover. IMO, optimising a large SP network to protect against specific failures (i.e. MPLS node forwarding plane failures) faster than 500ms-1000ms (at the expense of processing resources and network reliability) is unlikely to be technically or commercially viable. Pranjal: Since we have OAM mechanisms to tackle re-route at physical layer (like APS in SONET etc. etc), we can live with link failures to a certain extent. The problem will be more prominent in Node failure case. Yes,any such fast protection might not carry the OPEX/Commercial viability.=20 You mentioned packet loss for voice/video traffic in your original email, what do you think the impact of a 500ms-1000ms loss will have at the application layer? Can you give some examples? Pranjal: I was pointing to some applications like MPEG-2 SD/HD video frames which will carry at least 30 frames (I+P+B frames) a second.In that case we see the affect in video traffic. Thanks, Pranjal Regards, Richard > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org]On > Behalf Of Dutta, Pranjal > Sent: 11 August 2005 05:39 > To: David Charlap > Cc: mpls@ietf.org > Subject: [mpls] Re: Reg: Fast Reroute Timings in RFC 4090 >=20 >=20 >=20 > Hi, > I think most of the vendors implement min 1 seconds as > hello-intervals as lesser than that might lead to scalability=20 > issues (I > am not sure if that is the reason why vendors implement at=20 > least 1 sec). > Hardware level detection will be possible only when physical layer has > end-to-end signaling mechanism for failure. In the case where=20 > end-to-end > signaling mechanism is not possible, the PLR will still see=20 > that link is > up and keep forwarding traffic to downstream LSR, but=20 > actually the link > is failed. I am basically looking for some mechanism that can detect > "Node Failure" as early as possible and PLR will initiate node > protection accordingly. I think some kind of OAM mechanism might help. >=20 > Thanks, > Pranjal >=20 >=20 >=20 > Date: Wed, 10 Aug 2005 10:02:20 -0400 > From: David Charlap > Subject: Re: [mpls] Reg: Fast Reroute Timings in RFC 4090 > To: mpls@ietf.org > Message-ID: <42FA08EC.8050502@marconi.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > Dutta, Pranjal wrote: > >=20 > > As per RFC 4090- Fast Reroute Extensions to=20 > RSVP-TE for >=20 > > LSP Tunnels, it takes 10 ms to reroute the LSP at PLR either by > facility=20 > > back up or one-to-one back up method. The re-route timing is > definitely=20 > > lesser when compared to time taken for global rerouting (at Ingress=20 > > LSR). My concern is PLR will reroute the LSP locally only=20 > when it has=20 > > the fault notification (after missing hellos from the downstream=20 > > neighbor). Assuming that min 1 second of RSVP hello=20 > interval is being=20 > > used, it will take at least 1 second in total to re-route=20 > the traffic=20 > > locally which will lead to loss of voice/video packets and affects=20 > > traffic performance. I would like to know if there is some effort > going=20 > > on in this group to address this issue. Any pointers will=20 > be helpful. >=20 > First of all, the Hello interval may be faster than 1s,=20 > depending on the >=20 > implementation. The RFC actually recommends 5ms intervals,=20 > but I don't=20 > know if anyone actually implements that rate. >=20 > Second, a switch may detect a link failure by means other=20 > than loss of=20 > RSVP-Hello. For instance, the hardware may detect a loss of=20 > carrier on=20 > the interface. (As a matter of fact, I would expect hardware=20 > detection=20 > of link failure to be the only way that can reroute traffic=20 > fast enough=20 > for real-time applications.) >=20 > If a switch loses RSVP Hellos, but does not lose carrier,=20 > then the link=20 > is still physically active. It is probably still forwarding=20 > data-plane=20 > traffic as well (even though the control plane has probably=20 > failed.) So >=20 > actual losses may not be nearly as severe as you are assuming. >=20 > -- David >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 >=20 > End of mpls Digest, Vol 16, Issue 7 > *********************************** >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 11 10:20:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Duy-0004Gb-Md; Thu, 11 Aug 2005 10:20:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Duw-0004GV-3x for mpls@megatron.ietf.org; Thu, 11 Aug 2005 10:20:22 -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 KAA05010 for ; Thu, 11 Aug 2005 10:20:20 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ETF-00069I-Cf for mpls@ietf.org; Thu, 11 Aug 2005 10:55:50 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 15:20:05 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 15:20:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Reg: Fast Reroute Timings in RFC 4090 Date: Thu, 11 Aug 2005 15:20:04 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1EE2@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [mpls] Reg: Fast Reroute Timings in RFC 4090 Thread-Index: AcWeY8DJsk1fDvL6SL26x6Bu513CbwAFdKxQ To: X-OriginalArrivalTime: 11 Aug 2005 14:20:05.0379 (UTC) FILETIME=[C50AED30:01C59E7F] X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, David.Charlap@marconi.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Thanks JP, who wrote 11 August 2005 12:00 > > However...and having said all that.....I am always puzzled why some=20 > > folks think really rapid restoration MUST be done for=20 > voice. I can't=20 > > believe anyone would clear down a call after 10s, 100s or=20 > maybe even a=20 > > few 1000 ms of loss. I know there is some macho 'must equal/beat > > SDH's > > 50ms' mindset at work here.....but this is nuts. I know=20 > the folks who > > set the 50ms defect detection threshold in SDH and this was NOT =20 > > done to > > accomodate voice, or any application for that matter. It was simply > > down to the physics and ring topologies being considered. > > >=20 > That really depends on your targeted SLA ... If indeed the=20 > goal is to =20 > avoid a drop call, you're absolutely right, 1-2s is probably good =20 > enough depending on the VoIP GTW. On the other hand, if you want to =20 > avoid any voice quality degradation (in other words, no failure =20 > detection by the user), then your rerouting time objective will =20 > probably be on the order of a few tens of ms. Is there a golden =20 > number one should never exceed ? Certainly not .... but a few=20 > tens of =20 > ms is undoubtedly a good target reasonably achievable in the vast =20 > majority of the failure cases (provided a fast failure detection at =20 > the lower level). Many tests have been conducted during the last few =20 > years that showed a significant MOS degradation when exceeding a few =20 > hundreds of ms. >=20 > JP. NH=3D> If we could protect instantly that would be the best. Unfortunately you can trigger unnecessary protection events by going too quickly, eg an error event causing one lost OAM pkt, and thus cause more harm than good......especially if you have to make choice on *which* traffic to restore if there is a resource shortfall following a failure. Voice traffic may not be the most important traffic (and BTW there is no relationship between an application's QoS requirements and its survivability importance). So you need some integration period over which you make sure this is a real failure event and not some transient error event. And I as I noted earlier it all depends which layer network you are considering the failures reside in...the rule (of thumb) is as I stated before: closer to the duct the faster, closer to the application the slower. Further, if you have no sense of harmonisation/alignment across the layer networks then you can be invoking protection unnecessarily at the wrong layer network. This is not a good thing either. However, I have a question. What MPLS OAM mechanisms are you assuming are being used here? I am not interested in defects in the co-cs mode layer networks (like SDH, I know about these) but I am particularly interested to understand what MPLS layer defects you are referring to (because these cannot be detected by lower layer networks), and what the entry/exit criteria and consequent actions are that you would use here and where these are defined. Note - I note you mention SLAs...and I agree these are very important. Now an SLA has 2 related (but quite distinguishable) parts: A part that defines the amount of unavailability (ie down-time) that is allowed, and a part that defines the network transfer performance impairments that are allowed when available (ie up-time). So in order to define SLAs, and please note this also includes apportioning impairment allowances to different operators domains when interworking, then its rather important to have some standardised metrics and their objectives agreed here for these 2 parts of the SLA. However, to define the Network Performance SLA part you must know whether the trail is up or down....which means you must have defined the entry/exit criteria for unavailability (as Net Perf metric collection for SLA purposes must be suspended when unavailable).....and in order to specify the availability SLA part you must 1st have clearly defined defects with entry/exit criteria and consequent actions. Hence, to even talk about SLAs we must start with knowing where the defects are defined....hence my question above. regards, Neil=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Aug 12 09:45:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Zqq-00047A-BR; Fri, 12 Aug 2005 09:45:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Zqo-000475-BZ for mpls@megatron.ietf.org; Fri, 12 Aug 2005 09:45:34 -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 JAA22643 for ; Fri, 12 Aug 2005 09:45:29 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3aPI-0001KP-6N for mpls@ietf.org; Fri, 12 Aug 2005 10:21:13 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j7CDiG206533 for ; Fri, 12 Aug 2005 15:44:16 +0200 Received: from [127.0.0.1] ([172.16.2.224]) by mail1.imc.kth.se; Fri, 12 Aug 2005 15:41:56 +0200 Message-ID: <42FCA71D.5050901@pi.se> Date: Fri, 12 Aug 2005 15:41:49 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: [mpls] Working group last call on draft-ietf-mpls-rfc3036bis-02.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Working group, this is to initiate a MPLS working group last call on draft-ietf-mpls-rfc3036bis-01.txt The LDP spec has been updated based on operational and implementational experiences and will requested to be published as a Draft Standard. The working group last call ends 11.59PM PST on Friday August 26. The package needed for taking the LDP spec to draft standard also includes the following two drafts draft-thomas-mpls-ldp-survey2002-00.txt and draft-minei-ldp-operational-experience-01.txt at the same time we ask for working group consensus to make them working group documents. /Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Aug 15 08:01:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4den-0004BU-Pd; Mon, 15 Aug 2005 08:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4dem-0004Az-Mk for mpls@megatron.ietf.org; Mon, 15 Aug 2005 08:01:32 -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 IAA28298 for ; Mon, 15 Aug 2005 08:01:31 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4eDs-00059Z-8z for mpls@ietf.org; Mon, 15 Aug 2005 08:37:50 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j7FC0P200830 for ; Mon, 15 Aug 2005 14:00:25 +0200 Received: from [127.0.0.1] ([172.16.2.224]) by mail1.imc.kth.se; Mon, 15 Aug 2005 13:58:33 +0200 Message-ID: <43008366.8060606@pi.se> Date: Mon, 15 Aug 2005 13:58:30 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: [mpls] working group last call on draft-ietf-mpls-ecmp-bcp X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Working, draft-ietf-mpls-ecmp-bcp was working group last called in March, and has been updated according to comments. This mail initiates a one week (+) working group last call draft-ietf-mpls-ecmp-bcp-01.txt, limited to the changes. Please send comments to mpls mailing list, or directly to the working group co-chairs. The working group last call ends on EOB PST Wed Aug 24. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Aug 15 11:49:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hDg-0000dj-EU; Mon, 15 Aug 2005 11:49:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hDe-0000de-RK for mpls@megatron.ietf.org; Mon, 15 Aug 2005 11:49:46 -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 LAA09647 for ; Mon, 15 Aug 2005 11:49:44 -0400 (EDT) From: kkhanna@isocore.com Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4hmk-0001ru-PS for mpls@ietf.org; Mon, 15 Aug 2005 12:26:07 -0400 Received: from cpanel by ns1.cpanel.btnaccess.com with local (Exim 4.52) id 1E4hDO-0007R7-Ea for mpls@ietf.org; Mon, 15 Aug 2005 11:49:30 -0400 Received: from 65.213.193.37 ([65.213.193.37]) by www.isocore.com (Horde MIME library) with HTTP for ; Mon, 15 Aug 2005 11:49:30 -0400 Message-ID: <20050815114930.im8ojyqh1aggocss@www.isocore.com> Date: Mon, 15 Aug 2005 11:49:30 -0400 To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] Important Info: MPLS 2005 (October 16-19; Washington DC) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Greetings, You are invited to participate in the premier event on MPLS and related technologies at the MPLS 2005 International Conference () to be held from October 16-19, 2005 in Washington DC. PROGRAM: ---------- The conference includes presentations by leading exterts on hot topics in MPLS and GMPLS, tutorials, exhibits by key vendors, a panel discussion by Service Providers on Advanced Services using MPLS, and a panel discussion by industry vendors on LDP versus RSVP-TE. Program details are available at: REGISTRATION: -------------- Registration is underway - to register, go to: HOTEL RESERVATIONS: -------------------- The designated Hotel for the MPLS 2005 International Conference is the Omni Shoreham Hotel in Washington, D.C. (Tel: 202-234-0700 or 800-843-6664). A limited number of rooms are available at special rates for conference attendees. We suggest you make your reservation as soon as possible, since October is typically a busy period for hotels in Washington DC. To make reservations please call the Hotel Reservation Desk directly. You must identify yourself as MPLS 2005 conference attendees for discounted rates. We look forward to your participation in this event. Regards, Kavita _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Aug 15 12:38:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hyQ-0000G8-9Q; Mon, 15 Aug 2005 12:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hyN-0000Dy-Vf for mpls@megatron.ietf.org; Mon, 15 Aug 2005 12:38:04 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12337 for ; Mon, 15 Aug 2005 12:38:01 -0400 (EDT) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E4hyN-0001KU-GD; Mon, 15 Aug 2005 12:38:03 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 15 Aug 2005 12:38:03 -0400 Cc: mpls@ietf.org Subject: [mpls] Last Call: 'Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition' to Proposed Standard X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org The IESG has received a request from the Multiprotocol Label Switching WG to consider the following document: - 'Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition ' 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-08-29. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-lc-if-mib-06.txt _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Aug 16 08:20:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50R1-0003Jo-IV; Tue, 16 Aug 2005 08:20:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50R0-0003JZ-83 for mpls@megatron.ietf.org; Tue, 16 Aug 2005 08:20: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 IAA06567 for ; Tue, 16 Aug 2005 08:20:48 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E510I-0007hA-AS for mpls@ietf.org; Tue, 16 Aug 2005 08:57:21 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j7GCJR200674 for ; Tue, 16 Aug 2005 14:19:27 +0200 Received: from [127.0.0.1] ([172.16.2.224]) by mail1.imc.kth.se; Tue, 16 Aug 2005 14:17:34 +0200 Message-ID: <4301D95C.9090605@pi.se> Date: Tue, 16 Aug 2005 14:17:32 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for working document? X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Working group, in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" there were good support for making a working group document and we seek the input from the working group om the mailing list to decide the consensus. Please send your opinion to the mailing list. Context: It is understood tht more work needs to be done on the LDP aspects of p2mp ping, if this goes into this document or a separate document is an open issue. In Paris it was also pointed out that we need to collect the requirments for p2mp ping, the authors would like to draw attention to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to fill this need. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Aug 16 11:15:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53A3-0008Si-79; Tue, 16 Aug 2005 11:15:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53A0-0008Rr-AJ for mpls@megatron.ietf.org; Tue, 16 Aug 2005 11:15:28 -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 LAA17383 for ; Tue, 16 Aug 2005 11:15:25 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E53jM-0003qF-2h for mpls@ietf.org; Tue, 16 Aug 2005 11:52:00 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j7GFEI204358 for ; Tue, 16 Aug 2005 17:14:18 +0200 Received: from [127.0.0.1] ([172.16.2.224]) by mail1.imc.kth.se; Tue, 16 Aug 2005 17:12:10 +0200 Message-ID: <430201CE.6080005@pi.se> Date: Tue, 16 Aug 2005 17:10:06 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by oberon.imc.kth.se id j7GFEI204358 X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Content-Transfer-Encoding: quoted-printable Cc: Bill Fenner Subject: [mpls] draft mpls wg minutes X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org All, this is a draft version of the mpls working group notes from the Paris meeting. I would like to ask especially people that made presentation to review the agenda items that relates to their presentaions. Comments to me and/or the list before eob Tue Aug 23rd. Also make sure I've all slides that were used. If you are uncertain - please send! /Loa -------------------------------------------------------------------------= ---- Multi-Protocol Label Switching WG (mpls) MONDAY, August 1 at 10:30 - 12:30 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Loa Andersson George Swallow AGENDA: 1. ICMP interactions with MPLS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Ron Ron gave a short background; ICMP as specified in RFC792, does not have=20 a mechanism to report MPLS header information when a router fails to=20 deliver a packet. The MPLS WG processed a draft on MPLS extensions (an=20 object to report the MPLS header) for ICMP and requested that the draft=20 should be published as an RFC on the Standards track. The IESG decided=20 not to publish it because of "layer violation". However the draft has=20 been widely implemented and is an integrated part of most MPLS=20 implementations. The draft has now been resurrected < draft-ietf-mpls-icmp-03>, and the=20 discussion is what work we need to undertake get it published. It was pointed out that we can=92t change anything in the technical=20 details. This needs to be coordinated with the Internet Area, and one Suggestion is to move the parts that are not MPLS specific into a draft=20 that the Internet Area will progress, while the MPLS specific parts goes=20 through the MPLS working group. Ron will discuss this in the Internet Area meeting and we will await the=20 outcome of this discussion. 2. Agenda bashing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Apart from moving the discussion on MPLS ICMP, to the top of the agenda=20 to make possible for Ron to present the same topic in the Internet Area=20 meeting (taking place at the same time), there were no other changes in=20 agenda. 3. Working group status =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Working group chairs reported on the status of working group documents: Parking Place ------------- We have a new =93parking place=94, i.e. a web site that lists all documen= ts=20 that IESG have approved to be published as RFCs. The parking place is=20 located at: http://rtg.ietf.org:8080/Test/parking New RFCs from the MPLS working group since last meeting: ------------------------------------------------------- RFC 4090 Fast Reroute Extensions for RSVP-TE for LSP Tunnels Working group documents in RFC-ed queue: ---------------------------------------- draft-ietf-mpls-lsp-hierarchy-08.txt (2002-04-11!) draft-ietf-mpls-bundle-06.txt draft-ietf-mpls-telink-mib-07.txt draft-ietf-mpls-explicit-null-02.txt draft-ietf-mpls-mgmt-overview-09.txt We have documents that have been stuck in the RFC-editors queue for some=20 time. Actually the oldest document in the queue comes from the MPLS=20 working group. Working group documents in parking place: ----------------------------------------- None Working group documents in IESG review: --------------------------------------- draft-ietf-mpls-ecmp-bcp-01.txt (publication requested) draft-ietf-mpls-lc-if-mib-06.txt (new ID needed) draft-ietf-mpls-lsp-ping-09.txt (new ID needed) draft-ietf-mpls-nodeid-subobject-05.txt (ietf last call) draft-ietf-mpls-bgp-mpls-restart (IESG evaluation) draft-ietf-mpls-rsvpte-attributes (IESG evaluation) MPLS working group drafts: -------------------------- draft-ietf-mpls-lsr-self-test draft-ietf-mpls-oam-frmwk draft-ietf-mpls-oam-requirements-06.txt (dated) draft-ietf-mpls-over-l2tpv3 draft-ietf-mpls-p2mp-sig-requirement draft-ietf-mpls-rsvp-te-p2mp draft-ietf-mpls-rfc3036bis-01.txt (dated) draft-ietf-mpls-soft-preemption 4. LDP to Draft Standards =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Ina draft-ietf-mpls-rfc3036bis-01.txt has gone through minor editing and is=20 ready for WG last call. draft-minei-ldp-operational-experience-01.txt has been refreshed, it is=20 a required informational reference for advancing the BIS draft. Please=20 provide this draft with in depth review. One additional draft - protocol analysis - is also required (RFC 1264)=20 to take LDP to draft standard to receive in depth review. The packages we need to prepare for taking LDP to Draft Standard also=20 include . Working group chairs will start the Working Last Call on the LDP=20 document and poll the list for making the implementation survey and the=20 operational experiences working group documents. 5. MPLS OAM =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LSR Self Test ------------- George This draft has been waiting for the LSP Ping to clear working last call.=20 This has now happened and after minor changes it is ready go to working=20 group last call. P2MP LSP Ping ------------- Adrian Since the meeting in Minneapolis a new work from Bill Fenner (new=20 co-author) has been added and the objectives have been made more=20 precise. Currently it is possible to ping one specific leaf or the whole=20 tree. There was a good support for making it a working group document. Working=20 group chairs will confirm this based on input on the working group=20 mailing list. Tom The draft addresses issues for using the base LSP Ping in Inter AS=20 contexts. Although there is a need to complete some sections of the=20 draft the authors ask for feedback. One problem with using base LSP Ping=20 is that the IP address found in the packet need not be routable if the=20 forwarding failure occurs in an AS to which the AS where the packet=20 originates does not announce the address that is found =93under=94 the MP= LS=20 label. The indicated solution is to record the ASBR that the LSP Ping=20 packet passes through, and if a failure occurs return the packet to the=20 ASBR. P2MP OAM requirements --------------------- draft-yasukawa-mpls-p2mp-oam-reqs-00.txt Tom The document addresses issues on how to detect and report data plane=20 failures. Tom thinks that the document is a little rough; it needs a=20 clarification and additional review. The P2MP OAM requirements should go=20 into a document of its own and needs to address both diagnostic and=20 periodic OAM. Input from Service Providers and careful review is importan= t. Loa asked who has read and who supported this to become a working group=20 document. Among those who have read the document there is a good support=20 for making it a working group document. Needs to be confirmed on the list. 6. MPLS Multicast and MPLS P2MP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Rahul Rahul said that version -02 was recently published, according the=20 authors it is not entirely ready for last called and a version -03 is=20 planned. The working group should take the opportunity to read and commen= t. Rahul The background is that there is some inconsistency between what RFC3032=20 says about multicast and unicast, and the actual requirements. The three=20 drafts discuss separate aspects of this and propose mechanisms solutions=20 to some of the problems. One of the mechanisms that are introduced is upstream label allocation=20 (UAL). The drafts also concluded that it is not necessary to have one=20 code point allocated for unicast and one for multicast, since this is=20 given by context in the NHLFE. Conclusion is that there is some need to revisit how code points have=20 been assigned. Instead of assigning one code point for unicast (8847)=20 and one for multicast (8848), the draft suggests that the code points=20 are used for downstream allocated (8847) and upstream allocated (8848). The concept of =93Neighbor specific labels=94 is introduced since this is= =20 required for support of upstream assigned labels. With UAL - the context=20 of a label is derived from the neighbor from whom the labeled packet was=20 sent. The chairs asked how many had read the drafts and who thought they need=20 to become working group drafts. Neither the amount of people who have=20 read the drafts nor the support for making them working group drafts was=20 conclusive. The working group chairs will take steps to initiate a discussion on the=20 mailing list. Adrian pointed out that the LDP and RSVP-TE aspects are=20 split out in separate drafts. The working group co-chairs strongly=20 supported this. Authors agreed to this. MPLS Multicast -------------- Jean-Louis Jean-Louis discussed the multicast requirements that are emerging in MPLS VPN applications. Extending LDP is a fairly low complexity route=20 to support P2MP LSP setup requirements. The discussion brought up issues like why it is appropriate to have a leaf-initiated protocol in the p2mp case when this was not the case in=20 the TE case. The benefits of shared trees vs. source based trees were=20 discussed. George pointed out that some of the requirements are on the IGP routing=20 rather than MPLS or LDP. Since this work is not captured in the working group milestones we need=20 to ask the ADs if we can update the working group charter. Only after=20 that we can accept this as a working group document. George asked for a sense of how many people were interested in doing this work in this WG. Many hands were raised. The working group=20 chairs will bring this to the ADs. Ina To extend LDP for p2mp is an attractive option since LDP is widely=20 deployed. In these networks there might be a need for p2mp LSPs, but=20 deploying RSVP-TE might be considered too much of a cost. Ice This draft also proposes extensions to LDP for multicast, there seems to=20 be enough overlap between two drafts to look into if there is a=20 possibility to merge them into one. The author agreed to this. BGP Point to Multipoint LSP --------------------------- Satoru Matsushima Due to lack of time it was not possible to make this presentation. 6. Inter-AS LDP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruno Due to lack of time it was not possible to make this presentation. 7. End of meeting --=20 Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Aug 16 15:50:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57Rk-00085O-Dg; Tue, 16 Aug 2005 15:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57Ri-00084C-9v for mpls@megatron.ietf.org; Tue, 16 Aug 2005 15:50:02 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01810 for ; Tue, 16 Aug 2005 15:50:00 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E57Rh-0007HU-VB; Tue, 16 Aug 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: Tue, 16 Aug 2005 15:50:01 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-bgp-mpls-restart-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Graceful Restart Mechanism for BGP with MPLS Author(s) : Y. Rekhter, R. Aggarwal Filename : draft-ietf-mpls-bgp-mpls-restart-05.txt Pages : 11 Date : 2005-8-16 A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed an is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to also minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart. The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such it works in conjunction with any of the address famililies that could be carried in BGP (e.g., IPv4, IPv6, etc...) The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve their forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanism described in this document). Supporting a subset of the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp-mpls-restart-05.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-mpls-bgp-mpls-restart-05.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-mpls-bgp-mpls-restart-05.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-8-16130846.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bgp-mpls-restart-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bgp-mpls-restart-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-16130846.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Tue Aug 16 19:00:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5APv-0003IP-NH; Tue, 16 Aug 2005 19:00:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5APt-0003Hd-Mp for mpls@megatron.ietf.org; Tue, 16 Aug 2005 19:00:21 -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 TAA18880 for ; Tue, 16 Aug 2005 19:00:18 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5AzJ-0001Tu-5x for mpls@ietf.org; Tue, 16 Aug 2005 19:36:58 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 95A5DE000175 for ; Tue, 16 Aug 2005 23:59:55 +0100 (BST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for workingdocument? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 16 Aug 2005 23:59:32 +0100 Message-ID: Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for workingdocument? Thread-Index: AcWiXTtF/n1b/qMhSB+MiT1u7i8hAQAI5hLwAA1GBuA= From: "Daniel King" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Guys, I would like to support this becoming a working group document. Dan Daniel King dan@dnni.com -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, August 16, 2005 1:18 PM To: mpls@ietf.org Cc: Bill Fenner Subject: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for workingdocument? Working group, in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" there were good support for making a working group document and we seek the input from the working group om the mailing list to decide the consensus. Please send your opinion to the mailing list. Context: It is understood tht more work needs to be done on the LDP aspects of p2mp ping, if this goes into this document or a separate document is an open issue. In Paris it was also pointed out that we need to collect the requirments for p2mp ping, the authors would like to draw attention to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to fill this need. Loa and George --=20 Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Aug 17 12:25:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Qj2-0003sf-6K; Wed, 17 Aug 2005 12:25:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Qj0-0003sa-Hj for mpls@megatron.ietf.org; Wed, 17 Aug 2005 12:25:10 -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 MAA10082 for ; Wed, 17 Aug 2005 12:25:07 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5RIY-0004WF-Ar for mpls@ietf.org; Wed, 17 Aug 2005 13:01:56 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 17 Aug 2005 09:25:00 -0700 X-IronPort-AV: i="3.96,118,1122879600"; d="scan'208"; a="205516267:sNHT30895106" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7HFef36013703; Wed, 17 Aug 2005 08:41:09 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 11:41:11 -0400 Received: from [192.168.1.101] ([10.86.242.241]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 11:41:09 -0400 In-Reply-To: <4301D95C.9090605@pi.se> References: <4301D95C.9090605@pi.se> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <28142B5E-BBB5-45C8-B1B7-A493D48A6110@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for working document? Date: Wed, 17 Aug 2005 11:41:34 -0400 To: Loa Andersson X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 17 Aug 2005 15:41:09.0562 (UTC) FILETIME=[16CCD9A0:01C5A342] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Bill Fenner , mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org In favor. JP. On Aug 16, 2005, at 8:17 AM, Loa Andersson wrote: > Working group, > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > there were good support for making a working group document and > we seek the input from the working group om the mailing list to > decide the consensus. Please send your opinion to the mailing list. > > Context: It is understood tht more work needs to be done on the > LDP aspects of p2mp ping, if this goes into this document or a > separate document is an open issue. > In Paris it was also pointed out that we need to collect the > requirments for p2mp ping, the authors would like to draw attention > to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to > fill this need. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Aug 17 13:16:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5RWp-0000YJ-0y; Wed, 17 Aug 2005 13:16:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5RWm-0000YA-Vu for mpls@megatron.ietf.org; Wed, 17 Aug 2005 13:16:37 -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 NAA12372 for ; Wed, 17 Aug 2005 13:16:33 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5S6F-0005mx-Am for mpls@ietf.org; Wed, 17 Aug 2005 13:53:19 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA24473; Wed, 17 Aug 2005 12:16:04 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j7HHG3s00804; Wed, 17 Aug 2005 10:16:03 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 10:15:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for workingdocument? Date: Wed, 17 Aug 2005 10:15:43 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369461@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for workingdocument? Thread-Index: AcWiXT+st17gM9OqSpmAgsH6htiXXAA8fzvQ From: "Drake, John E" To: "Loa Andersson" , X-OriginalArrivalTime: 17 Aug 2005 17:15:44.0060 (UTC) FILETIME=[4D1087C0:01C5A34F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: Bill Fenner X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org It should be a working group document > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Tuesday, August 16, 2005 5:18 AM > To: mpls@ietf.org > Cc: Bill Fenner > Subject: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for > workingdocument? >=20 > Working group, >=20 > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > there were good support for making a working group document and > we seek the input from the working group om the mailing list to > decide the consensus. Please send your opinion to the mailing list. >=20 > Context: It is understood tht more work needs to be done on the > LDP aspects of p2mp ping, if this goes into this document or a > separate document is an open issue. > In Paris it was also pointed out that we need to collect the > requirments for p2mp ping, the authors would like to draw attention > to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to > fill this need. >=20 > Loa and George >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Aug 17 13:30:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Rkh-00058W-GX; Wed, 17 Aug 2005 13:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Rke-00058R-S3 for mpls@megatron.ietf.org; Wed, 17 Aug 2005 13:30:56 -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 NAA13561 for ; Wed, 17 Aug 2005 13:30:53 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5SKE-0006LA-82 for mpls@ietf.org; Wed, 17 Aug 2005 14:07:43 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 17 Aug 2005 10:30:00 -0700 X-IronPort-AV: i="3.96,118,1122879600"; d="scan'208"; a="205540148:sNHT1227437612" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7HHTe2w024283; Wed, 17 Aug 2005 10:29:57 -0700 (PDT) Received: from xmb-rtp-216.amer.cisco.com ([64.102.31.80]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 13:29:46 -0400 Received: from [161.44.192.105] ([161.44.192.105]) by xmb-rtp-216.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 13:29:45 -0400 Message-ID: <43037408.1050708@cisco.com> Date: Wed, 17 Aug 2005 13:29:44 -0400 From: Anca Zamfir User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Loa Andersson Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for working document? References: <4301D95C.9090605@pi.se> In-Reply-To: <4301D95C.9090605@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2005 17:29:45.0938 (UTC) FILETIME=[42DCEB20:01C5A351] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Bill Fenner , mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org In favor. Anca Loa Andersson wrote: > Working group, > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > there were good support for making a working group document and > we seek the input from the working group om the mailing list to > decide the consensus. Please send your opinion to the mailing list. > > Context: It is understood tht more work needs to be done on the > LDP aspects of p2mp ping, if this goes into this document or a > separate document is an open issue. > In Paris it was also pointed out that we need to collect the > requirments for p2mp ping, the authors would like to draw attention > to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to > fill this need. > > Loa and George > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Aug 17 14:09:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SLe-0006XT-0I; Wed, 17 Aug 2005 14:09:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SLa-0006Uw-9C for mpls@megatron.ietf.org; Wed, 17 Aug 2005 14:09:07 -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 OAA15149 for ; Wed, 17 Aug 2005 14:09:04 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Sv8-0007HR-SC for mpls@ietf.org; Wed, 17 Aug 2005 14:45:53 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Aug 2005 11:08:37 -0700 X-IronPort-AV: i="3.96,118,1122879600"; d="scan'208"; a="333093913:sNHT6603582310" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7HI7wpG013097; Wed, 17 Aug 2005 11:08:35 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 14:08:29 -0400 Received: from msiva-w2k01.cisco.com ([161.44.193.171]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 14:08:28 -0400 Message-Id: <4.3.2.7.2.20050817140759.032ba7c0@email.cisco.com> X-Sender: msiva@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Aug 2005 14:08:27 -0400 To: "Drake, John E" From: "Siva Sivabalan (msiva)" Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for workingdocument? In-Reply-To: <626FC7C6A97381468FB872072AB5DDC8369461@XCH-SW-42.sw.nos.bo eing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Aug 2005 18:08:28.0781 (UTC) FILETIME=[AB62A1D0:01C5A356] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mpls@ietf.org, Bill Fenner X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org in favor. At 10:15 AM 8/17/2005 -0700, Drake, John E wrote: >It should be a working group document > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.se] > > Sent: Tuesday, August 16, 2005 5:18 AM > > To: mpls@ietf.org > > Cc: Bill Fenner > > Subject: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for > > workingdocument? > > > > Working group, > > > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > > there were good support for making a working group document and > > we seek the input from the working group om the mailing list to > > decide the consensus. Please send your opinion to the mailing list. > > > > Context: It is understood tht more work needs to be done on the > > LDP aspects of p2mp ping, if this goes into this document or a > > separate document is an open issue. > > In Paris it was also pointed out that we need to collect the > > requirments for p2mp ping, the authors would like to draw attention > > to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to > > fill this need. > > > > Loa and George > > > > -- > > Loa Andersson > > > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Aug 17 14:28:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SeF-0003ne-0t; Wed, 17 Aug 2005 14:28:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SeC-0003mb-Vp for mpls@megatron.ietf.org; Wed, 17 Aug 2005 14:28:21 -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 OAA15934 for ; Wed, 17 Aug 2005 14:28:19 -0400 (EDT) Received: from plmler4.mail.eds.com ([199.228.142.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5TDl-0007kA-Jh for mpls@ietf.org; Wed, 17 Aug 2005 15:05:08 -0400 Received: from plmlir3.mail.eds.com (plmlir3-2.mail.eds.com [199.228.142.133]) by plmler4.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7HIS4vF007410; Wed, 17 Aug 2005 13:28:07 -0500 Received: from plmlir3.mail.eds.com (localhost [127.0.0.1]) by plmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7HIRGWH023869; Wed, 17 Aug 2005 13:27:16 -0500 Received: from usplm013.amer.corp.eds.com (USPLM003.txpln.us.eds.com [198.132.135.8]) by plmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7HIRGUH023864; Wed, 17 Aug 2005 13:27:16 -0500 Received: from usplm233.amer.corp.eds.com ([198.132.135.26]) by usplm013.amer.corp.eds.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 13:27:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdocument? Date: Wed, 17 Aug 2005 13:27:04 -0500 Message-ID: <0D02D00915228849BE0031E174500670D2E566@usplm233.amer.corp.eds.com> Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdocument? Thread-Index: AcWjV3YhDa4orWLMR/C8a8FBKjXl0QAAc5vn References: <4.3.2.7.2.20050817140759.032ba7c0@email.cisco.com> From: "Wongbe, Taa" To: "Siva Sivabalan \(msiva\)" , "Drake, John E" X-OriginalArrivalTime: 17 Aug 2005 18:27:16.0208 (UTC) FILETIME=[4B625700:01C5A359] X-Spam-Score: 0.5 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Bill Fenner , mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0020653154==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0020653154== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A359.4AF9335E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A359.4AF9335E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable in favor... ________________________________ From: mpls-bounces@lists.ietf.org on behalf of Siva Sivabalan (msiva) Sent: Wed 8/17/2005 1:08 PM To: Drake, John E Cc: mpls@ietf.org; Bill Fenner Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt = forworkingdocument? in favor. At 10:15 AM 8/17/2005 -0700, Drake, John E wrote: >It should be a working group document > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.se] > > Sent: Tuesday, August 16, 2005 5:18 AM > > To: mpls@ietf.org > > Cc: Bill Fenner > > Subject: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for > > workingdocument? > > > > Working group, > > > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > > there were good support for making a working group document and > > we seek the input from the working group om the mailing list to > > decide the consensus. Please send your opinion to the mailing list. > > > > Context: It is understood tht more work needs to be done on the > > LDP aspects of p2mp ping, if this goes into this document or a > > separate document is an open issue. > > In Paris it was also pointed out that we need to collect the > > requirments for p2mp ping, the authors would like to draw attention > > to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to > > fill this need. > > > > Loa and George > > > > -- > > Loa Andersson > > > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls ------_=_NextPart_001_01C5A359.4AF9335E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt = forworkingdocument?=0A= =0A= =0A=
=0A=
in =0A= favor...
=0A=

=0A=
=0A= From: mpls-bounces@lists.ietf.org on = behalf of =0A= Siva Sivabalan (msiva)
Sent: Wed 8/17/2005 1:08 = PM
To: =0A= Drake, John E
Cc: mpls@ietf.org; Bill = Fenner
Subject: RE: =0A= [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt =0A= forworkingdocument?

=0A=
=0A=

in favor.

At 10:15 AM 8/17/2005 -0700, Drake, = John E =0A= wrote:
>It should be a working group document
>
> > =0A= -----Original Message-----
> > From: Loa Andersson [mailto:loa@pi.se]
> > Sent: = Tuesday, August =0A= 16, 2005 5:18 AM
> > To: mpls@ietf.org
> > Cc: Bill =0A= Fenner
> > Subject: [mpls] = draft-yasukawa-mpls-p2mp-lsp-ping-02.txt =0A= for
> > workingdocument?
> >
> > Working =0A= group,
> >
> > in Paris we discussed =0A= "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt"
> > there were good = support =0A= for making a working group document and
> > we seek the input = from the =0A= working group om the mailing list to
> > decide the consensus. = Please =0A= send your opinion to the mailing list.
> >
> > = Context: It is =0A= understood tht more work needs to be done on the
> > LDP = aspects of =0A= p2mp ping, if this goes into this document or a
> > separate = document =0A= is an open issue.
> > In Paris it was also pointed out that we = need to =0A= collect the
> > requirments for p2mp ping, the authors would = like to =0A= draw attention
> > to = "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that =0A= intends to
> > fill this need.
> >
> > Loa = and =0A= George
> >
> > --
> > Loa Andersson
> =0A= >
> > Principal Networking Architect
> > Acreo =0A= AB            = ;            =    =0A= phone:  +46 8 632 77 14
> > Isafjordsgatan =0A= 22            = ;      =0A= mobile: +46 739 81 21 64
> > Kista, =0A= Sweden           &= nbsp;          =0A= email:  loa.andersson@acreo.se
> =0A= >           &nb= sp;           &nbs= p;            = ;         =0A= loa@pi.se
> >
> > =0A= _______________________________________________
> > mpls = mailing =0A= list
> > mpls@lists.ietf.org
> > https://www1.ietf.or= g/mailman/listinfo/mpls
>
>______________________________= _________________
>mpls =0A= mailing list
>mpls@lists.ietf.org
>https://www1.ietf.or= g/mailman/listinfo/mpls

______________________________________= _________
mpls =0A= mailing list
mpls@lists.ietf.org
https://www1.ietf.or= g/mailman/listinfo/mpls

=0A= =0A= =0A= ------_=_NextPart_001_01C5A359.4AF9335E-- --===============0020653154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0020653154==-- From mpls-bounces@lists.ietf.org Thu Aug 18 07:22:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5iTn-000494-GO; Thu, 18 Aug 2005 07:22:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5iTl-00048z-Qu for mpls@megatron.ietf.org; Thu, 18 Aug 2005 07:22:37 -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 HAA27055 for ; Thu, 18 Aug 2005 07:22:36 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5j3V-00057p-1K for mpls@ietf.org; Thu, 18 Aug 2005 07:59:33 -0400 Received: from du-069-0489.access.clara.net ([217.158.145.235] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E5iTU-000IiV-IF; Thu, 18 Aug 2005 12:22:26 +0100 Message-ID: <048401c5a3e7$784a1120$4f849ed9@Puppy> From: "Adrian Farrel" To: "Loa Andersson" , References: <430201CE.6080005@pi.se> Subject: Re: [mpls] draft mpls wg minutes Date: Thu, 18 Aug 2005 10:43:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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: 52f402fbded34a6df606921f56b8bdd8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA27055 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org I support (but, I'm an author) Adrian ----- Original Message -----=20 From: "Loa Andersson" To: Cc: "Bill Fenner" Sent: Tuesday, August 16, 2005 4:10 PM Subject: [mpls] draft mpls wg minutes All, this is a draft version of the mpls working group notes from the Paris meeting. I would like to ask especially people that made presentation to review the agenda items that relates to their presentaions. Comments to me and/or the list before eob Tue Aug 23rd. Also make sure I've all slides that were used. If you are uncertain - please send! /Loa -------------------------------------------------------------------------= - --- Multi-Protocol Label Switching WG (mpls) MONDAY, August 1 at 10:30 - 12:30 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Loa Andersson George Swallow AGENDA: 1. ICMP interactions with MPLS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Ron Ron gave a short background; ICMP as specified in RFC792, does not have a mechanism to report MPLS header information when a router fails to deliver a packet. The MPLS WG processed a draft on MPLS extensions (an object to report the MPLS header) for ICMP and requested that the draft should be published as an RFC on the Standards track. The IESG decided not to publish it because of "layer violation". However the draft has been widely implemented and is an integrated part of most MPLS implementations. The draft has now been resurrected < draft-ietf-mpls-icmp-03>, and the discussion is what work we need to undertake get it published. It was pointed out that we can=92t change anything in the technical details. This needs to be coordinated with the Internet Area, and one Suggestion is to move the parts that are not MPLS specific into a draft that the Internet Area will progress, while the MPLS specific parts goes through the MPLS working group. Ron will discuss this in the Internet Area meeting and we will await the outcome of this discussion. 2. Agenda bashing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Apart from moving the discussion on MPLS ICMP, to the top of the agenda to make possible for Ron to present the same topic in the Internet Area meeting (taking place at the same time), there were no other changes in agenda. 3. Working group status =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Working group chairs reported on the status of working group documents: Parking Place ------------- We have a new =93parking place=94, i.e. a web site that lists all documen= ts that IESG have approved to be published as RFCs. The parking place is located at: http://rtg.ietf.org:8080/Test/parking New RFCs from the MPLS working group since last meeting: ------------------------------------------------------- RFC 4090 Fast Reroute Extensions for RSVP-TE for LSP Tunnels Working group documents in RFC-ed queue: ---------------------------------------- draft-ietf-mpls-lsp-hierarchy-08.txt (2002-04-11!) draft-ietf-mpls-bundle-06.txt draft-ietf-mpls-telink-mib-07.txt draft-ietf-mpls-explicit-null-02.txt draft-ietf-mpls-mgmt-overview-09.txt We have documents that have been stuck in the RFC-editors queue for some time. Actually the oldest document in the queue comes from the MPLS working group. Working group documents in parking place: ----------------------------------------- None Working group documents in IESG review: --------------------------------------- draft-ietf-mpls-ecmp-bcp-01.txt (publication requested) draft-ietf-mpls-lc-if-mib-06.txt (new ID needed) draft-ietf-mpls-lsp-ping-09.txt (new ID needed) draft-ietf-mpls-nodeid-subobject-05.txt (ietf last call) draft-ietf-mpls-bgp-mpls-restart (IESG evaluation) draft-ietf-mpls-rsvpte-attributes (IESG evaluation) MPLS working group drafts: -------------------------- draft-ietf-mpls-lsr-self-test draft-ietf-mpls-oam-frmwk draft-ietf-mpls-oam-requirements-06.txt (dated) draft-ietf-mpls-over-l2tpv3 draft-ietf-mpls-p2mp-sig-requirement draft-ietf-mpls-rsvp-te-p2mp draft-ietf-mpls-rfc3036bis-01.txt (dated) draft-ietf-mpls-soft-preemption 4. LDP to Draft Standards =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Ina draft-ietf-mpls-rfc3036bis-01.txt has gone through minor editing and is ready for WG last call. draft-minei-ldp-operational-experience-01.txt has been refreshed, it is a required informational reference for advancing the BIS draft. Please provide this draft with in depth review. One additional draft - protocol analysis - is also required (RFC 1264) to take LDP to draft standard to receive in depth review. The packages we need to prepare for taking LDP to Draft Standard also include . Working group chairs will start the Working Last Call on the LDP document and poll the list for making the implementation survey and the operational experiences working group documents. 5. MPLS OAM =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LSR Self Test ------------- George This draft has been waiting for the LSP Ping to clear working last call. This has now happened and after minor changes it is ready go to working group last call. P2MP LSP Ping ------------- Adrian Since the meeting in Minneapolis a new work from Bill Fenner (new co-author) has been added and the objectives have been made more precise. Currently it is possible to ping one specific leaf or the whole tree. There was a good support for making it a working group document. Working group chairs will confirm this based on input on the working group mailing list. Tom The draft addresses issues for using the base LSP Ping in Inter AS contexts. Although there is a need to complete some sections of the draft the authors ask for feedback. One problem with using base LSP Ping is that the IP address found in the packet need not be routable if the forwarding failure occurs in an AS to which the AS where the packet originates does not announce the address that is found =93under=94 the MP= LS label. The indicated solution is to record the ASBR that the LSP Ping packet passes through, and if a failure occurs return the packet to the ASBR. P2MP OAM requirements --------------------- draft-yasukawa-mpls-p2mp-oam-reqs-00.txt Tom The document addresses issues on how to detect and report data plane failures. Tom thinks that the document is a little rough; it needs a clarification and additional review. The P2MP OAM requirements should go into a document of its own and needs to address both diagnostic and periodic OAM. Input from Service Providers and careful review is important. Loa asked who has read and who supported this to become a working group document. Among those who have read the document there is a good support for making it a working group document. Needs to be confirmed on the list. 6. MPLS Multicast and MPLS P2MP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Rahul Rahul said that version -02 was recently published, according the authors it is not entirely ready for last called and a version -03 is planned. The working group should take the opportunity to read and comment. Rahul The background is that there is some inconsistency between what RFC3032 says about multicast and unicast, and the actual requirements. The three drafts discuss separate aspects of this and propose mechanisms solutions to some of the problems. One of the mechanisms that are introduced is upstream label allocation (UAL). The drafts also concluded that it is not necessary to have one code point allocated for unicast and one for multicast, since this is given by context in the NHLFE. Conclusion is that there is some need to revisit how code points have been assigned. Instead of assigning one code point for unicast (8847) and one for multicast (8848), the draft suggests that the code points are used for downstream allocated (8847) and upstream allocated (8848). The concept of =93Neighbor specific labels=94 is introduced since this is required for support of upstream assigned labels. With UAL - the context of a label is derived from the neighbor from whom the labeled packet was sent. The chairs asked how many had read the drafts and who thought they need to become working group drafts. Neither the amount of people who have read the drafts nor the support for making them working group drafts was conclusive. The working group chairs will take steps to initiate a discussion on the mailing list. Adrian pointed out that the LDP and RSVP-TE aspects are split out in separate drafts. The working group co-chairs strongly supported this. Authors agreed to this. MPLS Multicast -------------- Jean-Louis Jean-Louis discussed the multicast requirements that are emerging in MPLS VPN applications. Extending LDP is a fairly low complexity route to support P2MP LSP setup requirements. The discussion brought up issues like why it is appropriate to have a leaf-initiated protocol in the p2mp case when this was not the case in the TE case. The benefits of shared trees vs. source based trees were discussed. George pointed out that some of the requirements are on the IGP routing rather than MPLS or LDP. Since this work is not captured in the working group milestones we need to ask the ADs if we can update the working group charter. Only after that we can accept this as a working group document. George asked for a sense of how many people were interested in doing this work in this WG. Many hands were raised. The working group chairs will bring this to the ADs. Ina To extend LDP for p2mp is an attractive option since LDP is widely deployed. In these networks there might be a need for p2mp LSPs, but deploying RSVP-TE might be considered too much of a cost. Ice This draft also proposes extensions to LDP for multicast, there seems to be enough overlap between two drafts to look into if there is a possibility to merge them into one. The author agreed to this. BGP Point to Multipoint LSP --------------------------- Satoru Matsushima Due to lack of time it was not possible to make this presentation. 6. Inter-AS LDP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruno Due to lack of time it was not possible to make this presentation. 7. End of meeting --=20 Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 18 08:30:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5jWy-0004bn-SF; Thu, 18 Aug 2005 08:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SuZ-0000J4-9o for mpls@megatron.ietf.org; Wed, 17 Aug 2005 14:45:15 -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 OAA16905 for ; Wed, 17 Aug 2005 14:45:13 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5TU9-0008DA-VD for mpls@ietf.org; Wed, 17 Aug 2005 15:22:02 -0400 Received: from [149.8.64.21] by mclmx.mail.saic.com for mpls@ietf.org; Wed, 17 Aug 2005 14:45:07 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005081714450707109 for ; Wed, 17 Aug 2005 14:45:07 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Aug 2005 14:45:07 -0400 Message-Id: <6A47CB4A48D1EA49A6F7AB618490D64927434866@mcl-its-exs03.mail.saic.com> From: "Mahan, James L." To: "'mpls@ietf.org'" Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdoc ument? Date: Wed, 17 Aug 2005 14:45:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.3 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f X-Mailman-Approved-At: Thu, 18 Aug 2005 08:29:58 -0400 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0414404460==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0414404460== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A35B.C6140C62" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5A35B.C6140C62 Content-Type: text/plain In favor of the working group recommendation Very Respectfully, James L. Mahan Sr. Systems Engineer & PM Network Systems & Services Naval & Maritime Solutions Group SAIC Work: 1.703.925.4331 Mobile: 1.571.201.0504 _____ From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Wongbe, Taa Sent: Wednesday, August 17, 2005 2:27 PM To: Siva Sivabalan (msiva); Drake, John E Cc: Bill Fenner; mpls@ietf.org Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdocument? in favor... _____ From: mpls-bounces@lists.ietf.org on behalf of Siva Sivabalan (msiva) Sent: Wed 8/17/2005 1:08 PM To: Drake, John E Cc: mpls@ietf.org; Bill Fenner Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdocument? in favor. At 10:15 AM 8/17/2005 -0700, Drake, John E wrote: >It should be a working group document > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.se ] > > Sent: Tuesday, August 16, 2005 5:18 AM > > To: mpls@ietf.org > > Cc: Bill Fenner > > Subject: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for > > workingdocument? > > > > Working group, > > > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > > there were good support for making a working group document and > > we seek the input from the working group om the mailing list to > > decide the consensus. Please send your opinion to the mailing list. > > > > Context: It is understood tht more work needs to be done on the > > LDP aspects of p2mp ping, if this goes into this document or a > > separate document is an open issue. > > In Paris it was also pointed out that we need to collect the > > requirments for p2mp ping, the authors would like to draw attention > > to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to > > fill this need. > > > > Loa and George > > > > -- > > Loa Andersson > > > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls ------_=_NextPart_001_01C5A35B.C6140C62 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt = forworkingdocument?

In favor of the working group recommendation

 

=

Very Respectfully,

James L. Mahan
Sr. Systems Engineer & PM
Network Systems & Services
Naval & Maritime Solutions Group
SAIC

Work:      1.703.925.4331
Mobile:  1.571.201.0504

From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] = On Behalf Of Wongbe, Taa
Sent: Wednesday, August = 17, 2005 2:27 PM
To: Siva Sivabalan = (msiva); Drake, John E
Cc: Bill Fenner; = mpls@ietf.org
Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt = forworkingdocument?

 

in = favor...

 

From: mpls-bounces@lists.ietf.org on behalf of Siva Sivabalan (msiva)
Sent: Wed 8/17/2005 1:08 = PM
To: Drake, John E
Cc: mpls@ietf.org; Bill = Fenner
Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt = forworkingdocument?

in favor.

At 10:15 AM 8/17/2005 -0700, Drake, John E wrote:
>It should be a working group document
>
> > -----Original Message-----
> > From: Loa Andersson [mailto:loa@pi.se]
> > Sent: Tuesday, August 16, 2005 5:18 AM
> > To: mpls@ietf.org
> > Cc: Bill Fenner
> > Subject: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt = for
> > workingdocument?
> >
> > Working group,
> >
> > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt"
> > there were good support for making a working group document = and
> > we seek the input from the working group om the mailing list = to
> > decide the consensus. Please send your opinion to the mailing = list.
> >
> > Context: It is understood tht more work needs to be done on = the
> > LDP aspects of p2mp ping, if this goes into this document or = a
> > separate document is an open issue.
> > In Paris it was also pointed out that we need to collect the
> > requirments for p2mp ping, the authors would like to draw = attention
> > to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that = intends to
> > fill this need.
> >
> > Loa and George
> >
> > --
> > Loa Andersson
> >
> > Principal Networking Architect
> > Acreo = AB     &nbs= p;           &nbs= p;         phone:  +46 8 632 77 14
> > Isafjordsgatan = 22           &nbs= p;      mobile: +46 739 81 21 64
> > Kista, Sweden   &nb= sp;           &nb= sp;      email:  loa.andersson@acreo.se
> >           &n= bsp;           &n= bsp;           &n= bsp;         loa@pi.se
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@lists.ietf.org
> > https://www1.ietf.o= rg/mailman/listinfo/mpls
>
>_______________________________________________
>mpls mailing list
>mpls@lists.ietf.org
>https://www1.ietf.o= rg/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.o= rg/mailman/listinfo/mpls

------_=_NextPart_001_01C5A35B.C6140C62-- --===============0414404460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0414404460==-- From mpls-bounces@lists.ietf.org Thu Aug 18 11:01:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ltp-0001Zh-Db; Thu, 18 Aug 2005 11:01:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lto-0001Zc-7l for mpls@megatron.ietf.org; Thu, 18 Aug 2005 11:01:44 -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 LAA11138 for ; Thu, 18 Aug 2005 11:01:42 -0400 (EDT) Received: from tcmail21.telekom.de ([217.6.95.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5mTW-0003fS-PM for mpls@ietf.org; Thu, 18 Aug 2005 11:38:42 -0400 Received: from g9jbq.mgb01.telekom.de (g9jbq.mgb01.telekom.de [164.20.31.5]) by tcmail21.dmz.telekom.de with ESMTP for mpls@ietf.org; Thu, 18 Aug 2005 17:01:16 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Aug 2005 17:01:14 +0200 Message-Id: <97A461F3EE5284469E41ED3728202F412FA696@S4DE9JSAAMW.ost.t-com.de> From: "Leymann, Nicolai" To: mpls@ietf.org Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for working d ocument? Date: Thu, 18 Aug 2005 17:01:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, I do support making the draft a WG document. > Working group, > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > there were good support for making a working group document and > we seek the input from the working group om the mailing list to > decide the consensus. Please send your opinion to the mailing list. Nic -- Dipl. Inf. Nicolai Leymann T-Systems International GmbH Senior Experte Systems Integration Technologiezentrum Engineering Networks, Products & Services Packet based Carrier Transport Networks Goslarer Ufer 35, D- 10589 Berlin Tel +49 30 3497-3570 Fax +49 30 3497-3571 Mobile +49 170 2275345 E-Mail: nicolai.leymann@t-systems.com Internet: http://www.t-systems.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 18 15:27:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5q2t-0006Mz-5H; Thu, 18 Aug 2005 15:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5q2s-0006LC-0A for mpls@megatron.ietf.org; Thu, 18 Aug 2005 15:27:22 -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 PAA25882 for ; Thu, 18 Aug 2005 15:27:20 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5qce-00034a-UK for mpls@ietf.org; Thu, 18 Aug 2005 16:04:22 -0400 Received: from du-069-0050.access.clara.net ([217.158.132.50] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E5q2X-000Nyi-9F; Thu, 18 Aug 2005 20:27:02 +0100 Message-ID: <04ff01c5a42b$2d91b540$4f849ed9@Puppy> From: "Adrian Farrel" To: "Loa Andersson" , References: <4301D95C.9090605@pi.se> Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for workingdocument? Date: Thu, 18 Aug 2005 20:23:10 +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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org OK This time I'll reply to the right email! I support. adrian ----- Original Message ----- From: "Loa Andersson" To: Cc: "Bill Fenner" Sent: Tuesday, August 16, 2005 1:17 PM Subject: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for workingdocument? > Working group, > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > there were good support for making a working group document and > we seek the input from the working group om the mailing list to > decide the consensus. Please send your opinion to the mailing list. > > Context: It is understood tht more work needs to be done on the > LDP aspects of p2mp ping, if this goes into this document or a > separate document is an open issue. > In Paris it was also pointed out that we need to collect the > requirments for p2mp ping, the authors would like to draw attention > to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to > fill this need. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Aug 19 03:53:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E61gS-0001Rr-Re; Fri, 19 Aug 2005 03:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E61gQ-0001Qi-GC for mpls@megatron.ietf.org; Fri, 19 Aug 2005 03:52:58 -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 DAA18858 for ; Fri, 19 Aug 2005 03:52:56 -0400 (EDT) Received: from mgw1.noc.ntt.com ([210.163.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E62GJ-000098-SD for mpls@ietf.org; Fri, 19 Aug 2005 04:30:05 -0400 Received: from mop1.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id j7J7qh3Y020501; Fri, 19 Aug 2005 16:52:43 +0900 (JST) Received: from mip3.noc.ntt.com (mvi2.noc.ntt.com) by mop1.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0ILG0069ZLVSI3@ntt.com>; Fri, 19 Aug 2005 16:52:43 +0900 (JST) Date: Fri, 19 Aug 2005 16:52:41 +0900 From: "Yuji KAMITE" Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for working document? In-reply-to: <4301D95C.9090605@pi.se> To: mpls@ietf.org Message-id: <0ILG00IT0LVT0N@ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcWiXcRc1TFn51j1TP6wwAdCY37NoQCNFaaA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: 'Bill Fenner' X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org I support it. It's a really meaningful item. - Yuji > > Working group, > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > there were good support for making a working group document > and we seek the input from the working group om the mailing > list to decide the consensus. Please send your opinion to the > mailing list. > > Context: It is understood tht more work needs to be done on > the LDP aspects of p2mp ping, if this goes into this document > or a separate document is an open issue. > In Paris it was also pointed out that we need to collect the > requirments for p2mp ping, the authors would like to draw > attention to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that > intends to fill this need. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Aug 19 04:24:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E62B6-0001RB-Pa; Fri, 19 Aug 2005 04:24:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E62B4-0001R6-Dy for mpls@megatron.ietf.org; Fri, 19 Aug 2005 04:24:38 -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 EAA20065 for ; Fri, 19 Aug 2005 04:24:36 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E62ky-0000yH-5Z for mpls@ietf.org; Fri, 19 Aug 2005 05:01:45 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 10:24:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for workingdocument? Date: Fri, 19 Aug 2005 10:24:57 +0200 Message-ID: Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for workingdocument? Thread-Index: AcWiXT+B1T2/t4RtRi6ZgFwD/0AB/wCOZF9w From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Loa Andersson" , X-OriginalArrivalTime: 19 Aug 2005 08:24:35.0155 (UTC) FILETIME=[6E8B0A30:01C5A497] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: Bill Fenner X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Loa, all Frankly speaking I initially had strong concerns w.r.t the scalability = of this apporach. The reply jitter mechanism addresses some scalability issues, and I = stongly encourage authors to pursue their effort in improving the = scalability. I support this draft as WG doc. Regards, JL=20 > -----Message d'origine----- > De : mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] De la part de Loa Andersson > Envoy=E9 : mardi 16 ao=FBt 2005 14:18 > =C0 : mpls@ietf.org > Cc : Bill Fenner > Objet : [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for=20 > workingdocument? >=20 > Working group, >=20 > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > there were good support for making a working group document=20 > and we seek the input from the working group om the mailing=20 > list to decide the consensus. Please send your opinion to the=20 > mailing list. >=20 > Context: It is understood tht more work needs to be done on=20 > the LDP aspects of p2mp ping, if this goes into this document=20 > or a separate document is an open issue. > In Paris it was also pointed out that we need to collect the=20 > requirments for p2mp ping, the authors would like to draw=20 > attention to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that=20 > intends to fill this need. >=20 > Loa and George >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Aug 19 06:55:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64XG-0004IE-Ia; Fri, 19 Aug 2005 06:55:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64XD-0004I3-JY for mpls@megatron.ietf.org; Fri, 19 Aug 2005 06:55:40 -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 GAA25833 for ; Fri, 19 Aug 2005 06:55:35 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6578-0005AH-D0 for mpls@ietf.org; Fri, 19 Aug 2005 07:32:47 -0400 Received: from du-069-0334.access.clara.net ([217.158.145.80] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E64Wz-000BML-HW; Fri, 19 Aug 2005 11:55:27 +0100 Message-ID: <05ee01c5a4ac$e00325c0$4f849ed9@Puppy> From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" References: Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdocument? Date: Fri, 19 Aug 2005 11:57:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA25833 Cc: Bill Fenner , mpls@ietf.org, Zafar Ali X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi J-L, Thanks for you support for this draft. I would like to pursue the scaling issue with you in more detail since it is something that has worried us as authors. The problem is essentially the stress that is placed on the root (and the network near the root) if one pings the entire tree and receives response= s from all of the leaves. The first point to note is, of course, that this only becomes a problem when the tree is over a certain size. But, yes, we need to be able to handle trees of all sizes. The jitter mechanism is designed to increase the size of tree that can be handled. And is it fair to say that if the root knows its own limitations and knows the size of the tree, it can set the jitter suitably large according to the size of the tree to mean that it is not swamped. The other mechanism that we supply allows the root to ping an individual leaf. Clearly this mechanism has a scaling problem in the other dimension. That is, the root will never be swamped, but it may take forever to ping all of the leaves one at a time. Well, to be frank, tough! If the root does not have enough horsepower to handle pinging all of the leaves, or to handle receiving responses from all of the leaves, there is not much that can be done. Recall that there are three purposes to the tool. 1. To discover the topology (or just the leaves) of the tree. This does not need to be a quick process, and setting a large jitter (10s of seconds) is fine. 2. To diagnose a fault in delivery to a particular leaf. This has no scaling issues because only a single leaf is pinged. 3. To detect faults through periodic polling. I am personally pretty suspicious of this use of ping even in unicast! Nevertheless, if "periodic" is acceptable, then it should be possible either to ping each leaf in turn, or to ping the entire tree with a large jitter. There are two other suggestions that have been made. a. Allow the specification of a "group" of leaves that are being pinged. This was in our original I-D, but we dropped it because it put considerable processing overhead on the transit nodes in the traceroute case (it also puts some overhead on the leaves in the ping case, but this is less significant). We have repeatedly asked the WG if we should reintroduce this function= , but no-one is interested. b. Develop some mechanism whereby ping responses are "aggregated" at branch points and sent back to the root as single report of all of the downstream tree. This is similar to the SRRO mechanism in P2MP RSVP-TE. This is certainly achievable, but the reasons for not even beginning t= o think about this is that it is a completely new protocol that would not be based on LSP Ping. Recall that the return path in LSP Ping is in the control plane and therefore might not (will not!) flow upstream through the branch nodes. Now, as mLDP comes along, some of these assumptions may need to change a bit. That is, the SRRO will not be available and the root must rely on th= e traceroute option to know the topology of the tree. Further, the root cannot know the addresses of the leaves or even know how many leaves ther= e are before it starts to ping. This makes for a *very* different situation and ping-all and traceroute-all become much more significant. It is our hope that jitter will be enough to resolve the scaling issues even in thi= s case. Note also that in the mLDP case there is some problem with doing traceroute to an individual egress because the state in the network does not know which branch to follow to that egress (unlike in P2MP RSVP-TE). Thus, a single-node traceroute in mLDP will generate the same responses a= s a traceroute-all with the exception of the responses from the leaves themselves. We have not started to work on extending the draft for mLDP (we decided t= o wait until mLDP is a bit more stable!). We would welcome any ideas that you have to improve the mechanism. Cheers, Adrian ----- Original Message -----=20 From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Loa Andersson" ; Cc: "Bill Fenner" Sent: Friday, August 19, 2005 9:24 AM Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdocument? Hi Loa, all Frankly speaking I initially had strong concerns w.r.t the scalability of this apporach. The reply jitter mechanism addresses some scalability issues, and I stongly encourage authors to pursue their effort in improving the scalability. I support this draft as WG doc. Regards, JL > -----Message d'origine----- > De : mpls-bounces@lists.ietf.org > [mailto:mpls-bounces@lists.ietf.org] De la part de Loa Andersson > Envoy=E9 : mardi 16 ao=FBt 2005 14:18 > =C0 : mpls@ietf.org > Cc : Bill Fenner > Objet : [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for > workingdocument? > > Working group, > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > there were good support for making a working group document > and we seek the input from the working group om the mailing > list to decide the consensus. Please send your opinion to the > mailing list. > > Context: It is understood tht more work needs to be done on > the LDP aspects of p2mp ping, if this goes into this document > or a separate document is an open issue. > In Paris it was also pointed out that we need to collect the > requirments for p2mp ping, the authors would like to draw > attention to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that > intends to fill this need. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Aug 19 08:17:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E65nw-00062m-Gp; Fri, 19 Aug 2005 08:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E65nu-00062Y-EA for mpls@megatron.ietf.org; Fri, 19 Aug 2005 08:16:58 -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 IAA29536 for ; Fri, 19 Aug 2005 08:16:56 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E66Nq-0007Ps-Sj for mpls@ietf.org; Fri, 19 Aug 2005 08:54:07 -0400 Received: from du-069-0067.access.clara.net ([217.158.132.67] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E65nk-000GCg-Eb; Fri, 19 Aug 2005 13:16:51 +0100 Message-ID: <062f01c5a4b8$3f1adcf0$4f849ed9@Puppy> From: "Adrian Farrel" To: "Loa Andersson" , References: <42FCA71D.5050901@pi.se> Subject: Re: [mpls] Working group last call on draft-ietf-mpls-rfc3036bis-02.txt Date: Fri, 19 Aug 2005 13:18:42 +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: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: Bill Fenner X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, Thanks to Ina, Bob and Loa for this work. A random set of nit-like comments... There are loads of hyphenations which ought really to be fixed. New text in 2.5.3 says... Until the LDP session is established, no other messages except those listed in the procedures above may be exchanged... Would it be better to use RFC2119 language? What should an LSR do if it receives a message? How about taking the opportunity to tidy up the RFC2119 language? For example, in section 3.3 we have several uses of "must" New text in section 3.5.1.1 has "shutdown message." Should be "Shutdown message." There are a bunch of normative references that are not actually referenced. Since these are RFCs, it is not harmful to the processing of the document by the RFC Ed, but we might consider whether we need them all to be normative references, or alternatively actually insert the references into the text. Do we need to do something specific to deprecate the Host Address FEC in the IANA registry? Cheers, Adrian ----- Original Message ----- From: "Loa Andersson" To: Cc: "Bill Fenner" Sent: Friday, August 12, 2005 2:41 PM Subject: [mpls] Working group last call on draft-ietf-mpls-rfc3036bis-02.txt > Working group, > > this is to initiate a MPLS working group last call on > draft-ietf-mpls-rfc3036bis-01.txt > > The LDP spec has been updated based on operational and implementational > experiences and will requested to be published as a Draft Standard. > > The working group last call ends 11.59PM PST on Friday August 26. > > The package needed for taking the LDP spec to draft standard also > includes the following two drafts > > draft-thomas-mpls-ldp-survey2002-00.txt and > draft-minei-ldp-operational-experience-01.txt > > at the same time we ask for working group consensus to make them > working group documents. > > /Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > ----- Original Message ----- From: "Loa Andersson" To: Cc: "Bill Fenner" Sent: Friday, August 12, 2005 2:41 PM Subject: [mpls] Working group last call on draft-ietf-mpls-rfc3036bis-02.txt > Working group, > > this is to initiate a MPLS working group last call on > draft-ietf-mpls-rfc3036bis-01.txt > > The LDP spec has been updated based on operational and implementational > experiences and will requested to be published as a Draft Standard. > > The working group last call ends 11.59PM PST on Friday August 26. > > The package needed for taking the LDP spec to draft standard also > includes the following two drafts > > draft-thomas-mpls-ldp-survey2002-00.txt and > draft-minei-ldp-operational-experience-01.txt > > at the same time we ask for working group consensus to make them > working group documents. > > /Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Aug 19 15:50:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CsP-0004I1-TY; Fri, 19 Aug 2005 15:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CsN-0004Gm-4b for mpls@megatron.ietf.org; Fri, 19 Aug 2005 15:50:03 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25865 for ; Fri, 19 Aug 2005 15:50:00 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E6CsM-0002iI-Do; Fri, 19 Aug 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: Fri, 19 Aug 2005 15:50:02 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-fastreroute-mib-03.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute Author(s) : R. Cetin, T. Nadeau Filename : draft-ietf-mpls-fastreroute-mib-03.txt Pages : 34 Date : 2005-8-19 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching fast rerouting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-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-mpls-fastreroute-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-mpls-fastreroute-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-8-19144509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-fastreroute-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-fastreroute-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-19144509.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Fri Aug 19 16:33:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6DYU-0007Lo-FF; Fri, 19 Aug 2005 16:33:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6DYS-0007LN-L3 for mpls@megatron.ietf.org; Fri, 19 Aug 2005 16:33:32 -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 QAA03658 for ; Fri, 19 Aug 2005 16:33:30 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6E8T-0007c7-Qy for mpls@ietf.org; Fri, 19 Aug 2005 17:10:46 -0400 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id j7JKrAqH010684 for ; Fri, 19 Aug 2005 13:53:10 -0700 (MST) Received: from il06exm62.ds.mot.com (IL06EXM62.corp.mot.com [10.0.111.44]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j7JKgE0F011629 for ; Fri, 19 Aug 2005 15:42:15 -0500 (CDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for working document? Date: Fri, 19 Aug 2005 15:33:28 -0500 Message-ID: <229228E0FDA3484D8F0D9BDDB8E9623191EAA4@il06exm62.ds.mot.com> Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for working document? Thread-Index: AcWiXcXuiN1BLRViS+u/7vj0B9tFKgCn0RjQ From: "Kullberg Alan-G19424" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org I'm in favor of acceptance. Alan -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, August 16, 2005 8:18 AM To: mpls@ietf.org Cc: Bill Fenner Subject: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for working document? Working group, in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" there were good support for making a working group document and we seek the input from the working group om the mailing list to decide the consensus. Please send your opinion to the mailing list. Context: It is understood tht more work needs to be done on the LDP aspects of p2mp ping, if this goes into this document or a separate document is an open issue. In Paris it was also pointed out that we need to collect the requirments for p2mp ping, the authors would like to draw attention to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to fill this need. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sat Aug 20 07:05:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6R9s-00054y-5k; Sat, 20 Aug 2005 07:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6R9q-00054Y-8N for mpls@megatron.ietf.org; Sat, 20 Aug 2005 07:05:02 -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 HAA15462 for ; Sat, 20 Aug 2005 07:04:59 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Rjy-0001VQ-BT for mpls@ietf.org; Sat, 20 Aug 2005 07:42:23 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6R9m-000Gae-Qs for mpls@ietf.org; Sat, 20 Aug 2005 11:04:59 +0000 Message-ID: <43070E48.5010902@psg.com> Date: Sat, 20 Aug 2005 13:04:40 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: multipart/mixed; boundary="------------080709020001040502080400" X-Spam-Score: 0.0 (/) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f Cc: Subject: [mpls] Some comments on draft-yasukawa-mpls-p2mp-oam-reqs-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------080709020001040502080400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit looking at this doc some comments in section 4.2 "These functions should allow an operator to stipulate the maximum amount of time to wait until responses are heard from all points along the path, as well a cut-offs for the number of paths tested." -> not sure to understand what "all points" means in this context, also if you don't receive an answer what are you going to do (is not btw a situation which is susceptible to occur ?) in section 4.3 " Note that path characterization should lead to the operator being able to deduce the full tree for a P2MP LSP. To achieve this, it is important that the branching points on that tree are clearly identified." -> does this sentence means that a mechanism should be made available to poll for specific branching point liveliness ? in section 4.6 "As described in [MPLS-OAM], network elements MUST provide alarm suppression and aggregation to prevent the generation of superfluous alarms within or across network layers." -> would it be possible to be a bit more specific in the P2MP context what does aggregation of alarms means ? (and which alarms ?) to which "network layers" is this sentence referring to ? in general, i find this section difficult to parse in section 4.8 "As described in [MPLS-OAM], these procedures will detect a broad range of defects, and SHOULD be operable where Since MPLS P2MP LSPs span multiple routing areas, or multiple Service Provider domains." -> would it be possible to clarify the beginning of the sentence refers to failure detection, the last part about multi-area/multi-AS ? in section 4.11 "Fundamental to understanding traffic flows within a network that supports P2MP LSPs will be the knowledge of where the branch points exist within the network." -> do you assume that the tree decomposition is unique ? it seems to me you need to also have the branch point relationship - clarifying what the term "where" means would help here --------------080709020001040502080400 Content-Type: text/plain; charset=UTF-8; name="www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-oam-reqs-00.txt" Content-Disposition: inline; filename="www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-oam-reqs-00.txt" Content-Transfer-Encoding: 7bit Network Working Group Seisho Yasukawa Internet Draft NTT Corp Expires: December 2005 Adrian Farrel Old Dog Consulting Daniel King DNNI Ltd. Thomas D. Nadeau Cisco Systems, Inc. June 2005 OAM Requirements for Point-to-Multipoint MPLS Networks draft-yasukawa-mpls-p2mp-oam-reqs-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs the requirement to detect, handle and diagnose control and dataplane defects is critical. For operators deploying services based on P2MP MPLS LSPs the detection and specification of how to handle those defects is important because such defects may not only affect the fundamental of an MPLS network, but also because they MAY impact service level specification commitments for customers of their network. Yasukawa et al. [Page 1] Internet-Draft draft-yasukawa-mpls-p2mp-oam-reqs-00.txt June 2005 This document describes requirements for user and data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. Table of Contents 1. Introduction .................................................. 2 2. Terminology ................................................... 3 2.1 Conventions ................................................ 3 2.2 Terminology ................................................ 3 2.3 Acronyms ................................................... 3 3. Motivations ................................................... 3 4. General Requirements .......................................... 4 4.1 Detection of Label Switch Path Defects ..................... 4 4.2 Diagnosis of a Broken Label Switch Path .................... 5 4.3 Path characterization ...................................... 5 4.4 Service Level Agreement Measurement ........................ 5 4.5 Frequency of OAM Execution ................................. 6 4.6 Alarm Suppression, Aggregation and Layer Coordination ...... 6 4.7 Support for OAM Interworking for Fault Notification ........ 6 4.8 Error Detection and Recovery ............................... 7 4.9 Standard Management Interfaces ............................. 7 4.10 Detection of Denial of Service Attacks ................... 7 4.11 Per-LSP Accounting Requirements ........................... 8 5. Security Considerations ....................................... 8 6. IANA Considerations ........................................... 8 7. References .................................................... 9 7.1 Normative References ....................................... 9 7.2 Informative References ..................................... 9 8. Acknowledgements ............................................. 10 9. Authors' Addresses ........................................... 10 10. Intellectual Property Statement ............................. 10 11. Full Copyright Statement .................................... 11 1. Introduction This document describes requirements for user and data plane operations and management (OAM) for point-to-multipoint (P2MP) Multi-Protocol Label Switching (MPLS). These requirements have been gathered from network operators who have extensive experience deploying MPLS networks and from operators who are considering deploying P2MP MPLS networks. This draft specifies OAM requirements for P2MP MPLS, as well as for applications of P2MP MPLS. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs [P2MP-SIG-REQ] and [P2MP-RSVP], as well as multicast LDP LSPs [P2MP-LDP] and [MCAST-LDP]. Yasukawa et al. [Page 2] Internet-Draft draft-yasukawa-mpls-p2mp-oam-reqs-00.txt June 2005 Note that the requirements for OAM for P2MP MPLS build heavily on the requirements for OAM for point-to-point MPLS. These latter are described in [MPLS-OAM] and are not repeated in this document. 2. Terminology 2.1 Conventions used in this document 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 [RFC2119]. 2.2 Terminology Definitions of key terms for MPLS OAM are found in [MPLS-OAM] and the reader is assumed to be familiar with those definitions which are not repeated here. [P2MP-SIG-REQ] includes some important definitions and terms for use within the context of P2MP MPLS. The reader should be familiar with at least the terminology section of that document. 2.3 Acronyms The following list of acronyms is a repeat of common acronyms defined in many other documents, and is provided here for convenience. CE: Customer Edge DoS: Denial of service ECMP: Equal Cost Multipath LDP: Label Distribution Protocol LSP: Label Switch Path LSR: Label Switch Router OAM: Operations and Management OA&M: Operations, Administration and Maintenance. RSVP: Resource reSerVation Protocol P2MP: Point-to-Multipoint SP: Service Provider TE: Traffic Engineering 3. Motivations OAM for MPLS networks has been established as a fundamental requirement both through operational experience and through its documentation in numerous Internet drafts. Many such documents (for example, [LSP-PING], [RFC3812], [RFC3813], [RFC3814], and [RFC3815]) developed specific solutions to individual issues or problems. Coordination of the full OAM requirements for MPLS was achieved by [MPLS-OAM] in recognition of the fact that the previous piecemeal approach could lead to inconsistent and inefficient applicability of OAM techniques across the MPLS architecture, and Yasukawa et al. [Page 3] Internet-Draft draft-yasukawa-mpls-p2mp-oam-reqs-00.txt June 2005 might require significant modifications to operational procedures and systems in order to provide consistent and useful OAM functionality. This document builds on these realizations and extends the statements of MPLS OAM requirements to cover the new area of P2MP MPLS. That is, this document captures the requirements for P2MP MPLS OAM in advance of the development of specific solutions. Nevertheless, at the time of writing, some effort had already been expended to extend existing MPLS OAM solutions to cover P2MP MPLS (for example, [P2MP-LSP-PING]). While this approach of extending existing solutions may be reasonable, in order to ensure a consistent OAM framework it is necessary to articulate the full set of requirements in a single document. This will facilitate a uniform set of MPLS OAM solutions spanning multiple MPLS deployments and concurrent applications. 4. General Requirements The general requirements described in this section are closely similar to those described for point-to-point MPLS in [MPLS-OAM]. The subsections below do not repeat material from [MPLS-OAM], but simply give references to that document. However, where the requirements for P2MP MPLS OAM differ from or are more extensive than those expressed in [MPLS-OAM], additional text is supplied. In general, it should be noted that P2MP LSPs introduce a scalability issue that is not present in point-to-point MPLS. That is, an individual P2MP LSP will have more than one egress and the path to those egresses will very probably not be linear (for example, it may have a tree structure). Since the number of egresses for a single P2MP LSP is unknown and not bounded by any small number, it follows that all mechanisms defined for OAM support must scale well with the number of egresses and the complexity of the path of the LSP. Mechanisms that are able to deal with individual egresses will scale no worse than similar mechanisms for point-to-point LSPs, but it is desirable to develop mechanisms that are able to leverage the fact that multiple egresses are associated with a single LSP, and so achieve better scaling. 4.1 Detection of Label Switch Path Defects The ability to detect defects in a broken Label Switch Path (LSP) SHOULD not require manual hop-by-hop troubleshooting of each LSR used to switch traffic for that P2MP LSP. Any solutions should either extend or work in close conjunction with existing solutions developed for point-to-point MPLS, such as those specified in [LSP-PING]. This will leverage existing software and hardware deployments. Yasukawa et al. [Page 4] Internet-Draft draft-yasukawa-mpls-p2mp-oam-reqs-00.txt June 2005 4.2 Diagnosis of a Broken Label Switch Path The ability to diagnose a broken P2MP LSP and to isolate the failed component (i.e., link or node) in the path is required. These functions include a path connectivity test that can test all branches of a P2MP LSP for reachability, as well as a path tracing function. These functions should allow an operator to stipulate the maximum amount of time to wait until responses are heard from all points along the path, as well a cut-offs for the number of paths tested. Any mechanism developed to perform these functions are subject to the scalability concerns expressed in section 4. 4.3 Path Characterization The path characterization function is the ability to reveal details of LSR forwarding operations for P2MP LSPs. These details can then be compared later during subsequent testing relevant to OAM functionality. Therefore, LSRs supporting P2MP LSPs MUST provide mechanisms that allow operators to interogate and characterize P2MP paths. Since P2MP paths are more complex than the paths of point-to-point LSPs, the scaling concerns expressed in section 4 apply. Note that path characterization should lead to the operator being able to deduce the full tree for a P2MP LSP. To achieve this, it is important that the branching points on that tree are clearly identified. 4.4 Service Level Agreement Measurement Mechanisms are required to measure the diverse aspects of Service Level Agreements for services that utlize P2MP LSPs. The aspects are listed in [MPLS-OAM]. Service Level Agreements are often measured in terms of the quality and rate of data delivery. In the context of P2MP MPLS, data is delivered to multiple egress nodes. The mechanisms MUST, therefore, be capable of measuring the aspects of Service Level Agreements as they apply to each of the egress points to a P2MP LSP. At the same time, in order to diagnose issues with meeting Service Level Agreements, mechanisms SHOULD be provided to measure the aspects of the agreements at key points within the network such as at branch nodes on the P2MP tree. Yasukawa et al. [Page 5] Internet-Draft draft-yasukawa-mpls-p2mp-oam-reqs-00.txt June 2005 4.5 Frequency of OAM Execution As stipulated in [MPLS-OAM], the operator MUST have the flexibility to configure OAM parameters to meet their specific operational requirements. This requirement is potentially more important in P2MP deployments where the effects of the execution of OAM functions can be potentially much greater than in a non-P2MP configuration. For example, a mechanism that causes each egress of a P2MP LSP to respond could result in a large burst of responses for a single OAM request. Therefore, solutions produced SHOULD NOT impose any fixed limitations on the frequency of the execution of any OAM functions. 4.6 Alarm Suppression, Aggregation and Layer Coordination As described in [MPLS-OAM], network elements MUST provide alarm suppression and aggregation to prevent the generation of superfluous alarms within or across network layers. The same time constraint issues identified in [MPLS-OAM] also exist for P2MP LSPs. A P2MP LSP also brings the possiblity of a single fault causing a larger number of alarms than for a point-to-point LSP. This can happen because there are a larger number of downstream LSRs (for example, a larger number of egresses). The resultant multiplier in the number of alarms could cause swamping of the alarm management systems to which the alarms are reported, and serves as a multiplier to the number of potentially duplicate alarms raised by the network. Alarm aggregation or limitation techniques MUST be applied within any solution, or be available within an implementation, so that this scaling issue can be reduced. 4.7 Support for OAM Interworking for Fault Notification [MPLS-OAM] specifies that an LSR supporting the interworking of one or more networking technologies over MPLS MUST be able to translate an MPLS defect into the native technology's error condition. This also applies to any LSR supporting P2MP LSPs. However, careful attention to the requirements for alarm suppression stipulated therein and in section 4.6 SHOULD be observed. Note that the time constraints for fault notification and alarm propagation impact upon the solutions that might be applied to the scalability problem inherent in certain OAM techniques applied to P2MP LSPs. For example, a solution to the issue of a large number of egresses all responding to some form of probe request at the same time, might be to make the probes less frequent - but this might impact on the ability to detect and/or report faults. Yasukawa et al. [Page 6] Internet-Draft draft-yasukawa-mpls-p2mp-oam-reqs-00.txt June 2005 Where fault notification to the egress is required, there is the possiblity that a single fault will give rise to multiple notifications, one to each egress node of the P2MP that is downstream of the fault. Any mechanisms MUST manage this scaling issue while still continuing to deliver fault notifications in a timely manner. Where fault notification to the ingress is required, the mechanisms MUST ensure that the notification identifies the egress nodes of the P2MP LSP that are impacted (that is, those downstream of the fault) and does not falsely imply that all egress nodes are impacted. 4.8 Error Detection and Recovery Recovery from a fault by a network element can be facilitated by MPLS OAM procedures. As described in [MPLS-OAM], these procesures will detect a broad range of defects, and SHOULD be operable where Since MPLS P2MP LSPs span multiple routing areas, or multiple Service Provider domains. The same requirements as those expressed in [MPLS-OAM] with respect to automatic repair and operator intervention ahead of customer detection of faults apply to P2MP LSPs. 4.9 Standard Management Interfaces The wide-spread deployment of MPLS requires common information modeling of management and control of OAM functionality. This is reflected in the the integration of standard MPLS-related MIBs [RFC3813][RFC3812][RFC3814][RFC3815] for fault, statistics and configuration management. These standard interfaces provide operators with common programmatic interface access to operations and management functions and their status. These The standard MPLS-related MIB modules [RFC3812], [RFC3813], [RFC3814], and [RFC3815] SHOULD be extended wherever possible, to support P2MP LSPs, the associated OAM functions on these LSPs, and the applications that utlize P2MP LSPs. Extending them will facillitate the reuse of existing management software both in LSRs and in management systems. In cases where the existing MIB modules cannot be extended, then new MIB modules MUST be created. 4.10 Detection of Denial of Service Attacks The ability to detect denial of service (DoS) attacks against the data or control planes which signal P2MP LSPs MUST be part of any security management related to MPLS OAM tools or techniques. Yasukawa et al. [Page 7] Internet-Draft draft-yasukawa-mpls-p2mp-oam-reqs-00.txt June 2005 4.11 Per-LSP Accounting Requirements In an MPLS network where P2MP LSPs are in use, Service Providers can measure traffic from an LSR to the egress of the network using some MPLS-related MIB modules (see section 4.9), for example. Other interfaces MAY exist as well and enable the creation of traffic matricies so that it is possible to know how much traffic is traveling from where to where within the network. Analysis of traffic flows to produce a traffic matrix is more complicated where P2MP LSPs are deployed becasue there is no simple pairing relationship between an ingress and a single egress. Fundamental to understanding traffic flows within a network that supports P2MP LSPs will be the knowledge of where the branch points exist within the network. Traffic flow and accounting tools MUST take this fact into account. 5. Security Considerations This document introduces no new security issues compared with [MPLS-OAM]. It is worth highlighting, however, that any tool designed to satisfy the requirements described in this document MUST include provisions to prevent its unauthorized use. Likewise, these tools MUST provide a means by which an operator can prevent denial of service attacks if those tools are used in such an attack. LSP mis-merging is described in [MPLS-OAM] where it is pointed out that it has security implications beyond simply being a network defect. It needs to be stressed that it is in the nature of P2MP traffic flows that any erroneous delivery (such as caused by LSP mis-merging) is likely to have more far reaching conseuqences since the traffic will be mis-delivered to multiple receivers. As with previous OAM function described in [MPLS-OAM], the performance of diagnostic functions and path characterization may involve the extraction of a significant amount of information about network construction. The network operator MAY consider this information private and wish to take steps to secure it, but further, the volume of this information may be considered as a threat to the integrity of the network if it is extacted in bulk. This issue may be greater in P2MP MPLS becuase of the potential for a large number of receivers on a single LSP and the consequent extensive path of the LSP. 6. IANA Considerations This document creates no new requirements on IANA namespaces. Yasukawa et al. [Page 8] Internet-Draft draft-yasukawa-mpls-p2mp-oam-reqs-00.txt June 2005 7. References 7.1 Normative References [MPLS-OAM] T. Nadeau, Allan D., et al. Allan D., "OAM Requirements for MPLS Networks", draft-ietf-mpls-oam-requirements-05.txt, December 2004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2 Informative References [LSP-PING] Kompella, K., and Swallow, G., (Editors), "Detecting MPLS Data Plane Failures", draft-ietf-mpls-lsp-ping, work in progress. [MCAST-LDP] Wijnands, IJ., et al., " Multicast Extensions for LDP", draft-wijnands-mpls-ldp-mcast-ext, work in progress. [P2MP-LDP] Minei, I., et al., "Label Distribution Protocol Extensions for Point-to-Multipoint Label Switched Paths", draft-minei-mpls-ldp-p2mp, work in progress. [P2MP-LSP-PING] Yasukawa, S., Farrel, A., Ali, Z., and Fenner, B., "Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Engineering - Extensions to LSP Ping", draft-yasukawa-mpls-p2mp-lsp-ping, work in progress. [P2MP-RSVP] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp, work in progress. [P2MP-SIG-REQ] Yasukawa, S. (Editor), "Signaling Requirements for Point to Multipoint Traffic Engineered MPLS LSPs", draft-ietf-mpls-p2mp-sig-requirement, work in progress. [RFC3812] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Traffic Engineering Management Information Base Using SMIv2", RFC3812, June 2004. [RFC3813] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Label Switch Router Management Information Base Using SMIv2", RFC3813, June 2004. Yasukawa et al. [Page 9] Internet-Draft draft-yasukawa-mpls-p2mp-oam-reqs-00.txt June 2005 [RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base", RFC3814, June 2004. [RFC3815] Cucchiara, J., Sjostrand, H., and Luciani, J., "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004. 8. Acknowledgment The authors wish to acknowledge and thank the following individuals for their valuable comments to this document: TBD 9. Authors' Addresses Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 Email: adrian@olddog.co.uk Daniel King Darwinian Neural Network Industries Ltd. Phone: +44 (0)1249 665923 Email: dan@dnni.com Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719 Phone: +1-978-936-1470 Email: tnadeau@cisco.com Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422 59 4769 Email: yasukawa.seisho@lab.ntt.co.jp 10. Intellectual Property Statement 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 in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has Yasukawa et al. [Page 10] Internet-Draft draft-yasukawa-mpls-p2mp-oam-reqs-00.txt June 2005 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 any 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. 11. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. Yasukawa et al. [Page 11] --------------080709020001040502080400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --------------080709020001040502080400-- From mpls-bounces@lists.ietf.org Sat Aug 20 16:03:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ZYg-0004Yw-EB; Sat, 20 Aug 2005 16:03:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ZYe-0004YR-AA for mpls@megatron.ietf.org; Sat, 20 Aug 2005 16:03: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 QAA07413 for ; Sat, 20 Aug 2005 16:03:10 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6a8r-0004wA-Kl for mpls@ietf.org; Sat, 20 Aug 2005 16:40:38 -0400 Received: from du-069-0174.access.clara.net ([217.158.132.174] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E6ZYQ-000NUA-H4; Sat, 20 Aug 2005 21:03:00 +0100 Message-ID: <006c01c5a5c2$89489140$20849ed9@Puppy> From: "Adrian Farrel" To: , , References: <43070E48.5010902@psg.com> Subject: Re: [mpls] Some comments on draft-yasukawa-mpls-p2mp-oam-reqs-00.txt Date: Sat, 20 Aug 2005 21:02:00 +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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Dimitri, Good of you to review... > in section 4.2 "These functions should allow an operator to stipulate > the maximum amount of time to wait until responses are heard from all > points along the path, as well a cut-offs for the number of paths tested." > > -> not sure to understand what "all points" means in this context, also > if you don't receive an answer what are you going to do (is not btw a > situation which is susceptible to occur ?) Rereading this text I don't like it. In answer to your question, it is exactly the case you raise that we are trying to cover. That is, it must be possible for the operator (or automated process) to stipulate a timeout after which the failure to see a response shall be flagged as an error. I don't like "as well a cut-offs for the number of paths tested." I think this should say "branches" not "paths". > in section 4.3 " Note that path characterization should lead to the > operator being able to deduce the full tree for a P2MP LSP. To achieve > this, it is important that the branching points on that tree are clearly > identified." > > -> does this sentence means that a mechanism should be made available to > poll for specific branching point liveliness ? No. It means that knowing the set of LSRs in a tree is not sufficient. In order to construct the tree, it is important to know the order of LSPs traversed and it must be possible to deduce the branch points. Our point is that a diagnostic tool should collect information that is easy to process rather than provide information that must be post-processed with some complexity. Finally, we should note that in some cases it may be possible for a branch point to have two downstream branches (different labels) that run through the same downstream LSR (downstream LSR is not branch capable in the data plane) and that in this case, the branch point is not possible to deduce from the sequence of LSRs, but must be clearly flagged. I think we should capture some of these ideas in the I-D. > in section 4.6 "As described in [MPLS-OAM], network elements MUST > provide alarm suppression and aggregation to prevent the generation of > superfluous alarms within or across network layers." > > -> would it be possible to be a bit more specific in the P2MP context > what does aggregation of alarms means ? (and which alarms ?) to which > "network layers" is this sentence referring to ? in general, i find this > section difficult to parse I don't think we should clarify [MPLS-OAM] within this document, so many of your questions need to be redirected to the authors of that I-D. Yes, we should be careful with the term "alarm aggregation" because, while [MPLS-OAM] means aggregation from layers, we can also have aggregation from branches as set out in the paragraph after the one you quoted. Please note that the whole I-D applies only to MPLS networks. > in section 4.8 "As described in [MPLS-OAM], these procedures > will detect a broad range of defects, and SHOULD be operable where > Since MPLS P2MP LSPs span multiple routing areas, or multiple Service > Provider domains." > > -> would it be possible to clarify the beginning of the sentence refers > to failure detection, the last part about multi-area/multi-AS ? Hmmm. The text here seems to have been passed through our patent Manglomatic (TM) text converter. It should read... Recovery from a fault by a network element can be facilitated by MPLS OAM procedures. As described in [MPLS-OAM], these procedures will detect a broad range of defects, and SHOULD be operable where MPLS P2MP LSPs span multiple routing areas, or multiple Service Provider domains. However, I don't suppose this answers your point. In fact, section 4.8 of [MPLS-OAM] talks about a broad range of defects and the application to multiple routing areas and multiple SP domains, so the text is intended to read as re-written above. > in section 4.11 "Fundamental to understanding traffic flows within a > network that supports P2MP LSPs will be the knowledge of where the > branch points exist within the network." > > -> do you assume that the tree decomposition is unique ? it seems to me > you need to also have the branch point relationship - clarifying what > the term "where" means would help here OK. We can re-work this a bit. Thanks, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Aug 22 10:05:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7CvM-0007Xu-SV; Mon, 22 Aug 2005 10: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 1E70pI-0000LB-01; Sun, 21 Aug 2005 21:10: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 VAA29393; Sun, 21 Aug 2005 21:10:10 -0400 (EDT) Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E71Ph-00068t-JU; Sun, 21 Aug 2005 21:47:53 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j7M19nED002467; Mon, 22 Aug 2005 09:09:49 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76])by rodin.i2r. a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j7M19llf002423; Mon, 22 Aug 2005 09:09:48 +0800 (SGT) Received: from bearty1 ([192.168.152.200])by mailhost.lit.org.sg (Sun Java S ystem Messaging Server 6.1 HotFix 0.06(built Nov 11 2004)) with SMTP id <0I LL00FDEN8DD620@mailhost.lit.org.sg>; Mon,22 Aug 2005 09:09:49 +0800 (SGT) Date: Mon, 22 Aug 2005 09:09:53 +0800 From: Boon Sain Yeo To: Message-id: <104901c5a6b6$343c1a60$c898a8c0@bearty1> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.29 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:5 C:4 M:4 S:4 R:4 (1.5000 1.5000) X-Spam-Score: 0.5 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 X-Mailman-Approved-At: Mon, 22 Aug 2005 10:05:14 -0400 Cc: Subject: [mpls] CFP SensorWare X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0203920124==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0203920124== Content-type: multipart/alternative; boundary="Boundary_(ID_2LetgtaYslsKWbFmxU0M3Q)" This is a multi-part message in MIME format. --Boundary_(ID_2LetgtaYslsKWbFmxU0M3Q) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT (My apologies if you receive multiple copies of this message) *********************************************************** 1st International Workshop on Software for Sensor Networks (SensorWare) - CFP *********************************************************** Welcome to the 1st International Workshop on Software for Sensor Networks (SensorWare) to be held on the 8 January 2006. The workshop is held in conjunction with COMSWARE 2006 in the beautiful and historical city of New Delhi. Advances in technology have made deployment of miniature sensors a realistic proposition. These sensors are low-power, inexpensive, smart devices with multiple on-board sensors, and are connected through wireless links, so as to form a collaborative sensor network to perform a specific task. As a result, it opens up a new paradigm of ubiquitous computing and enables a range of applications that are previously unrealizable or too costly to be realized. However, given the limitation of on-board hardware, one of the key areas towards achieving superior performance is through the software implementation. The workshop is intended for the presentation and discussion of novel algorithms and software implementation for sensor networks. This workshop, intends to bring together engineering experts and academicians to discuss the current status, technical challenges, standards, fundamental issues, and future services and applications in the form of panels and technical presentation. Topics of interest include but are not limited to the following: Operating System Efficient algorithms Protocol design Performance analysis Performance related issues Sensor applications Deployment issues and scenarios Middleware Sensor security Sensor network design and modeling Workshop co-chairs: Nirmala Shenoy (ns@rit.edu), RIT, USA Boon Sain Yeo (boonyeo@ieee.org), Institute for Infocomm Research, Singapore TPC Members: Holger Karl, University of Paderborn, Germany, Ling-Jyh Chen, Academia Sinica, Taiwan Kui Wu, University of Victoria, Canada, Daeyoung Kim, ICU, Korea Leonard Barolli, Fukuoka Institute of Technology, Japan, Wei-Peng Chen, Fujitsu Labs of America, USA Jason Redi, BBN Technologies, USA Biao Chen, Syracuse University, USA Hairong Qi, University of Tennessee, USA Xiaojun Cao, Rochester Institute of Technology, USA Xin Wang, University of Buffalo, USA James Minseok Kwon, RIT, USA Wenye Wang, North Carolina State University, USA Fei Hu, RIT, USA Robin Chellappa, Deakin Univeristy, Australia Technical Papers has to be submitted to the co-chairs at boonyeo@ieee.org. Papers should be written in English and should preferably follow the instructions in template.pdf. Preferred maximum paper length is 6 printed pages (10-point font) including figures. Important Dates: Paper Submission Deadline: 1 October 2005 Notification Acceptance/Rejection: 1 November 2005 Final Camera-Ready Paper Submission: 1 December 2005 Please visit the workshop website at http://www.sensorware.org for more info. We look forward to seeing you at SensorWare. Many thanks Best regards, Boon and Nirmala Workshop co-chairs --Boundary_(ID_2LetgtaYslsKWbFmxU0M3Q) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
(My = apologies if you=20 receive multiple copies of this message)
 
***********************************************************
1= st=20 International Workshop on Software for Sensor Networks (SensorWare) =96=20 CFP
***********************************************************
&nb= sp;
 
Welcome to the 1st International = Workshop on=20 Software for Sensor Networks (SensorWare) to be held on the 8 January = 2006. The=20 workshop is held in conjunction with COMSWARE 2006 in the beautiful and=20 historical city of New Delhi.
 
 
Advances in technology have made = deployment of=20 miniature sensors a realistic proposition. These sensors are low-power,=20 inexpensive, smart devices with multiple on-board sensors, and are = connected=20 through wireless links, so as to form a collaborative sensor network to = perform=20 a specific task. As a result, it opens up a new paradigm of ubiquitous = computing=20 and enables a range of applications that are previously unrealizable or = too=20 costly to be realized. However, given the limitation of on-board = hardware, one=20 of the key areas towards achieving superior performance is through the = software=20 implementation. The workshop is intended for the presentation and = discussion of=20 novel algorithms and software implementation for sensor networks. This = workshop,=20 intends to bring together engineering experts and academicians to = discuss the=20 current status, technical challenges, standards, fundamental issues, and = future=20 services and applications in the form of panels and technical=20 presentation.
 
 
 
Topics of interest include but are not = limited to=20 the following:
 
 
 
Operating System
Efficient = algorithms=20
Protocol design
Performance analysis
Performance related = issues=20
Sensor applications
Deployment issues and scenarios =
Middleware=20
Sensor security
Sensor network design and=20 modeling 
 
 
Workshop co-chairs:
 
Nirmala Shenoy (ns@rit.edu), RIT,=20 USA
Boon Sain Yeo (boonyeo@ieee.org), Institute for = Infocomm=20 Research, Singapore
 
 
 
TPC Members:
 
Holger Karl, University of Paderborn,=20 Germany,
Ling-Jyh Chen, Academia Sinica, Taiwan
Kui Wu, University = of=20 Victoria, Canada,
Daeyoung Kim, ICU, Korea
Leonard Barolli, = Fukuoka=20 Institute of Technology, Japan,
Wei-Peng Chen, Fujitsu Labs of = America,=20 USA
Jason Redi, BBN Technologies, USA      =
Biao=20 Chen, Syracuse University, USA
Hairong  Qi, University of = Tennessee,=20 USA
Xiaojun Cao, Rochester Institute of Technology, USA
Xin Wang,=20 University of Buffalo, USA
James Minseok Kwon, RIT, USA
Wenye = Wang, North=20 Carolina State University, USA
Fei Hu, RIT, USA
Robin Chellappa, = Deakin=20 Univeristy, Australia 
 
Technical Papers has to be submitted to = the=20 co-chairs at boonyeo@ieee.org.
 
Papers should be written in English and = should=20 preferably follow the instructions in template.pdf. Preferred maximum = paper=20 length is 6 printed pages (10-point font) including = figures.

Important Dates:
 
Paper Submission Deadline: 1=20 October 2005
Notification Acceptance/Rejection: 1 November=20 2005
Final Camera-Ready Paper Submission: 1 December = 2005
 
Please visit the workshop website at http://www.sensorware.org for more info.
 
We look forward to seeing you at=20 SensorWare.
 
Many thanks
Best = regards,
 
Boon and Nirmala
Workshop=20 co-chairs
--Boundary_(ID_2LetgtaYslsKWbFmxU0M3Q)-- --===============0203920124== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0203920124==-- From mpls-bounces@lists.ietf.org Mon Aug 22 13:59:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Ga2-0004Rv-TR; Mon, 22 Aug 2005 13:59:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Ga0-0004Rn-Ka for mpls@megatron.ietf.org; Mon, 22 Aug 2005 13:59:28 -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 NAA01282 for ; Mon, 22 Aug 2005 13:59:27 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7HAb-0000od-L0 for mpls@ietf.org; Mon, 22 Aug 2005 14:37:19 -0400 Received: from [141.39.20.72] (helo=[141.39.20.72]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1E7GZj-0001Yi-2F; Mon, 22 Aug 2005 19:59:17 +0200 Message-ID: <430A126C.1080009@pi.se> Date: Mon, 22 Aug 2005 19:59:08 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Loa Andersson Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for working document? References: <4301D95C.9090605@pi.se> In-Reply-To: <4301D95C.9090605@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "fw.testbed.se", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Working group, there is clearly support to make draft-yasukawa-mpls-p2mp-lsp-ping-02.txt a working group document. Could the authors please re-publish as draft-ietf-mpls-p2mp-lsp-ping-00.txt [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Working group, there is clearly support to make draft-yasukawa-mpls-p2mp-lsp-ping-02.txt a working group document. Could the authors please re-publish as draft-ietf-mpls-p2mp-lsp-ping-00.txt /Loa Loa Andersson wrote: > Working group, > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > there were good support for making a working group document and > we seek the input from the working group om the mailing list to > decide the consensus. Please send your opinion to the mailing list. > > Context: It is understood tht more work needs to be done on the > LDP aspects of p2mp ping, if this goes into this document or a > separate document is an open issue. > In Paris it was also pointed out that we need to collect the > requirments for p2mp ping, the authors would like to draw attention > to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that intends to > fill this need. > > Loa and George > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Aug 22 15:50:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IJ4-00009m-JB; Mon, 22 Aug 2005 15:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IJ2-00007U-3V for mpls@megatron.ietf.org; Mon, 22 Aug 2005 15:50:04 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08440 for ; Mon, 22 Aug 2005 15:50:02 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E7IIz-0000uJ-G7; Mon, 22 Aug 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: Mon, 22 Aug 2005 15:50:01 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-fastreroute-mib-04.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute Author(s) : R. Cetin, T. Nadeau Filename : draft-ietf-mpls-fastreroute-mib-04.txt Pages : 34 Date : 2005-8-22 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching fast rerouting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-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-mpls-fastreroute-mib-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-mpls-fastreroute-mib-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-8-22121850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-fastreroute-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-fastreroute-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-22121850.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Tue Aug 23 03:00:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7SmC-0003Vw-9u; Tue, 23 Aug 2005 03:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7SmA-0003Vq-9g for mpls@megatron.ietf.org; Tue, 23 Aug 2005 03:00: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 DAA17753 for ; Tue, 23 Aug 2005 03:00:49 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7SmA-0001s5-CG for mpls@ietf.org; Tue, 23 Aug 2005 03:00:54 -0400 Received: from [141.39.20.72] (helo=[141.39.20.72]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1E7Slj-0004Nj-Vf; Tue, 23 Aug 2005 09:00:35 +0200 Message-ID: <430AC987.800@pi.se> Date: Tue, 23 Aug 2005 09:00:23 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "fw.testbed.se", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Working Group, this mail initiates a two week working group last call on Label Switching Router Self-Test . The last call ends Wednesday September 7 EOB PST. Please send your comments to the working group mailing list. [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: [mpls] working group last call on draft-ietf-mpls-lsr-self-test-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Working Group, this mail initiates a two week working group last call on Label Switching Router Self-Test . The last call ends Wednesday September 7 EOB PST. Please send your comments to the working group mailing list. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Aug 24 02:50:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7p5T-0001kh-3R; Wed, 24 Aug 2005 02:50:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7p5O-0001kL-UT for mpls@megatron.ietf.org; Wed, 24 Aug 2005 02:50:13 -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 CAA02837 for ; Wed, 24 Aug 2005 02:50:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7p5f-0004Qd-5N for mpls@ietf.org; Wed, 24 Aug 2005 02:50:28 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7p5M-000DKt-07; Wed, 24 Aug 2005 06:50:08 +0000 Message-ID: <430C1885.50807@psg.com> Date: Wed, 24 Aug 2005 08:49:41 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [mpls] Some comments on draft-yasukawa-mpls-p2mp-oam-reqs-00.txt References: <43070E48.5010902@psg.com> <006c01c5a5c2$89489140$20849ed9@Puppy> In-Reply-To: <006c01c5a5c2$89489140$20849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: dimitri.papadimitriou@alcatel.be, "Thomas D. Nadeau" , mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org hi adrian, Adrian Farrel wrote: > Hi Dimitri, > > Good of you to review... > > >>in section 4.2 "These functions should allow an operator to stipulate >>the maximum amount of time to wait until responses are heard from all >>points along the path, as well a cut-offs for the number of paths >>tested." > >>-> not sure to understand what "all points" means in this context, also >>if you don't receive an answer what are you going to do (is not btw a >>situation which is susceptible to occur ?) > > Rereading this text I don't like it. > > In answer to your question, it is exactly the case you raise that we are > trying to cover. That is, it must be possible for the operator (or > automated process) to stipulate a timeout after which the failure to see a > response shall be flagged as an error. ok - much clearer > I don't like "as well a cut-offs for the number of paths tested." I think > this should say "branches" not "paths". shouldn't you also include a cut-off in terms of number of egresses then >>in section 4.3 " Note that path characterization should lead to the >>operator being able to deduce the full tree for a P2MP LSP. To achieve >>this, it is important that the branching points on that tree are clearly >>identified." >> >>-> does this sentence means that a mechanism should be made available to >>poll for specific branching point liveliness ? > > > No. > It means that knowing the set of LSRs in a tree is not sufficient. ok - i understand the meaning behind the sentence - i would suggest to refine the notion of "path characterization" in this sentence (see section 4.3 of the P2P document) but more importantly to add "sequence of branching points" or equivalent > In order to construct the tree, it is important to know the order of LSPs > traversed and it must be possible to deduce the branch points. > Our point is that a diagnostic tool should collect information that is > easy to process rather than provide information that must be > post-processed with some complexity. imho, this is a specific requirement that should normally be pointed as part of the text > Finally, we should note that in some cases it may be possible for a branch > point to have two downstream branches (different labels) that run through > the same downstream LSR (downstream LSR is not branch capable in the data > plane) and that in this case, the branch point is not possible to deduce > from the sequence of LSRs, but must be clearly flagged. indeed, i would also suggest having an extended version of this for deducing more generic cross-over branching points > I think we should capture some of these ideas in the I-D. ok - >>in section 4.6 "As described in [MPLS-OAM], network elements MUST >>provide alarm suppression and aggregation to prevent the generation of >>superfluous alarms within or across network layers." >> >>-> would it be possible to be a bit more specific in the P2MP context >>what does aggregation of alarms means ? (and which alarms ?) to which >>"network layers" is this sentence referring to ? in general, i find this >>section difficult to parse > > I don't think we should clarify [MPLS-OAM] within this document, so many > of your questions need to be redirected to the authors of that I-D. i understand your redirect and will do because the statement in the referenced doc is not indicated as being aggregation *from layers* > Yes, we should be careful with the term "alarm aggregation" because, while > [MPLS-OAM] means aggregation from layers, we can also have aggregation > from branches as set out in the paragraph after the one you quoted. ok - > Please note that the whole I-D applies only to MPLS networks. noted >>in section 4.8 "As described in [MPLS-OAM], these procedures >>will detect a broad range of defects, and SHOULD be operable where >>Since MPLS P2MP LSPs span multiple routing areas, or multiple Service >>Provider domains." >> >>-> would it be possible to clarify the beginning of the sentence refers >>to failure detection, the last part about multi-area/multi-AS ? > > Hmmm. The text here seems to have been passed through our patent > Manglomatic (TM) text converter. It should read... > Recovery from a fault by a network element can be facilitated by > MPLS OAM procedures. As described in [MPLS-OAM], these procedures > will detect a broad range of defects, and SHOULD be operable where > MPLS P2MP LSPs span multiple routing areas, or multiple Service > Provider domains. > > However, I don't suppose this answers your point. > In fact, section 4.8 of [MPLS-OAM] talks about a broad range of defects > and the application to multiple routing areas and multiple SP domains, so > the text is intended to read as re-written above. ok - but how do you link this with the path characterization where there is a need to "being able to deduce the full tree for a P2MP LSP" are you sure across AS, or providers the full tree topology will be made possible ? >>in section 4.11 "Fundamental to understanding traffic flows within a >>network that supports P2MP LSPs will be the knowledge of where the >>branch points exist within the network." >> >>-> do you assume that the tree decomposition is unique ? it seems to me >>you need to also have the branch point relationship - clarifying what >>the term "where" means would help here > > OK. We can re-work this a bit. ok - if you need some text/help let me know > Thanks, > Adrian > > > . > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Aug 24 11:08:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wrG-0007mO-Cr; Wed, 24 Aug 2005 11:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wrE-0007ld-GM for mpls@megatron.ietf.org; Wed, 24 Aug 2005 11:08:04 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26777 for ; Wed, 24 Aug 2005 11:08:02 -0400 (EDT) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E7wrD-0004HU-Jo; Wed, 24 Aug 2005 11:08:03 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 24 Aug 2005 11:08:03 -0400 Cc: mpls mailing list , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'Graceful Restart Mechanism for BGP with MPLS' to Proposed Standard X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org The IESG has approved the following document: - 'Graceful Restart Mechanism for BGP with MPLS ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp-mpls-restart-05.txt Technical Summary A mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart is described in "Graceful Restart Mechanism for BGP". This document extends this mechanism to also minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart. Working Group Summary The WG had consensus to progress this document. Protocol Quality The specification has been reviewed for the IESG by Alex Zinin. There are at least two known implementations. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Aug 25 07:42:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8G8D-0002NY-TV; Thu, 25 Aug 2005 07:42:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8G8C-0002LF-5f for mpls@megatron.ietf.org; Thu, 25 Aug 2005 07:42:52 -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 HAA13272 for ; Thu, 25 Aug 2005 07:42:51 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8G8f-0000A3-Sd for mpls@ietf.org; Thu, 25 Aug 2005 07:43:24 -0400 Received: from du-069-0246.access.clara.net ([217.158.132.246] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E8G80-0001yO-8P for mpls@ietf.org; Thu, 25 Aug 2005 12:42:42 +0100 Message-ID: <0ad401c5a96a$78d7e710$c5919ed9@Puppy> From: "Adrian Farrel" To: References: <430AC987.800@pi.se> Subject: Re: [mpls] working group last call ondraft-ietf-mpls-lsr-self-test-05.txt Date: Thu, 25 Aug 2005 12:25:13 +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: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, It might be nice to run idnits on this draft. A few nits... 1. Introduction This document defines a means for a Label-Switching Router (LSR) to verify that its dataplane is functioning for certain key Multi-Proto- col Label Switching (MPLS) applications, including unicast forwarding based on LDP [LDP] and traffic engineering tunnels based on [RSVP- TE]. MPLS Echo Request and MPLS Echo Reply messages [LSP-Ping] mes- sages are extended to do the actual probing. Too many "messages"! ======= 1. Introduction The pings are sent to an upstream neighbor, looped back through the LSR under test and intercepted, by means of TTL expiration by a downstream neighbor. Extensions to LSP-Ping [LSP-Ping] are defined to allow the down stream neighbor to report the test results. "downsteam" one word or hyphenated. ======= 1. Introduction In order to minimize the load on upstream LSRs a new loopback FEC is defined. Receipt of a packet labeled with a loopback label will cause the advertising LSR to pop the label off the label stack and send the packet out the advertised interface. What is a "loopback label"? Perhaps you ned to define the term and relate it to the loopback FEC. ======= Some examples of non-2119 language should be fixed. For example, section 2.1. Explanation of Res field. ======= Section 2.1 Spurious formatting instruction .in 9 Typos Note that this type alos indicates the encapsulation type for payloads that have a label stack contain the one loopback label. s/alos/also/ /contain/containing/ Clarity Note that this type alos indicates the encapsulation type for payloads that have a label stack contain the one loopback label. Could you clarify "containing the one loopback label." Also, I believe that this note explains why it is necessary to have different type values of IPv4 unnumbered and IPv6 unnumbered even though they are otherwise identical. Perhaps you could add to the note. ======= Section 2.2 identifier to form the request. In these cases, the downstream LSR will need to be configured to make unsolicited advertisements. Can we replace "will need to be" with a 2119 term? I think this is "MAY be" since the procedure is not mandatory. ======= Section 3 A self test operation involves three LSRs, the LSR doing the test, an upstream neighbor and a downstream neighbor. We refer to these as LSRs T, U, and D respectively. This seems to be in conflict with the Introduction that says... Note that use of a loopback allows an LSR to test label entries for which the LSR is not currently some neighbor's next hop. If the LSRs are neighbors, aren't they also next hops? I think that you mean to say that D is "a downstream LSR", but not say that it is a neighbor. In fact, you go on to say... Although the figure shows LSR-D adja- cent to LSR-T it may in some cases be an arbitrary number of hops away. ======= Section 3.1 The MPLS Data Plane Verification Reply message MAY contain the fol- lowing objects: You need something a little stronger. A Data Plane Verification Reply without either of 7 IPv4 Interface and Label Stack Object 8 IPv6 Interface and Label Stack Object would presumably be invalid as well as useless. ======= Section 3.4 The LSR creates an MPLS Data Plane Verification Request message and includes a Data Plane Verification Object. We don't appear to have a definition of a Data Plane Verification Object. I suspect that this object is needed when the Echo Request is used so that we can tell the difference between a normal Echo Request and one that is being used for Data Plane Verification. ======= Section 3.5 If the echo request is good, X notes the interface I over which the echo was received, and the label stack with which it came. If the MPLS echo request contained a Downstream Verification object, then X must format this information as a Downstream Verification object and include it in its MPLS echo reply message. The text has become confused between describing the processes for handling a Verification Request message, and the processes for handling echo requests that contain the mythical Downstream Verification object. Probably best to describe the main case (VR message) first and then have a coda for the use of Echo Request messages. ======== That's all. Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Aug 29 02:48:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dRN-0002c7-EP; Mon, 29 Aug 2005 02:48:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dRJ-0002bw-EX for mpls@megatron.ietf.org; Mon, 29 Aug 2005 02:48:18 -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 CAA19586 for ; Mon, 29 Aug 2005 02:48:16 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9dSa-0004d4-1m for mpls@ietf.org; Mon, 29 Aug 2005 02:49:37 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j7T6jq204292 for ; Mon, 29 Aug 2005 08:45:52 +0200 Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Mon, 29 Aug 2005 08:47:00 +0200 Message-ID: <4312AF64.4010508@pi.se> Date: Mon, 29 Aug 2005 08:47:00 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-rfc3036bis-02.txt References: <42FCA71D.5050901@pi.se> In-Reply-To: <42FCA71D.5050901@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Bill Fenner X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org All, this working group call has ended. We will ask the co-authors to take care of the comments and publish the survey and experience drafts as wg documents. /Loa Loa Andersson wrote: > Working group, > > this is to initiate a MPLS working group last call on > draft-ietf-mpls-rfc3036bis-01.txt > > The LDP spec has been updated based on operational and implementational > experiences and will requested to be published as a Draft Standard. > > The working group last call ends 11.59PM PST on Friday August 26. > > The package needed for taking the LDP spec to draft standard also > includes the following two drafts > > draft-thomas-mpls-ldp-survey2002-00.txt and > draft-minei-ldp-operational-experience-01.txt > > at the same time we ask for working group consensus to make them > working group documents. > > /Loa and George > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Aug 29 02:53:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dW6-0003Aj-46; Mon, 29 Aug 2005 02:53:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dW4-0003Ab-1o for mpls@megatron.ietf.org; Mon, 29 Aug 2005 02:53: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 CAA19742 for ; Mon, 29 Aug 2005 02:53:10 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9dXL-0004kP-Qg for mpls@ietf.org; Mon, 29 Aug 2005 02:54:32 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Aug 2005 08:52:57 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdocument? Date: Mon, 29 Aug 2005 08:52:56 +0200 Message-ID: Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdocument? thread-index: AcWkrIM8kcG8BD2USU6PFuYv4o7tYAFq386g From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 29 Aug 2005 06:52:57.0237 (UTC) FILETIME=[49A8D450:01C5AC66] X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Content-Transfer-Encoding: quoted-printable Cc: Bill Fenner , mpls@ietf.org, Zafar Ali X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Adrian Please see inline=20 > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Envoy=E9 : vendredi 19 ao=FBt 2005 12:58 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : zzx-yasukawa.seisho@lab.ntt.co.jp; Zafar Ali; Bill=20 > Fenner; mpls@ietf.org > Objet : Re: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt=20 > forworkingdocument? >=20 > Hi J-L, >=20 > Thanks for you support for this draft. >=20 > I would like to pursue the scaling issue with you in more=20 > detail since it is something that has worried us as authors. >=20 > The problem is essentially the stress that is placed on the=20 > root (and the network near the root) if one pings the entire=20 > tree and receives responses from all of the leaves. >=20 > The first point to note is, of course, that this only becomes=20 > a problem when the tree is over a certain size. But, yes, we=20 > need to be able to handle trees of all sizes. It depends on what you mean by "a certain size", to my mind without = Jitter mechanism we may face issues even with just a few tens of leaves, = particularly is leaves are at the same distance from the root (i.e. = simultaneous replies)... >=20 > The jitter mechanism is designed to increase the size of tree=20 > that can be handled. And is it fair to say that if the root=20 > knows its own limitations and knows the size of the tree, it=20 > can set the jitter suitably large according to the size of=20 > the tree to mean that it is not swamped. Yes, and we must be aware that this will have an impact on the delay to = diagnose that there is a failure. Note that the jitter may rapidly = become quite important: Let's take=20 R =3D the number of echo reply messages that can be handle on the root = per second L =3D the number of leaves J =3D the jitter We should have J >=3D L/R Let's take L =3D 1000 and R =3D 100, we have J >=3D 10s >=20 > The other mechanism that we supply allows the root to ping an=20 > individual leaf. Clearly this mechanism has a scaling problem=20 > in the other dimension. > That is, the root will never be swamped, but it may take=20 > forever to ping all of the leaves one at a time. >=20 > Well, to be frank, tough! > If the root does not have enough horsepower to handle pinging=20 > all of the leaves, or to handle receiving responses from all=20 > of the leaves, there is not much that can be done. >=20 > Recall that there are three purposes to the tool. > 1. To discover the topology (or just the leaves) of the tree. > This does not need to be a quick process, and setting a=20 > large jitter (10s of seconds) is fine. > 2. To diagnose a fault in delivery to a particular leaf. > This has no scaling issues because only a single leaf is pinged. > 3. To detect faults through periodic polling. > I am personally pretty suspicious of this use of ping even=20 > in unicast! > Nevertheless, if "periodic" is acceptable, then it should=20 > be possible either to > ping each leaf in turn, or to ping the entire tree with a=20 > large jitter. I agree with you that this would not be the best way to perform fast = failure detection. By the way note that the polling period would have to be higher than the = Jitter which may lead to a poor detection delay (e.g. more than 10s)... >=20 > There are two other suggestions that have been made. > a. Allow the specification of a "group" of leaves that are=20 > being pinged. > This was in our original I-D, but we dropped it because it=20 > put considerable > processing overhead on the transit nodes in the traceroute=20 > case (it also > puts some overhead on the leaves in the ping case, but=20 > this is less significant). > We have repeatedly asked the WG if we should reintroduce=20 > this function, > but no-one is interested. > b. Develop some mechanism whereby ping responses are "aggregated" at > branch points and sent back to the root as single report=20 > of all of the > downstream tree. > This is similar to the SRRO mechanism in P2MP RSVP-TE. > This is certainly achievable, but the reasons for not even=20 > beginning to think > about this is that it is a completely new protocol that=20 > would not be based > on LSP Ping. Recall that the return path in LSP Ping is in=20 > the control plane > and therefore might not (will not!) flow upstream through=20 > the branch nodes. Yes I also had this kind of procedure is mind.=20 In my view the main problem is note to flow upstream through the branch = node. You may easily enforce a return path along the reverse tree: The echo reply could be piggyback in a Resv message :-( Or you could check RSVP state info when propagating the reply message = upstream... IHMO the main issue would be related to the states to be maintained on = branch nodes. Branch nodes would have to wait for all dowstream replies = before to forward upstream, and we would fall into the classical timer = expiration issue (timer value would have to depend on the distance from = the leaves :-( >=20 > Now, as mLDP comes along, some of these assumptions may need=20 > to change a bit. That is, the SRRO will not be available and=20 > the root must rely on the traceroute option to know the=20 > topology of the tree. Further, the root cannot know the=20 > addresses of the leaves or even know how many leaves there=20 > are before it starts to ping. This makes for a *very*=20 > different situation and ping-all and traceroute-all become=20 > much more significant. It is our hope that jitter will be=20 > enough to resolve the scaling issues even in this case. Yes, for instance the Jitter may be computed based on the total number = of PEs, that is an upper bound of the number of leaves... Regards JL >=20 > Note also that in the mLDP case there is some problem with=20 > doing traceroute to an individual egress because the state in=20 > the network does not know which branch to follow to that=20 > egress (unlike in P2MP RSVP-TE). > Thus, a single-node traceroute in mLDP will generate the same=20 > responses as a traceroute-all with the exception of the=20 > responses from the leaves themselves. >=20 > We have not started to work on extending the draft for mLDP=20 > (we decided to wait until mLDP is a bit more stable!). >=20 > We would welcome any ideas that you have to improve the mechanism. >=20 > Cheers, > Adrian >=20 > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > To: "Loa Andersson" ; > Cc: "Bill Fenner" > Sent: Friday, August 19, 2005 9:24 AM > Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt > forworkingdocument? >=20 >=20 > Hi Loa, all >=20 > Frankly speaking I initially had strong concerns w.r.t the=20 > scalability of > this apporach. > The reply jitter mechanism addresses some scalability issues, and I > stongly encourage authors to pursue their effort in improving the > scalability. >=20 > I support this draft as WG doc. >=20 > Regards, >=20 > JL >=20 > > -----Message d'origine----- > > De : mpls-bounces@lists.ietf.org > > [mailto:mpls-bounces@lists.ietf.org] De la part de Loa Andersson > > Envoy=E9 : mardi 16 ao=FBt 2005 14:18 > > =C0 : mpls@ietf.org > > Cc : Bill Fenner > > Objet : [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt for > > workingdocument? > > > > Working group, > > > > in Paris we discussed "draft-yasukawa-mpls-p2mp-lsp-ping-02.txt" > > there were good support for making a working group document > > and we seek the input from the working group om the mailing > > list to decide the consensus. Please send your opinion to the > > mailing list. > > > > Context: It is understood tht more work needs to be done on > > the LDP aspects of p2mp ping, if this goes into this document > > or a separate document is an open issue. > > In Paris it was also pointed out that we need to collect the > > requirments for p2mp ping, the authors would like to draw > > attention to "draft-yasukawa-mpls-p2mp-oam-reqs-00.doc" that > > intends to fill this need. > > > > Loa and George > > > > -- > > Loa Andersson > > > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > > >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Aug 30 11:38:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8BU-0003oV-Tv; Tue, 30 Aug 2005 11:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8BR-0003no-On for mpls@megatron.ietf.org; Tue, 30 Aug 2005 11:37:58 -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 LAA19209 for ; Tue, 30 Aug 2005 11:37:54 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA8Cz-0004QU-7L for mpls@ietf.org; Tue, 30 Aug 2005 11:39:35 -0400 Received: from du-069-0151.access.clara.net ([217.158.132.151] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1EA8Ag-0003Is-9c; Tue, 30 Aug 2005 16:37:38 +0100 Message-ID: <0e3f01c5ad79$12d1baf0$c5919ed9@Puppy> From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" References: Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-lsp-ping-02.txt forworkingdocument? Date: Tue, 30 Aug 2005 14:37:09 +0100 MIME-Version: 1.0 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: 58b614506802734014829a093beb6879 Cc: Bill Fenner , mpls@ietf.org, Zafar Ali X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0029846224==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0029846224== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E2E_01C5AD70.4D7346F0" This is a multi-part message in MIME format. ------=_NextPart_000_0E2E_01C5AD70.4D7346F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JL, >> I would like to pursue the scaling issue with you in more=20 >> detail since it is something that has worried us as authors. >>=20 >> The problem is essentially the stress that is placed on the=20 >> root (and the network near the root) if one pings the entire=20 >> tree and receives responses from all of the leaves. >>=20 >> The first point to note is, of course, that this only becomes=20 >> a problem when the tree is over a certain size. But, yes, we=20 >> need to be able to handle trees of all sizes. > > It depends on what you mean by "a certain size", to my mind > without Jitter mechanism we may face issues even with just=20 > a few tens of leaves, particularly is leaves are at the same > distance from the root (i.e. simultaneous replies)... Yes. "A certain size" means the size that we can handle without jitter :-) But anyway, we now have jitter in place. >> The jitter mechanism is designed to increase the size of tree=20 >> that can be handled. And is it fair to say that if the root=20 >> knows its own limitations and knows the size of the tree, it=20 >> can set the jitter suitably large according to the size of=20 >> the tree to mean that it is not swamped. > > Yes, and we must be aware that this will have an impact on > the delay to diagnose that there is a failure. Note that=20 > the jitter may rapidly become quite important: > Let's take=20 > R =3D the number of echo reply messages that can be handle > on the root per second > L =3D the number of leaves > J =3D the jitter > We should have J >=3D L/R > > Let's take L =3D 1000 and R =3D 100, we have J >=3D 10s Agreed. I might be surprised to hear that R=3D100. But perhaps routers don't all = have very good CPUs, and (of course) we must share processing with other = control plane tasks. L=3D1000 seems a realistic long-term number for P2MP MPLS-TE. To quote = from the requirements doc... It is important to classify the issues of scaling within the context of Traffic Engineering. It is anticipated that the initial deployments of P2MP TE LSPs will be limited to a maximum of around a hundred recipients, but that medium term deployments may increase this to several hundred, and that future deployments may require significantly larger numbers. For multicast LDP we will need to do some similar thinking. Anyway, J >=3D 10 seconds is a good number to work with. [SNIP] As you say... > I agree with you that this would not be the best way > to perform fast failure detection. > By the way note that the polling period would have to=20 > be higher than the Jitter which may lead to a poor=20 > detection delay (e.g. more than 10s)... Yes. I think that using LSP Ping as a fast failure detection method has = been ruled out by this analysis. but, in any case, I don't think that = LSP Ping is recommended as a fast failure detection mechanism even for = P2P LSPs. [SNIP] >> b. Develop some mechanism whereby ping responses are=20 >> "aggregated" at branch points and sent back to the >> root as single report of all of the downstream tree. >> This is similar to the SRRO mechanism in P2MP RSVP-TE. >> This is certainly achievable, but the reasons for not >> even beginning to think about this is that it is a=20 >> completely new protocol that would not be based >> on LSP Ping. Recall that the return path in LSP Ping >> is in the control plane and therefore might not (will >> not!) flow upstream through the branch nodes. > > Yes I also had this kind of procedure is mind.=20 > In my view the main problem is note to flow upstream through > the branch node. You may easily enforce a return path along=20 > the reverse tree: > The echo reply could be piggyback in a Resv message :-( Ha, ha! :-) > Or you could check RSVP state info when propagating the > reply message upstream... Hmmm. I don't think the control plane and data plane states should be = linked in this way if we can help it. It would certainly open up some = interesting issues for the misconnection scenarios, but perhaps it would = help to find more problems. We should do some maths. Consider a mesh where multiple ingresses are = pinging P2MP trees. This idea will reduce the load on the ingresses, but = how will it increase the load on the core nodes? > IHMO the main issue would be related to the states to be > maintained on branch nodes. Branch nodes would have to wait > for all dowstream replies before to forward upstream, and=20 > we would fall into the classical timer expiration issue=20 > (timer value would have to depend on the distance from the > leaves :-( Right. And, we still want to send a reply up stream when the timer expires (to = say that some of the leaves are present). >> Now, as mLDP comes along, some of these assumptions may need=20 >> to change a bit. That is, the SRRO will not be available and=20 >> the root must rely on the traceroute option to know the=20 >> topology of the tree. Further, the root cannot know the=20 >> addresses of the leaves or even know how many leaves there=20 >> are before it starts to ping. This makes for a *very*=20 >> different situation and ping-all and traceroute-all become=20 >> much more significant. It is our hope that jitter will be=20 >> enough to resolve the scaling issues even in this case. > > Yes, for instance the Jitter may be computed based on the > total number of PEs, that is an upper bound of the number > of leaves... As I understand the way mLDP is going at the moment, the ingress will = not know the number of leaves or the number of PEs involved in the P2MP = flow. I guess that the ingress will know an upper bound for both, but = this will depend on the network and so will be the same for all mLDP = LSPs. So determining how to set the jitter period may be much harder. One = could run traceroute and increase the jitter as the tree is built. From = then on, ping can use the jitter that has been determined for the = deepest traceroute. And as leaves come and go, the jitter can be updated = for future pings. Thanks, Adrian ------=_NextPart_000_0E2E_01C5AD70.4D7346F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi JL,
 
>> I would like to pursue the = scaling issue=20 with you in more
>> detail since it is something that has = worried us=20 as authors.
>>
>> The problem is essentially the = stress that=20 is placed on the
>> root (and the network near the root) if = one pings=20 the entire
>> tree and receives responses from all of the=20 leaves.
>>
>> The first point to note is, of course, = that=20 this only becomes
>> a problem when the tree is over a certain = size.=20 But, yes, we
>> need to be able to handle trees of all=20 sizes.
>
> It depends on what you mean by "a certain size", = to my=20 mind
> without Jitter mechanism we = may face=20 issues even with just
> a few tens of leaves, = particularly is leaves=20 are at the same
> distance from the root = (i.e.=20 simultaneous replies)...
 
Yes.
"A certain size" means the size that = we can=20 handle without jitter :-)
But anyway, we now have jitter in=20 place.
 
>> The jitter mechanism is designed to increase the size of = tree=20
>> that can be handled. And is it fair to say that if the root =
>> knows its own limitations and knows the size of the tree, = it=20
>> can set the jitter suitably large according to the size of=20
>> the tree to mean that it is not swamped.
>
> = Yes, and=20 we must be aware that this will have an impact on
> the delay to diagnose that there is a failure. Note that =
> the jitter may rapidly become quite important:
> Let's = take=20
> R =3D the number of echo reply messages that can be = handle
>     on the root per second
> L =3D the number of leaves
> J =3D the jitter
> We should have J >=3D = L/R
>
>=20 Let's take L =3D 1000 and R =3D 100, we have J >=3D 10s
 
Agreed.
 
I might be surprised to hear that R=3D100. But perhaps routers = don't all have=20 very good CPUs, and (of course) we must share processing with other = control=20 plane tasks.
 
L=3D1000 seems a realistic long-term number for P2MP MPLS-TE. To = quote from=20 the requirements doc...
     It is important to classify the issues of = scaling=20 within the
     context of Traffic Engineering. = It is=20 anticipated that the initial
     deployments of = P2MP TE=20 LSPs will be limited to a maximum of around
     = a=20 hundred recipients, but that medium term deployments may=20 increase
     this to several hundred, and that = future=20 deployments may require
     significantly larger = numbers.
For multicast LDP we will need to do some similar = thinking.
 
 
Anyway, J >=3D 10 seconds is a good number to work with.
 
[SNIP]
 
As you say...
 
> I agree with you that this would not be the best way
> to perform fast failure detection.
> By the way = note that=20 the polling period would have to
> be higher than the Jitter which may lead to a poor
> detection delay (e.g. more than 10s)...
 
Yes. I think that using LSP Ping as a fast failure detection method = has=20 been ruled out by this analysis. but, in any case, I don't think that = LSP Ping=20 is recommended as a fast failure detection mechanism even for P2P = LSPs.

[SNIP]
 
>> b. Develop some mechanism whereby ping responses are =
>>    "aggregated" at branch points and sent = back to=20 the
>>    root as single report of all of the = downstream tree.
>>    This is similar to the = SRRO=20 mechanism in P2MP RSVP-TE.
>>    This is = certainly=20 achievable, but the reasons for not
>>    even beginning to think about this = is that=20 it is a
>>    completely new protocol that would = not be=20 based
>>    on LSP Ping. Recall that the return = path in=20 LSP Ping
>>    is in the control plane and = therefore might=20 not (will
>>    not!) flow upstream through the = branch=20 nodes.
>
> Yes I also had this kind of procedure is mind. =
>=20 In my view the main problem is note to flow upstream through
> the branch node. You may easily enforce a return path = along=20
> the reverse tree:
> The echo reply could be piggyback in = a Resv=20 message :-(
 
Ha, ha! :-)

> Or you could check RSVP state info when propagating = the
> reply message upstream...
 
Hmmm. I don't think the control plane and data plane states should = be=20 linked in this way if we can help it. It would certainly open up some=20 interesting issues for the misconnection scenarios, but perhaps it would = help to=20 find more problems.
 
 
We should do some maths. Consider a mesh where multiple ingresses = are=20 pinging P2MP trees. This idea will reduce the load on the ingresses, but = how=20 will it increase the load on the core nodes?
 
 
> IHMO the main issue would be related to the states to be
> maintained on branch nodes. Branch nodes would have to = wait
> for all dowstream replies before to forward upstream, and =
> we would fall into the classical timer expiration issue
> (timer value would have to depend on the distance from = the
> leaves :-(

Right.
And, we still want to send a reply up stream when the timer expires = (to say=20 that some of the leaves are present).
 
 
>> Now, as mLDP comes along, some of these assumptions may = need=20
>> to change a bit. That is, the SRRO will not be available = and=20
>> the root must rely on the traceroute option to know the=20
>> topology of the tree. Further, the root cannot know the=20
>> addresses of the leaves or even know how many leaves there=20
>> are before it starts to ping. This makes for a *very* =
>>=20 different situation and ping-all and traceroute-all become
>> = much=20 more significant. It is our hope that jitter will be
>> enough = to=20 resolve the scaling issues even in this case.
>
> Yes, for = instance=20 the Jitter may be computed based on the
> total number of PEs, that is an upper bound of the = number
> of leaves...
 
As I understand the way mLDP is going at the moment, the ingress = will not=20 know the number of leaves or the number of PEs involved in the P2MP = flow. I=20 guess that the ingress will know an upper bound for both, but this will = depend=20 on the network and so will be the same for all mLDP LSPs.
 
So determining how to set the jitter period may be much harder. One = could=20 run traceroute and increase the jitter as the tree is built. From then = on, ping=20 can use the jitter that has been determined for the deepest traceroute. = And as=20 leaves come and go, the jitter can be updated for future pings.
 
Thanks,
Adrian
------=_NextPart_000_0E2E_01C5AD70.4D7346F0-- --===============0029846224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0029846224==--