From mpls-bounces@lists.ietf.org Tue Jan 02 10:06:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1lBb-0002P4-L3; Tue, 02 Jan 2007 10:04:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1lBa-0002Ok-Bo for mpls@lists.ietf.org; Tue, 02 Jan 2007 10:04:18 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1lBV-0000Kr-6J for mpls@lists.ietf.org; Tue, 02 Jan 2007 10:04:18 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JB800ARYXT2YK@szxga03-in.huawei.com> for mpls@lists.ietf.org; Tue, 02 Jan 2007 23:03:02 +0800 (CST) Received: from huawei.com ([172.24.2.9]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JB8005BGXT122@szxga04-in.huawei.com> for mpls@lists.ietf.org; Tue, 02 Jan 2007 23:03:01 +0800 (CST) Received: from jys3105044303D ([10.200.193.66]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JB800EZPXST66@szxga03-in.huawei.com> for mpls@lists.ietf.org; Tue, 02 Jan 2007 23:03:01 +0800 (CST) Date: Tue, 02 Jan 2007 16:02:24 +0100 From: Xu Xiaohu Subject: =?gb2312?B?tPC4tDogW21wbHNdIExEUCBuZXdiaWUgcXVlc3Rpb24=?= In-reply-to: <6D26D1FE43A66F439F8109CDD42419651F965E@INEXC1U01.in.lucent.com> To: "'Dutta, Pranjal (Pranjal)'" , 'Abhishek Verma' , 'Yu Yi' Message-id: <003401c72e7f$04353a70$42c1c80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Accpbqs34mXy04H/RAWQprA/cvbuAAAIJT9UATsnopA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: mpls@lists.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: , Errors-To: mpls-bounces@lists.ietf.org Hi, IMO, Label binding advertisement is just to tell its neighbors that some label represents some prefix/FEC in its local meaning. The main benefit is to speed up the convergence of LSP forwarding. As = soon as the routing is converged, LSP is ready for forwarding.=20 Xiaohu Xu -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Dutta, Pranjal (Pranjal) = [mailto:pdutta@alcatel-lucent.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA12=D4=C227=C8=D5 9:16 =CA=D5=BC=FE=C8=CB: Abhishek Verma; Yu Yi =B3=AD=CB=CD: mpls@lists.ietf.org =D6=F7=CC=E2: RE: [mpls] LDP newbie question Hi, LDP uses platform wide label space and no specific to = neigbor. So the LSR will adverstise the local binding for the loopback address to = all neighbors irrespective of from whom it has received the remote binding. It's upto the neigbor whether to release the label for its own loopback = or not. =20 HTH, Pranjal ________________________________ From: Abhishek Verma [mailto:abhishekv.verma@gmail.com] Sent: Wed 12/27/2006 9:46 AM To: Yu Yi Cc: mpls@lists.ietf.org Subject: Re: [mpls] LDP newbie question Greetings Yu! The example that you have taken is slightly different. I don't mind LDP3 forwarding the label advertisement it learnt from LDP1 to LDP2 or vice-versa. What i dont comprehend is why an LDP router would advertise the label binding back to the neighbor it learnt that label from? Thanks, Abhishek On 12/26/06, Yu Yi wrote: > Hi Abhishek, > > It is because that LDP2 think it is possible that LDP1 will want = LDP2 send a lable if the next hop is change to LDP2 on LDP1. But in your = case it is impossible. Because the fec(1.1.1.1) is a loopback IP address on = LDP1. There is no chance for LDP1 to select LDP2 as the nexthop for 1.1.1.1. = In this case LDP1 should release the label which LDP2 send. > Please consider another case: > |------------------------------| > LDP1 ----- LDP2 ----- LDP3 > > 1.1.1.1 is a loopback IP address on LDP1. So LDP3 will receive a mapping from LDP2 for fec 1.1.1.1(Suppose the metric of link between LDP1/LDP3 is very large). LDP3 will send a mapping to LDP2. This label = will be used if the link between LDP1/LDP2 is down. > > Thanks, > Yu > > -----Original Message----- > From: Abhishek Verma [mailto:abhishekv.verma@gmail.com] > Sent: 2006?12?23? 9:23 AM > To: mpls@lists.ietf.org > Subject: [mpls] LDP newbie question > > Hi, > > LDP1 -- LDP2 > > I have two LDP peers 1 and 2. LDP1 advertises its loopback IP address = (say 1.1.1.1) to LDP2 with a label of 3. Is there a reason for LDP2 too also advertise 1.1.1.1 back to LDP1 with some label? > > Thanks, > Abhishek > > _______________________________________________ > 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 gdggfc@carreira.com.pt Tue Jan 02 10:26:18 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1lWs-0006WY-OY; Tue, 02 Jan 2007 10:26:18 -0500 Received: from [58.181.181.28] (helo=dsldevice.lan) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H1lWm-0000Jk-3t; Tue, 02 Jan 2007 10:26:16 -0500 Date: Sun, 16 Jan 2005 06:23:03 +0480 From: Nasdaq.com Alert! X-Mailer: The Bat! (v2.10.01) Personal Reply-To: gdggfc X-Priority: 3 (Normal) Message-ID: <260713120.20050116062303@carreira.com.pt> To: mpls-archive@lists.ietf.org Subject: AVPJ(ANDROS ISLE DEVELOPM) this special for you MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.8 (++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
REVEL IN BIG PROFIT BY ANDROS= ISLE DEVELOPM (AVPJ.PK)!
GET NNYG AFTER NEW Y= EAR DO NOT MISS YOUR CHANCE. IT IS COMING TO EXPLODE!
WE OFFER THE NEXT PR= ICES:
TARGET PRICE IN 1 WEEK: 0.72$.GET IT= NOW!
KNOWMORE NEWS ABOUT = THIS EXCITING COMPANY USE YOUR BROKERAGE SITE.
IT=92S GETTING GROWT= H ALMOST EVERY HOUR! MORE THAN 80% DAILY FRO= M INITIAL PRICE.
WE ASSURE YOU THAT Y= OU CAN DOUBLE YOUR INVESTMENTS WITH US.
From mpls-bounces@lists.ietf.org Tue Jan 02 17:20:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ry0-0001vd-9c; Tue, 02 Jan 2007 17:18:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rxy-0001vK-7C for mpls@lists.ietf.org; Tue, 02 Jan 2007 17:18:42 -0500 Received: from out001.atlarge.net ([129.41.63.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1rxt-0004oY-W9 for mpls@lists.ietf.org; Tue, 02 Jan 2007 17:18:42 -0500 Received: from nemertes-01-ex.atlarge.net ([10.100.50.167]) by out001.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 16:16:51 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 2 Jan 2007 16:18:53 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FutureNet 2007 Call For Presentations Thread-Index: AccukSytZr2ld2u9RvuHPF7uXbxFTwAA4FRQAAkWooAAAF48cA== From: "Irwin Lazar" To: , , , , X-OriginalArrivalTime: 02 Jan 2007 22:16:51.0794 (UTC) FILETIME=[B40E3320:01C72EBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mpls-ops@mplsrc.com Subject: [mpls] FutureNet 2007 Call For Presentations 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: , Errors-To: mpls-bounces@lists.ietf.org Greetings, The "Call for Presentations" for "FutureNet 2007: MPLS, VPLS and Beyond" is now available at http://www.futurenetexpo.com/speaker/submit_pres.html FutureNet will be held at the Grand Hyatt Hotel on April 30 - May 3, 2007 in New York City. FutureNet represents the evolution of MPLScon, which for the last six years has been the premier industry conference focusing on MPLS, VPN and WAN technologies from both enterprise and service provider perspectives. =20 With this year's event we'll expand our focus to cover next generation network technologies including emerging Ethernet services, fixed/mobile convergence, rich-media service delivery, optical networking and more. As has been the tradition from past events, FutureNet will focus on end-user case studies from both enterprises and service providers providing real-world insight into challenges and lessons learned. =20 We invite you to review the Call For Presentations and submit an abstract. Please note that abstracts are due by February 2nd, 2007. Please feel free to contact me with any questions. My contact information is below. =20 Sincerely, Irwin Lazar Conference Director, FutureNet: MPLS, VPLS, and Beyond (Formerly MPLScon) http://www.futurenetexpo.com/ irwin.lazar@nemertes.com 703-468-4361 AIM/Google/Yahoo/Skype: imlazar =20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From STABLE@RAVINI.COM Wed Jan 03 18:38:40 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Fgu-00050H-II for mpls-archive@lists.ietf.org; Wed, 03 Jan 2007 18:38:40 -0500 Received: from wsip-68-110-131-162.ga.at.cox.net ([68.110.131.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Fgs-0001Tv-JN for mpls-archive@lists.ietf.org; Wed, 03 Jan 2007 18:38:40 -0500 Received: from SATURN (HELO SATURN) (mpls-archive@lists.ietf.org@173.127.125.63) by [68.110.131.162] with SMTP; Wed, 3 Jan 2007 18:39:01 -0500 Message-ID: <000801c72f90$475705b0$a2836e44@SATURN> From: "divided" To: mpls-archive@lists.ietf.org Subject: create Date: Wed, 3 Jan 2007 18:38:32 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C72F66.5E80FDB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 ------=_NextPart_000_0004_01C72F66.5E80FDB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C72F66.5E80FDB0" ------=_NextPart_001_0005_01C72F66.5E80FDB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stable connection close demi wiktionary demifrom to navigation! Wiktionary demifrom to navigation searchsee, also and english etymology. = To navigation searchsee also and english etymology prefix! Close demi wiktionary demifrom to navigation searchsee. Wiktionary demifrom to navigation searchsee. Middle halfedit frenchedit from. French homophones related, termsedit = latin dimidium divided? Vit this page was, last modified. To navigation searchsee, also, and = english etymology prefix derived. To navigation, searchsee also and. Linkin other, vit this page was last. Navigation searchsee also and, english etymology prefix! Vit this page = was last modified october. Modified october content, is. Linkin other, vit this page was last modified october. French homophones = related, termsedit latin dimidium divided! Connection close demi = wiktionary demifrom. Discussion edit toolslog create links. Was last modified october content = is available. Demifrom to navigation searchsee also and english. Via old middle halfedit frenchedit from prefixes article, discussion. To, navigation searchsee also. Latin dimidium divided in half via old. Related termsedit latin, = dimidium divided in half via old. In half via old middle halfedit frenchedit. Page was last, modified = october content? Page, was last modified. Other vit this page was? Navigation searchsee also and english, etymology. Homophones related, = termsedit, latin, dimidium divided in half. From prefixes article = discussion, edit toolslog, create links. Other, vit this page was last. Divided in half via old middle, halfedit? = Discussion edit toolslog create links! Termsedit latin, dimidium = divided. Frenchedit from prefixes article discussion, edit toolslog = create links. Half, via old, middle halfedit frenchedit from! Also and english = etymology. Searchsee, also and english. ------=_NextPart_001_0005_01C72F66.5E80FDB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Stable connection close demi wiktionary = demifrom to navigation!
Wiktionary demifrom to navigation = searchsee, also=20 and english etymology. To navigation searchsee also and english = etymology prefix!
Close demi wiktionary demifrom to = navigation searchsee.
Wiktionary demifrom to navigation = searchsee.
Middle halfedit frenchedit from. French = homophones=20 related, termsedit latin dimidium divided?
Vit this page was, last modified. To = navigation=20 searchsee, also, and english etymology prefix derived.
To navigation, searchsee also = and.
Linkin other, vit this page was = last.
Navigation searchsee also and, english = etymology=20 prefix! Vit this page was last modified october.
Modified october content, = is.
Linkin other, vit this page was last = modified=20 october. French homophones related, termsedit latin dimidium divided! = Connection=20 close demi wiktionary demifrom.
Discussion edit toolslog create links. = Was last=20 modified october content is available.
Demifrom to navigation searchsee also = and english.
Via old middle halfedit frenchedit from = prefixes=20 article, discussion.
To, navigation searchsee = also.
Latin dimidium divided in half via old. = Related=20 termsedit latin, dimidium divided in half via old.
In half via old middle halfedit = frenchedit. Page=20 was last, modified october content?
Page, was last modified. Other vit this = page was?
Navigation searchsee also and english, = etymology.=20 Homophones related, termsedit, latin, dimidium divided in half. From = prefixes=20 article discussion, edit toolslog, create links.
Other, vit this page was last. Divided = in half via=20 old middle, halfedit? Discussion edit toolslog create links! Termsedit = latin,=20 dimidium divided. Frenchedit from prefixes article discussion, edit = toolslog=20 create links.
Half, via old, middle halfedit = frenchedit from!=20 Also and english etymology.
Searchsee, also and=20 english.
------=_NextPart_001_0005_01C72F66.5E80FDB0-- ------=_NextPart_000_0004_01C72F66.5E80FDB0 Content-Type: image/gif; name="Frenchedit.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c72f90$475705b0$a2836e44@SATURN> R0lGODlhvAGcAIfoAAAKB4wAAAB9CX55DgAAgIcAewB8fc3Bv8Dkup/W6DIZAFgXAHMsA5IaAMIq ANcrCgc0DRM7AEo3AGY2A4MyCpVDAL00AOs7AAFXABZXCElVBllrAIVeC6JfAMZnCu5sAAp+ABuO AE19C198AIx6BpuGALV1BNF3AACfACacAD2dAlqbAI6UAKqSC8OTANqSDAy0BhzLDTHHDV7EAHLH AZm2AL+xAO3CDgDqABXqBjXSAGfYCYjVCKHiDsrsBezcAQwINhkAPzcANWACQ3sHPKkARrUENt0B TAAYPhcZSE4oR1ktQ3IXSqMUQ7ooN9URTQBMPiJCQEc9PlM8O4xOO55CPss5QuI/Sw1gNSxpTTht OFltS45RAJJVS8hcRuFeRQBzTC1+Sz5+TFl0PICDOpWGTbN6Mt2ATQ6nThuqSTWcRlSjTYyaQqmm QLydSdGZQwC2MhPONTnBTF7BO4PFO5nLRLixRey2SgDhOh7aPDrUOVvnMYHdSqHeO7bfPdnrSggM iB0AhjEDc1oBiIQAfZkAcsYAdd8LjQAeiyskdj8ZelctcY0heJ8jfssoge4jfwBMeRJEekNOfFxH hIk7i6E8dLQzitVAcgpUeippg0lqhGheeoJsg5RXgLZsgtdnfgN4ex+Jd014dVZyfHx0jZeOhMuO c9NydQCmhiuhfkeggFyegX2YdJWTd7+qdeWqeQTCjh7Jgzu0eWO0hYC3fa67fs21jeXOeATZdyLW ijveg2npgo7TgZnrfLrgetLbjAAAsiUAyjIAtFgAtIMDt6wFyLgHvtEAuAArwCMqzE4VuWgjsnwt tqwUv7Qrw9wUwwBNyCxDyUpJxmQ0t3Myx5k0wrlExNJJxAFTwRxgy0hYvlJivn9ntpRbyMNgs9dT wwB9uxx8tkaKxWeHsoN5yJyLysJ6wdKLvgGUySeSvzuaxmypx4eWtpqVybufu9OntQy5vC2xyDbA vFHGuHW7yJi2y/3/7aussol7ePQAAAD/AP75AAML//UA/wD4////8SH5BABgoqUALAAAAAC8AZwA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKXPivosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOC1O3Mmzp8+fQIMKHUq0qNGjSJPuzMm0qdOnUEEqnUq1qtWrWLNq3cq1q9evYAVG HUu2rFmPYdOqDXu2rdu3cE+unUu3rt27ePPq3Vs1rt+/KvkKHky4sOHDiBMrXsxYMeDHkCNLnky5 suXLmD823sy5s2e8mUOLJvm5NOjRqFOrXs26tevXsGPLnk27tu3buHNvNM3btO7fwHX25h28+Nnh yJMrXw7WuPPn0DMzn069uvXr2LNTj869u/fv4J1i/wUAICJ57ejTD/dIvj2AleRJxg/v9qj78gLv 48+//7x6wh3NV5GAJxEIkoH0tSbgfAu+N6CDDSKY4HEJ+WeQfxbeZ097A+lHkIYd7rehiP81ZmFB J2JY3okjlogYiyHyF+KK56mIn4oxypijiwaFJuE/BDLYXkY/TviYfhe5lySETD5okZBPOgiklEau 9mOQTFIZZZVwQZQhhzni2KKOX+7II0FWZtnkllMiWCSXUEGkgAIDBWBnAB/eqKeOY5YpkJ1ndmbR nBcR+o+hFRlKKKIV2QmnZI5aFGmjAWCkqAKJYnqopptmOiinBE766GUPPGBRqQI54MBAqrK6qj2t Dv80Z6B1sXcfRqL+o2pFu+rqQEULBCvsRXeKyiijo1o257Ka5uPssxcFa5G0TiYbGrXWFpfVs/nQ OhdK2GYr7riV8YSqt+imq+667Lbr7rtWkSsvWvDWa++9+P40774l5evvvwAHnJcAAvQ4Fgoo8EsT kh1BAIHCtzmcEcIUY1QQwRgTBMPGG0PUcVH66APUxyiSmJDDBOGgssoRsZxUww9XJDHEznHMcUUY YGBRzhnx6V/OAwHdkMtFIexTzkIPtDIODYFpD8oCQS0QxwORLJDRWgEBxEBaCwTG118PBAccAzls dtlmQ1CQ1QLTlfbFBQtEcENjV7SxRXcfKCUUUFj/xPeDSn4E9tcypz1S3URqqRHff2uU9z9aQw6E 5Bq9GVhCXQuUudZbExS2PZ97DsZAoYM+ett2cd75QHNXRDBIhFNeUeSCg3ER7bJzPvvkH+HeoEix Y4T7RoQHj1HwkSfPO0aWp6SQhwIRQIBBmUtvkPXRT486X9JrPxD29oB/kHvfey9+QuKDj33m9rCv EPvwr87Q+dm/37n74XdPUNeqYy7/UB0BBjA0MryKCLAi0suI6nRHM8x0jwAWSSACIfgRAT1Qgra6 CAYl+LsKSokf/LAICEUioTcJ8IQHTNztVCe55bEpJgqhX/6od7//jWl7SKlJfOazQQp6JIXCcyFH /7DEpg56BHc9JKHiphSSH2HwIij8BxAn+BQJTbEiI2QiRoA4xeY1kCnPo5HP+rMfEA7EjAXBX0LQ KBA0gpAfY2wIG/3UNJO1738wuiEdByJAe/SxjwQBZFECtEQ3SelWgDOQF7/YEaVAjz9Ou+GIIkm+ h5zojW+EZCQXAiYQMeSRj1SjJC84PjGyKI84TKUkr6JCjzxxNhFi3hJbospACfIrqDQTdmQYFEaO qyu5XKV1eFnLYhoTKME8pjKXqRZfOpMjzNxLMtM1zWhaUz92LCVRsJlNzqCymnZ5pmrCOBFwSsSc yOzmVEC5yeSIsz4VUmfJKjlJP5kTnT/Bp1DoWf8ya6qSkIHbiBGXVK1FanFJQ0rkIRHZpggNdGEJ baVJ/Bkw/zTgohcVyKw0SieDAIqjG3VIsBTy0TsR5KP2+OhIBbJSe7SUT45EJUop6s+MIoSOxUKp qmLlEGeR0x4+PSme/jRUlKJUn0MplkFCmpZ3fqdXGkGUoSZF1TuNxFkZYdalMHJRi3T1HxgN66lM NRZH5QqrTk2rcBASUqYWJKjPItOJXtoQurZ0pSxqa0dRGdSttIqnHE2IWhnJSX4eRKsdTWlOCeJW hrjVphgNLGM7uiyWLmAgLe2rZJWCWIKE1aY0DRhZwoWSUpmWrF9FaEQZWhHTvvAmqZ1NaL8VFQb/ MIAsUAUMsgbL27VmRWpaoQAFZtvL3tJkOUhLGnGXy1y2GPe5FmuudKdL3epa97rYza52nQvdkCy3 u+D17XbHS97ymlcw4U2vetfL3va6970NPO+74Btd+XaFvqix71Hwy9/+ykS/APavwgBMYPUI+MDy KrCCF8zgBjcEwRCOsIQnTGHgOPjCGJ5uhUel3fdm2FsbDvF3PkziEptYwwI+MXZEzOLoMLfFv1Qx cmBM4xrbZrY2zrGOd8zjp8iYtj0O8mp+3BchG/nI3iGykpfMZHwh+cmYafJ+oaxjKa+YyljOspaz ZeUuN3XLYA6zmMfcFi9rZ71mTrM/t6zmNmOFa8yicbOc50znOlMFzngWj533zOc+NyfPgL6Jnwc9 kUAb+riETrRDDh0aRTv6wowG46PXHGnpTPoulc60pjfN6U57+tO0vDQzQZ1fUZv61Hvp73hJPRlU 35fFrkYIq2dN61pvOtaDtLWueRwQADs= ------=_NextPart_000_0004_01C72F66.5E80FDB0-- From mpls-bounces@lists.ietf.org Thu Jan 04 05:40:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2PzK-0005K3-Rj; Thu, 04 Jan 2007 05:38:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2PzK-0005JL-4U for mpls@ietf.org; Thu, 04 Jan 2007 05:38:22 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2PzI-0006wa-MO for mpls@ietf.org; Thu, 04 Jan 2007 05:38:22 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 11:38:13 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 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] Comments on draft-decraene-mpls-ldp-interarea Date: Thu, 4 Jan 2007 11:38:05 +0100 Message-ID: <5A0FF108221C7C4E85738678804B567C0413EDFE@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-decraene-mpls-ldp-interarea Thread-Index: AccfmkHjR0kSSpKHSLmIzZzJQ69zWwQTcWKw From: "DECRAENE Bruno RD-CORE-ISS" To: X-OriginalArrivalTime: 04 Jan 2007 10:38:13.0494 (UTC) FILETIME=[6FA0B960:01C72FEC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08aa56e70047071f9a3037af5750d40e 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: , Errors-To: mpls-bounces@lists.ietf.org Eric, First, thank you for writing down your comments. Let me start by summarizing my understanding of your mail. You believe the draft should work but you have some concerns regarding: - A potential significant impact on the implementation - LDP interactions with the RIB - Specific cases Regarding these points I believe that: - The complexity of the changes on the implementation depends on the implementation itself. For some implementations there may be minor impacts while for others there may be more impacts. - The interactions with the RIB are very similar to the BGP and RIB interactions where BGP need to find and maintain the best match for the BGP next hop. AFAIK, these interactions are not specified in the BGP specification (RFC 4271) and different implementations had different strategies. Additionaly I believe the same kind of interactions are also needed for PIM (RPF check) and mLDP. So is this draft the best place for this discussion? - The specific cases described are indeed valid technical points but most -if not all- are not specific to the draft and also applies to RFC 3036. As next steps, may I suggest that: - LDP coders express their opinion regarding the draft. For example do you think the draft would work? Can be implemented? How hard would it be compared to the implementations of others drafts/RFC? (eg Gracefull Restart, mLDP, ...). - Service Providers express their opinion regarding the draft. For example do you think it would be usefull that LDP be able to set up inter area LSPs while performing IP aggregation on Area Border Router? Would you use the hierarchical solution (using BGP plus LDP to set up inter area LSPs) for all deploiments? Would you use a flat solution (LDP) if available? - You send some feebacks and possibly improve the text I proposed to add in the draft to answer some of your concerns? Following are more detailled answers to the points you raised. Eric Rosen wrote: > In San Diego I expressed some concerns about > draft-decraene-mpls-ldp- interarea, and Loa asked me to write them up=20 > for this list. > > I certainly can't say at this time that the draft just won't work,=20 > but I'm not currently convinced that the complexity is fully=20 > understood, or that the proposed procedures will really achieve all > their goals. =20 >=20 > A summary of my concerns is the following: > > - The draft purports to be making a simple change to the LDP > procedures, but I believe it's actually a fairly involved change > to the implementation. > In particular the interaction between > routing, LDP, and the maintenance of the forwarding tables is made > more complicated, but the details are not fully specified. > > - The draft has LDP put prefixes into the forwarding table that > would not otherwise be there. Currently, LDP doesn't do this, > it just puts in labels for prefixes that have been installed by > routing. This means that LDP would have functionality that was > formerly in the domain of routing. The interactions of LDP with > the various routing algorithms under a variety of circumstances > must therefore be carefully considered. However, the draft has very > little about this. To be precise, we don't necessarily need the LSR to act as LER for this FEC (ie "forward packets that arrive unlabeled, but which are to be labeled before being forwarded"). We need this FEC be available to other protocols; typically MP-BGP to have an LSP toward the BGP next-hop. Nothing requires that LDP puts prefixes in the forwarding table. We need to put these prefixes in the RIB and some implementations have some part of the RIB which is not downloaded in the FIB. To come to your point, agreed LDP now needs to put prefixes in the RIB. But only for prefixes for a which routing protocols have already advertised IP reachability (through a superset) and defined the route to use to reach these prefixes. In others words, the advertisement of IP reachability and the selection of the route to reach these IP prefixes are still required to be done by routing protocols. LDP does not take any routing decision and does not change at all the path that will be followed for a given prefix. Hence it cannot be considered as a routing protocol. Installing entries in the FIB is not a sufficient condition to be a routing protocol. The routing protocol is in charge of determining a route for a given prefix, which LDP does not do. In short, the IGP already advertises IP reachability and the path to use to reach the remote PE. IP is working just fine. What we are lacking for MPLS to also be working are the labels for each remote PE. Isn't LDP the good candidate for this task ? Regarding the addition of a prefix in the RIB by a non routing protocol, is this a real issue? Doesn't RSVP-TE also install the tunnel destination prefix in the RIB? =20 > - The draft focuses on the use of the new procedures in a particular > sort of deployment scenario, and doesn't say much about the effects > on the network if the procedures were to be used in other > deployment scenarios, or if the procedures were misconfigured, etc. The deployement scenario is the set up of inter area LSPs and the draft describe procedure for this.=20 Do you think of others deployement scenario for which this procedure should be useful? Regarding misconfiguration, in the general case, any protocol will not behave as expected if the network operator makes a mistake. If the procedure is misconfigured (activated by error or activated on FECs which are normally advertised in the routing protocols and should behave according to RFC 3036), in case of egress LER failure, the LSP to this LER may not be immediately removed following the IGP convergence because some IP aggregate prefixe may still match the FEC. In this case the LSP will be removed by LDP when the withdraw messages are propagated (cf draft section 6.2).=20 Would this be fine for you if we add such text? > - I think that the major purpose of the proposal is to facilitate the > use of LDP-based node protection for area border routers. =20 > However, I am not convinced that the proposal really achieves this=20 > goal. One goal is to be able to keep IP aggregation between IGP area. I believe we both agree that this is a desirable goal. To achieve this goal, some may favor a hierarchical solution. Others may favor a flat solution. Regarding Orange/France Telecom, at least for one deployement we favored the flat solution when we introduced IGP areas because this is easier: PE routers in edge areas have the same configuration and use the same protocols as existing routers in the backbone areas. (more on this latter) =20 > Let me start by summarizing my understanding of the draft. The > problem > addressed by the draft is the following. There are a number of=20 > situations in which an ingress PE needs to send a packet on an LSP=20 > tunnel whose "LSP egress" is a PE router (the "egress PE"). This > requires the "tunnel label" =20 > to be bound to a /32 prefix for the egress, which in turn requires=20 > that the ingress PE's forwarding table contain a /32 prefix for each=20 > potential egress PE. > > The authors describe a deployment scenario in which the service=20 > provider's backbone is a multi-area IS-IS or OSPF network, containing=20 > tens of thousands of PE routers distributed across the areas. The=20 > usual way of getting all the /32s in each ingress PE's forwarding=20 > table is to have all IGP area border routers leak all the /32s into > each area. Then the IGP ensures that each ingress PE's > forwarding table is populated with all the /32s. =20 >=20 > The problem is that the intra-area IGP protocols don't scale up well=20 > as the number of prefixes increases into the tens of thousands. > Therefore it would be desirable to have some other way of getting=20 > all the /32s into the forwarding tables of the ingress > PEs. =20 >=20 > The proposal is to use LDP, rather than the IGP, to distribute the=20 > /32s and to ensure that the ingress PE's forwarding tables are > properly populated with the /32s. =20 > Note that this does not really reduce the resources in the core=20 > needed to support the LSPs to the PEs, it simply changes the=20 > protocol which is used to allocate some of those resources. you don't change the protocol as you still use LDP. You use one protocol instead of two. Instead of advertising the prefixes twice you advertise them only once.=20 > Resource consumption in the P routers of a given area is still > proportional to the total number of PEs in all the areas. =20 This allow to advertise the /32s only in LDP rather than both in LDP and the IGP. This is an obvious significant gain for the IGP. Agreed there is no gain (but no loss either) for LDP or the forwarding table. Besides, this seems reasonable for me to put the burden on LDP rather than the IGP because IP doesn't need these /32 whereas MPLS does. Additionaly LDP uses incremental messages over TCP so seems better suited than link state IGP. Not to mention that link states IGP are not designed for advertising tens of thousands of prefixes, especially when advertised by a single node (the ABR in our case). For instance with IS-IS there is an hard limitation around 42K IPv4 prefixes (max LSP fragment size =3D 1496 and max #fragments =3D 256) (and even less if = IPv6 is deployed). In return with LDP there is not such limitation. =20 > It might seem that a better solution would be to use hierarchy, so=20 > that the P routers do not have to maintain an LSP for each egress=20 > PE. For instance, BGP between the border routers could carry the=20 > /32s, without any need for the P routers to maintain the /32s are=20 > all. However, I think that the authors actually want to the P=20 > routers maintain an LSP for each egress PE, because they believe=20 > this to be a necessary condition of applying node protection when=20 > a border router fails. So they frame the problem not as one of=20 > reducing the resource usage in the core, but as one of finding a > better protocol to allocate those resources in the core. =20 The use of hierarchy is a perfectly valid solution. It has pro & con compared to the use of LDP inter area. As you said the advantage is that it does not require P routers to maintain the /32. However, one may weight this advantage in regard to the (usually) small numbers of P routers compare to the high number of PE routers. One disadvantage is that it requires BGP on ABR. Depending on some engineering choice, it may also requires that ABRs be iBGP route reflectors and change the BGP next hop to themselves. Another disadvantage is that the set up of PE to PE LSP requires two protocols (LDP plus BGP) and two labels instead of one. This may add complexity to the monitoring and the troubleshooting. =20 > One could of course put IBGP in all the P routers and use IBGP to=20 > distribute the /32s. However, the authors do not like the=20 > operational implications of putting BGP in the core. I'm not sure=20 > they've considered a restricted use of BGP for distributing only the=20 > egress PE addresses; I believe we did. The use of BGP to carry labelled IPv4 unicast adresses (as per RFC 3107) is only needed on ABR and PE (and probably iBGP route reflector), not on P routers. I would not call this a "restricted use" as is requires modifying BGP configurations (new AFI/SAFI, probably new iBGP peers) on all PE and RR ie 90% of the network equipments in the network. To conclude on the hierarchical solution, do you think we should add a section in the doc to present it and explain why this alternative does not fit all deployments ? Personnaly I'm not sure this would fit well in a solution draft. Such analysis should be part of an applicability statement draft. > often when we talk of a "BGP free core", what=20 > it really important is that the core be free of =20 > external routes, rather than that it be free of BGP protocol.=20 I agree that removing the external routes really matter but if you can also get rid of BGP on P routers that's an additional benefit. Some service providers do have BGP free core and they did it on purpose. > But in any event they propose to use LDP. >=20 > I think the proposed operational model is the following: >=20 > - A PE, say PE1, is configured to bind a label to its own address=20 > A (as a /32 prefix),a and to use LDP distribute this label > binding to its neighbors. >=20 > - If P1 is a neighbor of PE1, and PE1 is P1's next hop for A,=20 > and P1 receives a label binding for A from PE1, then P1 must put > an entry in its FIB for A, with the label distributed by PE1. >=20 > - P1 must then assign a label of its own to A, and use LDP to > advertise the binding A and that label to P1's neighbors. >=20 > - Using LDP ordered mode, this process proceeds out to the edges=20 > of the network. However, it does not go beyond the edges. >=20 > This operational model is not completely clear to me. I surmise > that each > PE needs to be configured to begin this process.=20 I'm not sure to follow you. Especially I fail to see the difference between your above text and the existing LDP ordered distribution mode. This does not necessarily require any configuration, this can be done by default (advertise FEC for which you're egress eg your loopback), this is how many LDP implementations work today. > I'm less clear > about how other nodes know whether or not they are on the "edge" > of the network.=20 They don't need to know that they are on the edge. FEC propagation stops when there is no LDP session with the downstream (Typically on the edge of the AS) or when the downstream has no IP route with the upstream for the FEC. Just like today. The only change beeing the "match algorithm" between FEC and RIB prefixes. > I think the authors have in mind a deployment > scenario in which the "edges" =20 > are inter-AS interfaces and VRF interfaces, but inter-area=20 > interfaces are not considered to be edges. But I'm not sure what the > model is supposed to > be in general. Are VRF interfaces always edges, even if Carrier's > Carrier is being used?=20 In section 5 "Application examples" of the draft, the authors have described a deployment scenario in which the "edges" of the SP network are the PE ("Provider Edge"). Regarding VRF Carrier's Carrier, even if LDP is used to distribute MPLS labels to the VPN customer (rather than BGP with RFC 3107), they advertise customers prefixes, not SP ones. So there is no relation between the LDP in the core and the LDP in the VRF carrier's carrier; Just like there is no relation between the routing protocol in the core (the SP one) and the routing protocol in the VRF (the customer one). > Are inter-AS interfaces always edges, even if a single SP has broken > his network into several ASes. If you refer to BGP confederation, I suppose it depends if you use one IGP or multiple IGP.=20 If have one IGP, you don't have IGP frontier or borders so you don't have issue with LDP mandating a longest match. If you have multiple IGPs, - if ASBRs change the BGP next hop I don't see the need to leak the /32 in the IGP and LDP from one AS to the other. - if ASBRs preserve the BGP next-hop, you need to advertise to the other AS IP reachability for the routers next-hop and you typically have the same use as in the inter area case described in the draft: either you advertise all the /32 in the IGP, or you need a hiearchical solution, or you need the LDP inter area draft. If you refer to inter AS VPN model C, this is basically identical to the last case described in the above text. (you can use a hiearchical solution or the ldp-inter-area draft) > Is it true that > inter-area links are never edges, or is this meant to be=20 > configurable? Inter-area links are edge from the point of view of the link state IGP. If you leak all /32, you don't have issue with LDP mandating the exact match. If you don't, you need a solution (again, hierarchy or LDP inter area). This is a matter of choice for the SP. > If the latter, are there deployment requirements for > all area border routers to be configured the same? =20 Currently, IGP policy allows you to have different rules (leaking or aggregation) per ABR/area but usually SPs perform the choice once and apply it globally. The draft does not change this. (I'm not sure I got your point so please elaborate on this if I missed it) > In any event, the authors note that the use of LDP in this=20 > manner is explicitly prohibited by the LDP specification, which=20 > requires that LDP not install a label for any prefix if that exact=20 > prefix has not already been installed in the forwarding table by=20 > routing. That is, LDP cannot bind a label to a prefix unless that > prefix is an exact match to one installed by routing. =20 >=20 > This prohibition didn't get there by accident. It was put there=20 > deliberately to ensure that LDP cannot "second guess" routing by=20 > creating paths which differ from the paths created by routing. Could you provide any relevant reference where the exact reason(s) for this limit is/are detailed ? In the inter area draft, LDP entirely relies on the routing decisions taken by the routing protocol. LDP DOES NOT TAKE ANY ROUTING DECISION. Could you please provide one example where the draft would have LDP create path which would differ from the paths created by routing? > After all, LDP does > not have its own procedures for deciding which path an LSP should=20 > follow, it depends upon routing for this. Absolutely. This is definitely not changed by the draft and LSPs set up by LDP still strictly follow the path chosen by routing protocols. =20 > The authors propose to remove this prohibition, and instead impose=20 > a more sophisticated restriction, which they express as follows: >=20 > "This procedure is similar to the one defined in [LDP] but=20 > performs a longest match when searching the FEC element in the RIB=20 > ... >=20 > With this new longest match label mapping procedure, a LSR > receiving a Label Mapping message from a neighbor LSR for a Prefix > Address FEC Element SHOULD use the label for MPLS forwarding if > its routing table contains an entry that matches the FEC Element > and the advertising LSR is a next hop to reach the FEC. If so, it > SHOULD advertise the FEC Element and a label to its LDP peers. >=20 > By 'matching FEC Element', one should understand an IP longest=20 > match." >=20 > The intention is to maintain the requirement that LDP not alter the=20 > routing, while allowing LDP to install prefixes that are not=20 > installed by routing. > They propose to allow LDP to install a prefix if and only if there > is a corresponding less specific prefix that has been installed by > routing. > Further, the next hop of the LDP-installed prefix is constrained to=20 > be the same as the next hop of the less specific prefix, as=20 > determined by routing. > This should ensure that labeled packets always follow the path that=20 > has been determined by routing to be the best path. I understand from your conclusion that removing the LDP requirement for an *exact* match should be ok from a routing point of view.=20 =20 > It must be understood that this procedure adds considerable=20 > complexity to the maintenance of the forwarding tables. >=20 > In existing LDP deployments, all LDP does with regard to the=20 > forwarding table is to supply the label for a given hop> pair which routing has installed in the forwarding table. > In the proposal, LDP has a number of additional jobs to do with > regard to the forwarding table. Let's define some terminology: =20 >=20 > - Let RP be a prefix distributed by routing. > - Let NH(RP) be the next hop for RP. > - Let LP(i) be a prefix distributed by neighbor i using LDP. > - Let RP(i) be the set of LDP-distributed prefixes from neighbor i > for which RP is the longest match. >=20 > If NH(RP) changes from i to j, things aren't too hard, as long as > RP(i) is identical to RP(j). Then you just have to change the next=20 > hop and outgoing label for each prefix in RP(i). Agreed. BTW this is basically the current LDP behavior. The difference being that currently, at most one FEC have its next-hop change where as with the ldp-interarea draft, multiple FECs can have their next-hop changed. =20 > It's a bit more complicated if RP(j) is different from RP(i). =20 > Now some prefixes need to get their nh and label changed, but others > need to either be put into or pulled out of the forwarding table entirely. IMHO, the difference is the same: with the draft multiple FECs may have to be updated whereas currently the "set of LDP-distributed prefixes" is limited to 1 (or 0) element. In RFC 3036 (current LDP) for a given FEC three cases are possible following a routing change - nh and label changed - new FEC put in - FEC pulled out We have the same cases with the draft. The difference is that the set is not limited to 1 FEC and multiple FECs may need to be updated. > It's even more complicated if routing installs a new prefix, RP2,=20 > which is more specific than an already installed prefix RP1, but=20 > less specific than some members of RP1(i). (And possibly more > specific than some other members =20 > of RP1(i)). Now one has to figure out which members of RP1(i)=20 > remain in > RP1(i) and which are now in RP2(i). In fact, one has to figure this=20 > out for each of the neighbors. Indeed the case where the routing install a new prefix more specific than the one used to match some FEC is a new behavior. Indeed for this case the LSR need to detect that the new prefix is a better match. The impact on the implementation is probably very implementation dependent so its hard to discuss it from a general point of view. One implementation strategy is that LDP ask the RIB the next hop to use for its FEC (ie the IP best match) and ask to be notified of a change. In this case, LDP only has to deal with three cases: - next-hop change - next-hop disappeared (there is no route for the FEC) - next-hop appeared (routing advertised a new route which for a FEC which had previously no route)=20 These 3 cases would not be different from the existing cases from RFC 3036 so this would not "add considerable complexity". You would probably argue that the complexity is pushed to the RIB but BGP has exactly the same job to do to resolve its BGP Next Hop so this is definitely doable and has been so for some years. > Certainly this could all be made to work, but it's not exactly the=20 > simple change that the draft suggests it is. The change is minimal from a specification point of view. The impact on the implementation may be significant or not but this is very implementation dependent. > It would be nice to > see section 4 replaced with a much more comprehensive treatment of=20 > how the interaction between routing events and LDP events affects=20 > the forwarding tables. I am not at all sure that I yet > understand all the implications. =20 Ok. What about adding something like: "As per RFC 3036, LDP has already some interactions with the RIB. In particular, it needs to be aware of the following events: - prefix UP when a new IP prefix appears in the RIB - prefix DOWN when an existing prefix disappears - next hop change when an existing prefix have new next hop following a routing change. With the longest match procedure, some LSR reactions following a RIB event are changed: - When a new prefix appears in the RIB, the LSR MUST check if this prefix is not a better match for some existing FECs. (Eg the FEC elements 10.0.0.1/32 and 10.0.0.2/32 used the IP RIB entry 10.0/16 and a new more specific IP RIB entry 10.0.0/24 appears). This may result in changing the LSR used as next hop and hence a change of outgoing label for this FEC. - When a prefix disappears in the RIB, the LSR MUST check all FEC elements which were using this RIB prefix as best match. For each FEC, if another RIB prefix is found as best match, LDP MUST use it which may result in changing LSR used as next hop for this FEC and hence a change of outgoing label for this FEC. Otherwise, the LSR MUST remove the FEC binding and send a label withdraw message." As your detailed comments shows you've started the analysis, your input or comments on this would be welcomed. However the following protocols already have similar interactions with routing event: BGP (from BGP next hop resolution), PIM (for RPF check), mLDP (to determine the 'upstream LSR') and probably others. They don't specify this interaction so I'm not sure to understand why suddenly this becomes needed for the inter area draft.=20 =20 > The draft also needs a lot more consideration of "corner cases". >=20 > For instance, what if BGP and LDP each distribute the same /32 prefix, > while IGP distributes a less specific prefix? > It's not immediately obvious > whether the LDP-distributed prefix is supposed to match the=20 > IGP-distributed less specific prefix, thereby replacing the=20 > BGP-distributed prefix, or whether the LDP-distributed prefix is > supposed to match the BGP-distributed =20 > prefix.=20 This is not really specific to the draft. I don't think that RFC 3036 specifies that the routing protocol advertising the prefix in the RIB should be taken into account. This should probably not be changed. Do you think different implementations made different choice? Ie some implementations consider the whole RIB whereas some other implementations filter out the RIB prefixes learnt through BGP?=20 In that case: - which would be the correct behavior (originally intended by RFC 3036)? - would both implementations be compliant with RFC 3036? - that would create an interoperability issue for the ldp-interarea draft because different implementation could select different prefixes in the RIB and that could lead to permanent routing loops. So we would need to mandate only one behavior. We will select it based on your and the MPLS WG feedback. > It's also not clear just what you'd have to do if the=20 > LDP-distributed prefix matched a BGP-distributed prefix, because the=20 > notions of "next hop" are different. Not sure I fully got the point but it seems to me that the question is not really specific to the draft and is also valid for RFC 3036 : LDP: FEC 10.0.0.1/32 BGP NLRI 10.0.0.1/32 NH ABR IGP: ABR -> interface I > To add a further > complication, suppose that the BGP-distributed prefix is really a > labeled-IPv4 prefix. What is the relation between the > BGP-distributed label and the LDP-distributed label? =20 > Are they both used, or not? Questions like these need to be > addressed, and > the implications of answering them one way or another need to be=20 > considered. This is definitely not specific to the draft. The same question is already valid with the current LDP specification (RFC 3036). Additionaly we have the same question with IPv4 unicast prefixes. Usually implementations I'm aware of use some kind of administrative distance / preference ranking protocols priorities. > Here's another case worth considering. Consider an intermediate P=20 > router, P1, with neighbors P2 and P3. Suppose: >=20 > - IGP distributes a route to prefix X. > - Using LDP, P2 distributes a label for prefix Y, where X is the > "longest match" for Y. > - P3 does not use LDP to distribute a label for Y. > - At time t0, the next hop at P1 for X is P2. > - At time t1, the next hop at P1 for X is P3. >=20 > I think this means that at time t1, any packets which P1 receives=20 > that have been labeled for Y will be dropped by P1. Why? The more=20 > specific prefix Y will have to be removed from the forwarding table=20 > at t1, as the conditions for having it in the forwarding table no=20 > longer seem to hold, given the P3 has not distributed a label for=20 > the longer prefix. Thus the labels that correspond to Y will also=20 > be removed, and packets which have already been labeled for Y will=20 > find that there is no outgoing label corresponding to the incoming > label. This means they must be dropped. =20 This is not specific to the draft. We have exactly the same issue with RFC 3036 (replacing "Y" by "X" and "longest match" by "exact match"). =20 > One could dismiss this as a transient, but if the whole reason for=20 > doing any of this is to make node protection work, i.e., to avoid the > bad effects of routing transients, then one presumably is not > willing to just dismiss transient effects. =20 >=20 > This scenario could occur, e.g., if a given egress PE can be reached=20 > via two different ABRs, where one of them is implementing the draft=20 > but the other is not (or where one is configured to use the draft=20 > procedures but the other is not). One could dismiss this as an=20 > operator error, This is not specific to the draft. This scenario can already occur with the current RFC 3036 if the operator forgot to configure LDP on the backup P/path. > but it can also happen if a new ABR comes up and=20 > the distribution of routing info across the =20 > network proceeds faster than the distribution of LDP info. =20 This is not specific to the draft. It also already occurs with RFC 3036 if a new P comes up and the distribution of routing info across the =20 network proceeds faster than the distribution of LDP info.=20 (BTW it also occurs with iBGP (IGP convergence precede iBGP sessions going up and running. Hence customer traffic is dropped) > Note that on a > single link, we can implement procedures which keep the link from=20 > coming up to routing until LDP has distributed labels over the link,=20 > in order to keep things like this from happening. This is not specific to the draft. It's already implemented on some boxes to fixe the two above cases. > That's fine as > long as LDP operations are per-link. When we start to provide LDP=20 > operations that have edge-to-edge significance, such as using LDP to=20 > build a path for X across the network, we don't have any similar way > to synchronize the LDP and IGP info. =20 I'm not sure to follow your point. Could you please be more specific?=20 =20 > There may be other corner cases as well. >=20 > If a decision is made to pursue this draft, I think it needs to=20 > have a fairly comprehensive treatment of (a) all the possible=20 > interactions between and routing, and (b) the behavior of the scheme > when deployed in other than =20 > the intended manner.=20 > Also, if the main purpose of the draft is to facilitate an=20 > LDP-based node protection scheme for border routers, it should provide > a better assurance that it doesn't leave a number of transient=20 > conditions unprotected. > Without this additional work, I think it is difficult to tell=20 > whether this is ultimately a direction worth pursuing. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mizuki@19room.info Sun Jan 07 05:49:07 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3VaN-0007Oh-3O for mpls-archive@lists.ietf.org; Sun, 07 Jan 2007 05:49:07 -0500 Received: from [203.82.16.52] (helo=lists.ietf.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H3VaK-0002C7-9C for mpls-archive@lists.ietf.org; Sun, 07 Jan 2007 05:49:05 -0500 To: From: =?iso-2022-jp?B?GyRCJF8kOiQtGyhC?= Subject: =?iso-2022-jp?B?GyRCIXkkXyQ6JC0kTjlwR3IkRyQ5ISobKEI=?= MIME-Version: 1.0 Reply-To: Date: Sun, 07 Jan 2007 07:52:30 +0900 Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.3 (+++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 $B(.(!(/(.(!(/(.(!(/(.(!(/(.(!(/(.(!(/(.(!(/(.(!(/(B $B(-"v(-(-$"(B $B(-(-$((B $B(-(-$k(B $B(-(-$8(B $B(-(-$c(B $B(-(-$s(B $B(-(-"v(B $B(-(B $B(1(!(0(1(!(0(1(!(0(1(!(0(1(!(0(1(!(0(1(!(0(1(!(0(B $B=w$N;R$@$C$F!"C/$K$bCN$i$l$:!"(B $BBgC@$JHkL)$NLk$r2a$4$7$?$$$3$H$,$"$k$N!&!&!&!#(B $B$9$C$4$/%(%C%A$J5$J,$N;~$,$"$k$1$I!"H`;a$H%^%s%M%j$+$J$!$C$F!#(B $B:G=i$+$i%(%C%A$,L\E*$G2q$&$+$i!"IaDL$N=P2q$$7O$h$j$9$02q$($k$3$H$,$$$$$H;W$$$^$9!#(B $B$9$4$/G/>e$N?M$H$+!"5U$KG/2<$N;R$H$+!"(B $BIaCJ$J$iCN$i$J$$$h$&$JBgC@$J$3$H$bJ?5$$G$G$-$A$c$&$+$iIT;W5D!*(B $B$b$A$m$s!"$*8_$$HkL)87 From info@diga-tec.de Mon Jan 08 20:24:40 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H45jE-0000q0-JE for mpls-archive@lists.ietf.org; Mon, 08 Jan 2007 20:24:40 -0500 Received: from [222.181.28.44] (helo=yq-5evu93lhyku9) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H45j2-0008DM-32 for mpls-archive@lists.ietf.org; Mon, 08 Jan 2007 20:24:38 -0500 Received: from 212.227.15.134 (HELO mx00.schlund.de) by lists.ietf.org with esmtp (*.3.+R95- .SQU) id .)6I50-E-G.7@--8 for mpls-archive@lists.ietf.org; Tue, 9 Jan 2007 01:24:36 -0480 Date: Tue, 9 Jan 2007 01:24:36 -0480 From: Broker Alert! X-Mailer: The Bat! (v2.12.00) Educational X-Priority: 3 (Normal) Message-ID: <970812658.25471737506564@thebat.net> To: mpls-archive@lists.ietf.org Subject: Double or triple your investments just per 1 week. Go WDSC! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 1.8 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Do it right now do not miss this great opportunity! Following a meetingHe told the BBC there would be no UN troops. About three= million have fled their homes.
Untitled Document
WORLDSOURCE INC.
GET WDSC (WORLDSOURCE INC)
VALUABLE = THING AFTER NEW YEAR. THIS IS GOING TO EXPLODE!
JUST EXAM= INE FOR HOT NEWS ABOUT THIS COMPANY. THE ALERT IS STARTED!!!
YOUR BROK= ERAGE SITE HELPS YOU TO KNOW THE HOT NEWS ON WDSC.
IT=92S GE= TTING GROWTH ALMOST EVERY HOUR! MORE THAN 80%= DAILY FROM STARTING PRICE.
HARDLY YO= U HAD A CHANCE TO TRIPLE YOUR INVESTMENTS JUST PER 1 WEEK.
CALL YOU = BROKERS IMMEDIATELY AND MAKE THEM TO GET IT. DO NOT MISS YOUR POSSIBILITY!!= !
GO WDSC!

Chad in anti-Sudan alliance President Omar al-Bashir told state TV: "The g= overnment of Sudan welcomes all financial, material, logistic or technical = assistance from the UN in order to strengthen the AU mission in Darfur." Su= dan has always rejected plans to replace the AU force with a larger, strong= er UN mission. On Thursday, UN chief Kofi Annan had said a compromise had b= een reached for a hybrid UN-AU force, to break the deadlock over the Darfur= mission. More than 200,000 people have died in three years of conflict in = the region. On Thursday, UN chief Kofi Annan had said a compromise had been= reached for a hybrid UN-AU force, to break the deadlock over the Darfur mi= ssion. More than 200,000 people have died in three years of conflict in the= region. His Foreign Minister Lam Akol specified that "there should be no t= alk about a mixed force".
From mpls-bounces@lists.ietf.org Wed Jan 10 05:07:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4aJ2-0006AA-66; Wed, 10 Jan 2007 05:03:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4aJ0-00068s-Eo for mpls@lists.ietf.org; Wed, 10 Jan 2007 05:03:38 -0500 Received: from web7915.mail.in.yahoo.com ([202.86.4.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4aIh-0006jc-3p for mpls@lists.ietf.org; Wed, 10 Jan 2007 05:03:38 -0500 Received: (qmail 56469 invoked by uid 60001); 10 Jan 2007 10:03:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=X1pFL0apCubWs25jqg7cTq2R8DqRe2TFi9UXqfsLKKw3VGAXIG74IH2OX3du+k8dTi+3DhfDMhxY6fnYVbZKd0+xyUGgsxCdk3nUbylRg7TmxpYXQb88FtRedxd8CG5W8qDDK7O+QxObfiayG4saAGPAK9vjitRYXY9buBlU5dk= ; Message-ID: <20070110100308.56467.qmail@web7915.mail.in.yahoo.com> Received: from [203.197.124.190] by web7915.mail.in.yahoo.com via HTTP; Wed, 10 Jan 2007 10:03:08 GMT Date: Wed, 10 Jan 2007 10:03:08 +0000 (GMT) From: anathbandhu garai To: mpls@lists.ietf.org MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [mpls] RSVP-TE Fast Reroute 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="===============0531050392==" Errors-To: mpls-bounces@lists.ietf.org --===============0531050392== Content-Type: multipart/alternative; boundary="0-430157935-1168423388=:53286" --0-430157935-1168423388=:53286 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Hi,=0A =0A Can somebody help me to understand Fast Reroute Extensions to RS= VP-TE for LSP Tunnels (rfc 4090)?=0A =0AWhat I understand from the standard= that is,=0Athere are two backup methods according to the standard (rfc 409= 0) for LSP Tunnels -- One-to-One and Facility backup.=0A =0AIn case of One-= to-One backup method, after the Resv message reaches at PLR from the downst= ream in the path of the protected LSP, then PLR signals Path message prior = to link/node failure through a detour path destined to next-hop node (link-= protection) or next-next-hop node (node protection).=0A =0AIn case of Facil= ity backup method, after the Resv message reaches at PLR from the downstrea= m in the path of the protected LSP, then PLR selects a bypass path (already= exists) destined to next-hop node (link-protection) or next-next-hop node = (node protection) and does not signals through that path prior to the link/= node failure unless MP uses interface specific label.=0A =0ANow if I am rig= ht, then how does PLR select backup path in both the cases?=0AI think that = IGP can help to select the backup path in a single IGP domain.=0A =0ABut in= case of inter-domain, is node-id subobject in RRO (rfc 4561) enough to do = it?=0A =0AActually I am facing a problem to get the PLR behavior from the C= isco and as well as Juniper router=0Athough I did not try using IGP.=0ACan = anyone give me any suggestion regarding this? It will help me a lot.=0A =0A= Thanks in advance.=0A =0ARegards,=0AAnath Bandhu Garai=0A=0A=0A=09=09=0A___= _______________________________________________________=0AYahoo! India Answ= ers: Share what you know. Learn something new=0Ahttp://in.answers.yahoo.com= / --0-430157935-1168423388=:53286 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
Hi,
=0A
 
=0A
 Can somebod= y help me to understand Fast Reroute Extensions to RSVP-TE for LSP Tunnels = (rfc 4090)?
=0A
 
=0A
What I understand from the sta= ndard that is,
=0A
there are two backup methods according to the s= tandard (rfc 4090) for LSP Tunnels -- One-to-One and Facility backup.
= =0A
 
=0A
In case of One-to-One backup method, after the = Resv message reaches at PLR from the downstream in the path of the protecte= d LSP, then PLR signals Path message prior to link/node failure throug= h a detour path destined to next-hop node (link-protection) or next-next-ho= p node (node protection).
=0A
 
=0A
=0A
In case = of Facility backup method, after the Resv message reaches at PLR from = the downstream in the path of the protected LSP, then PLR selects a by= pass path (already exists) destined to next-hop node (link-protec= tion) or next-next-hop node (node protection) and does not signals through = that path prior to the link/node failure unless MP uses interface spec= ific label.
=0A
 
=0A
Now if I am right, then = how does PLR select backup path in both the cases?
=0A
I think tha= t IGP can help to select the backup path in a single IGP domain.
=0A 
=0A
But in case of inter-domain, is node-id subobject in= RRO (rfc 4561) enough to do it?
=0A
 
=0A
Actu= ally I am facing a problem to get the PLR behavior from the Cisco and as we= ll as Juniper router
=0A
though I did not try using IGP.
=0A<= DIV>Can anyone give me any suggestion regarding this? It will help me a lot= .=0A
 
=0A
Thanks in advance.
=0A
 =0A
Regards,
=0A
Anath Bandhu Garai
=0A
 

=0A=09=0A=0A=09=0A=09=09
=0AHere=A2s a new w= ay to find what you're looking for - Yahoo! Answers --0-430157935-1168423388=:53286-- --===============0531050392== 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 --===============0531050392==-- From mpls-bounces@lists.ietf.org Wed Jan 10 07:34:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4cc0-0002tZ-SJ; Wed, 10 Jan 2007 07:31:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4cbz-0002tO-Ff for mpls@lists.ietf.org; Wed, 10 Jan 2007 07:31:23 -0500 Received: from web8810.mail.in.yahoo.com ([203.84.221.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4cbt-0000ak-P5 for mpls@lists.ietf.org; Wed, 10 Jan 2007 07:31:23 -0500 Received: (qmail 40773 invoked by uid 60001); 10 Jan 2007 12:30:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=GcbtsoI7YnDgxYOZJ0YfHRJ/ULwE1cAsLjeZznpOId/ESztd9IWAJ4vgxCXSTCg3yC1Rr/CPie/Q4+duV50Kln/3eo97yJHcsAXJtwOEXNZhZyRForWtbogmqKQCaNL2K6hmZ6orZ4f0mcZJDXtOG1zoYBlteFESgqwtRGVHRtI= ; Message-ID: <20070110123050.40771.qmail@web8810.mail.in.yahoo.com> Received: from [202.144.106.188] by web8810.mail.in.yahoo.com via HTTP; Wed, 10 Jan 2007 18:00:50 IST Date: Wed, 10 Jan 2007 18:00:50 +0530 (IST) From: Ramesh Huliyar Subject: Re: [mpls] RSVP-TE Fast Reroute To: anathbandhu garai , mpls@lists.ietf.org MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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="===============1630595936==" Errors-To: mpls-bounces@lists.ietf.org --===============1630595936== Content-Type: multipart/alternative; boundary="0-396200651-1168432250=:39494" --0-396200651-1168432250=:39494 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable Hello Anath,=0A=0ALSP (holds true for backup tunnel as well) are usually si= gnalled to the node-id which would usually be the router-id also. So it is = important to know the node-id of the downstream LSR in different domain (ei= ther area or autonomous systems). Now is only node-id sufficient to compute= the backup-path, the answer is No. =0A=0ASection 3 of RFC4726 "Framework f= or Inter-Domain TE" provides enough information to calculate a path to the= egress in a different domain (in this case MP). I hope this solves your qu= estion.=0A=0AThanks=0ARamesh Huliyar=0A=0A=0A=0A----- Original Message ----= =0AFrom: anathbandhu garai =0ATo: mpls@lists.ietf.= org=0ASent: Wednesday, 10 January, 2007 3:33:08 PM=0ASubject: [mpls] RSVP-T= E Fast Reroute=0A=0AHi,=0A=0A =0A=0A Can somebody help me to understand Fas= t Reroute Extensions to RSVP-TE for LSP Tunnels (rfc 4090)?=0A=0A =0A=0AWha= t I understand from the standard that is,=0A=0Athere are two backup methods= according to the standard (rfc 4090) for LSP Tunnels -- One-to-One and Fac= ility backup.=0A=0A =0A=0AIn case of One-to-One backup method, after the Re= sv message reaches at PLR from the downstream in the path of the protected = LSP, then PLR signals Path message prior to link/node failure through a det= our path destined to next-hop node (link-protection) or next-next-hop node = (node protection).=0A=0A =0A=0A=0AIn case of Facility backup method, after = the Resv message reaches at PLR from the downstream in the path of the prot= ected LSP, then PLR selects a bypass path (already exists) destined to next= -hop node (link-protection) or next-next-hop node (node protection) and doe= s not signals through that path prior to the link/node failure unless MP us= es interface specific label.=0A=0A=0A =0A=0ANow if I am right, then how doe= s PLR select backup path in both the cases?=0A=0AI think that IGP can help = to select the backup path in a single IGP domain.=0A=0A =0A=0ABut in case o= f inter-domain, is node-id subobject in RRO (rfc 4561) enough to do it?=0A= =0A =0A=0AActually I am facing a problem to get the PLR behavior from the C= isco and as well as Juniper router=0A=0Athough I did not try using IGP.=0A= =0ACan anyone give me any suggestion regarding this? It will help me a lot.= =0A=0A =0A=0AThanks in advance.=0A=0A =0A=0ARegards,=0A=0AAnath Bandhu Gara= i=0A=0A =0A=0A=0A=0A=09=0A=0A=09=0A=09=09 =0AHere=A2s a new way to find wha= t you're looking for - Yahoo! Answers _____________________________________= __________=0Ampls mailing list=0Ampls@lists.ietf.org=0Ahttps://www1.ietf.or= g/mailman/listinfo/mpls=0A=0A=0A=0A=0A=0A=0A=0A=09=09=0A___________________= _______________________________________=0AYahoo! India Answers: Share what = you know. Learn something new=0Ahttp://in.answers.yahoo.com/ --0-396200651-1168432250=:39494 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
Hello Anath,

LSP (holds true for backup tunn= el as well) are usually signalled to the node-id which would usually be the= router-id also. So it is important to know the node-id of the downstream L= SR in different domain (either area or autonomous systems). Now is only nod= e-id sufficient to compute the backup-path, the answer is No.

Secti= on 3 of RFC4726 "Framework for Inter-Domain TE"  provides enough infor= mation to calculate a path to the egress in a different domain (in this cas= e MP). I hope this solves your question.

Thanks
Ramesh Huliyar


----- Original Message ----
From: anathb= andhu garai <anath_bec04@yahoo.co.in>
To: mpls@lists.ietf.org
Sent: Wednes= day, 10 January, 2007 3:33:08 PM
Subject: [mpls] RSVP-TE Fast Reroute
Hi,
=0A
 
=0A
 Can somebody h= elp me to understand Fast Reroute Extensions to RSVP-TE for LSP Tunnels (rf= c 4090)?
=0A
 
=0A
What I understand from the standa= rd that is,
=0A
there are two backup methods according to the stan= dard (rfc 4090) for LSP Tunnels -- One-to-One and Facility backup.
=0A=
 
=0A
In case of One-to-One backup method, after the Res= v message reaches at PLR from the downstream in the path of the protected L= SP, then PLR signals Path message prior to link/node failure through a= detour path destined to next-hop node (link-protection) or next-next-hop n= ode (node protection).
=0A
 
=0A
=0A
In case of&= nbsp;Facility backup method, after the Resv message reaches at PLR from the= downstream in the path of the protected LSP, then PLR selects a bypas= s path (already exists) destined to next-hop node (link-protectio= n) or next-next-hop node (node protection) and does not signals through tha= t path prior to the link/node failure unless MP uses interface specifi= c label.
=0A
 
=0A
Now if I am right, then how= does PLR select backup path in both the cases?
=0A
I think that I= GP can help to select the backup path in a single IGP domain.
=0A
=  
=0A
But in case of inter-domain, is node-id subobject in RR= O (rfc 4561) enough to do it?
=0A
 
=0A
Actuall= y I am facing a problem to get the PLR behavior from the Cisco and as well = as Juniper router
=0A
though I did not try using IGP.
=0ACan anyone give me any suggestion regarding this? It will help me a lot.=0A
 
=0A
Thanks in advance.
=0A
 =0A
Regards,
=0A
Anath Bandhu Garai
=0A
 
=

=0A=09=0A=0A=09=0A=09=09
=0AHere=A2s a new way to = find what you're looking for - = Yahoo! Answers
_______________________________________________
= mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/li= stinfo/mpls


=0A=09=0A=0A=09=0A=09=09=
=0AHere=A2s a new way to find what you're looking for - = Yahoo! Answers --0-396200651-1168432250=:39494-- --===============1630595936== 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 --===============1630595936==-- From Based@ekomir.crimea.ua Thu Jan 11 07:28:52 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4z36-0004PO-T7 for mpls-archive@lists.ietf.org; Thu, 11 Jan 2007 07:28:52 -0500 Received: from [84.253.158.113] (helo=[84.253.158.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4z34-0001Tc-8Q for mpls-archive@lists.ietf.org; Thu, 11 Jan 2007 07:28:52 -0500 Received: from FSB (unknown [186.164.95.81]) by ekomir.crimea.ua with ESMTP id 96B6F81B1FF0 for ; Thu, 11 Jan 2007 13:29:07 +0100 (GMT) Message-ID: <000a01c7357c$0b0c70d0$00000000@XPold> From: "MBFact SearchLive" To: mpls-archive@lists.ietf.org Subject: swf crop mac mpc Date: Thu, 11 Jan 2007 13:28:48 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C73584.6CD0D8D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.8 (+) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 ------=_NextPart_000_0006_01C73584.6CD0D8D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C73584.6CD0D8D0" ------=_NextPart_001_0007_01C73584.6CD0D8D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Japanese, korean thai punjabi, love mandarin. Potato queens sweet charm = cure, magical. Volta own lg pc treo uploader cellular undertaker, mymp. Osco genovese cowboy walgreen savon. Odds thegreek gambling betonusa = diamond olympic betus. Payless guardian wallgreens script. Midi rm ma cda ram wave aac? Perl adobe mormon keeping islamic acrobat = exam. Time try microsoft presspass msn windows live. Allergy canceled simpson special fishing sporting liberty monster! Playaway unabridged simply, art attract bird mimicking pishing their. Magee treasure october sky. Auction candle half out sacred, hound = schulers crossroads. After bankruptcy target accept. Razr sprint verizon = ericsson. Sees record gift, merchants. Generic cialis, pack doctor ship. Navy citibank debit egg multiple = secret victoria providian. Printable, gluten reading planner color, database logic, cliff. Tove = overstreet hero, motion figure marvel character! ------=_NextPart_001_0007_01C73584.6CD0D8D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Japanese, korean thai punjabi, love = mandarin.=20 Potato queens sweet charm cure, magical. Volta own lg pc treo uploader = cellular=20 undertaker, mymp.
Osco genovese cowboy walgreen savon. = Odds thegreek=20 gambling betonusa diamond olympic betus.
Payless guardian wallgreens = script.
Midi rm ma cda ram wave aac? Perl adobe = mormon=20 keeping islamic acrobat exam. Time try microsoft presspass msn windows = live.
Allergy canceled simpson special = fishing sporting=20 liberty monster!
Playaway unabridged simply, art attract = bird=20 mimicking pishing their.
Magee treasure october sky. Auction = candle half out=20 sacred, hound schulers crossroads. After bankruptcy target accept. Razr = sprint=20 verizon ericsson.
Sees record gift, = merchants.
Generic cialis, pack doctor ship. Navy = citibank=20 debit egg multiple secret victoria providian.
Printable, gluten reading planner = color, database=20 logic, cliff. Tove overstreet hero, motion figure marvel=20 character!
------=_NextPart_001_0007_01C73584.6CD0D8D0-- ------=_NextPart_000_0006_01C73584.6CD0D8D0 Content-Type: image/gif; name="gary.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c7357c$0b0c70d0$00000000@XPold> R0lGODlhVAEsAYcJAAAAAIgABgKLAHx1AAAAcYMGhwCKcbLCwsLVwrHO80AYAGglAX4iAqwTAMct CeglAAY9DBZJAjtEBG40CYwxAKs6ALNAAOkxAAxpAC1dAEVcAFRkAHZTDaxgA7NmANNoBwB8ABiM AEh9AWd/AH+HDp90ALl+AOx4BgCVASWjADSWCGCnAIOrAJSlArmmDtSiAAvAACi6AEWxAGzKAHy1 AKe+ALvIANe8CArWARHfDjzkAWPmAHjXAJjWCcLeANPoDgIAMREATUEARGoAS3UAPpsIP8gENegA PwAUQxcuQUMgR1wcS3IiSKkbO8McSu4nOgQ2MyI+TD47RmEyNo40PpRMTsk1Pdo+TQBtNy1UQztj QWhWP4ddCZNhPLlWMdtTQACGPh6DM0KERFqJOnGDOJl6OLyESOiKPwyXThuZODqkOVmXNXagRJed QbyiO+ihQAC/RBW8OTvMNFazN4LJTZ67O8jDSu3ERAHZOhThMTnhRF3rTYLoOZrXScfhPtzqTQAA gioAfTUAjGEAhoQAgqYJi8MIgO4AeAAWfiERfUoZc1sqiYoidZ4XiMUce90gfABEdhdAdk1Jd2ZL hY5EiKNOfME4ee43gQBucyFugDdTc15mhY5eeqVre7NmiO1hdwdzfCaOhT2LjWGEjYB/iZt0crJ9 gN95dAufeSqffzOef2qshHmhe5mZerSigtmfiQaxiyDIhj/OjGvOf4e+d6bFdL24iNSzdQDjeSrd cTzWiFLhiYXbjqbci83fjN7tgQAAyiIAxTkAu1UAvo0AxpkGw7kAt9cAuAUWuSsttjYgv1oUwnQU sqEatsgexdMjzQA6zio+yk03s1E4tn9By5kxycZLx9UyxwBcuBVpxztVumFbwIdgt6dnzr9UxuRR wgyJzhNytD2GzGmGuXVytauEx8p5vtV9wwWXyCqhyUGXxF+SwXuSyqWUs72qtdWYugC5xhW2vjaz yle4x4HDwZSzy//6/aahpH93ifUNAAz/Cf//AAMI//EA/wD/////9SH5BABN5w0ALAAAAABUASwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnCnyn82bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq06VCaUKNKnUq1qtWrWLNCdcq1q9evYMOK HUu2rNmzaNOqXcu27VOtcOPKnevQrd27ePPq3WtXgICvftMGCMAXLyRIhXV++JA450W/AyEvlMyR csnBBQcHUIhZoObNLQ8LFC06ImlIDA+rRm1vNeuOiwsu/nBw9mx7tmNDpWwZYe+Mv0N+Bt05oWbP xEGvLF16YvPUr0dH95hboO6Fsa9L5S3AnuTvfiGH/+/uPXxk8+W5ox8vcDz59O8ffh5YHOH8zMpV Mke9v/9r163xt5pBzwUYkm0DaZeQbgp6tJR7gQX2T4R/TfhXeDZJSCFOGl5Y4YYWhhhih0V9dtNw Ow32j4o4sejWajYd9o+MN9Eoo42I3YjYjDvWCGOMqn1l2025+bSYTUWC9dh74IHXXnfcPVkeQU5W SZ54V0LpnkT3dVYfcvfZ8+Vyqkln4ED7nXmamtMVSJCbGCGIG21zItRgnQ4qJaGI42X4oYc3kbgn n4CO+CehIiZlIosu6uRioy8GyeOkPgJJqY6X9mgpTzR6NeSR/4CqGGOjJrbnqRUiiqqfiap6qKCv Hv9q1KKErVgrpIzWmlenmFY6KY6/7tjppjsNy9WnpIIqqqihJksqX6uyGmifg/bpZ4eoYmghiYQO KhSKNpkYrq7jjitupL7++COPQfZqrGs5rnvskEjORuSzzDabb2McpsrvUpD+K7Ba+xYGUnB0HTRm wgxDdCdNA0cs8cQUk9XwxRhnLFNa3lacIrkeC2VsyPcODBzCVMY3JV31hUnQcMktPFKaB63JsHZy 1sZgdduhfJ7Gw4mZHGebeZlfSTQTOB1d1e2ss510dsQUiBD+qS22VneM17ktgtx1ubaqBSy7wsab KdmS8kVvTvsW3GxYGGEppdxWriz3yjO5jBzR9B3/p1+ZBa1ps+ACQpVzglETxDPiU91Nt5Zza8me k1C5LPPemF8e0oDSlUm4mZ8bfhvjT+Npep5JVW3o6qt7y21h4gac06O3el2WumUHezamI+dFr9tv By98YatuSDWgsEoLu2Zhz65ro7myxWvuvFNvdu94IVtq8Mo+q6RFUT4OX5ZPUu7zSkEL3aVyX+p9 0nMADj5g6DPxnBud1+X8sEYk7yV7/wAcCvD0ojH0Ha2ACDydVALIwAY6MDEJjKAEJ0hBqmiugnLZ 30we5C+hgIhk0GMeT0R4ItuhBVjYAyCz1oaT+9VrgH3pIFG0JjEURc9RXiOh9HL3wBZqb3il6h7c /8CnMvbYDXKTWw96aOI+oRlkTE18H2vk15z4AY5zMDkc6UrntI9wsF+sSl62dEJDt3ANbM4ToYr+ d0JJvctswdIUsezCwnoZCV/2aky13HOtWE2rX9riC9f+Fz2Y2QV3QGqX9XDiGr2wcIDLctYQK2KZ 3xjxbnijXOX8djmjveyAKeGc/Nh0JlLKRE4aNF0XUYeUPSqveKmKVhntQiscgi2EhumRu+DYq7M5 0l5tw6MP7fg9Sl5yiZnMEuTOg8yYpA9mmFPf0S6ItP9MUZTziw6AsohK+0VNQVrkSA/XwsZx9iSF iYFhXjAoHFBiEItYSSU750nPetrznvjMZ1bOh/8VauozcEtbiTxh0hQ+0vCDIQuh7Axpq3LejodB QScj5diWfAHvd0kylQx7Mssa1rJ5IyTMDXc4R65I1CxJyuP2LOq9vXQMa2HMmkcXasLmjXSH08OR G8umU4hWVKXEXKn31JmUJRmkN+LjJxP99km+gcmdKKniNUlpM6WVkiVa3F9WEyc1PckQa8jz0Eb/ NciagvSmJE2kIi3VS7XCkY5AdZsQg6pRMhbKeLHsqCDVaNaz1u6QO80JCt+6O4qyZW1ylSRd6wpG MfpLr/5jXsBo9zWQrmWwbF3ksDCbPZWuULFzFcvJzNOkpDbTgutbX9/w48/NTTVANKPiNT0XUJT/ LE5/3xydAllpzrE4tLcNJOpd/lmR1hKXJgM9rnKXe1zgOve50DUKcyNi3LjAKWHJJahXlRddy56x hLT77VgaSaminBQo5yXKZwvmQhfy63XRteFfnVcutKaFs+Y17F2KFNqdsFRg1tpW1vLKLci25buW vaVI55tWHaUNdzvtqVrRNtgHp+0ndVzsMDcs2ripLHJSSln5PrxUKILSk55kSZpWPFUWo6nFLg7d KBmyVa7KhqvZbUklkxjiLYW4KpZzZ4rTR6YrwjiboLMmkpNsoFHCyyHhfBg4bczbo1greayL1sBi V1O0ijcsb8ysYBdZ0unpbpflVS9QgVgyDnfY/5ggnlLdjqjUl8zHxJnLT3U9UiAXNxnGL2Yyk2Vc uKti5zZdzB+Oqbwb8o3viCNeZp0NyMlnso+pTFVxm16LTTPBtnOv/bOoYws4GuNW0Vu0DqO72t2v fLnVAxMurHv76lnzS9bDna6ud00SW/v61w7kNUP2DJfrYnfVEONgIOMLsnKGV4di0+X19Buy//Kk jrhWi4F7CC5od812tfaKmduqQoy2tM2RPHdXjFqQY/oYPlnRm+bwHBpr/vk0/gF1qV+yVVOrOscq OSaIMfljIGfaicY5ILE5IlVRd86q9HNJvxXiNIBHhCvHa92AJ1ZWn+Cqrw+tVC83C6Pq/fKzd/+8 V4br6tgsj7Ux53J2s0FOlnG/1cxnJux+PatuDbNZj3cNq8spFnNy4bKEuRT5zaUtZnLDNZIbTuy/ +NjHmHZr27QsOmXN9TyaPzSw7EpzI03eWZ5DXV9x7blThL2QhbOdJBZfCbCZEu657yXbds+73vfO 9777/e+AD7yv3074whv+8IhPvOIXX2XBO/7xkI+85NXC+MobfvKYz7xPLM/5znv+8+zUvOhHT/rS m/70qE+96lfP+ta7/vWwjz3oZ0/72tv+9rjPve53z/ve+/73wA++8Ifvxdgb//jIT77ylx94mvCD Hyp5fkGkLxHqE/9iS3m+TbT/D+7/5Png7z7/P3Li/Z5w//zjB0r5xc/+9mt//etn/gMvQv36Q38h 1hdI/h9if/3fH///53/20H8DGIAEsX/Xh08EaH8IuH/g138PaIAFKIATWIAMCH0XiIH3B4Eb+ID+ h4AJiEERCH4U2IAkWIHSl4IdaBAjuIAauIIuOIICyIEUGILz1IId6IEIoYIzqIE1OBA4WII+2INC KIMTyIE6aINYwRQ4uH3p933jh37sJ4Xk14JOeIXe937ph34jiIVbGIVPKH98R4XuF4ZVWIZT+IU7 QYZSmIVgeIVw6IZoSIZiOHd0+IA6EYFx+IZ6uIZqeBN42H5lGH57CIhfSIiBWIf9kxUgqIS0/zcx 8aeIkjiJlIgXjniJL8GEkcgT8UeIibGJldhb9CeBADh9pDgRjWgRqQgSq4iJ4qQUoMiJZhiLREGL R2GLXoGLoegVo3iBQHiCDkiCOpiESfiLvsiCwJiMypiDBhiBxgiDQ9iKrsg/sPiEbaiG8GeNVKiF cGiI3iiIhYiI2DiOZjiH45iG3biLEuOGeNiF2fiN4teOfQiPdGiO36iF8uiHXuiFXQiO6jgwcogT 7yiQ2giP6XiGhUiQ+xiOs1iO9piG/aiL/9gUo/iLRHiEzfh/1keDFWiRQmiKF4mC0TiEIImRH9mR 02gS2ReGiRiIAwmOLemJBHmIDumSLGmT9f+YkDHZjRI5kUuRkkAZlEI5lERZlEb5iD6ZlGlxlEzZ lE75lFC5QUo5lVRZlVZ5lX0XlVqZEFjZlV75lXaxlWJZEGBZlmZ5ll8xlmppD2jZlm75lnAZl3I5 l0CxlmNJl3iZl11pl3zZl02pl2fpl4I5mIRZmL+3FARAADaRmIupmEGRmJDJFYypFJPZmJUJmY75 D5GpmZkJmLxoEYkpEKFpD6O5EKXJEacpEZA5EKMZmq1JAKQJm64Jm4Y5E68pmrSJmQaRmrGJm7H5 msAZnLhZmrp5EMSZm7KJnL1ZnLW5EUyBmZjZmNKJE5V5E5PJmJtJnYp5nduZmdzJmdOZE5f/6ZjY SZ7m2Z2eOUkVAZ2r+ZvtyZrJOZu+eZrQ2ZvLSZvuOZvMSRDHOZ/KyZ/x2ZwxwZ63iRD9eZv9eZ/+ CZ8FwZsNip8I+p/wKZ8CahFN8Z3TWZ0Zip7gOZ7S+Z0e2qHmuRMhWp7hKaLgmZ57gaGW2ZnauZnQ maItyqHceZ7emZ0veqPjqaE1qqJcUaFE6aNCOqREWqR4qaGIiaQkyqFOoaRGihROOhTRSRQmGqVA EaXZaaI56qKPyaU8YaWBCZr4OREF6hD0OaYR4aDDyaCpWaZmiqYJoaZamaQ1aqNcWp1aWqcf2p15 eqcwiqN7Gqjauad6OqMpqqdTOqVPWqI0/+qieNqo4omeWnqojjqiTtqnMrqhnDmiKNqpkyqjYLqX YsqgCmqfpLqg9lmf8nmmvBmhBpqcqDqhZeqqpUqhvrmmW5mk1mmpnLqrgwqivNqpLaoTwLqkMfqp mQqqweqpTJqsgEqkjEqpxMqpxYqiyKqk1RqpvnqtleqrzCqtjzqtT7qrNmqoxtqZMbqpVXqe3jqt LDqogcqj3UquOlqn5bqp6jquQhGqyfqcXqqve8ev+Nqk/wqwJgOkCJuwn2ewPqmwQMmwE+mwEjux FFuxFnuxEAGx/4ixNqixHvuxesexIjuyJFuyGQGyKJuysGaywqeyLvuyMBuzm8eywCezzP9HszVr szq7swKDsz77s0BrsTyLfBphhCdoikdrgcp4gCCYtBaotDLYgkgrtUHLigz4tAeRtEu7jDsYjC/Y tcxojFVbFyt5k/Eoi9potuGXiHmYjWDokGfrhGk7tELRi2B7t1iLjM6YEE4rjI14tIArjWPLltUI tzI5k3KLtofbtg35tmhriHNLt2SxuInrh4eouHA7k02Ig/hYuXJrhZLLFZQbt4zruVXItpZ7uqR7 uqg7uqHrFKMbu1yIubF4uGu7ibfbuK87sxXhtGKbtVcLvC94inn7gcXLtDmIvIPLEJqotrjLjgop js+ru7JLk5C7u2KBk6uLuJ+buJ6IuqbXe7bVC7mXi707UbR7G4RQi7xL+4x6i7RQ64xa67fqu7z2 m5Kcm7/6u7/827/++7/Ee78CPMAEXMAJaL4InMBrZ8AM3MAO3HsKHMESXBQPXHkTfMEYzBMVzHgZ 3MEdvMGL58GaB8KKJ8ImfMIonJUkvMINnMIuHLosHMMyPMP/9MKPR8NvZ8OOh8M83MM+nDE6LHg/ rGtB3HxDfMQiW8RK7LJI3MRO/MRQHMVSPMVUXMVWPBBL7HdXTE9ZrMJbjEFdHMZiPMZkfLNffMZo XMVlvMZs3MZKERAAOw== ------=_NextPart_000_0006_01C73584.6CD0D8D0-- From Canada@ensuing.net Thu Jan 11 09:38:49 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H514r-0001eR-3V for mpls-archive@lists.ietf.org; Thu, 11 Jan 2007 09:38:49 -0500 Received: from [195.60.191.226] (helo=host226-191-60-195.convergenze.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H514m-0000Us-Ih for mpls-archive@lists.ietf.org; Thu, 11 Jan 2007 09:38:49 -0500 Received: from DRMKG (unknown [124.171.126.138]) by ensuing.net with ESMTP id 1A68E636B4D3 for ; Thu, 11 Jan 2007 15:53:50 +0100 (GMT) Message-ID: <001001c73590$43a46b00$00000000@CAD> From: "Racing" To: mpls-archive@lists.ietf.org Subject: Homer TLC Inc Date: Thu, 11 Jan 2007 15:53:32 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C73598.A568D300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 ------=_NextPart_000_000C_01C73598.A568D300 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C73598.A568D300" ------=_NextPart_001_000D_01C73598.A568D300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As chairman chief executive officer. Homer, tlc inc rights reserved use = this! Succeeded frank blake board directors bob that they! Young readers, exchange buy photos books shop essentials under. Mexico continued design moving racing team foundation. On, worldwide = formats, photo. Associated essential global ap peoples right values principles. You have ever used at any time to. Get updates info privacy amp security = business customers. By email, current price date, jan pm et? Ahmed hadi naji found shot death iraq! Business customers, contractor government businesses other? Notice of plus, license your is hereby terminated if. National football = leaguer nflr? Bob, that they mutually agreed would back, top. Succeeded = frank blake board directors bob. Acquire chain quick links annual proxy statement! Webpage purchase, faqs printed material did, know. Did, know worlds leading employer olympic, paralympic. Photo video audio rss podcast industry function, featured products. In = violation applicable laws. About us, companies corporate report stock governance. Plus license your = is hereby terminated. Know worlds leading employer, olympic paralympic. ------=_NextPart_001_000D_01C73598.A568D300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
As chairman chief executive officer. = Homer, tlc inc=20 rights reserved use this!
Succeeded frank blake board directors = bob that they!
Young readers, exchange buy photos = books shop=20 essentials under.
Mexico continued design moving racing = team=20 foundation. On, worldwide formats, photo.
Associated essential global ap peoples = right values principles.
You have ever used at any time to. Get = updates info=20 privacy amp security business customers.
By email, current price date, jan pm = et?
Ahmed hadi naji found shot death = iraq!
Business customers, contractor = government=20 businesses other?
Notice of plus, license your is hereby = terminated=20 if. National football leaguer nflr? Bob, that they mutually agreed would = back,=20 top. Succeeded frank blake board directors bob.
Acquire chain quick links annual proxy = statement!
Webpage purchase, faqs printed material = did, know.
Did, know worlds leading employer = olympic, paralympic.
Photo video audio rss podcast industry = function,=20 featured products. In violation applicable laws.
About us, companies corporate report = stock=20 governance. Plus license your is hereby terminated.
Know worlds leading employer, olympic=20 paralympic.
------=_NextPart_001_000D_01C73598.A568D300-- ------=_NextPart_000_000C_01C73598.A568D300 Content-Type: image/gif; name="Design Moving.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c73590$43a46b00$00000000@CAD> R0lGODlhoAE0AYfrAA0EAIoAAAB0AHWDAQgAe4gAhQeHdLrFvMTTy6LO/EQiA2wdAHckBpYjAL8u ANwTAAs7ABQ9DT81ClVAB4w7A6NBCcs8ANhCAABdCSBbAE1UAFlZAItWC6VZDL1fANppAAt7BRly AE6HAFSBAHNxAKKNB82NAeN2CwCpChmnADGhAmScAH6pBp+oAMeqANufBQC3ACm0DDPICGi6DIXE AJ68DbW0C9+xBwztByXSCjnsC1jjAIfeCavXAL7XBdzmCwwGTCAAQkAAQ2UARX0APKIEQ84GOOUA RwImNi0iO0QoQ10bRX0XPJkrPsQrQesmRQA1PRgxR0o8OmdCTX1IQqpHScZDR9s3TABkNR1mODhT O2trMo5rDqxZTMxSNdVSPwCGMiuDRzGHOFuLOnd8R5qNTs2CRdKOSgKbRhOsPUWsQFOUQHOXOaWU OLSmPuSRRgvFMS64N0jKR2nFTIzMTZXJMruySdnOSQDlPSbtSkreQl/URnrVNa3iRsXdPdzcSgoK iiIOgEAAd2MBf3YAi5sAjMwNduIAfAAUiiAnjDsic2oghX0ahpsWhL8Vi9IocQ5FjRdGckFFcmQ/ c3tOeaNFhMo9gOxMeQBSeytlgTZthGVag3lUhaJthbNSh+FejgeLdB53gEl/jGeAi36OhJdxi8uK jNODdwCWfByfiTeedlyYjHOXhpudeMKajtOkiQK+di62eD/JhGe5cXfAh6TFc82+duy2gwDmeB3Y jEXeiGLfhnjnca7lhMvthuXZigcAwBYAwD0AvFEAvnoAtaEIyMcAyuQAwgAnwRQoyE0XymMSyoMn zJwjwsMiuNsevANCwxQ4y0ZHw2JIwnlEyqEztLlDsddIwwBgyRVYtEtstmRgxX1YvqhmurpbuOBR wAFxxhaNvT2FuGGJvIJyxq12yr6DyN+MvQKosx6lsT+fs1KfyXyqyaOasrmjwtaWzQC1thW7tk6/ w1y3y4a2tqS7zf/y/aaaqIx0efMDDgD4AP/4AAkK8PUB+AD///vx/yH5BAD//7kALAAAAACgATQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKBn+W8mypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNqBZqyq9evYMOK HUt24dazaNOqXcvWatm3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDJ6MKEHB0cdQAAdpShQRJ 8r8PHyxr3llx8UDPC0FzFF0SckHIARSaFog6NVjKAmHDjigbEkPKuG3by627I+aCmD8cDB7cHvHf iEH6dLyS+UznRKEzbR35H2SaqFdet159cuV/lH2G/785nmV5pMdXYra5fv3m988ZN2fMvP5ix/fl 52e5/19///0F+N9/OLXG0nYyGegSglONF56DuK2Um3kTPjihS+eB9x16wbHkHk3ufQjfiC3ldx+A 86GI4okq4idfiivqR5+MLc4IY4HZaafggpExyB1WF1rYEoQaSliZkEUOeaGGGQpFnIdPyhRilCSO 6Jx99qV4JY3QZekll2ASeJOC2/nI3Y5mNhhhkecR6eaR32XYJIVHRTllTCJCWSVVnQnwmZ/25CcQ aJ6JRqifpB0aKKCFMoqoo4te1Jo9q612kKWWhpVbbLbNxumns9W2m26efopQqRsRZ5xwqyKEHHCs Jv/n0XIvbskfmLdq+WKNvH6p6405GVhmdT4Oe1Z5SBqp7JtJyrnhS3MG9eSdl2WmnrXXZrvne7YC a6KK822JZa0CZlmjdDZRd2COP7Y07I5VIRvnmkvyxua8GNprr1HpXfvhv9j6G/C2T3lEmqyZyqrw qwo3XNDBySXs8GEMT2zxxRhnrHFXBHfs8ccgb2YSxIJJnByqgVW88V/3MXQwyXplOqlB1Lk2M0qh 9laQqIIxrKqryB0X68ootRwaoIVRR6nNriFkWqVNm5TzqTqnrGrQQw+kskBbE60SreeWa67Yu24F 77oJEqu2VEQyiS+SFu6LFpUt5VktngOHjJRFjQ7/+mikivYNOKRw3TyQyYc3bfhJm+7c6eOjggo5 ymL9TNDWx8Hq9UQ/ufir5zECuJ+5aMGbJto6ps72mm7Dee+yrkd7Fd12awuw3k31aeLgvPP+MuFx zYx44sQv3VXjU4ua/ORVl/Vz161GL/3mJRn6d9+B/907zGJNKjGmUUPtlafLR14+z3FdnXX0WHO9 PvUiWe/7o0YfqmikhQuvtPGsRb308CMpFW/MR6pNKa95lXte5qRnOejB74EeASAE0/e+CVrwLRK8 IFkcqMGN4O6DIAyhCEdIwhKa8IQoZMvpUjii2rGQTxThXkIE9xeZoSYhNyRIBkVSPsT4rDgGEZr7 /zioQbD1BF3vUZexXmImdnlHWSBMD7XwdrcqvpAnfXpY/SDVqC46SoZfWVz/aOa//5URZwWM3KjI Z0DccIpyXrHc5SrIPlYRsYMSSRQX94i/RSHtT8HLoQ7PuL+nnRGNUyMIz2rTPDimRI7uU8irIInH jOhRUH7ko98IsrtA2tBpTDPjDkOCvAK6sYdvdOQjgRjJhEzSjnTsoBGBFS5c3Yh0pcvRCpeoOqsE yXWvC2aznoUVO+XNJbez4hV1kkVA9lF+8ttkH/NnSDKOkX/X1FRvFgk5Ag4kkRssjspeOcdWVrIg tGIRgbp1oi6JKSvqOpMuu3O2FUJFXkaiV4WeJf+32RnTmHqqW4eWicVzquaQGVMlBQ0aEoICxZ4j XNJmXOhQpzD0ohjNqEY3ytHAQAWJJIJoRfOlFYqOtC3fAino9sSgs+mITE5UExRtIjuSZiVPFP3n QE+6FJDCxKdJFNba0tYukSqlbUap6VP6tVNkWgunx+RpdMoWtl+JjqprcWm7YLJEox6Vdb/UZz7n hdSq0E2ZAtWWWqWKFHRJx3Mr3YxL7Ykgra6OTsEUUrSSZdamolWgUGVrTZrJyS9ij358MRwAwZfN r7CxjZJT4zchm8AfAs2cd7zgLHPlK3HBB6bYoedQ4yVWJcEuSVDkq1Wo5MIpmlSwQXmrjULnzs// ZqeJonXXaGWaV2DqlZ9vI2Zfk2m7pxoXtkxJqYzaaaN3qhCmoO3lS7vzxGG2DW76jJBSm9KvahGX tVFFrnjTRd3xpuW15k2vUbyq3qigt73wja98x9vR+tr3voQZpV8U2pfM4tdgwLuYDRF3MzEiEpwQ 4e9tEGiRH2Iuc0LcqBGBijsl7lZ11+Elb1VLHuHedFrHldLA3stWvhktk347MSbvNxcDfy+U4nNs GgeYylSa8sY15s3y3FjjhlByeporJ0eBgkTQybaWkplreTHcowtHhVm9HSZq3xTc10F5u94dsUkD O18i70q5MPoWLbPqxNN11a5O2ReVtVvlsSbr/7dR1vFNzvrXtda5yzkRkFWNTC65zpOoW5XuXU0r zNQCE7UzhTN2EY2Ts7ZWy3hupuAmrT37/ZEu3itjjD/5mqr1kJuSReUBvUlqBQ9ROO1jYNb8W8Qj 0uiqsx1XrLFqNuj+ebrrWvKg8Qqh65J1rImOnbANjeUsYwu8AU32fOur3/9mhNXORmeX2YtnfoW3 2jmJtra3HRdse/vb4LYMtUlUbPiQONxTZZEJi6Vr1Mlz3EXBJ4e3xWWYOPrayCVsxgo5PEEOstOT JfVgFsjKIL8ylnjcLJJhLS5aq6We7RZ0oHlrZTb3mqwS9We9RSwwdNtEz7Sdba40A/GZ4PYq8v8+ NOvoBOcPb9zexz23x/kc8lo6PC2mi/jE4Z3UDbUc0foadkmbuuVjd9fjNKE5XGdt27rqnN1A8rnQ p1zleQ/X6Bx/iczRrfTmMj2oTtet2N3tS6kLE58VZ7TGsR7QRy87hphE8fxSDMay7M+MxcN7YzvN 45x108beNPVIFrgqcha+4NB+4LR1jnSibN3jHW02tyuS+Mlb/vKYH0njN8/5znv+86APvehPmvnS m/70qE+96lfP+ta7/vWwj73sZ0/72idm9LjPvU1sz3tu6/73wHdJ74fv7OAb//jIT77yl8/89hL/ +fZtvvSnT/3qpxD62M++9rfP/e57nyDWD7//+MdP/vd8//yKL7/6BYv+9nttK/zgx1Ti7xL678T+ 67e+/fcv/5rE////gH8rIYAxwX8D2H80QYD0Z4ABKH8KiID593kVEX8CQYH2YIEKgYEVyA8TYYEe yIEMoYEXyIEfuIEIIYLuR3slOIIbiIIi+H8lCIMgSBAr+IE2SIIgKIMsuIMUeIM5+H8pOHsyCIQ8 OIMDAYMmyII9+IMGMYQ1iINM+IRDaIIxyIRBCHtO+INIeII4SIVduIM06IRJuIRH+IU+SIRkqIQ6 eIX49RNZeIA2sYD9J4cNCIf154R2SIdwyIBvWIcGSIARyHwMWIeECBN6SIeD2BKD+IcIeIiN/ziH j0iIjhiIggiJigiAd4iJjNiAmPgSiQiDdiiJoJiHkciJ/AeIlJiKcQiBqtiKIYSKrhiLg8WGtFiL toh9bgiLhsiKnMgWuiiLEkgRKLgQL2iEFjGMF4GMIaGMt3hOzHgQxagRz9iBxkgS09iMGrSFWziC K1iGS3iD3liN2kiEBTGOPtiCWmiMa8iNUWiG1YiNBoWBVeiF5TiDaNiOSViG+giGYwiF/ViE3NiE +KiGBMmP8IgxPoF/Q2iKesgSCvmIoLiQl+iQljiRfliKchiRvCiKHNmHvwiM5vWQdziSFlmIDygT IlmIpGiSlniSntiSMCmRHwmS4pWSk+iSLP+5hxVJkTypkh2JkQ4Ik7uokyvpkzTZZQI4iqYYiqGY lJ2olJcIiag4ik6piVY5lKJok6V4lFzZlV75lWAZlmI5lmRZfQd5lmiZlmq5lmzZlm75lnC5MmU5 l3RZl3Z5l3iZlzQZl3zZl375l4AZmII5mISZgnp5mEpRmIpZEYjZmEaxmJAZmZI5K45ZmZZ5mW4x mZq5mZzZEJj5mczUmaI5mqRZmpLpEwRAACuRmqupmjaRmrBJFKz5E7PZmrUJm675D7Gpm7kJmiVU EakpEMFpD8O5EMXJEccpEbA5EMMZnM1JAMQJnc4Jnab5QM8pnNSJmwaRnNGJndH5nOAZntj/WZza eRDkmZ3SiZ7dWZ7VaZ24uZzdGZ/MSZ0EcZ3wWZ/p6Z3nqZ/quZ30aZ/9uZzc2Z6AQZvvOZsH6hKs iZu82ZoNyhLv+aALmpsJmqAvcZuuOaEO2hIT2pu+CVsHiqAeyqEUqpoi+qASaqIZqqIQ6qG1GRMY 6qAnSqIa+qHiNaMpeqErmqMx2qAn2qM1+qItOqQ+uqNDWqM2CqJGapsjyqQrGpsvGqEzupsMyqQw UaW8iaFCKqJNmqQgQ6CR6aViyhJgWqZmeqYdMaDAqaYFMZ3ISZ9oChao2aU4gaU3oaFCmhN52qIl iqJOuhN7eqV0OqZMsaYWcZ0PcZxsyhBs/3qfboqf3gkRiwqpcUqZPFGlmGqnGyqjRpqpRRqkI5qp eQqqfsqjVLqbWUqqqbqqrEqoiUkR+7me/TmfkIqotOqmsZqcAIoQj/qotCqrAZqfssqflCqfleoV uSqsugqnvYqeApqfinqfv+qrbaqswjqf8Jms8dmsxnqecHqsnNMTQMqipRql5EqqeNqbmmqqgiql 5Eqk8PqjOyqvJKqggeqqQ2Gokcqt1bqv6rmr1Gqs03qtxYqr37qsA7ut1tqt3yqw4PoQBvqkEtul dhqhqcqiXAqv9oqj9cqp5eqi6oqqFjuyp6qi94qvQhESkxqpG7GyD2tBSnGyNCqbg4qyNv97s/n2 sn2Js6CpszvLs5jps3wJtEErtHBJtEibtF1ptEertE77tKrItFI7tawHtYdJtWxptVq7teKHtWvJ tXfptWI7ttoGtnZJtmibtkNmtmzbtsCntnAbt5XktmIqk1MJlXYLgZ0YlZnIkDLot6yYhTNJtx9j lUG5kb1IkVKZuFDJt3y7t46rlJBLuCa0txlZgA+pt4e7lJgbuJe7ixCpuJRbJROIjORYj1rIhesI jcXoj6xrj/J4jXLbF6cbhu8YkLgrkNuouqibu73bgt44u8lRu8H7usD7utMouN8ohvdohMorvGOR kLA4uQe4uKBLvY4rutiLh9k7uiW0vdP/e4qd27h9+7jhu7nd670jBL6Ia7idy7mg27fsW73pq74i ZLno+5Khy5OG274PmL/lK7mDa78eQ5Wfq7+Ku7hPSb2QC4DzW73WS8Df+7eAK5VV6b4JjMDm+4b4 m5HcK8FnAb1sKL3KW8ImfMIonMIq3Icg3MIu/MLMJ8IyPMM0XMM2fMM4jBcwvMM8zEI5/MNAbBc9 PMREXMRGfMTTF8RKvMRM3MROLJdIHMVSrBlPXMVWfMVoOcXlh8W2p8Ve/MVawcW1B8bhJ8a0R8bW Z8azh8Zs3MZLocZwHMcH4cbSJ8evR8d4nMd6vMd8XKh2/Mdq3MfHB8hVK8iGfMiEvHqHNbzIjNzI jkzGiRzJVfzIlIzGkox6lZzJmrzJOXvJnvzJoBzKOsvJnSfKpnzKqJzKmknKnBcQADs= ------=_NextPart_000_000C_01C73598.A568D300-- From mpls-bounces@lists.ietf.org Thu Jan 11 10:44:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H524J-00017R-D3; Thu, 11 Jan 2007 10:42:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H524H-00016a-51 for mpls@ietf.org; Thu, 11 Jan 2007 10:42:17 -0500 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5236-0007Xe-5c for mpls@ietf.org; Thu, 11 Jan 2007 10:41:20 -0500 Received: from wdhcp-158-86.verkstad.net ([192.36.158.86]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1H5233-0001qV-Rx; Thu, 11 Jan 2007 16:41:03 +0100 Message-ID: <45A65A89.5080303@pi.se> Date: Thu, 11 Jan 2007 16:40:57 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mpls@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Bob Thomas , "Thomas D. Nadeau" Subject: [mpls] new mpls working group documents 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: , Errors-To: mpls-bounces@lists.ietf.org All, we have a good support for making the following three IDs working group documents: draft-nadeau-mpls-interas-lspping-02.txt draft-nadeau-rfc4379-bis-link-bundle-00.txt draft-thomas-mpls-ldp-typed-wildcard-00 Could the authors/editors please publish them as wg group drafts with the following names. draft-ietf-mpls-lspping-link-bundle-ext-00.txt draft-ietf-mpls-lspping-interas-ext-00.txt draft-ietf-mpls-ldp-typed-wildcard-00.txt /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 888momo444@docomo.ne.jp Fri Jan 12 06:47:44 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ksq-0005fd-4e for mpls-archive@lists.ietf.org; Fri, 12 Jan 2007 06:47:44 -0500 Received: from [220.194.46.217] (helo=kimu01.alpha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Ksk-0004G0-4v for mpls-archive@lists.ietf.org; Fri, 12 Jan 2007 06:47:44 -0500 Subject: =?ISO-2022-JP?B?g4GBW4OLkniCrYLIgsGCxIK3gt2C3IK5gvGBQoFCkJCK84LFgreBQg==?= From: SNSij^c To: mpls-archive@lists.ietf.org Message-ID: 20070112201907 Content-Type: text/plain; charset="SHIFT_JIS" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Fri, 12 Jan 2007 20:19:08 +0900 (JST) X-Spam-Score: 1.6 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ͂߂܂āBƂ܂('-') sɏZł܂B35˂ŕΓXI[i[Ă܂B [̂1ɓď₵ȂācyjjɉĂ݂܂񂩁H ꏊ𕷂ĂȂ̕Ǝ炩ȂƎv܂Asߍxł ̏TɎƉĂ܂񂩁HVhr܂肾ƊłB http://zum.versus.jp/mizuki/ ǂĂ̏Љɉ`̂ŁAx[炦܂񂩁H AmixiƂł͂ĂЉ^ɂȂĂłB̔Nw30݂ł('-') [AhX͐V‚Ă̎Ă炦܂񂩁HH FBЉẴT[NɓĂ܂AVAh܂B From Mizuki From mpls-bounces@lists.ietf.org Fri Jan 12 15:30:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5T01-0007A4-Hg; Fri, 12 Jan 2007 15:27:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bl5-0003me-8C for mpls@lists.ietf.org; Thu, 04 Jan 2007 18:12:27 -0500 Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2bl2-00021j-TN for mpls@lists.ietf.org; Thu, 04 Jan 2007 18:12:27 -0500 Received: from [129.25.14.14] (n1-14-14.dhcp.drexel.edu [129.25.14.14]) (authenticated bits=0) by coe.drexel.edu (8.13.6/8.13.4) with ESMTP id l04NBo2L026524; Thu, 4 Jan 2007 18:11:50 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14CB93E4-53D7-4D14-B7E6-608F534A9844@ece.drexel.edu> Content-Transfer-Encoding: 7bit From: Jaudelice Cavalcante de Oliveira Date: Thu, 4 Jan 2007 18:11:54 -0500 To: Dimitri.Papadimitriou@alcatel-lucent.be X-Mailer: Apple Mail (2.752.2) X-Spam-Score: (-1.414) ALL_TRUSTED,AWL X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d X-Mailman-Approved-At: Fri, 12 Jan 2007 15:27:35 -0500 Cc: mpls@lists.ietf.org, JP Vasseur , ccamp@ops.ietf.org, Jaudelice Cavalcante de Oliveira , Ross Callon , owner-ccamp@ops.ietf.org Subject: [mpls] Re: CCAMP Last call on draft-deoliveira-diff-te-preemption-06.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: , Errors-To: mpls-bounces@lists.ietf.org Hi Dimitri, Thank you for your comment. On Dec 18, 2006, at 3:47 AM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > adrian - > > in HBlock case the average wasted bw is a factor 10 smaller than > for any > other scheme (without significantly lowering the worst case, still an > order of 10) Indeed. This can be seen in table 2. In this case, selection of LSPs much larger than the required bandwidth did not occur often. The worst case value does not reflect the frequency with which a high bandwidth LSP was selected (which was very rarely in this case, therefore the low "wasted" bandwidth). > the only noticeable difference with PN is exactly that one (which is > induced by the possibility left to Hblock to have two selection > depending > on heavy vs normal loaded link) - hence it would be interesting to > know > the dependency on the min/max LSP bw and distribution (scenario > dependancy) and have a similar PN approach (non-uniform selection) Note that PN has the objective of preempting a small number of LSPs of the lowest priority (therefore ordering by decreasing bandwidth), while HBlock aims at minimizing the blocking probability, therefore selecting smaller LSPs which will be more likely to be rerouted once preempted. This is the main difference between the two policies: Given a set of LSPs with the same priority, PN picks the largest (in the interest of picking few) and HBlock picks smaller ones (even if more than one, in the interest of being able to reroute them easily). I hope this helps, Thanks, Jaudelice. > > thanks, > - d. > > > > > > > "Adrian Farrel" > Sent by: owner-ccamp@ops.ietf.org > 14/12/2006 18:02 > Please respond to "Adrian Farrel" > > To: > cc: , "Ross Callon" > , "Brungard, Deborah A, ALABS" > , > > Subject: Re: CCAMP Last call on > draft-deoliveira-diff-te-preemption-06.txt > > > Hi, > > I have been explicitly asked to lengthen this last call so as to allow > time > for a review. > > Unusual, but not unreasonable. > > The last call is extended to noon on Sunday 17th December. > > Thanks, > Adrian > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: ; "Ross Callon" ; > "Brungard, Deborah A, ALABS" ; > > Sent: Wednesday, November 29, 2006 11:06 AM > Subject: CCAMP Last call on draft-deoliveira-diff-te-preemption-06.txt > > >> Hi, >> >> This draft has been developed independently and has recently been > brought >> to the IESG for advancement as an individual submission to become an >> Informational RFC. I have done a first-level review and this latest >> revision includes updates to reflect my comments. >> >> Since the material here concerns preemption and the suggested ways to >> operate an MPLS-TE or GMPLS network, we are running a quick last >> call on > >> the CCAMP mailing list to ensure that no-one has any objections. >> >> Please send your comments to the CCAMP list no later than noon GMT on > 13th >> December 2006. >> >> Thanks, >> Adrian >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, November 28, 2006 8:50 PM >> Subject: I-D ACTION:draft-deoliveira-diff-te-preemption-06.txt >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : LSP Preemption Policies for MPLS Traffic Engineering >>> Author(s) : J. de Oliveira, et al. >>> Filename : draft-deoliveira-diff-te-preemption-06.txt >>> Pages : 19 >>> Date : 2006-11-28 >>> >>> When the establishment of a higher priority (Traffic Engineering >>> Label Switched Path) TE LSP requires the preemption of a set of >>> lower >>> priority TE LSPs, a node has to make a local decision to select >>> which >>> >>> TE LSPs will be preempted. The preempted LSPs are then >>> rerouted by >>> their respective Head-end Label Switch Router (LSR). This >>> document >>> presents a flexible policy that can be used to achieve different >>> objectives: preempt the lowest priority LSPs; preempt the minimum >>> number of LSPs; preempt the set of TE LSPs that provide the >>> closest >>> amount of bandwidth to the required bandwidth for the >>> preempting TE >>> LSPs (to minimize bandwidth wastage); preempt the LSPs that >>> will have >>> the maximum chance to get rerouted. Simulation results are >>> given and >>> a comparison among several different policies, with respect to >>> preemption cascading, number of preempted LSPs, priority, wasted >>> bandwidth and blocking probability is also included. >>> >>> A URL for this Internet-Draft is: >>> > http://www.ietf.org/internet-drafts/draft-deoliveira-diff-te- > preemption-06.txt > >> >> >> >> >> >> > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 12 16:33:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5U0P-0000Cz-Nb; Fri, 12 Jan 2007 16:32:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5U0O-0000Cq-Bw for mpls@lists.ietf.org; Fri, 12 Jan 2007 16:32:08 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5U0M-0006Yl-PL for mpls@lists.ietf.org; Fri, 12 Jan 2007 16:32:08 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0CLVicj011829; Fri, 12 Jan 2007 22:31:44 +0100 In-Reply-To: <14CB93E4-53D7-4D14-B7E6-608F534A9844@ece.drexel.edu> To: Jaudelice Cavalcante de Oliveira Subject: Re: [mpls] Re: CCAMP Last call on draft-deoliveira-diff-te-preemption-06.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Fri, 12 Jan 2007 22:31:37 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/12/2007 22:31:37, Serialize complete at 01/12/2007 22:31:37 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: mpls@lists.ietf.org, JP Vasseur , ccamp@ops.ietf.org, Ross Callon , Jaudelice Cavalcante de Oliveira , owner-ccamp@ops.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: , Errors-To: mpls-bounces@lists.ietf.org hi - thanks for the reply - not sure you ever got the following response back ----- Forwarded by Dimitri PAPADIMITRIOU/BE/ALCATEL on 12/01/2007 22:30 ----- Dimitri PAPADIMITRIOU 07/01/2007 11:43 To: Jaudelice Cavalcante de Oliveira Hi thanks for the answer - i am still looking at the reason why the PN selection process is driven by a uniform policy which looks like an arbitrary choice HBlock aims at minimizing the blocking probability PN aims at minimizing the system perturbation to have a fair analysis policy should be applied uniformly and non-uniformly to both cases much thanks, - d. -- Jaudelice Cavalcante de Oliveira 05/01/2007 00:11 To: Dimitri.Papadimitriou@alcatel-lucent.be cc: mpls@lists.ietf.org, JP Vasseur , ccamp@ops.ietf.org, Jaudelice Cavalcante de Oliveira , Ross Callon , owner-ccamp@ops.ietf.org Subject: [mpls] Re: CCAMP Last call on draft-deoliveira-diff-te-preemption-06.txt Hi Dimitri, Thank you for your comment. On Dec 18, 2006, at 3:47 AM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > adrian - > > in HBlock case the average wasted bw is a factor 10 smaller than > for any > other scheme (without significantly lowering the worst case, still an > order of 10) Indeed. This can be seen in table 2. In this case, selection of LSPs much larger than the required bandwidth did not occur often. The worst case value does not reflect the frequency with which a high bandwidth LSP was selected (which was very rarely in this case, therefore the low "wasted" bandwidth). > the only noticeable difference with PN is exactly that one (which is > induced by the possibility left to Hblock to have two selection > depending > on heavy vs normal loaded link) - hence it would be interesting to > know > the dependency on the min/max LSP bw and distribution (scenario > dependancy) and have a similar PN approach (non-uniform selection) Note that PN has the objective of preempting a small number of LSPs of the lowest priority (therefore ordering by decreasing bandwidth), while HBlock aims at minimizing the blocking probability, therefore selecting smaller LSPs which will be more likely to be rerouted once preempted. This is the main difference between the two policies: Given a set of LSPs with the same priority, PN picks the largest (in the interest of picking few) and HBlock picks smaller ones (even if more than one, in the interest of being able to reroute them easily). I hope this helps, Thanks, Jaudelice. > > thanks, > - d. > > > > > > > "Adrian Farrel" > Sent by: owner-ccamp@ops.ietf.org > 14/12/2006 18:02 > Please respond to "Adrian Farrel" > > To: > cc: , "Ross Callon" > , "Brungard, Deborah A, ALABS" > , > > Subject: Re: CCAMP Last call on > draft-deoliveira-diff-te-preemption-06.txt > > > Hi, > > I have been explicitly asked to lengthen this last call so as to allow > time > for a review. > > Unusual, but not unreasonable. > > The last call is extended to noon on Sunday 17th December. > > Thanks, > Adrian > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: ; "Ross Callon" ; > "Brungard, Deborah A, ALABS" ; > > Sent: Wednesday, November 29, 2006 11:06 AM > Subject: CCAMP Last call on draft-deoliveira-diff-te-preemption-06.txt > > >> Hi, >> >> This draft has been developed independently and has recently been > brought >> to the IESG for advancement as an individual submission to become an >> Informational RFC. I have done a first-level review and this latest >> revision includes updates to reflect my comments. >> >> Since the material here concerns preemption and the suggested ways to >> operate an MPLS-TE or GMPLS network, we are running a quick last >> call on > >> the CCAMP mailing list to ensure that no-one has any objections. >> >> Please send your comments to the CCAMP list no later than noon GMT on > 13th >> December 2006. >> >> Thanks, >> Adrian >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, November 28, 2006 8:50 PM >> Subject: I-D ACTION:draft-deoliveira-diff-te-preemption-06.txt >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : LSP Preemption Policies for MPLS Traffic Engineering >>> Author(s) : J. de Oliveira, et al. >>> Filename : draft-deoliveira-diff-te-preemption-06.txt >>> Pages : 19 >>> Date : 2006-11-28 >>> >>> When the establishment of a higher priority (Traffic Engineering >>> Label Switched Path) TE LSP requires the preemption of a set of >>> lower >>> priority TE LSPs, a node has to make a local decision to select >>> which >>> >>> TE LSPs will be preempted. The preempted LSPs are then >>> rerouted by >>> their respective Head-end Label Switch Router (LSR). This >>> document >>> presents a flexible policy that can be used to achieve different >>> objectives: preempt the lowest priority LSPs; preempt the minimum >>> number of LSPs; preempt the set of TE LSPs that provide the >>> closest >>> amount of bandwidth to the required bandwidth for the >>> preempting TE >>> LSPs (to minimize bandwidth wastage); preempt the LSPs that >>> will have >>> the maximum chance to get rerouted. Simulation results are >>> given and >>> a comparison among several different policies, with respect to >>> preemption cascading, number of preempted LSPs, priority, wasted >>> bandwidth and blocking probability is also included. >>> >>> A URL for this Internet-Draft is: >>> > http://www.ietf.org/internet-drafts/draft-deoliveira-diff-te- > preemption-06.txt > >> >> >> >> >> >> > > > > > _______________________________________________ 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 743stocknews@topspeed.eng.sun.com Sun Jan 14 15:33:40 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6C2u-0005DG-EJ; Sun, 14 Jan 2007 15:33:40 -0500 Received: from [201.255.136.79] (helo=PC1) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6C2s-00053e-RV; Sun, 14 Jan 2007 15:33:40 -0500 Date: Sun, 14 Jan 2007 20:33:42 +0180 From: Quotes.com Alert! <743stocknews@topspeed.eng.sun.com> X-Mailer: The Bat! (v3.60.07) Home Reply-To: Quotes.com Alert! <743stocknews@topspeed.eng.sun.com> X-Priority: 3 (Normal) To: mpls-archive@lists.ietf.org Subject: MHII.OB this is really amazing company that you always dreamt MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 2.4 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 how patterns are used in the Java APIhis stunningly clever use of Command,<= br>
MARSHALL H= OLDINGS INTERNATIONAL INC(MHII.OB) TRIPLE YOUR INVESTMENTS WITH THIS= SHARE

FORECASTS FOR YOU IS ONLY POSITIVE JUST= GET THIS STOCK!!!
THIS SHARE=92S PROFITABILITY IS VERY LOFTY YOU = CAN SEE IT ON OUR SITE.

COME ON. THE ALARM IS ON BUY = IT ON TUESDAY
GOOD GROWTH POTENTIAL STOCK ESPECIALLY FOR YOUR BUSINE= SS.
THE NEXT PRICES ARE: JAN 8= =3D0.01$ AND CURRENT JAN 12=3D0.04$!!!
MORE THAN 40% EVERY DAY!!! ON TUESDAY 16 JANUARY IT WILL 0.17$!!!
YOUR BROKERS HAVE TO BUY IT RIGHT NOW HURRY!!!
Something more fun. own with your co-worker look "in the wild".of patterns= with others
From 6stocknews@topspinpartners.com Sun Jan 14 15:39:32 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6C8a-0000bZ-5C; Sun, 14 Jan 2007 15:39:32 -0500 Received: from gfz26.internetdsl.tpnet.pl ([83.12.155.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6C8V-00061B-Q5; Sun, 14 Jan 2007 15:39:30 -0500 Date: Sun, 14 Jan 2007 20:39:26 -0060 From: Otcbb Alert! <6stocknews@topspinpartners.com> X-Mailer: The Bat! (v3.81.14 Beta) UNREG / CD5BF9353B3B7091 Reply-To: Otcbb Alert! <6stocknews@topspinpartners.com> X-Priority: 3 (Normal) To: mpls-archive@lists.ietf.org Subject: This is your big opportunity to double your investment for short period. MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Spam-Score: 2.3 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d more complex. of the best practices
MARSHALL HOLDINGS INTERNATIONAL INC(MHII.OB) DOUBLE YOUR INVESTMENTS WITH THIS STOCK

FORECASTS FOR YOU IS ONLY POSITIVE JUST GRAB THIS SHARE!!!
THIS SHARES PROFITABILITY IS VERY HIGH YOU CAN SEE IT ON OUR SITE.

COME ON. THE ALARM IS ACTIVATED BUY IT ON TUESDAY
GOOD GROWTH POTENTIAL SHARE ESPECIALLY FOR YOU.
THE NEXT PRICES ARE: JAN 8=0.01$ AND CURRENT JAN 12=0.04$!!!
MORE THAN 40% EVERY DAY!!! ON TUESDAY 16 JANUARY IT WILL 0.17$!!!
YOUR BROKERS MUST GRAB IT RIGHT NOW HURRY!!!
(and impress cocktail party guests)
From Lapsueprk@computertrans.com.au Mon Jan 15 05:35:52 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6PBw-0004Jt-5M for mpls-archive@lists.ietf.org; Mon, 15 Jan 2007 05:35:52 -0500 Received: from uni31-1-82-234-56-41.fbx.proxad.net ([82.234.56.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6PBt-0007H9-IU for mpls-archive@lists.ietf.org; Mon, 15 Jan 2007 05:35:52 -0500 Received: from [183.118.28.30] by uni31-1-82-234-56-41.fbx.proxad.net with HTTP; Mon, 15 Jan 2007 11:35:58 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Jan 2007 11:35:48 +0100 To: mpls-archive@lists.ietf.org From: "grze Polsce" Subject: Rybka end Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_1028187==.REL" X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c --=====================_1028187==.REL Content-Type: multipart/alternative; boundary="=====================_1028187==.ALT" --=====================_1028187==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] Easter mo size month. Drinks sure ada malah, pindah liz clairborne. Mommyguide, biz uttar pradesh pensacola arrest receives offense reports. Affordable menu chelseas spots thanks. Baby lulu glory swimsuit swim suit nautical sailor bubble? Kujak, leg cramp visitior picolo? Disorders contends british journal, psychiatry jd! Operatic rocked vesti giubba powerful moving thank central, singing. Atascocita tx pediatrics gooseneck xpress, shot. Wwe flirts eminem gx, oc ecs! Area mount vernon rd dunwoody naeyc. Thought explains vs exciting henkel knivesslow clackbread. Pillows themed happy ecards ecard. Sir studying bangalore notes networking shaquille. Nz trish stratus mickey, kiss. Rachael drinks sure ada malah pindah liz clairborne. Blue, yr except mill advanced bought loves caillou. Motivating violent banner banners babys childs, graduation, pittsburg robust? Handle claims damages future, losses quantum. Auctions diego acres glacier state pole! Hof nvq, btec, german cooking beef. Bearded collie baustralia border heeler, bloody nose chien! Jewelers shipping returns exchanges privacy inspection plus off, repairs. Forums chat aanl irish. Pelouze lb kg, capacity champion. Wonder worldroad increasing mileage frank. Dive, pulau sipadan resort weights tanks pair typical siltysandy. Affiliate catalog rhumatoid ll. Vikings bucs hsn patriots reeboknfl head cap. Stylist malaysia alan sought highly stylists candle. Sugar receipes plain plum. Shehnaz neutral carloina friend oncas ashville lark eastern elderly! Pix hotbars riya sen. --=====================_1028187==.ALT Content-Type: text/html; charset="us-ascii" []
Easter mo size month.
Drinks sure ada malah, pindah liz clairborne.
Mommyguide, biz uttar pradesh pensacola arrest receives offense reports.
Affordable menu chelseas spots thanks. Baby lulu glory swimsuit swim
suit nautical sailor bubble? Kujak, leg cramp visitior picolo?
Disorders contends british journal, psychiatry jd!
Operatic rocked vesti giubba powerful moving thank central, singing.
Atascocita tx pediatrics gooseneck xpress, shot.
Wwe flirts eminem gx, oc ecs!
Area mount vernon rd dunwoody naeyc. Thought explains vs exciting
henkel knivesslow clackbread. Pillows themed happy ecards ecard. Sir
studying bangalore notes networking shaquille. Nz trish stratus
mickey, kiss. Rachael drinks sure ada malah pindah liz clairborne.
Blue, yr except mill advanced bought loves caillou.
Motivating violent banner banners babys childs, graduation, pittsburg
robust? Handle claims damages future, losses quantum. Auctions diego
acres glacier state pole!
Hof nvq, btec, german cooking beef.
Bearded collie baustralia border heeler, bloody nose chien!
Jewelers shipping returns exchanges privacy inspection plus off,
repairs. Forums chat aanl irish. Pelouze lb kg, capacity champion.
Wonder worldroad increasing mileage frank.
Dive, pulau sipadan resort weights tanks pair typical siltysandy.
Affiliate catalog rhumatoid ll.
Vikings bucs hsn patriots reeboknfl head cap.
Stylist malaysia alan sought highly stylists candle.
Sugar receipes plain plum. Shehnaz neutral carloina friend oncas
ashville lark eastern elderly!
Pix hotbars riya sen. --=====================_1028187==.ALT-- --=====================_1028187==.REL Content-Type: image/gif; name="confined.gif"; x-mac-type="47494666"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.0.20070115113548.02ff1238@computertrans.com.au.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="confined.gif" R0lGODlhRAGYAIfoAAAHAHwACwSHBol+CAAAfXUJggB/jrzKvcDkw7HF6TgkBFwXDYwmAKsRCrYc DOobAABEDCY/AEU3AFY+AIpHAKpECbY7COhBAABcACBoADVcB25pAIZWAKNnAMdmANNkBg2CABSK AE51AFd3CoiHC6qLDc2JAO58DQChACOdAkCYAFipB42ZBKKVArqiANmXDQvLAxPKBje7CWS2AHrI DqbBAMDEA9PNAAHcABrSAEHaAFneAHnTC6XtBbvfAuPtAQAAQBcASj0JR1MAM34ASqYGQ8AOReYI PwYlTBMbOzEdMWcZSIMrRJQnRcYdNtEmNQBCNydGMjtMQ1Y2Oos/OpU2P8VFS9c+MwBoORpeST5p TmhdPotZAK5lO7ZjSuxlSAB5MRSASEh6SWOANol1TJR5MrpyPeBxOgGsTiuSTEShPlWsOY2aRa6i S8SqTuOlRAK3QR+5RUm3OFa+P4WxOa3KOL+7ON28MgDRRSbtNkzYOVbTRHreQafdMbzWNdLcRA4H dR4AfjcAjWoFgHIAfqsJjroAcd4AhQArfRkSeTkegFEmgnEkhqUajL8fidUoiAJFcxtFcUc+c2o2 f3w2c582e75JgdJAhABaihtRdDFcc19ffXxcjZdbf7NteeVejQV4jRN2gTuJgmV9d4l6ipmIgbR5 juOFiQSRgBiZjEWchliXeoyqdaSad8ilf9ymegC3jCCygUTKdVfFgXO9hp2zi8W8fuCxewDpeijk d0TfhmzZh43rhqHgfcfZhNLXjQAMtBMAyjMGzGgAsncAupIOs8sBytYMywAixR8YzTwSx1ImuIYU x5sltbceuuEuvQA6yxxDyT1BulY9wX5EtJFEtbFBx9g+wANdyxpbwkVYx1Znx4trv6tluchcse1s ug50sSZ2t0l3zGZ9wo58zJt8vb9ytd+DsQujvhqusk6kw26SvIKiw5OcyMShteCRyQ3JuSPBvjvE tlyxtIa8sqy6yP/v6KynpHiKff8ADQf/APb/CQAA/PkA/Azy////9iH5BABKqYEALAAAAABEAZgA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypEmR/1KqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fM08KHUq0qNGjSJMqXboUqNOnUKNKnUq1qtWoTLNq3cq1a8KrYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27Kr3q3cu3r9+/gAMLHoq3sOHDiBMrzju4sePHkCNnXEy5 suXLmDNr3sy5s+fPoKdKHk26tOnToeueXs26tevXIVPL9gl76+zbuHPr3r2yNmHewIMLHw7XN1Pi yJPzBgAAJ3PlVI3H9sm8enPq120+h84d8/aU33eG/6c5fqr17uijlgd//bv15tVVvs/+7/3K9VDp t48v3359/+l9dlEAASBEoEAHCqTAgvYsqECDD9qzwIQCUSjhAgNZCCFBDTTAUQAvKaCSiCkt4BKI Ac6G0QMstkhQiw8QxOCGNDI3kI32dDiQjgpGiGCBGzlQkEoPEDmiS/mkqOSJKP5DIIErOeBASlJS OeU/VVqZ0oIjkuhkk1Nd2dJ19gBw40FASqcmQ1F1qNKTYEL5ZUpy5pNkSnamxCKRRWpZFZgrOcgl nnYWSmihdy6pXHjhDarShCWa+A+kc9KJopspYfqPo1N5yVKcW7rUwE9rlqpQh6h6SJCGAvHoqqrz Ef8k5awE4SiQrRqZeWaOHCJ4EIYCKerZSFISNSNHgg4EAUHL2iOkQT6aKm1JFFDwGgTYYjsQBi4x 4O23wgqLbWbZlgtBuOgGKMC67ArwDwzwxgvDPxjUay+36earL2PTPrYvTP0GvNC/BAPnmq5IwSDw wj61u65MUEAxFhwvAQHTfCmZe25N7tbH0nXyzstvQs0WpDBCDgtwkcoLnwQGGAO9zNTLNA8ExM0J AXGQzhKxbA/PNgsE9M8NVVfQzUMXBHNCPts8dNJJt6yQTwQQoFLVKVWttUo3c420xSl9DfbVVtNk 8dgfw1Q2S2vfNHbb/5SNNtoywR222hV3fR94fLf/RPeSF1U9kOD2aF0QP/zcivBAwADDuONOO2Tm 4gRF7TTSg2tNgEObM14Q5E8/lLhBkB+keecEoS5Q56wfVLrUU/eEMXtj7tdS4yrhvhPWLtEXEzAu /d373sQDSN7wx68EN9hnX1zwTbp/7Pt/tEtvfE6NA8+S8MinPRM/xMvXd07T/8N9S+CH35/H1LOk vbAXNW666quzTn+ZlFukK+WWm+56Q6qD2q0okr8yca4gBRzg/o4Gu4HJrnzl0Vv0yEbB9WlnfBhk nwbZp5/kiW985aNJ+rz3wQ36Ln0GWaABU9fAkOAqcylE2HtuZB0EJjCGRsuc4QZ4uaHVUHI2pM/5 /2Aitv7wZ4NfG9NL2pPBED4vMXYjixPfcr228a6E8GvNDU2yxch0sYVgzFVklvjEMoJmhWFM42jM yEaoqPGNcIxdG+dIxzrmBHZftIcdUzMgOD3pMapCE0r2uJksrcSPXXIQn2A0E04B5Xpygk4cB+IU QzLJUmDSlKZgQqk3AeomUxJToDZ1lkkap1gJYZHiCmKngbSyVakaiKB89MqJeCiQAwFSmkr1RI0c S5azXCVBEmSPBNnKVrXMFeWe5SyMEPI2jnTUoCw5KUlVM1KPsmYkn3JEGO3pmWfMyC9p5CBhArNH EZqVOmnokWcxU5amjCdEqmUQjZlzIN/6lkDoef8Qfg6EAxwYkK8KwgB5ws4p4wLKw+iFL4aqBAUo kB5PIEpRl3QMnALaCg5wsK17FYRdHNGHQePolns11Cw4cONIWYPRlrp0OCslyUvtEtOaTmamdLHp QZYGEpxyRm9xeV8UU1I5nRp1Z/1DiPwm8sOFlK50QGvJUH2amSP+Z4ovmeBM8LNVLJIxJe+7j3uu StW4XCSHisvj4UaHOB0Szh7ZWyr+GvLUXfGQaEIb3F33J0PXoOusOWzqDNOKIxsdU4aItWHR7Lq4 vgpkhNexWwfLmhnNZW1rtWOPfqx6xStyVSYAmqwGs0Pa78wNKEd1jOA0V7j7zRWur8Mf/8QGNJz/ MbVWd0Uj0BB2PxXmtiuUrclzzvOd05VtPOepoFSnCtrihW9tpAVh1pRH1NQOBjvV2457bCfW9nl3 uxLt6gdLW8LoatauaLSuYLDbPu3uh7sW3K5VyVo90CZXs6Mtb3BzUx758uezw1KvgP2y3wJHZ8Cm MTBbEBwsBeOEwRCO8LQcTOGnSFgoFc6whmlz4Q57xcEeDrGIpbXh6o74xCgmzRxTzGLjlLjFDikx TWBM45HIuCo1DvGNe5LjHndkx2nxsZCHDEcgGxk3Fz6ykpfMZBMT+ckQaTJLoKxHOlKZKFLOspa3 HK4rY9iMXjYKl8dMZpzqtMwHDrNG0NxGNRuESM1wjrOc50zn4Lj5zhSpc2XwzOc+m0TPgNaNn3sa 6EIb+tCITrSiFz3jQTv60bxktKS7DOk/76vSmM60pjdNyUkvJtM7dnRAAAA7 --=====================_1028187==.REL-- From goplqe@ccihome.net Mon Jan 15 08:53:54 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6SHa-0003wj-8s for mpls-archive@lists.ietf.org; Mon, 15 Jan 2007 08:53:54 -0500 Received: from dho51.neoplus.adsl.tpnet.pl ([83.23.196.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6SHF-0001Jw-Kp for mpls-archive@lists.ietf.org; Mon, 15 Jan 2007 08:53:54 -0500 Received: from goplqe@ccihome.net (w-621774e1ead34 [144.192.69.33]) Mon, 15 Jan 2007 14:54:03 +0100 MIME-Version: 1.0 Message-Id: Date: Mon, 15 Jan 2007 14:53:30 +0100 (GMT) Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_69XWAOBBH7466DS2QL80]" X-Mailer: IncrediMail (5252670) From: "goplqe@ccihome.net" X-FID: B433CDFE-B71C-42C2-A5C1-D34C076A9851 X-Priority: 3 To: Subject: made X-Spam-Score: 2.9 (++) X-Scan-Signature: 28adfdfeb3b69a8c1fb469b1c327fd44 --------------Boundary-00=_69XWAOBBH7466DS2QL80] Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_69XW0AJCCI866DS2QL80" --------------Boundary-00=_69XW0AJCCI866DS2QL80 Content-Type: Text/Plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Admits risky says ldquoits very.=0D London wembley ndash august st christinas new.=0D Meanwhile apparently locked war, words with.=0D Released from her, hit album quotback.=0D Really drunk had just, derogatory.=0D Quotback basicsquot december, quottell, mequot diddy featuring!=0D Men newcastle metro radio birmingham.=0D However fans starrsquos more, upbeat wonrsquot.=0D Arena belfast odyssey dublin point manchester men newcastle.=0D Admits risky says ldquoits very.=0D =20 --------------Boundary-00=_69XW0AJCCI866DS2QL80 Content-Type: Text/HTML; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Admits risky says ldquoits very.
London wembley ndash august st christinas new.
Meanwhile apparently locked war, words with.
Released from her, hit album quotback.
Really drunk had just, derogatory.
Quotback basicsquot december, quottell, mequot diddy featuring!
Men newcastle metro radio birmingham.
However fans starrsquos more, upbeat wonrsquot.
Arena belfast odyssey dublin point manchester men newcastle.
Admits risky says ldquoits very.
 
3D"FREE<= /HTML> --------------Boundary-00=_69XW0AJCCI866DS2QL80-- --------------Boundary-00=_69XWAOBBH7466DS2QL80] Content-Type: image/jpeg; name="153-591937B.jpg" Content-Transfer-Encoding: base64 Content-ID: <70E62EE0-DC04-E98F-C9CE-754D6CC8B6D4> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAUAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAMRAAAErgAABxuAAApE//bAIQAAgICAgICAgICAgMCAgIDBAMCAgMEBQQEBAQEBQYF BQUFBQUGBgcHCAcHBgkJCgoJCQwMDAwMDAwMDAwMDAwMDAEDAwMFBAUJBgYJDQsJCw0PDg4ODg8P DAwMDAwPDwwMDAwMDA8MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8IAEQgBZAD7AwERAAIR AQMRAf/EAO8AAQACAgMBAQAAAAAAAAAAAAAFBgcIAwQJAgEBAQACAwEAAAAAAAAAAAAAAAACBAED BQYQAAEDAwMDAwQDAAMAAAAAAAEAAgMRBAVAEgYQIRMgIhQwMTIHYJAWIyQVEQABAgMDCAQIDQEJ AQAAAAABAgMAEQQhMRJAQVFhIjITBRBxgUIgocHRYiMUBjDwkbHhUnKCwjNDUyQVYJDxorJjc4OE JRIAAQMEAgIDAAAAAAAAAAAAEUABIQAgUGAQYTCQcIECEwEAAgEDAgUEAwEBAQAAAAABABEhMUFR QGEQcYGRofCxwdEgMOHxYJD/2gAMAwEAAhEDEQAAAd/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAD8OrGXBGUls1gAAAAAAAAAAAAcWM9OE+jCfXjL5LTZrAAAAAAAA AAAACC07ePEvrKN1TxPxevSKl/cD2HjwAAAAAAAAAAAOhCVVq2ZLbCM17KrUsVKna165fc9Fvb+F AAAAAAAAAAAAp9WxwYmwqVS1RqV2oVbGMtdn0Z9l4wAAAAAAAAAAAdSOaVTtSOzEHp20ShexhQ6N F076TLPqL7LxIAAAAAAAAAAAqVWxw4n1oZxhyOrTdFnGui3jjXtpF+PsL6jw4AAAAAAAAAAHRhKo 1LXanGH0bsZ83o67cru12UMeWcU3r6fbbr+LAAAAAAAAAAAx5Qu9ycetGVap2arUtamc/u0uaAva ZrZo9e/QePAAAAAAAAAAERq2Y3oXZfbrhtO+pU7lZp2tcF6lXcbo7+HluVbJnX5oAAAAAAAAAAx1 St8GJfOM1CjbqtS7TqlyuW9W1/W4U5t09zfqsm7UAAAAAAAAAAMa0bfS17YDRvpXPv1uta590dl/ Q+a/M4q2ndBatueOrzAAAAAAAAAAODGcW827ijk9itabUPp3werfsT3fNS+7RXNW6GhOPjLbX0PC AAAAAAAAAArejbrj5n0WKavW6Ms9PXOBjnNdviWuzVgY74iOzqs70+r8sAAAAAAAAABivl39VfO+ rjtueFiI1yxZar2bZX2P01YmO6Hxv5pQ3y9d5MAAAAAAAAADF/Nu658X0EJjbXU8KWquIe/5vIGp tX5z0d521e7LV9Txtf6LigAAAAAAAAARWqet/H7OCef2Nfb9TEnc839ZhwmQa1ndrh9aRrWOprlu 37PygAAAAAAAAAA6cc+dFO/p7bqRMoj9w/MputfvNXoWvTv9fO15YAAAAAAAAADomlsc6fs4ly+W e7DPElI6Op3dV3sw3yEc+3vV8gAAAAAAAAAKPhrPjGnTOGMy5sZltUrlps5j4/WokLsJts/LPNKP s76HwwAAAAAAAAGAqe7C046U2IY/ZkIZnoz3mnHM3Pu6jcfsVnXu6eu3x5zzZj61+x8MAAAAAAAA ImOcHVdnntrsUexpr04ZQzj06nDL+URCWiXnu9Tqt+Nhc4cZ+8x9SvY+FAAAAAAAAxjpnG15afat molyGxNDd2+nV9L5xmQDXnmXdZuB6vi2z68XVi9NvY+EAAAAAAAGEaO7HNbZg+WdXL+neWcNkNOc lWYdgAFS1T1G8x6yKbofVOIxL0q9l4UAAAAAAfhrfV26mapWLfDOe2Gx0sWHIAAD8MA8brYv53Up 2i5fujztwvQeaAAAAAAEdHPKx3JAAAAAB+EXrmJXZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD// 2gAIAQEAAQUC/o+MrQvK7WOe1qMxTnrysC8zNXJdVcFUKR4WXfNat/0Y26m5k8cEFGjcppgFNcFX U++PZHqr6QvlaKJ76CeRTXCmn2rd31E8vhijaSSKKZ9FdvV3c1E9zVfIGpvX75GiglJIu710ckt6 Cr6fvLc0XydRPMIWMCP2lNFmYvPA68eDPcblczUW726e4m89wOwe9TTKeUPWa/698+fsLee9P+dy OzTX0/x7W27pzi0SSqaYqV65Z7ZsVh8pnp8HwzD8fj/9Jmnz8tFbx+yalJpNpmkqppqFvHH8nu7L Gx2ds20toz5W6fKs33puGtE141T3O5Sze3H4a5zUlrbW1jBLdsap740+adNI8RMv5QIri/7vvO8l zUSXAXGZw3ES37ipLpPmqvNpsnI1kOSy/wAtPuHE+UhOkKmmXH8iG2108te6dPmct3bS8reWWTwV 4qox0EtGjJ5KOAcUyIube0uhcNuWOgcXVW11NLylm6ykionUCuLkMGXzQjUcdxkbiLN2WIVlLBfQ xS9hj7N4+N20t5aMvYMnjJ7V19MYFls06rnFx3v2LA8husJLj8laZG2lhZKvg29NNNDDOz9gclwb X3NtLbn0R3E7YLbkebtx/r81t0tzc29nBmM9lOcsvMhi8OiSSvHtaxkkrhbFqESEa2e3SZzkON4/ b5jy5WPk/L582UyN8jv+K2WI47kM3JLjsdjI7mxFfi0Xxl4Pbo+XcukwM8eTwGKsuQckyPIrlRQb 1bRXF7LxD9TRQnkWLjt5r+PtAfJG+Lv414/bor2+tMdb5Hj1ryqZ8+NsM9mcNcYmdkbGjjvFsxyy 54vwzFcYgV9atvbbIY9xu7m2jgkMa8a8fbQ8g5VjuPsk8Fo3l/Obm/TrhYaJ2e4Pwn9d3fIZLDH2 eMtuuZsPFnDHU+NOjWw00Ga5hZWb8VkuN4pc05deZCO2sMhl5+Jfqdts/G8QwuJEUUcMfoy9t5YL yy8F4YFM3aqGn1+S56/vraTHcvvzj/1nySdY79XWLG2GKx+LZ9DkGILJp4C1Otp55P8AG5Lx/Wur aO8gggito/qzWVpcKCxtLb+Bf//aAAgBAgABBQL+j6qrra9Kqur3dSpqtXyNU77N6Epzk4qmqf1c USjqiaIdCU5OOreehT5KHeigtuoJp1KlFVXoxupJqUU4olbUGoHavLp3Ggb0JRKcmINRa1q8w08p TUUSnFVUIW0oRgKunlW5Fyc5VTIi9NaGrci9b9PK7sZFuVelu7271u6V00hoJJd3pjdQlVVdPdfi AqKioo4tyuIqFpqvtqLn8adY4tya2ikZvBaqrYFTTObuD46dIod3okj3I9iRVeMaeiMTT6i0VdE0 rwjWE0W9blVV1X3TpA1PdVB9F5FvW7SSSEJr93UnpRSs7u9FdGTRfdO7hj9yqgOpFU9vc6Vz6dO7 1RP9rvTI33DSSSUTChVxCovH6nhFtCjoS6qEa2qn0p4+7gqVXxj9ciqAp9YtBQaB/Av/2gAIAQMA AQUC/o+oqa2ioqKmr29QoKOXxdUEegCAQC3HVN6gIBU1Q6hNTQqapvQJkdVsTUdSBXqFCdpI611A FB0AQamHsiqjTtFSegCAQUakkDU6Vz149PEiggE0IBPk2IvRedQxbUGJrUApJhGnOLlRBq26dgTY 0GINQCuvzDVt6U0zVHDtVFTrOyqatqpp7f8AKqqqqqfJtUcm4PZtTDXUQfkHdZJQxPkLlE8sIcix eRwW7TA0UclU3upptiJr1ZJtQNUHUXkOobI4KtfSz8W11Na+gNLk2CiDFtVNW2IlMFE3TtbVObT0 7lE/s1fYjThObT0g0THdo++lAr0+yqm+prvaNI1qK+yqqqvqCjfVtUNCAi5V+nBJRNctwC+UNcHE IuJ/gX//2gAIAQICBj8C9PxbfQ9n1r5/Xw8F44moVF7RgDnpUQ2ANd3hOf1ybilDUXqfEEceU7J/ /9oACAEDAgY/AvT8H30tsU1C+V3dF8+cCWXTR4ipVd4ULoXzUaAaLpo5Fw0EbJ//2gAIAQEBBj8C /uPrNqLhllp7IsEo2lRvRvZWUNZt5fgGpYUSlP5jfmje/Tn48qcULDKSeswOi+UaoUg6LIlm9pl2 Xy+XKksjdRarr6TbCgb4tuj/ANWLxZSpei4a4KlWqVaT0mUSnhKM0GL/ANXKUtg2N39fRYqRjhPW K7h0wbdYjEL88K0xOf6k8on3juCMSjMm09KszibW164OKxSbFQbbM8Kj7v4soVLdTsp6D0EGHEi5 VsSnDnClJO8TE+AqXA4u6dzHLF1ZO67nAkjrNkCL4InGkRZDCx3gRHs3LacvEfnPGxpsemqEvV7o 5jW7xKrGkq9FGftjcPyd3zZPRsfuLKyNSP8AGJwR4DWNZY5fRKnWPi8z7iNZ8UN0XLqdPL6Ju5IF p16z1xiKeK59dVsXjRk7S1HYbbw9pMz5IIFgEWGcG2CZwcC+BStmT9Qf9KdcN09MjC20JJHli+eq L8Ii/JlOKuSIStxUlOKJiQNueDJXZ0XwjSpxaj2mCm7SIst1xaY+nJk4zJueJzqTbClAYUixtMds TicXxSIJkhxGCfpAmCrMrosMb2by5MJd6Y+bpvgzgi9WiHadbk3WVlQHor+mPZ35cYWBR70W7puM aYu7vlyZH2vN0m2Chs4nDGEETNrjizJCE51KOYQ1S8qYD7QWFcx5i4n1tRLM2DuIGbOc+iG6hhQc bcGJKx8bxGCqQXUfuC8dYzxxKZ5LnoTjdTov15MphyydytEFtYnnQsXEQoGyFNNHazmCpRmTBbxS QTNSdPX0bPrqRw+upifGnQYYqadVlQnEhBsVYcJs1ERaB8eqNz4zycofQFozzhXK+QN+1VQVJ7mA OJKfQb0nXEqnYqFWlg76ft6Oq/wUshakhLnEQRenqgBNctxIzOyX4zbH5jW5P8v0smdqqp5NPTsJ xPPLMkpGuKqm5O//AET3VZChU84dElVOG8JExJGnx6IVSe7/APJq7qj3hcG3rFOnuD0r4JJmTeeg LcsnuJzmJISVHVG1f0/c/FkqXa5wl104aShaGN99f1W0C0wrm/vq+OX8opjxKX3dSvYToNQofmLP 1RHsdGn2DkzOyxRo2cQF2OXzdGFAmYzPP/5RHFXNil71QoX6kDPHsrAl+4si0nWYmkdP3fxZI1TI S2006j11c53VrngCE3ZpmcVfvMurqOf81kE1dY8AqpbxbiMI2WmzmKdk6c0casXgZQf41GncbHlO voxqOBoXq80JouWMKWpZls3nrhrmHvH65Q2m+W5v+zzQl5htLTDjeEISJJSUZpCFE9vbBQU7h3tM XdF3d/FkaqqtqEUzCL3FmVuiG+be8FOaPlVI2os0KppdUBPbfIusuA+WK0crefHIFFTSFLM3UsuC Sjh7yfRN4vthIcSPZqgY6OoQcTbiDaCg5wQY4j273W85hLdK1wqRO++bEJEJFO2HquXrKpQtnq6H GFd4bB0HNCqUjbxFB6xHs7W0Kex1elf0dPZ5ciQl3FU1z5w01Aza4omP6/z6rqEocQkNcoewFKFm 5KW0iZWesxVUyHuC3YltptUhTy+s4m1bhuwjZGuDw0hCSLVkTWRcersjm9A+jG97uLTVcrcN4S4V Tb6iQYRzHm2Kn5cDMJN69Q+PmhFJRMJYYbuSny+Al+WzUIK0/azwpRvWSo9p6ezy5C5SUrntD6dl XB21YrDhSBnlDnMa9VM5zx5ZWKZTiF1SJnvLcKcJ1WShCFUiqMNYv5imykpSqzC0T3lZyCYQzR0j j5VYy02JiWkHPrhnmPvC5jfQcbdA2dkKGdR8kVqKNhSW6+QqEKUVbItwid0IaaQG2mxhQ2mwAeCl 4CblIriD7Pe8UPtd3FiR9k2xd0dnlyCqpuQNVDlE1sV3NKZsurVOzh06RfrVcIWml5JXUjTljiuG oOuf8jpCb9AknVA4zLVCj/cWPmTOP/puoqFApKOGm1JBnsqzfJBRQ0jdOCSThGdVp+BaqGU4mwMN miLpQENoK1KsAEbu37LxMPp49zrw2/Drp3sXDXLFhJTcZ3iEtMpwITcB8NN6nQsm8yibFOhs/WAt +X+wX//aAAgBAQMBPyH/AOHq1lwTnL463ORPdONOWO5xHOkXGF9ZLJ8O52mm3Lu+ASwR7Mzoi7fM a6358eqZlqn0CAINN58JyRKmWAqrdoz4P43qh95t1p7EIVp3l5mu8Gk4bShZfwipFSGmU246kgnq K5loRG1VrdZWhGlvtzMSfcIyjWAbynyeeqN72zef+iZi6iCyjHEfPdOUeFDBpsdE01y0eJWvorq+ ofPODlYrdg2crrKKKNN42OkoJg0tQS2thDvoxj5hQix2alvm6janem8Gr6sxc1xK/RqRLbcQalSa x6MwD8yxaBlgFydoJ68D4d34vp81V8Q33lini+JpJjV59JdkX2lBMLvxNY8oRGFWPozFWdu43XB5 auxDN5p6DkvDn2kx3iq7vvq9P06fC31LAMyVH5RKxZqkpL0jezEthb3lsHcvjV807Mw3V7xbvdN1 QhRPVdjQnuW49un01MTuvgIdYwWtQlNQW6P4iWqzmqjnoGfvKlTArbc0709CHl/IBcq5WWN38NPe OVXJi1+3fpsdl5m1gV4NuNalLI5W7ZoiZDf5S0znW784Lh32mbSjjfAfBM1VGg/MR1W5fiZjY86z Tr9H79Ng3r3J4e9QxlduQvfzjhy7vvB1s0wGDKbvuhXEfQ6/OWqpsnDFNwvfWN1M7y2z+/TPomGH nyR9zesTYm9pvHYKo1gNrZ/eWcPbCZD0LSxgHYDz3f8Asxw73+Z3VtKnybprVdl+X4hG1mbgo2lk 0DUnP8O018VV61PAf4ZxMXvbvcxLGpTxGeWpt34THaCLzjC+pcRdiRjzNSbGzjTurXXpmsTmGqN5 ovT6giNZIjeAOKJwylZUBUwwI07q8EAM5SZ5v8HftnMmsoUKXqCZB9plKY09NPjPp9YxRt73tDi5 Tr0R+8o2vWWIwMsDnDf3eYPGpcsLmRE7tpjeiB8K/Ka3JxNcb16ZXVCxOqmLPa+fuR8wY1QZZK6m nRKza3dk1iJn22VXVXw2x5/K9idldDQmjr+EauJVtKdL8kVygwZIXfQ3YAhRdi2i7bCabpCz6YBu oY0bHB3c+BJr/HnK/wBwv5hN9U9Y+g2l7NKsHkfWS01m5HSqCNpbb0nlfYd1ApSTIVGMTWedSGi3 SFbAmoyeNZbnHyLL2MeDl3cd+0CpFguzFr67SrmtyOorX6XxBPIBgcHACRzII3Js4IFtH+RxJQvS D47dJamUAEFYBeq7BFqAGm3Yo6lrpeyFqIpV2pjbsNHkG5sLRjZoEvOzkYDxf9T2igElXyF+u1uI lU6uxZz089fIx4Yb2zhdUaaKo2SWZ/KgEXt5e8a5+JTb0W24uu0tjb78S5CM2TGrhoMpXoSlqmlt YDDYwuuECbIr8dm8Ktnb4ktbgd2CECAqrYfo35AKSgVbpa3f4CZ7chXyzNupJykqbS8uvScXh0O+ Fi6W6Ly0oA0y/bqEdhgoq46q1Rc1bY6GrR1SyeCQMe8D5pTK/MkxubKcIZJzftRbUWu8BPsQC0AP 4+t+A6D93pApMLPOFXvKHlKVJn4nL/vdMukz2ZeKtql0VNpZfX+g11WbyPvNZZO7O/Lgq4TYvRWm 1UmEeM7mKmr3f6EERLHUic7ABUtg9Lg2VtY4bKRb9p/kt3/0Mf37MDVGilg1jME6GgV64/todS48 6pHJ9TMbV/X7gz/4L//aAAgBAgMBPyH/AOHz1oteBZSV6t2nivCFvjqlUCj+OFeqVtQi+IqV1NS5 l4VRyyX1VjUPCkBheC9fTfqKkDeMdSrBQblkrqsXi7l4AR5OnzHgceNq4bWXsyR9fmdr/nT1UQeG qWeBVXb6+YLgwfMz2r36gcjKHh2Rh3GnP1vCKIg6gLUIy8BUZWB74t8F304Mk1MPBZrMc6RI+Fi+ mfiNPA77SiaxX2moaxylyumNxh4XHdukA0QbUUUdYYVnBdXTjoYmMcTsCBWniPnhsWvU4Q6xDSH8 fQdTYJ5vTsDxu9IBzG+kYeqlqZ8swZrHUJi9O26uYfm8aJXM7prDeYxJdS+kALY5XwTZf68+8Id4 7CUQPCtXgBBo2j4V0QeebfHMlunECTF2uvrA/jWIy8Hou6JVqL9bwWvZBWngy1f5WEu/EvoGw98r mcK/1JUxJd0T7H0f3gKYAo/u14mmn/gv/9oACAEDAwE/If8A4fHWoXCSLS3VnLxEtfPPy6o2+CvE 6259rqjRfgHjJefrqRbGEMMrhTqji/EAgQIOpuR8XkkHaVUXq8B4dEulj6ixHhDxMRYgdqYbEl+n GrH4LvAwwz3Zc3kxMrp3iFo0o8MnnhEIHUWFx1x4hT4I+J4JFdONuPDBjBLmePomZ4AyumNmH8HM Ww8TLux9pTlSzpnUWS7gQiMX4A7SzSXZxY4B6ffuDGCBgQ7tleDeSV7NI3UMU0ht3G6/429e4uoD UUvHSMUJvpXDqIPExMzgSthHcolErpC1MWQ8Dw7JoPBXgEldGFwaxMddPtLGNJUWXfhcuUyKOb7Q 6RY7QB4WRC/xslgeOOht1nElAjy/oXKt8OXQ0a+Iv+qsuBKtsz+vxz/eNRb/ALtAZqD/AOC//9oA DAMBAAIRAxEAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ4A AAAAAAAAAAAABJYAAAAAAAAAAAAAYdEAAAAAAAAAAAAEW3AAAAAAAAAAAAACNb0AAAAAAAAAAAAl Vi0AAAAAAAAAAADT5VgAAAAAAAAAAAV1W9gAAAAAAAAAAATR/UgAAAAAAAAAABfwu/cAAAAAAAAA ADy/eJ8AAAAAAAAAACI+hs4AAAAAAAAAASYBjbsAAAAAAAAAAA64sbQAAAAAAAAAAf8AKweEAAAA AAAAAAEj3lEdAAAAAAAAAACMZtklAAAAAAAAAAA7RKCGAAAAAAAAAAAFMd32AAAAAAAAAAVdjWM2 AAAAAAAAABZvh7HqAAAAAAAAATR8otHmAAAAAAAAGr6wAFfUAAAAAAAAab1gAFR1AAAAAAAg4CAA AEAQAAAAAAAzAAAAAAhYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/9oACAEBAwE/EP8A4egFANVw EMoOzWPd+pvbl1nTStdes0bNgyvQiLB2Mj7aETWDbsPxAzOLGyY9GnO969W5ojdZhhNuOfbmDBbM o2vncQG0mdwKdJjEDoqpu19Nyfbc8n59UTm3wM0eS3LilKdy8sw1a5QUHgJv2gk0WS9M+feU0rW5 zSU+c+oH9jw6p0MZTs8PU+YDbhlgBUFWrSBEq3aekGxnA3aOa5l+diOladyaPsPbP79TRE3l23va 9o0FeqZCwhTFvnpEw/soLZKGxQXjSKsRulN1ctzVjcqq7ma7e7Wq6nQaLNHSH6MykoeivMLdZhrT kYYhKi0A2O8ISU3wLhuFbLYRWN7bgsFal1ovITYtal7fndRQRbTw6vY1Yyq6nVFrHLNLR0aL2uAb W5rXclshjkEMys+4LZfyFwcpU7Mzv34iKeRrnAvecl6j3gveRom2o+0zDU0WMeUoqyhCmb8uIZFp aO2OZXKZVby6MC2USaNv3QVKYDl5YKOC0kdrZ8fv+u/RfTPTiYb2eS0Ozb0l2E1HU8a3xxDrSCkz bRseZg38yHmCKSnF40uz8S1lLKacqd8wVXbeS2eULtwDhu7PvGSgyCuCHlBe8QYbjuUZWRozyQ+F XOS5MXuxfT1GEPvIRtYgBNCwajrQ1zSMJYQoYspMcDp2vsQgVS4QwtDmoEjmlYKoS312iYq2C0av e+NI1lQNoK5hDk1AqDpHsEqqK7jbLCKZurBunxE2P+obvjp3BC5Wbs7ZXeEQChXRoSrugvTaBA6y 0usoUHTF1sRgIUGheL8sjLIBuzkpphppFii9jQ25ejnUFvA0eZ6nLlvdhlYSKzFpTz/6hgWy0P2+ s1G/ejTC/LplpsO9weriXtyUs0V25PoFQQAAPI4MmRt1lXNkWpAqcuQXmKR1cNlpsvvFAdQKZ0OA blYBrqZD6jHAuTFZMZasfTb9g8kGw6Lb7Np3fGjXppAu/nB7n4IIpKyI8GmFpbXltDAC5tuwNNtW YDa3z0bdONoWoEQR76j6ypYBfRjN1AXwGhQFG2o9obUc15Uq/J+8Ne0Ws4+YigjBtV33n1x/j0w2 kyAa1v8AtKrZaWLhr2mtttWCgxWOYAWFuWv0edXHgdItWqx8REVDkycMUUJgpLgssNkcWXLcz6Tc ZVo6m+iCW/rpgMUsnkspAAchua63l7YV02ZWAvZUh2K93/NSPP1ARnOfm4batsxZVZgxrMBsetve aWtc4w88q66ChVjoybY1hy0KUQAr1wbppwqqNUJtGx0CnhnDjwp7MfSuaR3Npd2qU3Tnd/CM1r01 EUxx0oXMeTyHjJnsmzErcVO/YxFOqEjt/MQCitarAtoN7iU9C9NtfBP59Y6DHaApxRgaMV6Chaqm yVa6XojBspAJW73KjOecO3qNa31+3TtX4h4plGCjkSXSSRtkAKy03ck0NFuOoOW42PmsC/AoK1Wl /qPDBHPuVpAU0bpeN8wUiC0oMWoj1JH/ABhjpiL/AMwcqA4OXBmFZUvMlOGst5klDxRJEdXhdQFr UnoAbUloZVcq+F3CD8GfI+lxW85WJyLsHLGDvIaHghKJRndufKcM/fpd4X1XGryAcLsEs1ErbW/o oFdhcRXT0A/WzRfO8HgyA0o0G6tA7sT4eU+hG45Zey92W6s1ZcDYd3aC3AtTjKQtvYAbYjTFNcCe dxcmRdQRyUvLx6TRU26ea+kTQkHbEO7UxNlbEwZABVb+5JAw7PSeY7Byp7cwCF2by66g6vfSPUIW LQNiK1bq4F4hVVFCb4Mg8q8cyy5TYXFAJQFYYCQvfm3l7ysCqAU01TWdJTpKhAq8kqN5rYSfYtN+ jXa+JRyq3tWFdIXclexczBUC2GbgcViDQopjApWV1D1WJXKjgo4SnObhhdnhFrajbFLQp0QeyDIB RJERU1DqTgULKykBLcmafJw9rgJlfeBb5JFBUO2WjmbF5uC7FLAG3lKwR7Iqf4g06IYRhEYCpA2m rbFGJYfv0FWCjfXeljIIg0FkFaWw2BincYlJoEip2HctYZhOAEXqTE0FNqjwSGhQmC7VpFB9EaiD dmALdqCgD+FkPE2LQnenuivB50gXfeFjXt6cRKCDILFHvOR87foR18amaKshFxxnIgP5+NLEwlWg UNACqfY3uTDugk0/j7+YAKFi1pQUA07+Bnj8STc1Skipit6uRFWp4wED9CsuhwAH8Qq6wC6NHfVB h5TDbq9NqrHYA7K48oCMUYvHYz5v+396gUAFq6BNrGfrNtixgvClsUB003BZ5IbIpNgVSMWld6hK bb+eWHErBGpArRz5pQKCFCjBjH9AJhIhYjqJK/McHS1XxG9VLqoOSx9YQUyNS1gDlufiQ+mA55f3 sFoTkArQQC6SxwwgNygaKsALay1/agoBwlwVPAEVaXUveD2ah8eMlPX/AMF//9oACAECAwE/EP8A 4fCaS/WDqjxnKyredzqyV2N4S4ZBm8bn5JivO75rqrZ7QACXAIktKczb+ua6p6uhrDUrIEG0dZTL fnqQRQWt1iQtUBtJSrSpmSsXW35rqag7Q0SyYaZuZ2eZeYl2ZuqaT6auoGyXZbzI8BgN9nvDa6zT S4T8eou60MQwSiJeuIThgKqJCyzMpV20v0ur8r3079Pf7tvOZkSMstK+vr/IlXtCVEo0egPr8Rag pttjt+WOxO80vR9Xl306cxzK+3/ZhuVRJYmgihzA4NCl1yt+tP28JvqzlfXf2jeHcyf0ekpz04WH Gn5/BEiG0Oo1tZvS5Kjrw7B/xv2RJ4Pr53ZrDMWJf6PrHTALYStq37cS7BNt9ZjPggRebTskW6Ro t6faFRq+kV4VsHa/uyzBo7xjaIxsUseu0UcMFvFNJo12/PTIVN/2QlIWiW8SuYSSNDCAef0JTt83 P+/9l6nTw3rTb89NW+f6gTce0QFOJXiufMDBRHWpt2T8cw06Gv7/AFDKCOdzzN/PWCXd2/zWaND3 OmZScseTOeOjyRzDNCjxLvQ6P4e32jk6Gv4TtC1/XtMf1z05NC528+qgAo08blRmIvJ384kuD2x/ k7nu/wA6dWSg8VqvdLY6IHahS2X6ValsDwAWx8r7obr8P3LOrfgi1kLRilenSCt91tXpeeMMK40U 8mp5n1xK8NllglvNgn8PrWUDFo9tILZlxFLwaNfq+jUJQStg1a7v69MsDYUtjbDQpgRo4T4nZTU+ vmIw8w8wDwJ1GH3S0Xd5/wCQ8SneV6IvOeEShiTT/Gl79t3EEfkOzn/fYhlOX4vaYZig9Sn8Pmd5 Tg0/jQhrfvUIFd244NI61lY9Pz0L/JbEopK0KcVuoq+OCCUHj9u3Z1YBrV93eZiMSjIG3z+P5Zc1 M/v4hLaXjyckSsQUS1en56C/KzfZ6c+kJ6X5/j/bl1mvvDFQA/pIBjR/cA3VMBAW5h05+t/hn+9B oMABQf3aLM0KPL/wX//aAAgBAwMBPxD/AOHysp1i6JyTgJdt1lUX4K8AUjLp+DNW2z46qhJZb8Ds 92PUn0eefbqu6GLLHwNFNIQslv2dTTEoFGkUVlWstWlj4Kuprs3iwA5JqEN+0UqVlbTBKz9cdQtE VYIQ3HF3anJFnBlYxS1+v46imvVzHLLpdGFko728I6Mz671rvWnn09NGMBZvw3znJKkMUUO275Rt BTjX329J3z3348/np7+0V7/8mWpczK2IBLIoZksH5eD7/MJ3fjPrtBaujgx1CthzcRXzEakwqhLU oyWafk9vljFLX69ozL+/T7FEYg0l5aTDk+qlyUR18UHtB1hbwrp096xa4PNjsHLvBEBxAaRpG1JG 4qRuQt4al6dMVrb9MG41il8CVMEXNiOSqodDvH3PmvppAxawrMmu/wCOmp3wgo3ZeXLsS5XkQzlW idn88QQS1L1vYdPR28pk6d6/Ok9XPTOImWiASH6/2ef6jV7WPgbrXj+SED2phBfrzmXX6rp3bVSx qXoc94yLK+NRZbqF5tGoYBz5n/Jjg+f304IUuXJ8aNUuAX7Rcs34lIxANpq06ZeJuvgEHqgH7j2g U0HywRmDRCVv646TLVH18RKtueTmUeAuABwRpx77/wCRFvKP3jvBDI5mZOOWv1/HRoqNZoVL9v3G 7LuPuO3aVDqafqVNZTFavBzEK3oSjFOYfTeGjw313/HRaRpzLz831tDNc8xbpgmUtdvTJ+vKW/xt eCe0IAaAHxEl1Lt6/joUz0QK4ggnXvLm/oRUK6FfyrU2cTkuqfMxCVFF+v46AcnXBLsXjtE1UWv9 QqdcnnFbzOgT02Ps/L+9FZEVv92rBNfn/wAF/9k= --------------Boundary-00=_69XWAOBBH7466DS2QL80] Content-Type: image/gif; name="April18.gif" Content-Transfer-Encoding: base64 Content-ID: <292E81F4-CF8F-C32D-DA16-9B0C49F30FC2> R0lGODlh/AC0AIfoAAAMAHkACg50AIeDAAAAenUDiwt0iLrDycbQvarK8UQZAFQTCYYgA5odALgR AeUuBQBCBBI/CzY2DFlDAINOAKpODbRLCNdJAApRDB5XAEtqDWtsAYpRAJ1gALpkC+hnAA13ABR3 AU2NAGWFAH2FAK6FAMd1DdVzBAOdAi2fC0GfAFqXAHeaAJeWALiZAN2XDgC2BCbCDUazA2W8BorL AKrEAMO3A+HEAADaABHgADvYAFfWAHXZBq7cALzVANfoBgAAShIKPTQBMW0LSo4ANasAMbsORNcI RwAoThorS0wWSGAnSXMbOaoUSbguS+smPwRFOhJIMURKP2Q9M45ENapLNr1LTtFBOABhOB9rOUhX TWthS4tUAKhdQsNWQ+1UTgBzNihxNT5yPWl8N4aOQKt7RchxS9iENQCgOxSqTjGdRlqkP3arQKKs OLOrN9ehSQ3CMRi8ODnFNVezOozDQqC5Oca3Ndu3PADbPy7eMTXuSGLfSYTXRpLrQLTrNN3tOAsA gCMAcTQOemUAjYAAcqoHc8YAgd0HdgAUfSwtg00WhW0egXshh5EqhMMsiOIefwROgRVDezVNjmZK d3E3h51Eirc5dedGdgBlfitkiTVjdmNujI5miZtkjc1edOxVhAVzhhyKhEF4dVV1hoZ/fJ6NibyO f92AfwycchaUcz6WgV2Vh3mhipSre8WThdKuiQDHeRXBgDW+jWK3hnLIfqrMcrLDceq5hQDhhx7e hjfTilXjgHnagaHXcbrXdenddAAFsyEAtj4AzVEJto4Ay5gEtr0DvNsEsQUWziQlxDYRul0ZvYMe zZUjy7cdveQcyws9tBY4uTk6w15CynVBtZM0yc09xeZAugFayxVTyEFTw2xcvIpSvqlntrpetNpU wACNwRN/tkiHvVuEtnuIxqKHt7OFyedytQClsy2cw0CStVqsu4ibvqiYsrOVydypxQC4vSrAxjHM uVjAxIjHtZK/yPP2+6uYrn58fv8ADQD2AP3/DgkA+f8A8QD/+///+yH5BAAQql0ALAAAAAD8ALQA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECMe/EexosWLGDNq3Mixo8eP/ySKHEmypMmTI0GqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSD+iXMq0qdOnUKNKnUq1asmkWLNq3erRqteFXMOK 5fi1LNWxaNOqXcuWq9m3cOPKtdq2Lsi5ePPq3cu3r9+GECD8FYgRjGEwFg8fphi4MQS7kDsKmEx5 JgAALIEA+am4ImKKn/+Ftiig4uDTSwkQIKjaZOuDwGLHZr16KjCCt+3V1l2RQEbMkYOHRPjaID9+ Ao8PvMzcXnOBmqMDGVi8+m6o0w/uXk3RN0ZgwoMn/9SMkLw987pbq179+jhye8qdA1g+X+Bl2k2z G5Q9W+D69fYxdx9qBI7EX38BDhjggvIx2OCDECp4nn4o5WZQffYJZCFuBXbIkEqaVSSgRap1512J /1wmInCxVdQiRSryBBxGM6ZI0WY0hqdjRyimyByJJwYJ44wxxujjij3hmKOIMP62o10JSSghetBl Z555Cir433USQoWhjf9sySSNAtb4ZFgKlYmhgwwOOOCW10W5ZpcoCejhnU3BZKSMNe7JZ5nyAarm mngW6hCdhiYIaKKMPvSSn2cG1eiklBoa6UyVZqppVZd26umnoIYq6qiklspVABot4NJI8ylQkKv2 KP8gq6wQNXAQoQTNOmtBARhE60CwnraRrrJ2VCxRql7UwLJBKUBRPhdB+48DFlHrUQDYmhbrrwf1 etAC4BZU37i8+rVRthShC5MD7LJLE7bwXmRtRsQ6+w+88X5k7z8NaGtrrLk+hKs9DiT0L0LBZuic wgR5u9dG7lIUMbEVHfsPuBhTZLHF/+QjrUr99pvRAxsle9G+K82I8j/2zjvtRQolDGxC7bJr0AKv CuSqzAMVXCC3vz4g9KuwLmuQxwMhDSzPC/XqcM4IPT1zRHOKKxC+Ujd90MELcW1P1veNS+gDfG0k 9Nkka7zyvajyK7JFg87ELL3n4ltRzS5z5HLe1pr/qZK1UDPEQOA324Oz4VYTiO2tuNq8rUGON9UY 5A75XC5DCRNaH9MNMT14Q4R+TjnBAlkukOinMYD6QBRQYFDrp69uD+wC0W7S56vLjpDurjOEQeIL MxxR7wUJRthFFFiUvPIaPfaP885XFD1WCQV2EAooGITB7xAShP33BW0vUvb2kG8PZZMVlNH00n9U 2kXfW8T+R99jX1H9KLS/4p6OsT99YBjBAFsAiBF96AMjOMDB/iC1vvl1pEweed8/JDjBJo3JIw4c it9wAgNTAYWCHBFgRRKYQILYySH62BRCjKfCuAgALwNzClLy58EabvAnVWFhC3cIF66AsIaj4iFq /4BIRFEJkYdFTCJOjkipQcXQQ09kohTFFcWnIMokT3zPFKVYHPo8J1BZWlSaqigRMVZpi1O8Ypsk FB/4aFGMYmxjGYNnNTJKRIk+YYgaH0Sl9FCnNtYZSB/3uJD54Ipck6qhHg+5qC6F0UFaitNJurQd NErRkRhyk+YyKTY42pFqYTyhJRPlET8V6ZQXOSVwGHgknKxySSsZ5cMe6Dc1DYlMI2qlLk15Q5W8 MpV4DGYpiZTL/SHpUcWEmzCXqRFW/qSXW5HlX8xolk9K85rYzKZZmMnNbnrzm+CEkjbHuZSMtC2c ONRmsA63kHygBJ1a8dhK1MUSXX3kbfPKm0VIRv/OHmokX+miJ0icmZG5tYRIpaxI2ozFMo7BEyiz skhE67m2jajuohURqEb2ta8+tY9hGLoofZbTTxg+R5T9G0hKZ9c7211UdQSxHZuqp1LWxXQgonPY 51hoPOLNzivcTEj9BDJUg1jvfOlTqWCOag/xCcSp9mBqRLZH1YG80KoD4V5UB0I+HQpEh14taVQ2 Yr/6/cN+GCGgn6gqwlu69XkZjCBpKKLAEervrBdsTEUo+EOxfiV96ENqVtnKvaQOhIQFwR/2lDqS FA7EsY4VSGTNBwOuGoR8lR1IZv0qlY0YkCKf/UdoYdBBipCWMf7Ta0VOmxG0HvOByqwgRSZzvwv/ vq+tIvToSzjbkI3QdoLv+y0BVfvbvZamuKz9R3KBK0ECSgZ98gNg9CQowbaStrQPBYqcLoSh/hmP tAVJqmFXytvymtdc2U2vemly3va6953rRct7OxtfiswXLPXNL1Hu21v9YoS/AA6wgE/i3wK3ZcB3 NLCCF8zgBjv4wSxBsIS3COEKWzioE86w+i7M3vtyOJYaDrGIR0ySD+eExCjmrIlXzOIWu/jFMMZj imdsD2HS+MY4ZkqMF5xjqMhYxTsO8or7KeSW9PjI2SwyWZAMESV/E8FOzq+Ed8zkPCWxymP1IJa3 zGVtRhnEXfZremn85TIrMcxoTjMTH6rmNgsYipxunoiD40znOttZLmbOs573vKM7o5HBfg60P/mc kSMTur4BZqagF13eQzv60ZDOs6EjXWBGj5LSQ7H0hyys6U4XytFAhvGUMU1q6nmalKUudIo5fOok p/rHrY61rLH86iCmudbDuTSuizhrWaLzzpXesjd7fc1DE9uSu062sjdy7GbreNlE7HJAAAA7 --------------Boundary-00=_69XWAOBBH7466DS2QL80] Content-Type: image/gif; name="imstp_usa.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlh4QFQAOYAAPONqgllpNMPHQWvEqKgl5IGCNuna/y2Ae1GYc5XBf7+/vmaBPruztPn+9HQ x1xaVv/yAP7G0u5uf+cCPptADv7TAHciAf2quwUFBe7KhxfhlBtTSv/7m+r0/QCh6f/2daWJT3pW LXb/zX99df/63b+8tfLYp/HivJYGRQBzG+no44rG84KqFgLH//3SMeiBQNPtqc7I2f6sM2yo0bz0 /v/3Ms7/6fvb4w4lgcDc+qamwd7d233k/hWcfOV9BPjx9O325r3KPO/v7EyRxdCmAv///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/ C05FVFNDQVBFMi4wAwEAAAAh+QQJKABFACwAAAAA4QFQAAAH/4BFgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uK4ru7y9vr/AwcLDxMXGwLnJysvM zZkrOdHS09TV1tfY2drb3NYBzuDh4uO4Kwrn6Onq6+zt7u/w8fLs3+T29/j5nubz/f7/AP/V00ew oMGDhPh1WMiwocOHECNKnEixokWG5wYi3Mix4zKFF0OKHEnSYkaPKC9hWMlyxA6WLQXBZLnj5UwM hW5i2DFJiIMiDx6AsimUXFCgQh/gTLSigwKIMBuuXDhVYlWrGKRmLcnw6sWnGlOKfYSBQKGXZgWN wFCiCIaihP/QKnqLSUjZUWuF6DuqVFHTpw6rXvU6kfBDr4ZHJp4IdqxjsmkHyR2EYYRbuJLvJqJ7 aXKotQT5LkX0t4Fp04i3Lj59ejXqra9Zy55Nu4Fr2o0f654bWZBnt5Y5x9WMSPggAm9XEkBeWS1L sy2PAl35QC/z5i+VYtjA87rlQWtX7nCwgbreB+WzqoX7wHL4u8h5AndbHjN56jLTcy/Pvcj1DT/x ldRoh0CjgGwr1ZagbRi0xpKDsc22YIQMTgjTaxY2WFttB4a124cywSSUZ0q1ddOIN31H2UxCISfU Wi9mtVZbStV011FrOeBAZSU0hxwBL20gxEsj2OUeBj+Bh5P/XULtOKB8guyo10sOzDjdDvHJFNwG hTBZBJFuIWmTA0QaWYSTSKXZF1MNHMjahAhquOCccjYI55s6RUhnnXpquOFsHYIoKGW9fXlTWsb5 RtwhifqHpKM/9bjDBnBVJtdRlBICmiDogZnmdipqipMOOzknhHSENDcCl5lqmeV8zRFCapKgccYZ qpwmpet0fuXgpjR3AstnDsFeeA2cdEaTrLLDBqtNoIMKuqihZu0opEyYKVpoTtk62l2pksZ62aVC GYdqjZodVYJ2D0BZBGibeourWqwGp+JbrzY37XUsXYZtrmcGhZ+AvDLlKzUrHYsBswwjzBI2CQvL LEwNEztT/8XdKJCDh9E6Nu1kaPp71rTcGpJllpK2Chy5Raj87midpouZi6J6a+q81JaqMo+lmrmv eqkWdWu7b7WbKcFrknbwNBE3HPHTCztsscJMR920xBhnvY3GHHcs1sfEraWDyMNtG7TJpaK8k5VK /dQcjkgy2aNlyLkkM5ieOleEl2jiPF1RbCO5o2VKBVeol0JkamtRQSH3E4xqdlvg0lVXDLXTVi98 deVYXz415t1Yw7XXH4LdW3k2zQSkTu7qtFza4Jb6XlqFS6ddf95RC/B11dV8Znq9+/2jkso5l5zh hty3HU+LA8xuX0gTaIiB1lDcedQWN+251Fhnj/3V1n8e+v/opJdvPiNSkkN96Oy37/7715B//vz0 A6w+5fDnr//+1MhvyAQADKAAB0jAAhrwgAHsRAgWyMD6OfAQdinV/TTGvwpa0H3+GwQAEYAAAADg AiAMoQhHSMISmjCEHuRgAhnRQEQskAEwPIEMQ/DAGhZkfRfMoQ6z4aEJIEACIIyAEIdIxCIa8YhI PCIIAYAAAC4iBDGkYSFeGEMZWlGKNsyiPQLAxS568YtgDKMYx0jGMprxjGH8XweTyMY2ulGJEnBi IqAYRQYu0ARVZIAVTWACLGrxj4C8hQ8v8MZCRkACQ0QkEj0IRzkego56zIAkJ2lFPfYxBJLsYyA3 yUlY+BD/AG2UACiJiABCIhEFo0QlEiWAACReoIlzJEEMKcnHPWYgBAYwQAb46MdO+vKXogDgKNn4 QyICAAVsVGUElGlEVibxAo6coiwtWctqzjCXu5whMLfJzU4M0o3FHOIxk5nKYRbRmUmE5SOnucd2 9lGX2bzi/CxAz3ra854W6KY+MzEBRbYxnEIcZ0A56E9lKpOJazxkK5PIygmss4ru5GUmbdnLaFlA ADe4wQkR2kR67vOjk5iAOdOpSACwEpmHRIEEJICChRoUlMf8oSrRucg4PjSi1ZykTrFZURBZIKNL 5OgEBEDUohIVgB59RAI4mIAEgBSYEzDlP1uKgpYiAKUq/02pIl8aAQ4K0as0XaVDDUFHnO40l2hF a09389MLeFCoATSqXAUwgXw2ggIrXSkC7OpTvj5VEiJ9I0FHOc5jsjSrQuSqMp0ZViOadKyEgGRO J6lWO1r2sh+yACE52kQBznWufk0EBQwgAQNcQK+hHQs9I5DavzoisOD0ZwQK21LZLrOctxUiYxe6 SnVGdpY6zUAuGTjN4hq3uC0Ui2Y/yMHODvCzoGUEXksrQ9QKggLYpQBKLBCBjLY2FmgMbxcRSN7y buKbbWTmbLFaUlVy1auGFSxkB1HWsxqAiseFoX73y98FpmS5pVQhAaEb3UVYgJVAJIEJVpoACoDA ihnALv9HfnqDCPzgu7AQr3jLy2EDnhe25DQmSo9ZVcRy9QIlXuhKnxnNIly2nsTNLzWtac39rpUg AA5wAQlcYEVYYKk/JORpEwACDhg3AyDQrkF+amEJ7EACGHZFFxfiRSpPuQNVxvKVx9vhLq9QE/2U 6ioda0xzDtPMZibiZdeM1he42c34Zac7g0vneDLgxvnI8St3zGOjRnkQPyaokBNgABJMlAQKMLSS cayAC9wAkTH48ye4tIgtW5qLVsa0ljXdxYDMgxMABKIhR23IO/JxotbEpQHeDGf+zvjUdE4rNnXK y40sF6F7fm6f/eyIQAfZBAgosnBzeQE8KhrHN2j0o53/LABJc2IDlFaEhsPraXl4M8ykzjYbQwDr Ot8yl6yO86u7PWxZmxueu8QzOXKsY137GZ/wLoCBgQxECTh42G42rRUXfQ/N/sDRERBADABQAGcX AtqSEFK0EwHGTAfA4RDfdKdHgA6KV1sdntigqLXN8SHSkbJp/TarE8Dt/c5wzQs8t8pnrW5x3FqF uY5rUet5QhIKoOCJ8DWDQSBJcLu52LLk9zi4e4EfrHQHBZBADApAAYMTAtoIb8QGNGCDhSOi4RKP eJa7OIKuU9zrCihS1wE4Ai8LEBQb/OEHa852ERbRhAAo+Z3LPdwQvJnkcochAxfA9777PeUgCLzg QaBy/0m2HBzsjqpzh9pseqIwhQIeYAdDiPND+JqDPC/3mw1gbKGH46cAEAIABPDkAsSgBAXQgdMH sQERiCDqiZi6Bl6/CGhPO4xgX8eQVMD7mjwAgL83ezDNTt5SDhGaB5R7ymVtRxnqd4F+X4Adoy/9 EAz++uY2fEESH/PGPx6u8K7nJ0H43UALIAEsyLzP8110IHi+GRY4ByiFIIASLL0AJUA9AJKac/5D WwRVB3stA3UEKICCUIC390Vdpw67VxMO+IA68gAOEHxd1gyhZkrQpAh5B3iDt4EhQH0hkH/5ZwHU J33XN3jZd3jw51bNpXhIFVRv1YL0JEscQAEFcIM4WP9wFjB+5ZcAE2AALMACurR+7HcCJPB+ocB/ gLZ6RRB/jeZkCCBwElAACFACo0cBAVBPludmoTV1ANgBBOh6AGgDZKgANvB6BfiFXHJpD5d1bmhx T9F7EAiBOlKHDnAOD9APzrBBm+VbjwRJd2ZZzxcCJEeCfReCIjiCB0B9FmB9J0h4zLd9LNhZe+ZW b8VZdWUBEMABRhZ0OZiD9DR5qeVgBZAALhAELEABPcdqb+ZoJ4BdTdVUoEBPPoAIPqCEPhYB7VdK BBcDMYACSRcDO/AAXmRPgMaFhiB7rgdtGtCMzuh6ZdgBVSeGGhB1bKh1U2ZxckgmdtiN3Zh/QXEO OmD/bXu4QR7UYmQFiP31gQkggiFwAAfQjvbXjYbodw7miCcYiTjGggEEg5y1V/SUABAwkNlFAjX4 iaAoioVAARwQeDXwACzwAKooXKz4cxRQARUwkJzoVJ1gAbW4CLfYCERnYVF4f6d3g07GAzywAjgQ AEMwBFxkTy/wXcwoe9VYgAU4e7K3cAnIRRSnAl1nh4lYh4lYlOD4ADowjvAgDgXEQuoIfQuQAERZ Au8olXeoABiADvXodxbwiIGnj/oAYIrXggFkT1ipAAIJARSADglgkDaIkDe4g3u1kJIUhNUBAxK5 ihVJAQsAj/BYARzAkZqwen8WfzdgUkIQAaaHAPhX/wJRKAAI4AEuiQMz0AErEAAzMAMxOZOxt5Mb 4AGg6QEbUHWhKZqtZ4A9qY0OQABBERRG+ZqvGXwogECH4APZhU+VUFWGkAIDkAKEwEWgYFk+wHdW uSM6QpVSmRFnqQA/5gOL2JcL4GBeCYnDxQm2iV24SQoAhlBlWU/pkJUBIJBrmQ5teYvhp4UL+QIG gIoPBgLrMpGrtpfZRQEaKZiXYFfXeZvoSQhR5oSHBABIJwGohwCnR1QW0JJgNAM0kIXIiAhT93/Q FpqnWZqj+aCFgHVbt2VF4hMlsBxCsByt+QCwGZslRl4L6QOdeFy2iWEp0KKGgEzHVAS6yZsDMABe xP8DLdA1m8CXxKmcWakAhIgOkukB5+CR2DWcz9mVXqlWO4qiMraio7BcyGdPizieQhoAHtBg6pCV CVCDkUABPrCe6UcED0ACDpBkevlmtgmYHKCRG6kJYJqi/AWlvZZsCiABAicASneD9jd6LTkEChAD LXmZCGoBnImTUFeNoNl6ztiojdoDn/mgiDqpbchFsdhgFHCcHUoAH7ocnjoCHTqiifgAJTabHnZd TmqQnPgBEICRrhqd35UCNtCivikIqORByNRENBoAKsmrLSCZwAkKfHkAFeAD5zCkRboAxnqs55AA PpAAHpkAFUCsFaCkj3hfKihdTkpPq/oBH1AD9AT/AbCahORHTxk5kNMaleqQpdH5nQoQnhnwkZCQ AOoZeAcAAjAABCUwAvDJarbZl35JrANpn5MQpwwwn976rTWgltnVaxYWcDHAQTFgg0q3AzrQkgoa AJQ5A5NqAwtBhstYjRrgAY06qbK3qNUohmQojWhoe1/UVBzwAS7gAvCIXfnnoZ76qa05AgQgquuS lEnZDteVoqu6sAPZqhjZqgvQWjRao7QqowjFRCjAm7xKAzmKo76ao5BAT0q2nwtJrG26rESqABTg l8t6DmAKrfDYqtTaiCiXrdJlZLQYs0Z7tOZZAUs7i+Y6rRm5os4Zj+RZs+kwpAmQAV4KCWDqZidQ /wMU8ABBEBRoSpGsNp/h2qqBWQkMCUNWSrZHq5bkKZKiFKCoZ4U3GANCwANchKBeNAT/x7KOKrI2 eZMbQAEqagEb0APOyKi5C3Vj1JbeSrMBW60PQAAF+KnL4bPrgpRA6w5FkLkG+QExe7R766oYeQBM W6M1WlXHJLVXVVU2iqMtkKOgGb6S+QgeCQFH2IQQYJuHcJHRq6zoMKzP6QPPmgDKagEXeQBsi5FM WLByi6LR27mde4vT2r8iaQHVi5HmaQHUGo+xGLAJMLiE9gLp+6U+8AIS8AEVwAJEsAAsAASRG59q GqYnoImuCgEE6wjOu7loS5DrkMKWhwA7UJJMF/+xkKkDQ0ADQ0CZHbDDTcGgOFmyGoC7N0m7MRuz 3loDRru0t9uMkroB14hlvjuz1ltPftm4OUu8lHK8+aepsKm8QcsOtEuDAXy0/IvArkqs1nsINAqj HFSqMDoBWFqaRAWawepj+cTAgKldmljBC0kC3iquUYldfTmtz9l3t6i2Gcm31WoIOAinsmQBNZhd Asyw2AUBCLzGnoDGxOqcA3m+bLuIAbuIEdysC+Bmfoy4L2CKHFABNAsCOZABeSm5atp0rdx3gAnD irDC7tqsVvqjzcoIFwUAS0e69heFOJDDOIADKzADqsugXZiokAptR8iJ8ynA88mM1TgIUTzFh7z/ tPVovTybxTzbxUJJonBMQM7LiW1qxouMt5zMt5pcBF80AKjUXChAAhBwAPeMAvQ8xwIgrgJAA1jr Yz5QAU0ItnxcAR/wfgz5AfDorEhKvX7Jd7dIeHpsyPwrCDdYBAUAmYwpb5aQuZK8ufR5tJsrkJls wAaWwOeKyT+mv9XrlzMdi3y3aqmMuJiqxBUwAjkABAQQwpMLmHibXcSqy4jgvCbwy+/qy+cAnmwp aRc1sQIHjKaLAM/ckjyww5tJk5AKqdXc0Olw0p4bv7a7zYJARt78zdQnzl7XdT07j+eMzlWlzp24 qp1Lva/KyQuAkXkbAOhgtQFgz6W6z1almwFA/9ABvYgCAL5aiwh6nNB73IQM7dCAfAC2ab+FPNPK ml2QiMYa3chUOIVERVBTiLl3zdScW9bAnADUmrecEM8vbcXoqteGPMq6lNOIW9TYFbM8x5r9yoUA SwF81LCPoNRLfaVjq6UKgKzNGpI+hn9Lt6cCcLpcxAM0MKSSWZmGypmHwIxgHbMszLnj3XSwp9Yx m64l6HeY7QNG6Y1ebJSkWqIC5AOR3M7ubNvVC519XQGdRgNWm6PZi1Aphtjg6wECsAACML7hq6OR rcdeisAN3b6XzdvzeeHHGwEmQACc/JfVeoM/FNI4uFIiLQn27ZboANVoOZ4qjpbUioSV0OGzzf/h HqnfFH0AF5kB0Avj0jWtFxmdFfAAZEoAI6B+bnaL2KWeeMTjFG5JOD64bGmlY2vKTN6EpkdwUCgA KMBFDb7MKECMLWCoGDZ14S3WKR6/Zx6/sPcOCSCzbL3eo9zePkAmdOgA8v2zYRy/covfSOuq87nf /L0AgC3Y4Zuj33DPV0XgNUrPOCqZPFCaoengxCrZXuoDE96+DM2qeMsBS5uzx2mEMEQArxjK1IqD HHRzRvVDp/2lRsYBEYYOXLTc4xnrbMl38BzbM520mMzhDpBdABvnmF3jH6DbSrXPDInjNPu4QYCX wX3BL3DBnGcAVT4ImctHhlzKgVsB2M6Wwwn/3T4mhUn3AwFXVDcoV9DsoCIwxBuQ3kwN2GT71E2N tgsQde7QpTS73vjO3pj9gA5o5/INtHmuAPYtyXlNvSYNj7bOd4NutXakAJcpoxNQVV3lz4s+x9cd RrT6tNROrGBKrIx7kWqZ1CjKquhqzQygex56sPtM0weAg0SVg0Wl6iXuCPbt6q9+rFjq1M2d86Zc yNNuvjMtsLtuAXT+iud5kdI67D9/CAKJ4xyA4wbAuF2Jl/yql/Tr7LpkbyrMAOl929vu2mr89c85 zz4mwwRX3edwWqKWUXja3TSp7un95OeQoy2AtnMfAHUv7xZa7zKb734fnRG9jePh70UJxmHM/5Ak iN96Xd4Ij/CD3gIhoLQhoACCXQQDAPG6WfFcpJwZgb3YawNOy58NXNsZCeMUEMi1XYNZ7KnncLAZ Kcr6+9EwL9Km3lwdfVdGJkkysLlTztzNTZ58R6ywnQkdTq1Df5VWpCM5K8ltipEavPSG0KU4buzY Bc94CdxW7+wvIElJFrcM8AF++7eXeuOXuoiG7O0+NgE/8AOl/Q5iju49AKka7OPpkPfvPvfAP++v d0CmCAgyC4OEhYaHFIQ+KjuNjg4lkZKRDyiWKBMTFCQ+HBAQFKEVowkKpgoYp4kLBwcLATQtLSGu PiEKsQFFAwEtsAHAwDQ0AbjFwwEDysvKKf9Fz88WraOfB58+PtDa0QWf3hUJDKfjpgwUFRCurBUF AgXv7gLu2u/12/famxwZGa2l5D78kVOQoNAoC/gSKoQmrUKraRUoOKBg4cRAUycscNiI7gMHHxQW ikzAAV06Cy80HqBQggCMDA8o8DPwoqaPmi8yvAAhssimDz4sCGX18OEodEePFnWIsGcRCwJuKLjg rp28q6ZQNr23QUOPDR8gOHRFYWCisuRWLei6IZPbtwlcqCsUqq7du2pbCWH0CNKkEg8oWXKrr+Q/ BefAnSqWSoGFQa0GBQsBIEQIWbJ0BeDRwgMPHpt9mSJW4tiKZM2WOdsm7YDJdK2w1cX3zlv/tU0D GSQ4lw4yvHbw4s1zqlBfv8iHFQR0fSB5QYMVthIXSQE20YgOdle0eOrECQIaS3768CHkdHwkIXA4 ILTkSpIkWDwAYWEmzvsZQJgvziDgp8djTePaa7YptcBB00ElwSk3XHDDDQAg0A5KKeGzgQhegVWD XBAMkpxaaJmSSAWsbNCDCG295VZchoRyyIuGHJDBXnw14tdfDzwwwgiDacLRYamcc5gHAXgg4gK7 +bDOMcP4EgwvnHkgD2ZEAqOAACRSAMxpqDWDDwXLoXMASKGMx8k97xCoHgXhMODmbsypE5xVBRQB HAISnvclCftUoEBkoWBjlCu7sTmIAqwc/xidniI1pE4rFJyQgHZCVVopR7YFxeg9JIkn1gIUuLAA ByQQ8AAQMdl3X04G7JfQT95YENAoRlFj262tiCVdT0IJgMAFETzIoABaJXThV+SJFdkgdj3EbF2F uMLWRYiJSohaMMLow4w01ujAjZI8oMO45CIm1mGMIZackSK6IhSYFcCCmS8pLFOklCRAIIAH/MKC iwALgDQaMl4m1FoFH21UzUOuPgOcrR2uV2gC1jj7DgLyWDVPOxJKUOem0PyUgbLMrifrrMsWwg9E u4Kcj3WsRCoppZZSoHCBDbuc3qcUgPBBBRkoABMJMIxQXwY04ZdBztvYHNYnFCma1K1Uw/+mK6O9 XiWPVBS2XMQGHYiA7CekJKAkZESlfIi0GqB4EQWCMEtXpXid7c8i3XoLbiQ6iEvuuNUpZgqRRlIw 5kDPpaD44ikEAwwzygAjQG/7+ksMmAI8AMswxAywmsHTeLLwu6GgmXEBSHWo3kbrRXYxnsINVwCe EtT+jstOZ0ArpCcJuntRzK2zqMv4OPooWpNOSvfN32hKvDYJiJWlAUDUIGMFDzhAQAksyKTqCwYs TR0DT0NgQQINQVz1N7kOj7VQN0jgzgXFWojh2Oc+ljLwaj+61okbeJs6VkERC5DrAQRI4PZKEIrk VUAFedMbjsblN3IFzgfjYFdiMHgKinn/KAU2gJwIB1CXF/DAcAsQAA+IYYx/GcNxlqDOrDzxEK9t Y3Z4SpNSirIAeOAJYxobjp1oVzuP3U5PP/lZgKrDHmwkJUBxYtnzineguaxEAd7JIgFsJjqykciG OisJqChAABe4wCEsAMEIQBCEEXhPVeJbiAXIFyvtyeqJeITU7q5GPEt1zUJhy9DTlPSYtEFkhzys oolE0IEUvQWFY7TAJS6BQAVK4luOgGAEbbQ3wFiCR5jQhFgMwMFTYOko2JhUZNylOMjVRRkUeAEC AAAACnSmF57xgOZ+MZoASAABKFBABIDZqEAVEIz08BXs6sHMeihzmVr7GDRw+MscbiqJ/16MCASC 4kehTC1ACJriPR7Tm2th8Vvg8RRSvihOTimrgSAgAhEoYAAQGIAFLDAaPfnBT6ZpwwIVKJ8F0Akt /j0kKD4YCx+nKJQK2e9+YPlGRNL2TTwWpGImapsjCTPASU6ykgssASYzuUlOdnKSE8CE4chTgVIC LI9qs4BY6gXLCL2AAiQcxAtq2S8q6aIIViJGNVEQgV+igDgN4YA/kzm7av5Qa/L4ITSjiaZmguwc yfKG4V5DHvJw4mTSqxUy+6ioudhFJXhcwFiJl56QsAl89nwAPvEJA/1YwADhi6NCZMWBp1mAADtQ gPa22E26/e4k4myoQ7cBNrEJ8lYTHf/Q+tABqlwdIKOM3GgmzkIBj1LSkiIdqSZLyslJBAalKQVT X0mUAHlILSk8dJf0FEcBALxAUbypgCwpUKXOeMAX71AcMIxqCQQYNUGuUapI6GRcp0r1uVVRZsba eY9A9VWrAwrLE/8TsN8xZ60uKyTJBsG61g1oEOBlawJCBr78bIAFBBgBB0owgtpZoGdLzUdWKbAD ApxiB98abAIfUxIogkKcZOSAUOzXNg0IsnxaTR8eR1HZXJmoB21zW1pApYC/lQukkcBkBEn7LdPy rVwdpkCyrDgg2PJQIwEChW0XAAHEvABRoQBGNxxHtgIoAwXAVEA6LnGepObXTlchYhH/l7xMq8Bu utQNWUlUXL6tQuAD/MPGycZClANHeZwjmvATQZXeKMcSryzIwAlGAAQ1SsAAtUOfU2Sl1cAm8CI7 4KJ3mTJFm1nPhhdqcIZ8sL6VGM6gbKrVhb2SWbOUxcOnAHFoRztivd2IgiX42ynoDJtaPdFZavXE WBxCAQTcNiKICQXjUDcIH7C6hz+2RG+ISkzkIiy/QVQyAIqIMag+VYhmdg+nQTGg2HDTUk5c1ne/ bDD9TZgsZWb2mfkJgh2MYALGvQCcJXDkZ/BGLPw1hQLHvcUCr9Ia3e7JWYQiZ8aGDcMO/opM17ce MtFtqwq1QA/23WANjyNEmjZFJUPs/4BGVPoHmwyMJHQwgkyjWERIeRRMPQRjhzjEyyWMpW4pQFNW JyBNg/BxMIt6iaLWGqmu8bJCcv3cXmtNqlA2M16aNTUI1KC8pGrNo9DNbDkWtlI9R+I++5kAPBng AiaA81rvSLZwU2sHCeDyOtjzvLMogIa7aqxjHWwiplcN5xJVB1P2De8TNVJFb7mEWyQt4m4hXAin imD2FF6CT3rULXd8SAEG4eIe7l3Ug7qvqWmMGCEv4KbLqEe+9v7xARC1dsCU6lGLnHJcxw6qvoY5 sMWJDZx7XnRQ3O7JILPsoJv+9D4ZugWkaoAHXYDbvDpQ0xMQWHLkGdSuUWvVQaFz3f9ro7En4nqG ALQ+6f2OEF8ke1cYnVm0u6VHE6hkwzF5qrjHHe57qX4jsoeCHNVd7SkNZSb0h6TzkX6AB1CYQ9ah +9reFlQvINECEIDTAXSDHZ+ox49NDsxJYq3yC0EnmPdy0LV5COZpYkYNUHRQo8d+0YZ6EKgnhUIR k4InF0ACSScBS6co70R7jrAb64F8HfKAxVMWCnZfLXMhjrVvXcGC5HQUEgVFIqhWZIdhXSE2zed8 KfUW0hdalYACbIZ9QmAJ1/cAjvCDQHh30Dd+rEVmfmQ4oOcK1uB7tWVqbnV4s4RT9xcw73AgsOZ4 RPY8DaFypnM6zhRVzfVkR/RlsmL/UG54FIUVMEoyhSQYgXaoJ6tHOxfweho4ZxxYDROTfoSQcr5H PIajc4jFWCKwgl/hFV+xAQDyaWrDd190YfyWUSfib9QicAk0AoJVcH4zAo3QN3sxLjuiAztghAzn YQGnA+TwFIPgDZ9HMuclHbPhba9kf/L3cXznaqnhOQwFgLTRcrCjZLVzOqd3TN1kF8txSAchhwnF Tnc4jUGXh831S+kVibLIOh2yDp9Sh9UlU0OBXlyxiMuXIRmyAZBIiXFyfpSlVpZog/CmghvgFAg0 As8gUg8ADaK4j0VwKvdghEWAj1hDNd4FGd1YZsqwd1yYAnuHDT7mOcCYWMJ4Q1K1/2QYCURrSI3/ RCbNyIDYQGjkyJEkGWWrx2vpxhAjIlHfwDPgWDzWYD4LxhUOpgHnWIPqCImRmIDwGI9kJ3xc5xQ7 og0E+Qz9CA3+uA1FuSn39VqIlHsUoScL+Q7NYA+p8TliWJHTRIDG9Wv2UJIlaG9+5ERZ8pJgeZbQ U0ApyRphllZRyYaRAUbneI6O+Ij1WClOqVYLlpPqyG9AaZPEsZT4IJjVmAgtZiAzySgT6SXAyAxY mZXo0DBBhHlfiZYGAyYhmZmEZJaW2ZmJ9XOc6XNjxZekqY7F000KUZo56Zl4CJrEw5iNKZEF005j mDPNZFWsKZqFlZu82Zu++ZvAGRycwjmcxFmcxnmcyJmcyrmczNmczvmc0Bmd1BUIACH5BAUoAEUA LAQAAwDZAUoAAAf/gEWCg4SFhoeIiYqLjI2Oj5CRkpOFK5aXmJmam5ydnp+goZuUpKWmp6ipqqus ra6vsIMrObS1tre4ubq7vL2+v7kBscPExcbHyMnKrisKzs/Q0dLT1NXW19jZ08LL3d7f4OHi483a 5ufo6ejc4+3u7/Dx8uUd9fb3+Pn6+/z9/v8A7TljJ6+gwYMIE06iF7Chw4cQAQ5USDEehosYR+zA mFEQR4w7Nn7EUGgkhh2ThDgo8uDBK5EuKxJqydLlA5KJVnRQoI/jvYv1gPITOhTDT6MR7RENyJOg zKfeMBAotHGqoBEYShTBEJNQVUVcTwmROgyrEKiGaN5UpJMnPqFE/5f2k5tvKd2Hd/s1Rct3GVmv fz2O2Np10NdEYU0dhoW170ybOBG1bUCZsl2keStXzmwZaWfNoEOLbsBZ9F7HqIkFFrR46+DEgK0i gj2IANeLBGxjGFwEK+6tF0fQZHnxwVndu4tsvIlhA0rkvK+CdLCh+NkH1Y1e7fpgsG+ytlG63lq9 MPXiHrM7r+68CPINK9VCZttAAeiLo/GTxrAZY//PoekH4H4CctRZgfyNNpp9TqXm4CofubTYTVqN JOFI0XkUoXthYeWSWVhpdVNIZNGElQMO7FZCcrYRsNEGQmw0wljeYbDSII2N5VKKkIknSIpnbeRA iMTtEJ5g5BWio/9yyV3kgEhP7kZjETzWZOVaOdV3X4IBJqjfl17yJ+CWIwEIZphmcqkgaAw+6CYr qzH5kVW0sRZnSYUJYttKexax4g4bdLXbVzQFSkhjgmAnY6IuNZchjiTpcJJ0QgxHSHIjbFCEoYId OV5yhEh6Y2OJJWYpo1fOl6V9tozZKpo5uBqrf7qMCSYtt+IKq6y9tPnmr6fE+VWKMHqUJ5OyHVIn h89N+ieohBHaaGGWjvgXTSUw94CPvZGEKLOnXqXpBq9Fx5WnTSbL4UeEGYuqAy2hJx9xbOWgwC0X 1YqBrvzii9Eu+dYS8Ej9zspRwcDc2yCwDD8i7F9VtkvVnZcee+T/kX9y6pq0mxb2raLXFmabx5FO 2m2lx1Y1qcYqTjplnJKeVbG7NS23raHzYimZvf6+2u/A+/YcMC5Dz4pwwUUf7YvCDTcdycOyYaWD xLGBZfGkGJ9E5E0rJWeijTquOJhtGoW86KKQFrFkleEmmtjWNqY42E2vqbukEIaWGlNLfXqYaiOz 3Nuz0T8HDTS/SQscdOGMNw7MLUw7LTkjUBNSnUhzYs4RtyblhrWzk35nFd3DMdcedMiiipxxh+J0 HlfXHcth1BhZ5RvdW6lLpXoo6Y2qtmvlHNkhgedysOJI/+u4z8jrOnTRxxP+eOSTV2+9MkCiVfzj 3Hfv/fe6UH/9//jkv9I2RduDr/767OMifiETxC///PTXb//9+MvPSgj891/+/6gYi8mgkr72GfCA 3HufIOKHAAQAAAAXiKAEJ0jBClrwghJ8YAP1xwj/IYJ/DAjhCUYYAgCaEIAFRKAKV6iLBk0AARKI YARmSMMa2vCGOMwhDiMIAATEbxEhEGEJCwFCEY7wiEM8oRKtF4AmOvGJUIyiFKdIxSpa8YpYlKIh XggAHXrxi2DcoQR+mIggCrF//DOBERlwRBOYIIlLjKMcq/fCC4TxjhGQAA31mMMHipGMhzAjGzNA yEIekY1vDAEh3zjHRjoSWFz8ogS6WEME2DGHKKBkJnMoAQTk8P8CPiwjCURoSDe2MQMhMIABMuBG OD7ylbCUSfwo6UUY1hAAKPDiJiOwyxt2UocXACQRR4lIUxqThKpkJQljycxmIqSOYLQlDXGpS03S 0oa/1GEoA0nMNnrzjatUJhJNaIFymvOc6LSAM9fZjgnw8YvSnCE15dnAd+5ylz104AyzycltDtOI 32zlIk/pSutZQAA3uAEG8+nDcrJzEQ59qCsmcE1t8hEAncxlHlEgAQmgwJO8tGYEcAnDTfIThxid ADeLeUw3FvKlGUhmQSVngYTykKETEIBOd6rT+EVUooWwQAR+ClRUTOCS8PwoCj6KAI1ydKN8vGcX GzhDqp4Uh2P/XGlAYarKrnp1pk2r6QUeiFP58fSsApiAOos6iJreYKhsNWpFc1hPSlITlx596gyl GtJ9evKqNkypIQRpzJd2FY2ITSxYH2QBOzLUh/NDK1rXGlcL/CACCaVsXClB0TDGc6S5JOk79yrS Xf4SsDXspEr/eQKYxtQA/SOmbGcrWw++qbEQbCBk6SfZyVZWAjuQwGVvoNllZPG4TsyfcperCmh+ sZeg3etFN8lXquLVs6slhBlbW8jDCpK2awyheMXLPzfh1pIbrF9vfctWC8QgjwpVQHGVgVzkLve+ 92tuZ597zXnicql65esFAAzSjgJTmEVIrDljC16WtvSQ5HXQ/3nRa7/1sheoB41BR+NL3G84sR5P BPGHOxBiEo84ufhNMQdT4U6kcvKG/e3vNG8pYxoqNrFdfYGOdVzEbm7VtTA1JQMWW5EJg7LCFubp fJ1pgQIAIAYCwOwFfnCBJadCU4s4sZabKGIum9jLTlSHNlYRvxji8cx4TKNLxWnMVBpgxzweL0DX 7FqvJvOlrXQMbvN5ZN4mWckYpkABNFyA4ArXjlY2xQawrIj6HlfM2WBFmV2M5krfMAR0BrKb4dzj OReWkHYOdVcNSWSETJjCflZyOlddACbroAAliEEBgCsAAAjB1oneFKMfAaNdIyKKXQ5AsIf95TCP 4BnHhnQ0Wv/BQDNb+tk2DmF3vYrKN+84AZgeLwlv7GZRe5uQpTbInjfYZ7Pu1JwYrKAACpBrhpkT ohYAAKxLUIBBl0AAQhipM3K96EU7YgMasIGvDwHsYhO7xE4cgcKPvXAFzEjh8RuBiuf3CgbCEILp zvgEbXhBAGR7yK/17rXTON7+LeDkKE85/wwAgpa7HATfRiVaTn3U3eZUAOi+aVnp50AJsvt6FtDx ks0ZAArUugQImDWUERDcKf+g3RsQgQj8rQiAa2Dqi1i0o6XYcGnESAVgD8kD4jf2icdi4su1JA2D ib+Pr9zOaBwheUOQ8gWgse52D8HL9x5qcEOF5uXGeWN1rlv/n666nFyMYLvNK/S2Et2J2yI0CmIg 69z+QAGIznrUBU51QfT78/02BOi3DkWFR+PrIUm96lH0AHiZPSGTnmEwFfHxIady77XnH95DUILe l8ACeLf73l/e93DHA/CQHTxZNbjBco6SA4Kut/TZbYHEL14eRBVE9h3/gnM2cQhDCAAOVsADHgS3 3rGu99Ivm3lGAFwENujA56UOfxvYXwE2mDro4S//ImxZ2AYXgMnGE2G3equHIgjoAM7wAOZAEQzk WP4USN+VWHOHbcCHcrzne71nAQeAdxagd8MHc3D3d2OVXkc2VsunWw1lAR/AARxATNE3ffVWTj13 fe5QTj6A/wg+sH1FEHQW0EQzMAMBoBMzgAPh5wEIoFMI0HsFwHQFEAFCMEk3IF+NYHVSt2gakIVa KHX31wECR38aQHX/d3AfNoCod4AJmIa91xLOoAOR5oAM9EAINljfJWe6lwC+FwIHcAB4GGtpeIEp RwEgAILDN4JPcV7yo3OPhQDmBAGO6IIvSALQJ4PTZwE1SBEWkIOLsIOGEHTdFwA0IIRRhAMHJQCx lnQlIAGFhlFQSIVVCHBWF4agB3pXZ3W7RnpNlGwFmIYJqIG+uIYPoANueA1PYT8dVIe6twAJgIC9 p4fLqIAKgAHPAIgpZwEh2HKGKBOICEqFJz/n5IgL4IiO2P+CkTiJlDiDL2SD4aCOPdiJnyh+Qyh+ MaAA4YcDtRYD9DZoEiAAUCZcCtBh/2aLG+ABBOkBGyBwBWmQUdd5goCLuph6zPiLEvmLZYcC+XMI PkABGplOpLBUhpACA5AChNBEr4BYPnByz5giKFICIbCMAxGN+5YAPtCBC9CBgniNIqhKxvcIGbmR 6MQK55VP3mhOFVABHcgBEFAB4QiOJxeJO3h475YQa9WTGkkB59SJQSV0Q4ADARCEXBmK4qcDIaGK FBADDQRlUAhXvCaL+leQC5mQBwmLhVBwCHdiD7mSE5mXGvgAAKZchUABPhCJtJWRiZYChmkIoYUC ReCRIDn/AAPwRDzQAguzChSAcgnwktKoAC35DB4QAB6wbz15kjRpjdd4WKoAmM43W+VklYSAAtOn mIWwVK9JCLjFdueEkkVplAuAlEoJjrq5mycAfQ4CmIIpZ4QJUd1Hj6PYRDwQI/UGAPSWiqsoAUs2 i/0WhgQZdVq4ndvZAwMJi9YZngCIcDOiEg6ggbmRngSgl77Il32ZX4JAnM/ngh9QTjVQA+DImoeQ AjZgmCIpCJn0QLnkQ40ZAOVnoC3QmST5CpV5ABXgA87QmZ8pXwsAoRHqDDKZAJmYAEZZlKQZgrC1 k4yAmpkIiR9wovf5lFbpmvoUARegirC5mBZgZi/qmm2l/3jltIcLoJQLAJXhuKO6CQG7SQKa2Bfy WZUUcKIfcJ8QgKSJ4Ik/2AErYIQdUIRDQANDoANJiAAxIGhLtwOMGJ7x54X5N3VhqAEesJ3haXXZ GYb0Z39eqH9ad0UjgJctcad4eqcKt556GYzCOIzSEJ+CSZ/46YjlVAGOqJRL1piO6Z+LmU89hAIg aaA0IJmRiaCSmQqrqX2HipQWOqEUsIcHYKHOAJgauodJ6aAV8IHcdpockImSyAFLKo60uoMLMGun x0uKuVSYJXsa1Go9eKhGOaqAeXIUAA3SGAAKoIy5eZRKaQLCyRcUEInH+gwUQKvViqGIUE7v2EQ4 MANTiv8DWGqPXEpv0DloAIBznhd1ccqdZxqLsrgB4LWDG9ADWqid99pvV5QA/JoASNp701hOz/AA ucGe2eKnwjgNllUE0/p8LfgBtAqOFpCbRrmojumYS4VLkdpUS/WYkdkCkkmQINuZqJCJEEACFNCD EJCREFuh1lqTNOkDPsCvFWoBFGCUqeqhxDCtFhCrshqxQDtrU/gMCZVQAFa0LvpAHZV0wVqUe6ih ykiTlxmhnpkAPXp4GYCysKCRPekKDcsA2Wqtjhi22noIPuitQ8AD8OhEOIAAzjl5AlCW6mo5tHiv GmCvsoiyGimrKFqoGlmvWQieGzCGX8avsuoCLiCqq8r/gPumANlKsHx6nn36p4DauI5LTPSJrVWp qE5bsfuJsSPVQADGqwAwAZ6ZkDpFkAtKCQ7FgRUgnBZwskkqpMqokTU5rHW3g6eKqB26qoYgfalA ASTQsxyQchFblCjHiEW7vEV7AQXgdC46Vp0EQxagmBNrlDO5h6FqmZyZANr7DMmqAAmQtSnbChop qtrLCl8btpkpvtnavuJrtkKnAEKouh5AA2proEKwboSGjz9XddfpnYs2StMKsUArjkqJhWE4CITb RAlAAieauOi7h6vqDBlJqgTrexFJkaO7VN4YP18LidgKDTfbgQ56wpQFRQOQSbqFAiQAAQfAworZ RAQp/wBCKgD4m6mTkIkV0IMOCrsV8AGhyocye7vNqqM1C3OuO6w6WwT15sQC0EBPXAohfAAkcHKo mqgviMVPxbzMa2uyJ70q2FQ96LSquqonaZn9ir5TK6EJ8GZaewpIer4TTKyuKkLvqwDK6r7OEL4Y Ol/cagGSyZc4wJUg20QoEMXn92T/W4Xe6Z0EDLEnjLMI3KwWIJcNaUUP/AGIewC3icWWtawJIAML GLm9OJHu6cE+tQATEMI/K45k67g02YHIq057rACVGgArPLowzFQeCYo8YMMdKAAfq8OR4Lo+/Lop O7FCTKxWa8S4S5UieL1M7LtNqIpKCEOqSApVvMW3q/+qEODNB+BklLZDKDi9LwRDrXa9FFyUVkmT KTfByhihVqtjcWwK0+qIPgABJ3oAMGzG5YvPkehG2SqhGFqtBo2hnJiVP3hW9cZTUKiKEgBl7IiF kDy7DkoCqurPSfmCG33JjKbJEJy41UiNnuwMpKwAGeyHaojKoxs/PgDTz1eV4ji10lCZNXlyRRlm NFCpkomx+URgv/yxHiAACyAAInvIO+ygyQzEzayUcxzVBRsBJkAA7NzOTXbNSTd9HQWskuADz4eo 4ty54XzFNUnOGqe06PxCXV3Gw6qqFnCq8Iy+TquMNLsAbxatkBDVgCmqLFixHFCxFeuklCC8iHQA YTv/oXx8oc9gtQHdVkInABKQUC7aUU6nAOsGAGDKjptyt/L6sz+s0UWZlGIt2oh6AJ1nDZsswcEX z3mqwU8CkXi5l9nyp9HQsBxg09cKATYNk/uGxSinrLkMspIpDCzcVEHtmP4XmZ3JAwlZkJMJUUzt usLpA0J8okm5mz2qnit5AuJFACdwrW9dlNLXQOvGU9rs1Y+A2xlQ2lhM1uLsZMs338u3tOnF1gaw zmYM1w5g1T5AsWf8mzl9AKt0zyOqkVlLW+f0AYAt2Dt4SFUZCQ3rRsPa2xjqoBYuvie50NwXytSQ hPj2A2oVCdrpnaBd2uDM0R492kZJdaotqwLe2jCL/74y6wOxjYYUSbmVC9a5fdu8/QzKmpk4zaPC XalopAArYNwTwKtkrNyny5xS5J+O2gih+qAzWQE1oJGIWsAI7ILC63W5QcAwrLjj/NDrJn07ld6R wOOE5N5G7KBljcXy3VF0Xud03o0WJwH57daKu6ooQgBVicV1PMEZYMWPjQhVmQEK4GPfVGUvvIOB 7cnlREEuFeFUzgAw/ta97b0nvOmzDMjJidkOXQACMGU3MLeQAHAmDrEdWtYpHs4rzruovcCqzcnw LOO47gOqJ9sSibAJ67gfEAG9LeQ2ndDbq6PC3QIhkN0hgMuZOgCLueSK6eRN9JIDcbEXawON6ghL zP/Rudmk2J2oyqye6ukMYHvaMAsBpD596yYI5a1bUzyiL0hIMvC6Hg2zHeqCGn1yBaBK0zvGY8xz MGQA23zVFGwB4K0A/Q3oVnl4FCCTLsDgh24IFJDgJOBGEhRqQrfPO/jonghnOxZOGaCRi9CwH0CY Mvu0/QrgfLjGO7qHHK59kd2EAGBTQ6sA+8jZmyICPeCdrE7Brj7a/qzv4KybC4k/CcABJI3ruD7E CVCAEOnS70kBEWAANh3kjuuyjP3M/nqSoAiyelihzZ7LRfCYkkkDUNTTwl3kuoztF/ufjcCB4AzD +uwDBXC8D1wN5w7D773uD03q7T4IMrjekkhI2hv/1R0a1R9F8P+ugvajWx1lAGTsunRNASdAAM9w AryYGy0HfEKaARyQkYpQ8aNkAhcA8qj/AjJrTk+ZiTUus6gv8hNPCMJ78uY043TN4hT71ijsjgd1 85QNSoI3Caq+AazOxEF/2rBu2jkLi0jPyUzf9DCr67u+A5JL29miyq1c9aRq0ENMquIL3KvpA04U Ah4XAsSdqQjqAQd6qc6A9iUg3En+9m8PCXKPqI4oqjJL0+IICAcUDAqFhgwJFBUQBwsLBwUFApKR ApOWBUWam5ydnpqDHBkVC4ocFY2PFIIVp6mQBgYSCLQTtre4tBK7spmgjI0HFRQnCgQEhsmGJxQQ /xCoHx8Un5sUGSQnGQYv3N3e3+DdPuPk4Bnn09SDPgfOFguoB/KoFYvO98/1jfUWnhbcFhTcsERQ gIV+1BJq2iBCQ48NH2q4kCcMAgcSwhYd4MARY71njTb0ELEBF64ELmQ4WsmSgsuXMF1SlCdExY6b Nx04KMGz54MHI0agQGGLgoyjPgx5UCCA4oJxCRKwXGABpI8ACmhobRGga4ABAXi08GCphVkPXpmS otB1RdcBcAekUPiJAruKB3y8dPaBhA98HCgkYEAY0ap4jipdmlSEEi1fdDfpTQeKhCjE5Mg5zTwO RYFYu2qZnEALAa9YFlBssiAsVT1ihY7Jlg2idv+zjxB8ICwSNaY1EudixQpH3BtnH8QNoEs46MM9 C+z0zcOND5+8Z7s5/bNwQZKEGwezR/bE8GE0qy5beRwmqGNGl48qbNCwQZkhlKlawp/K/5G8DDXZ hJNOPfmkw4EIKkDBB0c9ZYgA/snTXyNV6RMADWaZFUAKcQXgAVkkQCDAh2jRkBWEehWiFQ1fyTWe P9P5wJEzMylyzwIcHJCIYO04FQkCmBCUiSQIFCABZJENckB2zWUAEn/TSTgVChZIIMssCJiky2kS pNZJM1K+Vox9ypyQwEfDbJLALmzuYo0owQm3TXF0hiPcOeiEJxgnFHDgnDMUvFPPoPZUV911FYj/ p8k/L4R30IsKbdCBCOY5U0ECrE0GE0W+scPOAvORRCZKU+3XH5R5ARiggDkVyJMODyCIoFENLpCA JfFJx5KEKfTqawpevRUXXF0JwMgCI16YVQB2CfDAhSt+NRek2s1j3ZIwFbDIIgtYxFGOEv5Iy2KM NbblkUgy98GSfPo5CmIzEQrvTJ5RcKVopJlmZSxFqtYJa4h1O0wCY5LJDJq6gdLmlW5akwGc2sgp 8cQUS4znxRS0uUsC1TDwJwQWYJpRoYbiEw921GxHbWQMOQSRMz5Q9dRUM/UXc0gj1WcfBS60dCrN jsiTgA+rstpqgbHCKqsO9hqg0q4jSyelBRyk/2DDsFjH9dILPKyCLA8sLnvissEOtTKf0XEADLvm PqbtoDM1Uklp5JbbdpuRZBITn4wwSUI0UscrbzzzUEQlm7VsCZoF6WoHT34gCXbC5JSb2Wc+VFWz ywUnYHPDDSZcgEBMD19s+umop57BS1ZewPkFsnBchAUeP+cAAdANLq88ipycaMoAnU2NpA1VCpIg MQcdt5SOSPUIqCN1UJJJRq1EQUuOOvpSVGeqULTRO7n6wFBCETWBvR8YsPzgUmKqdgW9Yv0SXBS8 gAAAAFAwVgBj8eDBsxfCyrJmgQIFRAAB/hIedGQUqEdpgkjjypsE8yaA0gBJEkLqRAF0UZpMQP/n b9F4yTj6xicQWkp3HyiUvI53AM/oqzSn6Rdd3nEsR9xDRztySQI2gjkm8eJ1rnOdLEb3gA345ohI TCLrABDEz5HgBhtbVAU+ZgGdEOAlEVqebnzgO0WtJjzCI48IivcyS/FOeVEjXCOu9ziRaIAko/Fa KRzRwKGg4AGz6YlOcOK97+WEQK6yI1GIsgrAUaQAjiBUuBD5Pn1wiH4AQMALKDAANr4gfx/i31kC oImuDJAWKIgAAcM4O2EERoOTMI0FgVSQClqwbnbbxAR9UZV8TBFmeiEhKKb4MVtOUQHxINkJKVKP AqBAY7HwzIsEhQobOuNb0LRl5viksWrS4gX/QWABCzYAghFswAC12QABugmCDYygNkXsJjfPyc1t boAFMADBuVp3pXRAx0/uIMAOFHC7K2ZPe1LT5Seo9gHZkbIIxOuByz4Gt0D5Z3fy0EswGOFGEUiP eqlwSWoEeUfZ6HGPfPTjH5FWAkHaAgV28VMzMeU8p5RiI2rLB0V6RQEAvAAew9iW/SiAFv59iCuR 6FVXCDgUVSbwbAA7JScwuMHQrPKpk4AgJiD1Ty5qBEzscomMenmPb71iUDWQKTGXdDhedOmokXmH wBpxD7hNxxGKooAqn1qaBCDAANl0ABBGAAQgwGAEROjrMWDwExhkYAQEgAEB+AqDv2ZAmyPg/8AI 5PpUNlFmQX+iwA6QUYgd6KSfx3jHKdQIAcoMtB1KDWPLGrJQrjqjFKtYniDORBEIiEShY9SZIeRI gaUhCI/H4AlI+yjSAYWPJw941YEMwbTzkEIqDdQeD4e5j3bU9KYQUNALFADbrhQAAsGyVAHgggIE KoARdjxoUk3bGILMU2MRxOC4pkpKG7Wnb30axnkMxREF5OUuEPVPaTVBJeF4aWUWuJ5b4zaoUnix CHLlnl0RIOFbISAID8gBYYFwWBYcIMNAIAALAPuAv5bAv930K1+1yQIQwIACFeTeKncDnXto1hic VcYO+jTaeLFtoAe5XmrPtloNuOwvJbPIU/80GuTDBFM+PVBo9HRbiOtRQAG+PRBwCSDcm3yvuIAs gZbFnKBC1PgZzvQWNGMq1ocKQpLwuPJLfqUtR/igzgsY7wDseKxQIpCU60Wle/UlAQAgrpWuZGXj 6HLEeMiob644c8k4kqg+KS9grdkNSg1gtjAeJFe7czCjo/vPBFMgm0U8wAbeWQ8igIADRAgPC8KT AQUAgQirBsIDtHkCEJQABJR9Kntt9Iwb43g2x8jvvAacMtQqqFvsfVFCjeyyWiZ5zW0lrQWijNs3 UvnZV86yAoDbZS9/+Qd+TG5PdDACMi93t8JM8gkJ9zhmb61+FZjkI+ucgEiQIs97NqAE7Cj/yj97 2pTRxqAl6IroV8ZyPKGAZlhphGSY6CXeXW0FB7iLRuUxW5YUWDSCSw3Gg0JYFCzIJggykMIKuKAG YV3SX3QTIt08LIUgAOc7s3GOwPwz2rmzlLHJtAPafvXH/oiQqT8u7UlRitoiCbq8IRqmJXHbyFOm HgUmwFFbbLncRUO3EB6Qbgeou6QoKJ8dbyH1qStSQoVLMJyze2UILGCScclbiBDZ7z2LkoAWRCu1 Ao1KhSO6IKuk7+B9SZ1nqJnSbTeUxhWQPCnF3ROCN7nm65KAcwQhCLWRiJ9qUIHa0C43VENFeCrg auXkXDnnAPYy4SH0BOxTx7H96jQT8o6D/1hEQQ9OSEJZO5+HCMrtUlsJKbYd5fk4ZIwXvcXWTzqU WwC33XskO9nHLvbta/8mD3DAHZNrUq6bzxbMlPzbXSqMzF2Xji/49+jg8t0KfBcCeSNvwREoSPUi 3BNMdXiD5nAiN0N3wWC+ZFX6kH7VoRFPUXkr0X7Bt3kUyByCMScvkAC1YXrhkUJLEmkVoBsg8AIW kwgIhlORY3s4kQg5onx2N4Gr0SPywBrRFiljJGUP4RDGJzDUsWD5wS3MF2X08UZZNxrmd37XVwI6 MT5p5z3bNxTbpwIPgBNMmHZdx3UmkX7sszxB84KgEEmTBGF3dz+UVH9PEQnwAHB7ll4USP94SyUk EjRoToUJBZhW2aOAM3GAFKGF81YPE+KFFRiI1CJC3JAZe+iBqbckqgcOL6FAKEgjO7JDHBCBQDh7 cFUVCUYtDPF0zaeDq8ZM68cffmgBtyWEbjQSokImWKYDhXB9/LSEBzICNwErNRGLI6ADOzCF7LY0 q8iKZDI7OKVGXJgruwdhLlEN8zMAeNZviXRncPFI07J5bvhAdAUk70WHgshFcaMbVQWKPpgfxAiD gjiOnpBDLxFTfxENPSIdvmFQnvaIj2d38YFm4qgdvidQ0pZb1JaDD/GJiUQPlmctcFWKCuVG9JFb 44FHI6AJSvgAmyCLDlkEZOcJU1gEC4n/VP84jIkkj/WoCfRnZwWQAog0DnrGIdEojf+3VBZUTYeW N21IddxYg4uSkS5FiRxJjjgZRr4hW3pBjglGeyfUVmgWKBg5g0QGdfvIbau2AZ+mO4RCFavGbVJp ZM5HH+MRFJxwkZoAkZsQkZ2glQqkYE7ZYERJLfQXCc/oks/oIhU4jYYHQ3QTVXWoQHqoJ+Pxk2NJ lh2Zk3xpgXEjk20oloMjap7mQEdJldSmg/24AbPTlE8JRksZlQqFmFT5ImD5CZeJkz+ZRs1kmCvD ls9YBC4yLCepeW4pgHQ4l+pll0h1PZxJIXvZl7KpDnZxjLJJcp45m+QRmbzJmP7wT8LXIZurppuC iJux6QmhmZxyERelaZopKUuz5JLEuZokJ4iBAAA7 --------------Boundary-00=_69XWAOBBH7466DS2QL80]-- From Vinth@Champelect.com Mon Jan 15 12:51:21 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VzN-0004sX-51 for mpls-archive@lists.ietf.org; Mon, 15 Jan 2007 12:51:21 -0500 Received: from acaen-257-1-14-240.w86-205.abo.wanadoo.fr ([86.205.221.240] helo=ACaen-257-1-142-154.w86-220.abo.wanadoo.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H6Vym-0002WK-0o for mpls-archive@lists.ietf.org; Mon, 15 Jan 2007 12:51:21 -0500 Received: from Vinth@Champelect.com (maison-53xog2xi [181.134.39.86]) Mon, 15 Jan 2007 18:50:24 +0100 MIME-Version: 1.0 Message-Id: <8E492709.000004.00171@maison-53xog2xi> Date: Mon, 15 Jan 2007 18:50:00 +0100 (GMT) Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_C78XA2RUUGI4G6G00000" X-Mailer: IncrediMail (5252670) From: "Vinth@Champelect.com" X-FID: B433CDFE-B71C-42C2-A5C1-D34C076A9851 X-Priority: 3 To: Subject: Britney X-Spam-Score: 3.8 (+++) X-Scan-Signature: 28adfdfeb3b69a8c1fb469b1c327fd44 --------------Boundary-00=_C78XA2RUUGI4G6G00000 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_C78X0OZUUGI4G6G00000" --------------Boundary-00=_C78X0OZUUGI4G6G00000 Content-Type: Text/Plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Lindsy kika lin bet suprrrrr.=0D Dancedm voskovch figurnhon zbsile pirti.=0D Bet suprrrrr th devil nk, boziii waneska, hermione.=0D Light bette, filmech, lifesize get, clue prci?=0D Zub reklama, copy issn publikovn nebo en jakhokoli?=0D Zbsile pirti karibiku, truhla mrtvho muedenk princezny.=0D Vin diesel jennifer lopez orlando, bloom?=0D Zpvaka datum narozen msto narozennew.=0D Mezi nmi dvaty cel chapter.=0D Lindsy kika lin bet suprrrrr.=0D =20 --------------Boundary-00=_C78X0OZUUGI4G6G00000 Content-Type: Text/HTML; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Lindsy kika lin bet suprrrrr.
Dancedm voskovch figurnhon zbsile pirti.
Bet suprrrrr th devil nk, boziii waneska, hermione.
Light bette, filmech, lifesize get, clue prci?
Zub reklama, copy issn publikovn nebo en jakhokoli?
Zbsile pirti karibiku, truhla mrtvho muedenk princezny.
Vin diesel jennifer lopez orlando, bloom?
Zpvaka datum narozen msto narozennew.
Mezi nmi dvaty cel chapter.
Lindsy kika lin bet suprrrrr.
 
3D"FREE<= /HTML> --------------Boundary-00=_C78X0OZUUGI4G6G00000-- --------------Boundary-00=_C78XA2RUUGI4G6G00000 Content-Type: image/jpeg; name="950-D2870E3.jpg" Content-Transfer-Encoding: base64 Content-ID: <2BA20418-1DFB-2CC0-BA58-A5865C057D27> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAUAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAMRAAAErgAABxuAAApE//bAIQAAgICAgICAgICAgMCAgIDBAMCAgMEBQQEBAQEBQYF BQUFBQUGBgcHCAcHBgkJCgoJCQwMDAwMDAwMDAwMDAwMDAEDAwMFBAUJBgYJDQsJCw0PDg4ODg8P DAwMDAwPDwwMDAwMDA8MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8IAEQgBZAD7AwERAAIR AQMRAf/EAO8AAQACAgMBAQAAAAAAAAAAAAAFBgcIAwQJAgEBAQACAwEAAAAAAAAAAAAAAAACBAED BQYQAAEDAwMDAwQDAAMAAAAAAAEAAgMRBAVAEgYQIRMgIhQwMTIHYJAWIyQVEQABAgMDCAQIDQEJ AQAAAAABAgMAEQQhMRJAQVFhIjITBRBxgUIgocHRYiMUBjDwkbHhUnKCwjNDUyQVYJDxorJjc4OE JRIAAQMEAgIDAAAAAAAAAAAAEUABIQAgUGAQYTCQcIECEwEAAgEDAgUEAwEBAQAAAAABABEhMUFR QGEQcYGRofCxwdEgMOHxYJD/2gAMAwEAAhEDEQAAAd/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAD8OrGXBGUls1gAAAAAAAAAAAAcWM9OE+jCfXjL5LTZrAAAAAAAA AAAACC07ePEvrKN1TxPxevSKl/cD2HjwAAAAAAAAAAAOhCVVq2ZLbCM17KrUsVKna165fc9Fvb+F AAAAAAAAAAAAp9WxwYmwqVS1RqV2oVbGMtdn0Z9l4wAAAAAAAAAAAdSOaVTtSOzEHp20ShexhQ6N F076TLPqL7LxIAAAAAAAAAAAqVWxw4n1oZxhyOrTdFnGui3jjXtpF+PsL6jw4AAAAAAAAAAHRhKo 1LXanGH0bsZ83o67cru12UMeWcU3r6fbbr+LAAAAAAAAAAAx5Qu9ycetGVap2arUtamc/u0uaAva ZrZo9e/QePAAAAAAAAAAERq2Y3oXZfbrhtO+pU7lZp2tcF6lXcbo7+HluVbJnX5oAAAAAAAAAAx1 St8GJfOM1CjbqtS7TqlyuW9W1/W4U5t09zfqsm7UAAAAAAAAAAMa0bfS17YDRvpXPv1uta590dl/ Q+a/M4q2ndBatueOrzAAAAAAAAAAODGcW827ijk9itabUPp3werfsT3fNS+7RXNW6GhOPjLbX0PC AAAAAAAAAArejbrj5n0WKavW6Ms9PXOBjnNdviWuzVgY74iOzqs70+r8sAAAAAAAAABivl39VfO+ rjtueFiI1yxZar2bZX2P01YmO6Hxv5pQ3y9d5MAAAAAAAAADF/Nu658X0EJjbXU8KWquIe/5vIGp tX5z0d521e7LV9Txtf6LigAAAAAAAAARWqet/H7OCef2Nfb9TEnc839ZhwmQa1ndrh9aRrWOprlu 37PygAAAAAAAAAA6cc+dFO/p7bqRMoj9w/MputfvNXoWvTv9fO15YAAAAAAAAADomlsc6fs4ly+W e7DPElI6Op3dV3sw3yEc+3vV8gAAAAAAAAAKPhrPjGnTOGMy5sZltUrlps5j4/WokLsJts/LPNKP s76HwwAAAAAAAAGAqe7C046U2IY/ZkIZnoz3mnHM3Pu6jcfsVnXu6eu3x5zzZj61+x8MAAAAAAAA ImOcHVdnntrsUexpr04ZQzj06nDL+URCWiXnu9Tqt+Nhc4cZ+8x9SvY+FAAAAAAAAxjpnG15afat molyGxNDd2+nV9L5xmQDXnmXdZuB6vi2z68XVi9NvY+EAAAAAAAGEaO7HNbZg+WdXL+neWcNkNOc lWYdgAFS1T1G8x6yKbofVOIxL0q9l4UAAAAAAfhrfV26mapWLfDOe2Gx0sWHIAAD8MA8brYv53Up 2i5fujztwvQeaAAAAAAEdHPKx3JAAAAAB+EXrmJXZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD// 2gAIAQEAAQUC/o+MrQvK7WOe1qMxTnrysC8zNXJdVcFUKR4WXfNat/0Y26m5k8cEFGjcppgFNcFX U++PZHqr6QvlaKJ76CeRTXCmn2rd31E8vhijaSSKKZ9FdvV3c1E9zVfIGpvX75GiglJIu710ckt6 Cr6fvLc0XydRPMIWMCP2lNFmYvPA68eDPcblczUW726e4m89wOwe9TTKeUPWa/698+fsLee9P+dy OzTX0/x7W27pzi0SSqaYqV65Z7ZsVh8pnp8HwzD8fj/9Jmnz8tFbx+yalJpNpmkqppqFvHH8nu7L Gx2ds20toz5W6fKs33puGtE141T3O5Sze3H4a5zUlrbW1jBLdsap740+adNI8RMv5QIri/7vvO8l zUSXAXGZw3ES37ipLpPmqvNpsnI1kOSy/wAtPuHE+UhOkKmmXH8iG2108te6dPmct3bS8reWWTwV 4qox0EtGjJ5KOAcUyIube0uhcNuWOgcXVW11NLylm6ykionUCuLkMGXzQjUcdxkbiLN2WIVlLBfQ xS9hj7N4+N20t5aMvYMnjJ7V19MYFls06rnFx3v2LA8husJLj8laZG2lhZKvg29NNNDDOz9gclwb X3NtLbn0R3E7YLbkebtx/r81t0tzc29nBmM9lOcsvMhi8OiSSvHtaxkkrhbFqESEa2e3SZzkON4/ b5jy5WPk/L582UyN8jv+K2WI47kM3JLjsdjI7mxFfi0Xxl4Pbo+XcukwM8eTwGKsuQckyPIrlRQb 1bRXF7LxD9TRQnkWLjt5r+PtAfJG+Lv414/bor2+tMdb5Hj1ryqZ8+NsM9mcNcYmdkbGjjvFsxyy 54vwzFcYgV9atvbbIY9xu7m2jgkMa8a8fbQ8g5VjuPsk8Fo3l/Obm/TrhYaJ2e4Pwn9d3fIZLDH2 eMtuuZsPFnDHU+NOjWw00Ga5hZWb8VkuN4pc05deZCO2sMhl5+Jfqdts/G8QwuJEUUcMfoy9t5YL yy8F4YFM3aqGn1+S56/vraTHcvvzj/1nySdY79XWLG2GKx+LZ9DkGILJp4C1Otp55P8AG5Lx/Wur aO8gggito/qzWVpcKCxtLb+Bf//aAAgBAgABBQL+j6qrra9Kqur3dSpqtXyNU77N6Epzk4qmqf1c USjqiaIdCU5OOreehT5KHeigtuoJp1KlFVXoxupJqUU4olbUGoHavLp3Ggb0JRKcmINRa1q8w08p TUUSnFVUIW0oRgKunlW5Fyc5VTIi9NaGrci9b9PK7sZFuVelu7271u6V00hoJJd3pjdQlVVdPdfi AqKioo4tyuIqFpqvtqLn8adY4tya2ikZvBaqrYFTTObuD46dIod3okj3I9iRVeMaeiMTT6i0VdE0 rwjWE0W9blVV1X3TpA1PdVB9F5FvW7SSSEJr93UnpRSs7u9FdGTRfdO7hj9yqgOpFU9vc6Vz6dO7 1RP9rvTI33DSSSUTChVxCovH6nhFtCjoS6qEa2qn0p4+7gqVXxj9ciqAp9YtBQaB/Av/2gAIAQMA AQUC/o+oqa2ioqKmr29QoKOXxdUEegCAQC3HVN6gIBU1Q6hNTQqapvQJkdVsTUdSBXqFCdpI611A FB0AQamHsiqjTtFSegCAQUakkDU6Vz149PEiggE0IBPk2IvRedQxbUGJrUApJhGnOLlRBq26dgTY 0GINQCuvzDVt6U0zVHDtVFTrOyqatqpp7f8AKqqqqqfJtUcm4PZtTDXUQfkHdZJQxPkLlE8sIcix eRwW7TA0UclU3upptiJr1ZJtQNUHUXkOobI4KtfSz8W11Na+gNLk2CiDFtVNW2IlMFE3TtbVObT0 7lE/s1fYjThObT0g0THdo++lAr0+yqm+prvaNI1qK+yqqqvqCjfVtUNCAi5V+nBJRNctwC+UNcHE IuJ/gX//2gAIAQICBj8C9PxbfQ9n1r5/Xw8F44moVF7RgDnpUQ2ANd3hOf1ybilDUXqfEEceU7J/ /9oACAEDAgY/AvT8H30tsU1C+V3dF8+cCWXTR4ipVd4ULoXzUaAaLpo5Fw0EbJ//2gAIAQEBBj8C /uPrNqLhllp7IsEo2lRvRvZWUNZt5fgGpYUSlP5jfmje/Tn48qcULDKSeswOi+UaoUg6LIlm9pl2 Xy+XKksjdRarr6TbCgb4tuj/ANWLxZSpei4a4KlWqVaT0mUSnhKM0GL/ANXKUtg2N39fRYqRjhPW K7h0wbdYjEL88K0xOf6k8on3juCMSjMm09KszibW164OKxSbFQbbM8Kj7v4soVLdTsp6D0EGHEi5 VsSnDnClJO8TE+AqXA4u6dzHLF1ZO67nAkjrNkCL4InGkRZDCx3gRHs3LacvEfnPGxpsemqEvV7o 5jW7xKrGkq9FGftjcPyd3zZPRsfuLKyNSP8AGJwR4DWNZY5fRKnWPi8z7iNZ8UN0XLqdPL6Ju5IF p16z1xiKeK59dVsXjRk7S1HYbbw9pMz5IIFgEWGcG2CZwcC+BStmT9Qf9KdcN09MjC20JJHli+eq L8Ii/JlOKuSIStxUlOKJiQNueDJXZ0XwjSpxaj2mCm7SIst1xaY+nJk4zJueJzqTbClAYUixtMds TicXxSIJkhxGCfpAmCrMrosMb2by5MJd6Y+bpvgzgi9WiHadbk3WVlQHor+mPZ35cYWBR70W7puM aYu7vlyZH2vN0m2Chs4nDGEETNrjizJCE51KOYQ1S8qYD7QWFcx5i4n1tRLM2DuIGbOc+iG6hhQc bcGJKx8bxGCqQXUfuC8dYzxxKZ5LnoTjdTov15MphyydytEFtYnnQsXEQoGyFNNHazmCpRmTBbxS QTNSdPX0bPrqRw+upifGnQYYqadVlQnEhBsVYcJs1ERaB8eqNz4zycofQFozzhXK+QN+1VQVJ7mA OJKfQb0nXEqnYqFWlg76ft6Oq/wUshakhLnEQRenqgBNctxIzOyX4zbH5jW5P8v0smdqqp5NPTsJ xPPLMkpGuKqm5O//AET3VZChU84dElVOG8JExJGnx6IVSe7/APJq7qj3hcG3rFOnuD0r4JJmTeeg LcsnuJzmJISVHVG1f0/c/FkqXa5wl104aShaGN99f1W0C0wrm/vq+OX8opjxKX3dSvYToNQofmLP 1RHsdGn2DkzOyxRo2cQF2OXzdGFAmYzPP/5RHFXNil71QoX6kDPHsrAl+4si0nWYmkdP3fxZI1TI S2006j11c53VrngCE3ZpmcVfvMurqOf81kE1dY8AqpbxbiMI2WmzmKdk6c0casXgZQf41GncbHlO voxqOBoXq80JouWMKWpZls3nrhrmHvH65Q2m+W5v+zzQl5htLTDjeEISJJSUZpCFE9vbBQU7h3tM XdF3d/FkaqqtqEUzCL3FmVuiG+be8FOaPlVI2os0KppdUBPbfIusuA+WK0crefHIFFTSFLM3UsuC Sjh7yfRN4vthIcSPZqgY6OoQcTbiDaCg5wQY4j273W85hLdK1wqRO++bEJEJFO2HquXrKpQtnq6H GFd4bB0HNCqUjbxFB6xHs7W0Kex1elf0dPZ5ciQl3FU1z5w01Aza4omP6/z6rqEocQkNcoewFKFm 5KW0iZWesxVUyHuC3YltptUhTy+s4m1bhuwjZGuDw0hCSLVkTWRcersjm9A+jG97uLTVcrcN4S4V Tb6iQYRzHm2Kn5cDMJN69Q+PmhFJRMJYYbuSny+Al+WzUIK0/azwpRvWSo9p6ezy5C5SUrntD6dl XB21YrDhSBnlDnMa9VM5zx5ZWKZTiF1SJnvLcKcJ1WShCFUiqMNYv5imykpSqzC0T3lZyCYQzR0j j5VYy02JiWkHPrhnmPvC5jfQcbdA2dkKGdR8kVqKNhSW6+QqEKUVbItwid0IaaQG2mxhQ2mwAeCl 4CblIriD7Pe8UPtd3FiR9k2xd0dnlyCqpuQNVDlE1sV3NKZsurVOzh06RfrVcIWml5JXUjTljiuG oOuf8jpCb9AknVA4zLVCj/cWPmTOP/puoqFApKOGm1JBnsqzfJBRQ0jdOCSThGdVp+BaqGU4mwMN miLpQENoK1KsAEbu37LxMPp49zrw2/Drp3sXDXLFhJTcZ3iEtMpwITcB8NN6nQsm8yibFOhs/WAt +X+wX//aAAgBAQMBPyH/AOHq1lwTnL463ORPdONOWO5xHOkXGF9ZLJ8O52mm3Lu+ASwR7Mzoi7fM a6358eqZlqn0CAINN58JyRKmWAqrdoz4P43qh95t1p7EIVp3l5mu8Gk4bShZfwipFSGmU246kgnq K5loRG1VrdZWhGlvtzMSfcIyjWAbynyeeqN72zef+iZi6iCyjHEfPdOUeFDBpsdE01y0eJWvorq+ ofPODlYrdg2crrKKKNN42OkoJg0tQS2thDvoxj5hQix2alvm6janem8Gr6sxc1xK/RqRLbcQalSa x6MwD8yxaBlgFydoJ68D4d34vp81V8Q33lini+JpJjV59JdkX2lBMLvxNY8oRGFWPozFWdu43XB5 auxDN5p6DkvDn2kx3iq7vvq9P06fC31LAMyVH5RKxZqkpL0jezEthb3lsHcvjV807Mw3V7xbvdN1 QhRPVdjQnuW49un01MTuvgIdYwWtQlNQW6P4iWqzmqjnoGfvKlTArbc0709CHl/IBcq5WWN38NPe OVXJi1+3fpsdl5m1gV4NuNalLI5W7ZoiZDf5S0znW784Lh32mbSjjfAfBM1VGg/MR1W5fiZjY86z Tr9H79Ng3r3J4e9QxlduQvfzjhy7vvB1s0wGDKbvuhXEfQ6/OWqpsnDFNwvfWN1M7y2z+/TPomGH nyR9zesTYm9pvHYKo1gNrZ/eWcPbCZD0LSxgHYDz3f8Asxw73+Z3VtKnybprVdl+X4hG1mbgo2lk 0DUnP8O018VV61PAf4ZxMXvbvcxLGpTxGeWpt34THaCLzjC+pcRdiRjzNSbGzjTurXXpmsTmGqN5 ovT6giNZIjeAOKJwylZUBUwwI07q8EAM5SZ5v8HftnMmsoUKXqCZB9plKY09NPjPp9YxRt73tDi5 Tr0R+8o2vWWIwMsDnDf3eYPGpcsLmRE7tpjeiB8K/Ka3JxNcb16ZXVCxOqmLPa+fuR8wY1QZZK6m nRKza3dk1iJn22VXVXw2x5/K9idldDQmjr+EauJVtKdL8kVygwZIXfQ3YAhRdi2i7bCabpCz6YBu oY0bHB3c+BJr/HnK/wBwv5hN9U9Y+g2l7NKsHkfWS01m5HSqCNpbb0nlfYd1ApSTIVGMTWedSGi3 SFbAmoyeNZbnHyLL2MeDl3cd+0CpFguzFr67SrmtyOorX6XxBPIBgcHACRzII3Js4IFtH+RxJQvS D47dJamUAEFYBeq7BFqAGm3Yo6lrpeyFqIpV2pjbsNHkG5sLRjZoEvOzkYDxf9T2igElXyF+u1uI lU6uxZz089fIx4Yb2zhdUaaKo2SWZ/KgEXt5e8a5+JTb0W24uu0tjb78S5CM2TGrhoMpXoSlqmlt YDDYwuuECbIr8dm8Ktnb4ktbgd2CECAqrYfo35AKSgVbpa3f4CZ7chXyzNupJykqbS8uvScXh0O+ Fi6W6Ly0oA0y/bqEdhgoq46q1Rc1bY6GrR1SyeCQMe8D5pTK/MkxubKcIZJzftRbUWu8BPsQC0AP 4+t+A6D93pApMLPOFXvKHlKVJn4nL/vdMukz2ZeKtql0VNpZfX+g11WbyPvNZZO7O/Lgq4TYvRWm 1UmEeM7mKmr3f6EERLHUic7ABUtg9Lg2VtY4bKRb9p/kt3/0Mf37MDVGilg1jME6GgV64/todS48 6pHJ9TMbV/X7gz/4L//aAAgBAgMBPyH/AOHz1oteBZSV6t2nivCFvjqlUCj+OFeqVtQi+IqV1NS5 l4VRyyX1VjUPCkBheC9fTfqKkDeMdSrBQblkrqsXi7l4AR5OnzHgceNq4bWXsyR9fmdr/nT1UQeG qWeBVXb6+YLgwfMz2r36gcjKHh2Rh3GnP1vCKIg6gLUIy8BUZWB74t8F304Mk1MPBZrMc6RI+Fi+ mfiNPA77SiaxX2moaxylyumNxh4XHdukA0QbUUUdYYVnBdXTjoYmMcTsCBWniPnhsWvU4Q6xDSH8 fQdTYJ5vTsDxu9IBzG+kYeqlqZ8swZrHUJi9O26uYfm8aJXM7prDeYxJdS+kALY5XwTZf68+8Id4 7CUQPCtXgBBo2j4V0QeebfHMlunECTF2uvrA/jWIy8Hou6JVqL9bwWvZBWngy1f5WEu/EvoGw98r mcK/1JUxJd0T7H0f3gKYAo/u14mmn/gv/9oACAEDAwE/If8A4fHWoXCSLS3VnLxEtfPPy6o2+CvE 6259rqjRfgHjJefrqRbGEMMrhTqji/EAgQIOpuR8XkkHaVUXq8B4dEulj6ixHhDxMRYgdqYbEl+n GrH4LvAwwz3Zc3kxMrp3iFo0o8MnnhEIHUWFx1x4hT4I+J4JFdONuPDBjBLmePomZ4AyumNmH8HM Ww8TLux9pTlSzpnUWS7gQiMX4A7SzSXZxY4B6ffuDGCBgQ7tleDeSV7NI3UMU0ht3G6/429e4uoD UUvHSMUJvpXDqIPExMzgSthHcolErpC1MWQ8Dw7JoPBXgEldGFwaxMddPtLGNJUWXfhcuUyKOb7Q 6RY7QB4WRC/xslgeOOht1nElAjy/oXKt8OXQ0a+Iv+qsuBKtsz+vxz/eNRb/ALtAZqD/AOC//9oA DAMBAAIRAxEAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ4A AAAAAAAAAAAABJYAAAAAAAAAAAAAYdEAAAAAAAAAAAAEW3AAAAAAAAAAAAACNb0AAAAAAAAAAAAl Vi0AAAAAAAAAAADT5VgAAAAAAAAAAAV1W9gAAAAAAAAAAATR/UgAAAAAAAAAABfwu/cAAAAAAAAA ADy/eJ8AAAAAAAAAACI+hs4AAAAAAAAAASYBjbsAAAAAAAAAAA64sbQAAAAAAAAAAf8AKweEAAAA AAAAAAEj3lEdAAAAAAAAAACMZtklAAAAAAAAAAA7RKCGAAAAAAAAAAAFMd32AAAAAAAAAAVdjWM2 AAAAAAAAABZvh7HqAAAAAAAAATR8otHmAAAAAAAAGr6wAFfUAAAAAAAAab1gAFR1AAAAAAAg4CAA AEAQAAAAAAAzAAAAAAhYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/9oACAEBAwE/EP8A4egFANVw EMoOzWPd+pvbl1nTStdes0bNgyvQiLB2Mj7aETWDbsPxAzOLGyY9GnO969W5ojdZhhNuOfbmDBbM o2vncQG0mdwKdJjEDoqpu19Nyfbc8n59UTm3wM0eS3LilKdy8sw1a5QUHgJv2gk0WS9M+feU0rW5 zSU+c+oH9jw6p0MZTs8PU+YDbhlgBUFWrSBEq3aekGxnA3aOa5l+diOladyaPsPbP79TRE3l23va 9o0FeqZCwhTFvnpEw/soLZKGxQXjSKsRulN1ctzVjcqq7ma7e7Wq6nQaLNHSH6MykoeivMLdZhrT kYYhKi0A2O8ISU3wLhuFbLYRWN7bgsFal1ovITYtal7fndRQRbTw6vY1Yyq6nVFrHLNLR0aL2uAb W5rXclshjkEMys+4LZfyFwcpU7Mzv34iKeRrnAvecl6j3gveRom2o+0zDU0WMeUoqyhCmb8uIZFp aO2OZXKZVby6MC2USaNv3QVKYDl5YKOC0kdrZ8fv+u/RfTPTiYb2eS0Ozb0l2E1HU8a3xxDrSCkz bRseZg38yHmCKSnF40uz8S1lLKacqd8wVXbeS2eULtwDhu7PvGSgyCuCHlBe8QYbjuUZWRozyQ+F XOS5MXuxfT1GEPvIRtYgBNCwajrQ1zSMJYQoYspMcDp2vsQgVS4QwtDmoEjmlYKoS312iYq2C0av e+NI1lQNoK5hDk1AqDpHsEqqK7jbLCKZurBunxE2P+obvjp3BC5Wbs7ZXeEQChXRoSrugvTaBA6y 0usoUHTF1sRgIUGheL8sjLIBuzkpphppFii9jQ25ejnUFvA0eZ6nLlvdhlYSKzFpTz/6hgWy0P2+ s1G/ejTC/LplpsO9weriXtyUs0V25PoFQQAAPI4MmRt1lXNkWpAqcuQXmKR1cNlpsvvFAdQKZ0OA blYBrqZD6jHAuTFZMZasfTb9g8kGw6Lb7Np3fGjXppAu/nB7n4IIpKyI8GmFpbXltDAC5tuwNNtW YDa3z0bdONoWoEQR76j6ypYBfRjN1AXwGhQFG2o9obUc15Uq/J+8Ne0Ws4+YigjBtV33n1x/j0w2 kyAa1v8AtKrZaWLhr2mtttWCgxWOYAWFuWv0edXHgdItWqx8REVDkycMUUJgpLgssNkcWXLcz6Tc ZVo6m+iCW/rpgMUsnkspAAchua63l7YV02ZWAvZUh2K93/NSPP1ARnOfm4batsxZVZgxrMBsetve aWtc4w88q66ChVjoybY1hy0KUQAr1wbppwqqNUJtGx0CnhnDjwp7MfSuaR3Npd2qU3Tnd/CM1r01 EUxx0oXMeTyHjJnsmzErcVO/YxFOqEjt/MQCitarAtoN7iU9C9NtfBP59Y6DHaApxRgaMV6Chaqm yVa6XojBspAJW73KjOecO3qNa31+3TtX4h4plGCjkSXSSRtkAKy03ck0NFuOoOW42PmsC/AoK1Wl /qPDBHPuVpAU0bpeN8wUiC0oMWoj1JH/ABhjpiL/AMwcqA4OXBmFZUvMlOGst5klDxRJEdXhdQFr UnoAbUloZVcq+F3CD8GfI+lxW85WJyLsHLGDvIaHghKJRndufKcM/fpd4X1XGryAcLsEs1ErbW/o oFdhcRXT0A/WzRfO8HgyA0o0G6tA7sT4eU+hG45Zey92W6s1ZcDYd3aC3AtTjKQtvYAbYjTFNcCe dxcmRdQRyUvLx6TRU26ea+kTQkHbEO7UxNlbEwZABVb+5JAw7PSeY7Byp7cwCF2by66g6vfSPUIW LQNiK1bq4F4hVVFCb4Mg8q8cyy5TYXFAJQFYYCQvfm3l7ysCqAU01TWdJTpKhAq8kqN5rYSfYtN+ jXa+JRyq3tWFdIXclexczBUC2GbgcViDQopjApWV1D1WJXKjgo4SnObhhdnhFrajbFLQp0QeyDIB RJERU1DqTgULKykBLcmafJw9rgJlfeBb5JFBUO2WjmbF5uC7FLAG3lKwR7Iqf4g06IYRhEYCpA2m rbFGJYfv0FWCjfXeljIIg0FkFaWw2BincYlJoEip2HctYZhOAEXqTE0FNqjwSGhQmC7VpFB9EaiD dmALdqCgD+FkPE2LQnenuivB50gXfeFjXt6cRKCDILFHvOR87foR18amaKshFxxnIgP5+NLEwlWg UNACqfY3uTDugk0/j7+YAKFi1pQUA07+Bnj8STc1Skipit6uRFWp4wED9CsuhwAH8Qq6wC6NHfVB h5TDbq9NqrHYA7K48oCMUYvHYz5v+396gUAFq6BNrGfrNtixgvClsUB003BZ5IbIpNgVSMWld6hK bb+eWHErBGpArRz5pQKCFCjBjH9AJhIhYjqJK/McHS1XxG9VLqoOSx9YQUyNS1gDlufiQ+mA55f3 sFoTkArQQC6SxwwgNygaKsALay1/agoBwlwVPAEVaXUveD2ah8eMlPX/AMF//9oACAECAwE/EP8A 4fCaS/WDqjxnKyredzqyV2N4S4ZBm8bn5JivO75rqrZ7QACXAIktKczb+ua6p6uhrDUrIEG0dZTL fnqQRQWt1iQtUBtJSrSpmSsXW35rqag7Q0SyYaZuZ2eZeYl2ZuqaT6auoGyXZbzI8BgN9nvDa6zT S4T8eou60MQwSiJeuIThgKqJCyzMpV20v0ur8r3079Pf7tvOZkSMstK+vr/IlXtCVEo0egPr8Rag pttjt+WOxO80vR9Xl306cxzK+3/ZhuVRJYmgihzA4NCl1yt+tP28JvqzlfXf2jeHcyf0ekpz04WH Gn5/BEiG0Oo1tZvS5Kjrw7B/xv2RJ4Pr53ZrDMWJf6PrHTALYStq37cS7BNt9ZjPggRebTskW6Ro t6faFRq+kV4VsHa/uyzBo7xjaIxsUseu0UcMFvFNJo12/PTIVN/2QlIWiW8SuYSSNDCAef0JTt83 P+/9l6nTw3rTb89NW+f6gTce0QFOJXiufMDBRHWpt2T8cw06Gv7/AFDKCOdzzN/PWCXd2/zWaND3 OmZScseTOeOjyRzDNCjxLvQ6P4e32jk6Gv4TtC1/XtMf1z05NC528+qgAo08blRmIvJ384kuD2x/ k7nu/wA6dWSg8VqvdLY6IHahS2X6ValsDwAWx8r7obr8P3LOrfgi1kLRilenSCt91tXpeeMMK40U 8mp5n1xK8NllglvNgn8PrWUDFo9tILZlxFLwaNfq+jUJQStg1a7v69MsDYUtjbDQpgRo4T4nZTU+ vmIw8w8wDwJ1GH3S0Xd5/wCQ8SneV6IvOeEShiTT/Gl79t3EEfkOzn/fYhlOX4vaYZig9Sn8Pmd5 Tg0/jQhrfvUIFd244NI61lY9Pz0L/JbEopK0KcVuoq+OCCUHj9u3Z1YBrV93eZiMSjIG3z+P5Zc1 M/v4hLaXjyckSsQUS1en56C/KzfZ6c+kJ6X5/j/bl1mvvDFQA/pIBjR/cA3VMBAW5h05+t/hn+9B oMABQf3aLM0KPL/wX//aAAgBAwMBPxD/AOHysp1i6JyTgJdt1lUX4K8AUjLp+DNW2z46qhJZb8Ds 92PUn0eefbqu6GLLHwNFNIQslv2dTTEoFGkUVlWstWlj4Kuprs3iwA5JqEN+0UqVlbTBKz9cdQtE VYIQ3HF3anJFnBlYxS1+v46imvVzHLLpdGFko728I6Mz671rvWnn09NGMBZvw3znJKkMUUO275Rt BTjX329J3z3348/np7+0V7/8mWpczK2IBLIoZksH5eD7/MJ3fjPrtBaujgx1CthzcRXzEakwqhLU oyWafk9vljFLX69ozL+/T7FEYg0l5aTDk+qlyUR18UHtB1hbwrp096xa4PNjsHLvBEBxAaRpG1JG 4qRuQt4al6dMVrb9MG41il8CVMEXNiOSqodDvH3PmvppAxawrMmu/wCOmp3wgo3ZeXLsS5XkQzlW idn88QQS1L1vYdPR28pk6d6/Ok9XPTOImWiASH6/2ef6jV7WPgbrXj+SED2phBfrzmXX6rp3bVSx qXoc94yLK+NRZbqF5tGoYBz5n/Jjg+f304IUuXJ8aNUuAX7Rcs34lIxANpq06ZeJuvgEHqgH7j2g U0HywRmDRCVv646TLVH18RKtueTmUeAuABwRpx77/wCRFvKP3jvBDI5mZOOWv1/HRoqNZoVL9v3G 7LuPuO3aVDqafqVNZTFavBzEK3oSjFOYfTeGjw313/HRaRpzLz831tDNc8xbpgmUtdvTJ+vKW/xt eCe0IAaAHxEl1Lt6/joUz0QK4ggnXvLm/oRUK6FfyrU2cTkuqfMxCVFF+v46AcnXBLsXjtE1UWv9 QqdcnnFbzOgT02Ps/L+9FZEVv92rBNfn/wAF/9k= --------------Boundary-00=_C78XA2RUUGI4G6G00000 Content-Type: image/gif; name="Prairie53.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhPAGcAIfoAAAAAHUACwB3AIiNBQQAencDgACOi7vJwb/nuaPC80cdDWkgCowgDqoqAM0s AOscDQBDACgyBjRKAFw2AII4Cac+ALoyCt01AAdYABxkBDVUAGJnAHxqB5hSAMNeAOZcDgByCix5 AkN3B1aHB4t4CpGLALN5ANtzAAGRABeYAEenAGeoBXumAKqcAMCTDOCeDgDIACjBBEXJAF7IAIa/ DamyC7a9AN24DQTfBi3pBj3oAGPYDIfSAKHfAMfiAObhAAAAPhYONTcGM10BOo0AMZUNPr4OTOEA PwAnQCQkR0suQ20dMYcTM5QnN7UjS+ASNw04OhhENTQ1QF0+M4lLSKYxO7tMQdxBRwBjPyhgNzFW NVNfS3lgBahROMVmRuZqTQVySSd7S0JxQ2t+NY1zMaB2M7FyTtiMOgCjPCybODifMlKpPY6bNaye TcqhQ+6oSwe+PCrFR0C9Qly/PnHHSJvBOcjITdu+Nw3XPBbWNUfWQGDcO3HXS57aM8rhOOnuRgEL fiIBd0kAhGgCiIIAjp0Ag7kBfeYEfQApeSsqfkwRglEugooYhZ8nd8whjuITigA3hR40dUEzjlY8 g41Leqw0is5Ahd1DfwxnhxNqjj1RdGlijXJXgK1mfsdbiuZidQKIfS2FhD2MelR6fY2FjKGKcryL jd2EdQCeiROVjEiqgVWigHaijZGjhsaUeOKYegDCixS7dTPBjGDKfIfGgZW/frjIeum2hwDejhXu iULdhFbYfX/jd6bbhbTWieXWgA0AwBcOxDsJvWkAzYYNyZUAxrMAvOkAzQAexiomyEUjv1Qsuooa xaIqzMUcuOcfzgAyuhRKwkA2vW1DuXU4w5hFybs+uuhEtABdwyhivEditFdayX5js5RUy8ZosuNX vwB0tRGDzUl3wmB8znR7vauNuMl4v95ztAihyhSiyDqgu2utuoadzZuttMCWu9+szQC7ziyzu0K6 t2nCwHmywKqxsf/+6aaqqYGBe/IACwDzBv/4AAAB//wG8gL/////8yH5BAD//5cALAAAAAA8AZwA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnKjQnsWLGDNq3Mixo8ePIEOKHEmypMmTKFOGpMiypcuX MGPKnEmzps2bC1Xq3Mmzp8+fQIMKHUq0qNGjSJMqXco0I86nUKM6bEq1KkmpWLNq3cq1q9evYMPC tEq2pNizaNNWLMt2qNq3cOPKnUu3rt22ePPq3ct3o92/MfsKHky48GDAiBMrXmzQsGOQjMU+nky5 suXLmB9Hlpu5s+fPoDluHk1abejTeEurXs26JerXsGPLnj2y9WjauHNfts27t2+BuoOb/E28OEvh yO15BQAgInO0yaOrdMi8enOXzyFmh2p9YHfv1q+H/79uvPxUkMwxple5fmR7ogDUW4w//yL9jPdB m58Z8r16+u2FZ0919glYIIEF/gdUfvLV5yB+He0nYWPoMZjggPcRqCGA63WY4YcK/mThgxluNKJ0 KFIXHkHfCZTdi+KRByN4ND5FXkErupjjeP+gmKJEDTQwUABEBkAQkQIh+Y+SSi5p5D8KKDBQlEM+ idONBEk5ZZIHafmSj55NRKVAUY6p45n/ZJdPPgOtSaaXZjZ5E5YDCVknmQdZyRWYlL33XpQZEWmR oPYQuuZFhxYawEWEKorRAw8ElR+ADSqwkQM9TThhkUUW5IADnoL6z6cCkeokp1mW6eU/kB6pp0xB Bv9ZZ6x2jponp69SyOdrMLWq6a/APrQTpKFBaqyxGK746bKkjkdnsOXt1Oiu1FZrrbXQUnStbNl2 6+1T24YrLlDf7vfsVufaBAFW65YbEwrwxrsQDDBwJQBC6fL4DwT89vsQDi4C56AABBNMEgQZxdtR wQVnJIBG9GIEg8PjpsTvRRfr1W/GyXY04okf3fcwRiOPbJHJHtE7McQLc4TByxlhYJHM9tCc0coV Y9QQvQPx/A/D96KZZotgFF10QUAAEdG9QRvU7kH1GtQ0RE9DUZDVabL40LNTFxQ1Qk8LFPTYB6Xr rsAfFX2R2vY0jBHbBuMH4tpglFR33Ruh7DDDFyX/7bdI+ek9MhAYEQ74Rnhv5HfSGhm+tkV3e5yz zgwRYPnlAyVtkOUCAQOMQZoLFHpLniOkdEMEHHT6Qp9njrRAl3O+teoOrS765gTYk7vuuxc++UUN lW7QdjUSr2OO2Bn/T+oNPWv2QK0HrPU//FBU/eYORd95Qp8DY5H3GIH/e0iWb1R+RoxjqJHnkj5o ET8i9Y6R/JJfRP/uIH8kfoMgwc8/+hYxnOPcNz6P+Mci55vf7vjhvxCp70IlodT/BmSfBsmPfhxh kPjEh8HDhc9z7CPRBE8kQQ0WMCQMNB8G05es9ixugLwrSezkZyAKXgSE+7OOe+SWHxiGBIf7M5EC /2UHu9jhiEVYet7ZVKNEG+kKNA08oWd8yBQqWmUmTVyiFp2DkM7kT1xbpIsUmxJG14zxjGz54m7K yEbsJCSLbYyjs+DYEuVRBHlCi6MeGWLHK9HxjVkbXiD3SMg30gl5iExkdcCzyDxSZ5DekV4htUiS A4YIQfOZW4DmBsFKMqhEKZkkcUgCqI4Qalr2KGUqLWWPBSzgIq7spE6KBEtX2hKN4YKInN6kqjeF aiCmolWsqiQTUYmKIMdsIy43okqLBOkiz3wgoxY1KGqicpo+kSBGGrDMbUHETAKR1T+G+Q9XFsRN /1gTm9K5TnYOxFdtaudDhFm2bnWTcg7Z5ak6xf+qBxhEmLWiZ6rgtKpvirKQVYmmUiJ1z995xVSU bGhuGEBRikr0ohjl1kE3ipWMOoaj5/FotWBGGJvpLS8gBRdIcMBSjLAUByaJm0g4ZrF+9QdjIUGB SGnzMpvVjKQkAWpOdaoTnOGsIzgjqj2OmhGYFiWlbzEaGAQi1YEArWcqi1roRoe8qwoEClh7yOpW F9Z/hLVpYQMkVFUTEqlCzmiKEyAL7cE4FtrVcf6Za1sfdzKS8dUeifuQyNomU8GsdS0fqevf9IrA 3SUwgH+DYHsei5IXVvCydLVf3xA4EOZt54+HhU6FWihNBprWf5TF5PeAyMEOlmR/4BsgXjcbwO// aSSKUdxpYZoXIzSNbqu2GxrxiIi04E7kRtex3epkFMnjDeR6AoGuV3T7kxTaw7rWPd/lMik3ad71 hkEM4Q4vy0nxzRZC18VIbqmbGcrGELKLa2xGsNvAGfLQfq7tiGUPZMP+ghKUFyRjaF1SwN5hErbs TbCCxzjgBitmwRCOsEMdTGHANLTCGM6whvUo4Q2HRcIgDvF0PExitor4xMIpsYpXzOKOovjFwWnx EmFM49rIeC41zjFPOKxjwtz4xzbpsZCHTOQiswXITzSykpeskx9PDslQdjGTp0xlpUT5yljOspSF rOWGVJlcDv4yk7u8FYxmWMxo/kmWX0zmNrv5as0DSfOI4QxnOdv5znhOMJ33fJw8V4zPgA50F/08 Z6h2U9CI/jChzZxoDS86Qo3G8qNREulKh3HSJwktpn0iShFbetCb9vSnR01qjob6xKQ+tapXzWrN lPrVymz1nYG8U1iHVNa4zrVsAgIAOw== --------------Boundary-00=_C78XA2RUUGI4G6G00000 Content-Type: image/gif; name="imstp_usa.gif" Content-Transfer-Encoding: base64 Content-ID: <9BFDB788-4268-3594-94D6-93C3C1FB68E4> R0lGODlh4QFQAOYAAPONqgllpNMPHQWvEqKgl5IGCNuna/y2Ae1GYc5XBf7+/vmaBPruztPn+9HQ x1xaVv/yAP7G0u5uf+cCPptADv7TAHciAf2quwUFBe7KhxfhlBtTSv/7m+r0/QCh6f/2daWJT3pW LXb/zX99df/63b+8tfLYp/HivJYGRQBzG+no44rG84KqFgLH//3SMeiBQNPtqc7I2f6sM2yo0bz0 /v/3Ms7/6fvb4w4lgcDc+qamwd7d233k/hWcfOV9BPjx9O325r3KPO/v7EyRxdCmAv///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/ C05FVFNDQVBFMi4wAwEAAAAh+QQJKABFACwAAAAA4QFQAAAH/4BFgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uK4ru7y9vr/AwcLDxMXGwLnJysvM zZkrOdHS09TV1tfY2drb3NYBzuDh4uO4Kwrn6Onq6+zt7u/w8fLs3+T29/j5nubz/f7/AP/V00ew oMGDhPh1WMiwocOHECNKnEixokWG5wYi3Mix4zKFF0OKHEnSYkaPKC9hWMlyxA6WLQXBZLnj5UwM hW5i2DFJiIMiDx6AsimUXFCgQh/gTLSigwKIMBuuXDhVYlWrGKRmLcnw6sWnGlOKfYSBQKGXZgWN wFCiCIaihP/QKnqLSUjZUWuF6DuqVFHTpw6rXvU6kfBDr4ZHJp4IdqxjsmkHyR2EYYRbuJLvJqJ7 aXKotQT5LkX0t4Fp04i3Lj59ejXqra9Zy55Nu4Fr2o0f654bWZBnt5Y5x9WMSPggAm9XEkBeWS1L sy2PAl35QC/z5i+VYtjA87rlQWtX7nCwgbreB+WzqoX7wHL4u8h5AndbHjN56jLTcy/Pvcj1DT/x ldRoh0CjgGwr1ZagbRi0xpKDsc22YIQMTgjTaxY2WFttB4a124cywSSUZ0q1ddOIN31H2UxCISfU Wi9mtVZbStV011FrOeBAZSU0hxwBL20gxEsj2OUeBj+Bh5P/XULtOKB8guyo10sOzDjdDvHJFNwG hTBZBJFuIWmTA0QaWYSTSKXZF1MNHMjahAhquOCccjYI55s6RUhnnXpquOFsHYIoKGW9fXlTWsb5 RtwhifqHpKM/9bjDBnBVJtdRlBICmiDogZnmdipqipMOOzknhHSENDcCl5lqmeV8zRFCapKgccYZ qpwmpet0fuXgpjR3AstnDsFeeA2cdEaTrLLDBqtNoIMKuqihZu0opEyYKVpoTtk62l2pksZ62aVC GYdqjZodVYJ2D0BZBGibeourWqwGp+JbrzY37XUsXYZtrmcGhZ+AvDLlKzUrHYsBswwjzBI2CQvL LEwNEztT/8XdKJCDh9E6Nu1kaPp71rTcGpJllpK2Chy5Raj87midpouZi6J6a+q81JaqMo+lmrmv eqkWdWu7b7WbKcFrknbwNBE3HPHTCztsscJMR920xBhnvY3GHHcs1sfEraWDyMNtG7TJpaK8k5VK /dQcjkgy2aNlyLkkM5ieOleEl2jiPF1RbCO5o2VKBVeol0JkamtRQSH3E4xqdlvg0lVXDLXTVi98 deVYXz415t1Yw7XXH4LdW3k2zQSkTu7qtFza4Jb6XlqFS6ddf95RC/B11dV8Znq9+/2jkso5l5zh hty3HU+LA8xuX0gTaIiB1lDcedQWN+251Fhnj/3V1n8e+v/opJdvPiNSkkN96Oy37/7715B//vz0 A6w+5fDnr//+1MhvyAQADKAAB0jAAhrwgAHsRAgWyMD6OfAQdinV/TTGvwpa0H3+GwQAEYAAAADg AiAMoQhHSMISmjCEHuRgAhnRQEQskAEwPIEMQ/DAGhZkfRfMoQ6z4aEJIEACIIyAEIdIxCIa8YhI PCIIAYAAAC4iBDGkYSFeGEMZWlGKNsyiPQLAxS568YtgDKMYx0jGMprxjGH8XweTyMY2ulGJEnBi IqAYRQYu0ARVZIAVTWACLGrxj4C8hQ8v8MZCRkACQ0QkEj0IRzkego56zIAkJ2lFPfYxBJLsYyA3 yUlY+BD/AG2UACiJiABCIhEFo0QlEiWAACReoIlzJEEMKcnHPWYgBAYwQAb46MdO+vKXogDgKNn4 QyICAAVsVGUElGlEVibxAo6coiwtWctqzjCXu5whMLfJzU4M0o3FHOIxk5nKYRbRmUmE5SOnucd2 9lGX2bzi/CxAz3ra854W6KY+MzEBRbYxnEIcZ0A56E9lKpOJazxkK5PIygmss4ru5GUmbdnLaFlA ADe4wQkR2kR67vOjk5iAOdOpSACwEpmHRIEEJICChRoUlMf8oSrRucg4PjSi1ZykTrFZURBZIKNL 5OgEBEDUohIVgB59RAI4mIAEgBSYEzDlP1uKgpYiAKUq/02pIl8aAQ4K0as0XaVDDUFHnO40l2hF a09389MLeFCoATSqXAUwgXw2ggIrXSkC7OpTvj5VEiJ9I0FHOc5jsjSrQuSqMp0ZViOadKyEgGRO J6lWO1r2sh+yACE52kQBznWufk0EBQwgAQNcQK+hHQs9I5DavzoisOD0ZwQK21LZLrOctxUiYxe6 SnVGdpY6zUAuGTjN4hq3uC0Ui2Y/yMHODvCzoGUEXksrQ9QKggLYpQBKLBCBjLY2FmgMbxcRSN7y buKbbWTmbLFaUlVy1auGFSxkB1HWsxqAiseFoX73y98FpmS5pVQhAaEb3UVYgJVAJIEJVpoACoDA ihnALv9HfnqDCPzgu7AQr3jLy2EDnhe25DQmSo9ZVcRy9QIlXuhKnxnNIly2nsTNLzWtac39rpUg AA5wAQlcYEVYYKk/JORpEwACDhg3AyDQrkF+amEJ7EACGHZFFxfiRSpPuQNVxvKVx9vhLq9QE/2U 6ioda0xzDtPMZibiZdeM1he42c34Zac7g0vneDLgxvnI8St3zGOjRnkQPyaokBNgABJMlAQKMLSS cayAC9wAkTH48ye4tIgtW5qLVsa0ljXdxYDMgxMABKIhR23IO/JxotbEpQHeDGf+zvjUdE4rNnXK y40sF6F7fm6f/eyIQAfZBAgosnBzeQE8KhrHN2j0o53/LABJc2IDlFaEhsPraXl4M8ykzjYbQwDr Ot8yl6yO86u7PWxZmxueu8QzOXKsY137GZ/wLoCBgQxECTh42G42rRUXfQ/N/sDRERBADABQAGcX AtqSEFK0EwHGTAfA4RDfdKdHgA6KV1sdntigqLXN8SHSkbJp/TarE8Dt/c5wzQs8t8pnrW5x3FqF uY5rUet5QhIKoOCJ8DWDQSBJcLu52LLk9zi4e4EfrHQHBZBADApAAYMTAtoIb8QGNGCDhSOi4RKP eJa7OIKuU9zrCihS1wE4Ai8LEBQb/OEHa852ERbRhAAo+Z3LPdwQvJnkcochAxfA9777PeUgCLzg QaBy/0m2HBzsjqpzh9pseqIwhQIeYAdDiPND+JqDPC/3mw1gbKGH46cAEAIABPDkAsSgBAXQgdMH sQERiCDqiZi6Bl6/CGhPO4xgX8eQVMD7mjwAgL83ezDNTt5SDhGaB5R7ymVtRxnqd4F+X4Adoy/9 EAz++uY2fEESH/PGPx6u8K7nJ0H43UALIAEsyLzP8110IHi+GRY4ByiFIIASLL0AJUA9AJKac/5D WwRVB3stA3UEKICCUIC390Vdpw67VxMO+IA68gAOEHxd1gyhZkrQpAh5B3iDt4EhQH0hkH/5ZwHU J33XN3jZd3jw51bNpXhIFVRv1YL0JEscQAEFcIM4WP9wFjB+5ZcAE2AALMACurR+7HcCJPB+ocB/ gLZ6RRB/jeZkCCBwElAACFACo0cBAVBPludmoTV1ANgBBOh6AGgDZKgANvB6BfiFXHJpD5d1bmhx T9F7EAiBOlKHDnAOD9APzrBBm+VbjwRJd2ZZzxcCJEeCfReCIjiCB0B9FmB9J0h4zLd9LNhZe+ZW b8VZdWUBEMABRhZ0OZiD9DR5qeVgBZAALhAELEABPcdqb+ZoJ4BdTdVUoEBPPoAIPqCEPhYB7VdK BBcDMYACSRcDO/AAXmRPgMaFhiB7rgdtGtCMzuh6ZdgBVSeGGhB1bKh1U2ZxckgmdtiN3Zh/QXEO OmD/bXu4QR7UYmQFiP31gQkggiFwAAfQjvbXjYbodw7miCcYiTjGggEEg5y1V/SUABAwkNlFAjX4 iaAoioVAARwQeDXwACzwAKooXKz4cxRQARUwkJzoVJ1gAbW4CLfYCERnYVF4f6d3g07GAzywAjgQ AEMwBFxkTy/wXcwoe9VYgAU4e7K3cAnIRRSnAl1nh4lYh4lYlOD4ADowjvAgDgXEQuoIfQuQAERZ Au8olXeoABiADvXodxbwiIGnj/oAYIrXggFkT1ipAAIJARSADglgkDaIkDe4g3u1kJIUhNUBAxK5 ihVJAQsAj/BYARzAkZqwen8WfzdgUkIQAaaHAPhX/wJRKAAI4AEuiQMz0AErEAAzMAMxOZOxt5Mb 4AGg6QEbUHWhKZqtZ4A9qY0OQABBERRG+ZqvGXwogECH4APZhU+VUFWGkAIDkAKEwEWgYFk+wHdW uSM6QpVSmRFnqQA/5gOL2JcL4GBeCYnDxQm2iV24SQoAhlBlWU/pkJUBIJBrmQ5teYvhp4UL+QIG gIoPBgLrMpGrtpfZRQEaKZiXYFfXeZvoSQhR5oSHBABIJwGohwCnR1QW0JJgNAM0kIXIiAhT93/Q FpqnWZqj+aCFgHVbt2VF4hMlsBxCsByt+QCwGZslRl4L6QOdeFy2iWEp0KKGgEzHVAS6yZsDMABe xP8DLdA1m8CXxKmcWakAhIgOkukB5+CR2DWcz9mVXqlWO4qiMraio7BcyGdPizieQhoAHtBg6pCV CVCDkUABPrCe6UcED0ACDpBkevlmtgmYHKCRG6kJYJqi/AWlvZZsCiABAicASneD9jd6LTkEChAD LXmZCGoBnImTUFeNoNl6ztiojdoDn/mgiDqpbchFsdhgFHCcHUoAH7ocnjoCHTqiifgAJTabHnZd TmqQnPgBEICRrhqd35UCNtCivikIqORByNRENBoAKsmrLSCZwAkKfHkAFeAD5zCkRboAxnqs55AA PpAAHpkAFUCsFaCkj3hfKihdTkpPq/oBH1AD9AT/AbCahORHTxk5kNMaleqQpdH5nQoQnhnwkZCQ AOoZeAcAAjAABCUwAvDJarbZl35JrANpn5MQpwwwn976rTWgltnVaxYWcDHAQTFgg0q3AzrQkgoa AJQ5A5NqAwtBhstYjRrgAY06qbK3qNUohmQojWhoe1/UVBzwAS7gAvCIXfnnoZ76qa05AgQgquuS lEnZDteVoqu6sAPZqhjZqgvQWjRao7QqowjFRCjAm7xKAzmKo76ao5BAT0q2nwtJrG26rESqABTg l8t6DmAKrfDYqtTaiCiXrdJlZLQYs0Z7tOZZAUs7i+Y6rRm5os4Zj+RZs+kwpAmQAV4KCWDqZidQ /wMU8ABBEBRoSpGsNp/h2qqBWQkMCUNWSrZHq5bkKZKiFKCoZ4U3GANCwANchKBeNAT/x7KOKrI2 eZMbQAEqagEb0APOyKi5C3Vj1JbeSrMBW60PQAAF+KnL4bPrgpRA6w5FkLkG+QExe7R766oYeQBM W6M1WlXHJLVXVVU2iqMtkKOgGb6S+QgeCQFH2IQQYJuHcJHRq6zoMKzP6QPPmgDKagEXeQBsi5FM WLByi6LR27mde4vT2r8iaQHVi5HmaQHUGo+xGLAJMLiE9gLp+6U+8AIS8AEVwAJEsAAsAASRG59q GqYnoImuCgEE6wjOu7loS5DrkMKWhwA7UJJMF/+xkKkDQ0ADQ0CZHbDDTcGgOFmyGoC7N0m7MRuz 3loDRru0t9uMkroB14hlvjuz1ltPftm4OUu8lHK8+aepsKm8QcsOtEuDAXy0/IvArkqs1nsINAqj HFSqMDoBWFqaRAWawepj+cTAgKldmljBC0kC3iquUYldfTmtz9l3t6i2Gcm31WoIOAinsmQBNZhd Asyw2AUBCLzGnoDGxOqcA3m+bLuIAbuIEdysC+Bmfoy4L2CKHFABNAsCOZABeSm5atp0rdx3gAnD irDC7tqsVvqjzcoIFwUAS0e69heFOJDDOIADKzADqsugXZiokAptR8iJ8ynA88mM1TgIUTzFh7z/ tPVovTybxTzbxUJJonBMQM7LiW1qxouMt5zMt5pcBF80AKjUXChAAhBwAPeMAvQ8xwIgrgJAA1jr Yz5QAU0ItnxcAR/wfgz5AfDorEhKvX7Jd7dIeHpsyPwrCDdYBAUAmYwpb5aQuZK8ufR5tJsrkJls wAaWwOeKyT+mv9XrlzMdi3y3aqmMuJiqxBUwAjkABAQQwpMLmHibXcSqy4jgvCbwy+/qy+cAnmwp aRc1sQIHjKaLAM/ckjyww5tJk5AKqdXc0Olw0p4bv7a7zYJARt78zdQnzl7XdT07j+eMzlWlzp24 qp1Lva/KyQuAkXkbAOhgtQFgz6W6z1almwFA/9ABvYgCAL5aiwh6nNB73IQM7dCAfAC2ab+FPNPK ml2QiMYa3chUOIVERVBTiLl3zdScW9bAnADUmrecEM8vbcXoqteGPMq6lNOIW9TYFbM8x5r9yoUA SwF81LCPoNRLfaVjq6UKgKzNGpI+hn9Lt6cCcLpcxAM0MKSSWZmGypmHwIxgHbMszLnj3XSwp9Yx m64l6HeY7QNG6Y1ebJSkWqIC5AOR3M7ubNvVC519XQGdRgNWm6PZi1Aphtjg6wECsAACML7hq6OR rcdeisAN3b6XzdvzeeHHGwEmQACc/JfVeoM/FNI4uFIiLQn27ZboANVoOZ4qjpbUioSV0OGzzf/h HqnfFH0AF5kB0Avj0jWtFxmdFfAAZEoAI6B+bnaL2KWeeMTjFG5JOD64bGmlY2vKTN6EpkdwUCgA KMBFDb7MKECMLWCoGDZ14S3WKR6/Zx6/sPcOCSCzbL3eo9zePkAmdOgA8v2zYRy/covfSOuq87nf /L0AgC3Y4Zuj33DPV0XgNUrPOCqZPFCaoengxCrZXuoDE96+DM2qeMsBS5uzx2mEMEQArxjK1IqD HHRzRvVDp/2lRsYBEYYOXLTc4xnrbMl38BzbM520mMzhDpBdABvnmF3jH6DbSrXPDInjNPu4QYCX wX3BL3DBnGcAVT4ImctHhlzKgVsB2M6Wwwn/3T4mhUn3AwFXVDcoV9DsoCIwxBuQ3kwN2GT71E2N tgsQde7QpTS73vjO3pj9gA5o5/INtHmuAPYtyXlNvSYNj7bOd4NutXakAJcpoxNQVV3lz4s+x9cd RrT6tNROrGBKrIx7kWqZ1CjKquhqzQygex56sPtM0weAg0SVg0Wl6iXuCPbt6q9+rFjq1M2d86Zc yNNuvjMtsLtuAXT+iud5kdI67D9/CAKJ4xyA4wbAuF2Jl/yql/Tr7LpkbyrMAOl929vu2mr89c85 zz4mwwRX3edwWqKWUXja3TSp7un95OeQoy2AtnMfAHUv7xZa7zKb734fnRG9jePh70UJxmHM/5Ak iN96Xd4Ij/CD3gIhoLQhoACCXQQDAPG6WfFcpJwZgb3YawNOy58NXNsZCeMUEMi1XYNZ7KnncLAZ Kcr6+9EwL9Km3lwdfVdGJkkysLlTztzNTZ58R6ywnQkdTq1Df5VWpCM5K8ltipEavPSG0KU4buzY Bc94CdxW7+wvIElJFrcM8AF++7eXeuOXuoiG7O0+NgE/8AOl/Q5iju49AKka7OPpkPfvPvfAP++v d0CmCAgyC4OEhYaHFIQ+KjuNjg4lkZKRDyiWKBMTFCQ+HBAQFKEVowkKpgoYp4kLBwcLATQtLSGu PiEKsQFFAwEtsAHAwDQ0AbjFwwEDysvKKf9Fz88WraOfB58+PtDa0QWf3hUJDKfjpgwUFRCurBUF AgXv7gLu2u/12/famxwZGa2l5D78kVOQoNAoC/gSKoQmrUKraRUoOKBg4cRAUycscNiI7gMHHxQW ikzAAV06Cy80HqBQggCMDA8o8DPwoqaPmi8yvAAhssimDz4sCGX18OEodEePFnWIsGcRCwJuKLjg rp28q6ZQNr23QUOPDR8gOHRFYWCisuRWLei6IZPbtwlcqCsUqq7du2pbCWH0CNKkEg8oWXKrr+Q/ BefAnSqWSoGFQa0GBQsBIEQIWbJ0BeDRwgMPHpt9mSJW4tiKZM2WOdsm7YDJdK2w1cX3zlv/tU0D GSQ4lw4yvHbw4s1zqlBfv8iHFQR0fSB5QYMVthIXSQE20YgOdle0eOrECQIaS3768CHkdHwkIXA4 ILTkSpIkWDwAYWEmzvsZQJgvziDgp8djTePaa7YptcBB00ElwSk3XHDDDQAg0A5KKeGzgQhegVWD XBAMkpxaaJmSSAWsbNCDCG295VZchoRyyIuGHJDBXnw14tdfDzwwwgiDacLRYamcc5gHAXgg4gK7 +bDOMcP4EgwvnHkgD2ZEAqOAACRSAMxpqDWDDwXLoXMASKGMx8k97xCoHgXhMODmbsypE5xVBRQB HAISnvclCftUoEBkoWBjlCu7sTmIAqwc/xidniI1pE4rFJyQgHZCVVopR7YFxeg9JIkn1gIUuLAA ByQQ8AAQMdl3X04G7JfQT95YENAoRlFj262tiCVdT0IJgMAFETzIoABaJXThV+SJFdkgdj3EbF2F uMLWRYiJSohaMMLow4w01ujAjZI8oMO45CIm1mGMIZackSK6IhSYFcCCmS8pLFOklCRAIIAH/MKC iwALgDQaMl4m1FoFH21UzUOuPgOcrR2uV2gC1jj7DgLyWDVPOxJKUOem0PyUgbLMrifrrMsWwg9E u4Kcj3WsRCoppZZSoHCBDbuc3qcUgPBBBRkoABMJMIxQXwY04ZdBztvYHNYnFCma1K1Uw/+mK6O9 XiWPVBS2XMQGHYiA7CekJKAkZESlfIi0GqB4EQWCMEtXpXid7c8i3XoLbiQ6iEvuuNUpZgqRRlIw 5kDPpaD44ikEAwwzygAjQG/7+ksMmAI8AMswxAywmsHTeLLwu6GgmXEBSHWo3kbrRXYxnsINVwCe EtT+jstOZ0ArpCcJuntRzK2zqMv4OPooWpNOSvfN32hKvDYJiJWlAUDUIGMFDzhAQAksyKTqCwYs TR0DT0NgQQINQVz1N7kOj7VQN0jgzgXFWojh2Oc+ljLwaj+61okbeJs6VkERC5DrAQRI4PZKEIrk VUAFedMbjsblN3IFzgfjYFdiMHgKinn/KAU2gJwIB1CXF/DAcAsQAA+IYYx/GcNxlqDOrDzxEK9t Y3Z4SpNSirIAeOAJYxobjp1oVzuP3U5PP/lZgKrDHmwkJUBxYtnzineguaxEAd7JIgFsJjqykciG OisJqChAABe4wCEsAMEIQBCEEXhPVeJbiAXIFyvtyeqJeITU7q5GPEt1zUJhy9DTlPSYtEFkhzys oolE0IEUvQWFY7TAJS6BQAVK4luOgGAEbbQ3wFiCR5jQhFgMwMFTYOko2JhUZNylOMjVRRkUeAEC AAAACnSmF57xgOZ+MZoASAABKFBABIDZqEAVEIz08BXs6sHMeihzmVr7GDRw+MscbiqJ/16MCASC 4kehTC1ACJriPR7Tm2th8Vvg8RRSvihOTimrgSAgAhEoYAAQGIAFLDAaPfnBT6ZpwwIVKJ8F0Akt /j0kKD4YCx+nKJQK2e9+YPlGRNL2TTwWpGImapsjCTPASU6ykgssASYzuUlOdnKSE8CE4chTgVIC LI9qs4BY6gXLCL2AAiQcxAtq2S8q6aIIViJGNVEQgV+igDgN4YA/kzm7av5Qa/L4ITSjiaZmguwc yfKG4V5DHvJw4mTSqxUy+6ioudhFJXhcwFiJl56QsAl89nwAPvEJA/1YwADhi6NCZMWBp1mAADtQ gPa22E26/e4k4myoQ7cBNrEJ8lYTHf/Q+tABqlwdIKOM3GgmzkIBj1LSkiIdqSZLyslJBAalKQVT X0mUAHlILSk8dJf0FEcBALxAUbypgCwpUKXOeMAX71AcMIxqCQQYNUGuUapI6GRcp0r1uVVRZsba eY9A9VWrAwrLE/8TsN8xZ60uKyTJBsG61g1oEOBlawJCBr78bIAFBBgBB0owgtpZoGdLzUdWKbAD ApxiB98abAIfUxIogkKcZOSAUOzXNg0IsnxaTR8eR1HZXJmoB21zW1pApYC/lQukkcBkBEn7LdPy rVwdpkCyrDgg2PJQIwEChW0XAAHEvABRoQBGNxxHtgIoAwXAVEA6LnGepObXTlchYhH/l7xMq8Bu utQNWUlUXL6tQuAD/MPGycZClANHeZwjmvATQZXeKMcSryzIwAlGAAQ1SsAAtUOfU2Sl1cAm8CI7 4KJ3mTJFm1nPhhdqcIZ8sL6VGM6gbKrVhb2SWbOUxcOnAHFoRztivd2IgiX42ynoDJtaPdFZavXE WBxCAQTcNiKICQXjUDcIH7C6hz+2RG+ISkzkIiy/QVQyAIqIMag+VYhmdg+nQTGg2HDTUk5c1ne/ bDD9TZgsZWb2mfkJgh2MYALGvQCcJXDkZ/BGLPw1hQLHvcUCr9Ia3e7JWYQiZ8aGDcMO/opM17ce MtFtqwq1QA/23WANjyNEmjZFJUPs/4BGVPoHmwyMJHQwgkyjWERIeRRMPQRjhzjEyyWMpW4pQFNW JyBNg/BxMIt6iaLWGqmu8bJCcv3cXmtNqlA2M16aNTUI1KC8pGrNo9DNbDkWtlI9R+I++5kAPBng AiaA81rvSLZwU2sHCeDyOtjzvLMogIa7aqxjHWwiplcN5xJVB1P2De8TNVJFb7mEWyQt4m4hXAin imD2FF6CT3rULXd8SAEG4eIe7l3Ug7qvqWmMGCEv4KbLqEe+9v7xARC1dsCU6lGLnHJcxw6qvoY5 sMWJDZx7XnRQ3O7JILPsoJv+9D4ZugWkaoAHXYDbvDpQ0xMQWHLkGdSuUWvVQaFz3f9ro7En4nqG ALQ+6f2OEF8ke1cYnVm0u6VHE6hkwzF5qrjHHe57qX4jsoeCHNVd7SkNZSb0h6TzkX6AB1CYQ9ah +9reFlQvINECEIDTAXSDHZ+ox49NDsxJYq3yC0EnmPdy0LV5COZpYkYNUHRQo8d+0YZ6EKgnhUIR k4InF0ACSScBS6co70R7jrAb64F8HfKAxVMWCnZfLXMhjrVvXcGC5HQUEgVFIqhWZIdhXSE2zed8 KfUW0hdalYACbIZ9QmAJ1/cAjvCDQHh30Dd+rEVmfmQ4oOcK1uB7tWVqbnV4s4RT9xcw73AgsOZ4 RPY8DaFypnM6zhRVzfVkR/RlsmL/UG54FIUVMEoyhSQYgXaoJ6tHOxfweho4ZxxYDROTfoSQcr5H PIajc4jFWCKwgl/hFV+xAQDyaWrDd190YfyWUSfib9QicAk0AoJVcH4zAo3QN3sxLjuiAztghAzn YQGnA+TwFIPgDZ9HMuclHbPhba9kf/L3cXznaqnhOQwFgLTRcrCjZLVzOqd3TN1kF8txSAchhwnF Tnc4jUGXh831S+kVibLIOh2yDp9Sh9UlU0OBXlyxiMuXIRmyAZBIiXFyfpSlVpZog/CmghvgFAg0 As8gUg8ADaK4j0VwKvdghEWAj1hDNd4FGd1YZsqwd1yYAnuHDT7mOcCYWMJ4Q1K1/2QYCURrSI3/ RCbNyIDYQGjkyJEkGWWrx2vpxhAjIlHfwDPgWDzWYD4LxhUOpgHnWIPqCImRmIDwGI9kJ3xc5xQ7 og0E+Qz9CA3+uA1FuSn39VqIlHsUoScL+Q7NYA+p8TliWJHTRIDG9Wv2UJIlaG9+5ERZ8pJgeZbQ U0ApyRphllZRyYaRAUbneI6O+Ij1WClOqVYLlpPqyG9AaZPEsZT4IJjVmAgtZiAzySgT6SXAyAxY mZXo0DBBhHlfiZYGAyYhmZmEZJaW2ZmJ9XOc6XNjxZekqY7F000KUZo56Zl4CJrEw5iNKZEF005j mDPNZFWsKZqFlZu82Zu++ZvAGRycwjmcxFmcxnmcyJmcyrmczNmczvmc0Bmd1BUIACH5BAUoAEUA LAQAAwDZAUoAAAf/gEWCg4SFhoeIiYqLjI2Oj5CRkpOFK5aXmJmam5ydnp+goZuUpKWmp6ipqqus ra6vsIMrObS1tre4ubq7vL2+v7kBscPExcbHyMnKrisKzs/Q0dLT1NXW19jZ08LL3d7f4OHi483a 5ufo6ejc4+3u7/Dx8uUd9fb3+Pn6+/z9/v8A7TljJ6+gwYMIE06iF7Chw4cQAQ5USDEehosYR+zA mFEQR4w7Nn7EUGgkhh2ThDgo8uDBK5EuKxJqydLlA5KJVnRQoI/jvYv1gPITOhTDT6MR7RENyJOg zKfeMBAotHGqoBEYShTBEJNQVUVcTwmROgyrEKiGaN5UpJMnPqFE/5f2k5tvKd2Hd/s1Rct3GVmv fz2O2Np10NdEYU0dhoW170ybOBG1bUCZsl2keStXzmwZaWfNoEOLbsBZ9F7HqIkFFrR46+DEgK0i gj2IANeLBGxjGFwEK+6tF0fQZHnxwVndu4tsvIlhA0rkvK+CdLCh+NkH1Y1e7fpgsG+ytlG63lq9 MPXiHrM7r+68CPINK9VCZttAAeiLo/GTxrAZY//PoekH4H4CctRZgfyNNpp9TqXm4CofubTYTVqN JOFI0XkUoXthYeWSWVhpdVNIZNGElQMO7FZCcrYRsNEGQmw0wljeYbDSII2N5VKKkIknSIpnbeRA iMTtEJ5g5BWio/9yyV3kgEhP7kZjETzWZOVaOdV3X4IBJqjfl17yJ+CWIwEIZphmcqkgaAw+6CYr qzH5kVW0sRZnSYUJYttKexax4g4bdLXbVzQFSkhjgmAnY6IuNZchjiTpcJJ0QgxHSHIjbFCEoYId OV5yhEh6Y2OJJWYpo1fOl6V9tozZKpo5uBqrf7qMCSYtt+IKq6y9tPnmr6fE+VWKMHqUJ5OyHVIn h89N+ieohBHaaGGWjvgXTSUw94CPvZGEKLOnXqXpBq9Fx5WnTSbL4UeEGYuqAy2hJx9xbOWgwC0X 1YqBrvzii9Eu+dYS8Ej9zspRwcDc2yCwDD8i7F9VtkvVnZcee+T/kX9y6pq0mxb2raLXFmabx5FO 2m2lx1Y1qcYqTjplnJKeVbG7NS23raHzYimZvf6+2u/A+/YcMC5Dz4pwwUUf7YvCDTcdycOyYaWD xLGBZfGkGJ9E5E0rJWeijTquOJhtGoW86KKQFrFkleEmmtjWNqY42E2vqbukEIaWGlNLfXqYaiOz 3Nuz0T8HDTS/SQscdOGMNw7MLUw7LTkjUBNSnUhzYs4RtyblhrWzk35nFd3DMdcedMiiipxxh+J0 HlfXHcth1BhZ5RvdW6lLpXoo6Y2qtmvlHNkhgedysOJI/+u4z8jrOnTRxxP+eOSTV2+9MkCiVfzj 3Hfv/fe6UH/9//jkv9I2RduDr/767OMifiETxC///PTXb//9+MvPSgj891/+/6gYi8mgkr72GfCA 3HufIOKHAAQAAAAXiKAEJ0jBClrwghJ8YAP1xwj/IYJ/DAjhCUYYAgCaEIAFRKAKV6iLBk0AARKI YARmSMMa2vCGOMwhDiMIAATEbxEhEGEJCwFCEY7wiEM8oRKtF4AmOvGJUIyiFKdIxSpa8YpYlKIh XggAHXrxi2DcoQR+mIggCrF//DOBERlwRBOYIIlLjKMcq/fCC4TxjhGQAA31mMMHipGMhzAjGzNA yEIekY1vDAEh3zjHRjoSWFz8ogS6WEME2DGHKKBkJnMoAQTk8P8CPiwjCURoSDe2MQMhMIABMuBG OD7ylbCUSfwo6UUY1hAAKPDiJiOwyxt2UocXACQRR4lIUxqThKpkJQljycxmIqSOYLQlDXGpS03S 0oa/1GEoA0nMNnrzjatUJhJNaIFymvOc6LSAM9fZjgnw8YvSnCE15dnAd+5ylz104AyzycltDtOI 32zlIk/pSutZQAA3uAEG8+nDcrJzEQ59qCsmcE1t8hEAncxlHlEgAQmgwJO8tGYEcAnDTfIThxid ADeLeUw3FvKlGUhmQSVngYTykKETEIBOd6rT+EVUooWwQAR+ClRUTOCS8PwoCj6KAI1ydKN8vGcX GzhDqp4Uh2P/XGlAYarKrnp1pk2r6QUeiFP58fSsApiAOos6iJreYKhsNWpFc1hPSlITlx596gyl GtJ9evKqNkypIQRpzJd2FY2ITSxYH2QBOzLUh/NDK1rXGlcL/CACCaVsXClB0TDGc6S5JOk79yrS Xf4SsDXspEr/eQKYxtQA/SOmbGcrWw++qbEQbCBk6SfZyVZWAjuQwGVvoNllZPG4TsyfcperCmh+ sZeg3etFN8lXquLVs6slhBlbW8jDCpK2awyheMXLPzfh1pIbrF9vfctWC8QgjwpVQHGVgVzkLve+ 92tuZ597zXnicql65esFAAzSjgJTmEVIrDljC16WtvSQ5HXQ/3nRa7/1sheoB41BR+NL3G84sR5P BPGHOxBiEo84ufhNMQdT4U6kcvKG/e3vNG8pYxoqNrFdfYGOdVzEbm7VtTA1JQMWW5EJg7LCFubp fJ1pgQIAIAYCwOwFfnCBJadCU4s4sZabKGIum9jLTlSHNlYRvxji8cx4TKNLxWnMVBpgxzweL0DX 7FqvJvOlrXQMbvN5ZN4mWckYpkABNFyA4ArXjlY2xQawrIj6HlfM2WBFmV2M5krfMAR0BrKb4dzj OReWkHYOdVcNSWSETJjCflZyOlddACbroAAliEEBgCsAAAjB1oneFKMfAaNdIyKKXQ5AsIf95TCP 4BnHhnQ0Wv/BQDNb+tk2DmF3vYrKN+84AZgeLwlv7GZRe5uQpTbInjfYZ7Pu1JwYrKAACpBrhpkT ohYAAKxLUIBBl0AAQhipM3K96EU7YgMasIGvDwHsYhO7xE4cgcKPvXAFzEjh8RuBiuf3CgbCEILp zvgEbXhBAGR7yK/17rXTON7+LeDkKE85/wwAgpa7HATfRiVaTn3U3eZUAOi+aVnp50AJsvt6FtDx ks0ZAArUugQImDWUERDcKf+g3RsQgQj8rQiAa2Dqi1i0o6XYcGnESAVgD8kD4jf2icdi4su1JA2D ib+Pr9zOaBwheUOQ8gWgse52D8HL9x5qcEOF5uXGeWN1rlv/n666nFyMYLvNK/S2Et2J2yI0CmIg 69z+QAGIznrUBU51QfT78/02BOi3DkWFR+PrIUm96lH0AHiZPSGTnmEwFfHxIady77XnH95DUILe l8ACeLf73l/e93DHA/CQHTxZNbjBco6SA4Kut/TZbYHEL14eRBVE9h3/gnM2cQhDCAAOVsADHgS3 3rGu99Ivm3lGAFwENujA56UOfxvYXwE2mDro4S//ImxZ2AYXgMnGE2G3equHIgjoAM7wAOZAEQzk WP4USN+VWHOHbcCHcrzne71nAQeAdxagd8MHc3D3d2OVXkc2VsunWw1lAR/AARxATNE3ffVWTj13 fe5QTj6A/wg+sH1FEHQW0EQzMAMBoBMzgAPh5wEIoFMI0HsFwHQFEAFCMEk3IF+NYHVSt2gakIVa KHX31wECR38aQHX/d3AfNoCod4AJmIa91xLOoAOR5oAM9EAINljfJWe6lwC+FwIHcAB4GGtpeIEp RwEgAILDN4JPcV7yo3OPhQDmBAGO6IIvSALQJ4PTZwE1SBEWkIOLsIOGEHTdFwA0IIRRhAMHJQCx lnQlIAGFhlFQSIVVCHBWF4agB3pXZ3W7RnpNlGwFmIYJqIG+uIYPoANueA1PYT8dVIe6twAJgIC9 p4fLqIAKgAHPAIgpZwEh2HKGKBOICEqFJz/n5IgL4IiO2P+CkTiJlDiDL2SD4aCOPdiJnyh+Qyh+ MaAA4YcDtRYD9DZoEiAAUCZcCtBh/2aLG+ABBOkBGyBwBWmQUdd5goCLuph6zPiLEvmLZYcC+XMI PkABGplOpLBUhpACA5AChNBEr4BYPnByz5giKFICIbCMAxGN+5YAPtCBC9CBgniNIqhKxvcIGbmR 6MQK55VP3mhOFVABHcgBEFAB4QiOJxeJO3h475YQa9WTGkkB59SJQSV0Q4ADARCEXBmK4qcDIaGK FBADDQRlUAhXvCaL+leQC5mQBwmLhVBwCHdiD7mSE5mXGvgAAKZchUABPhCJtJWRiZYChmkIoYUC ReCRIDn/AAPwRDzQAguzChSAcgnwktKoAC35DB4QAB6wbz15kjRpjdd4WKoAmM43W+VklYSAAtOn mIWwVK9JCLjFdueEkkVplAuAlEoJjrq5mycAfQ4CmIIpZ4QJUd1Hj6PYRDwQI/UGAPSWiqsoAUs2 i/0WhgQZdVq4ndvZAwMJi9YZngCIcDOiEg6ggbmRngSgl77Il32ZX4JAnM/ngh9QTjVQA+DImoeQ AjZgmCIpCJn0QLnkQ40ZAOVnoC3QmST5CpV5ABXgA87QmZ8pXwsAoRHqDDKZAJmYAEZZlKQZgrC1 k4yAmpkIiR9wovf5lFbpmvoUARegirC5mBZgZi/qmm2l/3jltIcLoJQLAJXhuKO6CQG7SQKa2Bfy WZUUcKIfcJ8QgKSJ4Ik/2AErYIQdUIRDQANDoANJiAAxIGhLtwOMGJ7x54X5N3VhqAEesJ3haXXZ GYb0Z39eqH9ad0UjgJctcad4eqcKt556GYzCOIzSEJ+CSZ/46YjlVAGOqJRL1piO6Z+LmU89hAIg aaA0IJmRiaCSmQqrqX2HipQWOqEUsIcHYKHOAJgauodJ6aAV8IHcdpockImSyAFLKo60uoMLMGun x0uKuVSYJXsa1Go9eKhGOaqAeXIUAA3SGAAKoIy5eZRKaQLCyRcUEInH+gwUQKvViqGIUE7v2EQ4 MANTiv8DWGqPXEpv0DloAIBznhd1ccqdZxqLsrgB4LWDG9ADWqid99pvV5QA/JoASNp701hOz/AA ucGe2eKnwjgNllUE0/p8LfgBtAqOFpCbRrmojumYS4VLkdpUS/WYkdkCkkmQINuZqJCJEEACFNCD EJCREFuh1lqTNOkDPsCvFWoBFGCUqeqhxDCtFhCrshqxQDtrU/gMCZVQAFa0LvpAHZV0wVqUe6ih ykiTlxmhnpkAPXp4GYCysKCRPekKDcsA2Wqtjhi22noIPuitQ8AD8OhEOIAAzjl5AlCW6mo5tHiv GmCvsoiyGimrKFqoGlmvWQieGzCGX8avsuoCLiCqq8r/gPumANlKsHx6nn36p4DauI5LTPSJrVWp qE5bsfuJsSPVQADGqwAwAZ6ZkDpFkAtKCQ7FgRUgnBZwskkqpMqokTU5rHW3g6eKqB26qoYgfalA ASTQsxyQchFblCjHiEW7vEV7AQXgdC46Vp0EQxagmBNrlDO5h6FqmZyZANr7DMmqAAmQtSnbChop qtrLCl8btpkpvtnavuJrtkKnAEKouh5AA2proEKwboSGjz9XddfpnYs2StMKsUArjkqJhWE4CITb RAlAAieauOi7h6vqDBlJqgTrexFJkaO7VN4YP18LidgKDTfbgQ56wpQFRQOQSbqFAiQAAQfAworZ RAQp/wBCKgD4m6mTkIkV0IMOCrsV8AGhyocye7vNqqM1C3OuO6w6WwT15sQC0EBPXAohfAAkcHKo mqgviMVPxbzMa2uyJ70q2FQ96LSquqonaZn9ir5TK6EJ8GZaewpIer4TTKyuKkLvqwDK6r7OEL4Y Ol/cagGSyZc4wJUg20QoEMXn92T/W4Xe6Z0EDLEnjLMI3KwWIJcNaUUP/AGIewC3icWWtawJIAML GLm9OJHu6cE+tQATEMI/K45k67g02YHIq057rACVGgArPLowzFQeCYo8YMMdKAAfq8OR4Lo+/Lop O7FCTKxWa8S4S5UieL1M7LtNqIpKCEOqSApVvMW3q/+qEODNB+BklLZDKDi9LwRDrXa9FFyUVkmT KTfByhihVqtjcWwK0+qIPgABJ3oAMGzG5YvPkehG2SqhGFqtBo2hnJiVP3hW9cZTUKiKEgBl7IiF kDy7DkoCqurPSfmCG33JjKbJEJy41UiNnuwMpKwAGeyHaojKoxs/PgDTz1eV4ji10lCZNXlyRRlm NFCpkomx+URgv/yxHiAACyAAInvIO+ygyQzEzayUcxzVBRsBJkAA7NzOTXbNSTd9HQWskuADz4eo 4ty54XzFNUnOGqe06PxCXV3Gw6qqFnCq8Iy+TquMNLsAbxatkBDVgCmqLFixHFCxFeuklCC8iHQA YTv/oXx8oc9gtQHdVkInABKQUC7aUU6nAOsGAGDKjptyt/L6sz+s0UWZlGIt2oh6AJ1nDZsswcEX z3mqwU8CkXi5l9nyp9HQsBxg09cKATYNk/uGxSinrLkMspIpDCzcVEHtmP4XmZ3JAwlZkJMJUUzt usLpA0J8okm5mz2qnit5AuJFACdwrW9dlNLXQOvGU9rs1Y+A2xlQ2lhM1uLsZMs338u3tOnF1gaw zmYM1w5g1T5AsWf8mzl9AKt0zyOqkVlLW+f0AYAt2Dt4SFUZCQ3rRsPa2xjqoBYuvie50NwXytSQ hPj2A2oVCdrpnaBd2uDM0R492kZJdaotqwLe2jCL/74y6wOxjYYUSbmVC9a5fdu8/QzKmpk4zaPC XalopAArYNwTwKtkrNyny5xS5J+O2gih+qAzWQE1oJGIWsAI7ILC63W5QcAwrLjj/NDrJn07ld6R wOOE5N5G7KBljcXy3VF0Xud03o0WJwH57daKu6ooQgBVicV1PMEZYMWPjQhVmQEK4GPfVGUvvIOB 7cnlREEuFeFUzgAw/ta97b0nvOmzDMjJidkOXQACMGU3MLeQAHAmDrEdWtYpHs4rzruovcCqzcnw LOO47gOqJ9sSibAJ67gfEAG9LeQ2ndDbq6PC3QIhkN0hgMuZOgCLueSK6eRN9JIDcbEXawON6ghL zP/Rudmk2J2oyqye6ukMYHvaMAsBpD596yYI5a1bUzyiL0hIMvC6Hg2zHeqCGn1yBaBK0zvGY8xz MGQA23zVFGwB4K0A/Q3oVnl4FCCTLsDgh24IFJDgJOBGEhRqQrfPO/jonghnOxZOGaCRi9CwH0CY Mvu0/QrgfLjGO7qHHK59kd2EAGBTQ6sA+8jZmyICPeCdrE7Brj7a/qzv4KybC4k/CcABJI3ruD7E CVCAEOnS70kBEWAANh3kjuuyjP3M/nqSoAiyelihzZ7LRfCYkkkDUNTTwl3kuoztF/ufjcCB4AzD +uwDBXC8D1wN5w7D773uD03q7T4IMrjekkhI2hv/1R0a1R9F8P+ugvajWx1lAGTsunRNASdAAM9w AryYGy0HfEKaARyQkYpQ8aNkAhcA8qj/AjJrTk+ZiTUus6gv8hNPCMJ78uY043TN4hT71ijsjgd1 85QNSoI3Caq+AazOxEF/2rBu2jkLi0jPyUzf9DCr67u+A5JL29miyq1c9aRq0ENMquIL3KvpA04U Ah4XAsSdqQjqAQd6qc6A9iUg3En+9m8PCXKPqI4oqjJL0+IICAcUDAqFhgwJFBUQBwsLBwUFApKR ApOWBUWam5ydnpqDHBkVC4ocFY2PFIIVp6mQBgYSCLQTtre4tBK7spmgjI0HFRQnCgQEhsmGJxQQ /xCoHx8Un5sUGSQnGQYv3N3e3+DdPuPk4Bnn09SDPgfOFguoB/KoFYvO98/1jfUWnhbcFhTcsERQ gIV+1BJq2iBCQ48NH2q4kCcMAgcSwhYd4MARY71njTb0ELEBF64ELmQ4WsmSgsuXMF1SlCdExY6b Nx04KMGz54MHI0agQGGLgoyjPgx5UCCA4oJxCRKwXGABpI8ACmhobRGga4ABAXi08GCphVkPXpmS otB1RdcBcAekUPiJAruKB3y8dPaBhA98HCgkYEAY0ap4jipdmlSEEi1fdDfpTQeKhCjE5Mg5zTwO RYFYu2qZnEALAa9YFlBssiAsVT1ihY7Jlg2idv+zjxB8ICwSNaY1EudixQpH3BtnH8QNoEs46MM9 C+z0zcOND5+8Z7s5/bNwQZKEGwezR/bE8GE0qy5beRwmqGNGl48qbNCwQZkhlKlawp/K/5G8DDXZ hJNOPfmkw4EIKkDBB0c9ZYgA/snTXyNV6RMADWaZFUAKcQXgAVkkQCDAh2jRkBWEehWiFQ1fyTWe P9P5wJEzMylyzwIcHJCIYO04FQkCmBCUiSQIFCABZJENckB2zWUAEn/TSTgVChZIIMssCJiky2kS pNZJM1K+Vox9ypyQwEfDbJLALmzuYo0owQm3TXF0hiPcOeiEJxgnFHDgnDMUvFPPoPZUV911FYj/ p8k/L4R30IsKbdCBCOY5U0ECrE0GE0W+scPOAvORRCZKU+3XH5R5ARiggDkVyJMODyCIoFENLpCA JfFJx5KEKfTqawpevRUXXF0JwMgCI16YVQB2CfDAhSt+NRek2s1j3ZIwFbDIIgtYxFGOEv5Iy2KM NbblkUgy98GSfPo5CmIzEQrvTJ5RcKVopJlmZSxFqtYJa4h1O0wCY5LJDJq6gdLmlW5akwGc2sgp 8cQUS4znxRS0uUsC1TDwJwQWYJpRoYbiEw921GxHbWQMOQSRMz5Q9dRUM/UXc0gj1WcfBS60dCrN jsiTgA+rstpqgbHCKqsO9hqg0q4jSyelBRyk/2DDsFjH9dILPKyCLA8sLnvissEOtTKf0XEADLvm PqbtoDM1Uklp5JbbdpuRZBITn4wwSUI0UscrbzzzUEQlm7VsCZoF6WoHT34gCXbC5JSb2Wc+VFWz ywUnYHPDDSZcgEBMD19s+umop57BS1ZewPkFsnBchAUeP+cAAdANLq88ipycaMoAnU2NpA1VCpIg MQcdt5SOSPUIqCN1UJJJRq1EQUuOOvpSVGeqULTRO7n6wFBCETWBvR8YsPzgUmKqdgW9Yv0SXBS8 gAAAAFAwVgBj8eDBsxfCyrJmgQIFRAAB/hIedGQUqEdpgkjjypsE8yaA0gBJEkLqRAF0UZpMQP/n b9F4yTj6xicQWkp3HyiUvI53AM/oqzSn6Rdd3nEsR9xDRztySQI2gjkm8eJ1rnOdLEb3gA345ohI TCLrABDEz5HgBhtbVAU+ZgGdEOAlEVqebnzgO0WtJjzCI48IivcyS/FOeVEjXCOu9ziRaIAko/Fa KRzRwKGg4AGz6YlOcOK97+WEQK6yI1GIsgrAUaQAjiBUuBD5Pn1wiH4AQMALKDAANr4gfx/i31kC oImuDJAWKIgAAcM4O2EERoOTMI0FgVSQClqwbnbbxAR9UZV8TBFmeiEhKKb4MVtOUQHxINkJKVKP AqBAY7HwzIsEhQobOuNb0LRl5viksWrS4gX/QWABCzYAghFswAC12QABugmCDYygNkXsJjfPyc1t boAFMADBuVp3pXRAx0/uIMAOFHC7K2ZPe1LT5Seo9gHZkbIIxOuByz4Gt0D5Z3fy0EswGOFGEUiP eqlwSWoEeUfZ6HGPfPTjH5FWAkHaAgV28VMzMeU8p5RiI2rLB0V6RQEAvAAew9iW/SiAFv59iCuR 6FVXCDgUVSbwbAA7JScwuMHQrPKpk4AgJiD1Ty5qBEzscomMenmPb71iUDWQKTGXdDhedOmokXmH wBpxD7hNxxGKooAqn1qaBCDAANl0ABBGAAQgwGAEROjrMWDwExhkYAQEgAEB+AqDv2ZAmyPg/8AI 5PpUNlFmQX+iwA6QUYgd6KSfx3jHKdQIAcoMtB1KDWPLGrJQrjqjFKtYniDORBEIiEShY9SZIeRI gaUhCI/H4AlI+yjSAYWPJw941YEMwbTzkEIqDdQeD4e5j3bU9KYQUNALFADbrhQAAsGyVAHgggIE KoARdjxoUk3bGILMU2MRxOC4pkpKG7Wnb30axnkMxREF5OUuEPVPaTVBJeF4aWUWuJ5b4zaoUnix CHLlnl0RIOFbISAID8gBYYFwWBYcIMNAIAALAPuAv5bAv930K1+1yQIQwIACFeTeKncDnXto1hic VcYO+jTaeLFtoAe5XmrPtloNuOwvJbPIU/80GuTDBFM+PVBo9HRbiOtRQAG+PRBwCSDcm3yvuIAs gZbFnKBC1PgZzvQWNGMq1ocKQpLwuPJLfqUtR/igzgsY7wDseKxQIpCU60Wle/UlAQAgrpWuZGXj 6HLEeMiob644c8k4kqg+KS9grdkNSg1gtjAeJFe7czCjo/vPBFMgm0U8wAbeWQ8igIADRAgPC8KT AQUAgQirBsIDtHkCEJQABJR9Kntt9Iwb43g2x8jvvAacMtQqqFvsfVFCjeyyWiZ5zW0lrQWijNs3 UvnZV86yAoDbZS9/+Qd+TG5PdDACMi93t8JM8gkJ9zhmb61+FZjkI+ucgEiQIs97NqAE7Cj/yj97 2pTRxqAl6IroV8ZyPKGAZlhphGSY6CXeXW0FB7iLRuUxW5YUWDSCSw3Gg0JYFCzIJggykMIKuKAG YV3SX3QTIt08LIUgAOc7s3GOwPwz2rmzlLHJtAPafvXH/oiQqT8u7UlRitoiCbq8IRqmJXHbyFOm HgUmwFFbbLncRUO3EB6Qbgeou6QoKJ8dbyH1qStSQoVLMJyze2UILGCScclbiBDZ7z2LkoAWRCu1 Ao1KhSO6IKuk7+B9SZ1nqJnSbTeUxhWQPCnF3ROCN7nm65KAcwQhCLWRiJ9qUIHa0C43VENFeCrg auXkXDnnAPYy4SH0BOxTx7H96jQT8o6D/1hEQQ9OSEJZO5+HCMrtUlsJKbYd5fk4ZIwXvcXWTzqU WwC33XskO9nHLvbta/8mD3DAHZNrUq6bzxbMlPzbXSqMzF2Xji/49+jg8t0KfBcCeSNvwREoSPUi 3BNMdXiD5nAiN0N3wWC+ZFX6kH7VoRFPUXkr0X7Bt3kUyByCMScvkAC1YXrhkUJLEmkVoBsg8AIW kwgIhlORY3s4kQg5onx2N4Gr0SPywBrRFiljJGUP4RDGJzDUsWD5wS3MF2X08UZZNxrmd37XVwI6 MT5p5z3bNxTbpwIPgBNMmHZdx3UmkX7sszxB84KgEEmTBGF3dz+UVH9PEQnwAHB7ll4USP94SyUk EjRoToUJBZhW2aOAM3GAFKGF81YPE+KFFRiI1CJC3JAZe+iBqbckqgcOL6FAKEgjO7JDHBCBQDh7 cFUVCUYtDPF0zaeDq8ZM68cffmgBtyWEbjQSokImWKYDhXB9/LSEBzICNwErNRGLI6ADOzCF7LY0 q8iKZDI7OKVGXJgruwdhLlEN8zMAeNZviXRncPFI07J5bvhAdAUk70WHgshFcaMbVQWKPpgfxAiD gjiOnpBDLxFTfxENPSIdvmFQnvaIj2d38YFm4qgdvidQ0pZb1JaDD/GJiUQPlmctcFWKCuVG9JFb 44FHI6AJSvgAmyCLDlkEZOcJU1gEC4n/VP84jIkkj/WoCfRnZwWQAog0DnrGIdEojf+3VBZUTYeW N21IddxYg4uSkS5FiRxJjjgZRr4hW3pBjglGeyfUVmgWKBg5g0QGdfvIbau2AZ+mO4RCFavGbVJp ZM5HH+MRFJxwkZoAkZsQkZ2glQqkYE7ZYERJLfQXCc/oks/oIhU4jYYHQ3QTVXWoQHqoJ+Pxk2NJ lh2Zk3xpgXEjk20oloMjap7mQEdJldSmg/24AbPTlE8JRksZlQqFmFT5ImD5CZeJkz+ZRs1kmCvD ls9YBC4yLCepeW4pgHQ4l+pll0h1PZxJIXvZl7KpDnZxjLJJcp45m+QRmbzJmP7wT8LXIZurppuC iJux6QmhmZxyERelaZopKUuz5JLEuZokJ4iBAAA7 --------------Boundary-00=_C78XA2RUUGI4G6G00000-- From Creek@casualmodel.com Tue Jan 16 09:30:09 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6pKD-0006D3-Ts for mpls-archive@lists.ietf.org; Tue, 16 Jan 2007 09:30:09 -0500 Received: from cable-200-30.iesy.net ([81.210.200.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6pKB-0001Hm-KT for mpls-archive@lists.ietf.org; Tue, 16 Jan 2007 09:30:09 -0500 Received: from tommy-laptop (unknown [143.154.123.143]) by cable-200-30.iesy.net (Postfix) with ESMTP id E2DE0D1177EE for ; Tue, 16 Jan 2007 15:30:14 +0100 Message-ID: <000901c7397a$cf1bafc0$1ec8d251@tommylaptop> From: "Auditorium Received" To: mpls-archive@lists.ietf.org Subject: incident downloaded Napster net Date: Tue, 16 Jan 2007 15:30:02 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C73983.30E017C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 ------=_NextPart_000_0005_01C73983.30E017C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C73983.30E017C0" ------=_NextPart_001_0006_01C73983.30E017C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Different ball game moment telling stories. Perhaps, bands current electrical storm mind among. Vacation partied hitting nightspots, deciding take difficult personal = leaving! Insists never february singer stacie orrico. Made produce star = door adaptation novel tobi. Row made produce star door, adaptation. American date december, place kentwood louisiana. Last five years = shopping reality document backstage life! Durst, limp bizkit frontman, august, justin timberlake. Choice neil bogart memorial funds nbmf cure commitment issues. Knowles, pink, stormed bitter row made produce, star! Revealed dursts claims he false buddy flick. Tell, stubborn somebody tells something reason. Walk interview talk = queen diane, sawyer sobbed told coping! Columbus short culver california rehearsal, september palms weekend = along. Reporters, looking, forward shutting bitonce man started strip. Looks = funeral, marvellous timethree ago explained impressive scaryhe problem. = Mad elsei mexicowe hi puppy, clubi faces edgy. Festive cartoon robbie, = reindeer artists every genre. Reports, enjoying romance jared leto insisting hes. Seen performer go = unknown superstar, brief, instant, have! Explore talker expected skew. Mickey mouse club, jason, allen alexander married. Raunchy rap sure tongues wagging searches. Album, had, stores radio = stations music, video surpassed almost. Lopez doing male original = contained, material edited. Goodolboy, ran shed wait until virginity? = Citys soho childrens choice. Mystery, hospital thursday excitement partly. Problem, closeness intimacy afraid, letting, myself? Buddy flick = crossroads leading razzie rd golden. Schooling as travel schedule = include, sweden. Serious, seriously craving nicebut id soulmate. School in new york = dance? Pearls strap orgasm german chocolate museumwhen silence happiest. Elliott eminem dixie, chicks elton. Almost everyone else, pop rock biz. Proceeds foundation dedicated = helping children need, lawyers skechers. Friend but concedes, it. ------=_NextPart_001_0006_01C73983.30E017C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Different ball game moment telling=20 stories.
Perhaps, bands current electrical storm mind = among.
Vacation=20 partied hitting nightspots, deciding take difficult personal leaving! = Insists=20 never february singer stacie orrico. Made produce star door adaptation = novel=20 tobi. Row made produce star door, adaptation.
American date december, = place=20 kentwood louisiana. Last five years shopping reality document backstage=20 life!
Durst, limp bizkit frontman, august, justin = timberlake.
Choice neil=20 bogart memorial funds nbmf cure commitment issues.
Knowles, pink, = stormed=20 bitter row made produce, star!
Revealed dursts claims he false buddy=20 flick.
Tell, stubborn somebody tells something reason. Walk interview = talk=20 queen diane, sawyer sobbed told coping!
Columbus short culver = california=20 rehearsal, september palms weekend along.
Reporters, looking, forward = shutting bitonce man started strip. Looks funeral, marvellous timethree = ago=20 explained impressive scaryhe problem. Mad elsei mexicowe hi puppy, clubi = faces=20 edgy. Festive cartoon robbie, reindeer artists every genre.
Reports, = enjoying=20 romance jared leto insisting hes. Seen performer go unknown superstar, = brief,=20 instant, have! Explore talker expected skew.
Mickey mouse club, = jason, allen=20 alexander married.
Raunchy rap sure tongues wagging searches. Album, = had,=20 stores radio stations music, video surpassed almost. Lopez doing male = original=20 contained, material edited. Goodolboy, ran shed wait until virginity? = Citys soho=20 childrens choice.
Mystery, hospital thursday excitement = partly.
Problem,=20 closeness intimacy afraid, letting, myself? Buddy flick crossroads = leading=20 razzie rd golden. Schooling as travel schedule include, = sweden.
Serious,=20 seriously craving nicebut id soulmate. School in new york dance? Pearls = strap=20 orgasm german chocolate museumwhen silence happiest.
Elliott eminem = dixie,=20 chicks elton.
Almost everyone else, pop rock biz. Proceeds foundation = dedicated helping children need, lawyers skechers.
Friend but = concedes,=20 it.
------=_NextPart_001_0006_01C73983.30E017C0-- ------=_NextPart_000_0005_01C73983.30E017C0 Content-Type: image/gif; name="person.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c7397a$cf1bafc0$1ec8d251@tommylaptop> R0lGODlh/ACAAIfoAAAAAIQJAQ11AH50AAAEgXwBiwt3jMXNzM7fwaK79joRAGwYAI4VA6scBb4r ANURAABKCBNNAEtLDGUxAoo+AKY1BbNMAORDAwBeACxmADVfClpoAo5gAKFqBrhVAeNsBwWCBRp0 CDiACVp8AHaNAK56BL55ANp3AA2cACCTAjGhCm2qAIqZAqKsAc6cDuObAADBACjOADa7AFTACne6 AJK4ALzLAOq6BgDVAB7VAD/bBGjSCHvRBKTtDMDnBNPoAA4ANC4ANDQBTmgCNoAIPpMAPrMAQeUK MgoiOiAsRUoqTGEsRH0lN6MjSMUpS9sfQQBIMyI6RUU4TmNFTII9MaA9QcIyQdNHOA5aNhhsMTJS NldlNYZYEKdWN8xcTexWPAR/MR56SEOCOVR8S3eATJSOPb6KNuNySgCYSSuZOj+uOGmUNYaZO6Sp RLSoNe2RQwK3NCjCTjrGTFrITYa5OJTFOMe/Me29NwDWSB/VS0ToO2bYM3feRprrRcPnOurVSgsH ii4LdUwNhGIAd3wAe5QAdMIAhNQAfwgchS4ugDUlgFscdX4WiZsYfcUkjuksgQBMiS5OcU1JdVRM jII3e5xLfLhEdttHhQpRdxdueT1XjGdjeoNVg6pleMReh91Ycwt9fRSNiTdzfF12hnhzdqWFgMaB e913iACtiS6UjUGWdVSse46ofKGSeL+mg9OoiAC6iha8iEHKjG7Lgna1d5/JfsW3jdy5iQDRgRfn gjTmgVzpjHvRd6zli8fpeujgcwgAyCUMxEQAtmcAzHgAua4JtroAtu0EyAsqzCwos00cwGQXxXkj zpQlu7wuweAmvAk9tiQ6vE4yy2k6wohHupQ1vLE7ytlCygBZwhduyTFVyW5XuX5ttJZZvb9Vuupi vQB+tyuLwj6Ktmh/sYp6taaCzrd7yNuGvQetvCKasjSky2muvo2dvZGTyLObueOZzQXEzizLtzjK tF/BuoW7v6G+w/n54qKUmHaLi/8ABQv/AP/9AAMA//wA/wD+8vf/9iH5BACpwRUALAAAAAD8AIAA Bwj/AP8JHEiwoMGDCBMqXMiwoUN7ECNKnEixosWLGDNq3Mixo8ePIEOKHEmypEaHKFOqXMmSocmX MGPKnEmzps2WOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnZrTptWrWElS3coVatavYMNG 7Eq2rNmzaJWKXcu2Y9q3BNvKlQu3rt27ePPqvTu3r9+/gAMLHky48GACBD4CAWK4sWORDRFLJrAT GDCVlo1OXjgZscDFoIHEfUwaIkPPA1HjBABAJT9+RWEPlB2aYGuDoguW3s2RtUXf9oAHZ+2beMTX yPlJJC58uETEMZVXlG6POnWJ17HuNcoaYfd/38F3/ycuXqBk85TLCwwfXj3P2wbhw89d8Dbv+x2Z N5+8HABE4AD695+AlkVU4IBWCUiRggzqNyBz+EW4kXAQRhQggs5hCB1EG9rTIU0KTuTgfxUxdtV2 PYHUIX8RbehiYh7CGCOHMnbY3EwhLqejhxXlKOGPFobY3I0XZkihgEcG2Z9MQpJooZMiArlbQ/rB t56V6n2npX62Mdfllz95uZ5tY8bHJYpoeodlml2S15SUg934Y5VyBukgnRuxWVd7erYppm5wTtnn oA0FChKhiCaq6JuGNuroo5BaBVQAASy60JpsVlrXA5x2apYDCOWT0AKklioQpahq2lADpxakaaqq Uv95kKgIdeopQawW1ECuAvEqEKhw5UPrP8IKJOyxA5E60Jn/7OpsT2sii5CvAz3AErD/KFCQttkS xK1Cw+Xo7EUK/HZjPhCha4+6EwVQmrARwWtPqRMpUK499lK0a0T7ljRiRPf2WFHAHi0QkQMTIWxP AxIxzBHBAF/k7kXsQvSAxRgv+BdD7N2mbEEOABuyQbsOVPKymCrUWsoLJBTyywPB6tC34NXXaswo YZryP6V+TBC2vQZNLUEtR6URA0gnHRHSFFEKUb712is1wXVihLDCFEHAEdYSQfybRFzbo/DLIXvk I74cMTCR2glfDVHZCZMGgdYUMT0RBRRANHfdbMf/hLdFdGuUN0WDZ1R4cFHac7jZFS1+0eKOL20P 231DVHlbDAkgwEFzG6T5lQZ1LpDoOs0NQegOYYrBQBgFbo/rr+stEgYVwX6RABPZDhHu9vDOe0Qo +MUQ6QQRL9DnAmGgvPIDae58T6v/E33zBeEw0OnXl6m9QijYrP30KlnveUH6ZG/++QV1/4/66qNv lj7lI8X8StFPD//9yxKEw/7iC4TC/+3LXEGWJ5HgfWR5yosIDBa4wIi4joEwkIjzNDeRCCrQghH5 XaREUrWLmG5vbTHgBiGCwRGGRXdiQaGhVCgWPW1OKi8kFPamYkIgWUonNcyhDnfIwx6O5YZADKIQ /w+ysyEmKjS1OQqfoJUQ+oDLhxFajFheQxPLWHEiVNyYER/SGx/9KznU6YyMvpicFskoJIk545PO 5pEtLiU/bITIgYyjJAwlCUN15CDiJgIMOV7EjdtZIkFQoxrQGbJjKEtRHqEURygWJmdrqpIhE3lI SU4yTB37EyDZxCdEumeSW1KTUG4TyU0OqpOkDCWY3OTJT7qSJaSMjyn7tERL1pJZzLqSfIrIMU3m DymONIlTBJkUXs4SLW3pYFYaaZpjzjKXRgvmj5xJzbpI85pSqqY2t2lKbL5kKfZKC82k4k2QjItf /fIIp8zGTI2kakIRc2c5wdJLK7kpJSeb2ThXUv80njFEVQy6iMHm+ZepPU1qdhIOrA7K0IMi1KFQ E1vYMhLQp3XNgQeDZ0W4iZQPjs50B8HbqShVvNORTqQCQek/SEoQlTaEAgOBqUAYQBCaas+m/5gh SMd0T47yRCMJRKA9EkiR/0GEqA40XQFFaNSj0o4kCHyqPUQ4VeBlMCJPDRzdKLg7gtaEIf9bHwDF OpD74c+V/BtgVKdnvJXMMKejK95A2gcfGMQ1fQQJoE+LMr++Rm+BAwGs9MAn1rAG1q4HQd5qyPSP GDZ2IP2bYfue579/WNWra2mgPTSr2aYCUG+w2589RAuRpk6VqVS1B/w8ggN7QFYg8fsH/AL7Wtjq ju8fiBVIbvdalYxwVYK/WytEVisRzmIQgiV8HQg3m9yM8I+0oNVa4BQ0vfoNJHoB1Ctvt+vW8y2P euDlrnjHS97ymve86E2vetfLRcwGhr3wVYl75yuY+AqFvjy0Lznxq1+f4Pe/AIZUfwc84AB/077Y JLBRyqngoRj4wV9pcIMhTGFJSZjAFZ7LhTe8yQx7OCbb/HBYOEziEps3wSZOsYoRssMVu/jFMO6v iGc8khjb+MaWorGOdxxhHG+YxwCOL5CH/Mf0Epkj4z0yZC6sZPf62CBNbvKTpzyoKFt5yVTu5pW3 zOUuGzggADs= ------=_NextPart_000_0005_01C73983.30E017C0-- From Shopping@evenflowpainting.com Tue Jan 16 18:49:25 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6y3R-0005fQ-0m for mpls-archive@lists.ietf.org; Tue, 16 Jan 2007 18:49:25 -0500 Received: from ppp-114-178.32-151.iol.it ([151.32.178.114] helo=ppp-44-176.32-151.iol.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6y3L-0002Dl-1N for mpls-archive@lists.ietf.org; Tue, 16 Jan 2007 18:49:24 -0500 Received: from XUV (unknown [195.169.170.181]) by iol.it with ESMTP id 2FA5A4B65781 for ; Wed, 17 Jan 2007 00:50:41 +0100 (GMT) Message-ID: <001301c739c9$0b4b9160$2cb02097@soniapc> From: "these" To: mpls-archive@lists.ietf.org Subject: executives Sam Yagan Jed Date: Wed, 17 Jan 2007 00:50:04 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C739D1.6D0FF960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.0 (+++) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 ------=_NextPart_000_000F_01C739D1.6D0FF960 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C739D1.6D0FF960" ------=_NextPart_001_0010_01C739D1.6D0FF960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thisprint or license thisfirm claimsalex, presslos angeles the. Must still give final approval deala call ceo. Eric garland at media. Done so, opensource, version dubbed, emule eric garland at? So opensource version, dubbed emule eric garland at media. In terms latest agreement. Inc, was one of seven technology firms = receive letters! Politics state weird ads. An ad find pets dating breaking education = elections. Using previously downloaded versions softwarea. Steal music movies are lawthe concluded, with been most. We further footing legal mitch bainwol chairman chief. Much impact peertopeer, networks largely moved out hands these? Filed tuesdaynew yorkbased, inc was, one of? Featured message telling, = visitors that. Deala call, ceo not site tuesday featured. Receive, = letters last fall warning. According court documents, filed tuesdaynew. For jobs cars real estate. Jobs cars real estate apartments local shopping all create. Sports = living shop homes about cities? Tracks many functional unlikely shutdown edonkeys business operations! = With been most two years but computer users tapping. Largely moved out hands these companies developers end. Homes about = cities, use. So opensource version dubbed emule eric garland at media. Sports living = shop homes about cities use. Another domino falls we, further. ------=_NextPart_001_0010_01C739D1.6D0FF960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Thisprint or license thisfirm = claimsalex, presslos=20 angeles the.
Must still give final approval deala = call ceo. Eric=20 garland at media.
Done so, opensource, version dubbed, = emule eric=20 garland at?
So opensource version, dubbed emule = eric garland at media.
In terms latest agreement. Inc, was one = of seven=20 technology firms receive letters!
Politics state weird ads. An ad find = pets dating=20 breaking education elections.
Using previously downloaded versions = softwarea.
Steal music movies are lawthe = concluded, with been most.
We further footing legal mitch bainwol = chairman chief.
Much impact peertopeer, networks = largely moved out=20 hands these?
Filed tuesdaynew yorkbased, inc was, = one of?=20 Featured message telling, visitors that. Deala call, ceo not site = tuesday=20 featured. Receive, letters last fall warning. According court documents, = filed tuesdaynew.
For jobs cars real estate.
Jobs cars real estate apartments local = shopping all=20 create. Sports living shop homes about cities?
Tracks many functional unlikely = shutdown edonkeys=20 business operations! With been most two years but computer users = tapping.
Largely moved out hands these companies = developers=20 end. Homes about cities, use.
So opensource version dubbed emule eric = garland at=20 media. Sports living shop homes about cities use.
Another domino falls we,=20 further.
------=_NextPart_001_0010_01C739D1.6D0FF960-- ------=_NextPart_000_000F_01C739D1.6D0FF960 Content-Type: image/gif; name="Obituaries.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c739c9$0b4b9160$2cb02097@soniapc> R0lGODlhnAEsAYfqAAAKDosMAgCFAXF2Cw4AjncAcwp1dbnCtMDYsqLU6z4TBGwoAHYfAKMbCcoS AOggAABJABc7BUFACVlIA3dEApZHAMRECu1HAARXARdfCT5kAGZVAHpTAK5nBrhVAOtXAACNCh51 C0yHDmh7AHODAKx9AMx0DNmMAwCeAyutC0igCFysAIygBKSaDrKtANKiAQC3ASrAADjECFXKAHi0 AK3DAMa5BdW4AA3YABnrCDPfAFTaAnjcBZvuAMPTBejpAAABOyYBPUwAQVEANI0AQ5cJRsUBR+wE MwAUPhoSSkMbPF0VOnoSS6cZQrgtTO0jSgo6PB09QUc4QmNCN3pMM65DOsgyPdE/PQFZMxFhNTJT MWNdMXdTAZxdP7JkQthUMgWNMxmLQUx6Olt8PodzPJWOSLOFSeN4MgyXQh+RTTioP1+ZRX6RQqmn McKWQuqjTAC/TC2+OknNSFjHN3LFP5PHQMa3PdHGPgLdSi7XOjjoP2jmR3LlRKnUTsvbNuzaPQAA dRcJeUUEimUAfXEOeqcHeMEAdtkAfgAmcRQShkkodWoge3griZQui7QtfdMbewBKiBUxckFIgmgy g34xfqk3grFCje1AfwhReihSgj1ogFFueHxuiqhrfMBmedhbhgSJdheLjTSAgFKOjoVzc6Z0hbGH iNqMgA2oihalhzOXhV2li4GdcZSnjrKgdu2dgAC2che6gTqzi1O1gom8hqS6hcPBdtfEdQDiexLi djHRd1rfgofbiafUfLvac+rqjgMAuCABuz4FtmgAtnMDsqYAu80OvuAAyAAotCMsv0UlvmkTvXUR yaYhur8ZzeMTwwFOvS5AtUZBtllKv3E7yKpAxM41s+M4vwhsxiNmvTpbyF1TvYFgwaBqyslrs9Za tACOsRF0yDZ2vlqMtYyIvJR3t7uAzdR4tgCczB6UvU6mzl6hw4ObtZWgtMSoutyfxQDAsSjDwkK2 wmfLx3S5zZ+8s/P/9Jujq3mMevcHAAD7Av/xAAAJ+vUJ/wD0+f///yH5BAD//1UALAAAAACcASwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKAn+W8mypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMN2 TUm2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePOiFMu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLmDNr3sy5s+fPoHHqHU26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yIULEOBxOcoAAYxDglT3w4fkbZ0L1K6Q+0bvJKEX/4QePaF4geTLm50ukD37iO6pL5xOX359+R2t F7R+3SB//vb8px92A+20HEsH0pRgUQs2lV4AK0FHE3kRQviPhFVNt5KGPXFok4cbQrKUgCtZZ5OJ JoaWk0TcOafdi8u5GON2M9IIY4sxMmdPjjbiCF5D6Q10nnnkGTQkWe/F1x59S75nz31PUgdlQU4u GdJ/Aw240IBaEqiSTjnG+E+CB5IpwJhmrlTmmQiyuaaaZ6Ypp5ts4pQeSw/CJCGGeFpoVX0h/gMi hxoSKmKhIgqaKEv3MUrfUf+xRKJMKU6qIk0s6rijjjxuSqOnn3rqHYygyvgpqWFq+lCQ9px3JHoP Cv+p3ln1WVllklLal2uUVhJUJZX4bYRlgP11SZCxAiGLnIF1mpkmmtDCKW2Dc05LZ7Rv/nQnhny+ xGe3fz6q6LiOBmrouOe2BKJL6w4VaaUfxJSiS/NeGlOmA+GYL6fM6SuqqqjyW2q/ApMqUZCulvdq wm05qeRAuPLK68O//uprsMICyGWx/RF7LMdeCsRsmyS3KSa1YsLpbLM5qnwttinnlGeF3/pZIc0U XuWhoTwv2iiigar7M6BGWRppifEiTS9/9j7VIGTgNi1WvVL39fRjUVf9FdVad+3112CHLfbYZDd1 NWJZO9auYVyXzRNFNXanKqilHcnqeLG2WmRKER//9PBpXQ57EIDECk5gTzHLdLZheXJrs7cQOi5V ui+tTRiJ8MLU9j+bSz2RqZuG2aPAofMbd1t3E/Sq6gq3zreuTcJOca5TumV4lh3jjpCyITsEuqm/ Ezzw8G6lDqtCQxpvUq3ATryr89DbTvjHg9/Oe+8MBf/v8DLyaHDxex9PpKzio8R8lEwqGbH6GK9l OO8b6459pqIDL/z24H0PPsPIq8e/+UySGPsEuKu/SS9+uwNZsnI3P99pyn7bw1/BSPcWhM2qfHZz HZLws74Cys6DccESshCIwAZCRF8QFN3ADPajtOTtQRrUG95Wt7xgQWl26QPhATc2LC0J7nrLclva /9wGlc4R8SYmlGESzwLEJTrxiVCMohSnSEWFCPFxR4yKEbN4lMXNJFuF6dadYpKzPuksUUBzTL2O trSjsZGLiqvTyMK4LQtlLWplpArl1PiupBkRRX5MGhxj8rSWwQxaLTOkIbsyRpfgEYuN1CMaDzXJ nQGKaETLyhslJciXZI5znRykS1BmrVIuKHHSYmQebwa5nO0Ji5MT17rSiKhFlUuTTFvaTOa1SVG2 BGWKTBkYgelFq0QybZKD4RnTNTRz2bJRWnnjHwX5SV+OUo5XC2a0tvksr4xxiJIz4zInSS5aUvKW lqOKG0PpSWoG0povISU3WTbPkhXTmBR6JCvFCP/LWJbrXAD1GTm30sd2crIl1YSny+gkT5jFCZuL 3MrMlHkhP0WyolmxZIhkeclnZvIqkxLQO5WG0Fwq9FJDvEw6t8bOk8LEhDS0zfnu0sQqfsmlOM2p TnfKU7GQpIWjiSlyLFaWmtrUIvWb277oRpoM0hCGsBJqSfrWEKL6rX1FZeD1eiigoxIEqAcBK15i 9b+DiKesr+tVR6yKkq4WLoEL3A8Dq/ijG02wR3dRnhLNqkGpkuR8zJsSrgYLO7RYb65x9Zj8vMrU UC0VgnlRnlSTFz5acfCDtnqeQQyYVWNtdXqJZWxdTZdCscIldZP1XwzXc9ladVBiEHMtVlPyPsT/ KtaHtqXiaLl3v9BFdm9+pWz5yhJYjL32VphVyw9tW0KjEocnhXyoKSEamDpCTpz77KdTAurM7g6K nCstoknXONKE6jRMDn3Tmu7JlYm6F7s4O2PQMAneStr3nCBlo37dycuW9tQyKf0vT7Yo4K4FuMA5 IbBLGcvgBn8EwRCOcEsa6NfTsLU0zvXqHNnbGH4is4wXjSVHeRLeD9lSKORtm0hB2cuv4auxsyHr asV31hkDMLMTubBZulrC6snVwaXbl10fWCP9VbCy5MPb8dB6Y+cFEH26CmBxCQtlKdPOYU/eEmgX 6x+t5tamLdTeV0lLF8lekMbRYfJJXhu92cG2/4OYHWCbZytXzwLRzkB2bOnuN+Sl1gW1Z0ZzVCsc EsF+ULY4jt3fBujm+9C5znOFn5eTCF1hXqta9fTLN7UbTvj6U2jdBTW6BMouUgPNnOTSySY3RzUF DxLT2Yo1Q+UYFus60o64bsmBlzLL+oY6jeXE76iHzd1U16SgoCRpskv632eh19mJfBlY3LvpPtVM u0/p9XxHHGz7Bo3Y52SmuI693/4elNlEpHCg80yRDLM7OYR+N0PcbVMJ2/ve+M63vjuza8OUeDCu PunnOmWbha0bg3kj7mWjpxo8J9DhDDYtbF4oVCQPN6041jFe3Lpl+eH2y8eZ4y8tjV6XAeaiKf/V Z7j+SclaeltR0MRlq/2L7hYrVJuIlG50/4JybKs8Q6YW9rhZPmyZh3KLmQv4q6Wb86ajCZViOabP H9dvpWgU2N991KlPbBVp0nzZLDZp2JDKZ+FBVuKoC19qlYwWLDPc7dDjrGGn91kfs1t7pdXzn9U+ qwyyTi1uX/TC465Z5dI9dz2m3vyYFTNtyhrq026k5C0KYmxDBZo8M3YzgZ3f8XoeaV4v2/ziLe95 g5zBZKv6vsG++ta7/vWwj73sZ0/72tv+9rjPPWNKz/ve+/73wA++8Bus++J/ZvjI17Dxl6+Z5Duf isyP/mWeT30oSv/6k6m+9imN/e57//vgD7//+K2y/fJjb/zoT7/64Wn+9h9u/fCPv/xd7P762//+ +M+//vfvEH7wgyz+VxABKBEDyH/IN4AI+H8M4X8MaA8FKBAPiBAJCIEKuBARGIAT6ID/d4EVaIBH tRP+txIh+A8jOBMlKIL8wBMjuIIpWBMnSIIpyIIoGBMvOH/wJIMwiII1+IIMKIM92IItgYMsOIQx 2II/mINIGIJEaIQMaIPW9INNmIRAyBI9OIM5qIRM+BJQKIRFmIVcCIUz6INZ6ISDtIVMWIU0WIRh qIZIGIRbaIVYSIVsuIRRGIdXeIRkaC8TYYYU2BAYqIB/qIF9KIBbOIiB2IcZyIeCOIER6IG+/5eB ghiJB3GIgQiJBAGJjFiBlKiJgMiJkbiJjviInXiJDUiIpZiJGliKBmGJPTiIn9iKhuiJqZiAjRiK tiiJt5iLplGLutiLvviLwBiM1KeKC9iBFGiMbcGLwgh9OlGDNMGDU/gTzggU06gU1ZiHmHGNMAGN Q6GNKhiNTeGN2CgYBHiKqgiLHPiHtMiJjYiOxDgQ7riOnbiOpliA7riIo7iMyGGPo4iKpAiPibiB +QiQBImLr5iKsXiQ76iQ/SiQB6mPtQGCQAiGFBmNJXiRRwiGbiiHVsiRd+iRWFiFziiGa6iR4jiO gFGOBbmSruiK/EiICfGSBumPDAmTq9iQiP9YiAYJkbAhkSA5h2zokW1Ikm3YkTj4k0PphUq5jUsp hR2JkqBxgmgIg0dplFM4lVPphmcIjlQ5hjpIhE+JlF0plkUJlWZ5lmiZlmq5lmzZlsbHk3C5Fm45 lzYRl3Z5FnSZl3q5l3zZl6Jxl4AZmII5mIS5eH55mIjploW5mB2RmI75mGbJmJKZEZBZmZZ5mZiZ mZq5mZzZmZ65e5MZmqI5miXxmaZ5mrBHmqq5mqyJEgRAAALxmrEJmw3xmra5EbJpEbk5m7tpm7Rp D7cJnL/ZmsSRm8Y5nAmxmxyhnBIRnMI5m8/5nLI5nchJnK+xE6+5Etn5D9vpmy+xnS3RnQT/wJ22 qZ3lSZ7n6Z3oOZ7mCZ4uAZ7iSZ7mKZ/qiZp8MRG+6ZvQGZ0DwZzRSZ3VSZ3Q2Zu0KaD8SRAEOqAF uqCw6Z/W6Ro8kZ/pmZ/vOZ7eGZ/uSaEYyp7rmZ0SChPwyZ4eKqIcOp/naZ+LIaHxGRMhKp/0yaEb aqIwWqIuKhMt+qLzGZ7l6Z4oihgr6qI8CqQWSqI1GqM4mqMjmqMVyhJGmqFDWqM96qNEyqQnWqET uqMlqqFTeqUzGqTrSaUhyqPiSaNRWqZmeqZomqZquqZZ5KU+UaU2+qRE4aZs+hR0ehP1iadPeqc0 QacnmqQ6Cqc2wadUWqdGQagz8aODmqVk/4oTftqiYjqljtqoIEqphroSzRmc+imcztmfw2mgx3mc 0nmboloQm7qpCNqgC3qg/6mqofqb+dmqvOmqDFqdD7oWCTqq++mpqSqrvSqgucqcouqgulqsvDqq q1qsoKqqvbqrt0oS2DmjMqqk1AqoY5qkgNqeZGqk3ymn2aqtktqk3iqnSiqobJqpx7qspvqpzKqs zGqgs2oQw2qrKmqszsqf86qg+nqsnmqrz8oR0VqoRxqkKyquOBqplTqt3Vqo3wqlRUqkBuukC3up EXqt4MqiVUqhHTqwN9qtiiqwB0ujCAumXXqtJDqmX0qxHkGs69oRLPuvzveyqeqv+EmzMP/rRBTr fTe7szwrmDn7s0AbtEL7Ej07mkPLfEUrmke7tEzbtD2atFAbtVI7tVRbtTjrtLhntYOJtVzbtV6b mFobtmJbfV9btmZ7tmk5tneJtmzbtkmhtnbptq1XEVB4jJMIi8dojh24kAhJigLJhzoJkIoIt3nR E3UYkml4lUNIlV+ZuC7RhFGohWCpg3LrFZF7h1zJuJTLkZB7uY8LjV3ouJuruZWLFOWIjHZ7t/Mo gXUbk+nYtzfJjoJLuKkhkZnruXJ4homLu59rkYjLlBOJkZlbukFxuqyLun3Lt7OIvH4LuGb4t6mb t61Lu7GhvNZLi8ervLPrt7Bbj++ovdT/axe2K7qSq7vAm5Xl27ukq76ey7vEOxXuG7+LC7xjSb6U K7/mO7rvexWX+7vpq7+/i765y77TeLjCu79GsYd6273cm7d2e458+73qeLyCu7rhqxutq4g/2LzY W8Gxa4rLu8HE2IrPy7wX3BYIbG+nW8Is3MIu/MIwHMOBe8I0TLspfMM3XMPAiMM83MM+/MNAHMRC PMREHBk6fMRInMRKvMTWWcQ4xcRQHMVSPMUG4cQLRsX7Z8UCh8X6p8Ve/MVgDJpcjH9hXMZmfMZo nMZOPMZs3MajocZwHMdyPMd0vLRubH91PHZ3vMd87BZ5/MeO2ceCPMiEXMiGfMhiC8heAhMQADsA = ------=_NextPart_000_000F_01C739D1.6D0FF960-- From ressi98i@verizon.net Wed Jan 17 03:44:39 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H76PP-00034d-Mr for mpls-archive@lists.ietf.org; Wed, 17 Jan 2007 03:44:39 -0500 Received: from [210.69.170.95] (helo=mail-kr4.bigfoot.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H76PO-00036k-5V for mpls-archive@lists.ietf.org; Wed, 17 Jan 2007 03:44:39 -0500 Received: from 206.46.232.11 (HELO relay.verizon.net) by lists.ietf.org with esmtp (ZHR*M.<7 '25E) id /BSLC?-Q6*5 X-Mailer: The Bat! (v3.0) Personal X-Priority: 3 (Normal) Message-ID: <226063654.27692720810093@thebat.net> To: mpls-archive@lists.ietf.org Subject: Develop your business using our company MHII.OB now MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 4.4 (++++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Idol begins this week! because when MARSHAL HOLDINGS INC(MHII.OB)!!! DATE INITIAL COST VOLUME 01/18/2007 0.078 8,394,800 01/17/2007 0.064 5,394,800 01/12/2007 0.034 2,094,800 01/11/2007 0.035 3,091,232 01/10/2007 0.016 511,475 01/09/2007 0.015 481,693 =93What is that?=94 you say and we are so sorry that you still don=92t know= =85 This is great stock that you had ever met in your life!!! It grew for 300% just for a few days!!! Be ware don=92t miss it!!! You can get more news using your broker web-site! WARNING: INVEST YOUR MONEY EXACTLY IN OUR COMPANY!!! I thought I was From mpls-bounces@lists.ietf.org Wed Jan 17 06:11:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78ev-0000mY-FC; Wed, 17 Jan 2007 06:08:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78et-0000aF-Vr for mpls@lists.ietf.org; Wed, 17 Jan 2007 06:08:47 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H78es-0004cO-MH for mpls@lists.ietf.org; Wed, 17 Jan 2007 06:08:47 -0500 Received: by ug-out-1314.google.com with SMTP id k3so1254357ugf for ; Wed, 17 Jan 2007 03:08:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=m2O+5yrydHmnEEDSqvQo07L3t/MMoek0EkZGu8uq1Al1UWoSl8E/s8Q7/AD9k4pBF0b4Ak53ATXtoFRH6S4/hrrzVKUqhOr9LMEtZunc2GpqK9SpQGYJ8eGPPeWz7vx+6CePn4Xuo9gvEYSQokbWyW6aSdNjgPXnxchy4oHgUVA= Received: by 10.78.201.10 with SMTP id y10mr1581209huf.1169032122368; Wed, 17 Jan 2007 03:08:42 -0800 (PST) Received: by 10.78.121.9 with HTTP; Wed, 17 Jan 2007 03:08:42 -0800 (PST) Message-ID: Date: Wed, 17 Jan 2007 16:38:42 +0530 From: "shilpa goel" To: mpls@uu.net, mpls@lists.ietf.org, mpls-ops@mplsrc.com MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [mpls] basic doubt about LERs in MPLS 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="===============1794358653==" Errors-To: mpls-bounces@lists.ietf.org --===============1794358653== Content-Type: multipart/alternative; boundary="----=_Part_96371_33454526.1169032122204" ------=_Part_96371_33454526.1169032122204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have one basic doubt regarding LERs in IP/MPLS networks. How does a LER decide whether it should do IP routing (i.e. IP Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that it receives at an interface? Linked to this I have another doubt that how are control/protocol packets (which are IP) routed in a router i.e. are they label switched along the LSPs that exist for the FECs/destinations to which they are addressed or by default IP routed? regards, Shilpa ------=_Part_96371_33454526.1169032122204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
 I have one basic doubt regarding LERs in IP/MPLS networks.

How does a LER decide whether it should do IP routing (i.e. IP Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that it receives at an interface?

Linked to this I have another doubt that how are control/protocol packets (which are IP) routed in a router i.e. are they label switched along the LSPs that exist for the FECs/destinations to which they are addressed or by default IP routed?
 
regards,
Shilpa

------=_Part_96371_33454526.1169032122204-- --===============1794358653== 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 --===============1794358653==-- From mpls-bounces@lists.ietf.org Wed Jan 17 06:11:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78fy-000214-0T; Wed, 17 Jan 2007 06:09:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78fw-00020y-1D for mpls@lists.ietf.org; Wed, 17 Jan 2007 06:09:52 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H78fs-0004wk-Nn for mpls@lists.ietf.org; Wed, 17 Jan 2007 06:09:52 -0500 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JC00020NEZPDP@firewall.mci.com> for mpls@lists.ietf.org; Wed, 17 Jan 2007 11:09:44 +0000 (GMT) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQvxmq27097; Wed, 17 Jan 2007 11:09:11 +0000 (GMT) Received: by mail-control.ash.ops.us.uu.net id QQvxmq18197 for mpls-outgoing; Wed, 17 Jan 2007 11:09:05 +0000 (GMT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQvxmq18192 for ; Wed, 17 Jan 2007 11:08:53 +0000 (GMT) Received: from dgismtp03.wcomnet.com by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dgismtp03.mcilink.com [166.38.58.143]) id l0HB8rGn008854 for ; Wed, 17 Jan 2007 11:08:53 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([127.0.0.1]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JC0006MMEYTBD@dgismtp03.mcilink.com> for mpls@uu.net; Wed, 17 Jan 2007 11:08:53 +0000 (GMT) Received: from pmmspam05.mcilink.com ([166.37.156.165]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JC0005FTEYPLZ@dgismtp03.mcilink.com> for mpls@uu.net; Wed, 17 Jan 2007 11:08:53 +0000 (GMT) Received: from pmesmtp02.mci.com (pmesmtp02.mci.com [199.249.20.2]) by pmmspam05.mcilink.com (8.13.1/8.13.1) with ESMTP id l0HB8msv011427 for ; Wed, 17 Jan 2007 11:08:48 +0000 (GMT) Received: from pmesmtp02.mci.com ([127.0.0.1]) by firewall.mci.com (Iplanet MTA 5.2) with SMTP id <0JC0004OMEYO80@firewall.mci.com> for mpls@uu.net; Wed, 17 Jan 2007 11:08:48 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.170]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JC0003EZEYL79@firewall.mci.com> for mpls@uu.net; Wed, 17 Jan 2007 11:08:48 +0000 (GMT) Received: by ug-out-1314.google.com with SMTP id o2so1795551uge for ; Wed, 17 Jan 2007 03:08:44 -0800 (PST) Received: by 10.78.201.10 with SMTP id y10mr1581209huf.1169032122368; Wed, 17 Jan 2007 03:08:42 -0800 (PST) Received: by 10.78.121.9 with HTTP; Wed, 17 Jan 2007 03:08:42 -0800 (PST) Date: Wed, 17 Jan 2007 16:38:42 +0530 From: shilpa goel To: mpls@UU.NET, mpls@lists.ietf.org, mpls-ops@mplsrc.com Message-id: MIME-version: 1.0 Precedence: bulk DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=m2O+5yrydHmnEEDSqvQo07L3t/MMoek0EkZGu8uq1Al1UWoSl8E/s8Q7/AD9k4pBF0b4Ak53ATXtoFRH6S4/hrrzVKUqhOr9LMEtZunc2GpqK9SpQGYJ8eGPPeWz7vx+6CePn4Xuo9gvEYSQokbWyW6aSdNjgPXnxchy4oHgUVA= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0 adultscore=0 adjust=0 reason=mlx engine=3.1.0-0612050001 definitions=main-0701170016 X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [mpls] basic doubt about LERs in MPLS X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0548965954==" Errors-To: mpls-bounces@lists.ietf.org --===============0548965954== Content-type: multipart/alternative; boundary="----=_Part_96371_33454526.1169032122204" ------=_Part_96371_33454526.1169032122204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have one basic doubt regarding LERs in IP/MPLS networks. How does a LER decide whether it should do IP routing (i.e. IP Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that it receives at an interface? Linked to this I have another doubt that how are control/protocol packets (which are IP) routed in a router i.e. are they label switched along the LSPs that exist for the FECs/destinations to which they are addressed or by default IP routed? regards, Shilpa ------=_Part_96371_33454526.1169032122204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
 I have one basic doubt regarding LERs in IP/MPLS networks.

How does a LER decide whether it should do IP routing (i.e. IP Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that it receives at an interface?

Linked to this I have another doubt that how are control/protocol packets (which are IP) routed in a router i.e. are they label switched along the LSPs that exist for the FECs/destinations to which they are addressed or by default IP routed?
 
regards,
Shilpa

------=_Part_96371_33454526.1169032122204-- --===============0548965954== 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 --===============0548965954==-- From mpls-bounces@lists.ietf.org Wed Jan 17 07:09:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H79ag-0006cW-7d; Wed, 17 Jan 2007 07:08:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6XRH-0001FR-9v for mpls@lists.ietf.org; Mon, 15 Jan 2007 14:24:15 -0500 Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6XRF-0005Qh-TX for mpls@lists.ietf.org; Mon, 15 Jan 2007 14:24:15 -0500 Received: from [129.25.14.14] (n1-14-14.dhcp.drexel.edu [129.25.14.14]) (authenticated bits=0) by coe.drexel.edu (8.13.6/8.13.4) with ESMTP id l0FJNI95005409; Mon, 15 Jan 2007 14:23:20 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32F10E12-0A15-41C3-8D08-CDBF47C7154A@ece.drexel.edu> Content-Transfer-Encoding: 7bit From: Jaudelice Cavalcante de Oliveira Subject: Re: [mpls] Re: CCAMP Last call on draft-deoliveira-diff-te-preemption-06.txt Date: Mon, 15 Jan 2007 14:23:17 -0500 To: Dimitri.Papadimitriou@alcatel-lucent.be X-Mailer: Apple Mail (2.752.2) X-Spam-Score: (-1.414) ALL_TRUSTED,AWL X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a X-Mailman-Approved-At: Wed, 17 Jan 2007 07:08:28 -0500 Cc: mpls@lists.ietf.org, ccamp@ops.ietf.org, Ross Callon , owner-ccamp@ops.ietf.org, JP Vasseur 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Dimitri, On Jan 12, 2007, at 4:31 PM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > hi - > > thanks for the reply - not sure you ever got the following response > back > > ----- Forwarded by Dimitri PAPADIMITRIOU/BE/ALCATEL on 12/01/2007 > 22:30 > ----- > Dimitri PAPADIMITRIOU > 07/01/2007 11:43 > To: Jaudelice Cavalcante de Oliveira > > > Hi > > thanks for the answer - i am still looking at the reason > why the PN selection process is driven by a uniform policy > which looks like an arbitrary choice > > HBlock aims at minimizing the blocking probability > PN aims at minimizing the system perturbation > > to have a fair analysis policy should be applied uniformly > and non-uniformly to both cases > Both policies were applied in the same manner. The difference is in the selection of LSPs for preemption (largest or smallest). We chose to keep the policies simple. I appreciate your feedback. I'd be happy to meet with you and discuss it further at the next IETF meeting as well. Many thanks, Jau. > much thanks, > - d. > > -- > > > > > Jaudelice Cavalcante de Oliveira > 05/01/2007 00:11 > > To: Dimitri.Papadimitriou@alcatel-lucent.be > cc: mpls@lists.ietf.org, JP Vasseur , > ccamp@ops.ietf.org, Jaudelice Cavalcante de Oliveira > , Ross Callon , > owner-ccamp@ops.ietf.org > Subject: [mpls] Re: CCAMP Last call on > draft-deoliveira-diff-te-preemption-06.txt > > > Hi Dimitri, > > Thank you for your comment. > > On Dec 18, 2006, at 3:47 AM, Dimitri.Papadimitriou@alcatel-lucent.be > wrote: > >> adrian - >> >> in HBlock case the average wasted bw is a factor 10 smaller than >> for any >> other scheme (without significantly lowering the worst case, still an >> order of 10) > > Indeed. This can be seen in table 2. In this case, selection of LSPs > much larger than > the required bandwidth did not occur often. The worst case value does > not reflect the > frequency with which a high bandwidth LSP was selected (which was > very rarely in > this case, therefore the low "wasted" bandwidth). > >> the only noticeable difference with PN is exactly that one (which is >> induced by the possibility left to Hblock to have two selection >> depending >> on heavy vs normal loaded link) - hence it would be interesting to >> know >> the dependency on the min/max LSP bw and distribution (scenario >> dependancy) and have a similar PN approach (non-uniform selection) > > Note that PN has the objective of preempting a small number of LSPs > of the lowest > priority (therefore ordering by decreasing bandwidth), while HBlock > aims at minimizing > the blocking probability, therefore selecting smaller LSPs which will > be more likely to be > rerouted once preempted. This is the main difference between the two > policies: Given a set > of LSPs with the same priority, PN picks the largest (in the interest > of picking few) and HBlock > picks smaller ones (even if more than one, in the interest of being > able to reroute them easily). > > I hope this helps, > > Thanks, > > Jaudelice. > >> >> thanks, >> - d. >> >> >> >> >> >> >> "Adrian Farrel" >> Sent by: owner-ccamp@ops.ietf.org >> 14/12/2006 18:02 >> Please respond to "Adrian Farrel" >> >> To: >> cc: , "Ross Callon" >> , "Brungard, Deborah A, ALABS" >> , >> >> Subject: Re: CCAMP Last call on >> draft-deoliveira-diff-te-preemption-06.txt >> >> >> Hi, >> >> I have been explicitly asked to lengthen this last call so as to >> allow >> time >> for a review. >> >> Unusual, but not unreasonable. >> >> The last call is extended to noon on Sunday 17th December. >> >> Thanks, >> Adrian >> ----- Original Message ----- >> From: "Adrian Farrel" >> To: >> Cc: ; "Ross Callon" ; >> "Brungard, Deborah A, ALABS" ; >> >> Sent: Wednesday, November 29, 2006 11:06 AM >> Subject: CCAMP Last call on draft-deoliveira-diff-te- >> preemption-06.txt >> >> >>> Hi, >>> >>> This draft has been developed independently and has recently been >> brought >>> to the IESG for advancement as an individual submission to become an >>> Informational RFC. I have done a first-level review and this latest >>> revision includes updates to reflect my comments. >>> >>> Since the material here concerns preemption and the suggested >>> ways to >>> operate an MPLS-TE or GMPLS network, we are running a quick last >>> call on >> >>> the CCAMP mailing list to ensure that no-one has any objections. >>> >>> Please send your comments to the CCAMP list no later than noon >>> GMT on >> 13th >>> December 2006. >>> >>> Thanks, >>> Adrian >>> ----- Original Message ----- >>> From: >>> To: >>> Sent: Tuesday, November 28, 2006 8:50 PM >>> Subject: I-D ACTION:draft-deoliveira-diff-te-preemption-06.txt >>> >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : LSP Preemption Policies for MPLS Traffic Engineering >>>> Author(s) : J. de Oliveira, et al. >>>> Filename : draft-deoliveira-diff-te-preemption-06.txt >>>> Pages : 19 >>>> Date : 2006-11-28 >>>> >>>> When the establishment of a higher priority (Traffic Engineering >>>> Label Switched Path) TE LSP requires the preemption of a set of >>>> lower >>>> priority TE LSPs, a node has to make a local decision to select >>>> which >>>> >>>> TE LSPs will be preempted. The preempted LSPs are then >>>> rerouted by >>>> their respective Head-end Label Switch Router (LSR). This >>>> document >>>> presents a flexible policy that can be used to achieve different >>>> objectives: preempt the lowest priority LSPs; preempt the minimum >>>> number of LSPs; preempt the set of TE LSPs that provide the >>>> closest >>>> amount of bandwidth to the required bandwidth for the >>>> preempting TE >>>> LSPs (to minimize bandwidth wastage); preempt the LSPs that >>>> will have >>>> the maximum chance to get rerouted. Simulation results are >>>> given and >>>> a comparison among several different policies, with respect to >>>> preemption cascading, number of preempted LSPs, priority, wasted >>>> bandwidth and blocking probability is also included. >>>> >>>> A URL for this Internet-Draft is: >>>> >> http://www.ietf.org/internet-drafts/draft-deoliveira-diff-te- >> preemption-06.txt >> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > _______________________________________________ > 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 Jan 17 07:09:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H79ah-0006cj-53; Wed, 17 Jan 2007 07:08:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6lGj-0006Da-Bh for mpls@lists.ietf.org; Tue, 16 Jan 2007 05:10:17 -0500 Received: from fe20.tasp.pt ([213.13.158.95] helo=asp-fe20.asp-telepac.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6lGd-00034E-Ek for mpls@lists.ietf.org; Tue, 16 Jan 2007 05:10:13 -0500 Received: from EX03.corpPT.com ([10.162.203.10]) by asp-fe20.asp-telepac.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 10:09:57 +0000 Received: from PC18PMCOR109.ptcom.corppt.com ([10.162.200.180]) by EX03.corpPT.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 10:09:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Jan 2007 10:09:55 -0000 Message-ID: <08D891E55AC19D4ABA67C31698A254A21C68B4@PC18PMCOR109.ptcom.corppt.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-eusebio-mpls-els-00 Thread-Index: Acc5VnibfovM1XrHTY+XCMdfNELE+Q== From: "Francisco Miguel Tome de Sousa Eusebio" To: X-OriginalArrivalTime: 16 Jan 2007 10:09:57.0455 (UTC) FILETIME=[79AAB5F0:01C73956] X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-Mailman-Approved-At: Wed, 17 Jan 2007 07:08:28 -0500 Subject: [mpls] draft-eusebio-mpls-els-00 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="===============1487093081==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1487093081== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73956.798A7A50" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73956.798A7A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there. =20 I would be more than happy to hear your comments on the referred draft.=20 =20 One of the comments that I already got, concerns the need for new ASICs to deal with the suggested label ... Should I assume that as an handicap eventually overcome by the functional potential (keeping the draft unchanged), should I adapt the idea to existing ASICs capabilities, or is the whole idea too stupid for us to bother? =20 Thanks in advance. =20 fe =20 =20 ------_=_NextPart_001_01C73956.798A7A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

         =    Hi there.

 

         =    I would be more than happy to hear your comments on the referred draft. =

 

        = ;    One of the comments that I already got, concerns the need for new ASICs to = deal with the suggested label … Should I assume that as an handicap = eventually overcome by the functional potential (keeping the draft unchanged), = should I adapt the idea to existing ASICs capabilities, or is the whole idea too = stupid for us to bother?

 

        = ;    Thanks in advance.

 

fe

 

 

------_=_NextPart_001_01C73956.798A7A50-- --===============1487093081== 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 --===============1487093081==-- From mpls-bounces@lists.ietf.org Wed Jan 17 10:18:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7CWs-0002Hm-Ph; Wed, 17 Jan 2007 10:16:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7CWq-0002HO-Ux for mpls@lists.ietf.org; Wed, 17 Jan 2007 10:16:44 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7CWk-0003Fv-2p for mpls@lists.ietf.org; Wed, 17 Jan 2007 10:16:44 -0500 Received: from unknown (HELO pi-smtp.jnpr.net) ([10.10.2.36]) by kremlin.juniper.net with ESMTP; 17 Jan 2007 07:12:46 -0800 X-IronPort-AV: i="4.13,199,1167638400"; d="scan'208,217"; a="641522887:sNHT128125540" Received: from emailwf1.jnpr.net ([10.10.2.33]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Jan 2007 10:16:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Jan 2007 10:16:35 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MPLS-OPS]: basic doubt about LERs in MPLS Thread-Index: Acc6L6jd8Fn5rvakQlqymDMYyP7bGgAGCsXQ From: "Christopher Young" To: "shilpa goel" , , , X-OriginalArrivalTime: 17 Jan 2007 15:16:36.0435 (UTC) FILETIME=[7ABA0230:01C73A4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: Subject: [mpls] RE: [MPLS-OPS]: basic doubt about LERs in MPLS 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="===============1520841311==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1520841311== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73A4A.7A2952A7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73A4A.7A2952A7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shilpa, =20 For your first question an LER always does a lookup on the IP destination address of a packet regardless of whether or not the packet is meant to be encapsulated with MPLS or not. In other words, a router still functions like a router even with MPLS turned on. The destination of that packet will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and sent over an LSP. =20 (NOTE: In L2 VPN's where you don't do a L3 lookup this is different as usually a configured association is made between a CE-to-PE interface and an LSP) =20 =20 For your second question, my statement above still applies. For example if your IP routing table yields the LSP as the next-hop to the loop back address of your IBGP peer then you send the BGP packets over the LSP. For ISIS,OSPF, RSVP and LDP control packets those will still be sent out on the base POS/ATM/GE IP interface without MPLS encapsulation, but that is an exercise left up to the individual vendor. Note that if using hierarchical MPLS tunnels (LDP over RSVP) the LDP packets would ride over the MPLS LSP. Also, of note is that in all vendors you can control whether or not IP traffic and IGPs actually use LSPs for forwarding and next-hop computation with configuration knobs.=20 =20 Hope this helps. =20 Thanks, =20 =20 Christopher Young Resident Engineer JNCIP-E ERX #9 (978) 973-0574 cyoung@juniper.net ________________________________ From: shilpa goel [mailto:shilpa07@gmail.com]=20 Sent: Wednesday, January 17, 2007 6:09 AM To: mpls@uu.net; mpls@lists.ietf.org; mpls-ops@mplsrc.com Subject: [MPLS-OPS]: basic doubt about LERs in MPLS =20 Hi, =20 I have one basic doubt regarding LERs in IP/MPLS networks. How does a LER decide whether it should do IP routing (i.e. IP Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that it receives at an interface?=20 Linked to this I have another doubt that how are control/protocol packets (which are IP) routed in a router i.e. are they label switched along the LSPs that exist for the FECs/destinations to which they are addressed or by default IP routed?=20 =20 regards, Shilpa ------_=_NextPart_001_01C73A4A.7A2952A7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shilpa,

=

 

For your first question an LER = always does a lookup on the IP destination address of a packet regardless of whether = or not the packet is meant to be encapsulated with MPLS or not. In other words, = a router still functions like a router even with MPLS turned on. The = destination of that packet will yield whether or not the packet will be sent out = over a regular IP interface or encapsulated in MPLS and sent over an = LSP.

 

(NOTE: In L2 VPN’s where you = don’t do a L3 lookup this is different as usually a configured association is = made between a CE-to-PE interface and an LSP)

 

 

For your second question, my = statement above still applies. For example if your IP routing table yields the LSP = as the next-hop to the loop back address of your IBGP peer then you send the = BGP packets over the LSP.  For ISIS,OSPF, RSVP and LDP control packets those will still be sent out on the base = POS/ATM/GE IP interface without MPLS encapsulation, but that is an exercise left up to the = individual vendor. Note that if using hierarchical MPLS tunnels (LDP over RSVP) the = LDP packets would ride over the MPLS LSP. Also, of note is that in all = vendors you can control whether or not IP traffic and IGPs actually use LSPs for = forwarding and next-hop computation with configuration knobs. =

 

Hope this = helps.

 

Thanks,

=

 

 

Christopher Young
Resident Engineer
JNCIP-E ERX #9
(978) 973-0574
cyoung@juniper.net

From: = shilpa goel [mailto:shilpa07@gmail.com]
Sent: Wednesday, January = 17, 2007 6:09 AM
To: mpls@uu.net; mpls@lists.ietf.org; mpls-ops@mplsrc.com
Subject: [MPLS-OPS]: = basic doubt about LERs in MPLS

 

Hi,

 

 I have one basic doubt regarding LERs in IP/MPLS = networks.

How does a LER decide whether it should do IP routing (i.e. IP = Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that = it receives at an interface?

Linked to this I have another doubt that how are control/protocol = packets (which are IP) routed in a router i.e. are they label switched along the = LSPs that exist for the FECs/destinations to which they are addressed or by = default IP routed?

 

regards,
Shilpa

------_=_NextPart_001_01C73A4A.7A2952A7-- --===============1520841311== 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 --===============1520841311==-- From mpls-bounces@lists.ietf.org Wed Jan 17 16:43:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7IWz-0007ef-JL; Wed, 17 Jan 2007 16:41:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7IWy-0007ea-S8 for mpls@lists.ietf.org; Wed, 17 Jan 2007 16:41:16 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7IWx-0002JW-3f for mpls@lists.ietf.org; Wed, 17 Jan 2007 16:41:16 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0HLf3h2014531; Wed, 17 Jan 2007 22:41:04 +0100 In-Reply-To: <32F10E12-0A15-41C3-8D08-CDBF47C7154A@ece.drexel.edu> To: Jaudelice Cavalcante de Oliveira Subject: Re: [mpls] Re: CCAMP Last call on draft-deoliveira-diff-te-preemption-06.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Wed, 17 Jan 2007 22:41:07 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/17/2007 22:40:56, Serialize complete at 01/17/2007 22:40:56 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: ccamp@ops.ietf.org, mpls@lists.ietf.org, Ross Callon , owner-ccamp@ops.ietf.org, JP Vasseur 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: , Errors-To: mpls-bounces@lists.ietf.org Hi - let's then discuss the policy selection further - are these not dependent on the objectives - rather than be selected / defined independently - ? this question is fundamental to the understanding of the obtained results - i mean it may simply that with another simple "policy" both would have result in the same outcome i see here a potential discussion item for next f2f meeting - do you agree ? thanks, - d. Jaudelice Cavalcante de Oliveira 15/01/2007 20:23 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: mpls@lists.ietf.org, ccamp@ops.ietf.org, Ross Callon , owner-ccamp@ops.ietf.org, JP Vasseur Subject: Re: [mpls] Re: CCAMP Last call on draft-deoliveira-diff-te-preemption-06.txt Hi Dimitri, On Jan 12, 2007, at 4:31 PM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > hi - > > thanks for the reply - not sure you ever got the following response > back > > ----- Forwarded by Dimitri PAPADIMITRIOU/BE/ALCATEL on 12/01/2007 > 22:30 > ----- > Dimitri PAPADIMITRIOU > 07/01/2007 11:43 > To: Jaudelice Cavalcante de Oliveira > > > Hi > > thanks for the answer - i am still looking at the reason > why the PN selection process is driven by a uniform policy > which looks like an arbitrary choice > > HBlock aims at minimizing the blocking probability > PN aims at minimizing the system perturbation > > to have a fair analysis policy should be applied uniformly > and non-uniformly to both cases > Both policies were applied in the same manner. The difference is in the selection of LSPs for preemption (largest or smallest). We chose to keep the policies simple. I appreciate your feedback. I'd be happy to meet with you and discuss it further at the next IETF meeting as well. Many thanks, Jau. > much thanks, > - d. > > -- > > > > > Jaudelice Cavalcante de Oliveira > 05/01/2007 00:11 > > To: Dimitri.Papadimitriou@alcatel-lucent.be > cc: mpls@lists.ietf.org, JP Vasseur , > ccamp@ops.ietf.org, Jaudelice Cavalcante de Oliveira > , Ross Callon , > owner-ccamp@ops.ietf.org > Subject: [mpls] Re: CCAMP Last call on > draft-deoliveira-diff-te-preemption-06.txt > > > Hi Dimitri, > > Thank you for your comment. > > On Dec 18, 2006, at 3:47 AM, Dimitri.Papadimitriou@alcatel-lucent.be > wrote: > >> adrian - >> >> in HBlock case the average wasted bw is a factor 10 smaller than >> for any >> other scheme (without significantly lowering the worst case, still an >> order of 10) > > Indeed. This can be seen in table 2. In this case, selection of LSPs > much larger than > the required bandwidth did not occur often. The worst case value does > not reflect the > frequency with which a high bandwidth LSP was selected (which was > very rarely in > this case, therefore the low "wasted" bandwidth). > >> the only noticeable difference with PN is exactly that one (which is >> induced by the possibility left to Hblock to have two selection >> depending >> on heavy vs normal loaded link) - hence it would be interesting to >> know >> the dependency on the min/max LSP bw and distribution (scenario >> dependancy) and have a similar PN approach (non-uniform selection) > > Note that PN has the objective of preempting a small number of LSPs > of the lowest > priority (therefore ordering by decreasing bandwidth), while HBlock > aims at minimizing > the blocking probability, therefore selecting smaller LSPs which will > be more likely to be > rerouted once preempted. This is the main difference between the two > policies: Given a set > of LSPs with the same priority, PN picks the largest (in the interest > of picking few) and HBlock > picks smaller ones (even if more than one, in the interest of being > able to reroute them easily). > > I hope this helps, > > Thanks, > > Jaudelice. > >> >> thanks, >> - d. >> >> >> >> >> >> >> "Adrian Farrel" >> Sent by: owner-ccamp@ops.ietf.org >> 14/12/2006 18:02 >> Please respond to "Adrian Farrel" >> >> To: >> cc: , "Ross Callon" >> , "Brungard, Deborah A, ALABS" >> , >> >> Subject: Re: CCAMP Last call on >> draft-deoliveira-diff-te-preemption-06.txt >> >> >> Hi, >> >> I have been explicitly asked to lengthen this last call so as to >> allow >> time >> for a review. >> >> Unusual, but not unreasonable. >> >> The last call is extended to noon on Sunday 17th December. >> >> Thanks, >> Adrian >> ----- Original Message ----- >> From: "Adrian Farrel" >> To: >> Cc: ; "Ross Callon" ; >> "Brungard, Deborah A, ALABS" ; >> >> Sent: Wednesday, November 29, 2006 11:06 AM >> Subject: CCAMP Last call on draft-deoliveira-diff-te- >> preemption-06.txt >> >> >>> Hi, >>> >>> This draft has been developed independently and has recently been >> brought >>> to the IESG for advancement as an individual submission to become an >>> Informational RFC. I have done a first-level review and this latest >>> revision includes updates to reflect my comments. >>> >>> Since the material here concerns preemption and the suggested >>> ways to >>> operate an MPLS-TE or GMPLS network, we are running a quick last >>> call on >> >>> the CCAMP mailing list to ensure that no-one has any objections. >>> >>> Please send your comments to the CCAMP list no later than noon >>> GMT on >> 13th >>> December 2006. >>> >>> Thanks, >>> Adrian >>> ----- Original Message ----- >>> From: >>> To: >>> Sent: Tuesday, November 28, 2006 8:50 PM >>> Subject: I-D ACTION:draft-deoliveira-diff-te-preemption-06.txt >>> >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : LSP Preemption Policies for MPLS Traffic Engineering >>>> Author(s) : J. de Oliveira, et al. >>>> Filename : draft-deoliveira-diff-te-preemption-06.txt >>>> Pages : 19 >>>> Date : 2006-11-28 >>>> >>>> When the establishment of a higher priority (Traffic Engineering >>>> Label Switched Path) TE LSP requires the preemption of a set of >>>> lower >>>> priority TE LSPs, a node has to make a local decision to select >>>> which >>>> >>>> TE LSPs will be preempted. The preempted LSPs are then >>>> rerouted by >>>> their respective Head-end Label Switch Router (LSR). This >>>> document >>>> presents a flexible policy that can be used to achieve different >>>> objectives: preempt the lowest priority LSPs; preempt the minimum >>>> number of LSPs; preempt the set of TE LSPs that provide the >>>> closest >>>> amount of bandwidth to the required bandwidth for the >>>> preempting TE >>>> LSPs (to minimize bandwidth wastage); preempt the LSPs that >>>> will have >>>> the maximum chance to get rerouted. Simulation results are >>>> given and >>>> a comparison among several different policies, with respect to >>>> preemption cascading, number of preempted LSPs, priority, wasted >>>> bandwidth and blocking probability is also included. >>>> >>>> A URL for this Internet-Draft is: >>>> >> http://www.ietf.org/internet-drafts/draft-deoliveira-diff-te- >> preemption-06.txt >> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > _______________________________________________ > 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 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jan 17 17:40:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JRv-0001u9-55; Wed, 17 Jan 2007 17:40:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Ejo-0005eZ-UV for mpls@lists.ietf.org; Wed, 17 Jan 2007 12:38:16 -0500 Received: from outbound-mail-41.bluehost.com ([69.89.18.10]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Ejn-0007Ck-75 for mpls@lists.ietf.org; Wed, 17 Jan 2007 12:38:16 -0500 Received: (qmail 6941 invoked by uid 0); 17 Jan 2007 17:38:14 -0000 Received: from unknown (HELO box66.bluehost.com) (70.103.189.66) by mailproxy3.bluehost.com with SMTP; 17 Jan 2007 17:38:14 -0000 Received: from dhcp-guest-sjci-128-108-12-44.cisco.com ([128.107.12.44] helo=lifebook) by box66.bluehost.com with esmtp (Exim 4.52) id 1H7Ejj-0002l2-Lz; Wed, 17 Jan 2007 10:38:11 -0700 From: "Andrew Walding" To: "'shilpa goel'" , , , References: Date: Wed, 17 Jan 2007 11:38:07 -0600 Message-ID: <00aa01c73a5e$423784a0$2c0c6b80@lifebook> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc6KxoloRIALomNTcW1B5H4gi/4twAMV+eA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Identified-User: {885:box66.bluehost.com:cellstre:cellstream.com} {sentby:bopbeforesmtp 128.107.12.44 authed with cellstream.com} X-Spam-Score: 0.3 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 X-Mailman-Approved-At: Wed, 17 Jan 2007 17:40:05 -0500 Cc: Subject: [mpls] RE: [MPLS-OPS]: basic doubt about LERs in MPLS 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="===============0241267090==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0241267090== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A2_01C73A2B.F5445790" This is a multi-part message in MIME format. ------=_NextPart_000_00A2_01C73A2B.F5445790 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A3_01C73A2B.F5445790" ------=_NextPart_001_00A3_01C73A2B.F5445790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Shilpa, As you can imagine, different OS systems do things slightly differently (Cisco vs Juniper). So let's stay generic. First, MPLS is usually activated by interface on the platform. This means that a LER will have one interface (physical or logical) that is MPLS and one that is not - that is what makes it an LER. We would expect that on the interface that is not MPLS enabled to receive packets and frames that do not have MPLS labels. The layer 2 PID or ethertype will clearly identify the contents of the arriving frame (usually 0x08000 is IP). Based on this the lookup will be to the IP forwarding table. The other alternative a packet arriving on the MPLS enabled interface. This type of interface usually can receive both MPLS encapsulated and non MPLS encapsulated. Again, we depend on the Layer 2 PID or ethertype to tell us (MPLS encap Unicast IP = 0x08847, MPLS encap Multicast IP - 0x08848). With either of these, we look up the LFIB. With regards to transport between routers for protocol messaging, since IP and MPLS encaps can be received on an interface, either can be used. There are reserved labels (0-15) though not all are specified. Label value of 1 is reserved for router to router messaging - similar to the ILMI or LMI channel in Frame and ATM. Does that help? Andy http://www.cellstream.com _____ From: shilpa goel [mailto:shilpa07@gmail.com] Sent: Wednesday, January 17, 2007 5:09 AM To: mpls@uu.net; mpls@lists.ietf.org; mpls-ops@mplsrc.com Subject: [MPLS-OPS]: basic doubt about LERs in MPLS Hi, I have one basic doubt regarding LERs in IP/MPLS networks. How does a LER decide whether it should do IP routing (i.e. IP Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that it receives at an interface? Linked to this I have another doubt that how are control/protocol packets (which are IP) routed in a router i.e. are they label switched along the LSPs that exist for the FECs/destinations to which they are addressed or by default IP routed? regards, Shilpa ------=_NextPart_001_00A3_01C73A2B.F5445790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Shilpa,
As you can imagine, different OS systems do things = slightly=20 differently (Cisco vs Juniper).  So let's stay = generic.
 
First, MPLS is usually activated by interface on the=20 platform.  This means that a LER will have one interface (physical = or=20 logical) that is MPLS and one that is not - that is what makes it an = LER. =20 We would expect that on the interface that is not MPLS enabled to = receive=20 packets and frames that do not have MPLS labels.  The layer 2 PID = or=20 ethertype will clearly identify the contents of the arriving frame = (usually=20 0x08000 is IP).  Based on this the lookup will be to the IP = forwarding=20 table.
 
The other alternative a packet arriving on the MPLS = enabled=20 interface.  This type of interface usually can receive both MPLS=20 encapsulated and non MPLS encapsulated.  Again, we depend on the = Layer 2=20 PID or ethertype to tell us (MPLS encap Unicast IP =3D 0x08847, = MPLS encap=20 Multicast IP - 0x08848).  With either of these, we look up the=20 LFIB.
 
With regards to transport between routers for protocol = messaging,=20 since IP and MPLS encaps can be received on an interface, either can be=20 used.  There are reserved labels (0-15) though not all are = specified. =20 Label value of 1 is reserved for router to router messaging - similar to = the=20 ILMI or LMI channel in Frame and ATM.
 
Does that help?
 
 
Andy
 

From: shilpa goel = [mailto:shilpa07@gmail.com]=20
Sent: Wednesday, January 17, 2007 5:09 AM
To: = mpls@uu.net;=20 mpls@lists.ietf.org; mpls-ops@mplsrc.com
Subject: [MPLS-OPS]: = basic=20 doubt about LERs in MPLS

Hi,
 
 I have one basic doubt regarding LERs in IP/MPLS = networks.

How=20 does a LER decide whether it should do IP routing (i.e. IP Forwarding = Table=20 lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that = it=20 receives at an interface?

Linked to this I have another doubt = that how=20 are control/protocol packets (which are IP) routed in a router i.e. are = they=20 label switched along the LSPs that exist for the FECs/destinations to = which they=20 are addressed or by default IP routed?
 
regards,
Shilpa

------=_NextPart_001_00A3_01C73A2B.F5445790-- ------=_NextPart_000_00A2_01C73A2B.F5445790 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1jCCAl4w ggHHoAMCAQICEG98mfP+cZQWmZ+Y2GhnmzQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkwOTE4MDk1MFoXDTA3MDkwOTE4MDk1 MFowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYW5k eXdAY2VsbHN0cmVhbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM6WxDbqfyCbNaTw FszRRcznYa0uo9hTrRFKtYQbJPYADEl706ezHC2dXp7+Qdfnm8nDRQdhTiEw2FYA+pMqzoZ7jT54 /CSghBvhQPpaeVZ8XiFMxI97n+gWvDvNZacC9DQW0/h8hY1wHCZMW02B+p76DfRdr/w9+XJ2ObKp X7FZAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGFuZHl3QGNlbGxzdHJlYW0uY29tMAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADgYEAWn83GjKHNBfkaa1GY15XqHHk1d8mBZ4hBQJvO0DypaIekEjI 1OnpQ7NJ+Ds/7WDtAAW17K6iRclqDtNVXEqivHiTSNibJ/uXrWXVglsnoTSUeKONQEtrBH8Y4bvo OIJdCFrYKETvvcUCYnTiHiOl+TOeIF4ZvX5AS63198ZXkgEwggMtMIIClqADAgECAgEAMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYw MTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGw hF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d4 9vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQAB oxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg 0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o 6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMIID PzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVw jt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDww OjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEz ODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82 L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fW xghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAvgwggL0AgEBMHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBvfJnz/nGUFpmfmNhoZ5s0MAkGBSsO AwIaBQCgggHYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDEx NzE3MzgwN1owIwYJKoZIhvcNAQkEMRYEFCtHGE7Q1tvwPbO8AyarTmawy4SIMGcGCSqGSIb3DQEJ DzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGFBgkrBgEEAYI3EAQxeDB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQb3yZ8/5xlBaZn5jYaGeb NDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQb3yZ8/5xlBaZn5jYaGebNDANBgkqhkiG9w0BAQEFAASBgHSNAshgzNvOFxPg/AO/ w6ZhbffZWW1tjzZLfsBIP6RX31kkOQvoi2BV3ClLX2ZibZlgg/nTNV0LBBd9xZqibBrkVkA04CV+ i1NSEXmYT54WyA7fr+4qymcImBkcFIa1SYaMg59qrvDtD65jV31mbrRRgfwGn9Wo7cR5VSh3qSK9 AAAAAAAA ------=_NextPart_000_00A2_01C73A2B.F5445790-- --===============0241267090== 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 --===============0241267090==-- From mpls-bounces@lists.ietf.org Thu Jan 18 05:05:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7U7B-0005Jp-W8; Thu, 18 Jan 2007 05:03:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7U7A-0005Jj-57 for mpls@lists.ietf.org; Thu, 18 Jan 2007 05:03:24 -0500 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7U77-0005zh-K5 for mpls@lists.ietf.org; Thu, 18 Jan 2007 05:03:24 -0500 Received: by wr-out-0506.google.com with SMTP id 68so110887wra for ; Thu, 18 Jan 2007 02:03:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=qQDpKwQ+lxMaNh/0RJ2Qa6M/s6e4h09WwTQhkAo5PhclzJYJl7hZyATmut+oAHEiB7XO8/gRgg6QyOXU0Bm8y3+ponPszxPWFKB+OEHwvexe3F6mVaQD0yjT0nLDwm9IwI/L2oEWH7m1Fnn+4TobV4EMH5YSTOffVLc1+qg7SPg= Received: by 10.78.185.16 with SMTP id i16mr649105huf.1169114600002; Thu, 18 Jan 2007 02:03:20 -0800 (PST) Received: by 10.78.121.9 with HTTP; Thu, 18 Jan 2007 02:03:19 -0800 (PST) Message-ID: Date: Thu, 18 Jan 2007 15:33:19 +0530 From: "shilpa goel" To: mpls@uu.net, mpls@lists.ietf.org, mpls-ops@mplsrc.com In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.7 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: Subject: [mpls] [MPLS-OPS]: basic doubt about LERs in MPLS 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="===============0362345665==" Errors-To: mpls-bounces@lists.ietf.org --===============0362345665== Content-Type: multipart/alternative; boundary="----=_Part_106586_2008311.1169114599933" ------=_Part_106586_2008311.1169114599933 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: shilpa goel Date: Jan 18, 2007 3:32 PM Subject: Re: [MPLS-OPS]: basic doubt about LERs in MPLS To: Christopher Young Christopher, Thanks for the reply. Can you give me a little more insight on the points given below? You have mentioned that 'The destination of that packet will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and sent over an LSP' As I understand routers maintain 2 routes - one in IP forwarding table for some destination say 192.168.1.0 and one in MPLS LFIB with the same destination address. I am considering the case of LDP protocol setting up LSPs in response to route updates by IGPs. Now when a LER interface receives an IP packet with destination 192.168.1.0, will it consult some common table which will indicate which of the 2 tables mentioned above (IP or MPLS) will be used for routing of the packet? If so, how is this common table configured? Also is it "possible" or "advisable" for all packets (control/protocol or management) generated at the router to be IP routed by default? What is the usually adopted implementation? thanks, Shilpa On 1/17/07, Christopher Young wrote: > > Shilpa, > > > > For your first question an LER always does a lookup on the IP destination > address of a packet regardless of whether or not the packet is meant to be > encapsulated with MPLS or not. In other words, a router still functions like > a router even with MPLS turned on. The destination of that packet will yield > whether or not the packet will be sent out over a regular IP interface or > encapsulated in MPLS and sent over an LSP. > > > > (NOTE: In L2 VPN's where you don't do a L3 lookup this is different as > usually a configured association is made between a CE-to-PE interface and an > LSP) > > > > > > For your second question, my statement above still applies. For example if > your IP routing table yields the LSP as the next-hop to the loop back > address of your IBGP peer then you send the BGP packets over the LSP. For > ISIS,OSPF, RSVP and LDP control packets those will still be sent out on the > base POS/ATM/GE IP interface without MPLS encapsulation, but that is an > exercise left up to the individual vendor. Note that if using hierarchical > MPLS tunnels (LDP over RSVP) the LDP packets would ride over the MPLS LSP. > Also, of note is that in all vendors you can control whether or not IP > traffic and IGPs actually use LSPs for forwarding and next-hop computation > with configuration knobs. > > > > Hope this helps. > > > > Thanks, > > > > > > Christopher Young > Resident Engineer > JNCIP-E ERX #9 > (978) 973-0574 > cyoung@juniper.net > ------------------------------ > > *From:* shilpa goel [mailto:shilpa07@gmail.com] > *Sent:* Wednesday, January 17, 2007 6:09 AM > *To:* mpls@uu.net; mpls@lists.ietf.org; mpls-ops@mplsrc.com > *Subject:* [MPLS-OPS]: basic doubt about LERs in MPLS > > > > Hi, > > > > I have one basic doubt regarding LERs in IP/MPLS networks. > > How does a LER decide whether it should do IP routing (i.e. IP Forwarding > Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets > that it receives at an interface? > > Linked to this I have another doubt that how are control/protocol packets > (which are IP) routed in a router i.e. are they label switched along the > LSPs that exist for the FECs/destinations to which they are addressed or by > default IP routed? > > > > regards, > Shilpa > ------=_Part_106586_2008311.1169114599933 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

---------- Forwarded message ----------
From: shilpa goel <shilpa07@gmail.com>
Date: Jan 18, 2007 3:32 PM
Subject: Re: [MPLS-OPS]: basic doubt about LERs in MPLS
To: Christopher Young <cyoung@juniper.net>

 Christopher,

Thanks for the reply. Can you give me a little more insight on the points given below?

You have mentioned that 'The destination of that packet will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and sent over an LSP'
As I understand routers maintain 2 routes - one in IP forwarding table for some destination say 192.168.1.0 and one in MPLS LFIB with the same destination address. I am considering the case of LDP protocol setting up LSPs in response to route updates by IGPs. Now when a LER interface receives an IP packet with destination 192.168.1.0, will it consult some common table which will indicate which of the 2 tables mentioned above (IP or MPLS) will be used for routing of the packet? If so, how is this common table configured?

Also is it "possible" or "advisable" for all packets (control/protocol or management) generated at the router to be IP routed by default? What is the usually adopted implementation?

thanks,
Shilpa
On 1/17/07, Christopher Young < cyoung@juniper.net> wrote:

Shilpa,

 

For your first question an LER always does a lookup on the IP destination address of a packet regardless of whether or not the packet is meant to be encapsulated with MPLS or not. In other words, a router still functions like a router even with MPLS turned on. The destination of that packet will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and sent over an LSP.

 

(NOTE: In L2 VPN's where you don't do a L3 lookup this is different as usually a configured association is made between a CE-to-PE interface and an LSP)

 

 

For your second question, my statement above still applies. For example if your IP routing table yields the LSP as the next-hop to the loop back address of your IBGP peer then you send the BGP packets over the LSP.  For ISIS,OSPF, RSVP and LDP control packets those will still be sent out on the base POS/ATM/GE IP interface without MPLS encapsulation, but that is an exercise left up to the individual vendor. Note that if using hierarchical MPLS tunnels (LDP over RSVP) the LDP packets would ride over the MPLS LSP. Also, of note is that in all vendors you can control whether or not IP traffic and IGPs actually use LSPs for forwarding and next-hop computation with configuration knobs.

 

Hope this helps.

 

Thanks,

 

 

Christopher Young
Resident Engineer
JNCIP-E ERX #9
(978) 973-0574
cyoung@juniper.net

From: shilpa goel [mailto:shilpa07@gmail.com]
Sent: Wednesday, January 17, 2007 6:09 AM
To: mpls@uu.net; mpls@lists.ietf.org; mpls-ops@mplsrc.com
Subject: [MPLS-OPS]: basic doubt about LERs in MPLS

 

Hi,

 

 I have one basic doubt regarding LERs in IP/MPLS networks.

How does a LER decide whether it should do IP routing (i.e. IP Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that it receives at an interface?

Linked to this I have another doubt that how are control/protocol packets (which are IP) routed in a router i.e. are they label switched along the LSPs that exist for the FECs/destinations to which they are addressed or by default IP routed?

 

regards,
Shilpa


------=_Part_106586_2008311.1169114599933-- --===============0362345665== 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 --===============0362345665==-- From mpls-bounces@lists.ietf.org Thu Jan 18 05:05:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7U95-0006Pd-NS; Thu, 18 Jan 2007 05:05:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7U94-0006PU-3g for mpls@lists.ietf.org; Thu, 18 Jan 2007 05:05:22 -0500 Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7U91-0006FI-Dz for mpls@lists.ietf.org; Thu, 18 Jan 2007 05:05:22 -0500 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JC2000IC6ONIZ@firewall.mci.com> for mpls@lists.ietf.org; Thu, 18 Jan 2007 10:05:17 +0000 (GMT) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQvxqe26056; Thu, 18 Jan 2007 10:05:06 +0000 (GMT) Received: by mail-control.ash.ops.us.uu.net id QQvxqe04660 for mpls-outgoing; Thu, 18 Jan 2007 10:05:01 +0000 (GMT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQvxqe04651 for ; Thu, 18 Jan 2007 10:04:58 +0000 (GMT) Received: from dgismtp04.wcomnet.com by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dgismtp04.mcilink.com [166.38.58.144]) id l0IA4vqq011132 for ; Thu, 18 Jan 2007 10:04:57 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([127.0.0.1]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JC200AB66O9G5@dgismtp04.mcilink.com> for mpls@uu.net; Thu, 18 Jan 2007 10:04:57 +0000 (GMT) Received: from pmmspam04.mcilink.com ([166.37.156.164]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JC20099I6O8UF@dgismtp04.mcilink.com> for mpls@uu.net; Thu, 18 Jan 2007 10:04:57 +0000 (GMT) Received: from pmesmtp04.mci.com (pmesmtp04.mci.com [199.249.20.36]) by pmmspam04.mcilink.com (8.13.1/8.13.1) with ESMTP id l0IA4qxt027505 for ; Thu, 18 Jan 2007 10:04:56 +0000 (GMT) Received: from pmesmtp04.mci.com ([127.0.0.1]) by firewall.mci.com (Iplanet MTA 5.2) with SMTP id <0JC200IF96O6IQ@firewall.mci.com> for mpls@uu.net; Thu, 18 Jan 2007 10:04:54 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.173]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JC200IF56O5C6@firewall.mci.com> for mpls@uu.net; Thu, 18 Jan 2007 10:04:54 +0000 (GMT) Received: by ug-out-1314.google.com with SMTP id o2so122428uge for ; Thu, 18 Jan 2007 02:04:52 -0800 (PST) Received: by 10.78.185.16 with SMTP id i16mr649105huf.1169114600002; Thu, 18 Jan 2007 02:03:20 -0800 (PST) Received: by 10.78.121.9 with HTTP; Thu, 18 Jan 2007 02:03:19 -0800 (PST) Date: Thu, 18 Jan 2007 15:33:19 +0530 From: shilpa goel In-reply-to: To: mpls@UU.NET, mpls@lists.ietf.org, mpls-ops@mplsrc.com Message-id: MIME-version: 1.0 Precedence: bulk DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=qQDpKwQ+lxMaNh/0RJ2Qa6M/s6e4h09WwTQhkAo5PhclzJYJl7hZyATmut+oAHEiB7XO8/gRgg6QyOXU0Bm8y3+ponPszxPWFKB+OEHwvexe3F6mVaQD0yjT0nLDwm9IwI/L2oEWH7m1Fnn+4TobV4EMH5YSTOffVLc1+qg7SPg= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0 adultscore=0 adjust=0 reason=mlx engine=3.1.0-0612050001 definitions=main-0701180007 References: X-Spam-Score: 0.7 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: Subject: [mpls] [MPLS-OPS]: basic doubt about LERs in MPLS X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0583067542==" Errors-To: mpls-bounces@lists.ietf.org --===============0583067542== Content-type: multipart/alternative; boundary="----=_Part_106586_2008311.1169114599933" ------=_Part_106586_2008311.1169114599933 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: shilpa goel Date: Jan 18, 2007 3:32 PM Subject: Re: [MPLS-OPS]: basic doubt about LERs in MPLS To: Christopher Young Christopher, Thanks for the reply. Can you give me a little more insight on the points given below? You have mentioned that 'The destination of that packet will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and sent over an LSP' As I understand routers maintain 2 routes - one in IP forwarding table for some destination say 192.168.1.0 and one in MPLS LFIB with the same destination address. I am considering the case of LDP protocol setting up LSPs in response to route updates by IGPs. Now when a LER interface receives an IP packet with destination 192.168.1.0, will it consult some common table which will indicate which of the 2 tables mentioned above (IP or MPLS) will be used for routing of the packet? If so, how is this common table configured? Also is it "possible" or "advisable" for all packets (control/protocol or management) generated at the router to be IP routed by default? What is the usually adopted implementation? thanks, Shilpa On 1/17/07, Christopher Young wrote: > > Shilpa, > > > > For your first question an LER always does a lookup on the IP destination > address of a packet regardless of whether or not the packet is meant to be > encapsulated with MPLS or not. In other words, a router still functions like > a router even with MPLS turned on. The destination of that packet will yield > whether or not the packet will be sent out over a regular IP interface or > encapsulated in MPLS and sent over an LSP. > > > > (NOTE: In L2 VPN's where you don't do a L3 lookup this is different as > usually a configured association is made between a CE-to-PE interface and an > LSP) > > > > > > For your second question, my statement above still applies. For example if > your IP routing table yields the LSP as the next-hop to the loop back > address of your IBGP peer then you send the BGP packets over the LSP. For > ISIS,OSPF, RSVP and LDP control packets those will still be sent out on the > base POS/ATM/GE IP interface without MPLS encapsulation, but that is an > exercise left up to the individual vendor. Note that if using hierarchical > MPLS tunnels (LDP over RSVP) the LDP packets would ride over the MPLS LSP. > Also, of note is that in all vendors you can control whether or not IP > traffic and IGPs actually use LSPs for forwarding and next-hop computation > with configuration knobs. > > > > Hope this helps. > > > > Thanks, > > > > > > Christopher Young > Resident Engineer > JNCIP-E ERX #9 > (978) 973-0574 > cyoung@juniper.net > ------------------------------ > > *From:* shilpa goel [mailto:shilpa07@gmail.com] > *Sent:* Wednesday, January 17, 2007 6:09 AM > *To:* mpls@uu.net; mpls@lists.ietf.org; mpls-ops@mplsrc.com > *Subject:* [MPLS-OPS]: basic doubt about LERs in MPLS > > > > Hi, > > > > I have one basic doubt regarding LERs in IP/MPLS networks. > > How does a LER decide whether it should do IP routing (i.e. IP Forwarding > Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets > that it receives at an interface? > > Linked to this I have another doubt that how are control/protocol packets > (which are IP) routed in a router i.e. are they label switched along the > LSPs that exist for the FECs/destinations to which they are addressed or by > default IP routed? > > > > regards, > Shilpa > ------=_Part_106586_2008311.1169114599933 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

---------- Forwarded message ----------
From: shilpa goel <shilpa07@gmail.com>
Date: Jan 18, 2007 3:32 PM
Subject: Re: [MPLS-OPS]: basic doubt about LERs in MPLS
To: Christopher Young <cyoung@juniper.net>

 Christopher,

Thanks for the reply. Can you give me a little more insight on the points given below?

You have mentioned that 'The destination of that packet will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and sent over an LSP'
As I understand routers maintain 2 routes - one in IP forwarding table for some destination say 192.168.1.0 and one in MPLS LFIB with the same destination address. I am considering the case of LDP protocol setting up LSPs in response to route updates by IGPs. Now when a LER interface receives an IP packet with destination 192.168.1.0, will it consult some common table which will indicate which of the 2 tables mentioned above (IP or MPLS) will be used for routing of the packet? If so, how is this common table configured?

Also is it "possible" or "advisable" for all packets (control/protocol or management) generated at the router to be IP routed by default? What is the usually adopted implementation?

thanks,
Shilpa
On 1/17/07, Christopher Young < cyoung@juniper.net> wrote:

Shilpa,

 

For your first question an LER always does a lookup on the IP destination address of a packet regardless of whether or not the packet is meant to be encapsulated with MPLS or not. In other words, a router still functions like a router even with MPLS turned on. The destination of that packet will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and sent over an LSP.

 

(NOTE: In L2 VPN's where you don't do a L3 lookup this is different as usually a configured association is made between a CE-to-PE interface and an LSP)

 

 

For your second question, my statement above still applies. For example if your IP routing table yields the LSP as the next-hop to the loop back address of your IBGP peer then you send the BGP packets over the LSP.  For ISIS,OSPF, RSVP and LDP control packets those will still be sent out on the base POS/ATM/GE IP interface without MPLS encapsulation, but that is an exercise left up to the individual vendor. Note that if using hierarchical MPLS tunnels (LDP over RSVP) the LDP packets would ride over the MPLS LSP. Also, of note is that in all vendors you can control whether or not IP traffic and IGPs actually use LSPs for forwarding and next-hop computation with configuration knobs.

 

Hope this helps.

 

Thanks,

 

 

Christopher Young
Resident Engineer
JNCIP-E ERX #9
(978) 973-0574
cyoung@juniper.net

From: shilpa goel [mailto:shilpa07@gmail.com]
Sent: Wednesday, January 17, 2007 6:09 AM
To: mpls@uu.net; mpls@lists.ietf.org; mpls-ops@mplsrc.com
Subject: [MPLS-OPS]: basic doubt about LERs in MPLS

 

Hi,

 

 I have one basic doubt regarding LERs in IP/MPLS networks.

How does a LER decide whether it should do IP routing (i.e. IP Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that it receives at an interface?

Linked to this I have another doubt that how are control/protocol packets (which are IP) routed in a router i.e. are they label switched along the LSPs that exist for the FECs/destinations to which they are addressed or by default IP routed?

 

regards,
Shilpa


------=_Part_106586_2008311.1169114599933-- --===============0583067542== 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 --===============0583067542==-- From mpls-bounces@lists.ietf.org Thu Jan 18 08:49:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XbW-0005kE-I2; Thu, 18 Jan 2007 08:46:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XbV-0005k3-J4 for mpls@lists.ietf.org; Thu, 18 Jan 2007 08:46:57 -0500 Received: from borg.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7XbT-0007be-Fr for mpls@lists.ietf.org; Thu, 18 Jan 2007 08:46:57 -0500 Received: from unknown (HELO pi-smtp.jnpr.net) ([10.10.2.36]) by borg.juniper.net with ESMTP; 18 Jan 2007 05:43:01 -0800 X-IronPort-AV: i="4.13,204,1167638400"; d="scan'208,217"; a="659119421:sNHT112795584" Received: from emailwf1.jnpr.net ([10.10.2.33]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Jan 2007 08:46:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Jan 2007 08:46:52 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MPLS-OPS]: basic doubt about LERs in MPLS Thread-Index: Acc68Pd91OeKeGUbTk6CyqYSoIsc7QAFbKGg From: "Christopher Young" To: "shilpa goel" , , , X-OriginalArrivalTime: 18 Jan 2007 13:46:53.0449 (UTC) FILETIME=[1CA14790:01C73B07] X-Spam-Score: 0.7 (/) X-Scan-Signature: 510197464235b7be9252a74662931ef9 Cc: Subject: [mpls] RE: [MPLS-OPS]: basic doubt about LERs in MPLS 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="===============0001013980==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0001013980== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73B07.1BFE14CF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73B07.1BFE14CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shilpa, =20 Here is an example from an MPLS BGP VPN which shows the flow of information you are looking for. In this example the destination address would be 30.6.0.0. A route lookup in the virtual routing and forwarding instance table indicates that the next hop is an MPLS next-hop with a VPN label of 16 to be appended on to the packet, with a base label for the LSP of 19 which goes out over the POS0/0 physical interface. You are correct in that there are separate tables that maintain all of this information. The detailed routing table display ties it all together and shows the complete forwarding decision that is made for reaching this destination of 30.6.0.0 =20 =20 =20 test:pe1#sh ip route vrf vpn1 30.6.0.0 detail Protocol/Route type codes: I1- ISIS level 1, I2- ISIS level2, I- route type intra, IA- route type inter, E- route type external, i- metric type internal, e- metric type external, O- OSPF, E1- external type 1, E2- external type2, N1- NSSA external type1, N2- NSSA external type2 L- MPLS label, V- VRF, *- via indirect next-hop =20 30.6.0.0/30 Type: Bgp Distance: 200 Metric: 0 Tag: 0 Class: 0 MPLS next-hop: 132, label 16, VPN traffic, resolved by MPLS next-hop 60 MPLS next-hop: 60, resolved by MPLS next-hop 123, peer 31.0.0.1 MPLS next-hop: 123, label 19 on POS0/0 (ip19000002.mpls.ip [V:pe1]), nbr 11.13.0.1 =20 =20 This is an example of an MPLS forwarding table entry showing a label binding to the FEC 31.0.0.1. If you look at the display above you see that this label of 19 is displayed in the detailed "show ip route" output as the base label to append to packets headed to the next hop PE router 31.0.0.1 which originated the VPN route 30.6.0.0. =20 test:pe1#sh mpls ip binding 31.0.0.1 31.0.0.1/32 Out 19 neighbor 11.13.0.13 Out 20 neighbor 11.14.0.14 =20 Hope this helps in illustrating the forwarding decision. =20 Thanks, =20 Christopher Young Resident Engineer JNCIP-E ERX #9 (978) 973-0574 cyoung@juniper.net =20 ________________________________ From: shilpa goel [mailto:shilpa07@gmail.com]=20 Sent: Thursday, January 18, 2007 5:03 AM To: mpls@uu.net; mpls@lists.ietf.org; mpls-ops@mplsrc.com Subject: [MPLS-OPS]: basic doubt about LERs in MPLS =20 ---------- Forwarded message ---------- From: shilpa goel Date: Jan 18, 2007 3:32 PM=20 Subject: Re: [MPLS-OPS]: basic doubt about LERs in MPLS To: Christopher Young Christopher, Thanks for the reply. Can you give me a little more insight on the points given below? You have mentioned that 'The destination of that packet will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and sent over an LSP' As I understand routers maintain 2 routes - one in IP forwarding table for some destination say 192.168.1.0 and one in MPLS LFIB with the same destination address. I am considering the case of LDP protocol setting up LSPs in response to route updates by IGPs. Now when a LER interface receives an IP packet with destination 192.168.1.0 , will it consult some common table which will indicate which of the 2 tables mentioned above (IP or MPLS) will be used for routing of the packet? If so, how is this common table configured?=20 Also is it "possible" or "advisable" for all packets (control/protocol or management) generated at the router to be IP routed by default? What is the usually adopted implementation? thanks, Shilpa On 1/17/07, Christopher Young < cyoung@juniper.net > wrote:=20 Shilpa, =20 For your first question an LER always does a lookup on the IP destination address of a packet regardless of whether or not the packet is meant to be encapsulated with MPLS or not. In other words, a router still functions like a router even with MPLS turned on. The destination of that packet will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and sent over an LSP. =20 (NOTE: In L2 VPN's where you don't do a L3 lookup this is different as usually a configured association is made between a CE-to-PE interface and an LSP) =20 =20 For your second question, my statement above still applies. For example if your IP routing table yields the LSP as the next-hop to the loop back address of your IBGP peer then you send the BGP packets over the LSP. For ISIS,OSPF, RSVP and LDP control packets those will still be sent out on the base POS/ATM/GE IP interface without MPLS encapsulation, but that is an exercise left up to the individual vendor. Note that if using hierarchical MPLS tunnels (LDP over RSVP) the LDP packets would ride over the MPLS LSP. Also, of note is that in all vendors you can control whether or not IP traffic and IGPs actually use LSPs for forwarding and next-hop computation with configuration knobs.=20 =20 Hope this helps. =20 Thanks, =20 =20 Christopher Young Resident Engineer JNCIP-E ERX #9 (978) 973-0574 cyoung@juniper.net =09 ________________________________ From: shilpa goel [mailto:shilpa07@gmail.com]=20 Sent: Wednesday, January 17, 2007 6:09 AM To: mpls@uu.net; mpls@lists.ietf.org; mpls-ops@mplsrc.com Subject: [MPLS-OPS]: basic doubt about LERs in MPLS =20 Hi, =20 I have one basic doubt regarding LERs in IP/MPLS networks. =09 How does a LER decide whether it should do IP routing (i.e. IP Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that it receives at an interface?=20 =09 Linked to this I have another doubt that how are control/protocol packets (which are IP) routed in a router i.e. are they label switched along the LSPs that exist for the FECs/destinations to which they are addressed or by default IP routed?=20 =20 regards, Shilpa =20 ------_=_NextPart_001_01C73B07.1BFE14CF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shilpa,

=

 

Here is an example from an MPLS BGP = VPN which shows the flow of information you are looking for. In this example the destination address would be 30.6.0.0. A route lookup in the virtual = routing and forwarding instance table indicates that the next hop is an MPLS = next-hop with a VPN label of 16 to be appended on to the packet, with a = base label for the LSP of 19 which goes out = over the POS0/0 physical interface. You are correct in that there are = separate tables that maintain all of this information. The detailed routing table display ties it all together and = shows the complete forwarding decision that is made for reaching this = destination of 30.6.0.0

 

 

 

test:pe1#sh ip route vrf vpn1 = 30.6.0.0 detail

Protocol/Route type = codes:

  I1- ISIS level 1, I2- ISIS = level2,

  I- route type intra, IA- = route type inter, E- route type external,

  i- metric type internal, e- = metric type external,

  O- OSPF, E1- external type = 1, E2- external type2,

  N1- NSSA external type1, N2- = NSSA external type2

  L- MPLS label, V- VRF, *- = via indirect next-hop

 

30.6.0.0/30 Type: Bgp Distance: 200 Metric: 0 Tag: 0 Class: 0

  MPLS next-hop: 132, = label 16, VPN = traffic, resolved by MPLS next-hop 60

    MPLS next-hop: = 60, resolved by MPLS next-hop 123, peer 31.0.0.1

      MPLS = next-hop: 123, label = 19 on POS0/0 (ip19000002.mpls.ip [V:pe1]), nbr = 11.13.0.1

 

 

This is an example of an MPLS = forwarding table entry showing a label binding to the FEC 31.0.0.1. If you look at = the display above you see that this = label of 19 is displayed in the detailed “show ip route” output as the = base label to append to packets headed to the = next hop PE router 31.0.0.1 which originated the VPN route = 30.6.0.0.

 

test:pe1#sh mpls ip binding = 31.0.0.1

  = 31.0.0.1/32

    Out   = 19  neighbor 11.13.0.13

    Out   = 20  neighbor 11.14.0.14

 

Hope this helps in illustrating the forwarding decision.

 

Thanks,

=

 

Christopher Young
Resident Engineer
JNCIP-E ERX #9
(978) 973-0574
cyoung@juniper.net

 

From: = shilpa goel [mailto:shilpa07@gmail.com]
Sent: Thursday, January = 18, 2007 5:03 AM
To: mpls@uu.net; = mpls@lists.ietf.org; mpls-ops@mplsrc.com
Subject: [MPLS-OPS]: = basic doubt about LERs in MPLS

 



---------- Forwarded message ----------
From: shilpa goel <shilpa07@gmail.com>
Date: Jan 18, 2007 3:32 PM
Subject: Re: [MPLS-OPS]: basic doubt about LERs = in MPLS
To: Christopher = Young <cyoung@juniper.net>

Christopher,

Thanks for the reply. Can you give me a little more insight on the = points given below?

You have mentioned that 'The destination of that packet = will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and = sent over an LSP'
As I understand routers maintain 2 routes - one in IP forwarding table = for some destination say 192.168.1.0 and one in MPLS LFIB with the same destination address. I am considering the = case of LDP protocol setting up LSPs in response to = route updates by IGPs. Now when a LER interface receives an IP packet with destination = 192.168.1.0, will it = consult some common table which will indicate which of the 2 tables mentioned = above (IP or MPLS) will be used for = routing of the packet? If so, how is this common table configured?

Also is it "possible" or "advisable" for all packets (control/protocol or management) generated at the router to be IP routed = by default? What is the usually adopted implementation?

thanks,
Shilpa

On 1/17/07, Christopher = Young < = cyoung@juniper.net> wrote:

Shilpa,

 

For your first question an LER always does a lookup on = the IP destination address of a packet regardless of whether or not the packet = is meant to be encapsulated with MPLS or not. In other words, a router = still functions like a router even with MPLS turned on. The destination of = that packet will yield whether or not the packet will be sent out over a regular IP interface or encapsulated in MPLS and = sent over an = LSP.

 

(NOTE: In L2 VPN's where you don't do a L3 lookup this = is different as usually a configured association is made between a CE-to-PE interface and an LSP)

 

 

For your second question, my statement above still applies. For example if your IP = routing table yields the LSP as the next-hop to the loop back address of your = IBGP peer then you send the BGP = packets over the LSP.  For ISIS,OSPF, RSVP = and LDP control packets those will = still be sent out on the base POS/ATM/GE IP interface without MPLS encapsulation, but that is an = exercise left up to the individual vendor. Note = that if using hierarchical MPLS tunnels (LDP over RSVP) the LDP packets would = ride over the MPLS LSP. Also, of note is that in all vendors you can control = whether or not IP traffic and IGPs actually use LSPs for forwarding and next-hop computation with configuration knobs. =

 

Hope this helps.

 

Thanks,

 

 

Christopher = Young
Resident Engineer
JNCIP-E ERX #9
(978) 973-0574
cyoung@juniper.net

From: shilpa goel [mailto:shilpa07@gmail.com]
Sent: Wednesday, January = 17, 2007 6:09 AM
To: mpls@uu.net; mpls@lists.ietf.org; mpls-ops@mplsrc.com
Subject: [MPLS-OPS]: = basic doubt about LERs in MPLS

 

Hi,

 

 I have one basic doubt regarding LERs in IP/MPLS networks.

How does a LER decide whether it should do IP routing (i.e. IP = Forwarding Table lookup) or labelling (i.e. LFIB lookup) of the unlabeled IP packets that = it receives at an interface?

Linked to this I have another doubt that how are control/protocol = packets (which are IP) routed in a router i.e. are they label switched along the = LSPs that exist for the FECs/destinations to which they are = addressed or by default IP routed? =

 

regards,
Shilpa

 

------_=_NextPart_001_01C73B07.1BFE14CF-- --===============0001013980== 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 --===============0001013980==-- From mpls-bounces@lists.ietf.org Thu Jan 18 13:45:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7cEE-0005UG-G0; Thu, 18 Jan 2007 13:43:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7cEC-0005U7-44; Thu, 18 Jan 2007 13:43:12 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7cEA-0000gJ-NZ; Thu, 18 Jan 2007 13:43:12 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l0IIhAoL027785; Thu, 18 Jan 2007 10:43:10 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l0IIhALN027784; Thu, 18 Jan 2007 10:43:10 -0800 Date: Thu, 18 Jan 2007 10:43:10 -0800 Message-Id: <200701181843.l0IIhALN027784@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mpls@lists.ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 4781 on Graceful Restart Mechanism for BGP with MPLS 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: , Errors-To: mpls-bounces@lists.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4781 Title: Graceful Restart Mechanism for BGP with MPLS Author: Y. Rekhter, R. Aggarwal Status: Standards Track Date: January 2007 Mailbox: yakov@juniper.net, rahul@juniper.net Pages: 10 Characters: 23249 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-bgp-mpls-restart-05.txt URL: http://www.rfc-editor.org/rfc/rfc4781.txt A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to 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 families that could be carried in BGP (e.g., IPv4, IPv6, etc.). [STANDARDS TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun Jan 21 10:40:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8ekA-0000FB-It; Sun, 21 Jan 2007 10:36:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8ek9-0000C8-9P for mpls@lists.ietf.org; Sun, 21 Jan 2007 10:36:29 -0500 Received: from smtp20.msg.oleane.net ([62.161.4.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8ek6-0001Aq-Rw for mpls@lists.ietf.org; Sun, 21 Jan 2007 10:36:29 -0500 Received: from Pavillonquatre (154.34.70-86.rev.gaoland.net [86.70.34.154]) by smtp20.msg.oleane.net (MTA) with ESMTP id l0LFaKRf027843 for ; Sun, 21 Jan 2007 16:36:21 +0100 Message-Id: <200701211536.l0LFaKRf027843@smtp20.msg.oleane.net> From: "Chantal Ladouce" To: Date: Sun, 21 Jan 2007 16:36:16 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc9ceNSjcXe5V/xRWm/091jqfxjrw== X-Spam-Score: 0.2 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: [mpls] MPLS World Congress 2007 - Paris 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="===============0482613385==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0482613385== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0208_01C73D7A.45A64EE0" This is a multi-part message in MIME format. ------=_NextPart_000_0208_01C73D7A.45A64EE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Don't miss the 9th edition of the MPLS World Congress, which will stand in Paris from February 6th to 9th, 2007. For more info and to register, please visit: http://www.upperside.fr/mpls2007/mplsworld2007registration.htm We hope to see you there in February! ------=_NextPart_000_0208_01C73D7A.45A64EE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Don't miss the 9th edition of the = MPLS World = Congress, which will stand in Paris from February 6th to 9th, 2007.

 

For more info and to register, please = visit:

http://www.upperside.fr/mpls2007/mplsworld2007registration.h= tm

 

We hope to see you there in = February!

 

------=_NextPart_000_0208_01C73D7A.45A64EE0-- --===============0482613385== 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 --===============0482613385==-- From melioshowm@mailavie.com Tue Jan 23 02:30:01 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9G6T-00009B-2S for mpls-archive@lists.ietf.org; Tue, 23 Jan 2007 02:30:01 -0500 Received: from [222.98.225.10] (helo=mailavie.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9G6R-0005yd-Ew for mpls-archive@lists.ietf.org; Tue, 23 Jan 2007 02:30:01 -0500 Message-ID: <01c73ec0$49af32d0$660aa8c0@LocalHost> Reply-To: "Aviv Vanegas" From: "Aviv Vanegas" To: "Saira Cartier" Subject: Re: now chok Date: Tue, 23 Jan 2007 16:29:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi, VIxAGxRA $3. 35 CIxALxIS $3. 75 VAxLIxUM $1. 30 AMxBIxEN $2. 90 SOxMA $1. 15 and many other http://www.rx555*com ( Do not forget to replace "*" with "." ) -- seem to have taken in a word Snape had said. He stared, apparently repelled by the ugly mark on Snapes arm, then looked up at Dumbledore and whispered, I dont know what you and your staff are playing at, From mpls-bounces@lists.ietf.org Tue Jan 23 15:52:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Sap-0006LU-TT; Tue, 23 Jan 2007 15:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Sah-0006IU-Tf for mpls@lists.ietf.org; Tue, 23 Jan 2007 15:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Sah-00064L-22 for mpls@lists.ietf.org; Tue, 23 Jan 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id DA4EE26F17; Tue, 23 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9Sag-000450-IS; Tue, 23 Jan 2007 15:50:02 -0500 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, 23 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-ldp-typed-wildcard-00.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: , 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 Typed Wildcard FEC Author(s) : B. Thomas, I. Minei Filename : draft-ietf-mpls-ldp-typed-wildcard-00.txt Pages : 8 Date : 2007-1-23 The LDP specification [RFC3036] for the Wildcard FEC element has several deficiencies. This document corrects those deficiencies. In addition, it specifies the Typed Wildcard FEC for the Prefix FEC Element Type defined in RFC3036. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-typed-wildcard-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-typed-wildcard-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-typed-wildcard-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-23143347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-typed-wildcard-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-typed-wildcard-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-23143347.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 Jan 23 15:52:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9SbI-0006ZO-Oh; Tue, 23 Jan 2007 15:50:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9SbC-0006SW-PH for mpls@lists.ietf.org; Tue, 23 Jan 2007 15:50:34 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9SbA-0003Zo-Dj for mpls@lists.ietf.org; Tue, 23 Jan 2007 15:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3F0EB2ACC6; Tue, 23 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9Saf-00043p-VA; Tue, 23 Jan 2007 15:50:01 -0500 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, 23 Jan 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-07.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: , 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 : Extensions to RSVP-TE for Point-to-Multipoint TE LSPs Author(s) : R. Aggarwal, et al. Filename : draft-ietf-mpls-rsvp-te-p2mp-07.txt Pages : 55 Date : 2007-1-23 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-07.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-rsvp-te-p2mp-07.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-rsvp-te-p2mp-07.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: <2007-1-23123256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-te-p2mp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-23123256.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 laviniaaleak@ebargaindaze.net Tue Jan 23 20:30:24 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Wy0-00033b-JN for mpls-archive@lists.ietf.org; Tue, 23 Jan 2007 20:30:24 -0500 Received: from pom51-2-82-241-128-51.fbx.proxad.net ([82.241.128.51] helo=ebargaindaze.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H9Wxx-0007zk-Lv for mpls-archive@lists.ietf.org; Tue, 23 Jan 2007 20:30:24 -0500 Message-ID: <01c73f57$36e54c10$3380f152@FAMILLE> Reply-To: "Jodene Liao" From: "Jodene Liao" To: "Nikolaj Schram" Subject: Re: EDtroty Date: Wed, 24 Jan 2007 02:30:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Good day, VlA_AGRA $1, 80 ClA_ALIS $3, 00 LEV_VlTRA $3, 35 http://www.printeryml*com ( Important ! Replace "*" with "." ) -- into the wood, following the lantern-lit trail. They could hear the sounds of thousands of people moving around them, shouts and laughter, snatches of singing. The atmosphere of feverish excitement was highly From mpls-bounces@lists.ietf.org Wed Jan 24 10:55:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kRH-0000Jt-6z; Wed, 24 Jan 2007 10:53:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kRF-0000Jn-7e for mpls@ietf.org; Wed, 24 Jan 2007 10:53:29 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kRE-0003ru-Gn for mpls@ietf.org; Wed, 24 Jan 2007 10:53:29 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Jan 2007 10:53:28 -0500 X-IronPort-AV: i="4.13,232,1167627600"; d="scan'208,217"; a="112384574:sNHT117379956" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0OFrSuI010796 for ; Wed, 24 Jan 2007 10:53:28 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0OFrAOm011332 for ; Wed, 24 Jan 2007 10:53:28 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 10:53:17 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 10:53:16 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: mpls@ietf.org Message-Id: References: <323E68CB-B82E-48AC-B0CD-71DE2559EF7E@cisco.com> From: JP Vasseur Subject: Fwd: [mpls] Fwd: I-D ACTION:draft-vasseur-mpls-3209-patherr-00.txt Date: Tue, 23 Jan 2007 22:47:24 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 24 Jan 2007 15:53:16.0119 (UTC) FILETIME=[C2BB6670:01C73FCF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=26309; t=1169654008; x=1170518008; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[mpls]=20Fwd=3A=20I-D=20ACTION=3Adraft-vasseur-mpls- 3209-patherr-00.txt=20 |Sender:=20 |To:=20mpls@ietf.org; bh=sC4sDaVznwhOkddKpeQf2FtHh02YRvv82D1huk2njHQ=; b=VBvNNtHkeHKK93n1dns3ETi4m3cNhtjy2TCQ/tgVOZlGzxOgv1Ak3qCCLuU8kXAgrOn01FU/ uCg0iyzYDPi5AQ/8H0gRckAF3aET2XGUxUdgkbC1qebo96NH1IVTpCIJ; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.4 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 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="===============0496260855==" Errors-To: mpls-bounces@lists.ietf.org --===============0496260855== Content-Type: multipart/alternative; boundary=Apple-Mail-18-187999629 --Apple-Mail-18-187999629 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, We had comments from one vendor so far (to be addressed in the next revision). No other comment ? Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: November 14, 2006 9:06:51 AM EST > To: mpls@ietf.org > Subject: [mpls] Fwd: I-D ACTION:draft-vasseur-mpls-3209-patherr-00.txt > > Hi, > > As discussed last week, there's a need to document this behavior, > implementor's feed-back is more than welcome on this ID. > > Thanks. > > JP. > > Begin forwarded message: > >> From: JP Vasseur >> Date: September 13, 2006 6:01:12 PM EDT >> To: mpls@ietf.org >> Cc: Adrian Farrel , George Swallow >> , Loa Andersson >> Subject: Fwd: I-D ACTION:draft-vasseur-mpls-3209-patherr-00.txt >> >> Dear WG members, >> >> Some of you might recall the in-depth discussion that we had some >> time ago wrt to Soft Preemption. I think that we got a pretty >> clear consensus on the proposed solution. There was still a >> remaining issue related to the definition of "Hard Preemption" >> used in the ID. More precisely, some of you required >> clarifications on RFC3209 with regards to the behavior of a node >> upon the reception of a Path Error. Thus we have produced this ID, >> the aim of which is simply to clarify this aspect, thus hopping to >> be able to move forward on the Soft Preemption ID (of course, we >> will produce a new revision of the Soft Preemption ID referring to >> this new ID, once we'll get a consensus). >> >> Thanks. >> >> JP, Adrian and George. >> >> Begin forwarded message: >> >>> From: Internet-Drafts@ietf.org >>> Date: September 10, 2006 3:50:01 PM EDT >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-vasseur-mpls-3209-patherr-00.txt >>> Reply-To: internet-drafts@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Node behavior upon originating and receiving >>> Resource ReserVation Protocol (RSVP) >>> Path Error message >>> Author(s) : J. Vasseur, et al. >>> Filename : draft-vasseur-mpls-3209-patherr-00.txt >>> Pages : 8 >>> Date : 2006-9-10 >>> >>> The aim of this document is to describe a common practice with >>> regard >>> to the behavior of a node sending a Resource ReserVation Protocol >>> (RSVP) Path Error message and to the behavior of a node receiving an >>> RSVP Path Error message for a particular Multi-Protocol Label >>> Switching - Traffic Engineering (MPLS-TE) Label Switched Path (LSP). >>> This text does not define any new protocol extensions. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-vasseur-mpls-3209- >>> patherr-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the >>> body of >>> the message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >>> announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then >>> "get draft-vasseur-mpls-3209-patherr-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-vasseur-mpls-3209-patherr-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail >>> readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> Content-Type: text/plain >>> Content-ID: <2006-9-10103507.I-D@ietf.org> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/i-d-announce >> > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls --Apple-Mail-18-187999629 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

We had comments from one = vendor so far (to be addressed in the next revision). No other comment = ?

Thanks.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = November 14, 2006 9:06:51 AM EST
Subject: = [mpls] Fwd: I-D = ACTION:draft-vasseur-mpls-3209-patherr-00.txt=A0

Hi,

As discussed last week, = there's a need to document this behavior, implementor's feed-back is = more than welcome on this ID.

Thanks.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = September 13, 2006 6:01:12 PM EDT
Cc: Adrian = Farrel <adrian@olddog.co.uk>, George = Swallow <swallow@cisco.com>, Loa = Andersson <loa@pi.se>
Subject: = Fwd: I-D = ACTION:draft-vasseur-mpls-3209-patherr-00.txt=A0

Dear WG = members,

Some of = you might recall the in-depth discussion that we had some time ago wrt = to Soft Preemption. I think that we got a pretty clear consensus on the = proposed solution. There was still a remaining issue related to the = definition of "Hard Preemption" used in the ID. More precisely, some of = you required clarifications on RFC3209 with regards to the behavior of a = node upon the reception of a Path Error. Thus we have produced this ID, = the aim of which is simply to clarify this aspect, thus hopping to be = able to move forward on the Soft Preemption ID (of course, we will = produce a new revision of the Soft Preemption ID referring to this new = ID, once we'll get a consensus).

Thanks.

JP, Adrian and = George.

Begin forwarded message:

Date: September 10, 2006 3:50:01 PM = EDT
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-vasseur-mpls-3209-patherr-00.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts=A0
directories.


Title : Node behavior upon originating = and receiving=A0
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Resource ReserVation Protocol = (RSVP) Path Error message
= Author(s) = : J. Vasseur, et al.
= Filename = : draft-vasseur-mpls-3209-patherr-00.txt
Pages : 8
Date : = 2006-9-10

The aim of = this document is to describe a common practice with regard
to the behavior of a node sending a Resource = ReserVation Protocol
(RSVP) Path Error message = and to the behavior of a node receiving an
RSVP = Path Error message for a particular Multi-Protocol Label
Switching - Traffic Engineering (MPLS-TE) Label = Switched Path (LSP).
This text does not define = any new protocol extensions.


A URL for this Internet-Draft is:

To remove yourself from the I-D Announcement list, = send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-vasseur-mpls-3209-patherr-00.txt".

A list of = Internet-Drafts directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-vasseur-mpls-3209-patherr-00.txt".

NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 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
Content-Type: = text/plain

=


mpls mailing list
=

= --Apple-Mail-18-187999629-- --===============0496260855== 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 --===============0496260855==-- From mpls-bounces@lists.ietf.org Wed Jan 24 11:06:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kdV-0007C8-Aq; Wed, 24 Jan 2007 11:06:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kdU-00079R-2p for mpls@ietf.org; Wed, 24 Jan 2007 11:06:08 -0500 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kdR-00072w-P4 for mpls@ietf.org; Wed, 24 Jan 2007 11:06:08 -0500 Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.225]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1H9kdJ-0002uW-Hf; Wed, 24 Jan 2007 17:05:58 +0100 Message-ID: <45B783E3.60404@pi.se> Date: Wed, 24 Jan 2007 17:05:55 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mpls@ietf.org, Yakov Rekhter , Rahul Aggarwal X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [mpls] RFC4781 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: , Errors-To: mpls-bounces@lists.ietf.org Working Group, we have a new RFC "Graceful Restart Mechanism for BGP with MPLS" just published as RFC4781. It is almost to the day (diff is 3 days) 57 months since we asked the IESG to publish it. This also means that our longevity index in the RFC Editor Queue gone down drastically :) . Congrat's to Yakov and Rahul as authors! 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 vhzobgnaex@mpowercom.net Wed Jan 24 12:53:47 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9mJf-0008Sk-1L for mpls-archive@lists.ietf.org; Wed, 24 Jan 2007 12:53:47 -0500 Received: from san-static-208.57.86.137.mpowercom.net ([208.57.86.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9mJd-0007EH-7x for mpls-archive@lists.ietf.org; Wed, 24 Jan 2007 12:53:47 -0500 From: "IP:" To: mpls-archive@lists.ietf.org Subject: Classy drugs at very low prices! Date: Wed, 24 Jan 2007 09:53:54 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C73F9D.8F1398B0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc/nY8TSxiIdeeMRpqi4Ue+6fGRkA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.4 (+++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 ------=_NextPart_000_0002_01C73F9D.8F1398B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0003_01C73F9D.8F1398B0" ------=_NextPart_001_0003_01C73F9D.8F1398B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit resulting displays thats site regarding type. Showcase Ads concise listings include photos Compare Equipment Routers ------=_NextPart_001_0003_01C73F9D.8F1398B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

resulting displays thats = site regarding type. Showcase Ads concise listings include = photos

Compare Equipment = Routers

------=_NextPart_001_0003_01C73F9D.8F1398B0-- ------=_NextPart_000_0002_01C73F9D.8F1398B0 Content-Type: image/gif; name="pic01.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdh5wAOAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA5wAOAQcI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBD2gpJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJsydN AAYBCAX6j2jRgUCHCkW6tKhSgk8FRj0qtanToUyNZjU6dSpUrFWtcgVLlSvUswe7IkUb1ixb qlnXSp2bUCvco27xBpV7l25ZuUTd2oVrtzDavH7/0g18uKrfpHwLCuYL+bHjy3otE0689y1j yIwlp+2sWPHg03VFA458N7Tp0U4tI2br2mzewGPXzp67+21r3pmVjtV6mqzavlfFWt2aGPfy 5m1XX10cXHpQ41EFG9dbm3Pkwb6J/gOvDJ4yaeuuWatmLb70d+rw/2kIjbttet+bk9PXHTw7 wvb/rZffgOZ5h1p+k61nmGfxvVdaevvFhmCACmrW3WvxAchQV2QNKFxc6h34IAA+bDXcedFp 9pVY6G23mWFeIWebaAl+plqHv/mk44489ujjj0AGKeSQRBZpJEflHKnkkkw2KZE1TkYp5UYx UoQjgBoeBx1n2nWY5VO3PUccdlcKqCFyM5U30W2Edcfmi0xxad1Zu73Jpp115QacnDiN6Vxc z6FZmYQzWsjfZQu6d6iMBYI3aIJp6ZlZX2rCBGajDTJKHXnoZTieZNn5l2mbYIno3HBicmco fmnSJt19/8WViqiopoma6qgfajohqLISSGN/varXaoEYJnphfbtiWGuFut7n4arKqhkhpN4N 2xyLik5HKZx0bgcje4Bd2i22Hjb17WIx7gdjqThO6e678PooXKDx1mvvvfjmq+++/Pbr778A ByzwwAQXbPDBCCes8MIMN0xSDw5HLHFD1Exs8cU8xoDxxhx37PHHIIcs8shCJknyySXxo/JA /CDU8j8vu7xyQi3HLJDKOAtUMUE2Z1RpRvkEPVDQQg9NdD4CEW0Q0v8wzfSOMfdskNRTs+zy zQdRbTVHP1+E9NdJK+T00AWN3XSPUkc988tsz4z11G3jnHZBOcPsdt2R/knZtP68hnWQ0kkD vnTYhJN99uFQE/QFzHS/XbPMUTv+duNVM8641ns5uqmqmTOk9NNPGx546ISbnTjldrPtOOaq W9466jevvbpC7N746aB+S4gQ2ASR3vQ8hZNutu88Re665JZPnnzrzGfNM/I2aw1hY6riPv3g YINedu+iH4l33M3jzbLbdm9NvvJyxx53nkuVidlsYNI7utHaIz7/9ocTjzJP+uMr9/8ADKAA B0jAAhrwf/vDyCkMFo0EOvCBEIygBCdIwQpa8IJbsxrmIpI+hmwQdhD54EK65rWiGa1sRTua 8EoXE+NtxIVXM4kIaUeS7JEtdPUrnOFM5xLjqe2Hsf5TH+raFsTUFdGIOVPb+KInO/bl7jF8 W9ETe2fC/HFPh74bXgvNR7nmPY9n34Oe5GDoxdchj4ZagdJrQCMoNKGQd/bLIfG0uEUX1s2L RvziF8t4RyIe749ATF7eMAMfNuJOW/IL29dUKLocXpGHPVyeGAGpPEFO0owZfBwlN4m56xWy etSrlg2vGDwd+iR66gsk+EC4PDuuLIlNLB/07si+pNxKd/DDSrvoN7j8mVB/dNQRJou0CJr0 r0gHTKYyl8nMZs7QRyHAoDSnSc2TlKGa2MymNrfJzW7SrHHPbIj4qtYzBDqPayURXOD+1ktI njKDGoHhHs8ZQyrV8Gzay/9iFlmINi4K8Z9rOx/VAtpBPQL0bueTorag+EmF7lKdkITjDk35 zjNekpVh3CQrKfnMQ37SkKPp2ue6R1Ir2i9xrizjEr/JSXoCdHZO1N1cdmEjNjq0UtljJP4e SdF3+vCif8wkUGGnUniGMkc1nZR7wDPKkp5USahMnSpTCTcmmm9uS1xfHvNmS2O9iTm7vB9P SxpMmqjghZVs2DHd5cy2uvWt3oyrXOdK17ra9a54zateJ5LRyoVzhB8hU2HMVSWTZAFe8qyc PTtiU81tqWC9uAhW88i8hILIS3FSVu7IxJwVJUpkkxVjR9v4F5B2bpCI+erIJktL122wdtQD 6WD+kUUnMxFrtf4salob1J6kWu+xps1RtkB7N6oeb5yeXShDVRSdKymnS8LaK0pIKMG3BlC6 2M2udrfL3e42qRveDa94U7bRYQY2sM+9zon+oQqMJXa3IaEuRIKLJV9NLKVABeAICYulKF42 vecplBsdJs+i6jY1jvVtG8uD2b7Z976CbK2B4bvZBSl4toTcU7NStDFNtvTDnXzsGjnHW/44 i1sDjhgTmzjVoKq3qwpSbXKUi0hbAXi8HpHvxoqRNeseEMdADrKQGXLYIRv5yEhOMnctKxHW gbMlOn4IZ3kVZSOZlyPvTUmVN0Tiz9pLawi1ahCVqMfXfS+g//wPf2n+498Kr9dMYZ2SVicM 4jJX8sCWDClsLqznQWa4N3Leo4SNi8cnT27QrXwtYW0HSgzLVMPVSnGUzNzFO09Sg7nNb2qE O2Kblvh2DpL0pMvJ4pUG1bJRLaiEkQvWW5JrtjBW6EL1Js0r62TL8fKxrnWt5JbUodfADraw h03sYhu7Ilk+Ca73+2YQzRhkHoZyjrvsKlFfjNRaFWKy2dXfhv632aHu6rIRNlCLHpfLCQa1 5hi8nFgxt2PRRvRWPwjbV4HypqfdMKuunek6h5jT6iLxUk1cLQGPe2DllOosX2nUVnv1tjN2 7qnoc+Nj03Cau74ud+Fh8Y57/OMgD7nIRy7/E1YrG71ennUi3dvwkzN2Uq5+cId7nFXymdzN bPY2zqfo0UUd3GAZxbMIex5wT9fWzwUHN2g1nWY/34rP+P5VdGG+dKYXmtFbgvqnBW4smXfY 5j91LZMj7moZx8/Rjao4yX8O7YzfnORwj7vc5073C7qj7h+/A1/FudHFMlbtKmc7v6JdT5ej 09P1BTTDPKzfNJN5q2qmdZt0XmOlC/dR/LY609G4Z3X3Wb34CZbgHeILhaTDR+ak8ypdDPpH F12pNc63qTicE04Ur9909mfnHaT1gX+KtFSH8PP4iF/WJ9d9uGSPLsXEX3M9Mc4fHz2B3V5A vFv/+tjPvk4iq32X/ujiSPLovgOTnZGxL+TK5JeJ9J09K3frByTpt4itFcKPZeT50DxZP7Ux f1v9CxWQ5nRQoTU+RVRZr5RQrkSAjXdE4mN+lZdzmvWAPMcnARYSqTdUl7Y6KvU4HGhuF1hn IDh0pJVUxbRukVcukbJv8YR7ZyRv6CNalxODrBd2qndJb1dvHyVwsfcr87Jvild+LBiCfpVp HahJmESDmqdRm5Ylm2N0nmR0wQct8JdJpSZ2V3dErfR/DGdJCThUxZVotURjkpJL7cN8B+Ii LiJy/tcR1NeGbkh94heHcjiHdFiHdnhkCUd/leZ3XAN4U3Ztj+cQfyVl04Z4rvKDCoNQ/wQ4 ZqYWSCeoXHoSId/GftGVcgQWgzU4g+i2e7L1eQ72aH82cx2ocCAIea33dJ4XdUdXiVPXMEVo aUJIIUxYWlwHXNSGKRyDR/K2amN3djEGcb4oa2jYfGsoXsWYMG+ocSizC3fYjM74jNAYjdIo JX81fxXhf8hnIMRoMYNIYRahf4g3JswSaQuTNpRWMwfYdKfYbpkliTs3HY+gYYeUWplHhBl4 f1LHaJ2Yb5+4LdUmaiZTMNimOrp1g4sWW/f2X/yYcloifEZlhBiIdUiVilvnhAKSLBXBA4PX QX1FRKvHVWKYWb4SjJTYdbO2drWWjN04jVHCASz5kjCZL00AEeFpEJMQEQE2KTDqIGdnFmZg 1EcISIWxlGV9dWhf+IIaSFA/FEv/kmr9lmcFVmgQaV5hp3uUZmdQqXstty9O2YJpFZUWRZAy qFjwRArDdJZaiX9ZGTCp1pGp9JGYZkZiSXgNl4dzM1AcmZdhxpT+0pV29JWAKUtOOYpkCYvm uJbGd5UGJRAjgRK/ZhNdqVGs1UVyiTWEOUSGaZWYiZjW2JRuCXkfyIVCGVWSRDd7yXhHGWFX 1VpW2JnbtJLVpJKyOZtul5O2eZu4mZu6uZu82Zu++ZvAGZzCOZw8IQ7EeZwJERAAOw== ------=_NextPart_000_0002_01C73F9D.8F1398B0-- From buckodenise@ebiconsultants.com Thu Jan 25 05:11:40 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA1Zz-0002vP-F7 for mpls-archive@lists.ietf.org; Thu, 25 Jan 2007 05:11:39 -0500 Received: from s01060008a11d4a73.cg.shawcable.net ([70.73.245.71] helo=ebiconsultants.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HA1Zy-0003Wj-1b for mpls-archive@lists.ietf.org; Thu, 25 Jan 2007 05:11:39 -0500 Message-ID: <01c74069$35cbc940$47f54946@dellhartley> Reply-To: "Jade Noel" From: "Jade Noel" To: "Ceridwen Stanford" Subject: Re: zoRXsaj Date: Thu, 25 Jan 2007 03:11:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.5 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi, Vi_aagra $3, 35 Ci_ialis $3, 75 Va_llium $1, 30 Am_bbien $2, 90 So_mma $1, 15 http://www.33rx*com ( Important! Replace * with "." ) -- BAGMAN AND CROUCH Harry disentangled himself from Ron and got to his feet. They had arrived on what appeared to be a deserted stretch of misty moor. In From mpls-bounces@lists.ietf.org Thu Jan 25 10:46:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6kd-0006Pq-DV; Thu, 25 Jan 2007 10:42:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6kb-0006Pb-C4; Thu, 25 Jan 2007 10:42:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA6kV-00083F-1v; Thu, 25 Jan 2007 10:42:57 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2007 16:42:51 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0PFgo9H000878; Thu, 25 Jan 2007 16:42:50 +0100 Received: from [64.103.65.172] (dhcp-gpk02-vlan300-64-103-65-172.cisco.com [64.103.65.172]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0PFgoC8029063; Thu, 25 Jan 2007 16:42:50 +0100 (MET) Message-ID: <45B8CFF8.9090800@cisco.com> Date: Thu, 25 Jan 2007 15:42:48 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2023; t=1169739770; x=1170603770; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Y.1720=20liased=20text |Sender:=20; bh=LpUbxPuuuLqeGCNsmC+xJSMhsmTJvaR6WNljA4iKNB4=; b=odI1FyZueofTxCdoRqXJizQPYGqh5rLaG5ENEkQnUjXAtlvRS43IVnDAoJs9/iXnOKDd4pog g8zJmzt0U0V5v2O4AaE4tE3ZXAveQCavMxpO07mUj9+11LvLSGO1w5eu; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mpls@ietf.org Subject: [mpls] Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Please could some else from the PWE3 WG take a look at the following liaison statement. https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=289 I think that we need to respond with the following, but I would like someone else to check my interpretation of their text and the IETF MPLS design. An appropriate response would seem to be: The PWE3 WG is concerned about the consented text for Y.1720 that has been liaised to us. In particular the following text in Y.1720 looks like a violation of the IETF MPLS architecture. Appendix II Packet 1+1 example realization The packet 1+1 scheme can be implemented by using a sequence as an identifier. The sequence number can be carried as the first four bytes inside the shim header of the LSP providing packet 1+1. Since the ingress and egress nodes must be aware of each LSP participating in the packet 1+1, the egress node will recognize that there is a sequence number inside the label. It will use the sequence number for selection purpose and then remove it before forwarding the accepted packet further. Note that packet 1+1 can be provided at any level of the hierarchy of a nested LSP. Figure II.1 illustrates the sequence number position behind the 4-bytes MPLS encapsulation header. This implies that the Y.1720 is proposing to place an item in the label stack that does not conform to the design of an RFC3032 label stack entry. This breaks the MPLS invariant that any item that follows an LSE with the S bit set to zero MUST be another LSE. It also breaks the guideline that any item that follows a MPLS LSE should either be an IP packet or should conform to the design described in RFC4385. It is our view that all MPLS packet designs must adhere to the design invariants and guidelines produced by the IETF and the text in Appendix II, and any technical design that conflicts with the IETF design needs amendment before Y.1720 is published in its final form. Regards Stewart _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jan 25 11:48:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7j0-00041W-RY; Thu, 25 Jan 2007 11:45:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7iy-000407-Lg; Thu, 25 Jan 2007 11:45:20 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7iu-0004cw-Tv; Thu, 25 Jan 2007 11:45:20 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 16:45:16 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Jan 2007 16:45:14 +0000 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 Date: Thu, 25 Jan 2007 16:45:14 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AEF736A@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Y.1720 liased text Thread-Index: AcdAl7upam0dQ5/jQ1WFKzsuykEJMwAAQz0w From: To: , X-OriginalArrivalTime: 25 Jan 2007 16:45:14.0780 (UTC) FILETIME=[30030DC0:01C740A0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mpls@ietf.org Subject: [mpls] RE: [PWE3] Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Stewart, Well, there are certainly some issues when the semantic of a specific field in a traffic unit is NOT consistent in any layer network. For example, the MPLS label field can currently take on at least 3 different semantics, viz: - a proxy for destination identifier (ie the usual label-swapping/forwarding paradigm) - a proxy for a source identifier (ie a necessary consequence of (lower level) LSP merging) - a 'functional action', eg various labels in the reserved code-space 0-15. This is not good practice IMO....and one observation here would be that under misconnectivity incorrect downstream decisions could arise (noting that this may not simply be between LSPs at the same level but also across LSPs at different levels). Though to be strictly accurate, since the 'functional action' labels (0-15) are partitioned from the rest of the label space the consequence has some certainty of (incorrect) action. I am not familiar with the content of Y.1720, but from what you describe below it seems we can add yet another semantic to the label field.....or at least *its interpretation as a label field*, under misconnectivity, by some LSR that unexpectedly receives it (but also see Note below). Does not sound very good to me. Note - If S=3D1 in the preceding MPLS header then there seems less of a problem than if S=3D0.....which may appear an odd observation to make, = but I do so because of this specific text Stewart extracted from Y.1720 Appendix II (note the highlighted word 'any'): "Note that packet 1+1 can be provided at *any* level of the hierarchy of a nested LSP." regards, Neil > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com]=20 > Sent: 25 January 2007 15:43 > To: pwe3 > Cc: mpls@ietf.org > Subject: [PWE3] Y.1720 liased text >=20 >=20 > Please could some else from the PWE3 WG take a look at > the following liaison statement. >=20 > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D289 >=20 > I think that we need to respond with the following, but > I would like someone else to check my interpretation of > their text and the IETF MPLS design. >=20 > An appropriate response would seem to be: >=20 >=20 > The PWE3 WG is concerned about the consented text for Y.1720=20 > that has been liaised to us. >=20 > In particular the following text in Y.1720 looks like a=20 > violation of the IETF MPLS architecture. >=20 > Appendix II >=20 > Packet 1+1 example realization > The packet 1+1 scheme can be implemented by using a sequence as an=20 > identifier. The sequence number can be carried as the first=20 > four bytes=20 > inside the shim header of the LSP providing packet 1+1. Since the=20 > ingress and egress nodes must be aware of each LSP=20 > participating in the=20 > packet 1+1, the egress node will recognize that there is a sequence=20 > number inside the label. It will use the sequence number for=20 > selection=20 > purpose and then remove it before forwarding the accepted packet=20 > further. Note that packet 1+1 can be provided at any level of the=20 > hierarchy of a nested LSP. Figure II.1 illustrates the=20 > sequence number=20 > position behind the 4-bytes MPLS encapsulation header. >=20 >=20 > This implies that the Y.1720 is proposing to place an item in=20 > the label stack that does not conform to the design of an=20 > RFC3032 label stack entry. >=20 > This breaks the MPLS invariant that any item that follows > an LSE with the S bit set to zero MUST be another LSE. >=20 > It also breaks the guideline that any item that follows > a MPLS LSE should either be an IP packet or should conform > to the design described in RFC4385. >=20 > It is our view that all MPLS packet designs must adhere to > the design invariants and guidelines produced by the IETF > and the text in Appendix II, and any technical design that=20 > conflicts with the IETF design needs amendment before Y.1720=20 > is published in its final form. >=20 > Regards >=20 > Stewart >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jan 25 13:31:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9Kr-0002st-8m; Thu, 25 Jan 2007 13:28:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9Kp-0002sG-PZ; Thu, 25 Jan 2007 13:28:31 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA9Kl-0007dg-5a; Thu, 25 Jan 2007 13:28:31 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l0PIRkwa005071; Thu, 25 Jan 2007 12:28:14 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.5]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 12:27:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jan 2007 12:27:59 -0600 Message-ID: <858DDD4F5B8D924C955EB55302E4D1A89B88C7@ILEXC1U02.ndc.lucent.com> In-Reply-To: <45B8CFF8.9090800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Y.1720 liased text Thread-Index: AcdAl69IWvoz3o4xROaHgE5riVGhGAAFUCpg References: <45B8CFF8.9090800@cisco.com> From: "Trowbridge, Stephen J \(Steve\)" To: "Stewart Bryant" , "pwe3" X-OriginalArrivalTime: 25 Jan 2007 18:27:58.0345 (UTC) FILETIME=[89C86F90:01C740AE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mpls@ietf.org, "Ghani Abbas \(BE/ETL\)" Subject: [mpls] RE: [PWE3] Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Stewart, I am not really close enough to Y.1720 to respond regarding the technical content, but what was just approved is not a new Recommendation. It is a minor maintenance update to a Recommendation originally developed in ITU-T Study Group 13 that has been in force since April 2003. All protection switching work was collected together in ITU-T Study Group 15 with the reorganization of work at the end of 2004, so it fell to us (WP3/15 chair hat on) to do the maintenance update. If anyone on this list is more familiar with original Y.1720 than me, I think it would be helpful to know whether you think that we broke something in the process of doing the maintenance update, or if these are new concerns being raised in 2007 about a document that has been approved and in force since 2003? Regards, Steve -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Thursday, January 25, 2007 8:43 AM To: pwe3 Cc: mpls@ietf.org Subject: [PWE3] Y.1720 liased text Please could some else from the PWE3 WG take a look at the following liaison statement. https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D289 I think that we need to respond with the following, but I would like someone else to check my interpretation of their text and the IETF MPLS design. An appropriate response would seem to be: The PWE3 WG is concerned about the consented text for Y.1720 that has been liaised to us. In particular the following text in Y.1720 looks like a violation of the IETF MPLS architecture. Appendix II Packet 1+1 example realization The packet 1+1 scheme can be implemented by using a sequence as an identifier. The sequence number can be carried as the first four bytes inside the shim header of the LSP providing packet 1+1. Since the ingress and egress nodes must be aware of each LSP participating in the packet 1+1, the egress node will recognize that there is a sequence number inside the label. It will use the sequence number for selection purpose and then remove it before forwarding the accepted packet further. Note that packet 1+1 can be provided at any level of the hierarchy of a nested LSP. Figure II.1 illustrates the sequence number position behind the 4-bytes MPLS encapsulation header. This implies that the Y.1720 is proposing to place an item in the label stack that does not conform to the design of an RFC3032 label stack entry. This breaks the MPLS invariant that any item that follows an LSE with the S bit set to zero MUST be another LSE. It also breaks the guideline that any item that follows a MPLS LSE should either be an IP packet or should conform to the design described in RFC4385. It is our view that all MPLS packet designs must adhere to the design invariants and guidelines produced by the IETF and the text in Appendix II, and any technical design that conflicts with the IETF design needs amendment before Y.1720 is published in its final form. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jan 25 16:52:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HACTj-00070F-IF; Thu, 25 Jan 2007 16:49:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HACTg-0006xp-JX; Thu, 25 Jan 2007 16:49:52 -0500 Received: from amsfep20-int.chello.nl ([62.179.120.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HACTe-0007hu-3w; Thu, 25 Jan 2007 16:49:52 -0500 Received: from [192.168.17.5] (really [62.195.168.62]) by amsfep20-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070125214946.VSDM14586.amsfep20-int.chello.nl@[192.168.17.5]>; Thu, 25 Jan 2007 22:49:46 +0100 Message-ID: <45B925F8.90707@chello.nl> Date: Thu, 25 Jan 2007 22:49:44 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Trowbridge, Stephen J \(Steve\)" References: <45B8CFF8.9090800@cisco.com> <858DDD4F5B8D924C955EB55302E4D1A89B88C7@ILEXC1U02.ndc.lucent.com> In-Reply-To: <858DDD4F5B8D924C955EB55302E4D1A89B88C7@ILEXC1U02.ndc.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: mpls@ietf.org, "Ghani Abbas \(BE/ETL\)" , pwe3 , Stewart Bryant Subject: [mpls] Re: [PWE3] Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Hello Steve, You wrote: > Hi Stewart, > I am not really close enough to Y.1720 to respond regarding the > technical content, but what was just approved is not a new > Recommendation. It is a minor maintenance update to a Recommendation > originally developed in ITU-T Study Group 13 that has been in force > since April 2003. All protection switching work was collected together > in ITU-T Study Group 15 with the reorganization of work at the end of > 2004, so it fell to us (WP3/15 chair hat on) to do the maintenance > update. > > If anyone on this list is more familiar with original Y.1720 than me, I > think it would be helpful to know whether you think that we broke > something in the process of doing the maintenance update, or if these > are new concerns being raised in 2007 about a document that has been > approved and in force since 2003? It was indeed a maintenance update. The previous version was consented in the 07/2003 plenary and approved in 09/2003. The Appendix mentioned was not altered after that revision, so this text is there for three years. Regards, Huub (editor of Y.1720). > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, January 25, 2007 8:43 AM > To: pwe3 > Cc: mpls@ietf.org > Subject: [PWE3] Y.1720 liased text > > Please could some else from the PWE3 WG take a look at the following > liaison statement. > > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=289 > > I think that we need to respond with the following, but I would like > someone else to check my interpretation of their text and the IETF MPLS > design. > > An appropriate response would seem to be: > > > The PWE3 WG is concerned about the consented text for Y.1720 that has > been liaised to us. > > In particular the following text in Y.1720 looks like a violation of the > IETF MPLS architecture. > > Appendix II > > Packet 1+1 example realization > The packet 1+1 scheme can be implemented by using a sequence as an > identifier. The sequence number can be carried as the first four bytes > inside the shim header of the LSP providing packet 1+1. Since the > ingress and egress nodes must be aware of each LSP participating in the > packet 1+1, the egress node will recognize that there is a sequence > number inside the label. It will use the sequence number for selection > purpose and then remove it before forwarding the accepted packet > further. Note that packet 1+1 can be provided at any level of the > hierarchy of a nested LSP. Figure II.1 illustrates the sequence number > position behind the 4-bytes MPLS encapsulation header. > > > This implies that the Y.1720 is proposing to place an item in the label > stack that does not conform to the design of an RFC3032 label stack > entry. > > This breaks the MPLS invariant that any item that follows an LSE with > the S bit set to zero MUST be another LSE. > > It also breaks the guideline that any item that follows a MPLS LSE > should either be an IP packet or should conform to the design described > in RFC4385. > > It is our view that all MPLS packet designs must adhere to the design > invariants and guidelines produced by the IETF and the text in Appendix > II, and any technical design that conflicts with the IETF design needs > amendment before Y.1720 is published in its final form. > > Regards > > Stewart -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 02:46:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HALk2-0002iV-4r; Fri, 26 Jan 2007 02:43:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HALk0-0002iF-62; Fri, 26 Jan 2007 02:43:20 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HALju-0007Va-HN; Fri, 26 Jan 2007 02:43:20 -0500 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 07:43:07 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Jan 2007 07:43:06 +0000 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 Date: Fri, 26 Jan 2007 07:43:06 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Y.1720 liased text Thread-Index: AcdAyvfqh5wffLkuRQmC9hNv5lSAfgAUPIvA From: To: , X-OriginalArrivalTime: 26 Jan 2007 07:43:06.0985 (UTC) FILETIME=[9E592D90:01C7411D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: mpls@ietf.org, stbryant@cisco.com, pwe3@ietf.org, ghani.abbas@ericsson.com Subject: [mpls] RE: [PWE3] Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Thanks Huub,=20 Can you clarify how the S bit is set when this 1+1 seq no. field is used? What is puzzling me is this sentence in the text Stewart extracted from Y.1720/Appendix 11: "Note that packet 1+1 can be provided at any level of the hierarchy of a nested LSP." I sort-of read this as there can be a set of nested LSPs (hence concatenated MPLS headers) and that the protection mechanism can be applied to any one of these within such a stack. Am I reading this right? If I am, then please see my concerns of yesterday on this thread....which, in essence, is querying what happens if there is misconnectivity and the LSP carrying the 1+1 Seq No. stuff arrives at some arbitrary LSR.....how will that LSR parse/interpret the fields it sees? I have no background on Y.1720, so my apologies if I am asking a dumb question. regards, Neil > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 > Sent: 25 January 2007 21:50 > To: Trowbridge, Stephen J (Steve) > Cc: mpls@ietf.org; Ghani Abbas (BE/ETL); pwe3; Stewart Bryant > Subject: Re: [PWE3] Y.1720 liased text >=20 >=20 > Hello Steve, >=20 > You wrote: >=20 > > Hi Stewart, > > I am not really close enough to Y.1720 to respond regarding the=20 > > technical content, but what was just approved is not a new=20 > > Recommendation. It is a minor maintenance update to a=20 > Recommendation=20 > > originally developed in ITU-T Study Group 13 that has been in force=20 > > since April 2003. All protection switching work was=20 > collected together=20 > > in ITU-T Study Group 15 with the reorganization of work at=20 > the end of=20 > > 2004, so it fell to us (WP3/15 chair hat on) to do the maintenance=20 > > update. > >=20 > > If anyone on this list is more familiar with original=20 > Y.1720 than me,=20 > > I think it would be helpful to know whether you think that we broke=20 > > something in the process of doing the maintenance update,=20 > or if these=20 > > are new concerns being raised in 2007 about a document that=20 > has been=20 > > approved and in force since 2003? >=20 > It was indeed a maintenance update. The previous version was=20 > consented in the 07/2003 plenary and approved in 09/2003. >=20 > The Appendix mentioned was not altered after that revision, > so this text is there for three years. >=20 > Regards, Huub (editor of Y.1720). >=20 >=20 > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Thursday, January 25, 2007 8:43 AM > > To: pwe3 > > Cc: mpls@ietf.org > > Subject: [PWE3] Y.1720 liased text > >=20 > > Please could some else from the PWE3 WG take a look at the=20 > following=20 > > liaison statement. > >=20 > > = https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D289 > >=20 > > I think that we need to respond with the following, but I=20 > would like=20 > > someone else to check my interpretation of their text and the IETF=20 > > MPLS design. > >=20 > > An appropriate response would seem to be: > >=20 > >=20 > > The PWE3 WG is concerned about the consented text for=20 > Y.1720 that has=20 > > been liaised to us. > >=20 > > In particular the following text in Y.1720 looks like a=20 > violation of=20 > > the IETF MPLS architecture. > >=20 > > Appendix II > >=20 > > Packet 1+1 example realization > > The packet 1+1 scheme can be implemented by using a sequence as an=20 > > identifier. The sequence number can be carried as the first=20 > four bytes=20 > > inside the shim header of the LSP providing packet 1+1. Since the=20 > > ingress and egress nodes must be aware of each LSP participating in=20 > > the packet 1+1, the egress node will recognize that there is a=20 > > sequence number inside the label. It will use the sequence=20 > number for=20 > > selection purpose and then remove it before forwarding the accepted=20 > > packet further. Note that packet 1+1 can be provided at any=20 > level of=20 > > the hierarchy of a nested LSP. Figure II.1 illustrates the sequence=20 > > number position behind the 4-bytes MPLS encapsulation header. > >=20 > >=20 > > This implies that the Y.1720 is proposing to place an item in the=20 > > label stack that does not conform to the design of an RFC3032 label=20 > > stack entry. > >=20 > > This breaks the MPLS invariant that any item that follows=20 > an LSE with=20 > > the S bit set to zero MUST be another LSE. > >=20 > > It also breaks the guideline that any item that follows a MPLS LSE=20 > > should either be an IP packet or should conform to the design=20 > > described in RFC4385. > >=20 > > It is our view that all MPLS packet designs must adhere to=20 > the design=20 > > invariants and guidelines produced by the IETF and the text in=20 > > Appendix II, and any technical design that conflicts with the IETF=20 > > design needs amendment before Y.1720 is published in its final form. > >=20 > > Regards > >=20 > > Stewart >=20 > --=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > http://www.van-helvoort.eu/=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From akcycijsd@rdsnet.ro Fri Jan 26 03:52:02 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMoU-0007eq-PM for mpls-archive@lists.ietf.org; Fri, 26 Jan 2007 03:52:02 -0500 Received: from elda1-inet.galati.rdsnet.ro ([81.196.54.126]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAMoT-00049T-E5 for mpls-archive@lists.ietf.org; Fri, 26 Jan 2007 03:52:02 -0500 From: "effective methods." To: mpls-archive@lists.ietf.org Subject: Next Big market Winner! Date: Fri, 26 Jan 2007 10:51:56 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C74137.FF7605C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdBN/92Fp8jUaZlTHaUw8Lr6fLoAQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <078003964778886.ED1300457F@rdsnet.ro> X-Spam-Score: 1.7 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0000_01C74137.FF7605C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
<> ATTENTION DAY TRADERS AND INVESTORS. GET ON PSUD! <>

INVESTOR ALERT! DON'T MISS THIS RUN ON PSUD!!!

Watch PSUD Like a Hawk on January 26, 2007

Company: PetroSun
Sym: PSUD
Currently: $0.43 (+0.01 Close)
Friday Target: $1.50

PHOENIX, AZ--(MRKET WIRE)--Jan 11, 2007 -- PetroSun, Incorporated (Other 0TC:PSUD,PK - News) announced today that an agreement has been executed with New Standard Exploration NL of West Perth, Australia covering Exploration Permit 417 located within the Canning Basin of Western Australia. PetroSun and New Standard will form a joint venture to explore, develop and produce oil and/or gas from EP417. PetroSun is the designated Manager/Operator and will be assigned a 75% working interest in the permit for the initial consideration of A$5,000,000 through PetroSun's sole funding of exploration, permit development and drilling.

Keep a look out for additional GREAT weekly news and be sure to watch them trade like crazy on Friday January 26, 2007

------=_NextPart_000_0000_01C74137.FF7605C0-- From mpls-bounces@lists.ietf.org Fri Jan 26 03:52:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMlr-0004sE-MS; Fri, 26 Jan 2007 03:49:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMlq-0004s9-7X for mpls@ietf.org; Fri, 26 Jan 2007 03:49:18 -0500 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAMln-0003aK-Mp for mpls@ietf.org; Fri, 26 Jan 2007 03:49:18 -0500 Received: from wdhcp-158-58.verkstad.net ([192.36.158.58]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1HAMlk-0006g5-36 for mpls@ietf.org; Fri, 26 Jan 2007 09:49:14 +0100 Message-ID: <45B9C085.3060104@pi.se> Date: Fri, 26 Jan 2007 09:49:09 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mpls@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [mpls] [Fwd: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic] 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: , Errors-To: mpls-bounces@lists.ietf.org it is that time of the year again :), the secretariat has announced the cut-off dates for Prague, please see below. /Loa -------- Original Message -------- Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic Date: Fri, 26 Jan 2007 00:00:02 -0500 From: ietf-secretariat@ietf.org To: ietf-announce@ietf.org There are two (2) Internet-Draft cutoff dates for the 68th IETF Meeting in Prague, Czech Republic: February 26th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 26th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 19th at 9:00 AM ET. March 5th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, March 5th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 19th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 68th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_68.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- 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 Fri Jan 26 06:38:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPMz-0003wp-UU; Fri, 26 Jan 2007 06:35:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPMx-0003wM-Og; Fri, 26 Jan 2007 06:35:47 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAPMw-0001nr-GA; Fri, 26 Jan 2007 06:35:47 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2007 12:35:36 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QBZYaB017365; Fri, 26 Jan 2007 12:35:34 +0100 Received: from [10.61.80.119] (ams3-vpn-dhcp4216.cisco.com [10.61.80.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QBZTC8000147; Fri, 26 Jan 2007 12:35:29 +0100 (MET) Message-ID: <45B9E77A.9000606@cisco.com> Date: Fri, 26 Jan 2007 11:35:22 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Huub van Helvoort Subject: Re: [mpls] Re: [PWE3] Y.1720 liased text References: <45B8CFF8.9090800@cisco.com> <858DDD4F5B8D924C955EB55302E4D1A89B88C7@ILEXC1U02.ndc.lucent.com> <45B925F8.90707@chello.nl> In-Reply-To: <45B925F8.90707@chello.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=434; t=1169811335; x=1170675335; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[mpls]=20Re=3A=20[PWE3]=20Y.1720=20liased=20text |Sender:=20; bh=SDbbqx9uL2YN+vqIPtvRDkG9lvSuKAoc3UojRSS3Vqc=; b=mwBkpD63H7+bhA46PLVLvom6rbOJgI+LrlreaOrQc0OKHM0GoPFca4+6f+rZtbtdbLVhwwhW T0sqPpRMppmiet55NMk8+Am3+dQakN1ncEuXIrsgzp7bepcPenfB+Ivv; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mpls@ietf.org, pwe3 , "Ghani Abbas \(BE/ETL\)" 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: , Errors-To: mpls-bounces@lists.ietf.org > It was indeed a maintenance update. The previous version was > consented in the 07/2003 plenary and approved in 09/2003. > > The Appendix mentioned was not altered after that revision, > so this text is there for three years. > > Regards, Huub (editor of Y.1720). Not withstanding that, the issue of non-LSE data within the stack is a valid concern. What have stack design was implemented and deployed? Stewart _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 07:10:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPtz-0005cH-At; Fri, 26 Jan 2007 07:09:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPtx-0005Y8-Rv; Fri, 26 Jan 2007 07:09:53 -0500 Received: from [62.179.120.10] (helo=amsfep15-int.chello.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAPtt-0007Pv-EQ; Fri, 26 Jan 2007 07:09:53 -0500 Received: from [192.168.17.5] (really [62.195.168.62]) by amsfep15-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070126120947.BOMW1787.amsfep15-int.chello.nl@[192.168.17.5]>; Fri, 26 Jan 2007 13:09:47 +0100 Message-ID: <45B9EF8A.4000300@chello.nl> Date: Fri, 26 Jan 2007 13:09:46 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: neil.2.harrison@bt.com References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net> In-Reply-To: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mpls@ietf.org, stbryant@cisco.com, pwe3@ietf.org, ghani.abbas@ericsson.com Subject: [mpls] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Hello Neil, You responded: > Thanks Huub, > > Can you clarify how the S bit is set when this 1+1 seq no. field is > used? I checked the appendix II twice (because my left eye is still 10%), I could not find any text referring to setting the S bit. I only see that the 4 octet sequence number is placed right after the shim header. > What is puzzling me is this sentence in the text Stewart > extracted from Y.1720/Appendix 11: > > "Note that packet 1+1 can be provided at any level of the hierarchy of a > nested LSP." > > I sort-of read this as there can be a set of nested LSPs (hence > concatenated MPLS headers) and that the protection mechanism can be > applied to any one of these within such a stack. Am I reading this > right? I agree with your reading. > If I am, then please see my concerns of yesterday on this > thread....which, in essence, is querying what happens if there is > misconnectivity and the LSP carrying the 1+1 Seq No. stuff arrives at > some arbitrary LSR.....how will that LSR parse/interpret the fields it > sees? > > I have no background on Y.1720, so my apologies if I am asking a dumb > question. There are no dumb questions, only dumb answers. Maybe this is one: This morning I did some further investigating where the text originates and found it in the IETF archives: http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-protection-00.txt It was also discussed on the MPLS WG list and there I found the answer to your concerns expressed above (provided by yourself ;-) http://cell.onecall.net/mhonarc/mpls/2002-Apr/msg00211.html Cheers, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 07:16:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPzK-0000If-Do; Fri, 26 Jan 2007 07:15:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPzJ-0000IS-EJ; Fri, 26 Jan 2007 07:15:25 -0500 Received: from [213.46.243.15] (helo=amsfep18-int.chello.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAPzI-0008G4-14; Fri, 26 Jan 2007 07:15:25 -0500 Received: from [192.168.17.5] (really [62.195.168.62]) by amsfep18-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070126121520.CMYM25065.amsfep18-int.chello.nl@[192.168.17.5]>; Fri, 26 Jan 2007 13:15:20 +0100 Message-ID: <45B9F0D6.9040702@chello.nl> Date: Fri, 26 Jan 2007 13:15:18 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stewart Bryant Subject: Re: [mpls] / [PWE3] Y.1720 liased text References: <45B8CFF8.9090800@cisco.com> <858DDD4F5B8D924C955EB55302E4D1A89B88C7@ILEXC1U02.ndc.lucent.com> <45B925F8.90707@chello.nl> <45B9E77A.9000606@cisco.com> In-Reply-To: <45B9E77A.9000606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mpls@ietf.org, pwe3 , "Ghani Abbas \(BE/ETL\)" 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: , Errors-To: mpls-bounces@lists.ietf.org Hello Stewart, You replied: >> It was indeed a maintenance update. The previous version was >> consented in the 07/2003 plenary and approved in 09/2003. >> >> The Appendix mentioned was not altered after that revision, >> so this text is there for three years. >> >> Regards, Huub (editor of Y.1720). > > Not withstanding that, the issue of non-LSE data within > the stack is a valid concern. > > What have stack design was implemented and deployed? Would you please be so kind to elaborate/expand the last sentence, English is my second language, so I may misinterpret what you want to express. Kind regards, huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 07:18:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQ1A-00021L-Qd; Fri, 26 Jan 2007 07:17:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQ19-00021D-PH; Fri, 26 Jan 2007 07:17:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQ18-0008WO-Gg; Fri, 26 Jan 2007 07:17:19 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2007 13:17:18 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QCHHBL030636; Fri, 26 Jan 2007 13:17:17 +0100 Received: from [10.61.80.119] (ams3-vpn-dhcp4216.cisco.com [10.61.80.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QCHCC8012927; Fri, 26 Jan 2007 13:17:12 +0100 (MET) Message-ID: <45B9F143.2050701@cisco.com> Date: Fri, 26 Jan 2007 12:17:07 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Huub van Helvoort References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net> <45B9EF8A.4000300@chello.nl> In-Reply-To: <45B9EF8A.4000300@chello.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=460; t=1169813837; x=1170677837; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20Y.1720=20liased=20text |Sender:=20; bh=x+IT2iDw5NXffXm0BFumqsTZpg7CrtYV4qhteZ8tUOw=; b=KjjQCBTGDiX2b8IToF4TwBhbVz71OHC+NsZM8PCTl70yivzPhylo3sLNnAhYrp8G1ZB0i3rP x0QVo2AnCg3TbTorJfQXRFtdW5cVJBoq8PJ/FdgjA9cx0vwwGmZvzZ0u; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ghani.abbas@ericsson.com, pwe3@ietf.org, mpls@ietf.org Subject: [mpls] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org > I checked the appendix II twice (because my left eye is still 10%), > I could not find any text referring to setting the S bit. > I only see that the 4 octet sequence number is placed right > after the shim header. The implication of the text is that you can have a packet of the form: LSE (RFC3032) Sequence number LSE (RFC3032) Payload Is that correct? If so what is the setting of the S bit (See RFC3032) in each case? - Stewart _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 07:30:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQDO-0000YI-07; Fri, 26 Jan 2007 07:29:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQDM-0000Xu-KB; Fri, 26 Jan 2007 07:29:56 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQDH-00026e-6M; Fri, 26 Jan 2007 07:29:56 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 12:27:56 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Jan 2007 12:27:55 +0000 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 Date: Fri, 26 Jan 2007 12:27:54 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AF50079@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBRK7Mw4C9cvphRgOUNBIbPqxo3gAAJdoA From: To: , X-OriginalArrivalTime: 26 Jan 2007 12:27:55.0118 (UTC) FILETIME=[67AB58E0:01C74145] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mpls@ietf.org, pwe3@ietf.org, ghani.abbas@ericsson.com Subject: [mpls] RE: [PWE3] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Thanks Stewart....this is precisely my issue too. regards, Neil > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com]=20 > Sent: 26 January 2007 12:17 > To: Huub van Helvoort > Cc: Harrison,N,Neil,JCGA1 R; ghani.abbas@ericsson.com;=20 > pwe3@ietf.org; mpls@ietf.org > Subject: [PWE3] Re: Y.1720 liased text >=20 >=20 >=20 > > I checked the appendix II twice (because my left eye is=20 > still 10%), I=20 > > could not find any text referring to setting the S bit. I only see=20 > > that the 4 octet sequence number is placed right after the shim=20 > > header. >=20 > The implication of the text is that you can have a packet of the > form: >=20 > LSE (RFC3032) > Sequence number > LSE (RFC3032) > Payload >=20 > Is that correct? >=20 > If so what is the setting of the S bit (See RFC3032) in each case? >=20 > - Stewart >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 07:41:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQMO-0005dM-U9; Fri, 26 Jan 2007 07:39:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQMN-0005dA-DO; Fri, 26 Jan 2007 07:39:15 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQMJ-0003jQ-Qx; Fri, 26 Jan 2007 07:39:15 -0500 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 12:39:11 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Jan 2007 12:39:10 +0000 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 Date: Fri, 26 Jan 2007 12:39:10 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AF500B8@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBQwPYBpagkXcpTUyc+b2VicoIlAAAsUsA From: To: X-OriginalArrivalTime: 26 Jan 2007 12:39:10.0719 (UTC) FILETIME=[FA5BE0F0:01C74146] X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: mpls@ietf.org, ghani.abbas@ericsson.com, pwe3@ietf.org, stbryant@cisco.com Subject: [mpls] RE: [PWE3] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Thanks Huub....back in 2002 when I wrote this I did flag up the issue of misconnectivity even then......but reading my own words I was only thinking about a bottom of stack problem, ie S=3D1 in preceding header. The text Stewart picked out of Y.1720/Appendix II seems to imply that this can also apply to an LSP in the *middle* of an arbitrary stack....ergo the questions wrt: - what are the S bit settings in this stack? - what happens if misconnectivity occurs, ie could such an LSP arriving unexpectedly at some LSR end-up parsing the sequence number field assuming it had the 'normal' MPLS 4 octet header structure (ie label/S/EXP/TTL)?.....though as I noted in a previous mail, there is an even larger issue here that the fields in traffic units should have consistent semantics network-wide (any mode/technology) regards, Neil > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 > Sent: 26 January 2007 12:10 > To: Harrison,N,Neil,JCGA1 R > Cc: mpls@ietf.org; stbryant@cisco.com; pwe3@ietf.org;=20 > ghani.abbas@ericsson.com > Subject: [PWE3] Re: Y.1720 liased text >=20 >=20 > Hello Neil, >=20 > You responded: >=20 > > Thanks Huub, > >=20 > > Can you clarify how the S bit is set when this 1+1 seq no. field is=20 > > used? >=20 > I checked the appendix II twice (because my left eye is still=20 > 10%), I could not find any text referring to setting the S=20 > bit. I only see that the 4 octet sequence number is placed=20 > right after the shim header. >=20 > > What is puzzling me is this sentence in the text Stewart extracted=20 > > from Y.1720/Appendix 11: > >=20 > > "Note that packet 1+1 can be provided at any level of the=20 > hierarchy of=20 > > a nested LSP." > >=20 > > I sort-of read this as there can be a set of nested LSPs (hence=20 > > concatenated MPLS headers) and that the protection mechanism can be=20 > > applied to any one of these within such a stack. Am I reading this=20 > > right? >=20 > I agree with your reading. >=20 > > If I am, then please see my concerns of yesterday on this=20 > > thread....which, in essence, is querying what happens if there is=20 > > misconnectivity and the LSP carrying the 1+1 Seq No. stuff=20 > arrives at=20 > > some arbitrary LSR.....how will that LSR parse/interpret=20 > the fields it=20 > > sees? > >=20 > > I have no background on Y.1720, so my apologies if I am=20 > asking a dumb=20 > > question. >=20 > There are no dumb questions, only dumb answers. Maybe this is one: >=20 > This morning I did some further investigating where the text=20 > originates and found it in the IETF archives:=20 > http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls- packet-protection-00.txt It was also discussed on the MPLS WG list and there I found the answer to your concerns expressed above (provided by yourself ;-) http://cell.onecall.net/mhonarc/mpls/2002-Apr/msg00211.html Cheers, Huub. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.van-helvoort.eu/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 07:46:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQSQ-0000c7-QQ; Fri, 26 Jan 2007 07:45:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQSP-0000bp-1b; Fri, 26 Jan 2007 07:45:29 -0500 Received: from amsfep17-int.chello.nl ([62.179.120.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQSM-0004uO-KP; Fri, 26 Jan 2007 07:45:29 -0500 Received: from [192.168.17.5] (really [62.195.168.62]) by amsfep17-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070126124524.YGOM9209.amsfep17-int.chello.nl@[192.168.17.5]>; Fri, 26 Jan 2007 13:45:24 +0100 Message-ID: <45B9F3A1.1090006@chello.nl> Date: Fri, 26 Jan 2007 13:27:13 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stewart Bryant References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net> <45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> In-Reply-To: <45B9F143.2050701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ghani.abbas@ericsson.com, pwe3@ietf.org, mpls@ietf.org Subject: [mpls] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Hello Steward, You replied: >> I checked the appendix II twice (because my left eye is still 10%), >> I could not find any text referring to setting the S bit. >> I only see that the 4 octet sequence number is placed right >> after the shim header. > > The implication of the text is that you can have a packet of the > form: > > LSE (RFC3032) > Sequence number > LSE (RFC3032) > Payload > > Is that correct? This is also what I read, and apparently Neil does as well. > If so what is the setting of the S bit (See RFC3032) in each > case? Because the text does not mention any altering of the S-bit I assume they do not change. I agree with Neil (see his 2002 post) that this requires a very carefull configuartion of the network. Checking that both ends support this feature and closely guard the connectivity for both diverse routes. Note that this text is in an appendix, so it does not form an integral part of the recommendation, i.e. it is not mandatory. Regards, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 09:46:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASIu-0003gH-9d; Fri, 26 Jan 2007 09:43:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASIr-0003c9-9R; Fri, 26 Jan 2007 09:43:45 -0500 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HASIn-0006tY-Tw; Fri, 26 Jan 2007 09:43:45 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1HASIY-0005tH-00; Fri, 26 Jan 2007 14:43:26 +0000 Received: from your029b8cecfe ([80.68.57.98] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 14:43:27 +0000 Message-ID: <003d01c74158$5510a470$4002010a@your029b8cecfe> From: "Adrian Farrel" To: "Huub van Helvoort" , "Stewart Bryant" References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net><45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> <45B9F3A1.1090006@chello.nl> Date: Fri, 26 Jan 2007 14:39:48 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 26 Jan 2007 14:43:27.0839 (UTC) FILETIME=[572616F0:01C74158] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: mpls@ietf.org, pwe3@ietf.org, ghani.abbas@ericsson.com Subject: [mpls] Re: [PWE3] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Huub, >> The implication of the text is that you can have a packet of the >> form: >> >> LSE (RFC3032) >> Sequence number >> LSE (RFC3032) >> Payload >> >> Is that correct? > > This is also what I read, and apparently Neil does as well. > >> If so what is the setting of the S bit (See RFC3032) in each >> case? > > Because the text does not mention any altering of the S-bit > I assume they do not change. Ah, so either setting of the S-bit is allowed? > I agree with Neil (see his 2002 post) that this requires a > very carefull configuartion of the network. Checking that > both ends support this feature and closely guard the connectivity > for both diverse routes. With the S-bit, careful config is needed. Without the S-bit it seems like a router that popped a label would expect the next thing on the stack to also be a label, but would actually find a magic sequence number. Although you could config around this (since the pop action must be installed) this is a new MPLS behavior. At the least it is a new LFIB action that is not previously described in any MPLS documentation. > Note that this text is in an appendix, so it does not form > an integral part of the recommendation, i.e. it is not mandatory. Hmmm. Shouldn't there be a specification of: - what must be supported - what can also be attempted I think Stewart's question is quite helpful here. Do we have any idea of what deployed implementations do? Cheers, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 14:06:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWME-0002sn-47; Fri, 26 Jan 2007 14:03:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWMC-0002mS-AP; Fri, 26 Jan 2007 14:03:28 -0500 Received: from [213.46.243.15] (helo=amsfep13-int.chello.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWM7-0004ki-Rz; Fri, 26 Jan 2007 14:03:28 -0500 Received: from [192.168.17.3] (really [62.195.168.62]) by amsfep13-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070126190316.TWET13454.amsfep13-int.chello.nl@[192.168.17.3]>; Fri, 26 Jan 2007 20:03:16 +0100 Message-ID: <45BA5072.8060005@chello.nl> Date: Fri, 26 Jan 2007 20:03:14 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Adrian Farrel References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net><45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> <45B9F3A1.1090006@chello.nl> <003d01c74158$5510a470$4002010a@your029b8cecfe> In-Reply-To: <003d01c74158$5510a470$4002010a@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mpls@ietf.org, ghani.abbas@ericsson.com, pwe3@ietf.org, Stewart Bryant Subject: [mpls] Re: [PWE3] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Hi Adrian, You wrote: > Hi Huub, > >>> The implication of the text is that you can have a packet of the >>> form: >>> >>> LSE (RFC3032) >>> Sequence number >>> LSE (RFC3032) >>> Payload >>> >>> Is that correct? >> >> This is also what I read, and apparently Neil does as well. >> >>> If so what is the setting of the S bit (See RFC3032) in each >>> case? >> >> Because the text does not mention any altering of the S-bit >> I assume they do not change. > > Ah, so either setting of the S-bit is allowed? [hvh] the text does also not mention a specific value of the S-bit, so I suppose either value of the S-bit is allowed. If I would try to implement this protection, the LSR providing the protection would build the LSE according to RFC3032 and then add the 4 octet sequence number. >> I agree with Neil (see his 2002 post) that this requires a >> very carefull configuartion of the network. Checking that >> both ends support this feature and closely guard the connectivity >> for both diverse routes. > > With the S-bit, careful config is needed. [hvh] indeed I did mean careful > Without the S-bit it seems like a router that popped a label would > expect the next thing on the stack to also be a label, but would > actually find a magic sequence number. [hvh] if the the config was careful the router that pops the label inserted by the router that is the source of the protection knows that the 4 octets following this popped label is the sequene number and treats it accordingly. > Although you could config around > this (since the pop action must be installed) this is a new MPLS > behavior. At the least it is a new LFIB action that is not previously > described in any MPLS documentation. [hvh] ehh, it was described in http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-protection-00.txt This draft was presented and discussed in the IETF53 meeting. The meeting notes nor the discussion afterwards on the MPLS WG list mention the fact that it contains a new LFIB action. >> Note that this text is in an appendix, so it does not form >> an integral part of the recommendation, i.e. it is not mandatory. > > Hmmm. > > Shouldn't there be a specification of: > - what must be supported > - what can also be attempted [hvh] maybe, but apparently when the text was drafted there were no contributions providing/requesting these specifications, and when the recommendation was approved (as usual in ITU-T by consensus) nobody objected, in the meeting of the Q3/13, at the closing plenary, nor during the AAP. > I think Stewart's question is quite helpful here. Do we have any idea of > what deployed implementations do? [hvh] That would be a question to ask on the ITU-T Q9/15 exploder > Cheers, > Adrian Cheers, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 14:32:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWnN-0000m4-Ht; Fri, 26 Jan 2007 14:31:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWnK-0000jt-Nw; Fri, 26 Jan 2007 14:31:30 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWnJ-0000QX-Cb; Fri, 26 Jan 2007 14:31:30 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2007 20:31:27 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QJVQP0020701; Fri, 26 Jan 2007 20:31:26 +0100 Received: from [10.61.80.119] (ams3-vpn-dhcp4216.cisco.com [10.61.80.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QJVNC8009503; Fri, 26 Jan 2007 20:31:23 +0100 (MET) Message-ID: <45BA5707.3070503@cisco.com> Date: Fri, 26 Jan 2007 19:31:19 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Huub van Helvoort References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net><45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> <45B9F3A1.1090006@chello.nl> <003d01c74158$5510a470$4002010a@your029b8cecfe> <45BA5072.8060005@chello.nl> In-Reply-To: <45BA5072.8060005@chello.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1827; t=1169839886; x=1170703886; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20Re=3A=20Y.1720=20liased=20text |Sender:=20; bh=U6D9CHMHmnK2hVEmn7FOw4ACHxsMec07fEfiIXiggHc=; b=q5H5rjo61hRvpRtX1+KS+i8c5Lv035wZRsSLUPTmLf61Jmn2ge/5+VOMhwbPo5BsLlDEbrTr 2cN0yjuSc4BOh7SB599i5JliVFsiMOOmr5kEGLFn4RDS97TBIG0ounlJ; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mpls@ietf.org, pwe3@ietf.org, ghani.abbas@ericsson.com Subject: [mpls] Re: [PWE3] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org > [hvh] the text does also not mention a specific value of the S-bit, > so I suppose either value of the S-bit is allowed. > If I would try to implement this protection, the LSR > providing the protection would build the LSE according to > RFC3032 and then add the 4 octet sequence number. ... but it would not be building a label stack it would be building a something else. > [hvh] if the the config was careful the router that pops the > label inserted by the router that is the source of the protection > knows that the 4 octets following this popped label is the > sequene number and treats it accordingly. You can do lots of things if you are careful, but that does not mean that they should be done. We have no idea what the consequences of stray data in the stack are, or how they impact any developments we might wish to make in the future. > [hvh] ehh, it was described in > http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-protection-00.txt > > This draft was presented and discussed in the IETF53 meeting. > The meeting notes nor the discussion afterwards on the MPLS WG list > mention the fact that it contains a new LFIB action. Actually I see that you ran out of time at the meeting, and then not much. > [hvh] maybe, but apparently when the text was drafted there were no > contributions providing/requesting these specifications, and > when the recommendation was approved (as usual in ITU-T by > consensus) nobody objected, in the meeting of the Q3/13, at > the closing plenary, nor during the AAP. > I am not sure that presenting a draft at one IETF meeting - which ran out of time - and then letting the draft die constitutes IETF approval for the design. Stewart _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 15:04:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXHg-0001RW-2y; Fri, 26 Jan 2007 15:02:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXHe-0001RO-NF; Fri, 26 Jan 2007 15:02:50 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAXHd-0005fT-Bi; Fri, 26 Jan 2007 15:02:50 -0500 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1169841768!10872550!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2827 invoked from network); 26 Jan 2007 20:02:48 -0000 Received: from unknown (HELO attrh8i.attrh.att.com) (134.24.146.4) by server-15.tower-121.messagelabs.com with SMTP; 26 Jan 2007 20:02:48 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0QK0CKB001819; Fri, 26 Jan 2007 15:00:13 -0500 (EST) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0QK048x001715; Fri, 26 Jan 2007 15:00:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jan 2007 14:02:36 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0D845794@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <45BA5072.8060005@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBfLlXJ3ysepdtRL2eiZpEQ95QZAABJLLw From: "BRUNGARD, DEBORAH A, SBCLABS" To: "Huub van Helvoort" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: mpls@ietf.org, pwe3@ietf.org Subject: [mpls] RE: [PWE3] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org FYI- This 1+1 packet protection scheme was not only in ITU's SG13 work, it was also included in SG15's G.7712, done at the same time (2003). G.7712 doesn't reference Y.1720, probably as they were being done at the same time, though the scheme was of the same origin. G.7712's Appendix IV does say that the implementation is "non-trivial", maybe there have been no attempts. (ITU Recommendations (PDF) can be downloaded for free) Deborah =20 -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 Sent: Friday, January 26, 2007 2:03 PM To: Adrian Farrel Cc: mpls@ietf.org; ghani.abbas@ericsson.com; pwe3@ietf.org; Stewart Bryant Subject: Re: [PWE3] Re: Y.1720 liased text Hi Adrian, You wrote: > Hi Huub, >=20 >>> The implication of the text is that you can have a packet of the >>> form: >>> >>> LSE (RFC3032) >>> Sequence number >>> LSE (RFC3032) >>> Payload >>> >>> Is that correct? >> >> This is also what I read, and apparently Neil does as well. >> >>> If so what is the setting of the S bit (See RFC3032) in each >>> case? >> >> Because the text does not mention any altering of the S-bit >> I assume they do not change. >=20 > Ah, so either setting of the S-bit is allowed? [hvh] the text does also not mention a specific value of the S-bit, so I suppose either value of the S-bit is allowed. If I would try to implement this protection, the LSR providing the protection would build the LSE according to RFC3032 and then add the 4 octet sequence number. >> I agree with Neil (see his 2002 post) that this requires a >> very carefull configuartion of the network. Checking that >> both ends support this feature and closely guard the connectivity >> for both diverse routes. >=20 > With the S-bit, careful config is needed. [hvh] indeed I did mean careful > Without the S-bit it seems like a router that popped a label would=20 > expect the next thing on the stack to also be a label, but would=20 > actually find a magic sequence number. [hvh] if the the config was careful the router that pops the label inserted by the router that is the source of the protection knows that the 4 octets following this popped label is the sequene number and treats it accordingly. > Although you could config around=20 > this (since the pop action must be installed) this is a new MPLS=20 > behavior. At the least it is a new LFIB action that is not previously=20 > described in any MPLS documentation. [hvh] ehh, it was described in http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-pro tection-00.txt This draft was presented and discussed in the IETF53 meeting. The meeting notes nor the discussion afterwards on the MPLS WG list mention the fact that it contains a new LFIB action. >> Note that this text is in an appendix, so it does not form >> an integral part of the recommendation, i.e. it is not mandatory. >=20 > Hmmm. >=20 > Shouldn't there be a specification of: > - what must be supported > - what can also be attempted [hvh] maybe, but apparently when the text was drafted there were no contributions providing/requesting these specifications, and when the recommendation was approved (as usual in ITU-T by consensus) nobody objected, in the meeting of the Q3/13, at the closing plenary, nor during the AAP. > I think Stewart's question is quite helpful here. Do we have any idea of=20 > what deployed implementations do? [hvh] That would be a question to ask on the ITU-T Q9/15 exploder > Cheers, > Adrian Cheers, Huub. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.van-helvoort.eu/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jan 26 15:31:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXhS-0006kG-OY; Fri, 26 Jan 2007 15:29:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXhR-0006jr-2a; Fri, 26 Jan 2007 15:29:29 -0500 Received: from [213.46.243.15] (helo=amsfep12-int.chello.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAXhP-0001G4-KZ; Fri, 26 Jan 2007 15:29:29 -0500 Received: from [192.168.17.3] (really [62.195.168.62]) by amsfep12-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070126202921.BNZV1957.amsfep12-int.chello.nl@[192.168.17.3]>; Fri, 26 Jan 2007 21:29:21 +0100 Message-ID: <45BA649F.7070703@chello.nl> Date: Fri, 26 Jan 2007 21:29:19 +0100 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stewart Bryant References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net><45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> <45B9F3A1.1090006@chello.nl> <003d01c74158$5510a470$4002010a@your029b8cecfe> <45BA5072.8060005@chello.nl> <45BA5707.3070503@cisco.com> In-Reply-To: <45BA5707.3070503@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mpls@ietf.org, pwe3@ietf.org, ghani.abbas@ericsson.com Subject: [mpls] Re: [PWE3] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Stewart, You replied: >> [hvh] the text does also not mention a specific value of the S-bit, >> so I suppose either value of the S-bit is allowed. >> If I would try to implement this protection, the LSR >> providing the protection would build the LSE according to >> RFC3032 and then add the 4 octet sequence number. > > ... but it would not be building a label stack it would be > building a something else. [hvh] then I suggest that you/your company writes a contribution explaining this and sent it to q9/15 proposing a correction to Y.1720 >> [hvh] if the the config was careful the router that pops the >> label inserted by the router that is the source of the protection >> knows that the 4 octets following this popped label is the >> sequene number and treats it accordingly. > > You can do lots of things if you are careful, but that does > not mean that they should be done. We have no idea what > the consequences of stray data in the stack are, or how > they impact any developments we might wish to make in the > future. > >> [hvh] ehh, it was described in >> http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-protection-00.txt >> >> This draft was presented and discussed in the IETF53 meeting. >> The meeting notes nor the discussion afterwards on the MPLS WG list >> mention the fact that it contains a new LFIB action. > > Actually I see that you ran out of time at the meeting, and then > not much. ==================== diclaimer ==================================== I (Huub van Helvoort), did not write/present this draft. So I could not run out of time. (IETF64 was the first meeting I attended). I am editor of Y.1720 since 2004 when this text was already in the appendix. As an editor I can only change text by consensus based on contributions and discussion during drafting. =================================================================== I regret that I tried to help resolve this issue. >> [hvh] maybe, but apparently when the text was drafted there were no >> contributions providing/requesting these specifications, and >> when the recommendation was approved (as usual in ITU-T by >> consensus) nobody objected, in the meeting of the Q3/13, at >> the closing plenary, nor during the AAP. > > I am not sure that presenting a draft at one IETF meeting - which > ran out of time - and then letting the draft die constitutes > IETF approval for the design. Before the contribution proposing the addition of this text reached the ITU-T it has passed the USA approval process (maybe ANSI, but at least SGB). Is was contributed as a USA contribution so no US companies objected against the text. Is it wrong to assume that these companies will ask their experts to review such documents? and that some of these experts attend IETF meetings? Regards, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sat Jan 27 05:43:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAkxE-0001Au-70; Sat, 27 Jan 2007 05:38:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAkxC-0001Aj-Ff; Sat, 27 Jan 2007 05:38:38 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAkx2-0004fM-MN; Sat, 27 Jan 2007 05:38:38 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 10:38:16 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 27 Jan 2007 10:38:15 +0000 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: [PWE3] Re: Y.1720 liased text Date: Sat, 27 Jan 2007 10:38:15 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353891AF50933@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] RE: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBfLlXJ3ysepdtRL2eiZpEQ95QZAABJLLwABcCmIA= From: To: , X-OriginalArrivalTime: 27 Jan 2007 10:38:15.0937 (UTC) FILETIME=[4095BF10:01C741FF] X-Spam-Score: 0.2 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: mpls@ietf.org, pwe3@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: , Errors-To: mpls-bounces@lists.ietf.org Hi Deborah, Think it's high time we distinguished the symptom from the cause here. The problem is NOT the 1+1 prot-sw scheme...indeed this could be ANY function.....this is simply a symptom. So let's first be clear on this aspect. The real problem is the way MPLS has been designed. However, because of the amount of MPLS deployed to date I believe we will almost certainly end-up attacking/deprecating things that expose these design problems....like the 1+1 prot-sw scheme under discussion here. Despite this we should, IMO at least, attempt to accurately explain WHY it's creating a problem.....else we are not providing an objective technical analysis to the larger community. The real causal problem here is the MPLS stack. Stacked LSPs do NOT form a client/server relationship....they are all functionally coupled....and the functional coupling itself is not consistent. A key observation here is that MPLS does not treat its clients consistently...that is: - if IP then =3D> null encaps *OR* peer PDU.....which when coldly analysed means that a cl-ps IP layer network and (something that looks like) a co-ps layer network (ie MPLS) are co-existing in the *same layer network* space.....and for those folks familiar with functional architecture this should immediately ring alarm bells as 'a bit of a problem'.....this BTW is one of the reasons why some folks are pushing T-MPLS...however I don't want to get into that particular symptom here. - if MPLS then =3D> digital wrapper.....this holds the tantalising illusion that one can create topology on the fly by simply adding another MPLS header.....this, however, does not work. - if 'other' then =3D> PW encapsulation. This is a direct consequence of the above. Its practical impact however was fairly benign when PWs were restricted to 1-hop as we could treat these largely as a form of 'adaptation'. However, when PW entities become multi-hop we have no choice but to start off down the road of creating a new co-ps mode PW layer network above the hybrid IP/MPLS layer network. That is just the way it is. Now let's return to the 1+1 prot-sw symptom and try and understand why it exposes a design problem for MPLS against the above background. - the MPLS digital wrapper stack uses the rules: (i) if S=3D0 then another MPLS header follows and (ii) if S=3D1 another MPLS header does = not follow.....so what does follow? - well, it might be an IP packet or it might be a PW encapsulated packet. Noting that because of the different way MPLS treats its clients (including itself as a digital wrapper) AND the fact that ECMP mechanisms use the 1st nibble of an IP packet to distinguish v4 and v6 variants, the PW encapsulated packet must have a way to distinguish itself from the IP packet in the 1st nibble. Ergo the control-word structure of PW adaptation....at least the 1st nibble therein. Same distinguishing issue arises with the VCCV stuff....which is now yet another client type but only applicable with PWs (ie PW and VCCV clients are muxed together). - a critical question we should ask at this point is 'what happens if MPLS LSPs get misconnected?' And the first architectural design observation we can make here is that the functional fields in traffic units SHOULD (though I would say MUST) have consistent semantics if, under misconnectivity, the consequential behaviour is to be consistent/predictable....this should be especially obvious as a requirement for the OAM mechanisms if nothing else! - so let's look at MPLS itself here. The S/EXP/TTL fields do remain fairly consistent but the label field does not. The 1st functional split relates to the 0-15 reserved labels (that imply an 'action') and the rest of the labels.....nothing wrong here in concept as the semantics are clear and not assigned to arbitrary labels. Now in normal co-ps mode destination forwarding the label is a locally-significant (ie link connection) proxy for the trail's globally-significant destination address (DA). However, in MPLS we also permit mp2p merging behaviour (both LDP and PHP create merging). This requires that labels must also be able to take on a different functional 'demerging' role of being a proxy for a trail's globally-significant source address (SA). Further, there are 2 subtle spins on this: * if the client is a PW then the demerging label provides a 1:1 identification of the ultimate client instance; * if the client is a rfc4364 (ex rfc2547) IP VPN then the demerging label only resolves to a specific client VRF instance within a certain VPN.....the ultimate (IP) client is then always resolvable within its VPN instance because cl-ps mode traffic units MUST always carry globally-significant (ie with the layer network of interest...here a VPN) SA label. - so we already see we do not have consistent label semantics in MPLS per se. And because LSPs can be stacked and are functionally coupled, then not only can we have misconnectivity between LSPs at the same level in the stack but also between LSPs at different levels in the stack. So under misconnectivity the way in which the receiving LSR regards the semantics of the label field may not be consistent. - now let's now look at the 1+1 prot-sw function mentioned in Y.1720 in the context of the above; =20 - if the 1+1 function is below (ie payload to) an MPLS header with S=3D1 (ie no more MPLS headers follow) then there is no problem if there is no misconnectivity. However, under misconnectivity to a non 1+1 receiving LSR, that LSR will attempt to parse the payload as either an IP packet or a PW packet.....and the consequential behaviour will not be consistent/predictable because it will depend what is in the 1st nibble of the payload as the receiving LSR interprets this. Note however that if we ran, for example, a Y.1711 OAM CV flow on this LSP (actually ALL LSPs because we do not know which LSPs will experience misconnectivity ahead of the event) we should be able to detect the problem. Note also the importance of running the SAME OAM mechanism on all LSPs.....it is NOT sufficient to have OAM only associated with PWs! - if the 1+1 function can exist immediately following an MPLS header with S=3D0 then this is IMO a direct violation of the MPLS = stacking rules *irrespective* of the effects of misconnectivity. Why? Because normally this (ie S=3D0) indicates that this is not the bottom of the = MPLS header stack and that a further MPLS header follows.....but here it is not an MPLS header that follows but (in this case) a 1+1 prot-sw function. - now consider what happens under misconnectivity in the S=3D0 case. This is NOT like the previous S=3D1 case because the receiving LSR will attempt to parse the next 4 octets as an MPLS client header (and not an IP or PW client as in the S=3D1 case). However, it seems this case = would also be detectable if one ran a Y.1711 OAM CV flow (and on ALL LSPs for the reasons noted previously). Note again the importance of running the SAME OAM mechanism on all LSPs.....it is NOT sufficient to have OAM only associated with PWs! So what do we conclude/learn from all this. 1 Well, the real problem lies with MPLS and not the 1+1 scheme per se. 2 But it's far too late now to go back and re-spin MPLS (maybe the T-MPLS advocates disagree?) 3 If we ran a consistent OAM CV flow that contains a true SA on ALL LSPs (and not just PWs) (eg as described in Y.1711 say) we should be OK.....however, nothing works well in the context mp2p merging constructs, and its not just the OAM efficacy that is impacted but it also forces us to use varying labels semantics as I discussed above that also creates a problem itself under misconnectivity....just a fact. 4 Perhaps the easiest solution is to attack/deprecate the Y.1720 symptom and ban it from MPLS?.....all the above stuff does not 'go away' of course but it may be the simplest expedient course of action. Sorry for the length of this mail....but I think it important to try and properly explain what is going on here (at least as I see/understand it). regards, Neil =20 > -----Original Message----- > From: BRUNGARD, DEBORAH A, SBCLABS [mailto:dbrungard@att.com]=20 > Sent: 26 January 2007 20:03 > To: Huub van Helvoort > Cc: mpls@ietf.org; pwe3@ietf.org > Subject: [mpls] RE: [PWE3] Re: Y.1720 liased text >=20 >=20 > FYI- > This 1+1 packet protection scheme was not only in ITU's SG13=20 > work, it was also included in SG15's G.7712, done at the same=20 > time (2003). G.7712 doesn't reference Y.1720, probably as=20 > they were being done at the same time, though the scheme was=20 > of the same origin. >=20 > G.7712's Appendix IV does say that the implementation is=20 > "non-trivial", maybe there have been no attempts. >=20 > (ITU Recommendations (PDF) can be downloaded for free) >=20 > Deborah =20 >=20 > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 > Sent: Friday, January 26, 2007 2:03 PM > To: Adrian Farrel > Cc: mpls@ietf.org; ghani.abbas@ericsson.com; pwe3@ietf.org;=20 > Stewart Bryant > Subject: Re: [PWE3] Re: Y.1720 liased text >=20 > Hi Adrian, >=20 > You wrote: >=20 > > Hi Huub, > >=20 > >>> The implication of the text is that you can have a packet of the > >>> form: > >>> > >>> LSE (RFC3032) > >>> Sequence number > >>> LSE (RFC3032) > >>> Payload > >>> > >>> Is that correct? > >> > >> This is also what I read, and apparently Neil does as well. > >> > >>> If so what is the setting of the S bit (See RFC3032) in each case? > >> > >> Because the text does not mention any altering of the=20 > S-bit I assume=20 > >> they do not change. > >=20 > > Ah, so either setting of the S-bit is allowed? >=20 > [hvh] the text does also not mention a specific value of the S-bit, > so I suppose either value of the S-bit is allowed. > If I would try to implement this protection, the LSR > providing the protection would build the LSE according to > RFC3032 and then add the 4 octet sequence number. >=20 > >> I agree with Neil (see his 2002 post) that this requires a very=20 > >> carefull configuartion of the network. Checking that both ends=20 > >> support this feature and closely guard the connectivity for both=20 > >> diverse routes. > >=20 > > With the S-bit, careful config is needed. >=20 > [hvh] indeed I did mean careful >=20 > > Without the S-bit it seems like a router that popped a label would > > expect the next thing on the stack to also be a label, but would=20 > > actually find a magic sequence number. >=20 > [hvh] if the the config was careful the router that pops the=20 > label inserted by the router that is the source of the=20 > protection knows that the 4 octets following this popped=20 > label is the sequene number and treats it accordingly. >=20 > > Although you could config around > > this (since the pop action must be installed) this is a new MPLS=20 > > behavior. At the least it is a new LFIB action that is not=20 > previously=20 > > described in any MPLS documentation. >=20 > [hvh] ehh, it was described in=20 > http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls- > packet-pro > tection-00.txt > This draft was presented and discussed in the IETF53 meeting. > The meeting notes nor the discussion afterwards on the=20 > MPLS WG list > mention the fact that it contains a new LFIB action. >=20 > >> Note that this text is in an appendix, so it does not form an=20 > >> integral part of the recommendation, i.e. it is not mandatory. > >=20 > > Hmmm. > >=20 > > Shouldn't there be a specification of: > > - what must be supported > > - what can also be attempted >=20 > [hvh] maybe, but apparently when the text was drafted there were no > contributions providing/requesting these specifications, and > when the recommendation was approved (as usual in ITU-T by > consensus) nobody objected, in the meeting of the Q3/13, at > the closing plenary, nor during the AAP. >=20 > > I think Stewart's question is quite helpful here. Do we=20 > have any idea > of=20 > > what deployed implementations do? >=20 > [hvh] That would be a question to ask on the ITU-T Q9/15 exploder >=20 > > Cheers, > > Adrian >=20 > Cheers, Huub. >=20 > --=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > http://www.van-helvoort.eu/=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=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 jj_mix0323@yahoo.it Sat Jan 27 13:15:15 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAs55-0002rv-LL for MPLS-ARCHIVE@LISTS.IETF.ORG; Sat, 27 Jan 2007 13:15:15 -0500 Received: from [124.234.233.45] (helo=so-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAs4z-0005mJ-FZ for MPLS-ARCHIVE@LISTS.IETF.ORG; Sat, 27 Jan 2007 13:15:15 -0500 Received: from crnpkm3 (unknown [193.8.211.235]) by smtp14 (Coremail) with SMTP id l8gQxv1vLdM2ehnm.1 for ; Sat, 21 Feb 2004 10:53:19 +0800 (CST) X-Originating-IP: [193.8.211.235] Subject: =?iso-2022-jp?B?GyRCTyJNbUBoOHgzKyJ2GyhC?= From: =?shift-jis?B?bWlzYXRv?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C73C9F.BDDD1DC0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C73C9F.BDDD1DC0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit SEX$B$7$F$/$l$k=w@-$r3N
SEX=1B$B$7$F$/$l$k=3Dw@-$r3Nhttp://vqlh.com/?h238
=1B$BA4$FL5NA= $G;H$($k$N$G$*;n$72<$5$$=1B(B
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
/_/_/_/_/_/_/_/_/_/_/_/_/_/
=1B$B%a!<%kITMW=1B(B
saki_honda19@yahoo.fr
/_/_/_/_/_/_/_/_/_/_/_/_/_/
 
 
------=_NextPart_000_0007_01C73C9F.BDDD1DC0-- From caiusy@fairy-lamp.com Sat Jan 27 13:17:37 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAs7N-0003cu-R8 for mpls-archive@lists.ietf.org; Sat, 27 Jan 2007 13:17:37 -0500 Received: from cable-246-116.zeelandnet.nl ([82.176.246.116] helo=fairy-lamp.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAs7K-00068w-Na for mpls-archive@lists.ietf.org; Sat, 27 Jan 2007 13:17:37 -0500 Message-ID: <01c7423f$6bafba80$74f6b052@PRIVE1> Reply-To: "Marijana Cuccia" From: "Marijana Cuccia" To: "Evadne Acklin" Subject: Re: xyvRX Date: Sat, 27 Jan 2007 19:17:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Antivirus: avast! (VPS 000707-0, 27-01-2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.4 (++++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi, Virragra $3, 35 Varrlium $1, 20 Amrrbien $2, 90 Cirralis $3, 75 Xarrnax $1, 45 http://www.todrx*.com Remove "*" to make the link working! -- once it has been placed in the entrance hall. Nobody under the age of seventeen will be able to cross this line. Finally, I wish to impress upon any of you wishing to compete that this From mpls-bounces@lists.ietf.org Sat Jan 27 15:08:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAtn9-000660-O7; Sat, 27 Jan 2007 15:04:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAtn8-00063h-CI; Sat, 27 Jan 2007 15:04:50 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAtn1-0004FI-Qg; Sat, 27 Jan 2007 15:04:50 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BE8842048E; Sat, 27 Jan 2007 21:04:26 +0100 (CET) X-AuditID: c1b4fb3e-afed3bb0000007e1-12-45bbb04ab68b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A92F22007E; Sat, 27 Jan 2007 21:04:26 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 21:04:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 27 Jan 2007 21:04:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBWFhuHwMpAiD+QUKxB6F2Y06rUAA9RFuV References: <0536FC9B908BEC4597EE721BE6A353891AEF7630@i2km07-ukbr.domain1.systemhost.net><45B9EF8A.4000300@chello.nl> <45B9F143.2050701@cisco.com> <45B9F3A1.1090006@chello.nl> <003d01c74158$5510a470$4002010a@your029b8cecfe> From: "Ghani Abbas \(BE/ETL\)" To: "Adrian Farrel" , "Huub van Helvoort" , "Stewart Bryant" X-OriginalArrivalTime: 27 Jan 2007 20:04:26.0338 (UTC) FILETIME=[58859420:01C7424E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: pwe3@ietf.org, mpls@ietf.org Subject: [mpls] RE: [PWE3] Re: Y.1720 liased text 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: , Errors-To: mpls-bounces@lists.ietf.org Adrain and Stewart, =20 It seems to me the discussion about an issue in Y.1720 which has been in = the public domain for a long time. In order to resolve the issue I suggest that a contribution be submitted = to the next Q9/15 meeting ( either 12th., Feb or 10th.,April meetings). = Q9/15 can discuss the issue and may recommend a way forward. =20 Ghani =20 ________________________________ From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Fri 26/01/2007 15:39 To: Huub van Helvoort; Stewart Bryant Cc: neil.2.harrison@bt.com; Ghani Abbas (BE/ETL); pwe3@ietf.org; = mpls@ietf.org Subject: Re: [PWE3] Re: Y.1720 liased text Hi Huub, >> The implication of the text is that you can have a packet of the >> form: >> >> LSE (RFC3032) >> Sequence number >> LSE (RFC3032) >> Payload >> >> Is that correct? > > This is also what I read, and apparently Neil does as well. > >> If so what is the setting of the S bit (See RFC3032) in each >> case? > > Because the text does not mention any altering of the S-bit > I assume they do not change. Ah, so either setting of the S-bit is allowed? > I agree with Neil (see his 2002 post) that this requires a > very carefull configuartion of the network. Checking that > both ends support this feature and closely guard the connectivity > for both diverse routes. With the S-bit, careful config is needed. Without the S-bit it seems like a router that popped a label would = expect the next thing on the stack to also be a label, but would actually find = a magic sequence number. Although you could config around this (since the = pop action must be installed) this is a new MPLS behavior. At the least it = is a new LFIB action that is not previously described in any MPLS = documentation. > Note that this text is in an appendix, so it does not form > an integral part of the recommendation, i.e. it is not mandatory. Hmmm. Shouldn't there be a specification of: - what must be supported - what can also be attempted I think Stewart's question is quite helpful here. Do we have any idea of what deployed implementations do? Cheers, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From gulahab@abajob.com Sun Jan 28 14:35:50 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBFoc-0003TG-K6 for mpls-archive@lists.ietf.org; Sun, 28 Jan 2007 14:35:50 -0500 Received: from p54bddfe1.dip.t-dialin.net ([84.189.223.225] helo=abajob.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBFob-0002vK-3T for mpls-archive@lists.ietf.org; Sun, 28 Jan 2007 14:35:50 -0500 Message-ID: <01c74313$843e3f20$2002a8c0@blade> Reply-To: "Peppi Linck" From: "Peppi Linck" To: "Shankar Bowens" Subject: Re: uiuRX Date: Sun, 28 Jan 2007 20:35:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.8 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi, Virragra $3, 35 Varrlium $1, 20 Amrrbien $2, 90 Cirralis $3, 75 Xarrnax $1, 45 http://www.todrx*.com Remove "*" to make the link working! -- curl... not that it needs it she added, eyeing Hermiones bushy hair. Lets go, said Hermione, cmon. Harry Ron... They left; many people were staring at them as they went. Harry glanced From kucomcuk@karneval.cz Mon Jan 29 02:23:21 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBQrJ-0003Ff-Fb for mpls-archive@lists.ietf.org; Mon, 29 Jan 2007 02:23:21 -0500 Received: from mos-81-27-201-32.karneval.cz ([84.242.88.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBQrH-0008Un-RQ for mpls-archive@lists.ietf.org; Mon, 29 Jan 2007 02:23:21 -0500 From: "as retrieved" To: mpls-archive@lists.ietf.org Subject: Rocket Stock Report Date: Mon, 29 Jan 2007 08:21:35 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C7437E.7D9BC7D0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdDfn2eyMhbOigQQ/+O1Kos1SOr3A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <7E6841563710C7A.753EDE2B21@karneval.cz> X-Spam-Score: 1.3 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ------=_NextPart_000_0002_01C7437E.7D9BC7D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
TRADERS! PSUD is going through the roof next week!

WATCH OUT!
Monday January 29 IS SURE TO BE A GOOD DAY!

Company: PetroSun
Sym: PSUD
Currently: $0.52 (+0.09 Close) 20.9%
Friday Target: $1.50

2007-01-11 11:46 ET - News Release

PetroSun, Incorporated (PNKSHEETS: PSUD) recently announced that they have an agreement executed with New Standard Exploration NL of West Perth, Australia. It covers the Exploration Pemit 417 which is location within Western Australias Canning Basin. a Joint venture has been established to explore develop and produce oil and or gas from EP417. PetroSun was assigned a 75% working interest in the permit, intial consideration of $5Million.

ADD THIS TO YOUR LIST AND WATCH IT LIKE A HAWK ON Monday January 29, 2007!!!!
------=_NextPart_000_0002_01C7437E.7D9BC7D0-- From mpls-bounces@lists.ietf.org Mon Jan 29 14:50:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcTc-00082z-Us; Mon, 29 Jan 2007 14:47:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcTb-00082q-4B; Mon, 29 Jan 2007 14:47:39 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBcTX-0003t7-Kb; Mon, 29 Jan 2007 14:47:39 -0500 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1170100052!19569747!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 24145 invoked from network); 29 Jan 2007 19:47:32 -0000 Received: from unknown (HELO attrh8i.attrh.att.com) (134.24.146.4) by server-3.tower-121.messagelabs.com with SMTP; 29 Jan 2007 19:47:32 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0TJis32021259; Mon, 29 Jan 2007 14:44:56 -0500 (EST) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0TJikLq021187; Mon, 29 Jan 2007 14:44:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [PWE3] Re: Y.1720 liased text Date: Mon, 29 Jan 2007 13:47:25 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0D88BD07@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <0536FC9B908BEC4597EE721BE6A353891AF50933@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] RE: [PWE3] Re: Y.1720 liased text Thread-Index: AcdBfLlXJ3ysepdtRL2eiZpEQ95QZAABJLLwABcCmIAAf0IaoA== From: "BRUNGARD, DEBORAH A, SBCLABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mpls@ietf.org, pwe3@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: , Errors-To: mpls-bounces@lists.ietf.org Hi Neil, Good analysis - we still don't have the perfect technology;-) Though as you say I am not sure what can be done of the last four options - especially the last - by IETF. It seems to be set in stone from the other emails on the list. At most, IETF can mention concern (as Stewart captured in his proposal). And encourage cross-SDO review and use of RFC4775 when considering applying/extending MPLS. Deborah _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jan 30 05:34:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBqFs-0006kz-31; Tue, 30 Jan 2007 05:30:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBqFq-0006kp-JD for mpls@lists.ietf.org; Tue, 30 Jan 2007 05:30:22 -0500 Received: from smtp23.msg.oleane.net ([62.161.4.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBqFm-0005Bw-3K for mpls@lists.ietf.org; Tue, 30 Jan 2007 05:30:22 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp23.msg.oleane.net (MTA) with ESMTP id l0UAU4fD005452 for ; Tue, 30 Jan 2007 11:30:04 +0100 Message-Id: <200701301030.l0UAU4fD005452@smtp23.msg.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 30 Jan 2007 11:29:59 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdEWZeSIhBISp30SoCiQiv/hIf9UA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [mpls] MPLS World Congress 2007 - Next week in Paris 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="===============0330740178==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0330740178== Content-Type: multipart/alternative; boundary="----=_NextPart_000_011C_01C74461.F9D26460" This is a multi-part message in MIME format. ------=_NextPart_000_011C_01C74461.F9D26460 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit One week left before the starting of the 9th MPLS World Congress in Paris, THE major rendez-vous for the industry worldwide. The 2007 edition will welcome 800 participants, 30 exhibitors and co-organize an interoperability platform welcoming more vendors. New this year: a Carrier Ethernet Workshop http://www.upperside.fr/mpls2007/mplsworld2007intro.htm ------=_NextPart_000_011C_01C74461.F9D26460 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

One week left before the starting of the 9th = MPLS = World Congress in Paris, THE major rendez-vous for the = industry worldwide. The 2007 edition will welcome 800 participants, 30 exhibitors = and co-organize an interoperability platform welcoming more vendors. New = this year: a Carrier Ethernet Workshop

 

http://www.upperside.fr/mpls2007/mplsworld2007intro.htm

 

------=_NextPart_000_011C_01C74461.F9D26460-- --===============0330740178== 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 --===============0330740178==-- From gorley@kacto.ford.com Tue Jan 30 08:16:51 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBsqx-0000WU-Hm for mpls-archive@lists.ietf.org; Tue, 30 Jan 2007 08:16:51 -0500 Received: from pc-28-207-214-201.cm.vtr.net ([201.214.207.28] helo=kacto.ford.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HBsqt-0001cP-VR for mpls-archive@lists.ietf.org; Tue, 30 Jan 2007 08:16:49 -0500 Message-ID: <01c74470$e37351c0$1ccfd6c9@mammarita> Reply-To: "Kenya Mars" From: "Kenya Mars" To: "Ellil Loveall" Subject: Re: zos touca Date: Tue, 30 Jan 2007 10:16:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi, VI_zAGRA $3, 35 VA_zLIUM $1, 20 AM_zBIEN $2, 90 CI_zALIS $3, 75 XA_zNAX $1, 45 http://www.tod*rx.com Remove "*" to make the link working! -- No ones tried to attack me so far, except a dragon and a couple of grindylows, Harry said, but Sirius scowled at him. I dont care... Ill breathe freely again when this tournaments over, From mpls-bounces@lists.ietf.org Tue Jan 30 11:50:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBw7O-00085A-82; Tue, 30 Jan 2007 11:46:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBw7N-00084z-Ay for mpls@lists.ietf.org; Tue, 30 Jan 2007 11:46:01 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBw76-0005zD-0Y for mpls@lists.ietf.org; Tue, 30 Jan 2007 11:46:01 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 30 Jan 2007 08:45:15 -0800 X-IronPort-AV: i="4.13,258,1167638400"; d="scan'208,217"; a="358492087:sNHT77453034564" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0UGjEMf001946; Tue, 30 Jan 2007 11:45:14 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0UGjAVV000295; Tue, 30 Jan 2007 11:45:14 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 11:45:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Jan 2007 11:44:51 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D33202876A89@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <1A629FEA23F9F14CAF0B8B3A5AA2FC29400EC5@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MPLS-OPS]: IP Solution Center Thread-Index: AcdEgn4TAVcfvs04QayTmIRGHodZTwACoipQ From: "Roger Williams \(rogwilli\)" To: , , , , , X-OriginalArrivalTime: 30 Jan 2007 16:45:08.0577 (UTC) FILETIME=[00614D10:01C7448E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5075; t=1170175514; x=1171039514; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rogwilli@cisco.com; z=From:=20=22Roger=20Williams=20\(rogwilli\)=22=20 |Subject:=20RE=3A=20[MPLS-OPS]=3A=20IP=20Solution=20Center |Sender:=20 |To:=20, =20, =20, =0A=20=20=20=20=20=20=20=20, =20,=0A=20=20=20=20=20=20=20=20; bh=UIM+yF2SWlFMd8GRXPRlThHZT689tejqdR9ga6D63mg=; b=ongHl8YkPtPfGgIWHomqX6Cg7tjY1n+0wLaCXhcgbrWp+MA9Q4ht2ssEstYwwb216ShtZgTl tBRq1wS5Xt/eqWxD74kcA7yCAEf4Kf1Be81/YOD+AJdzkzoCFyhZ9aoZ; Authentication-Results: rtp-dkim-2; header.From=rogwilli@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Subject: [mpls] RE: [MPLS-OPS]: IP Solution Center 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="===============0355057226==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0355057226== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7448E.00095F13" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7448E.00095F13 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alaerte, your question is very broad, too broad to answer effectively.=20 =20 ISC has a number of different capabilities, so your question could be more specific. =20 Very short list of ISC capabilities: Layer 3 (MPLS) VPN deployment Layer 2 (VLAN/ MetroE) VPN deployment MPLS Core Traffic Engineering Planning and Deployment Some QoS deployment, both link and VPN. MPLS Diagnostics - capable of diagnosing faults in MPLS VPN configuration =20 For what it is worth, arguably the largest SP in the US, with over 120k end points, uses ISC for VPN deployment, and this from a single server. This says something about robustness. =20 Roger Williams ________________________________ From: Alaerte.Vidali@nokia.com [mailto:Alaerte.Vidali@nokia.com]=20 Sent: Tuesday, January 30, 2007 10:23 AM To: mpls@uu.net; mpls-ops@mplsrc.com; mpls@lists.ietf.org; cisco-nsp@puck.nether.net; mpls-ops@mplsrc.com Subject: [MPLS-OPS]: IP Solution Center Hi,=20 Could you give your opinion about IP Solution Center 4.2?=20 (characteristics like robustness, correctness when converting actions to commands...)=20 Thanks,=20 Alaerte Gladston Vidali=20 ------_=_NextPart_001_01C7448E.00095F13 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IP Solution Center
Alaerte, your question is very broad, too broad to = answer=20 effectively.
 
ISC=20 has a number of different capabilities, so your question could be more=20 specific.
 
Very=20 short list of ISC capabilities:
Layer=20 3 (MPLS) VPN deployment
Layer=20 2 (VLAN/ MetroE) VPN deployment
MPLS=20 Core Traffic Engineering Planning and Deployment
Some=20 QoS deployment, both link and VPN.
MPLS=20 Diagnostics - capable of diagnosing faults in MPLS VPN=20 configuration
 
For=20 what it is worth, arguably the largest SP in the US, with over 120k end = points,=20 uses ISC for VPN deployment, and this from a single server. This says = something=20 about robustness.
 
Roger=20 Williams

From: Alaerte.Vidali@nokia.com=20 [mailto:Alaerte.Vidali@nokia.com]
Sent: Tuesday, January 30, = 2007=20 10:23 AM
To: mpls@uu.net; mpls-ops@mplsrc.com; = mpls@lists.ietf.org;=20 cisco-nsp@puck.nether.net; mpls-ops@mplsrc.com
Subject: = [MPLS-OPS]: IP=20 Solution Center

Hi,

Could you give your = opinion about IP=20 Solution Center 4.2?
(characteristics like robustness, correctness when converting = actions to=20 commands...)

Thanks, =
Alaerte Gladston = Vidali

------_=_NextPart_001_01C7448E.00095F13-- --===============0355057226== 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 --===============0355057226==-- From mpls-bounces@lists.ietf.org Tue Jan 30 11:55:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwFZ-000401-Nc; Tue, 30 Jan 2007 11:54:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwFX-0003wh-L9 for mpls@lists.ietf.org; Tue, 30 Jan 2007 11:54:27 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwFU-0007Ys-Su for mpls@lists.ietf.org; Tue, 30 Jan 2007 11:54:27 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0UGpDmc023130; Tue, 30 Jan 2007 18:51:35 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 18:53:58 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 10:53:40 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Jan 2007 10:53:37 -0600 Message-ID: <1A629FEA23F9F14CAF0B8B3A5AA2FC29400FC9@daebe103.NOE.Nokia.com> In-Reply-To: <3C292CE901FC634693F24FB2DDC4D33202876A89@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MPLS-OPS]: IP Solution Center Thread-Index: AcdEgn4TAVcfvs04QayTmIRGHodZTwACoipQAABSDJA= References: <1A629FEA23F9F14CAF0B8B3A5AA2FC29400EC5@daebe103.NOE.Nokia.com> <3C292CE901FC634693F24FB2DDC4D33202876A89@xmb-rtp-20d.amer.cisco.com> From: To: , , , , , X-OriginalArrivalTime: 30 Jan 2007 16:53:40.0975 (UTC) FILETIME=[31CB07F0:01C7448F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: Subject: [mpls] RE: [MPLS-OPS]: IP Solution Center 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="===============1136334890==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1136334890== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7448F.319A9064" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7448F.319A9064 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Williams, =20 Thanks, =20 Customer is interested in complete solution: Layer 3 MPLS VPN deployment Layer 2 MPLS VPN deployment MPLS Core Traffic Engineering Planning and Deployment QoS deployment MPLS Diagnostics - capable of diagnosing faults in MPLS VPN configuration =20 As we may resell, it is important feedback about other customers concerning if they are happy and got what was expected from the tool. I am sure you understand this. =20 Good to know about the customer with 130K nodes using it. Is there any public working paper about this or other customer?=20 =20 Br, Alaerte =20 ________________________________ From: ext Roger Williams (rogwilli) [mailto:rogwilli@cisco.com]=20 Sent: Tuesday, January 30, 2007 11:45 AM To: Vidali Alaerte (Nokia-NET/RioDeJaneiro); mpls@uu.net; mpls-ops@mplsrc.com; mpls@lists.ietf.org; cisco-nsp@puck.nether.net; mpls-ops@mplsrc.com Subject: RE: [MPLS-OPS]: IP Solution Center Alaerte, your question is very broad, too broad to answer effectively.=20 =20 ISC has a number of different capabilities, so your question could be more specific. =20 Very short list of ISC capabilities: Layer 3 (MPLS) VPN deployment Layer 2 (VLAN/ MetroE) VPN deployment MPLS Core Traffic Engineering Planning and Deployment Some QoS deployment, both link and VPN. MPLS Diagnostics - capable of diagnosing faults in MPLS VPN configuration =20 For what it is worth, arguably the largest SP in the US, with over 120k end points, uses ISC for VPN deployment, and this from a single server. This says something about robustness. =20 Roger Williams ________________________________ From: Alaerte.Vidali@nokia.com [mailto:Alaerte.Vidali@nokia.com]=20 Sent: Tuesday, January 30, 2007 10:23 AM To: mpls@uu.net; mpls-ops@mplsrc.com; mpls@lists.ietf.org; cisco-nsp@puck.nether.net; mpls-ops@mplsrc.com Subject: [MPLS-OPS]: IP Solution Center Hi,=20 Could you give your opinion about IP Solution Center 4.2?=20 (characteristics like robustness, correctness when converting actions to commands...)=20 Thanks,=20 Alaerte Gladston Vidali=20 ------_=_NextPart_001_01C7448F.319A9064 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IP Solution Center
Hi Williams,
 
Thanks,
 
Customer is interested in complete=20 solution:
Layer 3 MPLS VPN deployment
Layer 2 MPLS=20 VPN = deployment
MPLS Core Traffic Engineering Planning and=20 Deployment
QoS deployment
MPLS Diagnostics - capable of diagnosing faults = in MPLS VPN=20 configuration
 
As we=20 may resell, it is important feedback about other customers = concerning if=20 they are happy and got what was expected from the tool. I am sure you = understand=20 this.
 
Good=20 to know about the customer with 130K nodes using it. Is there any public = working=20 paper about this or other customer? 
 
Br,
Alaerte
 

From: ext Roger Williams (rogwilli)=20 [mailto:rogwilli@cisco.com]
Sent: Tuesday, January 30, 2007 = 11:45=20 AM
To: Vidali Alaerte (Nokia-NET/RioDeJaneiro); mpls@uu.net;=20 mpls-ops@mplsrc.com; mpls@lists.ietf.org; cisco-nsp@puck.nether.net;=20 mpls-ops@mplsrc.com
Subject: RE: [MPLS-OPS]: IP Solution=20 Center

Alaerte, your question is very broad, too broad to = answer=20 effectively.
 
ISC=20 has a number of different capabilities, so your question could be more=20 specific.
 
Very=20 short list of ISC capabilities:
Layer=20 3 (MPLS) VPN deployment
Layer=20 2 (VLAN/ MetroE) VPN deployment
MPLS=20 Core Traffic Engineering Planning and Deployment
Some=20 QoS deployment, both link and VPN.
MPLS=20 Diagnostics - capable of diagnosing faults in MPLS VPN=20 configuration
 
For=20 what it is worth, arguably the largest SP in the US, with over 120k end = points,=20 uses ISC for VPN deployment, and this from a single server. This says = something=20 about robustness.
 
Roger=20 Williams

From: Alaerte.Vidali@nokia.com=20 [mailto:Alaerte.Vidali@nokia.com]
Sent: Tuesday, January 30, = 2007=20 10:23 AM
To: mpls@uu.net; mpls-ops@mplsrc.com; = mpls@lists.ietf.org;=20 cisco-nsp@puck.nether.net; mpls-ops@mplsrc.com
Subject: = [MPLS-OPS]: IP=20 Solution Center

Hi,

Could you give your = opinion about IP=20 Solution Center 4.2?
(characteristics like robustness, correctness when converting = actions to=20 commands...)

Thanks, =
Alaerte Gladston = Vidali

------_=_NextPart_001_01C7448F.319A9064-- --===============1136334890== 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 --===============1136334890==-- From mpls-bounces@lists.ietf.org Tue Jan 30 11:55:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwGQ-0004ax-Go; Tue, 30 Jan 2007 11:55:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwGP-0004as-KZ for mpls@lists.ietf.org; Tue, 30 Jan 2007 11:55:21 -0500 Received: from omzesmtp01.mci.com ([199.249.17.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwGK-0007pT-Uj for mpls@lists.ietf.org; Tue, 30 Jan 2007 11:55:21 -0500 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JCO00FL3XNWLC@firewall.mci.com> for mpls@lists.ietf.org; Tue, 30 Jan 2007 16:55:14 +0000 (GMT) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQvzjn17933; Tue, 30 Jan 2007 16:55:00 +0000 (GMT) Received: by mail-control.ash.ops.us.uu.net id QQvzjn10748 for mpls-outgoing; Tue, 30 Jan 2007 16:54:48 +0000 (GMT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQvzjn10743 for ; Tue, 30 Jan 2007 16:54:40 +0000 (GMT) Received: from pmismtp01.mcilink.com by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pmismtp01.mcilink.com [166.37.158.161]) id l0UGsduN009668 for ; Tue, 30 Jan 2007 16:54:39 +0000 (GMT) Received: from pmismtp01.mcilink.com ([127.0.0.1]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JCO00LFQXN3P3@pmismtp01.mcilink.com> for mpls@uu.net; Tue, 30 Jan 2007 16:54:39 +0000 (GMT) Received: from pmmspam01.mcilink.com ([166.37.156.161]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JCO00LDWXN1C4@pmismtp01.mcilink.com> for mpls@uu.net; Tue, 30 Jan 2007 16:54:39 +0000 (GMT) Received: from omzesmtp02.mci.com (omzesmtp02.mci.com [199.249.17.9]) by pmmspam01.mcilink.com (8.13.1/8.13.1) with ESMTP id l0UGsXF1006632 for ; Tue, 30 Jan 2007 16:54:36 +0000 (GMT) Received: from omzesmtp02.mci.com ([127.0.0.1]) by firewall.mci.com (Iplanet MTA 5.2) with SMTP id <0JCO00GZXXMZZ3@firewall.mci.com> for mpls@uu.net; Tue, 30 Jan 2007 16:54:35 +0000 (GMT) Received: from mgw-ext14.nokia.com ([131.228.20.173]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTPS id <0JCO00HCUXMX10@firewall.mci.com> for mpls@uu.net; Tue, 30 Jan 2007 16:54:34 +0000 (GMT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0UGpDmc023130; Tue, 30 Jan 2007 18:51:35 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 18:53:58 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 10:53:40 -0600 Date: Tue, 30 Jan 2007 10:53:37 -0600 From: Alaerte.Vidali@nokia.com In-reply-to: <3C292CE901FC634693F24FB2DDC4D33202876A89@xmb-rtp-20d.amer.cisco.com> To: rogwilli@cisco.com, mpls@UU.NET, mpls-ops@mplsrc.com, mpls@lists.ietf.org, cisco-nsp@puck.nether.net, mpls-ops@mplsrc.com Message-id: <1A629FEA23F9F14CAF0B8B3A5AA2FC29400FC9@daebe103.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Precedence: bulk Thread-topic: [MPLS-OPS]: IP Solution Center Thread-index: AcdEgn4TAVcfvs04QayTmIRGHodZTwACoipQAABSDJA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Nokia-AV: Clean X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0 adultscore=0 adjust=0 reason=mlx engine=3.1.0-0701160000 definitions=main-0701300022 References: <1A629FEA23F9F14CAF0B8B3A5AA2FC29400EC5@daebe103.NOE.Nokia.com> <3C292CE901FC634693F24FB2DDC4D33202876A89@xmb-rtp-20d.amer.cisco.com> X-OriginalArrivalTime: 30 Jan 2007 16:53:40.0975 (UTC) FILETIME=[31CB07F0:01C7448F] X-Spam-Score: 0.2 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: Subject: [mpls] RE: [MPLS-OPS]: IP Solution Center X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0358486349==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0358486349== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C7448F.319A9064" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C7448F.319A9064 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Williams, =20 Thanks, =20 Customer is interested in complete solution: Layer 3 MPLS VPN deployment Layer 2 MPLS VPN deployment MPLS Core Traffic Engineering Planning and Deployment QoS deployment MPLS Diagnostics - capable of diagnosing faults in MPLS VPN configuration =20 As we may resell, it is important feedback about other customers concerning if they are happy and got what was expected from the tool. I am sure you understand this. =20 Good to know about the customer with 130K nodes using it. Is there any public working paper about this or other customer?=20 =20 Br, Alaerte =20 ________________________________ From: ext Roger Williams (rogwilli) [mailto:rogwilli@cisco.com]=20 Sent: Tuesday, January 30, 2007 11:45 AM To: Vidali Alaerte (Nokia-NET/RioDeJaneiro); mpls@uu.net; mpls-ops@mplsrc.com; mpls@lists.ietf.org; cisco-nsp@puck.nether.net; mpls-ops@mplsrc.com Subject: RE: [MPLS-OPS]: IP Solution Center Alaerte, your question is very broad, too broad to answer effectively.=20 =20 ISC has a number of different capabilities, so your question could be more specific. =20 Very short list of ISC capabilities: Layer 3 (MPLS) VPN deployment Layer 2 (VLAN/ MetroE) VPN deployment MPLS Core Traffic Engineering Planning and Deployment Some QoS deployment, both link and VPN. MPLS Diagnostics - capable of diagnosing faults in MPLS VPN configuration =20 For what it is worth, arguably the largest SP in the US, with over 120k end points, uses ISC for VPN deployment, and this from a single server. This says something about robustness. =20 Roger Williams ________________________________ From: Alaerte.Vidali@nokia.com [mailto:Alaerte.Vidali@nokia.com]=20 Sent: Tuesday, January 30, 2007 10:23 AM To: mpls@uu.net; mpls-ops@mplsrc.com; mpls@lists.ietf.org; cisco-nsp@puck.nether.net; mpls-ops@mplsrc.com Subject: [MPLS-OPS]: IP Solution Center Hi,=20 Could you give your opinion about IP Solution Center 4.2?=20 (characteristics like robustness, correctness when converting actions to commands...)=20 Thanks,=20 Alaerte Gladston Vidali=20 ------_=_NextPart_001_01C7448F.319A9064 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IP Solution Center
Hi Williams,
 
Thanks,
 
Customer is interested in complete=20 solution:
Layer 3 MPLS VPN deployment
Layer 2 MPLS=20 VPN = deployment
MPLS Core Traffic Engineering Planning and=20 Deployment
QoS deployment
MPLS Diagnostics - capable of diagnosing faults = in MPLS VPN=20 configuration
 
As we=20 may resell, it is important feedback about other customers = concerning if=20 they are happy and got what was expected from the tool. I am sure you = understand=20 this.
 
Good=20 to know about the customer with 130K nodes using it. Is there any public = working=20 paper about this or other customer? 
 
Br,
Alaerte
 

From: ext Roger Williams (rogwilli)=20 [mailto:rogwilli@cisco.com]
Sent: Tuesday, January 30, 2007 = 11:45=20 AM
To: Vidali Alaerte (Nokia-NET/RioDeJaneiro); mpls@uu.net;=20 mpls-ops@mplsrc.com; mpls@lists.ietf.org; cisco-nsp@puck.nether.net;=20 mpls-ops@mplsrc.com
Subject: RE: [MPLS-OPS]: IP Solution=20 Center

Alaerte, your question is very broad, too broad to = answer=20 effectively.
 
ISC=20 has a number of different capabilities, so your question could be more=20 specific.
 
Very=20 short list of ISC capabilities:
Layer=20 3 (MPLS) VPN deployment
Layer=20 2 (VLAN/ MetroE) VPN deployment
MPLS=20 Core Traffic Engineering Planning and Deployment
Some=20 QoS deployment, both link and VPN.
MPLS=20 Diagnostics - capable of diagnosing faults in MPLS VPN=20 configuration
 
For=20 what it is worth, arguably the largest SP in the US, with over 120k end = points,=20 uses ISC for VPN deployment, and this from a single server. This says = something=20 about robustness.
 
Roger=20 Williams

From: Alaerte.Vidali@nokia.com=20 [mailto:Alaerte.Vidali@nokia.com]
Sent: Tuesday, January 30, = 2007=20 10:23 AM
To: mpls@uu.net; mpls-ops@mplsrc.com; = mpls@lists.ietf.org;=20 cisco-nsp@puck.nether.net; mpls-ops@mplsrc.com
Subject: = [MPLS-OPS]: IP=20 Solution Center

Hi,

Could you give your = opinion about IP=20 Solution Center 4.2?
(characteristics like robustness, correctness when converting = actions to=20 commands...)

Thanks, =
Alaerte Gladston = Vidali

------_=_NextPart_001_01C7448F.319A9064-- --===============0358486349== 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 --===============0358486349==-- From ecfceadgec@carltas.com Wed Jan 31 00:18:48 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7rr-0005nV-FC; Wed, 31 Jan 2007 00:18:48 -0500 Received: from cpe-075-176-039-176.carolina.res.rr.com ([75.176.39.176] helo=home-pc.carolina.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC7rq-0005lr-7u; Wed, 31 Jan 2007 00:18:47 -0500 From: Michael To: Subject: Please see this letter Date: Wed, 31 Jan 2007 05:18:49 +0300 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4025 Encoding: 1 TEXT X-Spam-Score: 4.3 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 kill at least 89 in BaghdadTwin attacks.I thought I was shows all major networks an extremely guiltyIdol begins this week! ADVANCED GR OWING SY STEMS INC(AGWS.PK) share!!! This stock is really exciting!!! From the very beginning it occupied first places on market of shares! And for this moment this share continues to increase!!! It brings 150% of first day growth just for a few days!!! Hurry dont miss it!!! This statistics will help you to realize our suggestion: January 31th Price: 1.08$ You can get more information using your broker web-site! I was 12 years old I had a guidance going to be an architect,an extremely guiltywhen you find yourself cracking up uncontrollably.I had nokill at least 89 in BaghdadTwin attacks.Train cars derail, catch fire in KentuckyMassive fireABC, NBC, CBS & FOX Now Need fresh faces I was a kid, I was 12 years old I had a guidance going to be an architect,But seasons 1-5 have already counselor that convinced me that Idol special From norcru@mail2model.com Wed Jan 31 14:44:17 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLNR-0000Ln-D2 for mpls-archive@lists.ietf.org; Wed, 31 Jan 2007 14:44:17 -0500 Received: from adijon-152-1-63-172.w83-194.abo.wanadoo.fr ([83.194.190.172] helo=mail2model.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HCLNL-00077p-Fk for mpls-archive@lists.ietf.org; Wed, 31 Jan 2007 14:44:15 -0500 Message-ID: <01c74570$2cb6ce20$acbec253@marchal56tov7p> Reply-To: "Thomasina Vanvalkenburg" From: "Thomasina Vanvalkenburg" To: "Vencesla Hayter" Subject: Re: VIAxusGRA Date: Wed, 31 Jan 2007 20:44:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Antivirus: avast! (VPS 000709-1, 31/01/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 1.8 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Good day, Viav_gra $1, 80 Ciav_lis $3, 00 Leviv_tra $3, 35 http://www.progenyid!.com ( Important Remove "!" ) -- impatiently, rearranging the pile of cushions they had used for the Banishing Spell, which Flitwick had left in a cabinet. Just try and fall backward!