From Stokoe@fotodeldia.com Mon Oct 01 02:46:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcF2g-0002Us-1J for ospf-archive@megatron.ietf.org; Mon, 01 Oct 2007 02:46:10 -0400 Received: from p508c3813.dip0.t-ipconnect.de ([80.140.56.19] helo=[80.140.12.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcF2f-0000eW-Bk for ospf-archive@megatron.ietf.org; Mon, 01 Oct 2007 02:46:09 -0400 Received: from gehirn ([168.177.35.41] helo=gehirn) by [80.140.12.37] ( sendmail 8.13.3/8.13.1) with esmtpa id 1LgTTm-000BWS-yF for ospf-archive@megatron.ietf.org; Sun, 30 Sep 2007 18:46:35 -1200 Message-ID: <000b01c803f6$c1a2a8c0$250c8c50@gehirn> From: "tinga Stokoe" To: Subject: detalsna Date: Sun, 30 Sep 2007 18:46:12 -1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C80392.2C6DC8C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0005_01C80392.2C6DC8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day ospf-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 deraepra deuteriu detceles derike-t ------=_NextPart_000_0005_01C80392.2C6DC8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good day ospf-archive
Alert to all investors!
Look at D-M-X-C!
5-day price: ~$0.50
Check it at 31.09.2007
deraepra
deuteriu
detceles
derike-t
------=_NextPart_000_0005_01C80392.2C6DC8C0-- From prasad@ltindia.com Mon Oct 01 06:50:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcIrS-00014f-Io for ospf-archive@megatron.ietf.org; Mon, 01 Oct 2007 06:50:50 -0400 Received: from [88.232.173.224] (helo=88.232.173.224) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcIrR-0007fY-Ie for ospf-archive@megatron.ietf.org; Mon, 01 Oct 2007 06:50:50 -0400 Received: from [88.232.173.224] by dns.ltindia.com; Mon, 01 Oct 2007 10:50:15 +0000 Message-ID: <000801c80418$05c35ee8$2a4bb685@bekwdvry> From: "hans-peter campion" To: Subject: Double or Triple your portfolio in 1 month! Date: Mon, 01 Oct 2007 09:02:52 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.7 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hello Investor We are pleased to invite you to an excellent investment opportunity. Make your money work today and tomorrow you will start to receive profits. In connection with a mortgage crisis in the real estate of the USA market, bank deposits became risky; investments in investment funds do not provide the desired return. Stock markets fall. Stop depend on the dollar rate and invest your money in a high profit financial instruments. Since the beginning of the year the American currency has lost about 15%, and it continues to fall. For The United States stock market is not the best time. Europe is also facing an economic crisis. In the difficult times of economic chaos you have to look for other investment instruments. Our investment company offers high profit investments with maximum impact. We are working on the market since 2005 and during the work we confirmed our impeccable reputation with regular payments and the performance of our profitability. Our clients receive 350% annual returns. We accept any amount of investments, and you can invest a small amount so as to see the quality of our work. We make our profit by day-trading on the American stock and bonds market. So, we are ready to provide individual Trading Platform for our clients. And you have an excellent opportunity to try your forces in the day-trading. Our best specialists will be pleased to provide you with investment advice and help you to choose an investment portfolio, which will be fully compatible with the chosen level of risk and return. If you are interested in this proposal please contact your personal manager to: MelChapmanYE@gmail.com If you received this message in error please send a blank email to: EmmanuelLottQI@gmail.com From cyprian@telia.com Mon Oct 01 06:50:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcIrV-00015t-9S for ospf-archive@lists.ietf.org; Mon, 01 Oct 2007 06:50:53 -0400 Received: from [189.12.167.11] (helo=18912167011.user.veloxzone.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcIrN-0005rO-Qg for ospf-archive@lists.ietf.org; Mon, 01 Oct 2007 06:50:53 -0400 Received: from [189.12.167.11] by ns02.savvis.net; Tue, 06 Aug 2002 03:05:25 +0000 Message-ID: <000801c23cf6$032e6cd2$606d01b7@kbeefsok> From: "demetre evie" To: Subject: Best investment advices. We can help you to build your portfolio Date: Tue, 06 Aug 2002 01:18:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hello Investor We are pleased to invite you to an excellent investment opportunity. Make your money work today and tomorrow you will start to receive profits. In connection with a mortgage crisis in the real estate of the USA market, bank deposits became risky; investments in investment funds do not provide the desired return. Stock markets fall. Stop depend on the dollar rate and invest your money in a high profit financial instruments. Since the beginning of the year the American currency has lost about 15%, and it continues to fall. For The United States stock market is not the best time. Europe is also facing an economic crisis. In the difficult times of economic chaos you have to look for other investment instruments. Our investment company offers high profit investments with maximum impact. We are working on the market since 2005 and during the work we confirmed our impeccable reputation with regular payments and the performance of our profitability. Our clients receive 350% annual returns. We accept any amount of investments, and you can invest a small amount so as to see the quality of our work. We make our profit by day-trading on the American stock and bonds market. So, we are ready to provide individual Trading Platform for our clients. And you have an excellent opportunity to try your forces in the day-trading. Our best specialists will be pleased to provide you with investment advice and help you to choose an investment portfolio, which will be fully compatible with the chosen level of risk and return. If you are interested in this proposal please contact your personal manager to: HarryMcdowellVW@gmail.com If you received this message in error please send a blank email to: BoydAllisonVH@gmail.com From ospf-bounces@ietf.org Mon Oct 01 07:35:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcJUx-0001e5-QN; Mon, 01 Oct 2007 07:31:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcJUw-0001dz-Tl for ospf@ietf.org; Mon, 01 Oct 2007 07:31:38 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcJUr-0007HG-LL for ospf@ietf.org; Mon, 01 Oct 2007 07:31:38 -0400 X-IronPort-AV: E=Sophos;i="4.21,216,1188770400"; d="scan'208,217";a="154567972" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Oct 2007 13:31:06 +0200 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 l91BV5Qv031735; Mon, 1 Oct 2007 13:31:05 +0200 Received: from [64.103.65.194] (dhcp-gpk02-vlan300-64-103-65-194.cisco.com [64.103.65.194]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l91BUtFp020729; Mon, 1 Oct 2007 11:30:56 GMT Message-ID: <4700DA6E.7000602@cisco.com> Date: Mon, 01 Oct 2007 12:30:54 +0100 From: mike shand User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: HeinerHummel@aol.com Subject: Re: [OSPF] ospf-lite welcomes comments References: In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3844; t=1191238265; x=1192102265; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshand@cisco.com; z=From:=20mike=20shand=20 |Subject:=20Re=3A=20[OSPF]=20ospf-lite=20welcomes=20comments |Sender:=20; bh=sgaXydAA3pTR9I5sUETDdn4uDzqXuctguODJ/iUQV0U=; b=V1fnJQGefMmCBVk5KELVoF5B4acoyinUzrhUJ5ij6n2E5dvNLHswDtgnHN5YxIz5dup35O8U fSr4ZqgV7L6Yf0JriWxdqj+VUjB5eIk2CXJIJyww7q4vLTRpkiXeZAQ2; Authentication-Results: ams-dkim-1; header.From=mshand@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -2.3 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1373208794==" Errors-To: ospf-bounces@ietf.org --===============1373208794== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit HeinerHummel@aol.com wrote:
In einer eMail vom 27.09.2007 16:58:46 Westeuropäische Normalzeit schreibt acee@redback.com:
Are you familiar with the work being done in the rtgwg? For example: 

   draft-ietf-rtgwg-ipfrr-spec-base-09.txt

 
Acee,
thank you for your quick response. No, I am not familiar with this rtgwg-draft.
Having just read the first "inequality  1 loop-free criterion" and having drawn a chess board network to visualize it, I must say: it is just not true. "<=" would be correct at a first glance.
I think you must have misunderstood something. If dist_opt(N,D) = dist_opt(N,S)+dist_opt(S,D) then it is absolutely clear that N is NOT a loop free Alternate for S, since any traffic N receives from S has an equal probability of being forwarded BACK to S because there is an ECMP from N to D, one branch of which traverses S.

The requirement for an LFA is that it MUST NOT cause a loop under any circumstances. Clearly in the ECMP case it won't for some traffic, but it WILL for other traffic.

But perhaps this discussion should be taking place in RTGWG rather than OSPF.

    Mike

But that is by far not the limit. I can distinguisch between guaranteed loop-free routes, loop-endangered routes which needs a little bit of caution, loop-endangered routes which needs some more intensive care, and I can identify any next hop which definitively enters a dead end.
 
If you look at www.hummel-research.de and look at my example network you will see that all links are, by means of my algorithm, converted into arrows which LOOP-FREE direct to the red destination node.
It takes some more labor as to safely use arrows from head to tail. In the end the proper relevant routing information could be assigned to each adjacent link, from "best-hop" to "dead end entrance".
 
But I will continue to read this rtgwg-draft.
 
Heiner
 
 

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf

--===============1373208794== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1373208794==-- From ospf-bounces@ietf.org Mon Oct 01 08:03:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcJyf-00048y-Oq; Mon, 01 Oct 2007 08:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcJyd-0003wZ-5u for ospf@ietf.org; Mon, 01 Oct 2007 08:02:19 -0400 Received: from imo-d20.mx.aol.com ([205.188.139.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcJyS-00089B-IA for ospf@ietf.org; Mon, 01 Oct 2007 08:02:15 -0400 Received: from HeinerHummel@aol.com by imo-d20.mx.aol.com (mail_out_v38_r9.3.) id c.c93.15c64712 (29679); Mon, 1 Oct 2007 08:01:08 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Mon, 1 Oct 2007 08:01:08 EDT Subject: Re: [OSPF] ospf-lite welcomes comments To: mshand@cisco.com MIME-Version: 1.0 X-Mailer: AOL 9.0 VR sub 52 X-Spam-Flag: NO X-Spam-Score: 1.8 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0054598534==" Errors-To: ospf-bounces@ietf.org --===============0054598534== Content-Type: multipart/alternative; boundary="-----------------------------1191240068" -------------------------------1191240068 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 01.10.2007 13:31:16 Westeurop=E4ische Normalzeit schreibt= =20 mshand@cisco.com: I think you must have misunderstood something. If dist_opt(N,D) =3D =20 dist_opt(N,S)+dist_opt(S,D) then it is absolutely clear that N is NOT a loop= free=20 Alternate for S, since any traffic N receives from S has an equal probabili= ty of=20 being forwarded BACK to S because there is an ECMP from N to D, one branch=20= of=20 which traverses S. Do you agree that this possibility is excluded by not forwarding any packet=20= =20 to precisely that neighbor node from which the package has been received ? =20 Heiner =20 -------------------------------1191240068 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 01.10.2007 13:31:16 Westeurop=E4ische Normalzeit sch= reibt=20 mshand@cisco.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>I think=20 you must have misunderstood something. If dist_opt(N,D) =3D=20 dist_opt(N,S)+dist_opt(S,D) then it is absolutely clear that N is NOT a lo= op=20 free Alternate for S, since any traffic N receives from S has an equal=20 probability of being forwarded BACK to S because there is an ECMP from N t= o D,=20 one branch of which traverses S.
Do you agree that this possibility is excluded by not forwarding any pa= cket=20 to precisely that neighbor node from which the package has been received ?
 
Heiner
-------------------------------1191240068-- --===============0054598534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0054598534==-- From germen_gvh@cneinc.org Tue Oct 02 00:28:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZNR-0001Eb-S3 for ospf-archive@lists.ietf.org; Tue, 02 Oct 2007 00:28:57 -0400 Received: from [208.188.98.118] (helo=adsl-208-188-98-118.iiat.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcZNO-0004Gf-JT for ospf-archive@lists.ietf.org; Tue, 02 Oct 2007 00:28:55 -0400 Received: from qus ([46.131.211.226]) by adsl-208-188-98-118.iiat.org (8.13.3/8.13.3) with SMTP id l924V0DJ072878; Mon, 1 Oct 2007 23:31:00 -0500 Message-ID: <4701C8F5.1010000@cneinc.org> Date: Mon, 1 Oct 2007 23:28:37 -0500 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: The time is now Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de New Designs Hit The Street, Same Hot Look, But Nearly Twice As Big. Fearless International Inc. F R L E . O B $0.20 Don't be fooled, this one is brewing a huge market busting trend. Don't take your eye off this for the next few days. Today's heavy trading is only the beginning. Get ahead on this one and grab FRLE Tuesday morning. From mike19147@hisottawa.ca Tue Oct 02 10:00:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IciIq-0006UO-7n for ospf-archive@lists.ietf.org; Tue, 02 Oct 2007 10:00:48 -0400 Received: from [62.118.52.130] (helo=jyfyatx) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IciIl-0002qx-Qu for ospf-archive@lists.ietf.org; Tue, 02 Oct 2007 10:00:45 -0400 Received: from odx ([166.59.56.231]) by jyfyatx with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Oct 2007 18:00:36 +0400 Message-ID: <002601c804fc$9b9ee290$e7383ba6@odx> From: To: Subject: Fearless 44 hits the street Date: Tue, 2 Oct 2007 18:00:36 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 1.7 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Finally we get first look at The "Fearless 44" Fearless International FRLE.OB Price: $0.20 Our job is to alert you to the big ones, this has all the makings, hot product, huge media coverage, and now volume is moving. Don't take your eye off this for the next few days. Big volume will be the soup of the day for this company from now on. We can not stress how crucial timing is on this, grab it fast. From ospf-bounces@ietf.org Tue Oct 02 12:57:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icl0P-0006R0-IM; Tue, 02 Oct 2007 12:53:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icl0O-0006Pq-9X for ospf@ietf.org; Tue, 02 Oct 2007 12:53:56 -0400 Received: from zaphod.je-ju.net ([145.99.151.210]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icl0N-0001Y9-Pv for ospf@ietf.org; Tue, 02 Oct 2007 12:53:56 -0400 Received: from doc.je-ju.net (doc.je-ju.net [145.99.151.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zaphod.je-ju.net (Postfix) with ESMTP id B2C9C2E033; Tue, 2 Oct 2007 18:53:52 +0200 (CEST) Message-ID: <470277AE.5090701@science.uva.nl> Date: Tue, 02 Oct 2007 18:54:06 +0200 From: Jeroen van der Ham User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: ospf@ietf.org, adrian@olddog.co.uk X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [OSPF] [Fwd: Question about TLV, subTLVs and length] X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hello, While working on implementing some features for GMPLS the question below came up. I sent this to the ccamp list, where Adrian Farrel answered my question, but also suggested that this issue should be taken to this list, where someone might actually be able to do something about it. :) The relevant part of his answer is pasted below the message. -------- Original Message -------- Subject: Question about TLV, subTLVs and length Date: Tue, 02 Oct 2007 17:36:40 +0200 From: Jeroen van der Ham To: ccamp@ops.ietf.org Hello, The current text defining the length of TLVs is the following (from RFC 4970): > The Length field defines the length of the value portion in octets > (thus a TLV with no value portion would have a length of zero). The > TLV is padded to four-octet alignment; padding is not included in the > length field (so a three octet value would have a length of three, > but the total size of the TLV would be eight octets). Nested TLVs > are also 32-bit aligned. For example, a one-byte value would have > the length field set to 1, and three octets of padding would be added > to the end of the value portion of the TLV. Unrecognized types are > ignored. To me this seems very unclear about the handling of lengths of subTLVs, and their impact on the length of the upper TLV. The padding after a subTLV should of course not be included in the length of that subTLV. But should that padding be included in the length of the (enclosing) TLV? I would think that the padding for the subTLV should be included in the length of the enclosing TLV. Most of the time it is possible to deduce the length, but if more than 4 bytes of padding are added, you run into problems. I really couldn't find a definitive answer on this anywhere, it may be worth defining this somewhere, as the current wording is not clear on this issue. Adrian Farrel wrote: > Hah! Nice question. > > Consider that the L field has two purposes. > 1. To define the actual length of the V field > 2. To allow a parser to step over the whole TLV without decoding it > > In order to perform the second, the operation on a TLV with multiple sub-TLVs it is essential that the L of the parent TLV includes all of the padding implicit in the sub-TLVs. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Oct 02 17:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcoxS-0007xU-MK; Tue, 02 Oct 2007 17:07:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcoxR-0007xI-Fc for ospf@ietf.org; Tue, 02 Oct 2007 17:07:09 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcoxL-00061e-7J for ospf@ietf.org; Tue, 02 Oct 2007 17:07:09 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B4127D9BEB3; Tue, 2 Oct 2007 14:06:52 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20136-07; Tue, 2 Oct 2007 14:06:52 -0700 (PDT) Received: from [ZJ??O??IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 2F567D9BEB2; Tue, 2 Oct 2007 14:06:50 -0700 (PDT) In-Reply-To: <470277AE.5090701@science.uva.nl> References: <470277AE.5090701@science.uva.nl> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7073F280-8838-4124-9060-AE027E0554E4@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] [Fwd: Question about TLV, subTLVs and length] Date: Tue, 2 Oct 2007 17:05:18 -0400 To: Jeroen van der Ham X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: CCAMP List , OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Jeroen, IMHO, it doesn't make sense for anything but the padded length of the sub-TLVs to be included in the length of the subsuming TLV. This both satisfies the salient OSPF design point of maintaining 4-bytes alignment while still allowing the actual length of the constituent sub-TLV values to be determined. Thanks, Acee On Oct 2, 2007, at 12:54 PM, Jeroen van der Ham wrote: > Hello, > > While working on implementing some features for GMPLS the question > below > came up. I sent this to the ccamp list, where Adrian Farrel > answered my > question, but also suggested that this issue should be taken to this > list, where someone might actually be able to do something about > it. :) > > The relevant part of his answer is pasted below the message. > > -------- Original Message -------- > Subject: Question about TLV, subTLVs and length > Date: Tue, 02 Oct 2007 17:36:40 +0200 > From: Jeroen van der Ham > To: ccamp@ops.ietf.org > > Hello, > > The current text defining the length of TLVs is the following (from > RFC > 4970): > >> The Length field defines the length of the value portion in octets >> (thus a TLV with no value portion would have a length of >> zero). The >> TLV is padded to four-octet alignment; padding is not included >> in the >> length field (so a three octet value would have a length of three, >> but the total size of the TLV would be eight octets). Nested TLVs >> are also 32-bit aligned. For example, a one-byte value would have >> the length field set to 1, and three octets of padding would be >> added >> to the end of the value portion of the TLV. Unrecognized types >> are >> ignored. > > To me this seems very unclear about the handling of lengths of > subTLVs, > and their impact on the length of the upper TLV. > The padding after a subTLV should of course not be included in the > length of that subTLV. But should that padding be included in the > length > of the (enclosing) TLV? > > I would think that the padding for the subTLV should be included in > the > length of the enclosing TLV. Most of the time it is possible to deduce > the length, but if more than 4 bytes of padding are added, you run > into > problems. > > I really couldn't find a definitive answer on this anywhere, it may be > worth defining this somewhere, as the current wording is not clear on > this issue. > > Adrian Farrel wrote: >> Hah! Nice question. >> >> Consider that the L field has two purposes. >> 1. To define the actual length of the V field >> 2. To allow a parser to step over the whole TLV without decoding it >> >> In order to perform the second, the operation on a TLV with >> multiple sub-TLVs it is essential that the L of the parent TLV >> includes all of the padding implicit in the sub-TLVs. > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From NitashaBriscar@aareschlucht.ch Tue Oct 02 20:51:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsS4-0007H4-Lf for ospf-archive@megatron.ietf.org; Tue, 02 Oct 2007 20:51:00 -0400 Received: from [81.185.200.200] (helo=[86.70.27.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcsS3-0005kh-4G for ospf-archive@megatron.ietf.org; Tue, 02 Oct 2007 20:51:00 -0400 Received: from pc by aareschlucht.ch with ASMTP id 50480DA5 for ; Wed, 3 Oct 2007 02:51:38 +0200 Received: from pc ([110.129.129.56]) by aareschlucht.ch with ESMTP id 0B4443EDFCC1 for ; Wed, 3 Oct 2007 02:51:38 +0200 Message-ID: <000b01c80557$858308f0$171b4656@pc> From: "Nitasha Briscar" To: Subject: elmntapa Date: Wed, 3 Oct 2007 02:51:24 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C80568.490BD8F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000778-1, 02/10/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.1 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C80568.490BD8F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://cosyinn.com/ Evening ospf-archive A bigger penis can give you a massive confidence boost Nitasha Briscar ------=_NextPart_000_0004_01C80568.490BD8F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://cosyinn.com/
Evening ospf-archive
A bigger penis can give you a massive = confidence boost
Nitasha Briscar
------=_NextPart_000_0004_01C80568.490BD8F0-- From senkorei@orsayphysics.com Wed Oct 03 02:45:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icxyd-0004ZU-V8 for ospf-archive@lists.ietf.org; Wed, 03 Oct 2007 02:44:59 -0400 Received: from [190.42.127.120] (helo=frcty) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcxyS-0001OB-VF for ospf-archive@lists.ietf.org; Wed, 03 Oct 2007 02:44:50 -0400 Received: from zczs ([103.73.102.54]) by frcty with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Oct 2007 01:44:25 -0500 Message-ID: <001201c80588$d6b61f10$36664967@zczs> From: To: Subject: Take a look at this and tell me what you think Date: Wed, 3 Oct 2007 01:44:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Hottest boat on the market. Fearless International (FRLE) $0.20 Fearless has already pulled down 10 mill in orders. Wed is the day for F R L E From marchant@arbenina.ru Wed Oct 03 04:10:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IczJP-0002dt-Qz for ospf-archive@megatron.ietf.org; Wed, 03 Oct 2007 04:10:31 -0400 Received: from host130-160-dynamic.9-79-r.retail.telecomitalia.it ([79.9.160.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IczJC-0003q1-AC for ospf-archive@megatron.ietf.org; Wed, 03 Oct 2007 04:10:24 -0400 Received: by 10.235.209.42 with SMTP id udQWmjmeQAezS; Wed, 3 Oct 2007 10:10:18 +0200 (GMT) Received: by 192.168.160.144 with SMTP id fYgdPUclfyKSYI.8689516120117; Wed, 3 Oct 2007 10:10:16 +0200 (GMT) Message-ID: <000d01c80594$d2fc7c00$82a0094f@computer> From: "Araldo marchant" To: Subject: remision Date: Wed, 3 Oct 2007 10:10:13 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C805A5.96854C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C805A5.96854C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.cosyinn.com/ How it is going ospf-archive A Genuine Way To Permanently Enlarge Your Penis At Home Araldo marchant ------=_NextPart_000_0007_01C805A5.96854C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.cosyinn.com/
How it is going ospf-archive
A Genuine Way To Permanently Enlarge Your = Penis At Home
Araldo marchant
------=_NextPart_000_0007_01C805A5.96854C00-- From ospf-bounces@ietf.org Wed Oct 03 04:57:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id00I-0003Ub-AG; Wed, 03 Oct 2007 04:54:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id00H-0003Ft-3B for ospf@ietf.org; Wed, 03 Oct 2007 04:54:49 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id006-0004uN-Sz for ospf@ietf.org; Wed, 03 Oct 2007 04:54:45 -0400 Received: by ug-out-1314.google.com with SMTP id u2so245415uge for ; Wed, 03 Oct 2007 01:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=fSMlF8bW5dywSzxl8pFhkEYJngm4UM+0pqEapMPaPd8=; b=hf+lhgKTE7ns1glZH7uktpFksyOcHi8Sk3sZenTckQkAkka2dYuAWg1mHCkyREq361d/qwyWd/qT6w9iFtIkDYHKCdOpwwq79bbwgE1Q3GVeMjVjngVry3Z6EcTEN6OVn18fbedIdAy20sOxrTkWg/QNDnGJtqib8krimgGAbx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EjMm3TbL6lVtx6RCnvBResmfo+KG3bQ3d/WXGhjrHnr8YqKRJnQHGuHLPS9g9JdihrzmZIBrYLZ+g9qZdP3NxIzu8kaN4GA2mAApirExE7G700LlTTpU0YkbHrUGfxB9aIaZDLccTSudieXPlS4Ogkfm5ZS5IROwdUP5BN8rpQQ= Received: by 10.67.103.12 with SMTP id f12mr211234ugm.1191401639886; Wed, 03 Oct 2007 01:53:59 -0700 (PDT) Received: by 10.67.88.1 with HTTP; Wed, 3 Oct 2007 01:53:59 -0700 (PDT) Message-ID: Date: Wed, 3 Oct 2007 14:23:59 +0530 From: "Santosh P K" To: "ospf@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [OSPF] OSPFv2 option bit X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi All, I was going through the option bits of OSPFv2. I have couple of doubts on this please clarify. In RFC 2328 in A.2 it says +----------------------------------------------+ | * | * | DC | EA | N/P | MC | E | * | +----------------------------------------------+ That is Value Description ------ ---------------- 0x01 Reserved 0x02 E-bit 0x04 MC-bit 0x08 N/P-bit 0x10 EA 0x20 DC-bit 0x40 Reserved 0x80 Reserved In RFC 4813 OSPF Link-Local Signaling sec 2.1 it says +---+---+---+---+---+---+---+---+ | * | O | DC| L |N/P| MC| E | * | +---+---+---+---+---+---+---+-+-+ That is Value Description ------ ---------------- 0x01 Reserved 0x02 E-bit 0x04 MC-bit 0x08 N/P-bit 0x10 L-bit 0x20 DC-bit 0x40 O-bit 0x80 Reserved In IANA document (http://www.iana.org/assignments/ospfv2-parameters) last updated 2007-08-14 says Value Description Reference ------ ---------------- --------- 0x01 MT-bit [RFC4915] 0x02 E-bit [RFC2328] 0x04 MC-bit [RFC1584] 0x08 N/P-bit [RFC3101] 0x10 Reserved 0x20 DC-bit [RFC1793] 0x40 O-bit [RFC2370] 0x80 DN-bit [RFC4576] In all the three documents there is a conflict for bit 0x10, RFC 2328 uses it as EA bit , RFC 4813 uses it as L bit and IANA document says its reserved. Out of all these three which one shall i consider. Thanks and regards Santosh P K _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 03 05:30:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0Ws-0001KO-9T; Wed, 03 Oct 2007 05:28:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0Wq-0001IY-U6 for ospf@ietf.org; Wed, 03 Oct 2007 05:28:28 -0400 Received: from no-more.cisco.com ([64.104.206.251] helo=av-tac-apt.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id0Wp-0001nq-WF for ospf@ietf.org; Wed, 03 Oct 2007 05:28:28 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-apt.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l939SOn15826; Wed, 3 Oct 2007 19:28:25 +1000 (EST) Received: from [144.254.14.251] (dhcp-peg2-vl21-144-254-14-251.cisco.com [144.254.14.251]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l939SKI06117; Wed, 3 Oct 2007 11:28:21 +0200 (CEST) Message-ID: <470360B4.1020108@cisco.com> Date: Wed, 03 Oct 2007 11:28:20 +0200 From: Anton Smirnov Organization: Cisco Systems, Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Santosh P K Subject: Re: [OSPF] OSPFv2 option bit References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: "ospf@ietf.org" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org > its reserved. Out of all these three which one shall i consider. Consider exactly for which purpose? Education, implementation, new standard proposal? The answer depends. EA (External Attribute) never took off the ground, you can disregard it. LLS is in Experimental state now, not Standards track, that's the reason why it is not listed in IANA assignment. Thanks, Anton Santosh P K wrote: > Hi All, > I was going through the option bits of OSPFv2. I have couple of > doubts on this please clarify. > > > In RFC 2328 in A.2 it says > +----------------------------------------------+ > | * | * | DC | EA | N/P | MC | E | * | > +----------------------------------------------+ > That is > Value Description > ------ ---------------- > 0x01 Reserved > 0x02 E-bit > 0x04 MC-bit > 0x08 N/P-bit > 0x10 EA > 0x20 DC-bit > 0x40 Reserved > 0x80 Reserved > > > > In RFC 4813 OSPF Link-Local Signaling sec 2.1 it says > +---+---+---+---+---+---+---+---+ > | * | O | DC| L |N/P| MC| E | * | > +---+---+---+---+---+---+---+-+-+ > > That is > Value Description > ------ ---------------- > 0x01 Reserved > 0x02 E-bit > 0x04 MC-bit > 0x08 N/P-bit > 0x10 L-bit > 0x20 DC-bit > 0x40 O-bit > 0x80 Reserved > > > > In IANA document (http://www.iana.org/assignments/ospfv2-parameters) > last updated 2007-08-14 says > > > Value Description Reference > ------ ---------------- --------- > 0x01 MT-bit [RFC4915] > 0x02 E-bit [RFC2328] > 0x04 MC-bit [RFC1584] > 0x08 N/P-bit [RFC3101] > 0x10 Reserved > 0x20 DC-bit [RFC1793] > 0x40 O-bit [RFC2370] > 0x80 DN-bit [RFC4576] > > > In all the three documents there is a conflict for bit 0x10, RFC 2328 > uses it as EA bit , RFC 4813 uses it as L bit and IANA document says > its reserved. Out of all these three which one shall i consider. > > > Thanks and regards > Santosh P K > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 03 05:31:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0Zq-0006RI-31; Wed, 03 Oct 2007 05:31:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0Zo-0006EO-Fw for ospf@ietf.org; Wed, 03 Oct 2007 05:31:32 -0400 Received: from zaphod.je-ju.net ([145.99.151.210]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id0Zo-0001tx-4H for ospf@ietf.org; Wed, 03 Oct 2007 05:31:32 -0400 Received: from nb-vdham.science.uva.nl (nb-vdham.science.uva.nl [146.50.22.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zaphod.je-ju.net (Postfix) with ESMTP id 5C0002E01B; Wed, 3 Oct 2007 11:31:27 +0200 (CEST) Message-ID: <47036172.3000107@science.uva.nl> Date: Wed, 03 Oct 2007 11:31:30 +0200 From: Jeroen van der Ham User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] [Fwd: Question about TLV, subTLVs and length] References: <470277AE.5090701@science.uva.nl> <7073F280-8838-4124-9060-AE027E0554E4@redback.com> In-Reply-To: <7073F280-8838-4124-9060-AE027E0554E4@redback.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Acee Lindem wrote: > Hi Jeroen, > IMHO, it doesn't make sense for anything but the padded length of the > sub-TLVs to be included in the length of the subsuming TLV. This both > satisfies the salient OSPF design point of maintaining 4-bytes alignment > while still allowing the actual length of the constituent sub-TLV values > to be determined. I completely agree. However, the actual text in the RFCs about the lengths of TLVs are not so clear on the matter. Particularly the line "The TLV is padded to four-octet alignment; padding is not included in the length field" can be misleading when using subTLVs and their padding. Jeroen. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 03 05:35:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0ch-0003Yh-H7; Wed, 03 Oct 2007 05:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0cf-0003YR-LB for ospf@ietf.org; Wed, 03 Oct 2007 05:34:29 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id0cZ-00064E-Aq for ospf@ietf.org; Wed, 03 Oct 2007 05:34:29 -0400 Received: by ug-out-1314.google.com with SMTP id u2so252422uge for ; Wed, 03 Oct 2007 02:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=guSKoIrP1zwgXp+p+vmE1+OD33YWnnCiPPzv2gHEIJs=; b=RzD48DTA+4IOpWUPJ+wHPr2+PVYrt+rRtrbu1GKcaiZR+4BfgZ4SLMCx6TwPNcyAyV1Sv/eSHqoOwW/E6QWNkSGDAaZPnDXSfoMsxJv4rGzolpPhqe6jCd0r1NWZt38ZfKw1aZ3VbeQvXuHGmCgID87O6vKONT4b1A2O5A8zBvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VGI+08hMZsINyLGoHOCUGGttiZGJfp5rVIgQgQWO/LaVcXsUgFWy6s/zgbBkCknZs0r6RRd+3m2z7sj2+pEfezhcDNwp8qH1ZAQXVtyNMi4D/5sWfDPzrMFSTOB6pvlIxMuItaOR1vdN6OinoDE08ROv2xBjqT2pjwuJrU+P/Zw= Received: by 10.66.225.17 with SMTP id x17mr243404ugg.1191404050480; Wed, 03 Oct 2007 02:34:10 -0700 (PDT) Received: by 10.67.88.1 with HTTP; Wed, 3 Oct 2007 02:34:10 -0700 (PDT) Message-ID: Date: Wed, 3 Oct 2007 15:04:10 +0530 From: "Santosh P K" To: "Anton Smirnov" Subject: Re: [OSPF] OSPFv2 option bit In-Reply-To: <470360B4.1020108@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <470360B4.1020108@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: "ospf@ietf.org" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Thanks a lot Smirnov :) On 10/3/07, Anton Smirnov wrote: > > its reserved. Out of all these three which one shall i consider. > > Consider exactly for which purpose? Education, implementation, new > standard proposal? The answer depends. > > EA (External Attribute) never took off the ground, you can disregard it. > LLS is in Experimental state now, not Standards track, that's the reason > why it is not listed in IANA assignment. > > Thanks, > > Anton > > > > Santosh P K wrote: > > Hi All, > > I was going through the option bits of OSPFv2. I have couple of > > doubts on this please clarify. > > > > > > In RFC 2328 in A.2 it says > > +----------------------------------------------+ > > | * | * | DC | EA | N/P | MC | E | * | > > +----------------------------------------------+ > > That is > > Value Description > > ------ ---------------- > > 0x01 Reserved > > 0x02 E-bit > > 0x04 MC-bit > > 0x08 N/P-bit > > 0x10 EA > > 0x20 DC-bit > > 0x40 Reserved > > 0x80 Reserved > > > > > > > > In RFC 4813 OSPF Link-Local Signaling sec 2.1 it says > > +---+---+---+---+---+---+---+---+ > > | * | O | DC| L |N/P| MC| E | * | > > +---+---+---+---+---+---+---+-+-+ > > > > That is > > Value Description > > ------ ---------------- > > 0x01 Reserved > > 0x02 E-bit > > 0x04 MC-bit > > 0x08 N/P-bit > > 0x10 L-bit > > 0x20 DC-bit > > 0x40 O-bit > > 0x80 Reserved > > > > > > > > In IANA document (http://www.iana.org/assignments/ospfv2-parameters) > > last updated 2007-08-14 says > > > > > > Value Description Reference > > ------ ---------------- --------- > > 0x01 MT-bit [RFC4915] > > 0x02 E-bit [RFC2328] > > 0x04 MC-bit [RFC1584] > > 0x08 N/P-bit [RFC3101] > > 0x10 Reserved > > 0x20 DC-bit [RFC1793] > > 0x40 O-bit [RFC2370] > > 0x80 DN-bit [RFC4576] > > > > > > In all the three documents there is a conflict for bit 0x10, RFC 2328 > > uses it as EA bit , RFC 4813 uses it as L bit and IANA document says > > its reserved. Out of all these three which one shall i consider. > > > > > > Thanks and regards > > Santosh P K > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 03 05:41:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0j2-0002Se-C3; Wed, 03 Oct 2007 05:41:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0iy-0002Em-Be for ospf@ietf.org; Wed, 03 Oct 2007 05:41:01 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id0is-0006Jx-23 for ospf@ietf.org; Wed, 03 Oct 2007 05:41:00 -0400 Received: by ug-out-1314.google.com with SMTP id u2so253674uge for ; Wed, 03 Oct 2007 02:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=cVBX5X5xJn+T8iKU9JWix5gDUzc6abxXsdgYefa5p4k=; b=AanGHcwXdDJPeNktKmmmMSdSfKiTLODWzxRBf4rpz4mLwiKBDruf18JJtzLfz0yJCHKJkEiOBudn+q79bQ8zEnXO3Avo3h1Vrb0bQZLKudjvhmWpo49NKg2hjCYteqvaGDx1ooza9DV4Mj2HhOY0Ptk+T3H3he9KQYekkYK3U58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oxnetJIBKyViX0/ODjewv05zdF4D2mG687XbGEhE40kH2G+gVZ7JctCvf/ODQDPiUyTeMfPJNepR3XEE/ObvV2BIIc0Hlv/WnOLc51JJdYEDpU844c4m0XgctFqa2mjeAX7DBhqTTEMTCosWybBjQ9CP1vsJDkRm33n5U5nPB+c= Received: by 10.67.115.2 with SMTP id s2mr246512ugm.1191404442364; Wed, 03 Oct 2007 02:40:42 -0700 (PDT) Received: by 10.67.88.1 with HTTP; Wed, 3 Oct 2007 02:40:42 -0700 (PDT) Message-ID: Date: Wed, 3 Oct 2007 15:10:42 +0530 From: "Santosh P K" To: "Anton Smirnov" Subject: Re: [OSPF] OSPFv2 option bit In-Reply-To: <470360B4.1020108@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <470360B4.1020108@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "ospf@ietf.org" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Consider for implementation. On 10/3/07, Anton Smirnov wrote: > > its reserved. Out of all these three which one shall i consider. > > Consider exactly for which purpose? Education, implementation, new > standard proposal? The answer depends. > > EA (External Attribute) never took off the ground, you can disregard it. > LLS is in Experimental state now, not Standards track, that's the reason > why it is not listed in IANA assignment. > > Thanks, > > Anton > > > > Santosh P K wrote: > > Hi All, > > I was going through the option bits of OSPFv2. I have couple of > > doubts on this please clarify. > > > > > > In RFC 2328 in A.2 it says > > +----------------------------------------------+ > > | * | * | DC | EA | N/P | MC | E | * | > > +----------------------------------------------+ > > That is > > Value Description > > ------ ---------------- > > 0x01 Reserved > > 0x02 E-bit > > 0x04 MC-bit > > 0x08 N/P-bit > > 0x10 EA > > 0x20 DC-bit > > 0x40 Reserved > > 0x80 Reserved > > > > > > > > In RFC 4813 OSPF Link-Local Signaling sec 2.1 it says > > +---+---+---+---+---+---+---+---+ > > | * | O | DC| L |N/P| MC| E | * | > > +---+---+---+---+---+---+---+-+-+ > > > > That is > > Value Description > > ------ ---------------- > > 0x01 Reserved > > 0x02 E-bit > > 0x04 MC-bit > > 0x08 N/P-bit > > 0x10 L-bit > > 0x20 DC-bit > > 0x40 O-bit > > 0x80 Reserved > > > > > > > > In IANA document (http://www.iana.org/assignments/ospfv2-parameters) > > last updated 2007-08-14 says > > > > > > Value Description Reference > > ------ ---------------- --------- > > 0x01 MT-bit [RFC4915] > > 0x02 E-bit [RFC2328] > > 0x04 MC-bit [RFC1584] > > 0x08 N/P-bit [RFC3101] > > 0x10 Reserved > > 0x20 DC-bit [RFC1793] > > 0x40 O-bit [RFC2370] > > 0x80 DN-bit [RFC4576] > > > > > > In all the three documents there is a conflict for bit 0x10, RFC 2328 > > uses it as EA bit , RFC 4813 uses it as L bit and IANA document says > > its reserved. Out of all these three which one shall i consider. > > > > > > Thanks and regards > > Santosh P K > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 03 05:49:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0qH-0003k5-Tu; Wed, 03 Oct 2007 05:48:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0qG-0003e0-D7 for ospf@ietf.org; Wed, 03 Oct 2007 05:48:32 -0400 Received: from no-more.cisco.com ([64.104.206.251] helo=av-tac-apt.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id0qF-0006at-MC for ospf@ietf.org; Wed, 03 Oct 2007 05:48:32 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-apt.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l939mBj09649; Wed, 3 Oct 2007 19:48:11 +1000 (EST) Received: from [144.254.14.251] (dhcp-peg2-vl21-144-254-14-251.cisco.com [144.254.14.251]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l939m8I19311; Wed, 3 Oct 2007 11:48:09 +0200 (CEST) Message-ID: <47036558.9060700@cisco.com> Date: Wed, 03 Oct 2007 11:48:08 +0200 From: Anton Smirnov Organization: Cisco Systems, Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen van der Ham Subject: Re: [OSPF] [Fwd: Question about TLV, subTLVs and length] References: <470277AE.5090701@science.uva.nl> <7073F280-8838-4124-9060-AE027E0554E4@redback.com> <47036172.3000107@science.uva.nl> In-Reply-To: <47036172.3000107@science.uva.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Jeroen, if sub-TLV is in the middle of TLV's value (i.e. there exists other sub-TLVs after it) then sub-TLVs padding must be counted in TLVs value. I don't think document's wording leaves any ambiguity here. If sub-TLV is the last one in TLV then it is not really important if you will include padding into TLV length or not. If you include - it will be counted as sub-TLV padding and TLV itself ends on word boundary. If you don't - it is padding of TLV which didn't end on word boundary. Either way, any implementation on receiver conforming to document's wording should be able to correctly unpack sub-TLVs and find beginning of the next TLV. Thanks, Anton Jeroen van der Ham wrote: > Acee Lindem wrote: >> Hi Jeroen, >> IMHO, it doesn't make sense for anything but the padded length of the >> sub-TLVs to be included in the length of the subsuming TLV. This both >> satisfies the salient OSPF design point of maintaining 4-bytes alignment >> while still allowing the actual length of the constituent sub-TLV values >> to be determined. > > I completely agree. However, the actual text in the RFCs about the > lengths of TLVs are not so clear on the matter. > Particularly the line "The TLV is padded to four-octet alignment; > padding is not included in the length field" can be misleading when > using subTLVs and their padding. > > Jeroen. > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 03 09:53:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id4bE-0002BZ-O4; Wed, 03 Oct 2007 09:49:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id4bC-00028O-PK for ospf@ietf.org; Wed, 03 Oct 2007 09:49:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id4bC-00023p-Bo for ospf@ietf.org; Wed, 03 Oct 2007 09:49:14 -0400 X-IronPort-AV: E=Sophos;i="4.21,224,1188802800"; d="scan'208";a="229695243" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2007 06:49:13 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l93DnDGH006605; Wed, 3 Oct 2007 06:49:13 -0700 Received: from akr-lnx (akr-lnx.cisco.com [171.71.54.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l93DnD0X023187; Wed, 3 Oct 2007 13:49:13 GMT Date: Wed, 3 Oct 2007 06:49:13 -0700 (PDT) From: Abhay Roy To: Santosh P K Subject: Re: [OSPF] OSPFv2 option bit In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2454; t=1191419353; x=1192283353; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=akr@cisco.com; z=From:=20Abhay=20Roy=20 |Subject:=20Re=3A=20[OSPF]=20OSPFv2=20option=20bit |Sender:=20; bh=IsS6NNN+JOfne2b9TRbqqMEV6fy3DyVXFK+5SJyNR0w=; b=REhR6aGybJ1Kz4Zd4yW8cSBe9aStY+T5JwAtjyOLEQEY+ZQi1Mbka1T8FFF2/NeiBGqbItZP aVYdHWCEXa5M2wOIFEQAXo6AFEWkbfE7ZsAdXWVtSDQHrM1NKilLR92O; Authentication-Results: sj-dkim-2; header.From=akr@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: "ospf@ietf.org" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Santosh, There is also the respin of RFC4813 (which includes OSPFv3), which is on standards track. Once we get to handling IANA action from draft-ietf-ospf-lls-03.txt, IANA will allocate bit 0x10 for L-bit. Regards, -Abhay On 10/03/07+0530 at 2:23pm, Santosh P K writes: > Hi All, > I was going through the option bits of OSPFv2. I have couple of > doubts on this please clarify. > > > In RFC 2328 in A.2 it says > +----------------------------------------------+ > | * | * | DC | EA | N/P | MC | E | * | > +----------------------------------------------+ > That is > Value Description > ------ ---------------- > 0x01 Reserved > 0x02 E-bit > 0x04 MC-bit > 0x08 N/P-bit > 0x10 EA > 0x20 DC-bit > 0x40 Reserved > 0x80 Reserved > > > > In RFC 4813 OSPF Link-Local Signaling sec 2.1 it says > +---+---+---+---+---+---+---+---+ > | * | O | DC| L |N/P| MC| E | * | > +---+---+---+---+---+---+---+-+-+ > > That is > Value Description > ------ ---------------- > 0x01 Reserved > 0x02 E-bit > 0x04 MC-bit > 0x08 N/P-bit > 0x10 L-bit > 0x20 DC-bit > 0x40 O-bit > 0x80 Reserved > > > > In IANA document (http://www.iana.org/assignments/ospfv2-parameters) > last updated 2007-08-14 says > > > Value Description Reference > ------ ---------------- --------- > 0x01 MT-bit [RFC4915] > 0x02 E-bit [RFC2328] > 0x04 MC-bit [RFC1584] > 0x08 N/P-bit [RFC3101] > 0x10 Reserved > 0x20 DC-bit [RFC1793] > 0x40 O-bit [RFC2370] > 0x80 DN-bit [RFC4576] > > > In all the three documents there is a conflict for bit 0x10, RFC 2328 > uses it as EA bit , RFC 4813 uses it as L bit and IANA document says > its reserved. Out of all these three which one shall i consider. > > > Thanks and regards > Santosh P K > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 03 10:01:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id4mJ-000663-Vd; Wed, 03 Oct 2007 10:00:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id4mJ-00065b-Da for ospf@ietf.org; Wed, 03 Oct 2007 10:00:43 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id4mI-0002SW-Rq for ospf@ietf.org; Wed, 03 Oct 2007 10:00:43 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 67AC0484E56; Wed, 3 Oct 2007 07:00:42 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12395-05; Wed, 3 Oct 2007 07:00:42 -0700 (PDT) Received: from [????N???p??IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 719B3484E4E; Wed, 3 Oct 2007 07:00:39 -0700 (PDT) In-Reply-To: <470360B4.1020108@cisco.com> References: <470360B4.1020108@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83E99BE8-67D5-4A34-A609-447E5624413E@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] OSPFv2 option bit Date: Wed, 3 Oct 2007 09:59:05 -0400 To: Anton Smirnov X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Santosh P K , "ospf@ietf.org" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Anton, You are correct. If we ever chose to respin RFC 2328, we'd deprecate the EA-Bit since it was never implemented or deployed. With respect to LLS, it is in on our recently revamped charter to be advanced as a WG standards track document. The new version covers OSPFv3 as well. Thanks, Acee On Oct 3, 2007, at 5:28 AM, Anton Smirnov wrote: > > its reserved. Out of all these three which one shall i consider. > > Consider exactly for which purpose? Education, implementation, new > standard proposal? The answer depends. > > EA (External Attribute) never took off the ground, you can > disregard it. > LLS is in Experimental state now, not Standards track, that's the > reason why it is not listed in IANA assignment. > > Thanks, > > Anton > > > > Santosh P K wrote: >> Hi All, >> I was going through the option bits of OSPFv2. I have >> couple of >> doubts on this please clarify. >> In RFC 2328 in A.2 it says >> +----------------------------------------------+ >> | * | * | DC | EA | N/P | MC | E | * | >> +----------------------------------------------+ >> That is >> Value Description >> ------ ---------------- >> 0x01 Reserved >> 0x02 E-bit >> 0x04 MC-bit >> 0x08 N/P-bit >> 0x10 EA >> 0x20 DC-bit >> 0x40 Reserved >> 0x80 Reserved >> In RFC 4813 OSPF Link-Local Signaling sec 2.1 it says >> +---+---+---+---+---+---+---+---+ >> | * | O | DC| L |N/P| MC| E | * | >> +---+---+---+---+---+---+---+-+-+ >> That is >> Value Description >> ------ ---------------- >> 0x01 Reserved >> 0x02 E-bit >> 0x04 MC-bit >> 0x08 N/P-bit >> 0x10 L-bit >> 0x20 DC-bit >> 0x40 O-bit >> 0x80 Reserved >> In IANA document (http://www.iana.org/assignments/ospfv2-parameters) >> last updated 2007-08-14 says >> Value Description Reference >> ------ ---------------- --------- >> 0x01 MT-bit [RFC4915] >> 0x02 E-bit [RFC2328] >> 0x04 MC-bit [RFC1584] >> 0x08 N/P-bit [RFC3101] >> 0x10 Reserved >> 0x20 DC-bit [RFC1793] >> 0x40 O-bit [RFC2370] >> 0x80 DN-bit [RFC4576] >> In all the three documents there is a conflict for bit 0x10, RFC >> 2328 >> uses it as EA bit , RFC 4813 uses it as L bit and IANA document says >> its reserved. Out of all these three which one shall i consider. >> Thanks and regards >> Santosh P K >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 03 10:03:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id4ok-0007fw-C1; Wed, 03 Oct 2007 10:03:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id4oi-0007YS-D4 for ospf@ietf.org; Wed, 03 Oct 2007 10:03:12 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id4oc-0006LO-7h for ospf@ietf.org; Wed, 03 Oct 2007 10:03:12 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id CCC8EA27BB2; Wed, 3 Oct 2007 07:03:00 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12676-07; Wed, 3 Oct 2007 07:03:00 -0700 (PDT) Received: from [????N???p??????$IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id C7140A27BAF; Wed, 3 Oct 2007 07:02:59 -0700 (PDT) In-Reply-To: <47036172.3000107@science.uva.nl> References: <470277AE.5090701@science.uva.nl> <7073F280-8838-4124-9060-AE027E0554E4@redback.com> <47036172.3000107@science.uva.nl> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4FA2D541-83FE-4EB7-8730-6A5BFD618071@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] [Fwd: Question about TLV, subTLVs and length] Date: Wed, 3 Oct 2007 10:01:25 -0400 To: Jeroen van der Ham X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org On Oct 3, 2007, at 5:31 AM, Jeroen van der Ham wrote: > Acee Lindem wrote: >> Hi Jeroen, >> IMHO, it doesn't make sense for anything but the padded length of the >> sub-TLVs to be included in the length of the subsuming TLV. This both >> satisfies the salient OSPF design point of maintaining 4-bytes >> alignment >> while still allowing the actual length of the constituent sub-TLV >> values >> to be determined. > > I completely agree. However, the actual text in the RFCs about the > lengths of TLVs are not so clear on the matter. > Particularly the line "The TLV is padded to four-octet alignment; > padding is not included in the length field" can be misleading when > using subTLVs and their padding. I'll clarify this is the OSPFv3 Traffic Engineering draft. Thanks, Acee > > Jeroen. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From Jody.laumann@newyorkstoneco.com Wed Oct 03 22:22:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdGLm-0000dK-7Z for ospf-archive@megatron.ietf.org; Wed, 03 Oct 2007 22:22:06 -0400 Received: from cust-02-5286b428.adsl.scarlet.nl ([82.134.180.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdGLZ-000322-CJ for ospf-archive@megatron.ietf.org; Wed, 03 Oct 2007 22:22:00 -0400 Received: by 10.48.83.49 with SMTP id NcaYIhOSNPCEd; Thu, 4 Oct 2007 04:22:32 +0200 (GMT) Received: by 192.168.46.100 with SMTP id ybtalZWBwOnvEq.7748348003209; Thu, 4 Oct 2007 04:22:30 +0200 (GMT) Message-ID: <000d01c8062d$6859a6e0$28b48652@janniethuis> From: "Jody laumann" To: Subject: noyzirok Date: Thu, 4 Oct 2007 04:22:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8063E.2BE276E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0006_01C8063E.2BE276E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.eatmebay.com/ Morning ospf-archive The demand for these pills is so high .. prices will go up soon Jody laumann ------=_NextPart_000_0006_01C8063E.2BE276E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.eatmebay.com/
Morning ospf-archive
The demand for these pills is so high .. = prices will go=20 up soon
Jody laumann
------=_NextPart_000_0006_01C8063E.2BE276E0-- From Ryan886@kastley.co.uk Thu Oct 04 14:58:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVu8-0006dm-FV for ospf-archive@megatron.ietf.org; Thu, 04 Oct 2007 14:58:36 -0400 Received: from e178186223.adsl.alicedsl.de ([85.178.186.223]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdVu2-0003kY-Pg for ospf-archive@megatron.ietf.org; Thu, 04 Oct 2007 14:58:33 -0400 Received: by 10.165.19.51 with SMTP id kcwfUryopZZZy; Thu, 4 Oct 2007 20:58:35 +0200 (GMT) Received: by 192.168.232.41 with SMTP id YKXmtyIKLlSizE.6011316763457; Thu, 4 Oct 2007 20:58:33 +0200 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 4 Oct 2007 20:58:30 +0200 To: ospf-archive@megatron.ietf.org From: "Ryan Herr" Subject: cowlin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Yo man ospf-archive Rated #1 for effectiveness and value Ryan Herr http://www.stickmaze.com/ From lajoiergc@nsts.inter-tel.com Fri Oct 05 04:20:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdiQ1-0005K8-SW for ospf-archive@megatron.ietf.org; Fri, 05 Oct 2007 04:20:21 -0400 Received: from athedsl-189057.home.otenet.gr ([85.74.58.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdiQ0-0002VL-SN for ospf-archive@megatron.ietf.org; Fri, 05 Oct 2007 04:20:21 -0400 Received: by 10.25.108.72 with SMTP id vEUMbXLHpyOeX; Fri, 5 Oct 2007 11:20:18 +0300 (GMT) Received: by 192.168.197.135 with SMTP id YMsqBfEeaLHbXV.0488337988784; Fri, 5 Oct 2007 11:20:16 +0300 (GMT) Message-ID: Date: Fri, 5 Oct 2007 11:20:13 +0300 From: "koko lajoie" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: tipakise Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Nice to meet you ospf-archive A slightly soft erection is not only troublesome to you, but it's less visually exciting and less stimulating to your partner koko lajoie http://www.supraekeyl.com/ From bulten@uaeu.ac.ae Fri Oct 05 06:37:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdkYX-0002U1-Px for ospf-archive@lists.ietf.org; Fri, 05 Oct 2007 06:37:17 -0400 Received: from acls111.neoplus.adsl.tpnet.pl ([83.10.120.111]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IdkYM-000807-8O for ospf-archive@lists.ietf.org; Fri, 05 Oct 2007 06:37:12 -0400 Received: from bzk ([143.51.147.188]) by acls111.neoplus.adsl.tpnet.pl with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Oct 2007 12:41:14 +0200 Message-ID: <470614CA.1020701@uaeu.ac.ae> Date: Fri, 5 Oct 2007 12:41:14 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: The Updater Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Huge wave were made with Fearless, shares prices rocket. Fearless International Inc. (F R L E . O B) $0.25 UP 31.26 % Huge day today for Fearless yachts as heavy trading turns to increased share prices. These kind of numbers draw a crowd and tomorrow this will begin exploding. Be ready to get in early, this will take off at open. From ianbuckles@eso.e-burg.ru Fri Oct 05 06:38:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdkZF-0003xl-HG for ospf-archive@megatron.ietf.org; Fri, 05 Oct 2007 06:38:01 -0400 Received: from acls111.neoplus.adsl.tpnet.pl ([83.10.120.111]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IdkZB-00081H-VY for ospf-archive@megatron.ietf.org; Fri, 05 Oct 2007 06:37:59 -0400 Received: from xinbs ([35.56.156.116]) by acls111.neoplus.adsl.tpnet.pl with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Oct 2007 12:42:15 +0200 Message-ID: <47061507.6010806@eso.e-burg.ru> Date: Fri, 5 Oct 2007 12:42:15 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: This one is pulling away from the dock Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Fearless opens up the throttle as share go through the roof. Fearless International (F R L E) $0.25 UP 31.63 % Huge prices increases backed by week long trading is the order of the day for Fearless International. Friday will be pushed now as market makers see the trend going into place. Set your alarm clock early Friday, this will not linger after today.s numbers, get in fast. From LaFantlmeuk@one-to-oneinstitute.org Sat Oct 06 01:29:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie2EF-0000J3-FD for ospf-archive@megatron.ietf.org; Sat, 06 Oct 2007 01:29:31 -0400 Received: from user-514de958.l4.c1.dsl.pol.co.uk ([81.77.233.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ie2E8-0001QJ-TV for ospf-archive@megatron.ietf.org; Sat, 06 Oct 2007 01:29:31 -0400 Received: from BEN1 ([120.185.102.135] helo=BEN1) by user-514de958.l4.c1.dsl.pol.co.uk ( sendmail 8.13.3/8.13.1) with esmtpa id 1ECVDZ-000SWE-uc for ospf-archive@megatron.ietf.org; Sat, 6 Oct 2007 06:29:55 +0100 Message-ID: <000501c807d9$df8e4600$58e94d51@BEN1> From: "Raman LaFant" To: Subject: uohukot Date: Sat, 6 Oct 2007 06:29:31 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C807E2.4152AE00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C807E2.4152AE00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://stasuzuki.com/ Good morning ospf-archive The manster system is a definite plus to a man's confidence Raman LaFant ------=_NextPart_000_0005_01C807E2.4152AE00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://stasuzuki.com/
Good morning ospf-archive
The manster system is a definite plus to a = man's confidence
Raman LaFant
------=_NextPart_000_0005_01C807E2.4152AE00-- From wl@evandillon.com Sat Oct 06 05:41:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie6A4-00036O-79 for ospf-archive@megatron.ietf.org; Sat, 06 Oct 2007 05:41:28 -0400 Received: from [78.84.221.37] (helo=imis.apollo.lv) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ie69x-0007mN-2i for ospf-archive@megatron.ietf.org; Sat, 06 Oct 2007 05:41:28 -0400 Received: from [78.84.221.37] by bluekudu.com; Sat, 6 Oct 2007 12:01:24 +0200 Message-ID: <01c807ff$da6b2910$25dd544e@wl> From: "Vanessa Ramey" To: Subject: Gain a monolithic body part Ron Date: Sat, 6 Oct 2007 12:01:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 0.1 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 have a huge cock Roseann http://reffrance.com From raymakersote@chubu.to Sat Oct 06 08:13:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie8XP-000213-Ok for ospf-archive@megatron.ietf.org; Sat, 06 Oct 2007 08:13:43 -0400 Received: from p54a405c7.dip0.t-ipconnect.de ([84.164.5.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ie8XK-0004EI-Ry for ospf-archive@megatron.ietf.org; Sat, 06 Oct 2007 08:13:39 -0400 Received: by 10.63.197.118 with SMTP id UbZIFbTNSzECF; Sat, 6 Oct 2007 14:13:41 +0200 (GMT) Received: by 192.168.156.225 with SMTP id PyqTWlSRihygSj.0325690504481; Sat, 6 Oct 2007 14:13:39 +0200 (GMT) Message-ID: <000b01c80812$52a556a0$c705a454@gernoty5xd7qni> From: "Carrie raymakers" To: Subject: lirbmu Date: Sat, 6 Oct 2007 14:13:36 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C80823.162E26A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0004_01C80823.162E26A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.mldating.com/ Hi ospf-archive Penis enlargement is very important for a man who wants better sex life Carrie raymakers ------=_NextPart_000_0004_01C80823.162E26A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.mldating.com/
Hi ospf-archive
Penis enlargement is very important for a man = who wants=20 better sex life
Carrie raymakers
------=_NextPart_000_0004_01C80823.162E26A0-- From Pillageocc@gzxinyi.com.cn Sat Oct 06 20:57:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeKT0-0005ey-Lb for ospf-archive@megatron.ietf.org; Sat, 06 Oct 2007 20:57:58 -0400 Received: from [83.230.169.134] (helo=[83.230.169.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeKSn-0006K6-GW for ospf-archive@megatron.ietf.org; Sat, 06 Oct 2007 20:57:46 -0400 Received: from TYLER ([173.135.149.163]:13951 "EHLO TYLER" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [83.230.169.154] with ESMTP id S22YVQGLNMVGSNYX (ORCPT ); Sun, 7 Oct 2007 02:57:30 +0200 Date: Sun, 7 Oct 2007 02:57:02 +0200 From: "Tri Pillage" Reply-To: "Tri Pillage" Message-ID: <336575649588.274616505983@gzxinyi.com.cn> To: Subject: revelaar MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 4.0 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hello ospf-archive The demand for these pills is so high .. prices will go up soon Tri Pillage http://muias.com/ From hgdmlaw@kofree.com Sun Oct 07 09:43:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeWPQ-0004W2-Ad for ospf-archive@lists.ietf.org; Sun, 07 Oct 2007 09:43:04 -0400 Received: from [125.93.189.133] (helo=[125.93.189.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeWPO-0006wz-6F for ospf-archive@lists.ietf.org; Sun, 07 Oct 2007 09:43:04 -0400 Received: from [125.93.189.133] by mail.kofree.com; , 7 Oct 2007 21:21:12 +0800 Message-ID: <01c808e4$ee3c8b10$85bd5d7d@hgdmlaw> From: "Annabelle Hanks" To: Subject: 100mg x 90 pills Date: , 7 Oct 2007 21:21:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 100mg x 90 pills http://picktook.com From gibsonm@compuserve.com Sun Oct 07 21:17:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IehFr-000297-OY for ospf-archive@megatron.ietf.org; Sun, 07 Oct 2007 21:17:55 -0400 Received: from pool-71-183-219-141.nycmny.fios.verizon.net ([71.183.219.141]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IehFf-0006az-In for ospf-archive@megatron.ietf.org; Sun, 07 Oct 2007 21:17:49 -0400 Received: from utqb ([51.197.123.170]) by pool-71-183-219-141.nycmny.fios.verizon.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 7 Oct 2007 21:17:23 -0400 Message-ID: <001801c80948$fae6e3b0$aa7bc533@utqb> From: To: Subject: We're ready to move. Date: Sun, 7 Oct 2007 21:17:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Huge news expected on Monday for FRLE. Fearless International (f r L E) Current: $0.21 Fearless International has certainly been a Cinderella story in the boating market this year. A small company that brought in world renowned Porsche Design Studios to design their new line of luxury yachts has taken the word by storm, sending waves all the way to the investment market. Huge news this week is expected to make those waves even bigger, providing amazing returns for the savvy investors who have gotten aboard this hot new yacht. We all know there is a best time to get in on an investment, well Monday first thing is it for FRLE. From Kami891@TattooedSingles.com Sun Oct 07 22:12:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iei6b-00011k-Ux for ospf-archive@megatron.ietf.org; Sun, 07 Oct 2007 22:12:25 -0400 Received: from host-84-222-185-179.cust-adsl.tiscali.it ([84.222.185.179] helo=[84.222.174.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iei6b-0005lh-4a for ospf-archive@megatron.ietf.org; Sun, 07 Oct 2007 22:12:25 -0400 Received: from dio ([189.103.10.33] helo=dio) by [84.222.174.141] ( sendmail 8.13.3/8.13.1) with esmtpa id 1iiJRo-000CJG-eV for ospf-archive@megatron.ietf.org; Mon, 8 Oct 2007 04:12:59 +0200 Message-ID: <000d01c80950$acf61060$8daede54@dio> From: "Kami Nijjar" To: Subject: monaadin Date: Mon, 8 Oct 2007 04:12:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C80961.707EE060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C80961.707EE060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://picchus.com/ Hi there ospf-archive its the size of ones penis that determines success Kami Nijjar ------=_NextPart_000_0009_01C80961.707EE060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://picchus.com/
Hi there ospf-archive
its the size of ones penis that determines = success
Kami Nijjar
------=_NextPart_000_0009_01C80961.707EE060-- From cjordan@ebay.com Mon Oct 08 08:44:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ierya-0007hQ-MK for ospf-archive@lists.ietf.org; Mon, 08 Oct 2007 08:44:48 -0400 Received: from [212.175.188.242] (helo=iwphro) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IeryZ-0005Ku-9s for ospf-archive@lists.ietf.org; Mon, 08 Oct 2007 08:44:48 -0400 Received: from ynd ([177.76.169.234]) by iwphro with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 15:44:43 +0300 Message-ID: <470A263B.8030101@ebay.com> Date: Mon, 8 Oct 2007 15:44:43 +0300 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: come get it Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Finally get all your game free online. Come on in! http://83.83.36.98/ From klorton@3sr.com Tue Oct 09 05:07:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfB3V-0004pQ-9c for ospf-archive@lists.ietf.org; Tue, 09 Oct 2007 05:07:09 -0400 Received: from [85.105.160.15] (helo=dsl.static.85-105-40975.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfB3M-0007Ii-TR for ospf-archive@lists.ietf.org; Tue, 09 Oct 2007 05:07:05 -0400 Received: from rcj ([45.55.186.147]) by dsl.static.85-105-40975.ttnet.net.tr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 12:05:48 +0300 Message-ID: <470B446C.4050004@3sr.com> Date: Tue, 9 Oct 2007 12:05:48 +0300 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: cool arcade games Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 What can we say, we got free games. over 1000 of them. check it out! http://72.228.51.98/ From takomaru@op.pl Tue Oct 09 05:07:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfB3s-0005I2-8X for ospf-archive@megatron.ietf.org; Tue, 09 Oct 2007 05:07:32 -0400 Received: from [85.105.160.15] (helo=dsl.static.85-105-40975.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfB3p-0007LG-S9 for ospf-archive@megatron.ietf.org; Tue, 09 Oct 2007 05:07:32 -0400 Received: from gttnr ([61.172.93.116]) by dsl.static.85-105-40975.ttnet.net.tr with Microsoft SMTPSVC(5.0.2195.5329); Tue, 9 Oct 2007 12:07:20 +0300 Message-ID: <470B44C8.7080504@op.pl> Date: Tue, 9 Oct 2007 12:07:20 +0300 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: Something for free..... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.3 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Over a 1000 games for free. Come check it out. http://69.223.68.77/ From jen@vgcafe.net Tue Oct 09 06:10:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfC2z-0002hi-Oa for ospf-archive@lists.ietf.org; Tue, 09 Oct 2007 06:10:41 -0400 Received: from [213.181.227.22] (helo=auc227-22.aucegypt.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfC2s-0000ix-F0 for ospf-archive@lists.ietf.org; Tue, 09 Oct 2007 06:10:36 -0400 Received: from [213.181.227.22] by mail-incoming2.gate.com; Tue, 9 Oct 2007 12:30:57 +0200 Message-ID: <01c80a5f$7aca5370$16e3b5d5@jen> From: "Jon Rodrigues" To: Subject: sizeable rod for Reginald Date: Tue, 9 Oct 2007 12:30:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.1 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 incur a gargantuan erectile organ Eugenio http://lieslyrics.com From talkingjusticetalking@dial.pipex.com Tue Oct 09 13:43:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfJ6u-0004rL-A2 for ospf-archive@lists.ietf.org; Tue, 09 Oct 2007 13:43:12 -0400 Received: from [122.169.129.252] (helo=ABTS-AP-dynamic-252.129.169.122.airtelbroadband.in) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfJ6f-00060o-R1 for ospf-archive@lists.ietf.org; Tue, 09 Oct 2007 13:42:59 -0400 Received: from kpgwc ([191.96.118.187]) by ABTS-AP-dynamic-252.129.169.122.airtelbroadband.in with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 23:08:41 +0530 Message-ID: <470BBCA1.2050108@dial.pipex.com> Date: Tue, 9 Oct 2007 23:08:41 +0530 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: did you get your copy yet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -99.9 (---------------------------------------------------) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Get on board and get all your free games in one place. http://200.89.157.164/ From maja@bbulletinmarkets.com Tue Oct 09 13:43:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfJ7B-0005Xu-0F for ospf-archive@megatron.ietf.org; Tue, 09 Oct 2007 13:43:29 -0400 Received: from [122.169.129.252] (helo=ABTS-AP-dynamic-252.129.169.122.airtelbroadband.in) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfJ74-00062O-7y for ospf-archive@megatron.ietf.org; Tue, 09 Oct 2007 13:43:23 -0400 Received: from nwf ([76.237.35.91]) by ABTS-AP-dynamic-252.129.169.122.airtelbroadband.in with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Oct 2007 23:09:34 +0530 Message-ID: <470BBCD6.3030807@bbulletinmarkets.com> Date: Tue, 9 Oct 2007 23:09:34 +0530 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: HOT Games for real players Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Come get your free games. Over 1000 to choose from! http://80.96.113.88/ From fgotopo@shinbiro.com Tue Oct 09 21:34:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfQSW-0000O3-9L for ospf-archive@lists.ietf.org; Tue, 09 Oct 2007 21:34:00 -0400 Received: from [201.230.144.7] (helo=client-201.230.144.7.speedy.net.pe) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfQSP-0003xC-Jh for ospf-archive@lists.ietf.org; Tue, 09 Oct 2007 21:33:55 -0400 Received: from pcr ([198.43.204.221]) by client-201.230.144.7.speedy.net.pe with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Oct 2007 20:33:46 -0500 Message-ID: <470C2BFA.6030705@shinbiro.com> Date: Tue, 9 Oct 2007 20:33:46 -0500 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: cool arcade games Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 All the games you will ever want to play in one program. http://190.18.192.60/ From ospf-bounces@ietf.org Tue Oct 09 22:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRSw-0007ww-EZ; Tue, 09 Oct 2007 22:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRSv-0007wG-Bm for ospf@ietf.org; Tue, 09 Oct 2007 22:38:29 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfRSp-0005oz-Lp for ospf@ietf.org; Tue, 09 Oct 2007 22:38:29 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPO00LYBCMJWW@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 10 Oct 2007 10:37:31 +0800 (CST) Received: from M55527 ([10.111.12.79]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPO003KFCMIL3@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 10 Oct 2007 10:37:31 +0800 (CST) Date: Wed, 10 Oct 2007 10:37:14 +0800 From: Mach Chen Subject: Re: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt To: Peng He Message-id: <0JPO003KICMIL3@szxga03-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: CCAMP List , OSPF List , Vishwas Manral X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Peng, Sorry for the late response(Just return from long national holidays) On 2007-10-03, at 10:33:31 Peng He wrote: >Hello Mach, > >Just be curious about the following: >>>3. Add the missing part about that the local ASBR SHOULD do a >"proxy" advertisement for the backward of an inter-AS TE link; > >What do you mean by "the backward of an inter-AS TE link"? Does that >mean that local ASBR would advertise TE info about the incoming >inter-AS link(s)? Thanks. Yes, due to there is no OSPF adjacency running on the inter-AS link, and some implements(CSPF) will do a two-way check before using the link for path computation, so the local ASBR should advertise the TE info of the inter-AS TE link from the view of the remote ASBR. > >Regards, >Peng > Best regards, Mach Chen _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Oct 09 22:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRSb-0007HG-2A; Tue, 09 Oct 2007 22:38:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRSa-0007Gt-58 for ospf@ietf.org; Tue, 09 Oct 2007 22:38:08 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfRSZ-0001Kw-6L for ospf@ietf.org; Tue, 09 Oct 2007 22:38:08 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPO000QJCMC37@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 10 Oct 2007 10:37:25 +0800 (CST) Received: from M55527 ([10.111.12.79]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPO006MCCMB60@szxgFrom ospf-bounces@ietf.org Tue Oct 09 22:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRSw-0007ww-EZ; Tue, 09 Oct 2007 22:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRSv-0007wG-Bm for ospf@ietf.org; Tue, 09 Oct 2007 22:38:29 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfRSp-0005oz-Lp for ospf@ietf.org; Tue, 09 Oct 2007 22:38:29 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPO00LYBCMJWW@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 10 Oct 2007 10:37:31 +0800 (CST) Received: from M55527 ([10.111.12.79]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPO003KFCMIL3@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 10 Oct 2007 10:37:31 +0800 (CST) Date: Wed, 10 Oct 2007 10:37:14 +0800 From: Mach Chen Subject: Re: Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt To: Peng He Message-id: <0JPO003KICMIL3@szxga03-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: CCAMP List , OSPF List , Vishwas Manral X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Peng, Sorry for the late response(Just return from long national holidays) On 2007-10-03, at 10:33:31 Peng He wrote: >Hello Mach, > >Just be curious about the following: >>>3. Add the missing part about that the local ASBR SHOULD do a >"proxy" advertisement for the backward of an inter-AS TE link; > >What do you mean by "the backward of an inter-AS TE link"? Does that >mean that local ASBR would advertise TE info about the incoming >inter-AS link(s)? Thanks. Yes, due to there is no OSPF adjacency running on the inter-AS link, and some implements(CSPF) will do a two-way check before using the link for path computation, so the local ASBR should advertise the TE info of the inter-AS TE link from the view of the remote ASBR. > >Regards, >Peng > Best regards, Mach Chen _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Oct 09 22:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRSb-0007HG-2A; Tue, 09 Oct 2007 22:38:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRSa-0007Gt-58 for ospf@ietf.org; Tue, 09 Oct 2007 22:38:08 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfRSZ-0001Kw-6L for ospf@ietf.org; Tue, 09 Oct 2007 22:38:08 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPO000QJCMC37@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 10 Oct 2007 10:37:25 +0800 (CST) Received: from M55527 ([10.111.12.79]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPO006MCCMB60@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 10 Oct 2007 10:37:24 +0800 (CST) Date: Wed, 10 Oct 2007 10:37:07 +0800 From: Mach Chen Subject: RE: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt To: Alan Davey Message-id: <0JPO006MDCMB60@szxga02-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: CCAMP List , OSPF List , Vishwas Manral X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Alan, Sorry for the late response(Just return from long national holidays) Thanks for your useful comments! On 2007-09-27, at 17:48:59 Alan Davey wrote: >Guys > >Apologies for the late response. > >I basically agree with Acee. > >* It makes sense to define a new OSPFv3-TE LSA type to carry the >AS connectivity information. I think that this would probably provide a >better and more back compatible way to identify the new advertisements >than defining a new link type value. Agree, a new LSA type is a better option for OSPFv3 inter-AS TE. > >* It also makes sense to use the same approach in OSPFv2 and >OSPFv3 and so a new OSPFv2 opaque type may be the way to go. > We are considering whether define a new OSPFv2 opaque type. >My other comments on the draft, from an OSPFv3 TE perspective, are as >follows. > >* On the subject of identifying the other end of the inter-AS >link. > > - The Link ID sub-TLV is not suitable as it SHOULD be ignored >on receipt by an OSPFv3 TE implementation. > > - The Neighbor ID sub-TLV MUST be used instead. This sub-TLV >contains the neighbor's interface ID and the neighbor's 32-bit Router ID >(note that this is NOT the TE Router ID). > > - Use of the Neighbor ID sub-TLV requires configuration at the >ASBR of the remote ASBR's interface ID and the 32-bit Router ID. > Yes, for OSPFv3 inter-AS TE, this will be performed as the current OSPFv3 TE does. > - You may want to advertise a global-scope IPv6 address for the >router at the other end of an inter-AS link in a Remote Interface IPv6 >Address Sub-TLV. This would also need to be configured. > >* As Acee pointed out, there is currently no OSPFv3 TE equivalent >to the Type 11 Opaque LSA, that is, there is no defined LSA for flooding >AS scope TE information. So, allocating a new separate LSA could make it easyly for the inter-AS TE information having area or AS flooding scope. > >* The wording needs to be changed for OSPFv3 TE when describing >the contents of a "proxy" advertisement for the backward direction of an >inter-AD TE link. > OK. >Regards > > >Alan Davey > Best regards, Mach Chen _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf a02-in.huawei.com> for ospf@ietf.org; Wed, 10 Oct 2007 10:37:24 +0800 (CST) Date: Wed, 10 Oct 2007 10:37:07 +0800 From: Mach Chen Subject: RE: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt To: Alan Davey Message-id: <0JPO006MDCMB60@szxga02-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: CCAMP List , OSPF List , Vishwas Manral X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Alan, Sorry for the late response(Just return from long national holidays) Thanks for your useful comments! On 2007-09-27, at 17:48:59 Alan Davey wrote: >Guys > >Apologies for the late response. > >I basically agree with Acee. > >* It makes sense to define a new OSPFv3-TE LSA type to carry the >AS connectivity information. I think that this would probably provide a >better and more back compatible way to identify the new advertisements >than defining a new link type value. Agree, a new LSA type is a better option for OSPFv3 inter-AS TE. > >* It also makes sense to use the same approach in OSPFv2 and >OSPFv3 and so a new OSPFv2 opaque type may be the way to go. > We are considering whether define a new OSPFv2 opaque type. >My other comments on the draft, from an OSPFv3 TE perspective, are as >follows. > >* On the subject of identifying the other end of the inter-AS >link. > > - The Link ID sub-TLV is not suitable as it SHOULD be ignored >on receipt by an OSPFv3 TE implementation. > > - The Neighbor ID sub-TLV MUST be used instead. This sub-TLV >contains the neighbor's interface ID and the neighbor's 32-bit Router ID >(note that this is NOT the TE Router ID). > > - Use of the Neighbor ID sub-TLV requires configuration at the >ASBR of the remote ASBR's interface ID and the 32-bit Router ID. > Yes, for OSPFv3 inter-AS TE, this will be performed as the current OSPFv3 TE does. > - You may want to advertise a global-scope IPv6 address for the >router at the other end of an inter-AS link in a Remote Interface IPv6 >Address Sub-TLV. This would also need to be configured. > >* As Acee pointed out, there is currently no OSPFv3 TE equivalent >to the Type 11 Opaque LSA, that is, there is no defined LSA for flooding >AS scope TE information. So, allocating a new separate LSA could make it easyly for the inter-AS TE information having area or AS flooding scope. > >* The wording needs to be changed for OSPFv3 TE when describing >the contents of a "proxy" advertisement for the backward direction of an >inter-AD TE link. > OK. >Regards > > >Alan Davey > Best regards, Mach Chen _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 10 09:40:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfbkZ-0004df-Ij; Wed, 10 Oct 2007 09:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfbkZ-0004cW-0U for ospf@ietf.org; Wed, 10 Oct 2007 09:37:23 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfbkT-0001SG-Ex for ospf@ietf.org; Wed, 10 Oct 2007 09:37:22 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1IfbkF-0008Hr-HF for ospf@ietf.org; Wed, 10 Oct 2007 13:37:03 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 14:37:01 +0100 Message-ID: <098901c80b42$a122ab10$5102010a@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 10 Oct 2007 14:30:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: 10 Oct 2007 13:37:01.0996 (UTC) FILETIME=[A39076C0:01C80B42] X-Originating-Rutherford-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [OSPF] Question on flodding scope in draft-ietf-ospf-ospfv3-update-17.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, In section 2.3... o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in Router-LSAs for regular areas. I'm concerned about the impact of this statement for future application of text in 3.4.4 It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 3.8. For example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. But in 3.4.4 it also says To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR). You are saying that the only router that cause AS scoped flooding is an ASBR. This limit seems to be unnecessary and overly restrictive. Further, this seems to be a change from RFC2740 where section 2.3 had only o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. Can you clarify why a non-ASBR is not allowed to originate an AS-scoped LSA? Thanks, Adrian PS. I think the I-D header should include "Obsoletes RFC2740" _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 10 09:56:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifc1G-00065n-4F; Wed, 10 Oct 2007 09:54:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifc1E-0005yq-PY for ospf@ietf.org; Wed, 10 Oct 2007 09:54:36 -0400 Received: from mail.advaoptical.de ([213.70.90.131] helo=mail.advaoptical.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifc1E-0004cg-8O for ospf@ietf.org; Wed, 10 Oct 2007 09:54:36 -0400 Received: from muc-srv-mimesweeper.advaoptical.com (10.200.0.15) by mail.advaoptical.com (10.200.0.20) with Microsoft SMTP Server id 8.0.685.24; Wed, 10 Oct 2007 15:54:42 +0200 Received: from muc-srv-mail2.advaoptical.com (unverified) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 10 Oct 2007 15:53:52 +0200 Received: from atl-srv-mail.atl.advaoptical.com ([172.16.5.25]) by muc-srv-mail2.advaoptical.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 15:54:30 +0200 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: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Date: Wed, 10 Oct 2007 09:54:44 -0400 Message-ID: In-Reply-To: <098901c80b42$a122ab10$5102010a@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Thread-Index: AcgLQ9fcnAvqG6WYQxeJXjJTWhgblgAAJ7hg References: <098901c80b42$a122ab10$5102010a@your029b8cecfe> From: Igor Bryskin To: "Adrian Farrel" , X-OriginalArrivalTime: 10 Oct 2007 13:54:30.0227 (UTC) FILETIME=[145BD230:01C80B45] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Adrian, I'd just like to put my 2 cents here. If a non-ASBR advertises AS-scope LSA and then dies, then there would be no way for routers in other areas to "feel" that, hence they will be using the stale information for some while. Note that the way we fixed the problem with AS-scope opaque LSAs in OSPF2 is by making the advertising routers ASBRs. Cheers, Igor -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Wednesday, October 10, 2007 9:31 AM To: ospf@ietf.org Subject: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Hi, In section 2.3... o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in Router-LSAs for regular areas. I'm concerned about the impact of this statement for future application of=20 text in 3.4.4 It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 3.8. For example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. But in 3.4.4 it also says To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR). You are saying that the only router that cause AS scoped flooding is an=20 ASBR. This limit seems to be unnecessary and overly restrictive. Further, this seems to be a change from RFC2740 where section 2.3 had only o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. Can you clarify why a non-ASBR is not allowed to originate an AS-scoped LSA? Thanks, Adrian PS. I think the I-D header should include "Obsoletes RFC2740"=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 10 10:09:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcE5-00011H-6X; Wed, 10 Oct 2007 10:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcE3-000103-UX for ospf@ietf.org; Wed, 10 Oct 2007 10:07:51 -0400 Received: from tigger.icir.org ([192.150.187.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfcDw-0002w1-Dg for ospf@ietf.org; Wed, 10 Oct 2007 10:07:51 -0400 Received: from tigger.icir.org (localhost [127.0.0.1]) by tigger.icir.org (8.12.11/8.13.6) with ESMTP id l9AE6DLL064128; Wed, 10 Oct 2007 07:06:13 -0700 (PDT) (envelope-from atanu@tigger.icir.org) To: Adrian Farrel Subject: Re: [OSPF] Question on flodding scope in draft-ietf-ospf-ospfv3-update-17.txt In-Reply-To: Message from "Adrian Farrel" of "Wed, 10 Oct 2007 14:30:57 BST." <098901c80b42$a122ab10$5102010a@your029b8cecfe> From: Atanu Ghosh X-Organisation: The International Computer Science Institute X-Phone: +1 510 666 2966 X-Fax: +1 510 666 2956 X-Url: X-Mailer: MH-E 7.4.2; nmh 1.0.3; XEmacs 21.4 (patch 19) Date: Wed, 10 Oct 2007 07:06:13 -0700 Message-ID: <64127.1192025173@tigger.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: atanu@icsi.berkeley.edu List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, If a router is an ASBR then border routers will generate a Summary-LSA into other areas. If a non-ASBR generates an AS scoped LSA the router will never be reachable from other areas. Atanu. >>>>> "Adrian" == Adrian Farrel writes: Adrian> Hi, In section 2.3... Adrian> o AS scope. LSA is flooded throughout the routing domain. Adrian> Used for AS-external-LSAs. A router that originates AS Adrian> scoped LSAs is considered an AS Boundary Router (ASBR) and Adrian> will set its E-bit in Router-LSAs for regular areas. Adrian> I'm concerned about the impact of this statement for future Adrian> application of text in 3.4.4 Adrian> It is expected that new LSAs will be defined that will not Adrian> be processed during the Shortest Path First (SPF) Adrian> calculation as described in Section 3.8. For example, Adrian> OSPFv3 LSAs corresponding to information advertised in Adrian> OSPFv2 using opaque LSAs [OPAQUE]. Adrian> But in 3.4.4 it also says Adrian> To facilitate inter-area reachability validation, any Adrian> OSPFv3 router originating AS scoped LSAs is considered an AS Adrian> Boundary Router (ASBR). Adrian> You are saying that the only router that cause AS scoped Adrian> flooding is an ASBR. This limit seems to be unnecessary and Adrian> overly restrictive. Adrian> Further, this seems to be a change from RFC2740 where Adrian> section 2.3 had only o AS scope. LSA is flooded throughout Adrian> the routing domain. Used for AS-external-LSAs. Adrian> Can you clarify why a non-ASBR is not allowed to originate Adrian> an AS-scoped LSA? Adrian> Thanks, Adrian Adrian> PS. I think the I-D header should include "Obsoletes Adrian> RFC2740" Adrian> _______________________________________________ OSPF mailing Adrian> list OSPF@ietf.org Adrian> https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 10 10:45:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcnA-0002CL-Io; Wed, 10 Oct 2007 10:44:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifcn8-0002CD-Ip for ospf@ietf.org; Wed, 10 Oct 2007 10:44:06 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifcn7-0006sx-VI for ospf@ietf.org; Wed, 10 Oct 2007 10:44:06 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1Ifcn7-0002BR-Ez for ospf@ietf.org; Wed, 10 Oct 2007 14:44:05 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 15:20:43 +0100 Message-ID: <09e701c80b48$bb3bd2f0$5102010a@your029b8cecfe> From: "Adrian Farrel" To: References: <098901c80b42$a122ab10$5102010a@your029b8cecfe> Subject: Re: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Date: Wed, 10 Oct 2007 15:19:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: 10 Oct 2007 14:20:43.0185 (UTC) FILETIME=[BDEA2A10:01C80B48] X-Originating-Rutherford-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org I understand the problem, but no the solution! These advertising routers are not ASBRs unless they have links to other ASes. Seems like the problem should be described in terms of ABRs. If an ABR is given special function for flooding AS-scoped LSAs into other areas, it should also be given special function for withdrawing those LSAs if *it* cannot reach the originator and the originator is supposed to be in the area from which the flooding takes place. The alternative is to fix the language! The originator is not an ASBR, it is an originator of AS-scoped LSAs. A ----- Original Message ----- From: "Igor Bryskin" To: "Adrian Farrel" ; Sent: Wednesday, October 10, 2007 2:54 PM Subject: RE: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Hi Adrian, I'd just like to put my 2 cents here. If a non-ASBR advertises AS-scope LSA and then dies, then there would be no way for routers in other areas to "feel" that, hence they will be using the stale information for some while. Note that the way we fixed the problem with AS-scope opaque LSAs in OSPF2 is by making the advertising routers ASBRs. Cheers, Igor -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, October 10, 2007 9:31 AM To: ospf@ietf.org Subject: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Hi, In section 2.3... o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in Router-LSAs for regular areas. I'm concerned about the impact of this statement for future application of text in 3.4.4 It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 3.8. For example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. But in 3.4.4 it also says To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR). You are saying that the only router that cause AS scoped flooding is an ASBR. This limit seems to be unnecessary and overly restrictive. Further, this seems to be a change from RFC2740 where section 2.3 had only o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. Can you clarify why a non-ASBR is not allowed to originate an AS-scoped LSA? Thanks, Adrian PS. I think the I-D header should include "Obsoletes RFC2740" _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 10 11:09:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdA8-0003Mx-NZ; Wed, 10 Oct 2007 11:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdA8-0003Mn-3v for ospf@ietf.org; Wed, 10 Oct 2007 11:07:52 -0400 Received: from mail.advaoptical.de ([213.70.90.131] helo=mail.advaoptical.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfdA3-0004t9-I4 for ospf@ietf.org; Wed, 10 Oct 2007 11:07:52 -0400 Received: from muc-srv-mimesweeper.advaoptical.com (10.200.0.15) by mail.advaoptical.com (10.200.0.20) with Microsoft SMTP Server id 8.0.685.24; Wed, 10 Oct 2007 17:07:54 +0200 Received: from muc-srv-mail2.advaoptical.com (unverified) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 10 Oct 2007 17:07:03 +0200 Received: from atl-srv-mail.atl.advaoptical.com ([172.16.5.25]) by muc-srv-mail2.advaoptical.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 17:07:41 +0200 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: [OSPF] Question on flodding scopeindraft-ietf-ospf-ospfv3-update-17.txt Date: Wed, 10 Oct 2007 11:03:12 -0400 Message-ID: In-Reply-To: <09e701c80b48$bb3bd2f0$5102010a@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Question on flodding scopeindraft-ietf-ospf-ospfv3-update-17.txt Thread-Index: AcgLTXLFIRqrrSx3Rz+RQLScbSsFGAAAClow References: <098901c80b42$a122ab10$5102010a@your029b8cecfe> <09e701c80b48$bb3bd2f0$5102010a@your029b8cecfe> From: Igor Bryskin To: "Adrian Farrel" , X-OriginalArrivalTime: 10 Oct 2007 15:07:41.0610 (UTC) FILETIME=[4DD3B0A0:01C80B4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org I agree with the alternative :=3D). This is because originally only Type = 5 LSAs were of AS scope, hence is the term. I disagree with what you are writing about ABRs. When flooding AS-scope LSAs ABRs as far as I know are no different from any other nodes. One of the functions of ABRs though is to identify ASBRs in areas the ABRs are responsible for, and properly advertise Summary ASBR LSAs (area-scope) into adjacent areas. Igor -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Wednesday, October 10, 2007 10:20 AM To: ospf@ietf.org Subject: Re: [OSPF] Question on flodding scopeindraft-ietf-ospf-ospfv3-update-17.txt I understand the problem, but no the solution! These advertising routers are not ASBRs unless they have links to other=20 ASes. Seems like the problem should be described in terms of ABRs. If an ABR is=20 given special function for flooding AS-scoped LSAs into other areas, it=20 should also be given special function for withdrawing those LSAs if *it* cannot reach the originator and the originator is supposed to be in the area=20 from which the flooding takes place. The alternative is to fix the language! The originator is not an ASBR, it is=20 an originator of AS-scoped LSAs. A ----- Original Message -----=20 From: "Igor Bryskin" To: "Adrian Farrel" ; Sent: Wednesday, October 10, 2007 2:54 PM Subject: RE: [OSPF] Question on flodding scope=20 indraft-ietf-ospf-ospfv3-update-17.txt Hi Adrian, I'd just like to put my 2 cents here. If a non-ASBR advertises AS-scope LSA and then dies, then there would be no way for routers in other areas to "feel" that, hence they will be using the stale information for some while. Note that the way we fixed the problem with AS-scope opaque LSAs in OSPF2 is by making the advertising routers ASBRs. Cheers, Igor -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, October 10, 2007 9:31 AM To: ospf@ietf.org Subject: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Hi, In section 2.3... o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in Router-LSAs for regular areas. I'm concerned about the impact of this statement for future application of text in 3.4.4 It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 3.8. For example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. But in 3.4.4 it also says To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR). You are saying that the only router that cause AS scoped flooding is an ASBR. This limit seems to be unnecessary and overly restrictive. Further, this seems to be a change from RFC2740 where section 2.3 had only o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. Can you clarify why a non-ASBR is not allowed to originate an AS-scoped LSA? Thanks, Adrian PS. I think the I-D header should include "Obsoletes RFC2740" _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 10 11:22:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdMg-0005KR-Ah; Wed, 10 Oct 2007 11:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdMe-0005KM-JW for ospf@ietf.org; Wed, 10 Oct 2007 11:20:48 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfdMY-0005F9-4x for ospf@ietf.org; Wed, 10 Oct 2007 11:20:48 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4F5F9888CBA; Wed, 10 Oct 2007 08:20:36 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26472-07; Wed, 10 Oct 2007 08:20:35 -0700 (PDT) Received: from [????O??IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 5E2D1888CBC; Wed, 10 Oct 2007 08:20:31 -0700 (PDT) In-Reply-To: <098901c80b42$a122ab10$5102010a@your029b8cecfe> References: <098901c80b42$a122ab10$5102010a@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Message-Id: <039A6B88-D28C-479E-B6D5-B83D499A203F@redback.com> From: Acee Lindem Subject: Re: [OSPF] Question on flodding scope in draft-ietf-ospf-ospfv3-update-17.txt Date: Wed, 10 Oct 2007 11:18:56 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1074642843==" Errors-To: ospf-bounces@ietf.org --===============1074642843== Content-Type: multipart/alternative; boundary=Apple-Mail-7--1026028432 --Apple-Mail-7--1026028432 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Adrian, On Oct 10, 2007, at 9:30 AM, Adrian Farrel wrote: > Hi, > > In section 2.3... > > o AS scope. LSA is flooded throughout the routing domain. Used > for > AS-external-LSAs. A router that originates AS scoped LSAs is > considered an AS Boundary Router (ASBR) and will set its E-bit in > Router-LSAs for regular areas. > > I'm concerned about the impact of this statement for future > application of text in 3.4.4 > > It is expected that new LSAs will be defined that will not be > processed during the Shortest Path First (SPF) calculation as > described in Section 3.8. For example, OSPFv3 LSAs corresponding to > information advertised in OSPFv2 using opaque LSAs [OPAQUE]. > > But in 3.4.4 it also says > > To facilitate inter-area reachability validation, any OSPFv3 router > originating AS scoped LSAs is considered an AS Boundary Router > (ASBR). > > You are saying that the only router that cause AS scoped flooding > is an ASBR. This limit seems to be unnecessary and overly restrictive. > > Further, this seems to be a change from RFC2740 where section 2.3 > had only > o AS scope. LSA is flooded throughout the routing domain. Used > for AS-external-LSAs. > > Can you clarify why a non-ASBR is not allowed to originate an AS- > scoped LSA? This is necessary to enforce the "condition of reachability" for all LSAs. In other words, in order for an LSA to be considered valid, you need to verify that the advertising router is reachable. Hence, a router advertising an AS scoped LSA must advertise itself as ASBR so that Inter-Area-Router-LSAs are advertised into all regular areas. We are also respinning RFC 2370 (Opaque LSAs) to enforce this. This is draft-ietf-ospf-rfc2370bis-01.txt. Thanks, Acee > > Thanks, > Adrian > > PS. I think the I-D header should include "Obsoletes RFC2740" > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf --Apple-Mail-7--1026028432 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Adrian,

On = Oct 10, 2007, at 9:30 AM, Adrian Farrel wrote:

Hi,

In section 2.3...

=A0 o=A0 AS scope.=A0 LSA is flooded throughout the = routing domain.=A0 Used = for
=A0=A0 =A0 AS-external-LSAs.=A0 A router that originates AS = scoped LSAs is
=A0=A0 =A0 considered an AS = Boundary Router (ASBR) and will set its E-bit in
=A0=A0 =A0 = Router-LSAs for regular areas.

I'm concerned = about the impact of this statement for future application of text in = 3.4.4

=A0 It = is expected that new LSAs will be defined that will not be
=A0 = processed during the Shortest Path First (SPF) calculation = as
=A0 = described in Section 3.8.=A0 = For example, OSPFv3 LSAs corresponding to
=A0 = information advertised in OSPFv2 using opaque LSAs = [OPAQUE].

But in 3.4.4 it also says

=A0 To facilitate inter-area = reachability validation, any OSPFv3 router
=A0 originating AS scoped LSAs is = considered an AS Boundary Router
=A0 (ASBR).

You are = saying that the only router that cause AS scoped flooding is an ASBR. = This limit seems to be unnecessary and overly restrictive.

Further, = this seems to be a change from RFC2740 where section 2.3 had = only
=A0 o =A0 AS scope. LSA is flooded = throughout the routing domain. Used
=A0 =A0 =A0 for = AS-external-LSAs.

Can you clarify why a non-ASBR is not allowed to = originate an AS-scoped LSA?

This is necessary to = enforce the "condition of reachability" for all LSAs. In other words, in = order for an LSA to be considered valid, you need to verify that the = advertising router is reachable. Hence, a router advertising an AS = scoped LSA must advertise itself as ASBR so that Inter-Area-Router-LSAs = are advertised into all regular areas.=A0

We are also respinning RFC = 2370 (Opaque LSAs) to enforce this. This is=A0=A0draft-ietf-ospf-rfc2370bis-01.txt.
Thanks,
Acee
<= BR>

Thanks,
Adrian

PS. I think the I-D header = should include "Obsoletes RFC2740"=A0


OSPF mailing list
=

= --Apple-Mail-7--1026028432-- --===============1074642843== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1074642843==-- From ospf-bounces@ietf.org Wed Oct 10 11:30:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdVd-00079J-7P; Wed, 10 Oct 2007 11:30:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdVb-00077r-Nc for ospf@ietf.org; Wed, 10 Oct 2007 11:30:03 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfdVb-0008Dj-3F for ospf@ietf.org; Wed, 10 Oct 2007 11:30:03 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A2F0C6046C9; Wed, 10 Oct 2007 08:30:02 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27939-02; Wed, 10 Oct 2007 08:30:02 -0700 (PDT) Received: from [????O??IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 49CC79B776; Wed, 10 Oct 2007 08:29:57 -0700 (PDT) In-Reply-To: <09e701c80b48$bb3bd2f0$5102010a@your029b8cecfe> References: <098901c80b42$a122ab10$5102010a@your029b8cecfe> <09e701c80b48$bb3bd2f0$5102010a@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6361E9A9-C26F-4786-8AE3-5F4520850DF2@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Date: Wed, 10 Oct 2007 11:28:22 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Adrian, On Oct 10, 2007, at 10:19 AM, Adrian Farrel wrote: > I understand the problem, but no the solution! > > These advertising routers are not ASBRs unless they have links to > other ASes. > > Seems like the problem should be described in terms of ABRs. If an > ABR is given special function for flooding AS-scoped LSAs into > other areas, it should also be given special function for > withdrawing those LSAs if *it* cannot reach the originator and the > originator is supposed to be in the area from which the flooding > takes place. > > The alternative is to fix the language! The originator is not an > ASBR, it is an originator of AS-scoped LSAs. I could modify the definition of the Router E bit to include both situations. However, I don't want to define a new bit since we only have 8 router bits total in the Router-LSA (and only 4 left assuming we can reclaim the bit from MOSPF). Thanks, Acee > > A > ----- Original Message ----- From: "Igor Bryskin" > > To: "Adrian Farrel" ; > Sent: Wednesday, October 10, 2007 2:54 PM > Subject: RE: [OSPF] Question on flodding scope indraft-ietf-ospf- > ospfv3-update-17.txt > > > Hi Adrian, > > I'd just like to put my 2 cents here. > > If a non-ASBR advertises AS-scope LSA and then dies, then there > would be > no way for routers in other areas to "feel" that, hence they will be > using the stale information for some while. > > Note that the way we fixed the problem with AS-scope opaque LSAs in > OSPF2 is by making the advertising routers ASBRs. > > Cheers, > Igor > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, October 10, 2007 9:31 AM > To: ospf@ietf.org > Subject: [OSPF] Question on flodding scope > indraft-ietf-ospf-ospfv3-update-17.txt > > Hi, > > In section 2.3... > > o AS scope. LSA is flooded throughout the routing domain. Used > for > AS-external-LSAs. A router that originates AS scoped LSAs is > considered an AS Boundary Router (ASBR) and will set its E-bit in > Router-LSAs for regular areas. > > I'm concerned about the impact of this statement for future > application > of > text in 3.4.4 > > It is expected that new LSAs will be defined that will not be > processed during the Shortest Path First (SPF) calculation as > described in Section 3.8. For example, OSPFv3 LSAs corresponding to > information advertised in OSPFv2 using opaque LSAs [OPAQUE]. > > But in 3.4.4 it also says > > To facilitate inter-area reachability validation, any OSPFv3 router > originating AS scoped LSAs is considered an AS Boundary Router > (ASBR). > > You are saying that the only router that cause AS scoped flooding > is an > ASBR. This limit seems to be unnecessary and overly restrictive. > > Further, this seems to be a change from RFC2740 where section 2.3 had > only > o AS scope. LSA is flooded throughout the routing domain. Used > for AS-external-LSAs. > > Can you clarify why a non-ASBR is not allowed to originate an AS- > scoped > LSA? > > Thanks, > Adrian > > PS. I think the I-D header should include "Obsoletes RFC2740" > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 10 14:05:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffsd-0001vd-35; Wed, 10 Oct 2007 14:01:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffsc-0001vW-92 for ospf@ietf.org; Wed, 10 Oct 2007 14:01:58 -0400 Received: from corp.force10networks.com ([64.186.164.204] helo=mx.force10networks.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iffsb-00057B-Fo for ospf@ietf.org; Wed, 10 Oct 2007 14:01:58 -0400 Received: from EXCH-CLUSTER-03.force10networks.com ([10.11.0.54]) by mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 11:02:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Date: Wed, 10 Oct 2007 11:02:00 -0700 Message-ID: <44ED058B21DF294ABE394CABE5C1B521E1984F@EXCH-CLUSTER-03.force10networks.com> In-Reply-To: <039A6B88-D28C-479E-B6D5-B83D499A203F@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Thread-Index: AcgLUdw0moCPHwTqRvmRhTLMD4sb1gAFDjig References: <098901c80b42$a122ab10$5102010a@your029b8cecfe> <039A6B88-D28C-479E-B6D5-B83D499A203F@redback.com> From: "Nitin Kakkar" To: "Acee Lindem" , "Adrian Farrel" X-OriginalArrivalTime: 10 Oct 2007 18:02:00.0579 (UTC) FILETIME=[A7DBB530:01C80B67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d0bcffb66863314915c89d5f9c8a747 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0319584626==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0319584626== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80B67.A7D2E974" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80B67.A7D2E974 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian> You are saying that the only router that cause AS scoped flooding is an ASBR. This limit seems to be unnecessary and overly restrictive. Adrian> Can you clarify why a non-ASBR is not allowed to originate an AS-scoped LSA? =20 Acee> This is necessary to enforce the "condition of reachability" for all LSAs. In other words, in order for an LSA to be considered valid, you need to verify that the advertising router is reachable. Hence, a router advertising an AS scoped LSA must advertise itself as ASBR so that Inter-Area-Router-LSAs are advertised into all regular areas.=20 =20 IMHO> It is quite possible in many scenario's that a router originated AS scope LSA's and then changed from ASBR to Non ASBR, leaving older ASE LSA's in domain. =20 1) If we use implict definition of ASBR (independent of E bit) it will result in incorrect Routes=20 2) This statement also tries to prevent unnecessary origination of unusable lsa's (If router originate ASE lsa's and does not advertise it self as ASBR, what would be the use of those LSA's? these LSA's will only occupy space in LSDB & result into unnecessary flooding but won't contribute to routing, this is very similar to ) =20 =20 Regards Nitin ________________________________ From: Acee Lindem [mailto:acee@redback.com]=20 Sent: Wednesday, October 10, 2007 8:19 AM To: Adrian Farrel Cc: ospf@ietf.org Subject: Re: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt =20 Hi Adrian, =20 On Oct 10, 2007, at 9:30 AM, Adrian Farrel wrote: Hi, =20 In section 2.3... =20 o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in Router-LSAs for regular areas. =20 I'm concerned about the impact of this statement for future application of text in 3.4.4 =20 It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 3.8. For example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. =20 But in 3.4.4 it also says =20 To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR). =20 You are saying that the only router that cause AS scoped flooding is an ASBR. This limit seems to be unnecessary and overly restrictive. =20 Further, this seems to be a change from RFC2740 where section 2.3 had only o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. =20 Can you clarify why a non-ASBR is not allowed to originate an AS-scoped LSA? =20 This is necessary to enforce the "condition of reachability" for all LSAs. In other words, in order for an LSA to be considered valid, you need to verify that the advertising router is reachable. Hence, a router advertising an AS scoped LSA must advertise itself as ASBR so that Inter-Area-Router-LSAs are advertised into all regular areas.=20 =20 We are also respinning RFC 2370 (Opaque LSAs) to enforce this. This is draft-ietf-ospf-rfc2370bis-01.txt. =20 Thanks, Acee =20 Thanks, Adrian =20 PS. I think the I-D header should include "Obsoletes RFC2740"=20 =20 =20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf =20 ------_=_NextPart_001_01C80B67.A7D2E974 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adrian>= ; You are saying that the only router that cause AS scoped flooding is an = ASBR. This limit seems to be unnecessary and overly = restrictive.

Adrian>= ; Can you clarify why a non-ASBR is not allowed to originate an AS-scoped = LSA?

 

Acee> This is necessary to enforce the "condition of reachability" for all LSAs. In other words, in order for an LSA to = be considered valid, you need to verify that the advertising router is = reachable. Hence, a router advertising an AS scoped LSA must advertise itself as = ASBR so that Inter-Area-Router-LSAs are advertised into all regular = areas. 

 

IMHO> It is quite possible in = many scenario’s that  a router originated AS scope LSA’s and = then changed from ASBR to Non ASBR, leaving older ASE LSA’s in = domain. 

1)     = If we use implict definition of ASBR (independent of E bit) = it will result in incorrect  Routes

2)     = This statement also tries to prevent unnecessary origination = of unusable lsa’s (If router originate ASE lsa’s and does not = advertise it self as ASBR, what would be the use of those LSA’s?  these = LSA’s will only occupy space in LSDB & result into unnecessary flooding = but won’t contribute to routing, this is very similar to  ) =  

 =

Regards

Nitin<= /span>

From: = Acee Lindem [mailto:acee@redback.com]
Sent: Wednesday, October = 10, 2007 8:19 AM
To: Adrian Farrel
Cc: ospf@ietf.org
Subject: Re: [OSPF] = Question on flodding scope = indraft-ietf-ospf-ospfv3-update-17.txt

 

Hi Adrian,

 

On Oct 10, 2007, at 9:30 AM, Adrian Farrel = wrote:



Hi,

 

In section 2.3...

 

  = o  AS scope.  LSA is flooded throughout = the routing domain.  Used = for

   =   AS-external-LSAs.  A router that originates AS = scoped LSAs is

   =   considered an AS Boundary Router (ASBR) and will set its E-bit in

   =   Router-LSAs for regular areas.

 

I'm concerned about the impact of this statement for future = application of text in 3.4.4

 

  = It is expected that new LSAs will be defined that will not = be

  = processed during the Shortest Path First (SPF) calculation as

  = described in Section 3.8.  For = example, OSPFv3 LSAs corresponding to

  = information advertised in OSPFv2 using opaque LSAs [OPAQUE].

 

But in 3.4.4 it also says

 

  = To facilitate inter-area reachability validation, any OSPFv3 = router

  = originating AS scoped LSAs is considered an AS Boundary Router

  = (ASBR).

 

You are saying that the only router that cause AS scoped = flooding is an ASBR. This limit seems to be unnecessary and overly = restrictive.

 

Further, this seems to be a change from RFC2740 where section = 2.3 had only

  = o   AS scope. LSA is = flooded throughout the routing domain. Used

    =   for AS-external-LSAs.

 

Can you clarify why a non-ASBR is not allowed to originate an = AS-scoped LSA?

 

This is necessary to enforce the "condition of = reachability" for all LSAs. In other words, in order for an LSA to be considered = valid, you need to verify that the advertising router is reachable. Hence, a router advertising an AS scoped LSA must advertise itself as ASBR so that Inter-Area-Router-LSAs are advertised into all regular = areas. 

 

We are also respinning RFC 2370 (Opaque LSAs) to enforce this. = This is  draft-ietf-ospf-rfc2370bis-01.txt.<= /span>

 

Thanks,

Acee



 

Thanks,

Adrian

 

PS. I think the I-D header should include "Obsoletes = RFC2740" 

 

 

_______________________________________________=

OSPF mailing list

 

------_=_NextPart_001_01C80B67.A7D2E974-- --===============0319584626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0319584626==-- From ospf-bounces@ietf.org Wed Oct 10 14:22:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgBP-0000cJ-IP; Wed, 10 Oct 2007 14:21:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgBN-0000bn-UG for ospf@ietf.org; Wed, 10 Oct 2007 14:21:22 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfgBM-0005iv-6t for ospf@ietf.org; Wed, 10 Oct 2007 14:21:21 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 91FB169E7; Wed, 10 Oct 2007 11:21:19 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26768-02; Wed, 10 Oct 2007 11:21:19 -0700 (PDT) Received: from [????O??IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id EA5EF69F3; Wed, 10 Oct 2007 11:21:17 -0700 (PDT) In-Reply-To: <44ED058B21DF294ABE394CABE5C1B521E1984F@EXCH-CLUSTER-03.force10networks.com> References: <098901c80b42$a122ab10$5102010a@your029b8cecfe> <039A6B88-D28C-479E-B6D5-B83D499A203F@redback.com> <44ED058B21DF294ABE394CABE5C1B521E1984F@EXCH-CLUSTER-03.force10networks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <7F019337-CE1E-4AA1-A95A-7D4D0F8E5D35@redback.com> From: Acee Lindem Subject: Re: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Date: Wed, 10 Oct 2007 14:19:43 -0400 To: "Nitin Kakkar" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 634fdbde3f75ae1fea5a01ebf03b5480 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359926508==" Errors-To: ospf-bounces@ietf.org --===============0359926508== Content-Type: multipart/alternative; boundary=Apple-Mail-8--1015181674 --Apple-Mail-8--1015181674 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Nitin, On Oct 10, 2007, at 2:02 PM, Nitin Kakkar wrote: > Adrian> You are saying that the only router that cause AS scoped =20 > flooding is an ASBR. This limit seems to be unnecessary and overly =20 > restrictive. > > Adrian> Can you clarify why a non-ASBR is not allowed to originate =20 > an AS-scoped LSA? > > > > Acee> This is necessary to enforce the "condition of reachability" =20 > for all LSAs. In other words, in order for an LSA to be considered =20 > valid, you need to verify that the advertising router is reachable. =20= > Hence, a router advertising an AS scoped LSA must advertise itself =20 > as ASBR so that Inter-Area-Router-LSAs are advertised into all =20 > regular areas. > > > > IMHO> It is quite possible in many scenario=92s that a router =20 > originated AS scope LSA=92s and then changed from ASBR to Non ASBR, =20= > leaving older ASE LSA=92s in domain. > > 1) If we use implict definition of ASBR (independent of E bit) =20 > it will result in incorrect Routes > > 2) This statement also tries to prevent unnecessary origination =20= > of unusable lsa=92s (If router originate ASE lsa=92s and does not =20 > advertise it self as ASBR, what would be the use of those LSA=92s? =20= > these LSA=92s will only occupy space in LSDB & result into =20 > unnecessary flooding but won=92t contribute to routing, this is very =20= > similar to ) So, I'll take this as agreement. Thanks, Acee > > > Regards > > Nitin > > From: Acee Lindem [mailto:acee@redback.com] > Sent: Wednesday, October 10, 2007 8:19 AM > To: Adrian Farrel > Cc: ospf@ietf.org > Subject: Re: [OSPF] Question on flodding scope indraft-ietf-ospf-=20 > ospfv3-update-17.txt > > > > Hi Adrian, > > > > On Oct 10, 2007, at 9:30 AM, Adrian Farrel wrote: > > > > > Hi, > > > > In section 2.3... > > > > o AS scope. LSA is flooded throughout the routing domain. Used =20= > for > > AS-external-LSAs. A router that originates AS scoped LSAs is > > considered an AS Boundary Router (ASBR) and will set its E-bit in > > Router-LSAs for regular areas. > > > > I'm concerned about the impact of this statement for future =20 > application of text in 3.4.4 > > > > It is expected that new LSAs will be defined that will not be > > processed during the Shortest Path First (SPF) calculation as > > described in Section 3.8. For example, OSPFv3 LSAs corresponding to > > information advertised in OSPFv2 using opaque LSAs [OPAQUE]. > > > > But in 3.4.4 it also says > > > > To facilitate inter-area reachability validation, any OSPFv3 router > > originating AS scoped LSAs is considered an AS Boundary Router > > (ASBR). > > > > You are saying that the only router that cause AS scoped flooding =20 > is an ASBR. This limit seems to be unnecessary and overly restrictive. > > > > Further, this seems to be a change from RFC2740 where section 2.3 =20 > had only > > o AS scope. LSA is flooded throughout the routing domain. Used > > for AS-external-LSAs. > > > > Can you clarify why a non-ASBR is not allowed to originate an AS-=20 > scoped LSA? > > > > This is necessary to enforce the "condition of reachability" for =20 > all LSAs. In other words, in order for an LSA to be considered =20 > valid, you need to verify that the advertising router is reachable. =20= > Hence, a router advertising an AS scoped LSA must advertise itself =20 > as ASBR so that Inter-Area-Router-LSAs are advertised into all =20 > regular areas. > > > > We are also respinning RFC 2370 (Opaque LSAs) to enforce this. This =20= > is draft-ietf-ospf-rfc2370bis-01.txt. > > > > Thanks, > > Acee > > > > > > > Thanks, > > Adrian > > > > PS. I think the I-D header should include "Obsoletes RFC2740" > > > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > > > --Apple-Mail-8--1015181674 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Nitin,

On = Oct 10, 2007, at 2:02 PM, Nitin Kakkar wrote:

> You are saying that the only router that cause = AS scoped flooding is an ASBR. This limit seems to be unnecessary and = overly restrictive.

> Can you clarify why a non-ASBR is not allowed to = originate an AS-scoped LSA?

=A0

Acee> This is necessary to enforce the = "condition of reachability" for all LSAs. In other words, in order for = an LSA to be considered valid, you need to verify that the advertising = router is reachable. Hence, a router advertising an AS scoped LSA must = advertise itself as ASBR so that Inter-Area-Router-LSAs are advertised = into all regular areas.=A0

=A0

IMHO> It is quite possible in many scenario=92s that=A0 = a router originated AS scope LSA=92s and then changed from ASBR to Non = ASBR, leaving older ASE LSA=92s in domain.=A01)=A0=A0=A0=A0 = If = we use implict definition of ASBR (independent of E bit) it will result = in incorrect =A0Routes2)=A0=A0=A0=A0 =

Thanks,
Acee

=A0

Regards

Nitin

From: Acee Lindem [mailto:acee@redback.com]
Wednesday, = October 10, 2007 8:19 AM
To: Adrian Farrel
Cc: ospf@ietf.org Re: [OSPF] = Question on flodding scope = indraft-ietf-ospf-ospfv3-update-17.txt=A0

Hi Adrian,

=A0

On Oct 10, 2007, at 9:30 AM, Adrian Farrel = wrote:



Hi,

In section 2.3...

=A0

=A0 = o=A0 = AS scope.=A0 = LSA is flooded throughout the = routing domain.=A0 Used = for=A0=A0 =A0 = =A0 A router that = originates AS scoped LSAs is

=A0=A0 =A0 = considered an = AS Boundary Router (ASBR) and will set its E-bit in=A0=A0 =A0 = Router-LSAs = for regular areas.

=A0

I'm concerned about the impact of this = statement for future application of text in 3.4.4

=A0

=A0 = It is expected = that new LSAs will be defined that will not be=A0 = processed = during the Shortest Path First (SPF) calculation as=A0 = described in = Section 3.8.=A0 For example, = OSPFv3 LSAs corresponding to

=A0 = information = advertised in OSPFv2 using opaque LSAs [OPAQUE].

=A0

But in 3.4.4 it also says

=A0

=A0 = To facilitate = inter-area reachability validation, any OSPFv3 router=A0 = originating AS = scoped LSAs is considered an AS Boundary Router=A0 =

=A0

You are saying that the only router that cause = AS scoped flooding is an ASBR. This limit seems to be unnecessary and = overly restrictive.

Further, this seems to be a change from = RFC2740 where section 2.3 had only=A0 = o =A0 = AS scope. LSA is flooded throughout = the routing domain. Used

=A0 =A0 =A0 = for = AS-external-LSAs.

=A0

Can you clarify why a non-ASBR is not allowed = to originate an AS-scoped LSA?

=A0

This is necessary to enforce the "condition of = reachability" for all LSAs. In other words, in order for an LSA to be = considered valid, you need to verify that the advertising router is = reachable. Hence, a router advertising an AS scoped LSA must advertise = itself as ASBR so that Inter-Area-Router-LSAs are advertised into all = regular areas.=A0

=A0

We are also respinning RFC 2370 (Opaque LSAs) = to enforce this. This is=A0Thanks,

Acee


=A0

Thanks,

=A0

PS. I think the I-D header should include = "Obsoletes RFC2740"=A0

OSPF mailing list


= --Apple-Mail-8--1015181674-- --===============0359926508== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0359926508==-- From ospf-bounces@ietf.org Wed Oct 10 14:30:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgJV-0005Mj-Hl; Wed, 10 Oct 2007 14:29:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgJU-0005MR-TY for ospf@ietf.org; Wed, 10 Oct 2007 14:29:44 -0400 Received: from corp.force10networks.com ([64.186.164.204] helo=mx.force10networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfgJN-0003hn-Pl for ospf@ietf.org; Wed, 10 Oct 2007 14:29:44 -0400 Received: from EXCH-CLUSTER-03.force10networks.com ([10.11.0.54]) by mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 11:29:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Date: Wed, 10 Oct 2007 11:29:26 -0700 Message-ID: <44ED058B21DF294ABE394CABE5C1B521E19850@EXCH-CLUSTER-03.force10networks.com> In-Reply-To: <7F019337-CE1E-4AA1-A95A-7D4D0F8E5D35@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt Thread-Index: AcgLal5KLQ0DEtMoQjCS1PejXO/bVgAANo2w References: <098901c80b42$a122ab10$5102010a@your029b8cecfe> <039A6B88-D28C-479E-B6D5-B83D499A203F@redback.com> <44ED058B21DF294ABE394CABE5C1B521E1984F@EXCH-CLUSTER-03.force10networks.com> <7F019337-CE1E-4AA1-A95A-7D4D0F8E5D35@redback.com> From: "Nitin Kakkar" To: "Acee Lindem" X-OriginalArrivalTime: 10 Oct 2007 18:29:26.0287 (UTC) FILETIME=[7CC6D1F0:01C80B6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d20755f70c178b57c076995ecfb1501 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0441569513==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0441569513== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80B6B.7CCA0810" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80B6B.7CCA0810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 ________________________________ From: Acee Lindem [mailto:acee@redback.com]=20 Sent: Wednesday, October 10, 2007 11:20 AM To: Nitin Kakkar Cc: Adrian Farrel; ospf@ietf.org Subject: Re: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt =20 Hi Nitin, =20 On Oct 10, 2007, at 2:02 PM, Nitin Kakkar wrote: Adrian> You are saying that the only router that cause AS scoped flooding is an ASBR. This limit seems to be unnecessary and overly restrictive. Adrian> Can you clarify why a non-ASBR is not allowed to originate an AS-scoped LSA? =20 Acee> This is necessary to enforce the "condition of reachability" for all LSAs. In other words, in order for an LSA to be considered valid, you need to verify that the advertising router is reachable. Hence, a router advertising an AS scoped LSA must advertise itself as ASBR so that Inter-Area-Router-LSAs are advertised into all regular areas.=20 =20 IMHO> It is quite possible in many scenario's that a router originated AS scope LSA's and then changed from ASBR to Non ASBR, leaving older ASE LSA's in domain.=20 1) This statement also tries to prevent unnecessary origination of unusable lsa's (If router originate ASE lsa's and does not advertise it self as ASBR, what would be the use of those LSA's? these LSA's will only occupy space in LSDB & result into unnecessary flooding but won't contribute to routing, this is very similar to ) =20 =20 So, I'll take this as agreement.=20 =20 Nitin> Yes Sir, Agreement to your Statement. My statement was in explanation to Adrian's mention that ASBR definition is overly restrictive. I tried to point out that restrictive ASBR definition was necessary for maintaining sanity in ospf & tried to explain what happen when non asbr's originate ASE lsa's. =20 Regards Nitin =20 Thanks, Acee =20 Regards Nitin ________________________________ From: Acee Lindem [mailto:acee@redback.com]=20 Sent: Wednesday, October 10, 2007 8:19 AM To: Adrian Farrel Cc: ospf@ietf.org =20 Subject: Re: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt =20 Hi Adrian, =20 On Oct 10, 2007, at 9:30 AM, Adrian Farrel wrote: Hi, =20 In section 2.3... =20 o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in Router-LSAs for regular areas. =20 I'm concerned about the impact of this statement for future application of text in 3.4.4 =20 It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 3.8. For example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. =20 But in 3.4.4 it also says =20 To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR). =20 You are saying that the only router that cause AS scoped flooding is an ASBR. This limit seems to be unnecessary and overly restrictive. =20 Further, this seems to be a change from RFC2740 where section 2.3 had only o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. =20 Can you clarify why a non-ASBR is not allowed to originate an AS-scoped LSA? =20 This is necessary to enforce the "condition of reachability" for all LSAs. In other words, in order for an LSA to be considered valid, you need to verify that the advertising router is reachable. Hence, a router advertising an AS scoped LSA must advertise itself as ASBR so that Inter-Area-Router-LSAs are advertised into all regular areas.=20 =20 We are also respinning RFC 2370 (Opaque LSAs) to enforce this. This is draft-ietf-ospf-rfc2370bis-01.txt. =20 Thanks, Acee =20 Thanks, Adrian =20 PS. I think the I-D header should include "Obsoletes RFC2740"=20 =20 =20 _______________________________________________ OSPF mailing list OSPF@ietf.org =20 https://www1.ietf.org/mailman/listinfo/ospf =20 =20 =20 ------_=_NextPart_001_01C80B6B.7CCA0810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: = Acee Lindem [mailto:acee@redback.com]
Sent: Wednesday, October = 10, 2007 11:20 AM
To: Nitin Kakkar
Cc: Adrian Farrel; = ospf@ietf.org
Subject: Re: [OSPF] = Question on flodding scope = indraft-ietf-ospf-ospfv3-update-17.txt

 

Hi Nitin,

 

On Oct 10, 2007, at 2:02 PM, Nitin Kakkar = wrote:



Adrian> You are saying that the only = router that cause AS scoped flooding is an ASBR. This limit seems to be = unnecessary and overly restrictive.

Adrian> Can you clarify why a non-ASBR is not allowed to = originate an AS-scoped LSA?

 

Acee> This is necessary to = enforce the "condition of reachability" for all LSAs. In other words, in = order for an LSA to be considered valid, you need to verify that the = advertising router is reachable. Hence, a router advertising an AS scoped LSA must advertise itself as ASBR so that Inter-Area-Router-LSAs are advertised = into all regular areas. 

 

IMHO> It is = quite possible in many scenario’s that  a router originated AS = scope LSA’s and then changed from ASBR to Non ASBR, leaving older ASE LSA’s in = domain. 

1)     This statement also tries to prevent unnecessary origination = of unusable lsa’s (If router originate ASE lsa’s and does not = advertise it self as ASBR, what would be the use of those LSA’s?  these = LSA’s will only occupy space in LSDB & result into unnecessary flooding but won’t = contribute to routing, this is very similar to  ) =  

 

So, I'll take this as = agreement. 

 

=

Nitin> Yes Sir, Agreement to = your Statement.

      = ;     My statement was in explanation to Adrian’s mention  that ASBR definition is overly restrictive. I tried to point out = that restrictive ASBR definition was necessary for maintaining sanity in ospf & tried = to explain what happen when non asbr’s originate ASE = lsa’s.

 

=

Regards

Nitin

 

Thanks,

Acee

 

Regards

Nitin

From: = Acee Lindem [mailto:acee@redback.com] =
Sent: Wednesday, October 10, 2007 8:19 AM
To: Adrian Farrel
Cc: ospf@ietf.org
Subject: Re: [OSPF] Question on flodding scope = indraft-ietf-ospf-ospfv3-update-17.txt

 

Hi Adrian, 

On Oct 10, 2007, at 9:30 AM, = Adrian Farrel wrote:


Hi,

 

In section 2.3...

 

  o  AS scope.  LSA = is flooded throughout the routing domain.  Used = for

     = AS-external-LSAs.  A router that originates AS scoped LSAs is

     considered an = AS Boundary Router (ASBR) and will set its E-bit = in

     Router-LSAs = for regular areas.

 

I'm concerned about the impact of = this statement for future application of text in 3.4.4

 

  It is expected that new = LSAs will be defined that will not be

  processed during the = Shortest Path First (SPF) calculation as

  described in Section = 3.8.  For example, OSPFv3 LSAs corresponding to

  information advertised in = OSPFv2 using opaque LSAs [OPAQUE].

 

But in 3.4.4 it also says

 

  To facilitate inter-area reachability validation, any OSPFv3 router

  originating AS scoped LSAs = is considered an AS Boundary Router

  = (ASBR).

 

You are saying that the only = router that cause AS scoped flooding is an ASBR. This limit seems to be unnecessary = and overly restrictive.

 

Further, this seems to be a change = from RFC2740 where section 2.3 had only

  o   AS scope. LSA is = flooded throughout the routing domain. Used

      for = AS-external-LSAs.

 

Can you clarify why a non-ASBR is = not allowed to originate an AS-scoped LSA?

 

This is necessary to enforce the "condition of reachability" for all LSAs. In other words, in = order for an LSA to be considered valid, you need to verify that the = advertising router is reachable. Hence, a router advertising an AS scoped LSA must advertise itself as ASBR so that Inter-Area-Router-LSAs are advertised = into all regular areas. 

 

We are also respinning RFC 2370 = (Opaque LSAs) to enforce this. This is  draft-i= etf-ospf-rfc2370bis-01.txt.

 

Thanks,

Acee

 

Thanks,

Adrian

 

PS. I think the I-D header should = include "Obsoletes RFC2740" 

 

 

___________________________________= ____________OSPF mailing listOSPF@ietf.org

https://www1.ietf.org/mailman/listinfo/ospf<= O:P style=3D"font-family: Times New Roman; font-size: 16px; = ">

 



 

------_=_NextPart_001_01C80B6B.7CCA0810-- --===============0441569513== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0441569513==-- From Tudose.Shafer@advancedhome.org Wed Oct 10 14:34:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgNv-0004ky-LP for ospf-archive@megatron.ietf.org; Wed, 10 Oct 2007 14:34:19 -0400 Received: from [201.234.8.226] (helo=[201.234.8.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfgNj-00069J-GL for ospf-archive@megatron.ietf.org; Wed, 10 Oct 2007 14:34:08 -0400 Received: from PENTIUM4 ([125.147.56.89]:29510 "EHLO PENTIUM4" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [201.234.8.226] with ESMTP id S22SUQDXHIMRMOTP (ORCPT ); Wed, 10 Oct 2007 15:34:17 -0300 Message-ID: <872059D7.40D769DF@advancedhome.org> Date: Wed, 10 Oct 2007 15:34:07 -0300 From: "Tudose Shafer" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: minarier Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Hi there ospf-archive YES you can turn your worm into a trouser snake safely, check it out Tudose Shafer http://www.bajzu.com/ From dailyb@ser.org.pe Thu Oct 11 02:02:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifr7S-0004Lv-Sn for ospf-archive@lists.ietf.org; Thu, 11 Oct 2007 02:02:02 -0400 Received: from xdsl-92-ppp91.tts.nov.ru ([81.16.92.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ifr7I-0000iA-Ev for ospf-archive@lists.ietf.org; Thu, 11 Oct 2007 02:01:58 -0400 Received: from [201.212.105.80] (helo=efxln) by xdsl-92-ppp91.tts.nov.ru with smtp (Exim 4.62 (FreeBSD)) id 1Jr70-0007VS-K8; Thu, 11 Oct 2007 10:01:28 +0400 Message-ID: <002201c80bcc$007c5000$5069d4c9@efxln> From: To: Subject: dude, its free Date: Thu, 11 Oct 2007 10:00:18 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 1.6 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 No membership, no tricks, no gimmicks, just 1000 free games. http://75.68.240.5/ From ospf-bounces@ietf.org Thu Oct 11 11:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzlz-0006z2-A2; Thu, 11 Oct 2007 11:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzly-0006yb-9B; Thu, 11 Oct 2007 11:16:26 -0400 Received: from no-more.cisco.com ([64.104.206.251] helo=av-tac-apt.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifzlr-0006E9-63; Thu, 11 Oct 2007 11:16:26 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-apt.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9BFGAj13519; Fri, 12 Oct 2007 01:16:10 +1000 (EST) Received: from [128.107.163.254] (dhcp-128-107-163-254.cisco.com [128.107.163.254]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9BFG6I20532; Thu, 11 Oct 2007 17:16:07 +0200 (CEST) Message-ID: <470E3E35.7060400@cisco.com> Date: Thu, 11 Oct 2007 08:16:05 -0700 From: Anton Smirnov Organization: Cisco Systems, Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [OSPF] Fw: Four L1VPN working group last calls References: <02e801c8013c$9df58d00$0200a8c0@your029b8cecfe> In-Reply-To: <02e801c8013c$9df58d00$0200a8c0@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ospf@ietf.org, l1vpn@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Adrian, all, I know it is damn close to last call deadline but I wanted to question format of data propagated via OSPF in http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-ospf-auto-discovery-03.txt Format of TLVs propagated via L1VPN LSA proposed as: ----- 3.2. L1VPN INFO TLV The following TLV is introduced: Name: L1VPN IPv4 Info Type: 1 Length: Variable 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L1VPN TLV length | L1VPN TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... TLV length The length of the TLV in bytes, including the 4 bytes of the TLV header. ----- So here length comes before TLV type (so strictly speaking it should be called LTV throughout the document) and length includes TLV header. Just about every TLV so far standardized to be propagated via OSPF has Type field coming first and length covering only value field (see TLV definitions in TE, GR, RCAP, LLS, tags and whatsnot). Wouldn't it be prudent to avoid divergence and make implementator's life slightly easier to follow the suit? OSPF is used here merely as a transport protocol for L1VPN discovery values so it is better if definition of service fields is more friendly toward existing OSPF practices. Thanks, Anton Adrian Farrel wrote: > Hi OSPF working group, > > The L1VPN working group is holding a last call on several drafts. One of > them uses OSPF to advertise L1VPN membership. > > This I-D has previously been presented to the OSPF working group and > some feedback has been incorporated. We would welcome any further > thoughts during the last call. By preference, please send comments to > the L1VPN list, but anything sent to the OSPF list will be forwarded. > > Thanks, > Adrian > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Thursday, September 27, 2007 8:17 PM > Subject: [L1vpn] Four working group last calls > > >> Hi, >> >> Now that there is a bit of peace and quiet on the CCAMP last calls, we >> would like to hold L1VPN last calls on four I-Ds: >> >> http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-applicability-basic-mode-02.txt >> >> http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-basic-mode-02.txt >> http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-bgp-auto-discovery-02.txt >> >> http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-ospf-auto-discovery-03.txt >> >> >> Since there are four drafts, we will make this a three week last call. >> It will complete at 12 noon GMT on 18th October 2007. >> >> We will be notifying the IDR, OSPF, and CCAMP working groups about >> this last call. >> >> Thanks, >> Adrian, Hamid, and Tomonori > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Oct 11 11:40:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig08N-0005PT-Gz; Thu, 11 Oct 2007 11:39:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig08L-0005P5-NH; Thu, 11 Oct 2007 11:39:33 -0400 Received: from esc91.midphase.com ([216.104.33.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig08L-0002ZV-3Q; Thu, 11 Oct 2007 11:39:33 -0400 Received: from esc91.midphase.com ([216.104.33.66] helo=LC1.labn.net) by esc91.midphase.com with esmtpa (Exim 4.68) (envelope-from ) id 1Ig08I-0005kT-O6; Thu, 11 Oct 2007 11:39:30 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Oct 2007 11:39:21 -0400 To: Anton Smirnov From: Lou Berger Subject: Re: [OSPF] Fw: Four L1VPN working group last calls In-Reply-To: <470E3E35.7060400@cisco.com> References: <02e801c8013c$9df58d00$0200a8c0@your029b8cecfe> <470E3E35.7060400@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: l1vpn@ietf.org, ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Message-Id: Anton, I believe someone else made a similar comment (perhaps Adrian?). I agree that the T&L definition should be aligned with the common T&L definition. (i.e., Type then length & length only covers size of V.) Lou At 11:16 AM 10/11/2007, Anton Smirnov wrote: > Hi Adrian, all, > I know it is damn close to last call deadline but I wanted to > question format of data propagated via OSPF in > >http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-ospf-auto-discovery-03.txt > >Format of TLVs propagated via L1VPN LSA proposed as: > >----- >3.2. L1VPN INFO TLV > > The following TLV is introduced: > > Name: L1VPN IPv4 Info > Type: 1 > Length: Variable > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | L1VPN TLV length | L1VPN TLV Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >... > > TLV length > The length of the TLV in bytes, including the 4 bytes of > the TLV header. >----- > >So here length comes before TLV type (so strictly speaking it should >be called LTV throughout the document) and length includes TLV header. >Just about every TLV so far standardized to be propagated via OSPF >has Type field coming first and length covering only value field >(see TLV definitions in TE, GR, RCAP, LLS, tags and whatsnot). >Wouldn't it be prudent to avoid divergence and make implementator's >life slightly easier to follow the suit? OSPF is used here merely as >a transport protocol for L1VPN discovery values so it is better if >definition of service fields is more friendly toward existing OSPF practices. > > Thanks, > >Anton > > > >Adrian Farrel wrote: >>Hi OSPF working group, >>The L1VPN working group is holding a last call on several drafts. >>One of them uses OSPF to advertise L1VPN membership. >>This I-D has previously been presented to the OSPF working group >>and some feedback has been incorporated. We would welcome any >>further thoughts during the last call. By preference, please send >>comments to the L1VPN list, but anything sent to the OSPF list will >>be forwarded. >>Thanks, >>Adrian >>----- Original Message ----- From: "Adrian Farrel" >>To: >>Sent: Thursday, September 27, 2007 8:17 PM >>Subject: [L1vpn] Four working group last calls >> >>>Hi, >>> >>>Now that there is a bit of peace and quiet on the CCAMP last >>>calls, we would like to hold L1VPN last calls on four I-Ds: >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-applicability-basic-mode-02.txt >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-basic-mode-02.txt >>>http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-bgp-auto-discovery-02.txt >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-ospf-auto-discovery-03.txt >>> >>> >>>Since there are four drafts, we will make this a three week last >>>call. It will complete at 12 noon GMT on 18th October 2007. >>> >>>We will be notifying the IDR, OSPF, and CCAMP working groups about >>>this last call. >>> >>>Thanks, >>>Adrian, Hamid, and Tomonori >> >>_______________________________________________ >>OSPF mailing list >>OSPF@ietf.org >>https://www1.ietf.org/mailman/listinfo/ospf > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Oct 11 12:10:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0aU-0003du-6H; Thu, 11 Oct 2007 12:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0aR-0003Th-JW; Thu, 11 Oct 2007 12:08:35 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig0aQ-0000G5-9G; Thu, 11 Oct 2007 12:08:35 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1Ig0aP-0004YC-Jq; Thu, 11 Oct 2007 16:08:33 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Oct 2007 17:08:33 +0100 Message-ID: <0c9901c80c20$f621dbc0$5102010a@your029b8cecfe> From: "Adrian Farrel" To: References: <02e801c8013c$9df58d00$0200a8c0@your029b8cecfe> <470E3E35.7060400@cisco.com> <200710111539.l9BFdWX2019051@mta3.iomartmail.com> Subject: Re: [OSPF] Fw: Four L1VPN working group last calls Date: Thu, 11 Oct 2007 17:08:23 +0100 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: 11 Oct 2007 16:08:33.0303 (UTC) FILETIME=[F8D19270:01C80C20] X-Originating-Rutherford-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Anton, Last call deadline is only the deadline. Your comments are well within. Yes, as Lou says, I noted that the L should apply only to the V for harmony with OSPF. I completely missed the LTV/TLV thing. Good catch! Adrian ----- Original Message ----- From: "Lou Berger" To: "Anton Smirnov" Cc: "Adrian Farrel" ; ; Sent: Thursday, October 11, 2007 4:39 PM Subject: Re: [OSPF] Fw: Four L1VPN working group last calls > Anton, > I believe someone else made a similar comment (perhaps Adrian?). > I agree that the T&L definition should be aligned with the common T&L > definition. (i.e., Type then length & length only covers size of V.) > > Lou > > At 11:16 AM 10/11/2007, Anton Smirnov wrote: > >> Hi Adrian, all, >> I know it is damn close to last call deadline but I wanted to question >> format of data propagated via OSPF in >> >>http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-ospf-auto-discovery-03.txt >> >>Format of TLVs propagated via L1VPN LSA proposed as: >> >>----- >>3.2. L1VPN INFO TLV >> >> The following TLV is introduced: >> >> Name: L1VPN IPv4 Info >> Type: 1 >> Length: Variable >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | L1VPN TLV length | L1VPN TLV Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>... >> >> TLV length >> The length of the TLV in bytes, including the 4 bytes of >> the TLV header. >>----- >> >>So here length comes before TLV type (so strictly speaking it should be >>called LTV throughout the document) and length includes TLV header. >>Just about every TLV so far standardized to be propagated via OSPF has >>Type field coming first and length covering only value field (see TLV >>definitions in TE, GR, RCAP, LLS, tags and whatsnot). Wouldn't it be >>prudent to avoid divergence and make implementator's life slightly easier >>to follow the suit? OSPF is used here merely as a transport protocol for >>L1VPN discovery values so it is better if definition of service fields is >>more friendly toward existing OSPF practices. >> >> Thanks, >> >>Anton >> >> >> >>Adrian Farrel wrote: >>>Hi OSPF working group, >>>The L1VPN working group is holding a last call on several drafts. One of >>>them uses OSPF to advertise L1VPN membership. >>>This I-D has previously been presented to the OSPF working group and some >>>feedback has been incorporated. We would welcome any further thoughts >>>during the last call. By preference, please send comments to the L1VPN >>>list, but anything sent to the OSPF list will be forwarded. >>>Thanks, >>>Adrian >>>----- Original Message ----- From: "Adrian Farrel" >>>To: >>>Sent: Thursday, September 27, 2007 8:17 PM >>>Subject: [L1vpn] Four working group last calls >>> >>>>Hi, >>>> >>>>Now that there is a bit of peace and quiet on the CCAMP last calls, we >>>>would like to hold L1VPN last calls on four I-Ds: >>>> >>>>http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-applicability-basic-mode-02.txt >>>>http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-basic-mode-02.txt >>>>http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-bgp-auto-discovery-02.txt >>>>http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-ospf-auto-discovery-03.txt >>>> >>>>Since there are four drafts, we will make this a three week last call. >>>>It will complete at 12 noon GMT on 18th October 2007. >>>> >>>>We will be notifying the IDR, OSPF, and CCAMP working groups about this >>>>last call. >>>> >>>>Thanks, >>>>Adrian, Hamid, and Tomonori >>> >>>_______________________________________________ >>>OSPF mailing list >>>OSPF@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ospf >> >>_______________________________________________ >>OSPF mailing list >>OSPF@ietf.org >>https://www1.ietf.org/mailman/listinfo/ospf >> >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From sreeja_subodh@westminster.ca Thu Oct 11 21:49:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig9ej-0004KY-HV for ospf-archive@lists.ietf.org; Thu, 11 Oct 2007 21:49:37 -0400 Received: from [206.103.104.122] (helo=jvkftr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ig9ee-0006j1-6t for ospf-archive@lists.ietf.org; Thu, 11 Oct 2007 21:49:33 -0400 Received: from anx ([82.190.100.238]) by jvkftr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 20:49:02 -0500 Message-ID: <000701c80c72$109c1a50$ee64be52@anx> From: To: Subject: You have one new ecard waiting! Date: Thu, 11 Oct 2007 20:49:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 This Psycho Cat Card has been sent to you. http://76.98.62.253/ From Klawitterodgv@allamandasurfcamp.com Fri Oct 12 01:00:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCdN-0003Bq-7q for ospf-archive@megatron.ietf.org; Fri, 12 Oct 2007 01:00:25 -0400 Received: from [84.205.242.105] (helo=[84.205.244.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgCdH-000411-GN for ospf-archive@megatron.ietf.org; Fri, 12 Oct 2007 01:00:19 -0400 Received: by 10.227.113.37 with SMTP id ZbzFslbmoaKiL; Fri, 12 Oct 2007 07:58:32 +0300 (GMT) Received: by 192.168.114.18 with SMTP id vzpwzTFxemozaQ.0089833880859; Fri, 12 Oct 2007 07:58:30 +0300 (GMT) Message-ID: Date: Fri, 12 Oct 2007 07:58:27 +0300 From: "Argyris Klawitter" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: tsvipnei Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed whats poppin ospf-archive charm the socks and panties off the girls when they see the bulge in your pants! Argyris Klawitter http://bitoffon.com/ From ainterrupting@cleenenergy.com Fri Oct 12 01:27:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgD3N-0002Y9-OE for ospf-archive@megatron.ietf.org; Fri, 12 Oct 2007 01:27:19 -0400 Received: from bb116-14-61-8.singnet.com.sg ([116.14.61.8] helo=cleenenergy.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IgD3C-0004g4-E1 for ospf-archive@megatron.ietf.org; Fri, 12 Oct 2007 01:27:17 -0400 Received: from pro9ea7f0138fc ([44.106.61.52]) by 116.14.61.8 (5.6.8/1.6.9) with SMTP id 38160bd949fa1a; Fri, 12 Oct 2007 13:27:04 +0800 Message-ID: <001501c80cd3$9432f760$00a57944@pro9ea7f0138fc> From: "Tonia Martin" To: "ospf-archive" Subject: Viagra 100mg x 30 pills $99.95 buy now Date: Fri, 12 Oct 2007 13:23:00 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.2963 X-Spam-Score: 2.4 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 buy now Viagra 100mg x 60 pills http://stepfull.com From ahynrqk@boegerwinery.com Fri Oct 12 08:43:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJr5-0001cU-5C; Fri, 12 Oct 2007 08:43:03 -0400 Received: from p6d18.p.pppool.de ([89.52.109.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgJqx-0002OQ-6N; Fri, 12 Oct 2007 08:42:59 -0400 Received: from [89.52.109.24] by smtp.easydns.com; Fri, 12 Oct 2007 13:41:19 +0100 From: "Herman Potter" To: Subject: Airports experiment with charging stations Date: Fri, 12 Oct 2007 13:41:19 +0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000E_01C80CCD.2FF67890" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QUKYEBW1YS1KFS0MFN0F57E7LV== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <01c80ccd$2ff67890$186d3459@ahynrqk> X-Spam-Score: 2.9 (++) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C80CCD.2FF67890 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C80CCD.2FF67890" ------=_NextPart_001_000F_01C80CCD.2FF67890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit "The degree of recovery in trading volume will largely decide how high the market can go," he said. "You're seeing a continuation of the recent momentum," said Chris Johnson, CEO of Johnson Research Group. Carol Ann Gotbaum may have accidentally strangled herself while trying to get out of her handcuffs, Phoenix Police Department spokesman Sgt. Andy Hill said Saturday. Someone close to Stiles told investigators Stiles is a "survivalist type" and always carries a weapon, Nye County District Attorney Bob Beckett said. "The Nikkei appears to be in a gradual uptrend now," Nobuyuki Nagamorim, a technical analyst at Unimat Yamamaru Securities, told The Associated Press. While handcuffed, the New Yorker became "disruptive" and she was taken to a holding room, where she was left alone, Hill told CNN affiliate KTVK. A spokeswoman for the Maricopa County medical examiner said an autopsy would be conducted Monday morning. "The mother has cooperated with us," De Meo said. "We believe that the mother was not aware of anything that went on with this young girl. It was very sad for her to find this out." "It becomes a psychological phenomenon. Investors know that there are inherent risks in the market, but at the same time, they're rationalizing any bad news." "But I have seen him verbally and mentally assault many people," Allen told CNN. "He's good with mind games. He's good at twisting people's realities and manipulating people." In Asia on Tuesday, Tokyo's Nikkei 225 gained 200 points to close up 1.19 percent at 17,047, its highest finish since August 9. Technology companies Sony (4.2 percent) and Canon (2.6 percent) and automakers Nissan (3 percent) were among the biggest gainers. "Sometime during the time she went into custody, she went into medical distress," he said. Investigators said officers went to check on her five to 10 minutes later. Police policy requires that be done every 15 minutes. "According to investigators, it appeared as though Ms. Gotbaum had possibly tried to manipulate the handcuffs from behind her to the front, got tangled up in the process, and they ended up around her neck area," he said. CNN and other news organizations did so until the child was found, and De Meo asked media to stop showing the picture. Witnesses told police that Gotbaum was "yelling and screaming" and running through the terminal Friday. She was arrested for disorderly conduct. Authorities have identified Chester A. Stiles, 37, as the suspect in the tape. A resident of Pahrump, Nevada, he remains at-large, De Meo said. Pahrump is about 60 miles west of Las Vegas.(CNN) -- Darren Tuck, the man who gave police a tape depicting the rape of a 3-year-old girl, turned himself in Sunday to Nye County, Nevada, authorities. Todd Allen, a Las Vegas resident, told CNN he once lived with the girl from the video and her mother. He said he recognizes his old apartment from scenes in the video. He said he knows the suspect because Allen's mother dated Stiles and the couple spent time together at Allen's apartment. Watch Allen describe Stiles and the girl » Stiles was a distant friend of the girl's family, De Meo said. Finding Gotbaum "unconscious and not breathing," Hill said, officers performed CPR. Gotbaum was the mother of three young children and the daughter-in-law of longtime New York City Public Advocate Betsy Gotbaum. Betsy Gotbaum called Carol Ann Gotbaum "a wonderful, wonderful person" and a great mother. She said the family was dealing with the situation "the best way we can." Allen said nobody realized the child had been abused. "She's what you'd expect a little girl in elementary school to be like," he said. "You would never know something like that happened. Ever." ------=_NextPart_001_000F_01C80CCD.2FF67890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

"The degree of recovery in trading volume will largely decide how hig= h the market can go," he said.


"You're seeing a continuation of the recent momentum," said Chris Joh= nson, CEO of Johnson Research Group.


Carol Ann Gotbaum may have accidentally strangled herself while tryin= g to get out of her handcuffs, Phoenix Police Department spokesman Sgt. A= ndy Hill said Saturday.


Someone close to Stiles told investigators Stiles is a "survivalist t= ype" and always carries a weapon, Nye County District Attorney Bob Becket= t said.


"The Nikkei appears to be in a gradual uptrend now," Nobuyuki Nagamor= im, a technical analyst at Unimat Yamamaru Securities, told The Associate= d Press.


While handcuffed, the New Yorker became "disruptive" and she was take= n to a holding room, where she was left alone, Hill told CNN affiliate KT= VK.


A spokeswoman for the Maricopa County medical examiner said an autops= y would be conducted Monday morning.


"The mother has cooperated with us," De Meo said. "We believe that th= e mother was not aware of anything that went on with this young girl. It = was very sad for her to find this out."


"It becomes a psychological phenomenon. Investors know that there are= inherent risks in the market, but at the same time, they're rationalizin= g any bad news."


"But I have seen him verbally and mentally assault many people," Alle= n told CNN. "He's good with mind games. He's good at twisting people's re= alities and manipulating people."


In Asia on Tuesday, Tokyo's Nikkei 225 gained 200 points to close up = 1.19 percent at 17,047, its highest finish since August 9. Technology com= panies Sony (4.2 percent) and Canon (2.6 percent) and automakers Nissan (= 3 percent) were among the biggest gainers.


"Sometime during the time she went into custody, she went into medica= l distress," he said.


Investigators said officers went to check on her five to 10 minutes l= ater. Police policy requires that be done every 15 minutes.


"A= ccording to investigators, it appeared as though Ms. Gotbaum had possibly= tried to manipulate the handcuffs from behind her to the front, got tang= led up in the process, and they ended up around her neck area," he said.<= /p>

CNN and other news organizations did so until the child was found, an= d De Meo asked media to stop showing the picture.


Witnesses told police that Gotbaum was "yelling and screaming" and ru= nning through the terminal Friday. She was arrested for disorderly conduc= t.


Authorities have identified Chester A. Stiles, 37, as the suspect in = the tape. A resident of Pahrump, Nevada, he remains at-large, De Meo sai= d. Pahrump is about 60 miles west of Las Vegas.


(CNN) -- Darren Tuck, the man who gave police a tape depicting th= e rape of a 3-year-old girl, turned himself in Sunday to Nye County, Neva= da, authorities.


Todd Allen, a Las Vegas resident, told CNN he once lived with the g= irl from the video and her mother. He said he recognizes his old apartmen= t from scenes in the video. He said he knows the suspect because Allen's = mother dated Stiles and the couple spent time together at Allen's apartme= nt. Watch Allen describe Stiles and the girl =BB


Stiles was a distant friend of the girl's family, De Meo said.

Finding Gotbaum "unconscious and not breathing," Hill said, officers = performed CPR.


Gotbaum was the mother of three young children and the daughter-in-la= w of longtime New York City Public Advocate Betsy Gotbaum.


Betsy Gotbaum called Carol Ann Gotbaum "a wonderful, wonderful person= " and a great mother. She said the family was dealing with the situation = "the best way we can."


Allen said nobody realized the child had been abused.


"She's what you'd expect a little girl in elementary school to be lik= e," he said. "You would never know something like that happened. Ever."

------=_NextPart_001_000F_01C80CCD.2FF67890-- ------=_NextPart_000_000E_01C80CCD.2FF67890 Content-Type: image/gif; name="footer" Content-Disposition: attachment; filename="footer" Content-Transfer-Encoding: base64 Content-ID: <006901c80ccd$2ff67890$186d3459@A9YXP7> R0lGODlhigHWAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/ /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBm AABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/ MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/ mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZm zGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb/ /5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZ AJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwA M8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZ ZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8A mf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+Z zP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAACKAdYA AAj/AP8JHEiwIEF/2gwqFFhtm8OGDiNuq1bNIC1XCxf6++eM4D2B1AZuzDhwW0Z/CAlOE4iPpMB7 2j6S7FdwpUuXMm8ODKmzp0uTN23qdDXSp9GEA18ZXdpTKNOnPrUBJemwZ1GBESn6bPlPHkGk/3iC JTl24CJJLmkGzdivLFSoNrO9JZkt4dV/dw3iw6dW4VWMcwXCUtg3sOGBTpdyhaotr0DHLt0WhIx1 YiyJh2+6XTzzLed/8KRl1ikaqty5PElS/ncv5+HUIkfLTuxz6tJtnw0XDmw5ItNs06adZrp7oeSF cuQILE5cNsk7eGoGdj0Q7N2KAv+wdM795j3aC7fl/xMIXidKfChRkiJ18jhB5t4XDico0SRmoBOr dl+Ym6rL/oE1tt9BCpXnU14yFRcLQZ0sFM+ALsE2ID7aAPhTeuftRc2GHK5GECQDzafQeD7BV1B9 vjkUy2WZWbhdT+4N5OJb2ph4GIDYTFfQaSbG2BGEJNFm12MyZpRaPtTMSF1Be/nTD4f4cChlkhsK RMtNIL53HHaxkSRhZSiGGdGKsEyy4FwzGmSMZ0C2aZCNTMlkIZcD8YLJP/hkwxc+Bhol3EB0NijQ Lp5wtheReHEIy5RV/kMnohnVhSeVUvpDzT0aaphKplFuyNWVBpFoEE/3wPmPiQ7N59AtYkZEIXr4 QP9UDZmP/iOiajet8sxAoszl4WjsRQboaHn5cyhObjZV2rADCeoRnkhSM942G2ojZZHYhoWPKv+U tde3SXY65bd8ckpNKpRuaOyMxwmVjYktwQNPQczYA1I/rW6TTasU9dsvLIycqdJWhvkjand9KhRI Nl/a9FmaN6UElT8JJxscQdTYBtK41FjLYT75HLqRsVO+yOteqmSDKaPpehquhtRMEyXMHDbTTDbN LNpoRtEMNMooTFEWUcfThFkKtQb7g6Jw1ADnbywBQzSQvTpBnGxNf1YsX2ofUWOqUf2gV/DVS6HE krhSoj0QielpvHFLlIrSsaf3xOzpzOSSK+U01DT/s+E0NvfdjMx8N3nTsk8V1apUWdX3zL7+Ru7v NNpMA8uKAbMY4qh+aabQrGKELrroZ3DBRehaaDH66Cs2tJA09uQYGFd6tohXYB2izSHZO0HZkh8y 5v1t549xmEoqfiSPLtqNAfcyuFCGOyXgzdwT+IbXey3NzEmiafU/raqcleTUSE5RlCuSuaLMmK+o H/FxGrSNGDfgYH/9+N/gww3848B///8D4A24ABSYGCY3YRPIrYDEsgZ6jFG8m5LHtLO2hXSvJXBL nh+mwMEO+qFl1RLeXvh2Kb/ZjITBOSGj9nIPe3xLZvj4AzV+pRC3/WRxDvlOrMzXr/TFAh+XS18Q /2MxjXtcrhFIbEStcFdDLtzvifkLoP+oYQgpBvAGg7GK2DRyky/JpoFg5BijqNemhIQRNiTCx/FS IbdOhYWDfejgFOL4Qe6xLG/nolz2SOg74dnDheD6lgyL9RLehEly/ZCcD9W3yCH68IhEZIQkk6jE //iphvSzgv/8F8UrctIQ2pDiJrNIEvR4cTLJOqMqw0g9m7lycEb53kC6dsawhCVJG7zDFD4Ikyht UI5z3OU0SLZCMfLxZesSoTL/hrcZGgQ7C8xWRhrHw6ctchjIWKQ2txkLSqaBkki04eZ4Qw38cfKK 6AwgPtDgSVKipkKLaUdgjskhZ6TCbyzLBsNUSf+9Vg6unwA1Cg0Vss8GousfIaPSFHRZx5BcapfA PMUpqGQul6WtJWGj6N3ylkxlBjJKq0mNxpYEpvxQZCKK5KYP9akNbWRjm+CMqSQZgYZJPso1JGVK OTe5yXT69AZnuKI7fVKLgiQQT6fgiFGw90rBrfJSBd1bcPzZj6lO9ZVrPF4zECesibHMGRu6Z0U4 lMspoMt4fRDOFLIAxynwjZi6ExfMYtKk53lUeHrSW7gGqpeF5KEKJm2IPyii0sKub5ExTexMGyGG STJiKrT5mkvEoI2e/vSnrxCqQnI6sOq4phVRsuDxwCole7rSGaQF4zRSwTR/ujKF/2wGPrCa1dr/ 3tNmh+GsjMB4UOMtVJhVakYc2YqPtXIwFZZKUuHs2qkXfkc4d90T3qBXxGaClC5sKUl9eIgQfxhW pdOQKSMacQXxNoIRhmBE6CYJFC/qtieGoMY5L4vZAJKyqAo0j5wk40U3LGKN+HwqGzWYPFQM7pUH noYiCmEz29YWwfj852GKAhzaSOmBYS0fRZDHwTvIjEq/nMI95FjH5OoVelCiGB7T1SSPFnOvkQoP a/CBooa0lLA+pIZKG/HIboJTGkhc7ExzMMkgz9QQSG5sOAvZHUNwgb5Q1uxAQKW1l3xEsv9wcICN hzzWbmiDWQjzQlEB23+mEHAPduV39Gnmqf7t/2KyrOBL7HY7JomroGDdcojPGqVUzLFja2XrB00M s+ZGt7nPo9KTpCe8tLksSB5K0kMi1y1tpO+lO4ZakSkpyfCed7yOnamo0Zte0aWXERWpcpUJYogt RPnVWCwJYoI2lRg5+HgbUsW5/JAFP1QYFX3odR/80AcyC87MyH6lVem57OAITmZvcQxzpNeys26D EL/9YJVSkYUnTYEaxu0DpQqtt+ZaytC5o/Ydx7XiYxHUISTCDPhcdT4cL8KHlk4fjzM3XsX2e6bT mKSSjXxeJKfXEGJAuOgmOZBH3IRqRmk1rOnLiFgbZNVfeU9Gbp0KsDpDFX7Qgh9SUVXk9eHkwf/2 A2ylkeBlx4xvweGTsznUbBIOLicgM0iwUMPbkW8DFsQ+rkspNw04FjeYyGWxHc2VV+gVghB2pMYx nuoyOy7EFUJRWkLwM769LLIQiIWaj8272CQCHL2MHXgjDp7kJHds4ZIcSCJ0MpxojkXiE/8pO4e6 HGQVZCwHMwjHSfuHOYqCb9o4efIUb8JpSMOqfnM5zJ0NODfXPGayvYkwDBPGVIyiYxukI6X8zEG2 BtMPptxrIM/DXOu2pKP+mHpFxahRALXi7ymadDXwYdh9j/3TiQX+qEWddkYArOAJH11jprFwJPpK RJ/B+09jMHG+90REV3HR4O2ZcjMLm9cjx7z/CiPf7DYHp3Izv3zfTumcKaX2XKnIB7c7vKkZcjit 94jHNJxRt3PfcboagmGBFD0adTf/p1ch4R5VsREPsQ2DRRH58F2fNnz/BmoU6AcEZwjFBzDjZQho EDqGsA3aIDp8IwY1VRHZwFecUx0F4WRQNg2wZn0u4SQGMRarUVtFdCn7B36stVoEdnLo0k8vRzjm RziQV2E1B3kY9xadhy6ht0vS80ti1ge6lHR4A0N4lDfwBD1hcQeiYC4AmDfT8ArtloD0AT6VwThd x3sSaIFuOFPMUIGhVgiXI0lIlgYmOF6hg0Si8w+hYwyjcw/ntURs0oJPRl8weAPTUAuJ6FMy/3gT 6CE0G1dbwPF5qdB9fQN+wnZ4fbNs/wQTzUYxfGNm6Hd5fFEhWxJnRgJGquB5pmdWh0J6pXd61IYP 0nBRpqQtePJAfFJsagSFLZaFchVdZRFvh9RDseBdmCNJKxJ8oTaBjOAKoNZY46Vp/2ZwYjAGULNe 2zg6zLA64cUlFDJPBuGCiPg/+EBfj2gQ/Ic1/DGJx8MwWUVsfXBW9Lh4IwdQzXAMjpeDROds3xE4 CXZCl5dC7BcVTDIq7ldPm5INghaFgWZcC1UhVKJD5NJ0b9RGZtMSzTAFqGAsfkMzjnZoM/MkNYSG EmFNPkRwjsWSFCiH3MiBCteBSZZEC9eNq/8DdxrTUsRhE48ifT4VA42Yjpe1jtFUENJwlAqBa/1Q W8nTa36DPMI2bEGIbOhSPXVTedSjDV0meW12QrGVGSPBCrd3F2EUNk/4Yb8ITMcViZcCgHl0Dx+U Ckzwhd9iKf9QdJsSJckgD6LQYRkGgMsQDyLkNaFVQzVGEY7UjP4mfHY4gQE3gcUHfGKQDeOFBkkm BpL5bzkpOjyWWyRRDa52WTFAffzjD+poQUo5F7c2Chp0lSiHctrWDK7ADDMXefnobJxgCfckClGp bJOnhIBjGIwgENZhlg5kT78kbmYEZhL5ZwFoLRqSZXIUcyGpNh0pCv7QkcezS83QRjP0Ufj/sAwO 9S0Mc5gnIiaKyZhk94bE92n9wG8Cp5nnRY22gF6rg0Q+hnZpl5PpRYiyIZpQZppRBgtiUIMQ4mAg R2x+EJUpx6Am9E9hpTyXeFZhdQes1ZsUik+U54kH2RO2gEp1tjENZE9FB4z3IItt5ZGwslEt4WcN CiUxt5YLtSFMgFzc+ZchgTeBg2syF5VtRC7hsV2zspIx5QaOeV7S8Iyho2McaGR7+HuetnYzOY0g 2Jl7+FhkcRgCekWh9D+WE4P/YAgY8xSrSRAOZghPiQqZCH7EJjdaGRyiMGwjd0LIM3KpgKF3iqeu 9AdbwFqudE+V4hz8xSiLZqLHtRFqNYt9/3CXBgguurQS5NKRfjMFosBGlkoNGDpbZkV6DUoyzXBb JyQKqFCqPiou8tOAKFWkXvd7k1RTFIgNpyZJH8hjfJiHCKdw+olEtdBpdhI63RQ6Y4Clo4NqERMj OrENhxhA28A/YMA/MWAtBToxRaEK7JEm2XBrEHou2qBBVBmn54KhxjNyBDanx+MHXxguq3U8VsBG ovCuW/YPbhAJmXEcjPJAiCpueOJn08BWbBVH2kloe5UK0lALcOUPflZ/UdKRDWqp/8Cd2/lLezlb QXhmoXqp6paeEIFSL7UXL/mxkrSkp1afmglwpqaHJXteeZJwjTCCJtgIw5qTMfuB69UIVf+mgoH3 D050RajJPzZwA6bJNwSaTuuoGRtxGu8VFto6DR/EtNlAYE3bZskjJZcYqhwmCqdwrqG6QVdJqlDA RqgAr9fid7izN1PCYWwaFlIYkVPQDAJLLtLwbTNzbtypttmWnZyaCnjysLu0EYEaW/jko6JiG/mx qrOijAQHq5uZXo2QBozwCsNHChq4dp0WcHa4h3xoCCynmZZJrMRqs1ezs176P6XZiPxjN+gEC/Bh DuQRIw7jOdr6Cmx6p9TwmkNoQngAp3yDPN/5rhrkCl0Wqhi6rlllMwY2thlRZWsSIdXCKBwmWwir S8YlZh9EkZySJxskPTBEDUxQqTF6Bw3/q7fcaU+1C4v48K7nIlt6I7iyBii6Vw15sCLaEGroJWSj hrlI5IGMMAaSO4F7iA2gRrPIN6wjaAjM57k5yQhFE7o4kFkB9A+k24iWY7oBFAOwsBhNMxDD4BHH wQ8gsRba6gq3yKD42HjO1gxeOIR7Cgt5Kgpe+K6iUGDHZmZOVTIx1hPz4iUbElVhhQcN9YSmx1bI RSEeozfZiyd74Qyc2gx+4GF4Ar5x+21AygRtmVzPsw5cKBD50BCuUxkqmQfnNb/2O0npJcbqNXDd FHDU4AMlK0ljwMZmd5NnPDoHjKUzG7MLbBUGITE3sSA7Kw0+JQ9DewNEeUWGEAO30jEq/7gU2uoH LEfCvKa7t5s8ITlgLkwIyQPDWiWodvNmnQxBS+U2pnJhZ+vDGhJHszgF2oChxGQsJLMXXBtadGtW uuQ3vzQNf9mgs7V+L/M853YMd/ktS6R76YMQwbGkFIhw4yXGa9fGAcMIpMAI+NDGGuiZ+Rs6NYWl 2eC56vWBPhAw4pQRqjgQqiC6rwDI/MNCGzLIhRxAhzDOgdHIu/Z4LMcMV+lyeeoHckmuF3tb2DPD SnhG6WFJLEEdyHpLFuVbm0KdHcRW2QCMhpY3pKeuetq2HclBpMqJG5IP0JYpFEVuLwMy45FzonIZ yBgLzPyGjQCrUYoP82mToKYKzBfHlP/bbwqHwDmJEDGbcGysOThxD8PBGUVbEIBwRa4QQNNQmoNM yOgUA0nLHdpKZnMKtfdsVdXSrfdUeTVjtQ9mVbdIT4P6H3khSy92ofUXYmFmC6IX0eRiKX5AxUF3 BzYDi+fSPTHDevhQN7j40Xkj0ggl0tIiELZw0tDohjWbdmhQF/WLuWccZIYwzQFzfEEGgjeN000a Ov6gXmccMN5hKqugEJOgEEU9fUoNtEpdmtpAoKU51NXxKgOxc/KxlA7mB2TmB6+gQVBZfh/GRw3G cQQ5c98xQ2ZTNmaqxRtxRsgjM7f9HRz00InK1sJzfxNLDYC0HeniN9ZjPdc5jHdTEFr/oRVYMSvI UArdNGoGJ0nciLLjxTBpN9lKht7r5dLWGDppUNl5XSGrM81iQA3K5w+icxmgsh/FWRDlBK3QetoI nuDUUJpaALQy+NTHECQLEdWDQ2BQWYTbuUZcmWYv92xTMhJ8wjtOgdyDlqccNA3xAG6J+qhZmEzn NkIwI1tScj3DKIx7EXgVcQ90gmOaNoEa+JgfyAio2DTU8JhZaoGa5oGhE3AaGBzw3ZluMDrbLAYI gQZocAhoN4KNABRcdRNA8xbVcMgJPuZkjuBedNBrMeGznQq3/YMN2nJXdTz+BDh/A5ac3D0mEyBM 8ScIbVAlzpZwNEMs/lEd0jKv5Dy0/wc9euXXJfUPrwAblpE+/TaZn1azpCYGjrvNjX1eUPNpOCkG zWCCVi4c3Cw605yCCUdTpSYG7/MUX15V38EPTw0SqlDrW7AFZW6aMQADvN7rpcklalExHqKU2nqu dMqg07AIZxanzVBVgGu1bnvn8DNLEKcTSLGasRCiA0PiMxRizyluM4MpygRz5IdClcJRjaZu4bI2 G2sS1HALIQEURdqMReaZj5kHAdzYRb7pMyXAA8cI9yBqYqDfNNuZNKsNNTW/hnAIqiA6rc47BB4W VODrQbnrvB4DuzIQauFMuPIm5OESxb6nJazsV+VmgqNV0O636uITJMUcZpMQkvUl3P+OD94uZhDd R3g0c4yGD1qQJGGTheyGNvhA0oDNNybBgLbkKD7khv0ZwKpTn+r1zbFwD7qav4aAh8l3XgU3DUg2 U+t0xgUvOla+76C0dkikCGKQ7QD6FpzAFGCB6wMKAzJkEoshF2pxFQNVITdRW03ZZZfo5rG17H7j 7A22Ws3wsG91GMUhIHyxasUx8ycnkabXUBySUY12V3fw0VMyOL7z0SIN2MPhECNRDXqr9Nao9fOZ 9tDIWIYQs4zQufTJn/mbzLNKjeq1CGewXt0MqzO1DXr4CFrKFBbSF3kgohZUFGJgP8q//DiQDcp/ A7WyQANNEKvw2bayx1uk5lm1a8f/830QemDIVmYAlgeC2h+LrPF7nBJ8rFNhFMO+lMqmBytydZ7l 9uKOCkbo9qhno8WA/flo2gcA8e9ftVgFGR1EKOagGDGNGh18iDANQ4f3GDE0BHEhQnwIORoCmVAh IzQHSZFilG2ax0YUtwmEGVPmzH/3+tHURhNmTp0xq4nBEVToUH84uOAQsw2fzKX+YN7L6RSmPJn3 BDrtt7Tnv1v/Un0Fm4qaHz+pyJ7tU7ZZs2nT/E1jC3ft17XN/kyjJnWmXpivtsacNvOeXnza+mX7 O5PaYsaNqYnys/jOlClZKlueEpkaPnyLOX8GzdnxaNJtHX/eDDNf43wD81X7l9dr/2aB1WB5PEjt YUY0FB0yirhwZLZGJbPFYpkxN+5I/nDjVh6xETWVFxW+TPzP30utMVNX7dl66zZYR7mcNzoUhzah SXnCDCywH7WrMunLjI+Pb09bYcP2OwstP/pAhZq1/KkLrrbWMg2vvPzZD6YIYUnMqpgihAmxrW6S kLTGzKJmGsoqu4wyzTZbhJDP7hFtM87Yyosx/Ug7ZDRtqMknn2nuyXG1xpzBsbUcBUplimn6qA0W h5ZUpa1GMmqIIo0Q6k2MjH4jTpEwEHrot440UiQfbVgCLrjnHmIIu60i7G7Nf6rQAiedtpkIKPXQ M489H/aMz7uaNMQwMf0S8w+sAf8DPDQtxvwxUEG52jLtwUC1m1QnC2N6D78126zNw8VApMayLDAj 8cTTQkNts7xg7KwZVRmrUUb9+vFxGnx8XMwZIHOsRshUwKBMK9t+O2gaZ8os6SIfGjJomifLZESb iFY6k1guic0HONyItdY6Nf+yRdN/OJ2J3Atj2iaWNMYYY12GuNgzqHjh1WZZHE6hJpZvp1HpH8Oy A5imQr8iKy1E++hDrMZggZSttRgD+L6A+7wq05g0pEli+zylJpU72hI1ZMv6aIazahpDNdVFHXNQ 1RbF+2ebnGA7GeXVcqSv4ym06CMzq7YhqKBGajnoS4haEiONRtp6jhFqgXuaGov/mjazaatFauRb cAHTytyAY1Y3jXXZJZsheX3AYU97g+LiFKPEiAU+7TD+uu6BzUK0YD+yKMvTVFxd7GuN/6JYIIvr FghjjnUWyw8SR8Usi1RUdlE0fAB5FWVZU+5RSOx6Fe/W1b4aJZV7dO55irTGTVdo4pY7SBpD0BRj 6qoZ6cejbMp07h5qzexWW46+NLO3rBHPEHmZtqFTbOefd95es9WjHilYYKOGQ+W/vjvvRPvIouPF Aw9YG38IIQRxCLeP6R5pYvMQlo7v8GMax0UeMbLOTu0Mn0BalJU/UCUr8VTDgMwzYI7kVzpn/G0x p3OciRyHJIEALRa3WdK0jua0/251kCWN6MhDbHItMnnEH9nikkQaorW6Fe5rzAtbu6A3wzGIAW1t OYp61OaDHMLtW5din2KINDDvfS988+EY4gZHuMAwSifUmUktaqESfj3RQ9Mo0hRSIaop/IEyfJvC HTYTBv71L0YD7IytKqcffPSqNtUA2kDk+Aog4UhqsYmg6iDnB5ggsCBCg4izpLOkDRYygweRlvA0 QkhoMbKQjDDECgF2uHPVTV34kOEMxya2Gi7LTrYyynm0YIO07VBtjIBNTYLYk/h0r4hpQdgoPKGw G41mK+bCS92w8b6tQMo+f+FYKvAwImJ6cVSUSQWjCOEZzsRmf+NzUeeG9A9pCv/JgAZ8yugiyLc8 8rGPsQja7qCWwRBNqWrAy+AhhYfOKZGpOJIMGMxoUqmZ0AkfYsuLJsfGrj0xhCGvuIfadGhDG6oN bkBc5UwQ48q8IWxA4FOdwvpRy+9MCqH/mA+E6CkhpxQmG/6g2y23EsxhEtOkpfILfTrDKBetcTT9 E13nQFfNm1FTID7CY/7IMiK+yYQgQcMHcVbiSG2l8zed4NYik7otRRa1S2g63rjwQaGeeC0mtqBq dtLgD+gV5nns8qcYMslJMWQjrGcN6w6nwcKECmQprkxLNgaUDf3cIxvUQJhlypIKaTyTUj3BEPlg 0qZMObGtG1vMXT9U0hFl46T/JrrRagSymXzggx0e+gxNezRTad6nZqk0S/5C+0XayKQgQVOFYf4Y C6Mu9SHCgMgiXtHOFBJVnRH5ikJSGZO46cSqTBHi8qihT7KNwZNj1acmi+tJMUxjWVndSm//YjEs EvFQJ0JYXiEnqvp9hUOy6UlI/+GgmHCqOw8SyDEOC7/FTEMbzxTmiF7hWJ6SVosqFZ1U15EyzmjW v5ul5n18lEUTpaIKI0pd+mYCx9at1sGsLVNrzZm7oy1JkNz6Q1MJCTfY/LZcMtmPPTJGk22I9as1 DGtyVbxisooBuj15sZxkwlCyUMd+xdhujo1EFrGwdH00scp78OGM0z1lJjwx/yxMkHFYln0ogiIi JhePmbDavAY2/8XyZivrFl6lUjyjjSgq+mCFk6JiTqd9MGu7pOYOGlU3o5BO0T74kD/E+SC9Aafh /rEMY2zvx+O1wS9p4k/nkY3Fz3tDIw6dBkOgmCHLYutfzGWxu/3humTJQjaIkePtIowZfavln/ei GPJRckar7EQwrOih0L7ipJEjUWacAZMEZhnL1fCHNvKRjc7FZrJ5jGgeYT0FM/cEjgZM82qNqg1p JfUenvggNSJ8kN2lUziw+JZ4E+MMecTHKs38hz2mABPtLRhes1WxjRdNXH/GC227ZYrX4E3uGXeP m3sbFfh0nD/7iSXUgaLkZP9VKhW9iDpgF+3JFTcD7CjbFzN9Y15srjlxK1+zR/OY+CEmXmtexQbM mfl4meXTE+T0INl/bARy3uuQZh+yH3aW9pKqkUjoRFK60+ClTlyoGCDyRNs0gUXakrHu5y2CxWdV zw1iPPJxCXCS9iFidrULOWIabK9iETg1zFc3iI0YeUvcghU90ZiWMbzhCJ4CFZBJs41TvOKg2/j1 euV2aoacYI9FcCoSN54tpRw5rW0Ezcek4d8Qa/BO80cjmAE8hty8PpZKjHvL+xeMrQ8WDCkF0QGR jTS8gt3tTroqliiQndObe0X6CicKRvUvBugrCV+UWznj9J4sYzFO+dZvhTz/WEaBVCZhAC78SEH2 xQAI78fPH3iPsZhrxuTtE+9UkO6zmDxSA+Rmzwwh/FA6ve8FQ0GbXUFg4eAMttyccy5TCBuBCkaE 4QwMud6Rt/LRv9gEU27KGKHXHQzlOloM6BEKLhC9rUA4DskKxLEDsNgEnoqMvhm9SnKMjYqJZWCp C3nAwXo8QRkUCWEvxmgZuUK+xzqmyhCLl1Cvtms7WsMmm5osMFOJvdqpzDgLRgALiJHAProNK7Et RsCH4OAWh5iGV7gt5/BB+EMeyWOlydqJ8IoJ9YqJy2OIdZsGsRmFFnu0V3gFHLiBLdwCbNue9zKc XOO6AHmgr9Eoxrgr86En/43RuvMKGA8rF3CjKA9kjJALwfqijD4ghFcIOBSku475OMe6OrL4gxpc jPgDMcRJF+toCDtzJ8BzxGubt7oJOO3QCkDRCWyQCVKYiVhgCORyHm3oKufJA9BLhSy8AS00hElE nH4ot5iYqLphEd8yF41iKerQOnrCmH+5CvBKDHrixaryG+y7w8fisa77CwOihlEANirwA20oFFdZ r/GAQn+6mm25HeHwoXkKmBvUM4VCuJlgGBODnuF6nlqYhrPigv8bCkNAxFUqDH8pL21wkGx4Rd/q iXvMmMaYKIviCYvxxQvMwO3JC9GDhVdwsmJUSJ36Cg9pILNgLLLgvq8Aif9cmsaAIQ9l6aewSkcr MQStuxFmQytGkK5/OIVlwMA3/Bqv0cS/2AZDyAZYAMWvAr3qWcVpxIdXzImfy0c/k4qX+jGqgImc ATclnLzx4sZVogZVYBRVUJhPIcaFNClSGRFSCBAqwIOsDJBCVBi+4MmtkKfDIo9IKigfwAdTQitr LEmdu8jBOpzS2waJqQZD8IFsAEUWmIFHQxvqEUBWbKv9KL22fLwPYQw19Ad2SByD0zrBkMfsMISv W0pqaCAnC4ZOkMrLnIJSmAI8cL2G/IefE0jB/JqgAaR286fxi7SZCEzRjI9KjA26JMexCSsA1MIb 6MLVvMivFE1brMPC9If/ftCokOo9xcgG3YwJMYBM0ZvMxojKO6TKx7I6zwSyq2gT3BTNhHLNDfka 65wubFiKcNmKuRQrtIqX2rRNwTLO61QefVyTM/SQjNoYDEnPr0FMUru9VKgjIGnOk6IGXyAGvEOU hry9bsw19jysNNjNaSw97swOOBwIgpoXodhC21QF2HiPd2CG+YwJeRBK9dSJqAiYAZ1DGQExwRKI aHCr0HxDC+nQoVwZx8C+56QM6zOpzkTG7WFQmZi17OgHq0CDaTS4w9K2HGUfKBqIHEq6G3DHbxE1 DV0vZqMY+6uqb+zGbECy4NMO8mmTYiOURfgam7AYDemYW9QG/SQmKAuW/zPNQx57vbqJkGpIBoDx i62AriW7SC9NSg+VG6Yw0LaiBkPgggml0AvkCyJNDA3VkHjUTtl7Q55YDIu5xf1w0LYEopNhSsao vpPCB8qYBkJo09Rc1KIUCFhoh+xQhboRhpgIA+D7mj+Ik5hQsFHT0z2VDwmkhhfoPuWxjfO4HlBV z0I4BVyVibeMGA5szJhohhnTAn94VeyAkEfVKJmgouwUCBGbiUJ4AVy1xxYal50Q0DxCUx57BX+w B0OlicJ5rz/I1tD0nVmdsRegqmBMRHclPeWBgVfViQOkPf64mITjiVP9unr9B1iAgYJ9gT8Y1pkQ Dypoq2QVCC3I1hegVv+ZKDcJlAZRGMqChYEaUDB8CMxgAAZYtAoncgrJDK368dTBcQulPNbYkNh1 zUdzPSyChYX3qoIu0AmnaFN65b3s0IJX/VmamJFwvKq9yw4VpQkOEdMXKASROsoXMFV4zQ5XwFdq CNry0R5yoSSMvVVFUJ4+uQcLkQrJMlF8jJl5CMtu/QdV+IIXuxSpqAYYgK6rVc2voQJ8zY5UUNcX wFuBUAWJ9QoYYEW+MBekFZRMucfCKASIFVaZ0IKm/QcYgFwJSdvIs1yBYVwtyNV+RcqHjROe3I/D SYXMndzAHVzveAGK6YfSzY6Zm4ZsLQR4q1zPBc/tFC8OCZTHnFJ/Ydb/bNUCMCQSMmDFNnFVmZDc JPxF/QhSgcHVakgFqZWJP0DYv3jF/ejTiEEo8aqGn9U7uh3KF3hAaxXMfomJn6WQ7WXdz0yegYWB 7uuHwOiY3R3KnwXYVDje7ICZ5/XLrVgFmCDY6cVWeGNPgt3cfygE+rBSmsiGi7IK3HxMMiCDhKPf xLlfAqwNgahggJHZ9Y2J0YWJe70/ahBcQZFVtSVIhHMhLQBYbI2xP0jf9nHXQhhhgSiEAgYMmFBX jcmG9pVfl+1bFV5Ux+3bgDnVuJ3cuIVhncjh8sXbkBzKnhAxq8LYv4AFvnVcgO2J9+iKvz3VW5jY IBIvq4UJbMXiqwDi/+nSidbQtudduoObiUL84FelBZhQhSH+WoFwhYHw3uwAYZhIhTY2XhiQiUJg ttbt45j4A4E8nGpg2oBxo5jAVo3BV6t4wIL1iUaGxboRL6cYhV6qBhVg2Oilhv7VCfEK4MRoySDa uUKYXIidtz/YBgHijL6VYRjAIvuA2Gl4VWr4g3v4Cr5NpVpu3K3gCRd6gVT628m9htiAgbiBBYgt YwOGgWwtYPst2O4LAy2AgWiA5lFlXEF2Swu5Vbw9YD+GWBgo43GGCS1gBmnI1lxzTYhdIgC2YkiG AXwYZi725hco4721439Y4tqYXquoYzxAZ5hQB3Ue2Gyd5noWWPbhi/+IXtvXned/KAVspWWDzVW6 fS9+pmPGnYZUZsuE04nFhYkXAOcxRtjt9V03EGjY4BeNSQXIBeGZVld80AJq8Itq+APYeF6V6mGf gl5s3Vx8KOdXiFi57GmvAF9EXsYqAN/tJQS+fdwx5itXOGTtkD1tKNjd4tLiFWHBvVWGjtgifgF7 INqreN3pXbDMpbWlvlWJOeXnhdmHRdipHj1sTV/EKN64Fets/YWI9WiKBrJiVp5MgRltcMrU1QmW dmie9ummHghMpmvwIlgDCtp27QnNFpcjq+JUcgG8rWPDSWRcRdDttURtjglVaNpn1bumlWeBeAXU ftiUNpfrrWoDht7/h1WFpUhk1a4NLeAQ4H7YdRZkhWkGHqZhgK3iXJWKPsHoVEJRA35V35GGaRju Y76QF4CQsBVaxIhtoCttvVsFQ4gTp8hpJhaIP3jmlGZkvZtTnZjm9DVpGh5mV96JPa4KJy1hEAtv xRjv4DZuOvZogH5muU7p3xSItK6JPpOJOFXg98jWnfgzf5Dh+9CCabCHeqgGJByIlG4SiSnY70jv Dy9dcrle+IjkdYaFVJWKQxZu+egfGp7cQ37eBfbmMdZuw4GK6HVol81VGa7xH97xkfpxmljxf9AC qooFwK0Npu0OENaQrG7sa0ZdvaMPvY7jwbrVF/YTb5S/vTjymfjp/4f1rBfAmKmGN23A1+eNZjDo gexwwpggZQXG4DiJ5SG+Wg++ES7mEOld5/i+VYSlDw/22wIfyJbtJabGcPpI1UPvvlToE3122ekb 5uuWGM1dZ3zVhp+DWHy9cB3vvsv7UQmhcp143n+GiS14VUN/BEpfW2HNCS7uDtFT9e9F9BXPCaKe LEwmEkS3czAWGJz+Cy2YYkOPdaYUCD9IaYwaZiWXbJpAhnVYr6BFdlrDZC1AWKtQ11S6VSyGgZzL hgLHabZW12gGc5n4Wwop8caU4VTSdhze8eI9dPpoCxCedcmuBk6YXFCF2O6DWHu+DzfvEF/fCnX1 8tq433gXiEQo8v9QvwkZDqk/yAZASIy/xVfi1m1kBnbils+YQR5rVYVneGNqSPjJLoRZY3iA1m5/ iFu2dll4C+vsiOUv7gltHu2Z0GdGhtxbBWdFk+y/bSI2H2G7wuQQEeQ6H0ixTYzm1nQqDdpteIbU zRmU3vLa/l7glWHjXocF3pGt+NvphYFA2/R1rgJcu4oyp+26/Xew92ie73VBxo6grQZC/llywepA SIzwtuSyr21462NoBCzlsQp+aIuYIAVPUG6BhYVT3fmjt/peP9UDZvMh/lsbFsxPL+ljXuw4sdp7 tVpePmb3cufvOOQQwe7Pd6/0xiUqTThqNj2UV/IQiZPRBX3NPdj/Q8dX0cPi2P5Z8NXb7OxyDKYC lbrsD7aCpVjMbrdfzJ8sbXZ++64Gp9yZgdXmnM5pnt/eVOhw+sD9+yiE6977HYeBQbD3aZjhf5CG +HbZns4GLfBLm8/iBF5nWX/ozwzgzrf+2zf5aaj73wWIajAK/dOi5c+/f9VepEro8CHEiBKnSXT4 R0tEbQm1wKCmRdWLkFqohXyBcdorigZfUEtIkqDLkiO3hZzW8p8/hxr/ZasokWTDhPkouoSR6k8q as1EkmRq8p8qLS8QboRRzaHUkKoKhYQBC59DkC13/kvFMuGfp9k6OnzZ72HWkT4TTpsGsyLHah9l Nn1KDYZUVf9g/zFEalYwrIH/pvUsiBEi4H/abqU99e9vNqL4XtwdXJLo3NCiHWbL/I8rQbAKHars uPcF4L4YpWqbptFZ4VQGq14VnXP0zZ+9JUoNKhUhyY8JQQKuxvWyLZCCsU69rE25w9/a/OGbhu8e ztGdteULa7LlveOXTU7naHTh3chtTcIqyFnyQ67U+v0W+HhjSH+QVdYL0zmE2mgggRZWewUCSFFy 01UjjVxQnYdWV0ElxM9CLwx32gv1UTfVcP5ok42BCQE24GgtigYSRjs1008qqqjEEIDIsYcWGEH5 08wrcnkk0ocPhRFGQvj8JtElLv6jmpMRUfPHdGlJBGVbFfmz5P9bb7kozShRQqTNPVTBJ+aY2rBV lnxXwgWDli0G9hAs/1WEJWtoJsTVYx551eJaegoqWmBkwVKXly6yuCSawQ3qm2iF2MmRmxBpCNGS mkW5jKD4YLfepXpW84ctsP3haKX/KCZRecDBYNRydjr0SkKNRWTrQ9K4qJtInYlGTWf5yPMosQLB sJNuaK5T5D/b6IknsT4xGs9DGkkKmawOYakRtZXiGu1oMKQoVmj7LQguVFYVy9WOFdEKrUbnJqQr uhWpoq5L0eLDn0RnoDGacyKlGCUyt9YrqLzZPeTMmP50xlWo2j7U6sEPJfyihw75NxeZWdar18AV S8RieFGSLKr/cs0kdLKT2iRaL4v5gCfmzCLrlJCzc01T80OMSiTgTWlRVfHFPp1LTdE7JVdeVPgC F21WIQXFssjB/ZazmP2QNZmLUeP4j8qX9fzko7CEjCY+ZH07V81rQ4RNRqNx1/M2RYfms0RcadPu wf3YXdHfYzpUJ2ywViQix3qmNdVNVIv8cpKhQQ4RtKMtfqpEie7Es81P74vqXLreA17goJmop7Og Ve7T5FGKYXJE3dEcZU4Utwj6yv+0LijeLWqjDdaAZsTsQ26LGUqLzOCXUKJ41iLygNvYHsvEoy24 s6LEgoVPNvesbvO/gxofWuAG266nl47Dnnto5/PU+YbgFuOi/zH33IQllvT6NH5oVOOdDdwAZzEn 7U5MVoNftDI1l+65rXyYAtdYbKY+oUAEd/VyILq+xbn1xclF+Pjedlikv9Dxj1g1+x4HETiREkYp Hgx7CCJGtiWI2AqFKhxbraKUD/XZ8IYP2aCLrhC5VI2mhxGZRu8Ad48AHsxRRhQNC7MGRB9GJIba 6p09aOikJ0Jkig98X5T4ITkEIu5pEJFXXSKyB/ZRzodKmkszLIg+C+JjE1y8W2iMIUefjG6PQ4xS HcVEFj9iSY864Zw/KFJALfmxZHMJZES8OMQ7GlI0L5wg7oxnmpF9UVuboGIlH8UOdqzmbsagBCXw cZNNoFIUFf8xxif/wUpUphKMV5plLJ+0CWNApBm0RGVLZunKiFzljgk5JTATMktanXENlIglNWgZ tsy5BJf7+eAmgJGQ39QlG89UjShQmcvYPQqZlLiJL7/ZS3EqKZqonKbF7qEZXB6Tnet85tyE2UUB Ai5hVDPnKlsZEX2CTZqiqaM4ExLOZ96EmdSYZdgI+kefNEMTzdglJf4ByydRAp4J8WUsN+FR/Kxt E6Iwhi9VNkteVsSXBf1gRyXSm7lFhKYOSSlGNfpJfKSiGYxwSD8o8QhZ8nKXBWWbLE/aDHyolBr4 EEV5VDM6aWRDFJ/0JVh2qYeK4fSU+1HKP6z6kGiqTKzT4KX/S1mDvYeYFKUdxWpSxxrTTXzyHjuN 6USj5bauZnSj+MArT7D616VSwg8vDU1bUwrXUybEFgmhhCtdKljAjgarm1gGWOqmTJayla7KHKlG QNdRQ4IlJ0atiFFPC8vKpc1JllUFlqZh1EUENpaiEMVfVUNZiLxltC2B0iaosbVogiWoYLOtKKix xnphlRpzg2U/kAaRjWqrlv/oKCoi5hDfku2m46RuWv9hCzJx1oeASOVOIXLay6jWjglBUkxR4RPu frAt1j0qW1lK3dtB9rIJuUdOyMooY5w0ls98pxbVS1cnrreC5yTqRzPKOWNepr9QKV5H9RdNp3aU uJ9FIV2D/6tezqpGpLLsyV85rLIJRimaYlUmXdXpkBB/08OyHKmCRfwk0zR4tRy9iSTISsWEpAIP L37IYMfKy9+9LLd7KmVndfyQ8Gr0wA8+LZWllRN/UGOhKruHNk7p3pzldqPaiIfKfFmanSQMljJ+ UnkfQt1wYjOj/5Dk7bzsEGNIw47wSAhtQepK2X1WNG52rzLTKFdW3vSZw5zHo3Y2OslEN5z2+wce 3OvZGWtapHa+saFZaUeNNGNLjkrpNMJ5EzHjqVUJs6mguozgeiL6mNnQBkLZig/bfcgfzjo0PgKY 5D131B/erHKdxVRHXxIFPJvejomp+8E1N4MXuwDbNFAZEf+UmnTGFiy2MsX5aTwX0dNY2vSedkYN e0T30yaOsLane9Fh/kMacfbwRRcTUl6iShojVFRjtuTpftioJVTeBL18Gc0ZTzOdn97zvAFcniwb QxuUyPa5x7m8xTykHxRu1k/M3Vn1ijtJzwaLwyMiinnXO6XTtc2P71xyQNrxwQ6RxqeV9MuHg9rQ Xc7lLknmUjztdy6kCM0b65jiKT/83Vit5bDzSI39NlinSTrnNMKWZS3jJImxq/nPSf1wURDl6brF 8bZ/DqWlA/Wj3Wo0DnMIkW14vYOUiwfbP5qwbPiVEj5DoR7F6vJ1/vacZCn6XPKxDVg+1KWb3sTb c1e/Cqv/zMlz0UIzuD1NowYvqTvpO9ohcvQ8BtfTsgzpOK2a1U+auBneCc1oL7r5OCv8pbJdvZNe QVvR2LXxGa19g33p7KKinOcSib1IsRrmh1s8q0VFPZLP+BBO0W7b3DP9ph/KGlh6J6aU4GXdt5t5 2Qs5IsxAxzHCugl/gD5KC30wQp+JxB671+Ghv+kXEjpjYygeq1wG9zbIw0rFjZ68n3Ah1O1BWPy5 lzvtlkRclP5tVoSBhTm53gJ+TxTxUbbZXDrt20cxwzNd3azBET2FFSptg8Gl0lPp3wUilUMoT/Wx UT/EAzDR3Sy93i5hQx3hXGT9kjbc33El1PsBE1bZhDjl/0T8xRke6VKS4EkBfVwoYQpFsJiUdEou qYZqYJKTRGGLnIvdYNCVKJr19Mb2JN6Agc6ANJJoeMkqnM1cMApZYNMRSR8TSUT4HZMfLcgdLuES MspvgJCe2Ioatl1NuciSaISX7KHNMAZdDJDOINAZZMdOLJKYKKKLrAKk9A8hikYdIlDClJFPDAh4 OI40yJM8+Yz62AoQFc2SGFNsORJE2E5ractOxIs0DAgl1ss9fEvpiAyUKAI5FVGLWKKWzCImPtJo UGGuUFESgeKd/BAscp3gVASucE73sMySZKDOJNGHaMOwqNW8iNF/beLtUM+QfdxBPeNcvNA2iYmv IB0x4v/JFCmjQ5DOKhwj0kWfi0wOuXXcWCURriwJ1myOwYzjRNTMH/rjo9xaJo4JgEWElwzikEUj q7SjQ4ABGCREOoxDPqIJPL2Ri4SJzUDL7jiOF32HIeYVFEnEzASOPO4PETXiWDliG/FEFm1JTiSK RPoENZSQ/5yMl1TO75DGyDgW9CTEObDRQ8zUQ7yDiyBRlFxaMEbEKIikCqmGNk6E3cRLi8jTPirl RAhjF7rkZaBAdKHAP/jBFOwPKSmMxIyGH2zBr2Rly4zV76QCWkoDBrlPRQDRkizJOZBMIvgE9Y1G FpULClADXt6DWk5kJy0QPRIlFG0QNSQmXqblFIgRO+L/hRZAyVucDFjMDCE5SSfOIWmgZWNWhMFZ pD46ZkIwg1O2DLLoZWpKxNrkAzfxJF14pUU20lBJxGGKht2U4Tah5lrORTvAjyVqw0560J1VxGXW JkTgAQHmDstwT0KYI7rYzVs0Riq8gjZIpyCJjHZ2zjQYZ+bw4sqcQSQ+z51AzlvkROe5SD/KJERQ y2/8JXqCTUUIA0RsZky+oZO44XZKRHQeZ0RQp2hQTXOWBQpMAQqgQFBA6INSQ2VCqIZMAYWuJTWk xGVmA4K65ls6hFE6BF5OAQxIaEJsqBlcqIqu6IaWpWLSSmMOyMnUp33+0W/8FOtIBDYsQzGcaIRO aIRO/4FNPOiLNgs8FKmMpoKz+MF/MFM6PpINtQQx/oMhiMaJcsKLbqiFImmGxmhlKuZ+DsrJTAMk QIKT4GVD4CU1pKZaVqZhPYSGtsQU+MGY3sN+toJy7g5DaslVsOk/bEFiwukUnAEKzKlD1Ok/3OmY pkJP1KhC8OVz3kxEcAInSAQ7uE34/ITc/UM+6I+guqmhyimSMaqjWiZqfsFoZOR/SYJYJgQsuOfg UA0QlahPsOkjAEOhHmecJqpF1umPHCmZYiax3MS3GNNlJoSERqizJmaSrmhQ/Gqx1uZgVszpPAnP MKfHQCdaMitePiu0hsoUTOsUVOZZGqv6TNgiSOlcmP9DBT1ldoDGsv6DhAKCuFYmuZrrmLZCmYaG HzBGT+yeb1xpQqyCM/4DwVaENnyrvYbrs+qrTvhDuXoPtR5ovVRjlNRrs16KxA5HuSbExf4rtsIk NOaqw04Dm3KZs0gsnfJrYr4Cja4lHC5oi/CjvOLMQyxrw+JllrZFtDZqQ/gDtTIDyVLjW0zDKDnE NsxnkqiP3TyDvEQixzhsx45V0LqeyJ6rqhoruIghzYzqfv7q1MDoZajso6LmvyWQ1igbyqaCNuAl PuDp1rrsonJouaYtl60li7CQwYoNfbolkakoPuynPFUmnmjo2dpP14rnEXlmgYpJaVpKNrTp2HIt ueL/bVI0bohGmi1tkYNS6E34QZF+aeZGaEukbV107sbpyYKkgkgCaEEa6IOe51iQboXaLYwyadqm ZcKUj8GCYdyVhTZAaDaMbul6x7loKJP+SLWyrguyppgQxbU6ydruLDWIrsiWru42qphyLrqw2ezU a+zMUESELPPQZCGKT0UUDMdM0bJqjmig73geDF0+BNYYm8Ni4/mGyv3WZOtGCUX4Q/UKCq6Qr4vQ 71S6iDD4p80gsOBeiYYYETommEr2KO3aYWgo8JBNTmRyUr2eTO8osPBKBCy8AtKAwd8m5ZP8bfFY yv52a+Vw8GNKxDCIqA4lBCAIRuVorfSKydlw0Qfj/3AyHswdAuE/5EGODsrMFILXwWBFtIMLz6Tu cJLHrE7v4AoKtSUAg4vx/JncuEirGNPrqqMR/y/viElWuuuItgiBOoQSRxEplAJQkcm2Di9EQLEV o8kz2JIi5mIknWyLVLDJdtw0xOYP4/HBgMVmuiEXPVGDJlASsYxGIMlpzIV2fa4XS5CLPMMBiYqj 4A2O/e2CUOEU0+fFJNEpx6qJmvGUOsnOZKAzlGclunK1WPIlg+7FeJxEqILs5gm4rM531JctD7GL uG89ViosdzERC6iI4snPPsoTZUZWOi3azO4CTy/5lDC4vAXxdKQiw889ALJtVgysuog27sQd/kYj 2P+ymATCo4TyXJgCR1YEJZ4yt6rmRGZgEt2RM8ZnAlERjuqzcMoTC51zFw5jOFeLQ/wUquzL/+4E PGtiRRQJCoFONyGN40T0BEUmId9Es/nE6nzj7fBWM6NJAfHySYvG9VaxpeoJz0xDRO6EEV2pMkIJ BlFiNhisMY8Rwnzq9xCySKNL+CkosZwIMHccOc8FNSSsi/wy723yQuNZAfGvmLDxUCfOSnfXT3Nc vmR1M/cOi3FCJOtE3xpMNiw14LjNO1ZEH+tEI/V0vEZwIIPqrpCMTfTEKrMN/6Cxzb5PH2iiWncl Mj4LKjgwsZyycO3ivoAG1WTD6mwQz7hqvXQGn0b/S80AAlSXtNE9wRN8Mz9lg1XK1DZ4ttFskotQ w+RKjCp4NmjriT94iVHvTlmHBhBRjDGB2Vukwg23sQAXtmho9jSGYliGBiEgEJ/yBzHiKpRYwei5 CCB4tiqoghXMhRW8ttEEcEQ4Q3UnhB4AAg21dGiUUE/oQW84w2dXxBO8cTbjhDH79T/I11KO5D4p s3bbdxWKhnNHhDWz0e+YSG0czHc7SbZGCa7uhx58dmsPTDWQgmc/wXMPOCmAdyiqwlY5CaewEFjo wdmowugJtdF0t8j44aAMNkTIt2uWIq5ohPv0I8lUQ4JXw4IPb3SvdzvK9ZCNonP+g3lPN0TAuCqk /0Nrn3d6j4YVsHdEqINXY4qvmYg8VMMTyC6UM0xPj8/ODLie4Gqq7DWLqUKoSBpjDHQYQwQs8OjJ whqa9E6Ph8xvWAF4k8KFk9RJUyJWBu4/WEGCD4yPqwMgxDkgUPgLS0mUE3dfPgRlQ0RrU1BYPMEF C6etQA54QDmSE7oz35A0zM8N2Y4iEnNiRwSe27jgkIKIjw2OV/SRjwzJgFl2m7gzgDeMI/qFg/o/ gHo14DldTIMVuDZUPIEtpMITAHr6KkSCPwF1zjh6XwUYVEONU3ifLwcpqAKUP/h060F3c/ePU4P3 3IMzNPgTQEg1TMMTXPg0tLauV8M9MPpySPc/RP83w8B4dTs4eFMDjD/BdStErps3bP92YcLP+fSz b2cnWDbkymTpq0vJuMtUgr/CVVC3umP5DkMEu5P7wh/50bU2lNR4uyd4vevO/STzfRMLej+4rjsD dU+Hh0NFdwOCm9d6h8f6Hzz7oIt6QsD4VYD6qU/3oN/5dABCrR8dlC8ltX93awPCHxACtuM6NVB3 Qkw4yivEhH/jn/O40DO6slM7z693P9R6NRw7j0N7PrAjMyDxQidRcDomiTOPUAL8/QYPJQ75dl93 rR+5eUc9eo+ejzvEDv96NUj6hOv9dE/DC3E4y2s919cjo9wEjtJdi8i8Dnf33g96q3v36OX64zP/ S60nBHpPg4yju5snRL2jd0tMuUIkukLkfLoL+0P4MoSve3U7QzZchRXURb0rPY+7us57z6hXPVRA +Va5/Z+XvA4Du0TQgiugCdVwc1dbqnY8xGhvUxZ6aqVrwzx4ESHE+UOc+rqvN84vfJH7ssbIeL1P +T3MuIyrRtTj/bNjf3Zgd710vucDOu2fuuhLetOHvGs/vD9Qd3m7epQnPbNvFUD0U/XkX0E9pAoO LLjw3xNnzlQx/Dew2j8rEe/pmfhED76FFws+ifjP2ZOKeqZJFFmwZEVAGqs9eYJwYTUrNCXm1LmT p8SUPf9RAzqUYTOJ/v4hDSqRmc57BZUS5YkP/18/nVtGMqRoUOM/PVYSmvxXDVBOPWUn6lE1TU9U fGhXFow5U6dHqXcLPpXYkqXIn2dJilUY2CAgVc4YViOlzZ9NaWNXAjJJCqTFiNNe+tMY9+VExAan SavIsHNMxBdJSf6HDyJfighVgW2ItizfibIvqtpKNjXk0XgX2pVotefjocSBJydKTeg/bcp3ahO+ 8bdXVaTEovs18utYKyardVX5+c+qoHH/TYtYcqRhsWQZRr07nWc2hhfx3Vy49elF99UGki0b2Z4A xIrqqoFFlfCeeIU6A8+KCSE9RNKjmoyoASQmVSzcghRV0CoIkBFz0k+hDVMzKTYAVXziImbgef8J RI7+6W0gZzQCbEO1RLKJLI1ulKw6ougrqEjojiTqOaDk+wcM6H5iqDmezEFmIb1sugkQUk7SLbIQ B0qtJFLEY4ivlzyyrRqkeIxIrYEWPFDChT68a8qd8kmPocWeWNIgmVCxZxqZ3BOJxH9ggcvCo6zw hBTXCiTrwH8kcw8kK6hJ08WIrKgiq7A+hSyi0grcKK6Y/KuMQg0lUyssV1cqqay5uPRuGmpGle0u P/V0DrqdmpTKluQIyamfaaLcSS8peVpWooFkipbQsShEz7lFLdsJ2lIT0rWki2x6wpCKaCXX2l+T 88efVHoiKyVAmrNPqtiMBC5YbUNEV1+81L3/d6eUkJvGnnr3ZSjJghFeqJ97sukHnzsZSnang3VS 1ymGAAPuloL9BeqYntjF959sMiLFH16Hyhi5glCWqCqpNFxoGooTrjknPyL2yeacaD5q55rvCZmn lodqkr5z/yk2p21+Tu5j5Z6gJqVqXomIsbvQE47o5zK9CyKGtHksVHQ7bvofTmS212yJ8il77bum EbouiRZJztnAhvwHZ53yfjvhe9Tzriuid8IuK63jC26hYXvC5zqJmoNFJ3mlGtg5Qv5YiGjddpZ4 oWyy8Xw1v5umnPSCVv6nEKKi9FxIm6cTXd/U5/2OLrzmkilUtxeq5Z9RcpIMU4kIN1gqfnhy/1ub 4nu6Gi/QTWe+6Z6lki7d06/kqVpuEbZLKNORZQiSWZSTHirgsb9Yor2Hunsn2sHoIeeho8vG/Lp4 rz658HPKf6mEs0E9qKQPWaBLH+A8oo1kGbAnpmPSULJhJZ3IrWnOSIkDF3KKYvwjT8aSCu1ykqzP TGx5ICSSCWVXs9Alb1cuE6AhfuW+0yWrH6OQjgl/NQ29JLB1owMKBqPjr1ekYmVgCANDJDdDiaQj J4yJSnOmo46FyIdiy1LKPHQSi5GtLYUF66KvgBIJ3wlQJ/n6B+OkwsB/OeweEMtJB6FDwaH5j2cp QcpP6Dg/htAOZUD82cnK9pOUMLFiBqOdFP+DJUOfAaUa90PXF82WR6n4D40fhOS+Ltk85JAxYpLk iQ5TiEOE3Ulp+HCkIIeCj7J5cmETGw7C7qXIfyhibY68iyeBI0vj6cSNOpOKDJvEtPSFcBr+GOEe /Taagbwgb7HhXk6oYTmeKOMdPfFfM9A3OnzcYzq0w2PTpAE497XCbLacJHR6uatbaa6J0svk/3JC FpmQDWE/0QZOkBmLvtUMWzkB0UKQhqh/6LJov3KgH/0WJcod42k5ISjH8MLJECZHOv3BSeoQ2hOj 6ER2NmFORm1jtmkwiEWfsopipBWtfeqknzqh104cMhWpNIWL8hLl6ZiWLG24sUgdkyg7k/L/j234 Y2wD3BcnSQqnLWpFMjLRAwyHYpQMMQShzJELHHNyhvRZiHMSsQlCDLSQMgGlMz3JmD8J0pNK8gQe w5SIcbDXwYzytCdYBQ59YhFAtzJEHhgD0NjC46qTxJQolWEkYYei1Z7ctJBRao4VKDS2SWVLRHcx LN8CSqmxLm2RPjwrUXAZVIY8JSUP+xnKqEG5VhaEHS7jJQttZlWJ9GEK0LErTz4mHMieyyajipVY /pGFPkhEaKYhymAKxjzALcQZbStIsqrhjFmNVbpyiemC6CQTXTV1RtFy6RPwkQ+q4INBXbECcSTj DAa5KC1hAUk1MrQgw+XJVbBFF1X6l06d/zA2SdqwD1L00g7XTs6Vittr83gCMZqyZLoSqRPeKAUI mjYVMeGhgkkG5dR4UmhSnZHMSNZLLgrtR3dhecJDFyI54rzzn6aap0HchBZngKUzyHVwWV46YwCB JSYecY9lYiLiiZTlLDPC1YIo4g/D/MoVhYwPY3tyScrJ45gKk0oSnwdXs2U0oj/dboE6Iw1twCoi /wQJW/h2oJKcJkIx1XGWeNOV3ugBSGXBDFAYgeWBCsWOwMqGPzwSZK90hTYjORVwNetS2WQMNSPN xkC00Y8fNWROJFmQoYBUkjuBBBBVfi5QqPGcREhEmLuEzv30a+qh6FkqbX3b3fg4lHcmJv9EVsAx ZP/Rj4scpFtmKuplUXWbglTmdSB5qXVBlGprRjo51tJ1WLQy2cqYrjIrCRBG/vGKpzwnLuypbKuy kuT96OEMt5VZlOQ4n399UYCqBO2BC3a3I/UMGwyRIFEWVQ1mjMQQT9iGKWO2kLLGxH0hpY5XcAxc OkP4s9hRi/T2+dODy4zQMBELiUwDXzMJZjKqIQk1FqaKRNnG2zGz9Rmxu3DhtOSIRMHnXevYPrwU M7R+u0WpdRIMYQBFYrGG4JQ2elywqAIVLLPCgcAL4yUZmyAA0sp7ytwVQwmpH9mwNoFoUhZbD2Mi Ky0IzlEnWryElTRgwc6IlLpwigSOxCz/usgWJOM4K3hEHs0wzI0sPqLRsPdQvI2aev1hMiVhsmkC g7ff3Icyc2bvLjZJiTbSG5NshEc396hGbyl1oJaGwSHhqYh+xuQeH9NGLa2iFEIGxI5D+bJsnNwW egZiIZmA1akVGUiRUAUitfiBKivxxz048pTYj+SywhuJwXMtjaLHhI5cPnx6MlnzBAMlcwmTuE4U SJSm4sPqAf8OtvTQfREhrRCzR3ZgplviP2mIC5samfHrI71n4MT5OQM7UFAsdqNOcV9IQTRwVqhm zC2GJmnxhiLVtiBxpK94Fq+NBm+YuAyrHKn+CEYqSstYrs+aRmshlI1vOgg+oiwntIwC/6EsjShn 1pbt1H6lqBDGeQrw0xDsZ75Iy2KQZVio/ihQZpqkH/yEaJyhXxLGX6rhGciKKO5mG+ptIYaKSB7w OORluSCKo0hGkZZkmyRCl4hw5upveTzt+fTPoSDoAf3h/jQn/1DQc1oG0PrBKtRFG7pQXwyQUn7j YFAwnQSoZXglSWgHFjaGdFxQj7BnSZqhBJMLKNztH3znV6QJ1IbiDeGQtKbBhJjtZPLvV/xnLgLO wDgKL4rnWJIjGKJClEIN3sjQWbwOOMjQOTyCZipRKpLkHu5BPtZKIvqK5wqqFWvG8Oamf/xG+iqw IAbQECfGI/qhAxliHXwlWPykbpIiDv+nBIjsgctaxlniEE/ohyhoR5J2kBe5iaBuwXp2YoSSMASB oxphzgujMI8QCtBYJgeBIvv+IRIQxh07qyCih3R4x2j0796AAuw4qQHhZn/QcSEWbDkO72QKSgPB BmHEBmH6wRc3kP/+oaGmJyGDA2JUAR7xghDBaCeMkcD2IpXS5pfAqRyfz2IU0r5q5lhYUCKWARuh IwwUC1gWgh8ThjjYUSIy6l6Qgh5zjRM/qWaCrj4KAnmMcGeoYRBoYCkdJAuybSmxYCFegQYcZP8W AiqVbSppwBxtMCWxxxNzYiol5iWF0cruAiufkgai0nz8wbnSRSlqoSoJISrzYidggQb/8IEugUMp qbIg+LIViSaA6MiMiKIZhnJKIIlm/pAoplJpFGgpF0IppbIvJZIhUIEG7sTVciIbvuBt5EMbBoGq rNIiC+wopvIV4Mp/VsacplIorEIye3CVQrH17AJl5pIhJFBhJBM4vqAzb7M3kwYLAHOikkI49Kv6 0AUx39GVwHGpDpAGOlNmdjM4gaM1GaKasC861+aJQnOPFvMLB4xfoMKKomOPTMeElCEUoAkzR+c2 m4QxYEGLioYnVa16hOI2ObEvs+ALFKgptbOFmhA6yFIDUXB0qMFZ8KGHjuQL2LMqd2orCwI/78I6 h4IQ/tMrkwMfHuMVlOYfOuFKvsk5/53MJJPiKY7EPm6KjLSBPZ9DQpvoM3WiC4yEKxlCFDrSRRmT MrNtGqoSln5mQHdCmGatOX2oSeyDV4aFGiCzILDhJwahOXB0KCgUKCxUJHPCPMCTJ6SBBpQmImyU eMxSJ4KxcRTGlP6lIxmiycIuR6EoSnkChK7gZ9DmZaIUhF6gtu6yR6eBBgp0OYcJZZ5Cl+5lvCTC ckznFqbyPz3nNqmBQXU0KZdyEJakNamhE0YBC/hHIgbhC1AhNKiyGULmFRxVUtOyWEYBLwtCVCO1 ZbQSKqvvFbJgKYslKuxDK4uFQeUFFkb1OS5zKYvOUXtTh3q0H/jyC0KGBlwBCwhhRf99dSpj1Y0g VS179Cmbg1j1EnIcFRWK5RUacy6hc0pAcym/oEejlT//AS1T1VGz4BUADSlwdFm89QuMw1GZ8gv2 lAakQS6xQFqNZCmpQSu5JltNdefgCUyjo2V6phQZ8BpHEp54FTojkiFu0yOU1EG59Dmw4AuYxjpD LYUGIV/vEwuao2Ij1CkL4gsIARUyJSpJ9h++gBrIUFkZ4jT9UmKWBGVVdhpYljIJwSnxgWYjtCpv pUexQBpqlT3/oWido2WpIQuIRmb/4TJ7lEKpwU2DSyhAszv7YV+zQCgYdEmyAAyewzpXVGn2M1WR FmiV0k8G4VoZIlif0jiANij68jX/v8BSYbUqAY1DaTYLpmGnNhWaeFE8CTA5uuZz6gdi44En5nIm edZkt7Y7W1NUuzIn5lIoVCEVKPMLTJZu5XJcnaMzOXeKqPL+oLYgMpYDs2FaI3MQHKRRXbZzSXYa Rhd1ZYYypcEV/ERmswE/V9RkUYF1WYZLC6JlqXUh3LRp2XYhOHdJlLRYLnOMkrZY2nYhoJZCgXZK 3XQqp+AOIq1n0XZq+/Ie5hZ86dYjTlN5WUa2CgKq4gMPewIXDRY4UieFXmEahsURb1NpsKAqaaA7 JaIxU5dyhqRKi5cyoXIp1ZIQ3FVkoyKBFbhDr4RDkyIflLToZEaCIxNpC0KB91VW/5GCZin4ufr3 ZKESkEyWZiW1hLtWc5iteKUhC1xBR7XXbZlXVlHBT4DTekU3gbOBBpzybHPiLu/kFXqVgwchWPxh TyOmQWkYdyF4KbmGeJv4f3OYuJRF8XaCH7gSv6TCMTW4J7CgENyIW/3yWhEYgGeWS5XUgXDOgD23 g78gkbIhKh84OlOIR5dVlU4Gg1FXjZHXbaETq6LibF+WITaXBojH3XpTG4KYEGDXOVAmX3OYGphB fKfEfHVCW6GSef8TYhmUWZL2QtFWKbShN4tOe7MgWFxUFET2KcW3KlEhX3lJR6FCW/fVhuvRgRDy lfalFodCCwaqIJ4kR8NYL6vXev+rsnZt93j3VHiRd53i+GpnFoMRiCFitS6NWCekQWk6U4iDwoxz IpmtNyqFaZvDt3NRV1/BFYCnchCgV1mh+R+YIW3x9SemUjjIeWYluIRj13mJ93LLMHYZgi6nkjEU qHMvM5PpUj5qOHwnsyrn1mUPeFpf4U78eUQVEiX1inS0yAAv01xXF3T9UpGHV6L/N0IxeEWbY22V RS9J9t9SOtu0kxAuiDje+R/ylZQLwhU6k4Jp9lh4mjrXWGkotyCGJVandUUddD+FolF5BQtemVkJ Zy4dRFWLrlazgaFdayoxuGmbw1G91mmdw6mDgj+1IaeTBoMvWjr8IVbH9msjUy//o+Iedjh7n7hH 27YqXbeiZ3YavrqFy2eKlCIL0TTFACghoINDt1JZm6NVaQAV6LVBRxV1aeAeIpsQPBhyPNiIFdgu RBUMCMGoPdik01WtdQJWITZV15WKA7i0Z7ayF0ISnvJtExhr+fJJkwUVOncQABls+HJbz6Azl3IZ oBOy/dgqklKzj9uTe1WaTSm3myMfVJWKFRgz/UG1+1IpefS6/bgumZukFRizIZtnl3JdTViBvxqe xXWe17cGOXDVEman9mVky7JmHgGorLRQgfInB1J+oYI++tAf3oER0GWHYdCEqIdw1hBDEydi0Yko QgehaBQdo8JtQqtsRm0nwvgV/wk3MfQLIvMoAxNnEuLjIwsiC9RZT+hDmHyqMvdL5vBPX7qIZO6H RiscDvW7WZSjSfzg94ii5dZ0r5AikHYigOyHjNxoTJsIcvIPfa97WA87qMztv/5mxr3wN6SDV56x l1AyYVhtZ+S3SNgnEHWCEdCAXzrGGA+RNIExl4b8HXnHAfvHXxjmKwuGKvyBGsRLOfIBQZeHJIqX Jn/GGJkRH9ExFa+HKCmqPPXFHW1JkaoIxYfCFH7bpZQDHwyb0Pd7Jz60s3qZHBPGfesyObaBrhAG mAdyNIGDGjZ90LFPX/DAT6ccOjiSdFpy1T99cIdicfGiFWgJL7BBlxjhkg7mp//koU9Xvb7x4h5W JhtmXb+5Scb7+8BynCgU/cCyfV8eCg2GkieC8aeU/YfGvWb8J5tmzVkgZqup/ZysHV2wdNnl/doh UhN3ZqsdSJr9pnjGUay2YRvG3XTs4qF0icl9Ejp8MdcPj0gPTCnahsnvO37DsGAc5nlS622AKDRE vWCyaePrcRMRHcaVgx4P1AspvdRBy93yp3j8h91lSqhIUt5VciHgSo6eYR58smM63uOVsP9sZpWY XH6vndkDUn+yjREOJtSHPpHekVcAXCrWxGZahgYpyCMK9DsF0mDqHeKLN1h+ojnkY3WS4+AJUypg 9sAAvGOChetJ5+mPvCp0aNX/eeWdvny+0XFZ/lYiVmfWlB0Q/IG28Qc4niEZuAhJKpfW92XbyVTm sQ/keDADjV3kY/3AQMntJd+BiufkA3iYbh3CM/TDyaYtWckc655nkpNkgIMRDLwn+p0ncO5Iwqfe bTHkRVOUt7P0793yI7zaHz3x6rfJf6bz8+LgLVCF8r6cDNcSiRM4Dv1XnGghQPV0XvhMeWZMSVwR RceBQI7TBbQ0V50G35ThPWj60yeduhgMgaMlCTZ9toHJO2i1dqIWD7RAif95hj/mGVZK7gf87bHH B1vyAeKfwIEECxo8SNDfQH8KETo8yBAhNYP4Hlq8iDGjwWP/XGn8iLAfxooTxy9W/Dft3rSL+Qiu PNhPW0N/2kAOvGdQ5EOcNi3ey/ZQC4+eDU2WFKiz4cmeTAX6s2UxFLGLRQkCbYo1K8JZWj/iW9r1 H0+QKS1uq2rz6MCXYRFmaQsXoUyBNQVeLZgNrdZYcfv6BUlNG9i/hJH2ZMvUX7/BBMcS1Fn439uP kFuSRSxw28d7R+8aFBw5dOhoWqndY0wYrF6C1KBmlIe5YC2DhOg2XdxUrShUBtmJXkjQcmasq/9V I4hP291+2H47fy7QI3SbAQEAOw== ------=_NextPart_000_000E_01C80CCD.2FF67890-- From somjit_s@my.tupperware.com Fri Oct 12 08:46:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJuV-0001zC-HY for ospf-archive@megatron.ietf.org; Fri, 12 Oct 2007 08:46:35 -0400 Received: from [88.248.250.117] (helo=dsl88-248-64117.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IgJuQ-0002WO-Ps for ospf-archive@megatron.ietf.org; Fri, 12 Oct 2007 08:46:32 -0400 Received: from ebcl ([193.194.113.148]) by dsl88-248-64117.ttnet.net.tr (8.13.4/8.13.4) with SMTP id l9CCngmY037405; Fri, 12 Oct 2007 15:49:42 +0300 Message-ID: <470F6C9C.1010801@my.tupperware.com> Date: Fri, 12 Oct 2007 15:46:20 +0300 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@megatron.ietf.org Subject: Your ecard horoscope is waiting! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Click here to view your laughing kitty card online. http://69.149.35.166/ From ademiju.allen@igod.com Fri Oct 12 08:49:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJxR-0003lo-7e for ospf-archive@lists.ietf.org; Fri, 12 Oct 2007 08:49:37 -0400 Received: from [193.226.114.44] (helo=44.ew.ro) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IgJxK-0002ce-Re for ospf-archive@lists.ietf.org; Fri, 12 Oct 2007 08:49:32 -0400 Received: from obe ([175.27.71.46]) by 44.ew.ro with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 15:49:17 +0300 Message-ID: <470F6D4D.3070700@igod.com> Date: Fri, 12 Oct 2007 15:49:17 +0300 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: We have a ecard greeting for you. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 You have been sent the funniest Kitty Kard. http://24.128.176.72/ From Marchmrd@amave.pt Fri Oct 12 10:45:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLl6-0003HS-RH for ospf-archive@megatron.ietf.org; Fri, 12 Oct 2007 10:45:00 -0400 Received: from bzy175.neoplus.adsl.tpnet.pl ([83.30.70.175] helo=cbg11.neoplus.adsl.tpnet.pl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgLl5-0008Nw-7U for ospf-archive@megatron.ietf.org; Fri, 12 Oct 2007 10:45:00 -0400 Received: from d-b147d4d0b38c4 ([102.193.187.153]:32290 "EHLO d-b147d4d0b38c4" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by cbg11.neoplus.adsl.tpnet.pl with ESMTP id S22BFRXIJICBYARY (ORCPT ); Fri, 12 Oct 2007 16:45:34 +0200 Message-ID: <000a01c80cde$742edb40$0b681e53@db147d4d0b38c4> From: "Pyung March" To: Subject: srotkade Date: Fri, 12 Oct 2007 16:44:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C80CEF.37B7AB40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ------=_NextPart_000_0003_01C80CEF.37B7AB40 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable wats up ospf-archive does she like cum in her face? bust out massive amounts of semen so she = can slurp it up Pyung March http://antems.com/ ------=_NextPart_000_0003_01C80CEF.37B7AB40 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
wats up ospf-archive
does she like cum in her face? bust out = massive amounts=20 of semen so she can slurp it up
Pyung March
http://antems.com/
------=_NextPart_000_0003_01C80CEF.37B7AB40-- From morgenthalerthtf@e-asf.com Fri Oct 12 22:29:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgWkk-0005B8-Gj for ospf-archive@megatron.ietf.org; Fri, 12 Oct 2007 22:29:22 -0400 Received: from aamiens-157-1-189-206.w86-192.abo.wanadoo.fr ([86.192.92.206] helo=[86.192.77.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgWkj-0006qX-Ua for ospf-archive@megatron.ietf.org; Fri, 12 Oct 2007 22:29:22 -0400 Received: from mce2005 ([168.164.117.154]:12520 "EHLO mce2005" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [86.192.77.176] with ESMTP id S22ANNUXJVZWMVKY (ORCPT ); Sat, 13 Oct 2007 04:30:04 +0200 Message-ID: <000b01c80d40$e11a62d0$b04dc056@mce2005> From: "ice morgenthaler" To: Subject: anirtxed Date: Sat, 13 Oct 2007 04:29:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C80D51.A4A332D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0008_01C80D51.A4A332D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello honey ospf-archive women love dick driving deep inside. ice morgenthaler http://amianrts.com/ ------=_NextPart_000_0008_01C80D51.A4A332D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello honey ospf-archive
women love dick driving deep = inside.
ice morgenthaler
http://amianrts.com/
------=_NextPart_000_0008_01C80D51.A4A332D0-- From bullet_one666@tcikorea.co.kr Sat Oct 13 16:03:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgnCh-0001JM-F4 for ospf-archive@lists.ietf.org; Sat, 13 Oct 2007 16:03:19 -0400 Received: from p549e6794.dip.t-dialin.net ([84.158.103.148]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IgnCU-0000aV-WC for ospf-archive@lists.ietf.org; Sat, 13 Oct 2007 16:03:13 -0400 Received: from gcaf ([150.32.153.189]) by p549E6794.dip.t-dialin.net (8.13.4/8.13.4) with SMTP id l9DK8dX5023773; Sat, 13 Oct 2007 22:08:39 +0200 Message-ID: <001001c80dd4$33307260$bd992096@gcaf> From: To: Subject: check this out Date: Sat, 13 Oct 2007 22:04:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original 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.7 (++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 PPYH Changes To A Fast Track. Physical Property Holdings Inc. PPYH $0.25 Moving in a new direction, PPYH is laying fast track for success in HK Real Estate. Moving fast and furious, they have been acquiring a number of high profile properties already. Wake your broker up early and tell him to move on PPYH. From tln@terona.com Sun Oct 14 19:38:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhD24-0000dU-3b for ospf-archive@megatron.ietf.org; Sun, 14 Oct 2007 19:38:04 -0400 Received: from cablelink218-59.telefonia.intercable.net ([201.172.218.59] helo=218-59.CableLink4.InterCable.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhD1r-0007j8-M7 for ospf-archive@megatron.ietf.org; Sun, 14 Oct 2007 19:38:00 -0400 Received: from [201.172.218.59] by mx1.mediadesign.nl; , 14 Oct 2007 15:37:51 -0800 Message-ID: <01c80e78$2e731ee0$3bdaacc9@tln> From: "Tricia Thayer" To: Subject: adobe cs3 our price US $ 89.95 Date: , 14 Oct 2007 15:37:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 1.8 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 CREATIVE 3 $269.90 http://produktdv.com From Jurgen-Ibricic@bild-und-heimat-verlag.de Mon Oct 15 15:00:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVB7-00049C-1t for ospf-archive@megatron.ietf.org; Mon, 15 Oct 2007 15:00:37 -0400 Received: from dlc77.neoplus.adsl.tpnet.pl ([83.24.32.77]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhVB5-0002Yf-Ej for ospf-archive@megatron.ietf.org; Mon, 15 Oct 2007 15:00:36 -0400 Received: from ppp-3f60773a170 ([184.185.6.105] helo=ppp-3f60773a170) by dlc77.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1lLeQe-000TEA-Uw for ospf-archive@megatron.ietf.org; Mon, 15 Oct 2007 20:58:39 +0200 Message-ID: <000e01c80f5d$5f0f9110$4d201853@ppp3f60773a170> From: "Jurgen Ibricic" To: Subject: enoisivi Date: Mon, 15 Oct 2007 20:58:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C80F6E.22986110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0006_01C80F6E.22986110 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable hay you ospf-archive I feel like a full man now that i have an extra 3 inches http://www.fantface.com/ Jurgen Ibricic ------=_NextPart_000_0006_01C80F6E.22986110 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
hay you ospf-archive
I feel like a full man now that i have an = extra 3=20 inches
http://www.fantface.com/
Jurgen Ibricic
------=_NextPart_000_0006_01C80F6E.22986110-- From ospf-bounces@ietf.org Tue Oct 16 02:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihg0k-0002gW-Qh; Tue, 16 Oct 2007 02:34:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihg0j-0002T8-Hs for ospf@ietf.org; Tue, 16 Oct 2007 02:34:37 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihg0D-0006UF-Jz for ospf@ietf.org; Tue, 16 Oct 2007 02:34:07 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPZ005DWRJFHZ@szxga03-in.huawei.com> for ospf@ietf.org; Tue, 16 Oct 2007 14:33:15 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPZ003VZRJE3A@szxga03-in.huawei.com> for ospf@ietf.org; Tue, 16 Oct 2007 14:33:15 +0800 (CST) Received: from p709321533 ([10.18.4.174]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPZ00IKBRJAZF@szxml03-in.huawei.com> for ospf@ietf.org; Tue, 16 Oct 2007 14:33:14 +0800 (CST) Date: Tue, 16 Oct 2007 12:02:46 +0530 From: sinbad To: ospf@ietf.org Message-id: <002e01c80fbe$5ffa4820$8119fea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcgO+fDunL+LDDi5So2l+7SKWkYc6gAxGLWw X-Spam-Score: 0.0 (/) X-Scan-Signature: 398dc098b38497efe55f044562a219e7 Subject: [OSPF] Reg. use of checksum for checking newer LSA instance X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0724455702==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0724455702== Content-type: multipart/alternative; boundary="Boundary_(ID_nXa36PdMLG0gjd4T+75Fqw)" This is a multi-part message in MIME format. --Boundary_(ID_nXa36PdMLG0gjd4T+75Fqw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT In finding the newer instance of LSA, if the sequence number is same, checksum of the two LSAs are compared and the LSA having higher checksum is considered more recent. Can someone explain how this can be always true? thanks sinbad --Boundary_(ID_nXa36PdMLG0gjd4T+75Fqw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

In finding the newer instance of LSA, if the sequence number is same, checksum of the two LSAs are compared and the LSA having higher checksum is considered more recent. Can someone explain how this can be always true?

 

thanks

sinbad

--Boundary_(ID_nXa36PdMLG0gjd4T+75Fqw)-- --===============0724455702== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0724455702==-- From ospf-bounces@ietf.org Tue Oct 16 03:12:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgZl-0004dH-CN; Tue, 16 Oct 2007 03:10:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgZj-0004cS-UP for ospf@ietf.org; Tue, 16 Oct 2007 03:10:48 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhgZi-0007eZ-CK for ospf@ietf.org; Tue, 16 Oct 2007 03:10:47 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPZ005I9T8NHZ@szxga03-in.huawei.com> for ospf@ietf.org; Tue, 16 Oct 2007 15:09:59 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPZ003DTT8L3A@szxga03-in.huawei.com> for ospf@ietf.org; Tue, 16 Oct 2007 15:09:59 +0800 (CST) Received: from z44434sza ([10.70.142.144]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPZ00G52T8L4Y@szxml04-in.huawei.com> for ospf@ietf.org; Tue, 16 Oct 2007 15:09:57 +0800 (CST) Date: Tue, 16 Oct 2007 15:09:37 +0800 From: zhang kui Subject: Re: [OSPF] Reg. use of checksum for checking newer LSA instance In-reply-to: <002e01c80fbe$5ffa4820$8119fea9@china.huawei.com> To: 'sinbad' , ospf@ietf.org Message-id: <000601c80fc3$835738f0$010110ac@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcgO+fDunL+LDDi5So2l+7SKWkYc6gAxGLWwAAD20KA= X-Spam-Score: 0.6 (/) X-Scan-Signature: 76319d6f172f4cd0a083860f80065cd1 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1173947379==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1173947379== Content-type: multipart/alternative; boundary="Boundary_(ID_fIwohSdsMhZJ76vkCn+B/A)" This is a multi-part message in MIME format. --Boundary_(ID_fIwohSdsMhZJ76vkCn+B/A) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi sinbad, It is not necessarily true. Maybe the reason for doing this is to ensure = all the routers in the network behave the same way in such conditions. When = it=A1=AF s false, the originator will correct it. =20 zhangkui _____ =20 =B7=A2=BC=FE=C8=CB: sinbad [mailto:sinbad.sinbad@gmail.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA10=D4=C216=C8=D5 14:33 =CA=D5=BC=FE=C8=CB: ospf@ietf.org =D6=F7=CC=E2: [OSPF] Reg. use of checksum for checking newer LSA = instance =20 In finding the newer instance of LSA, if the sequence number is same, checksum of the two LSAs are compared and the LSA having higher checksum = is considered more recent. Can someone explain how this can be always true? =20 thanks sinbad --Boundary_(ID_fIwohSdsMhZJ76vkCn+B/A) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi sinbad,

It is not necessarily true. Maybe the reason for doing = this is to ensure all the routers in the network behave the same way in such = conditions. When it=A1=AFs false, the originator will correct = it.

 

zhangkui

=B7=A2= =BC=FE=C8=CB: sinbad = [mailto:sinbad.sinbad@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA10=D4=C216=C8=D5 14:33
=CA=D5=BC=FE=C8=CB: ospf@ietf.org
=D6=F7=CC=E2: [OSPF] Reg. use of checksum for checking newer LSA instance

 

In finding the newer instance of LSA, if the sequence number is same, = checksum of the two LSAs are compared and the LSA having higher checksum is = considered more recent. Can someone explain how this can be always = true?

 =

thanks=

sinbad=

--Boundary_(ID_fIwohSdsMhZJ76vkCn+B/A)-- --===============1173947379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1173947379==-- From ospf-bounces@ietf.org Tue Oct 16 03:19:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihghk-0006l5-25; Tue, 16 Oct 2007 03:19:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihghi-0006kY-QJ for ospf@ietf.org; Tue, 16 Oct 2007 03:19:02 -0400 Received: from exprod7og108.obsmtp.com ([64.18.2.169]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihghi-0007wj-BI for ospf@ietf.org; Tue, 16 Oct 2007 03:19:02 -0400 Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Tue, 16 Oct 2007 00:18:55 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 00:18:29 -0700 Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id l9G7ITn65261; Tue, 16 Oct 2007 00:18:29 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <000601c80fc3$835738f0$010110ac@china.huawei.com> References: <000601c80fc3$835738f0$010110ac@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <9A8FB931-C909-49FD-A1E7-29D0A474817F@juniper.net> From: Dave Katz Subject: Re: [OSPF] Reg. use of checksum for checking newer LSA instance Date: Tue, 16 Oct 2007 01:18:26 -0600 To: zhang kui X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Oct 2007 07:18:29.0864 (UTC) FILETIME=[C08EA680:01C80FC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1396021765==" Errors-To: ospf-bounces@ietf.org --===============1396021765== Content-Type: multipart/alternative; boundary=Apple-Mail-11--536458180 --Apple-Mail-11--536458180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed On Oct 16, 2007, at 1:09 AM, zhang kui wrote: > Hi sinbad, > > It is not necessarily true. Maybe the reason for doing this is to =20 > ensure all the routers in the network behave the same way in such =20 > conditions. When it=92s false, the originator will correct it. Yep, that's the reason. You want a deterministic function, lest the =20 network tie itself in knots. --Dave= --Apple-Mail-11--536458180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252
On Oct 16, 2007, = at 1:09 AM, zhang kui wrote:

Hi sinbad,

It is not necessarily true. Maybe the reason for doing = this is to ensure all the routers in the network behave the same way in = such conditions. When it=92s false, the originator will correct = it.


Yep, that's the reason.=A0 You = want a deterministic function, lest the network tie itself in = knots.

--Dave
= --Apple-Mail-11--536458180-- --===============1396021765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1396021765==-- From naftaly@gvcalligraphy.org Tue Oct 16 08:27:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhlVy-00074E-Po for ospf-archive@megatron.ietf.org; Tue, 16 Oct 2007 08:27:14 -0400 Received: from [82.101.177.64] (helo=[82.101.177.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhlVt-000154-5G for ospf-archive@megatron.ietf.org; Tue, 16 Oct 2007 08:27:09 -0400 Received: from PHARMA ([149.181.99.53]:5846 "EHLO PHARMA" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [82.101.177.64] with ESMTP id S22INQRGYJGVECBB (ORCPT ); Tue, 16 Oct 2007 13:27:17 +0200 Message-ID: <000c01c80fe7$7bad34f0$40b16552@PHARMA> From: "Slater naftaly" To: Subject: |revidde Date: Tue, 16 Oct 2007 13:27:06 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C80FF8.3F3875F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.4 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0003_01C80FF8.3F3875F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable howdy partner ospf-archive I feel like a full man now that i have an extra 3 inches http://www.ginewtte.com/ Slater naftaly ------=_NextPart_000_0003_01C80FF8.3F3875F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
howdy partner ospf-archive
I feel like a full man now that i have an = extra 3=20 inches
http://www.ginewtte.com/
Slater naftaly
------=_NextPart_000_0003_01C80FF8.3F3875F0-- From ospf-bounces@ietf.org Tue Oct 16 15:26:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihs0K-0001Cf-Lt; Tue, 16 Oct 2007 15:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihs0I-0001BA-GB for ospf@ietf.org; Tue, 16 Oct 2007 15:22:58 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihs0C-0001Mw-Bm for ospf@ietf.org; Tue, 16 Oct 2007 15:22:58 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gpJUmNr2nnRI9r4mdfQVd6V9E3MbVoM1ynV+92zCGi+iTF9De8zffzozdTTkuJMN; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.86.15] (helo=earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ihrzt-0000CT-Tz; Tue, 16 Oct 2007 15:22:34 -0400 Message-ID: <47150D97.696EDA0A@earthlink.net> Date: Tue, 16 Oct 2007 12:14:31 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Dave Katz Subject: Re: [OSPF] Reg. use of checksum for checking newer LSA instance References: <000601c80fc3$835738f0$010110ac@china.huawei.com> <9A8FB931-C909-49FD-A1E7-29D0A474817F@juniper.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7934cd30458cf206cbee660302dabea36b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.86.15 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Dave Katz wrote: > > On Oct 16, 2007, at 1:09 AM, zhang kui wrote: > > > Hi sinbad, > > > > It is not necessarily true. Maybe the reason for doing this is to > > ensure all the routers in the network behave the same way in such > > conditions. When it’s false, the originator will correct it. > > > > Yep, that's the reason. You want a deterministic function, lest the > network tie itself in knots. > > --Dave > Let us remember that normally a LSA will be refreshed (or it will be a DNA LSA), but that would not correct the instability. Thus, an area of say routers of type A COULD artifically partition itself from routers of type B. Hopefully, the LSA(s) would be a second or third unequal unused contributor(s) to the SPF calc, so their is a possibility that no routing instability would be seen. Yes, the resulting rexmits would also consume cycles. Mitchell Erblich _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 17 03:21:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii39o-0005FX-8j; Wed, 17 Oct 2007 03:17:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii39m-0005E8-Gw for ospf@ietf.org; Wed, 17 Oct 2007 03:17:30 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii39l-0001Dd-09 for ospf@ietf.org; Wed, 17 Oct 2007 03:17:30 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ100B01O7Y85@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 17 Oct 2007 15:16:46 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ100DVEO7WSY@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 17 Oct 2007 15:16:46 +0800 (CST) Received: from p709321533 ([10.18.4.174]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQ1005K9O7MSQ@szxml03-in.huawei.com> for ospf@ietf.org; Wed, 17 Oct 2007 15:16:43 +0800 (CST) Date: Wed, 17 Oct 2007 12:46:10 +0530 From: sinbad To: ospf@ietf.org Message-id: <006201c8108d$9cd83f70$8119fea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcgQjZfHFY4+PzSEQ6u/H+UmuP6KLg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ff4385cf5f055d6f6dabfc300106446 Subject: [OSPF] ospfv2 NSSA address range question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0816234881==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0816234881== Content-type: multipart/alternative; boundary="Boundary_(ID_pU6oS9T719IopSy+BkPV8Q)" This is a multi-part message in MIME format. --Boundary_(ID_pU6oS9T719IopSy+BkPV8Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT RFC 3101 section 3.2 point (2) Else the Type-7 LSA must be aggregated by the most specific Type-7 address range that subsumes it. If this Type-7 address range has the same [address,mask] pair as the LSA's network and no other translatable Type-7 LSA with a different network best matches this range, then flag the LSA as not contained in any explicitly configured Type-7 address range and process the LSA as described in step (2). Otherwise compute the path type and metric for this Type-7 address range as described below. The path type and metric of the Type-7 address range is determined from the path types and metrics of those translatable Type-7 LSAs that best match the range plus any locally sourced Type-5 LSAs whose network has the same [address,mask] pair. If any of these LSAs have a path type of 2, the range's path type is 2, otherwise it is 1. ------------------------------------- "If the range's path type is 1 its metric is the highest cost amongst these LSAs; if the range's path type is 2 its metric is the highest Type-2 cost + 1 amongst these LSAs. (See Section 2.5 step (5).) 1 is added to the Type-2 cost to ensure that the translated Type-5 LSA does not appear closer on the NSSA border than a translatable Type-7 LSA whose network has the same [address,mask] pair and Type-2 cost." ------------------------------------- The above quoted text is not very clear why + 1 is added to the cost ... any one pls shed some light on this. thanks sinbad --Boundary_(ID_pU6oS9T719IopSy+BkPV8Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

RFC 3101 section 3.2 point (2)

 

Else the Type-7 LSA must be aggregated by the most specific

Type-7 address range that subsumes it.  If this Type-7 address

range has the same [address,mask] pair as the LSA's network

and no other translatable Type-7 LSA with a different network

best matches this range, then flag the LSA as not contained in

any explicitly configured Type-7 address range and process the

LSA as described in step (2).  Otherwise compute the path type

and metric for this Type-7 address range as described below.

 

The path type and metric of the Type-7 address range is

determined from the path types and metrics of those

translatable Type-7 LSAs that best match the range plus any

locally sourced Type-5 LSAs whose network has the same

[address,mask] pair.  If any of these LSAs have a path type of

2, the range's path type is 2, otherwise it is 1. 

-------------------------------------

"If the range's path type is 1 its metric is the highest cost amongst

these LSAs; if the range's path type is 2 its metric is the

highest Type-2 cost + 1 amongst these LSAs. 

 

(See Section 2.5 step (5).)  1 is added to the Type-2 cost to ensure that the

translated Type-5 LSA does not appear closer on the NSSA

border than a translatable Type-7 LSA whose network has the

same [address,mask] pair and Type-2 cost."

-------------------------------------

 

The above quoted text is not very clear why + 1 is added to the cost ... any one pls shed some light on this.

thanks

sinbad

--Boundary_(ID_pU6oS9T719IopSy+BkPV8Q)-- --===============0816234881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0816234881==-- From Gallinger@SAVIDTECH.COM Wed Oct 17 03:41:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii3XH-0001dc-0q for ospf-archive@megatron.ietf.org; Wed, 17 Oct 2007 03:41:47 -0400 Received: from 213-140-21-229.fastres.net ([213.140.21.229]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii3XB-0001l3-CM for ospf-archive@megatron.ietf.org; Wed, 17 Oct 2007 03:41:41 -0400 Received: from salva-45fbe1247 ([138.106.127.138]:31874 "EHLO salva-45fbe1247" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [213.140.21.229] with ESMTP id S22CSBYAYMPSCXOE (ORCPT ); Wed, 17 Oct 2007 09:41:52 +0200 Message-ID: <000401c81091$187f08e0$e5158cd5@salva45fbe1247> From: "Rigo Gallinger" To: Subject: uyuuy Date: Wed, 17 Oct 2007 09:41:14 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C810A1.DC07D8E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C810A1.DC07D8E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hallo ospf-archive no need to feel shy when you slap her in the face with ya dick http://www.hlrscope.com/ Rigo Gallinger ------=_NextPart_000_0009_01C810A1.DC07D8E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hallo ospf-archive
no need to feel shy when you slap her in the = face with=20 ya dick
http://www.hlrscope.com/
Rigo Gallinger
------=_NextPart_000_0009_01C810A1.DC07D8E0-- From ospf-bounces@ietf.org Wed Oct 17 09:43:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii98e-0002Dq-7m; Wed, 17 Oct 2007 09:40:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii98c-0002Cc-VY for OSPF@IETF.ORG; Wed, 17 Oct 2007 09:40:42 -0400 Received: from omega7.wr.usgs.gov ([130.118.4.3] helo=ns0.wr.usgs.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii98X-0005Az-L9 for OSPF@IETF.ORG; Wed, 17 Oct 2007 09:40:42 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01MMMBMX1FE800EQ26@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Wed, 17 Oct 2007 06:23:03 -0700 (PDT) Date: Wed, 17 Oct 2007 06:23:03 -0700 (PDT) From: "Pat Murphy - (650)329-4044" Subject: Re: [OSPF] ospfv2 NSSA address range question To: OSPF@IETF.ORG Message-id: <01MMMBMX1GC200EQ26@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Sinbad, Regarding, ...If the range's path type is 1 its metric is the highest cost amongst these LSAs; if the range's path type is 2 its metric is the highest Type-2 cost + 1 amongst these LSAs. (See Section 2.5 step (5).) 1 is added to the Type-2 cost to ensure that the translated Type-5 LSA does not appear closer on the NSSA border than a translatable Type-7 LSA whose network has the same [address,mask] pair and Type-2 cost. I puzzled over a similar statement in RFC 1587 and added the last sentence based on this subtle occurrence. If a Type-7 LSA exists with the same [address,mask] pair as the Type-7 range's [address,mask] pair, and other Type-7 LSAs exist that are strictly subsumed by the address mask pair, then adding +1 ensures that the Type-7 path is preferred. Note normally a static discard route would be generated by a Type-7 address range to avoid routing loops. Here this Type-7 LSA's path should be administratively preferred over the discard route. Perhaps someone else remembers (or can think of) something more pertinent. Pat _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From Arnan.Mandalia@lilacdays.com Wed Oct 17 18:20:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiHFJ-0004Or-Kx for ospf-archive@megatron.ietf.org; Wed, 17 Oct 2007 18:20:09 -0400 Received: from srbk-590fc843.pool.einsundeins.de ([89.15.200.67] helo=srbk-590fccc5.pool.einsundeins.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiHFJ-0006O1-6d for ospf-archive@megatron.ietf.org; Wed, 17 Oct 2007 18:20:09 -0400 Received: by 10.132.208.101 with SMTP id ZnIeqDDtNqfaG; Thu, 18 Oct 2007 00:21:32 -0000 (GMT) Received: by 192.168.166.59 with SMTP id PHCPqYruRNSIIZ.2050750469511; Thu, 18 Oct 2007 00:21:30 -0000 (GMT) Message-ID: <000e01c8111c$d318bf30$c5cc0f59@awfjuwi> From: "Arnan Mandalia" To: Subject: rebaptis Date: Thu, 18 Oct 2007 00:21:27 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C8111C.D318BF30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C8111C.D318BF30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Howdy ospf-archive she loves it when i squirt cum all over her face now http://www.hiothi.com/ Arnan Mandalia ------=_NextPart_000_0008_01C8111C.D318BF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Howdy ospf-archive
she loves it when i squirt cum all over her = face=20 now
http://www.hiothi.com/
Arnan Mandalia
------=_NextPart_000_0008_01C8111C.D318BF30-- From ospf-bounces@ietf.org Fri Oct 19 00:03:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiiz2-0001op-JD; Thu, 18 Oct 2007 23:57:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiiz1-0001o1-11 for ospf@ietf.org; Thu, 18 Oct 2007 23:57:11 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiiz0-0003qR-GO for ospf@ietf.org; Thu, 18 Oct 2007 23:57:10 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ5001A04A1NL@szxga03-in.huawei.com> for ospf@ietf.org; Fri, 19 Oct 2007 11:56:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ5000X44A0M3@szxga03-in.huawei.com> for ospf@ietf.org; Fri, 19 Oct 2007 11:56:25 +0800 (CST) Received: from d68733d ([10.111.12.195]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQ500FDV4A01A@szxml04-in.huawei.com> for ospf@ietf.org; Fri, 19 Oct 2007 11:56:24 +0800 (CST) Date: Fri, 19 Oct 2007 11:56:23 +0800 From: "Abhay D.S" To: ospf@ietf.org Message-id: <05f101c81204$047cdc40$c30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocol Question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Abhay D.S" List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org hi all, Suppose I am providing real-time transactions over IP in a non NSR environment(I dont invest much on getting a backup RP i.e). But I have NSF, owing to the ease of which OSPF can be used, I use OSPF to manage connections to WAN. And I have bought new I/0 modules which require a restart for all my routers for proper installation. Luckily, I have inservice upgrade on the boxes. Assuming that I am a new operator without any certifications under my belt, I dont have a beautiful NMS with colored buttons. But I must implement the new I/O cards and its features without disturbing the users who are using the network for routing transactions such as data backup over network or voice forwarding and other distributed applications running over TCP/IP using my network. I want to graceful restart all my routers one by one, called as cascaded re-starts, how can I make sure the transition is done seamlessly. I want the "this thing" to be automatic, since each router is graceful restarted and then then the next one is re-started and then the next one, automatically. I can write a script to do that, but I am not sure the forwarding will be safe, because it is difficult to control the network transient conditions. Any mechanism available ?. Thanks and Regards, Abhay _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From Mickey349@anfo.gr Fri Oct 19 07:58:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqSx-0007y5-AH for ospf-archive@megatron.ietf.org; Fri, 19 Oct 2007 07:56:35 -0400 Received: from ppp-175-39.21-151.libero.it ([151.21.39.175] helo=ppp-91-36.21-151.libero.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiqSw-0000OY-Kh for ospf-archive@megatron.ietf.org; Fri, 19 Oct 2007 07:56:35 -0400 Received: by 10.60.28.215 with SMTP id ZLONiiBtfuAOv; Fri, 19 Oct 2007 13:56:40 +0200 (GMT) Received: by 192.168.235.177 with SMTP id SwrZspkLqtwdfd.5908471307888; Fri, 19 Oct 2007 13:56:38 +0200 (GMT) Date: Fri, 19 Oct 2007 13:56:35 +0200 From: "Mickey Boulanger" Reply-To: "Mickey Boulanger" Message-ID: <658935086720.097871428750@anfo.gr> To: Subject: hurchton MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hey honey ospf-archive want big sausage? she wants it massive too http://www.ilmilu.com/ Mickey Boulanger From ospf-bounces@ietf.org Fri Oct 19 09:19:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iirgo-0002oR-8y; Fri, 19 Oct 2007 09:14:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iirgm-0002my-LV for ospf@ietf.org; Fri, 19 Oct 2007 09:14:56 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iirgl-0003Ix-Ng for ospf@ietf.org; Fri, 19 Oct 2007 09:14:56 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3B5FD982046; Fri, 19 Oct 2007 06:14:55 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20290-01; Fri, 19 Oct 2007 06:14:55 -0700 (PDT) Received: from [?*??O??IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 325EE982044; Fri, 19 Oct 2007 06:14:52 -0700 (PDT) In-Reply-To: <05f101c81204$047cdc40$c30c6f0a@china.huawei.com> References: <05f101c81204$047cdc40$c30c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Message-Id: From: Acee Lindem Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocol Question Date: Fri, 19 Oct 2007 09:13:14 -0400 To: "Abhay D.S" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0257368182==" Errors-To: ospf-bounces@ietf.org --===============0257368182== Content-Type: multipart/alternative; boundary=Apple-Mail-16--255969863 --Apple-Mail-16--255969863 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Abhay, Most of this borders on the implementation of the networking equipment's in-service upgrade. For now, let's just assume that you have redundant data place connectivity for the new line cards and solely need do the graceful restarts as indicated below. Again, this borders more on implementation. However, now the OSPFv2 MIB as described in RFC 4750 does support a variable which could be polled to determine when restart on a given router has completed. ospfRestartStatus OBJECT-TYPE SYNTAX INTEGER { notRestarting (1), plannedRestart (2), unplannedRestart (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Current status of OSPF graceful restart." ::= { ospfGeneralGroup 21 } Hope this helps, Acee On Oct 18, 2007, at 11:56 PM, Abhay D.S wrote: > hi all, > > Suppose I am providing real-time transactions over IP in a > non NSR environment(I dont invest much on getting a backup RP i.e). > > But I have NSF, owing to the ease of which OSPF can be used, I > use OSPF to manage connections to WAN. > > And I have bought new I/0 modules which require a restart for > all my routers for proper installation. > > Luckily, I have inservice upgrade on the boxes. > > Assuming that I am a new operator without any certifications under > my belt, I dont have a beautiful NMS with colored buttons. > > But I must implement the new I/O cards and its features without > disturbing > the users who are using the network for routing transactions such > as data > backup over network or voice forwarding and other distributed > applications > running over TCP/IP using my network. > > I want to graceful restart all my routers one by one, called as > cascaded > re-starts, how can I make sure the transition is done seamlessly. > > I want the "this thing" to be automatic, since each router is graceful > restarted > and then then the next one is re-started and then the next one, > automatically. > > I can write a script to do that, but I am not sure the forwarding > will be > safe, > because it is difficult to control the network transient conditions. > > Any mechanism available ?. > > Thanks and Regards, > Abhay > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf --Apple-Mail-16--255969863 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Abhay,
Most of this = borders on the implementation of the networking equipment's in-service = upgrade. For now, let's just assume that you have redundant data place = connectivity for the new line cards and solely need do the graceful = restarts as indicated below. Again, this borders more on implementation. = However, now the OSPFv2 MIB as described in RFC 4750 does support a = variable which could be polled to determine when restart on a given = router has completed.=A0

=A0ospfRestartStatus = OBJECT-TYPE
=A0=A0 =A0 =A0 = SYNTAX = =A0 =A0 =A0 = INTEGER { = notRestarting (1),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 plannedRestart (2),
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unplannedRestart = (3)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= }
=A0=A0 =A0 =A0 = MAX-ACCESS = =A0 = read-only
=A0=A0 =A0 =A0 = STATUS = =A0 =A0 =A0 = current
=A0=A0 =A0 =A0 = DESCRIPTION
=A0 =A0 =A0 =A0 =A0 = "Current = status of OSPF graceful restart."
=A0=A0 =A0 =A0 = ::=3D { = ospfGeneralGroup 21 }

=A0=A0
Hope this = helps,
Acee

On Oct 18, 2007, at 11:56 = PM, Abhay D.S wrote:

hi all,

Suppose I am providing real-time = transactions over IP in a
non NSR = environment(I dont invest much on getting a backup RP i.e).

But I = have NSF, owing to the ease of which OSPF can be used, I
use OSPF to manage connections to WAN.

And I = have bought new I/0 modules which require a restart for
all my routers for proper installation.

Luckily, = I have inservice upgrade on the boxes.

Assuming that = I am a new operator without any certifications under
my belt, I dont have a beautiful NMS with colored = buttons.

But I must implement the new I/O cards and its = features without disturbing
the users who = are using the network for routing transactions such as data
backup over network or voice forwarding and other = distributed applications
running over = TCP/IP using my network.

I want to graceful restart all = my routers one by one, called as cascaded

I want the "this thing" to be automatic, since each = router is graceful
restarted
and then then the next one is re-started and then = the next one,
automatically.

I can = write a script to do that, but I am not sure the forwarding will = be
safe,
because it is = difficult to control the network transient conditions.

Any = mechanism available ?.
Thanks and Regards,
Abhay




OSPF mailing list
=

= --Apple-Mail-16--255969863-- --===============0257368182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0257368182==-- From ospf-bounces@ietf.org Fri Oct 19 15:57:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IixuO-0006Sh-1K; Fri, 19 Oct 2007 15:53:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IixuK-0005n6-GR for ospf@ietf.org; Fri, 19 Oct 2007 15:53:21 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iixth-0002WR-E8 for ospf@ietf.org; Fri, 19 Oct 2007 15:52:41 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JagAHapVrWNlKreq7J0MgvmqUklsV87f0EjOFVnX1PNreLDp4rwT+f0ErwL1UUiY; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.86.15] (helo=earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Iixtf-0007nJ-VS; Fri, 19 Oct 2007 15:52:40 -0400 Message-ID: <471908FA.CD147059@earthlink.net> Date: Fri, 19 Oct 2007 12:43:54 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Abhay D.S" Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocolQuestion References: <05f101c81204$047cdc40$c30c6f0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79a9837d60f6faf109ea8cb7ec929e2791350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.86.15 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Abhay D.S., et al, Their are multiple issues that need to be addressed before you can even attempt to sucessfully perform a cascade restart: 1) NSF is a patented process that is specific to one well-known company. 2) Their is no GUARANTEE that any Restart will be sucessful, that the LSDB will be stable and/or that helper(s) exist. 3) It would be my initial expectation that resumption of recieving "aliveness" from a restarting router COULD be a passive method. Mitchell Erblich ----------------- "Abhay D.S" wrote: > > hi all, > > Suppose I am providing real-time transactions over IP in a > non NSR environment(I dont invest much on getting a backup RP i.e). > > But I have NSF, owing to the ease of which OSPF can be used, I > use OSPF to manage connections to WAN. > > And I have bought new I/0 modules which require a restart for > all my routers for proper installation. > > Luckily, I have inservice upgrade on the boxes. > > Assuming that I am a new operator without any certifications under > my belt, I dont have a beautiful NMS with colored buttons. > > But I must implement the new I/O cards and its features without disturbing > the users who are using the network for routing transactions such as data > backup over network or voice forwarding and other distributed applications > running over TCP/IP using my network. > > I want to graceful restart all my routers one by one, called as cascaded > re-starts, how can I make sure the transition is done seamlessly. > > I want the "this thing" to be automatic, since each router is graceful > restarted > and then then the next one is re-started and then the next one, > automatically. > > I can write a script to do that, but I am not sure the forwarding will be > safe, > because it is difficult to control the network transient conditions. > > Any mechanism available ?. > > Thanks and Regards, > Abhay > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From Normel.Jeong@autoren.mysteria3000.de Fri Oct 19 16:05:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiy6V-0005pV-PP for ospf-archive@megatron.ietf.org; Fri, 19 Oct 2007 16:05:55 -0400 Received: from host21-126-dynamic.57-82-r.retail.telecomitalia.it ([82.57.126.21] helo=host253-127-dynamic.17-87-r.retail.telecomitalia.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iiy6P-0008Pg-Eg for ospf-archive@megatron.ietf.org; Fri, 19 Oct 2007 16:05:55 -0400 Received: from scardina-6b0d81 ([159.117.88.123]:18232 "EHLO scardina-6b0d81" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host253-127-dynamic.17-87-r.retail.telecomitalia.it with ESMTP id S22ZBCCRVIRJAYVR (ORCPT ); Fri, 19 Oct 2007 22:07:54 +0200 Message-ID: <000201c8128b$b377b4e0$fd7f1157@scardina6b0d81> From: "Normel Jeong" To: Subject: yllohtnu Date: Fri, 19 Oct 2007 22:07:40 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8129C.770084E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.2 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d ------=_NextPart_000_0009_01C8129C.770084E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Monday update. Symb: T A D F (Tactical Air Defense Services) Tactical Air Defense Services (TADS), a leading provider of tactical = aviation training and services to the United States and Allied Nations, has = quietly positioned itself to utilize a fleet of the most advanced fighter jets = and aerial refueling tankers in the world for military aviation training = needs. Those who get in now are likely to see profits soar through the = stratosphere. Headquartered at the Grayson County Airport in Denison, Texas =96 formerly the Perrin Air Force Base =96 Tactical Air Defense has the = capability to provide clients with the most comprehensive logistical, repair, and = aircraft training support available. TADS IS AS CLOSE AS IT COMES TO A SUREFIRE = MONEY-MAKER. ------=_NextPart_000_0009_01C8129C.770084E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Monday update.
Symb: T A D F (Tactical Air Defense = Services)
Tactical Air Defense Services (TADS), a = leading provider=20 of tactical aviation
training and services to the United States and = Allied=20 Nations, has quietly
positioned itself to utilize a fleet of the = most=20 advanced fighter jets and
aerial refueling tankers in the world for = military=20 aviation training needs.
Those who get in now are likely to see profits = soar=20 through the stratosphere.
Headquartered at the Grayson County Airport in = Denison,=20 Texas =96
formerly the Perrin Air Force Base =96 = Tactical Air=20 Defense has the capability
to provide clients with the most comprehensive = logistical, repair, and aircraft
training support available. TADS IS AS CLOSE = AS IT=20 COMES TO A SUREFIRE MONEY-MAKER.
------=_NextPart_000_0009_01C8129C.770084E0-- From ospf-bounces@ietf.org Fri Oct 19 23:30:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij4xe-00012v-2F; Fri, 19 Oct 2007 23:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij4xb-00012S-Rd for ospf@ietf.org; Fri, 19 Oct 2007 23:25:11 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij4xU-0005sv-Ni for ospf@ietf.org; Fri, 19 Oct 2007 23:25:11 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ600HBMXGFGY@szxga02-in.huawei.com> for ospf@ietf.org; Sat, 20 Oct 2007 11:24:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ600FKSXGDKH@szxga02-in.huawei.com> for ospf@ietf.org; Sat, 20 Oct 2007 11:24:15 +0800 (CST) Received: from d68733d ([10.111.12.195]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQ6004AIXGCBR@szxml04-in.huawei.com> for ospf@ietf.org; Sat, 20 Oct 2007 11:24:13 +0800 (CST) Date: Sat, 20 Oct 2007 11:24:10 +0800 From: "Abhay D.S" Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocol Question To: Acee Lindem , "Abhay D.S" Message-id: <062301c812c8$aecb5720$c30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal References: <05f101c81204$047cdc40$c30c6f0a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Abhay D.S" List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1184028424==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1184028424== Content-type: multipart/alternative; boundary="Boundary_(ID_Qad2Q3lzSnK3LBXq9WZSUA)" This is a multi-part message in MIME format. --Boundary_(ID_Qad2Q3lzSnK3LBXq9WZSUA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hello Acee, a) Restart complete variable poll is one method after restart I am trying to find a method before restart to be deterministic. A simple analogy in TCP. For example..in TCP, just after connection establishment, I want start sending data, at the same time the remote link had some problem. a) Scenario 1 0sec .....5 Sec...(ok).....10 Sec (ok).....15 Sec (ok).....[DONE] Continue restart y/n ? : y Attempting graceful restart..... [OK] b) Scenario 2 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to network conditions] 0sec .....5 Sec...(Wait a While).....10 Sec (Ok)...15 Sec (ok).....[DONE] Continue restart y/n ? : y Attempting graceful restart...... [OK] c) Scenario 3 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to network conditions] 0sec .....5 Sec...(Wait a While).....10 Sec (Ok)...15 Sec (Wait a While).....[Retrying due to network conditions] 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to network conditions] Continuing restart may affect forwarding... Continue anyway ? y/n .....n [OK] The time line above considers a network stable. After the restart is done I can follow method a) Thanks for your reply, Regards, Abhay ----- Original Message ----- From: Acee Lindem To: Abhay D.S Cc: ospf@ietf.org Sent: Friday, October 19, 2007 9:13 PM Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocol Question Hi Abhay, Most of this borders on the implementation of the networking equipment's in-service upgrade. For now, let's just assume that you have redundant data place connectivity for the new line cards and solely need do the graceful restarts as indicated below. Again, this borders more on implementation. However, now the OSPFv2 MIB as described in RFC 4750 does support a variable which could be polled to determine when restart on a given router has completed. ospfRestartStatus OBJECT-TYPE SYNTAX INTEGER { notRestarting (1), plannedRestart (2), unplannedRestart (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Current status of OSPF graceful restart." ::= { ospfGeneralGroup 21 } Hope this helps, Acee On Oct 18, 2007, at 11:56 PM, Abhay D.S wrote: hi all, Suppose I am providing real-time transactions over IP in a non NSR environment(I dont invest much on getting a backup RP i.e). But I have NSF, owing to the ease of which OSPF can be used, I use OSPF to manage connections to WAN. And I have bought new I/0 modules which require a restart for all my routers for proper installation. Luckily, I have inservice upgrade on the boxes. Assuming that I am a new operator without any certifications under my belt, I dont have a beautiful NMS with colored buttons. But I must implement the new I/O cards and its features without disturbing the users who are using the network for routing transactions such as data backup over network or voice forwarding and other distributed applications running over TCP/IP using my network. I want to graceful restart all my routers one by one, called as cascaded re-starts, how can I make sure the transition is done seamlessly. I want the "this thing" to be automatic, since each router is graceful restarted and then then the next one is re-started and then the next one, automatically. I can write a script to do that, but I am not sure the forwarding will be safe, because it is difficult to control the network transient conditions. Any mechanism available ?. Thanks and Regards, Abhay _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --Boundary_(ID_Qad2Q3lzSnK3LBXq9WZSUA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hello Acee,
 
a) Restart complete variable poll is one method after restart
 
I am trying to find a method before restart to be deterministic.
 
A simple analogy in TCP.
 
For example..in TCP, just after connection establishment, I want
start sending data, at the same time the remote link had some problem.
 
 
a) Scenario 1
 
0sec .....5 Sec...(ok).....10 Sec (ok).....15 Sec (ok).....[DONE]
 
Continue restart y/n ? : y
 
Attempting graceful restart.....
 
[OK]
 
b) Scenario 2
 
0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to network conditions]
 
 
0sec .....5 Sec...(Wait a While).....10 Sec (Ok)...15 Sec (ok).....[DONE]
 
Continue restart y/n ? : y
 
Attempting graceful restart......
 
[OK]
 
c) Scenario 3
 
0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to network conditions]
 
 
0sec .....5 Sec...(Wait a While).....10 Sec (Ok)...15 Sec (Wait a While).....[Retrying due to network conditions]
 
0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to network conditions]
 
Continuing restart may affect forwarding...
Continue anyway ? y/n .....n
 
[OK]
 
 
The time line above considers a network stable.
 
 
After the restart is done I can follow method a)
 
 
Thanks for your reply,
Regards,
Abhay
 
 
 
 
 
----- Original Message -----
Sent: Friday, October 19, 2007 9:13 PM
Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocol Question

Hi Abhay,
Most of this borders on the implementation of the networking equipment's in-service upgrade. For now, let's just assume that you have redundant data place connectivity for the new line cards and solely need do the graceful restarts as indicated below. Again, this borders more on implementation. However, now the OSPFv2 MIB as described in RFC 4750 does support a variable which could be polled to determine when restart on a given router has completed. 

 ospfRestartStatus OBJECT-TYPE
       SYNTAX       INTEGER { notRestarting (1),
                              plannedRestart (2),
                              unplannedRestart (3)
                            }
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
          "Current status of OSPF graceful restart."
       ::= { ospfGeneralGroup 21 }

  
Hope this helps,
Acee

On Oct 18, 2007, at 11:56 PM, Abhay D.S wrote:

hi all,

Suppose I am providing real-time transactions over IP in a
non NSR environment(I dont invest much on getting a backup RP i.e).

But I have NSF, owing to the ease of which OSPF can be used, I
use OSPF to manage connections to WAN.

And I have bought new I/0 modules which require a restart for
all my routers for proper installation.

Luckily, I have inservice upgrade on the boxes.

Assuming that I am a new operator without any certifications under
my belt, I dont have a beautiful NMS with colored buttons.

But I must implement the new I/O cards and its features without disturbing
the users who are using the network for routing transactions such as data
backup over network or voice forwarding and other distributed applications
running over TCP/IP using my network.

I want to graceful restart all my routers one by one, called as cascaded
re-starts, how can I make sure the transition is done seamlessly.

I want the "this thing" to be automatic, since each router is graceful
restarted
and then then the next one is re-started and then the next one,
automatically.

I can write a script to do that, but I am not sure the forwarding will be
safe,
because it is difficult to control the network transient conditions.

Any mechanism available ?.

Thanks and Regards,
Abhay




_______________________________________________
OSPF mailing list

--Boundary_(ID_Qad2Q3lzSnK3LBXq9WZSUA)-- --===============1184028424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1184028424==-- From ospf-bounces@ietf.org Fri Oct 19 23:30:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij50J-0006Xm-OX; Fri, 19 Oct 2007 23:27:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij50I-0006Xh-8A for ospf@ietf.org; Fri, 19 Oct 2007 23:27:58 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij50H-0008NJ-KL for ospf@ietf.org; Fri, 19 Oct 2007 23:27:58 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ6000T5XLF8E@szxga03-in.huawei.com> for ospf@ietf.org; Sat, 20 Oct 2007 11:27:15 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ6006OBXLDWV@szxga03-in.huawei.com> for ospf@ietf.org; Sat, 20 Oct 2007 11:27:15 +0800 (CST) Received: from d68733d ([10.111.12.195]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQ600K6QXLDPP@szxml03-in.huawei.com> for ospf@ietf.org; Sat, 20 Oct 2007 11:27:13 +0800 (CST) Date: Sat, 20 Oct 2007 11:27:11 +0800 From: "Abhay D.S" Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocolQuestion To: Erblichs , "Abhay D.S" Message-id: <062b01c812c9$1a3a8b70$c30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <05f101c81204$047cdc40$c30c6f0a@china.huawei.com> <471908FA.CD147059@earthlink.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Abhay D.S" List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Mitchell, 2) Their is no GUARANTEE that any Restart will be sucessful, that the LSDB will be stable and/or that helper(s) exist. I wanted an automated and deterministic number 2. Any ideas or any attempts in the direction of 2 ? With Regards, Abhay ----- Original Message ----- From: "Erblichs" To: "Abhay D.S" Cc: Sent: Saturday, October 20, 2007 3:43 AM Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocolQuestion > Abhay D.S., et al, > > Their are multiple issues that need to be addressed > before you can even attempt to sucessfully perform > a cascade restart: > > 1) NSF is a patented process that is specific to > one well-known company. > > 2) Their is no GUARANTEE that any Restart will > be sucessful, that the LSDB will be stable and/or > that helper(s) exist. > > 3) It would be my initial expectation that > resumption of recieving "aliveness" from a > restarting router COULD be a passive method. > > Mitchell Erblich > ----------------- > > "Abhay D.S" wrote: > > > > hi all, > > > > Suppose I am providing real-time transactions over IP in a > > non NSR environment(I dont invest much on getting a backup RP i.e). > > > > But I have NSF, owing to the ease of which OSPF can be used, I > > use OSPF to manage connections to WAN. > > > > And I have bought new I/0 modules which require a restart for > > all my routers for proper installation. > > > > Luckily, I have inservice upgrade on the boxes. > > > > Assuming that I am a new operator without any certifications under > > my belt, I dont have a beautiful NMS with colored buttons. > > > > But I must implement the new I/O cards and its features without disturbing > > the users who are using the network for routing transactions such as data > > backup over network or voice forwarding and other distributed applications > > running over TCP/IP using my network. > > > > I want to graceful restart all my routers one by one, called as cascaded > > re-starts, how can I make sure the transition is done seamlessly. > > > > I want the "this thing" to be automatic, since each router is graceful > > restarted > > and then then the next one is re-started and then the next one, > > automatically. > > > > I can write a script to do that, but I am not sure the forwarding will be > > safe, > > because it is difficult to control the network transient conditions. > > > > Any mechanism available ?. > > > > Thanks and Regards, > > Abhay > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sat Oct 20 04:23:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij9XR-0003kL-Jp; Sat, 20 Oct 2007 04:18:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij9XQ-0003e6-0u for ospf@ietf.org; Sat, 20 Oct 2007 04:18:28 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij9XK-0008MM-9h for ospf@ietf.org; Sat, 20 Oct 2007 04:18:22 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=hQOfR5s24ExsCZ8g2ZHiaaoxjYAkyojoFtyXWdweX1nHGQysydzLilza6vlNsInO; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.86.15] (helo=earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ij9XI-0004Ui-V7; Sat, 20 Oct 2007 04:18:21 -0400 Message-ID: <4719B607.770D8C01@earthlink.net> Date: Sat, 20 Oct 2007 01:02:15 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Abhay D.S" Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocolQuestion References: <05f101c81204$047cdc40$c30c6f0a@china.huawei.com> <062301c812c8$aecb5720$c30c6f0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7913c99afb0bd5922c48c20fa03c90c611350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.86.15 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Abhay D.S., Sorry about the top post, but.. TCP has a slow-start mechanism with ACK clocking to verify completion of xmit'ed data, until a threshold is met or, Until 2 or 3 DUP ACKs are seen and then rexmited or a coarse grain timeout occurs, However, TCP does not guarantee that the recvr will actually recieve data xmited by the send, just that if the data arrives then, it will send acks.. And again, their is no guarantee that the acks will be recieved, so the sender can send more data. Mitchell Erblich ----------------- > "Abhay D.S" wrote: > > Hello Acee, > > a) Restart complete variable poll is one method after restart > > I am trying to find a method before restart to be deterministic. > > A simple analogy in TCP. > > For example..in TCP, just after connection establishment, I want > start sending data, at the same time the remote link had some problem. > > > a) Scenario 1 > > 0sec .....5 Sec...(ok).....10 Sec (ok).....15 Sec (ok).....[DONE] > > Continue restart y/n ? : y > > Attempting graceful restart..... > > [OK] > > b) Scenario 2 > > 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to > network conditions] > > > 0sec .....5 Sec...(Wait a While).....10 Sec (Ok)...15 Sec > (ok).....[DONE] > > Continue restart y/n ? : y > > Attempting graceful restart...... > > [OK] > > c) Scenario 3 > > 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to > network conditions] > > > 0sec .....5 Sec...(Wait a While).....10 Sec (Ok)...15 Sec (Wait a > While).....[Retrying due to network conditions] > > 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to > network conditions] > > Continuing restart may affect forwarding... > Continue anyway ? y/n .....n > > [OK] > > > The time line above considers a network stable. > > > After the restart is done I can follow method a) > > > Thanks for your reply, > Regards, > Abhay > > > > > > > ----- Original Message ----- > From: Acee Lindem > To: Abhay D.S > Cc: ospf@ietf.org > Sent: Friday, October 19, 2007 9:13 PM > Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for > OSPF protocol Question > > Hi Abhay, > Most of this borders on the implementation of the networking > equipment's in-service upgrade. For now, let's just assume > that you have redundant data place connectivity for the new > line cards and solely need do the graceful restarts as > indicated below. Again, this borders more on implementation. > However, now the OSPFv2 MIB as described in RFC 4750 does > support a variable which could be polled to determine when > restart on a given router has completed. > > ospfRestartStatus OBJECT-TYPE > SYNTAX INTEGER { notRestarting (1), > plannedRestart (2), > unplannedRestart (3) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Current status of OSPF graceful restart." > ::= { ospfGeneralGroup 21 } > > > Hope this helps, > Acee > > On Oct 18, 2007, at 11:56 PM, Abhay D.S wrote: > > > hi all, > > > > Suppose I am providing real-time transactions over IP in a > > non NSR environment(I dont invest much on getting a backup > > RP i.e). > > > > But I have NSF, owing to the ease of which OSPF can be > > used, I > > use OSPF to manage connections to WAN. > > > > And I have bought new I/0 modules which require a restart > > for > > all my routers for proper installation. > > > > Luckily, I have inservice upgrade on the boxes. > > > > Assuming that I am a new operator without any > > certifications under > > my belt, I dont have a beautiful NMS with colored buttons. > > > > But I must implement the new I/O cards and its features > > without disturbing > > the users who are using the network for routing > > transactions such as data > > backup over network or voice forwarding and other > > distributed applications > > running over TCP/IP using my network. > > > > I want to graceful restart all my routers one by one, > > called as cascaded > > re-starts, how can I make sure the transition is done > > seamlessly. > > > > I want the "this thing" to be automatic, since each router > > is graceful > > restarted > > and then then the next one is re-started and then the next > > one, > > automatically. > > > > I can write a script to do that, but I am not sure the > > forwarding will be > > safe, > > because it is difficult to control the network transient > > conditions. > > > > Any mechanism available ?. > > > > Thanks and Regards, > > Abhay > > > > > > > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > > > --------------------------------------------------------------- > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sat Oct 20 04:41:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij9rr-0000zu-VR; Sat, 20 Oct 2007 04:39:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij9rr-0000rh-3k for ospf@ietf.org; Sat, 20 Oct 2007 04:39:35 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij9rf-00076b-Uk for ospf@ietf.org; Sat, 20 Oct 2007 04:39:30 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Gw7U6IW1eILE6lfFDoH6aOPvL4W21i9MU3q0n9G7wtxNOUagikRwCPXwvtH4jKS3; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.86.15] (helo=earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ij9rQ-0007Vx-A4; Sat, 20 Oct 2007 04:39:08 -0400 Message-ID: <4719BA7F.BC701169@earthlink.net> Date: Sat, 20 Oct 2007 01:21:19 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Abhay D.S" Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPFprotocolQuestion References: <05f101c81204$047cdc40$c30c6f0a@china.huawei.com> <471908FA.CD147059@earthlink.net> <062b01c812c9$1a3a8b70$c30c6f0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec794495fdba8f849031a5c7daefcd42b151350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.86.15 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Abhay D.S., Actually it is just a bit more complicated. With OSPF, we should start with a case of two routers. How does the restarting router know that the restart is done and how does the other router know that the restart is done? The restarting router can determine whether NSF and restart is done. Whether restart required a a standard resync of the LSDB is almost irrelevant. So, the question is why must Gracefull be successful? It basicly just "reduces" overhead while NOT distrupting forwarding. Thus, It is done when it re-starts sending HELLOs and re-extablishes full adjs from the perspective of the 2nd router. The hellos are the aliveness criteria from my earlier post. ` So, you MIGHT want to track the nbr FSM if you have access to the OSPF source code. Mitchell Erblich ---------------- "Abhay D.S" wrote: > > Mitchell, > > 2) Their is no GUARANTEE that any Restart will > be sucessful, that the LSDB will be stable and/or > that helper(s) exist. > > I wanted an automated and deterministic number 2. > > Any ideas or any attempts in the direction of 2 ? > > With Regards, > Abhay > > ----- Original Message ----- > From: "Erblichs" > To: "Abhay D.S" > Cc: > Sent: Saturday, October 20, 2007 3:43 AM > Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF > protocolQuestion > > > Abhay D.S., et al, > > > > Their are multiple issues that need to be addressed > > before you can even attempt to sucessfully perform > > a cascade restart: > > > > 1) NSF is a patented process that is specific to > > one well-known company. > > > > 2) Their is no GUARANTEE that any Restart will > > be sucessful, that the LSDB will be stable and/or > > that helper(s) exist. > > > > 3) It would be my initial expectation that > > resumption of recieving "aliveness" from a > > restarting router COULD be a passive method. > > > > Mitchell Erblich > > ----------------- > > > > "Abhay D.S" wrote: > > > > > > hi all, > > > > > > Suppose I am providing real-time transactions over IP in a > > > non NSR environment(I dont invest much on getting a backup RP i.e). > > > > > > But I have NSF, owing to the ease of which OSPF can be used, I > > > use OSPF to manage connections to WAN. > > > > > > And I have bought new I/0 modules which require a restart for > > > all my routers for proper installation. > > > > > > Luckily, I have inservice upgrade on the boxes. > > > > > > Assuming that I am a new operator without any certifications under > > > my belt, I dont have a beautiful NMS with colored buttons. > > > > > > But I must implement the new I/O cards and its features without > disturbing > > > the users who are using the network for routing transactions such as > data > > > backup over network or voice forwarding and other distributed > applications > > > running over TCP/IP using my network. > > > > > > I want to graceful restart all my routers one by one, called as cascaded > > > re-starts, how can I make sure the transition is done seamlessly. > > > > > > I want the "this thing" to be automatic, since each router is graceful > > > restarted > > > and then then the next one is re-started and then the next one, > > > automatically. > > > > > > I can write a script to do that, but I am not sure the forwarding will > be > > > safe, > > > because it is difficult to control the network transient conditions. > > > > > > Any mechanism available ?. > > > > > > Thanks and Regards, > > > Abhay > > > > > > _______________________________________________ > > > OSPF mailing list > > > OSPF@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ricci.Priest@ojmrarchitects.net Sat Oct 20 05:53:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjB1j-0008LM-3g for ospf-archive@megatron.ietf.org; Sat, 20 Oct 2007 05:53:51 -0400 Received: from c-76-119-127-228.hsd1.ma.comcast.net ([76.119.127.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjB1i-0002rn-Pw for ospf-archive@megatron.ietf.org; Sat, 20 Oct 2007 05:53:51 -0400 Received: from nickhscomp ([189.171.70.88]:29644 "EHLO nickhscomp" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by c-76-119-127-228.hsd1.ma.comcast.net with ESMTP id S22ONVONWPKVMBUX (ORCPT ); Sat, 20 Oct 2007 02:54:12 -0700 Message-ID: <000901c812ff$1f57d730$e47f774c@nickhscomp> From: "ricci Priest" To: Subject: takelter Date: Sat, 20 Oct 2007 02:53:53 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C812C4.72F8FF30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0007_01C812C4.72F8FF30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable welcum ospf-archive dont blow your load just because she touched your dick! http://kakakul.com/ ricci Priest ------=_NextPart_000_0007_01C812C4.72F8FF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
welcum ospf-archive
dont blow your load just because she touched = your=20 dick!
http://kakakul.com/
ricci Priest
------=_NextPart_000_0007_01C812C4.72F8FF30-- From ospf-bounces@ietf.org Sat Oct 20 06:16:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjBKY-0006Zi-Nd; Sat, 20 Oct 2007 06:13:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjBKX-0006Za-32 for ospf@ietf.org; Sat, 20 Oct 2007 06:13:17 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjBKV-0003Pp-Tm for ospf@ietf.org; Sat, 20 Oct 2007 06:13:17 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ700BGSGCWB3@szxga01-in.huawei.com> for ospf@ietf.org; Sat, 20 Oct 2007 18:12:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ700BGSGCUKZ@szxga01-in.huawei.com> for ospf@ietf.org; Sat, 20 Oct 2007 18:12:32 +0800 (CST) Received: from d68733d ([10.111.12.195]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQ7006RXGCUE1@szxml04-in.huawei.com> for ospf@ietf.org; Sat, 20 Oct 2007 18:12:30 +0800 (CST) Date: Sat, 20 Oct 2007 18:12:30 +0800 From: "Abhay D.S" Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocolQuestion To: Erblichs , "Abhay D.S" Message-id: <064e01c81301$b9709f80$c30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <05f101c81204$047cdc40$c30c6f0a@china.huawei.com> <062301c812c8$aecb5720$c30c6f0a@china.huawei.com> <4719B607.770D8C01@earthlink.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Abhay D.S" List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Mitchell, Agreed, I rather not have a TCP style in OSPF graceful restart. But I am talking about TCP Timeout, but an application has already done much work to send data to end point, before time out occurs. I would rather have a request reply mechanism , which is similar to pinging end points, before actually beginning the signaling. Which I have shown in the time line. Stressing the point of only what I want before the irreversible restart. Regards, Abhay ----- Original Message ----- From: "Erblichs" To: "Abhay D.S" Cc: "Acee Lindem" ; Sent: Saturday, October 20, 2007 4:02 PM Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocolQuestion > Abhay D.S., > > Sorry about the top post, but.. > > TCP has a slow-start mechanism with ACK > clocking to verify completion of xmit'ed data, > until a threshold is met or, > > Until 2 or 3 DUP ACKs are seen and then > rexmited or a coarse grain timeout occurs, > > However, TCP does not guarantee that the > recvr will actually recieve data xmited > by the send, just that if the data arrives > then, it will send acks.. > > And again, their is no guarantee that the > acks will be recieved, so the sender can > send more data. > > Mitchell Erblich > ----------------- > > > "Abhay D.S" wrote: > > > > Hello Acee, > > > > a) Restart complete variable poll is one method after restart > > > > I am trying to find a method before restart to be deterministic. > > > > A simple analogy in TCP. > > > > For example..in TCP, just after connection establishment, I want > > start sending data, at the same time the remote link had some problem. > > > > > > a) Scenario 1 > > > > 0sec .....5 Sec...(ok).....10 Sec (ok).....15 Sec (ok).....[DONE] > > > > Continue restart y/n ? : y > > > > Attempting graceful restart..... > > > > [OK] > > > > b) Scenario 2 > > > > 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to > > network conditions] > > > > > > 0sec .....5 Sec...(Wait a While).....10 Sec (Ok)...15 Sec > > (ok).....[DONE] > > > > Continue restart y/n ? : y > > > > Attempting graceful restart...... > > > > [OK] > > > > c) Scenario 3 > > > > 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to > > network conditions] > > > > > > 0sec .....5 Sec...(Wait a While).....10 Sec (Ok)...15 Sec (Wait a > > While).....[Retrying due to network conditions] > > > > 0sec .....5 Sec...(ok).....10 Sec (Wait a While)....[Retrying due to > > network conditions] > > > > Continuing restart may affect forwarding... > > Continue anyway ? y/n .....n > > > > [OK] > > > > > > The time line above considers a network stable. > > > > > > After the restart is done I can follow method a) > > > > > > Thanks for your reply, > > Regards, > > Abhay > > > > > > > > > > > > > > ----- Original Message ----- > > From: Acee Lindem > > To: Abhay D.S > > Cc: ospf@ietf.org > > Sent: Friday, October 19, 2007 9:13 PM > > Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for > > OSPF protocol Question > > > > Hi Abhay, > > Most of this borders on the implementation of the networking > > equipment's in-service upgrade. For now, let's just assume > > that you have redundant data place connectivity for the new > > line cards and solely need do the graceful restarts as > > indicated below. Again, this borders more on implementation. > > However, now the OSPFv2 MIB as described in RFC 4750 does > > support a variable which could be polled to determine when > > restart on a given router has completed. > > > > ospfRestartStatus OBJECT-TYPE > > SYNTAX INTEGER { notRestarting (1), > > plannedRestart (2), > > unplannedRestart (3) > > } > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "Current status of OSPF graceful restart." > > ::= { ospfGeneralGroup 21 } > > > > > > Hope this helps, > > Acee > > > > On Oct 18, 2007, at 11:56 PM, Abhay D.S wrote: > > > > > hi all, > > > > > > Suppose I am providing real-time transactions over IP in a > > > non NSR environment(I dont invest much on getting a backup > > > RP i.e). > > > > > > But I have NSF, owing to the ease of which OSPF can be > > > used, I > > > use OSPF to manage connections to WAN. > > > > > > And I have bought new I/0 modules which require a restart > > > for > > > all my routers for proper installation. > > > > > > Luckily, I have inservice upgrade on the boxes. > > > > > > Assuming that I am a new operator without any > > > certifications under > > > my belt, I dont have a beautiful NMS with colored buttons. > > > > > > But I must implement the new I/O cards and its features > > > without disturbing > > > the users who are using the network for routing > > > transactions such as data > > > backup over network or voice forwarding and other > > > distributed applications > > > running over TCP/IP using my network. > > > > > > I want to graceful restart all my routers one by one, > > > called as cascaded > > > re-starts, how can I make sure the transition is done > > > seamlessly. > > > > > > I want the "this thing" to be automatic, since each router > > > is graceful > > > restarted > > > and then then the next one is re-started and then the next > > > one, > > > automatically. > > > > > > I can write a script to do that, but I am not sure the > > > forwarding will be > > > safe, > > > because it is difficult to control the network transient > > > conditions. > > > > > > Any mechanism available ?. > > > > > > Thanks and Regards, > > > Abhay > > > > > > > > > > > > > > > _______________________________________________ > > > OSPF mailing list > > > OSPF@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ospf > > > > > > > --------------------------------------------------------------- > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From donevskiaqx@archindustrie.com Sun Oct 21 12:05:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjdIg-0006kM-6a for ospf-archive@megatron.ietf.org; Sun, 21 Oct 2007 12:05:14 -0400 Received: from host244-209-dynamic.49-82-r.retail.telecomitalia.it ([82.49.209.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjdIf-0005vd-8f for ospf-archive@megatron.ietf.org; Sun, 21 Oct 2007 12:05:14 -0400 Received: by 10.115.89.84 with SMTP id fMkaRAcjWBmtX; Sun, 21 Oct 2007 18:05:17 +0200 (GMT) Received: by 192.168.239.87 with SMTP id MqDxiWbAipJUwS.9511678949814; Sun, 21 Oct 2007 18:05:15 +0200 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 21 Oct 2007 18:05:12 +0200 To: ospf-archive@megatron.ietf.org From: "Hanyu donevski" Subject: seirewod Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.5 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Yo yo ospf-archive hit that pussy and hit it hard with a new imrpoved cock size http://learmn.com/ Hanyu donevski From bmbienesraices@candemgray.com Mon Oct 22 05:15:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjtO0-0006JV-4w for ospf-archive@lists.ietf.org; Mon, 22 Oct 2007 05:15:48 -0400 Received: from [66.255.201.10] (helo=jmjqn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IjtNu-0005e4-Jw for ospf-archive@lists.ietf.org; Mon, 22 Oct 2007 05:15:44 -0400 Received: from uijg ([149.104.110.89]) by jmjqn (8.13.5/8.13.5) with SMTP id l9M9HWZa014608; Mon, 22 Oct 2007 05:17:32 -0400 Message-ID: <471C6A3D.4050805@candemgray.com> Date: Mon, 22 Oct 2007 05:15:41 -0400 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ospf-archive@lists.ietf.org Subject: Have you seen this hilarious greeting? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Here is your laughing Kitty Card. http://71.194.151.223/ From tek@qcsi.com Mon Oct 22 06:27:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjuVk-0006OV-SX; Mon, 22 Oct 2007 06:27:52 -0400 Received: from [88.233.26.153] (helo=dsl88-233-6809.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjuVQ-0000Tl-MD; Mon, 22 Oct 2007 06:27:37 -0400 Received: from [88.233.26.153] by qcsi.com.inbound35.mxlogic.net; Mon, 22 Oct 2007 12:27:48 +0200 From: "Eliseo Holman" To: Subject: Cashmore expected to plead guilty to reduced charge; testify against four others Date: Mon, 22 Oct 2007 12:27:48 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000E_01C814A6.F4B33110" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Aca6Q67B9JRFBA3AKQ80SV9V43I264== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <01c814a6$f4b33110$991ae958@tek> X-Spam-Score: 1.6 (+) X-Scan-Signature: 86a4d7ebdc337882c86d755b1c60a122 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C814A6.F4B33110 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C814A6.F4B33110" ------=_NextPart_001_000F_01C814A6.F4B33110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Despite U.S. pledges of cooperation and new ideas on missile defense, Secretary of State Condoleezza Rice and Defense Secretary Robert Gates were warned by President Vladimir Putin to back off on missile defense plans for the former Soviet sphere."We may decide someday to put missile defense systems on the moon, but before we get to that we may lose a chance for agreement because of you implementing your own plans," he told Rice and Gates in Russian, according to an Associated Press translation.In combative comments that took the U.S. side aback during a photo session, Putin criticized Bush's pet project and threatened to pull out of a Cold War-era treaty that limits intermediate-range missiles.Meanwhile, two U.S. soldiers were killed and five others were wounded in a mortar attack launched "in the vicinity of Baghdad" on Wednesday, the U.S. military said Saturday. The deaths put the total number of U.S. military personnel killed in the Iraq war at 3,827.The attack comes a day after a security official in Iraq's Salaheddin province said that a U.S. military operation Thursday night killed 20 civilians, most of them women and children. Full storyU.S. military planners quietly have stepped up a review of alternatives in case the Turkish government restricts U.S. access to Turkish airspace or cuts off access to the air base at Incirlik, Turkey, CNN has learned.The Pentagon plans to install 10 missile interceptors in Poland, linked to a missile tracking radar in the Czech Republic. The Pentagon says the system will provide some protection in Europe and beyond for long-range missiles launched from Iran, but Russia believes the system is a step toward undermining the deterrent value of its nuclear arsenal.Russian President Vladimir Putin says any treaty must be "universal in nature."Rice said the ideas that she and Gates presented are "conceptual at this point" and would be handed to experts to consider further.MOSCOW, Russia (AP) -- President Bush's top two Cabinet officials, expecting a polite photo op, were ambushed by a Russian leader who fears Eastern Europe may be turned into a U.S. staging point for a new Cold War. ------=_NextPart_001_000F_01C814A6.F4B33110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Despite U.S. pledges of cooperation and new ideas on missile defense, Sec= retary of State Condoleezza Rice and Defense Secretary Robert Gates were = warned by President Vladimir Putin to back off on missile defense plans f= or the former Soviet sphere.

"We may decide someday to put missile defense systems on the moon, but be= fore we get to that we may lose a chance for agreement because of you imp= lementing your own plans," he told Rice and Gates in Russian, according t= o an Associated Press translation.

In combative comments that took the U.S. side aback during a photo sessio= n, Putin criticized Bush's pet project and threatened to pull out of a Co= ld War-era treaty that limits intermediate-range missiles.

Meanwhile, two U.S. soldiers were killed and five others were wounded in = a mortar attack launched "in the vicinity of Baghdad" on Wednesday, the U= S. military said Saturday. The deaths put the total number of U.S. milit= ary personnel killed in the Iraq war at 3,827.

The attack comes a day after a security official in Iraq's Salaheddin pro= vince said that a U.S. military operation Thursday night killed 20 civili= ans, most of them women and children. Full story

U.S. military planners quietly have stepped up a review of alternatives i= n case the Turkish government restricts U.S. access to Turkish airspace o= r cuts off access to the air base at Incirlik, Turkey, CNN has learned.

The Pentagon plans to install 10 missile interceptors in Poland, linked t= o a missile tracking radar in the Czech Republic. The Pentagon says the s= ystem will provide some protection in Europe and beyond for long-range mi= ssiles launched from Iran, but Russia believes the system is a step towar= d undermining the deterrent value of its nuclear arsenal.

Russian President Vladimir Putin says any treaty must be "universal in na= ture."

Rice said the ideas that she and Gates presented are "conceptual at this = point" and would be handed to experts to consider further.

MOSCOW, Russia (AP) -- President Bush's top two Cabinet officials, expect= ing a polite photo op, were ambushed by a Russian leader who fears Easter= n Europe may be turned into a U.S. staging point for a new Cold War.

------=_NextPart_001_000F_01C814A6.F4B33110-- ------=_NextPart_000_000E_01C814A6.F4B33110 Content-Type: image/jpeg; name="pic01.jpg" Content-Disposition: attachment; filename="pic01.jpg" Content-Transfer-Encoding: base64 Content-ID: <006901c814a6$f4b33110$991ae958@NLC593O> R0lGODlhjQGcAfcAAMnHx3eXPv+cAJVcAf///2CSqPT19DUxMF9Mw5QNDfjyVoycYu/Qyw9FZgWj 3E96m3VLBfzOBrKz1ZmM2FOq1Vw2BQSHt3trzfzpCuzt7vTu9Pz8+VG25//26VpXWJLP7QQCA+bm 8rOq4m6v0dns9ry8vWi14WlmZvu0BXDE69mtqeWTXPv9+kdERAaYxMnm8zMassd3dgRlkcuIiNTQ 7rnX6gYyZMvRrc+7wft0BeTl5TClz3p2dq7B1TGv4q/Hqui7t5C31IiFhZyZmgVooi+UyaOTJAVY mAV+xAVzv9zd3AWKzNbk1Uucx/fLuqilpfn1sRip2qezidTT08jb6MXA5gV4rAVVirfn9+vz9Pjt 1ZHG1/rq6+vk1vlZCTaMuNr297zKatyHAWZSVIF9fKk7Oi99rixomMvNzo6tjujb3+n1+uT05fn3 huv7+/vyLwRHf21rbKuLe5GXrCEaFI3B5S0pJ8yrfo2sv+6okjmjstfk7wiFkbzVyLfM4AdttPv9 /JCMjN7Z1kFHH/b1+gSW1ajb9cPRnxeYwjOSil1GQd7V0qnU6FFUaiPE7e2Gfe+qM7hfXrGxsfc7 DPPc3CpagMRtNmSANdHWvtvJyGNfYBpPfwspPdWpDbqApr2vR9SZmrOBXYx9M3VvcbuqpqKh0ajK 5Albr9XHOO2KOReZ08fT3tZaTEpqh/uGBc3N5m6gwu/l55S6QqqpuGa0nLm4reLf9FVWP0w2u7ma S+rZQsvkexhfk5bf+OrUduJ3LqG6rz06Ovz2+Y9XPxEREKZyk+tkVoWXmcJ3AF1mLYGHm1BNTiY5 HheGxEpYIb2swufh5pZHcyQkImpwihuArwVHkfySBbvf8fz7/Prhy+6SAPH34Ofv9fz41OT98tLZ 1BpxsuPq5ebo7tfV1/vu8PH+9dTb2dbhufn5+hdrmZWUkNjN00RHWdjX6eP39+LuzgyZoOKTHXN3 bPn5/b72+xZNmm9uSTNVXuyAFmmAjCFWsq3WJ4E1J+c5TMVQKdTyHCH5BAAAAAAALAAAAACNAZwB AAj/AAkIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKDUIA5SypcuX MGPKnMkRDTSD48jYazTEAM2fQIMKHUq04RA0BKAFamGnRQmWA1sMMAIBAg90DNEAwFq0q9evYMMe HKfJjqYhTT0MqsrjaVI7EeJGGGRrIIC7Wm8SeEKHjqSE4/AiFUu4sOHDF0u0aDQNBJ1A8wgIgdCJ qqancSh3skpIYCBiB0JLOwB5lONRCMcFGz3a6cKycRDLnk1bKNpppaat9iBJyAEQgzpFGDCI9xAe yHt7sGeEquPnTz4Tc4uT2HPogPseqM29u3eSPIIp/ytFvlSw68EUC99cXEjZWwM6yYdAjHeL0zok bUVYwrG0OL+BcIJdd0ElnQcEARAIdd816OCDCY0iXnm5SVNfI47dFVxcm00lXFxG2JFhUo4tZp0B APRl3Yon4JcicAag9ZwmgPB1nQfS+bcfhDz26J17FJbHzgGNrAbZHBDIpWQEm03jwYhD+Begated FiUIQhDwYgumVekeemVV2UIGPpZp5kZKCJHlRNGR2RBjFCpTJDtOjimQBx8qSdVT9wkYJmm/BZMT GUv5p9RpAPTJFHCS2OhUgAs+SYwQio14ZlAT4ALDBZfKhJaFEqGhFgiDZTXhHEP+N41uOzYywJKb 1f8FzXlebunTnSPGUSWjbSp4GgF9aqmdTWRY2mlSE8CEAAzMIoDScWoyCFMJalIaUgnSVHSAEhLd Jl54jNFp14ZKdoLgW/49d0CXNHr2qwGSXjeOZ33iF+he6opo7Hc0ZNpsQbbgUoVdMAxc0gW41DWQ wiQpwRS3nlL6RAai2unRCQOyud1Eo5zgVqKhhSCQenLlCcFT4wyLBq0qxiYsjOiCpl1S8dKapYVj SrLrvt1lmqwIzBa0bIIwMCwSDTAkO9AESpeEZURoUYTxQVdlcN9AJ2Tr0aRSV53REH9pQAZlctGX 5HBkAPJiuzx4GbNbs2YoaW/4SfcEGn0hKISUq63/e6t3Ijg7sqYEZSp4S5kynLhJeFNHbVJremYt sBkbBLcQ3JYwsUBcFxQ5kQs/LXmpAkF8t2duYq7l5v2VehzpdiW4d08cSXKLERwSdxR8TNrzMmpW Vzlxi6KTCOOBT25LAPGN/to2CGF3vPl3CIiwNMJL+xxqwRcRPhACh4MHwkC+eXzfmsjNft9opRKf ZQktigqqb8BZnNT0xQNrp1Pxo4Hcw/1ZkzQ0F7+sjU8yWrPaE+JHPuuca3nIIdVGFDMII8znFqqr UZLMhQ1HAUhKGdKZlcB2JUHhrUSOiQ6LdCUgUSFKEyl0UPW+tzgNXABoBqPBshiGMO4FrGiaooEO /5llvcHB4HA95BTQmMXEZTGxaSJRy8gy8J+JQY9zE0MK3iCmJTtJUIVZCo9nEki+gfCFQYsBFu2w hKDGSeaKkkEDGDMgRsrdaY1rcg1p7oiv2i3HHsh5BVRKdwv5ZOlKXmKehXZVLAFhZZEBEpOMGKWi Gf0NcDD4Hg4JwCnsaelfSUGALXQ4AREYrpSfpAEBdpiUoiFtYLhIFsKKWAXuDa6IToucEq4YpYGM hnwbE4jy+IK1jUkjj14ro7sKUkViDARLE2OKMBOYsawJU4A96c8zw7jGzGnNN6FqhzjHSc7OmFNk 6BQZOwYwAMw9b0WkeUVZ/mMH1rDmLBY6gTjn5P8keKbQFpLSRDsaA88qjDMyDqpCKYtmylUKjmmx FMgMl6aBpBVRYALJlPVqqUqJKq2WSstU4TLJODjuRWtTG5nolgPMO1XumCSC2HQsZ0z7Na6OBIDj Su2kuWvGVFhkwin08DZGn6oxIv0KkgSWytRXOLWcIajLNCAwiBLYQnPR0Y8QhYjVrnp1FmBlalgl MIfxlNWsuUHrWdVainN+54avdFbAmsbRVBYEpBklKQE0KlHB1bWVSgMfQXARvpHsjSAp5RrErpbT LB6VimvaJbfACVQteU4Ju4yc/jbbR869DzSQK50EKQvOlfHUmXVM4y5RZlKHtEOpBn3qQd06LuX/ NcSqIQgrOceZm9jK1rdNFatwy0Pb7sj1iBu15V5J6smRXlSvzXXocju6SQIkbWHXNUnIfJlNUoUn jM4kqppyepXZlRelHvAfOD1GNQnSbGNP4qMw04ucAXotavrzH8YWGN+jSvM2bcGSw7wLkdfC1rej jGpxdbBHXelTJQqOqjixRa0S4Va2yvBLFSQwpPEM98OwLW5tbiiQI+Z1sKI0HEWlK1G9xhJpdeFo DS/AKbsOrl+iFImM9vjT/jilfAMUVpAJgDMfBzVj53uj/RbGl2O6h8f4Wg7txtiTKGk2pUlOMl+k jKsBgsYmVnJkgQ+M4AhzJUHQgE0GuaHgRM3B/xaR+nGZ5anhxtBpFuvaMIiVSh4Rz6a5RevrYDUa RB12dFPfuy6NP2k9kWpPpCde2hNl4jjcTnFhg4Fd6bioactZOkGfvnRSOr3pUpcu1B/D9KhDRWbZ mnmQXHnFY8w5hEY4NQ6z0NUBcj0H0ESL168tkoaHtNQM71pO43ESbu6sVD8bpofKrTHSmFjiHC+R rsr9YXaXe8SOOrHGgiZYjkciRxKa+9zoTre6183udrv73fCG944aYuBWJxjCsO4Mfk+6GGPD8JjH LNEAiSSevk3nFcaehb8XmeH6hQY3QXJ2YRA2bqDM9SV725nGN87xjnv84yAPucjzlxV7Q/XMCP+t ER3QCZvHaPjlqMI1wLNmpLYx1c4SeExZzJMqY4+m2cdCHC6mhbGiG/3oSE+60pfO9KY7/elQf3rY XGvye/uZwriSsjRee/CZZ/g9jPFLhpuKoV7LadcE5wlomE0hiQf9IxN9+7HqHdw54/sguzkOHc7y Gaf+3OsA55LPD3729NAhGBg6j27YYZ7RsLWtch8JE7cd+UvRve5bfXW+50GW/yjFDoRyjW/klGse oIqsTaGWWdKD8J9X4buL5znqQQ/0yoNEU3G3/Zkuj3mrb/6c9x6H1RP8W+A6te7I3zOfIa/75jv/ Irzvve/vbmbiW3+3mS++nrev/OW3/fngD3//gbXvauyb//zozz75189+8qNc/PCPv/xZQP/6258c 98+//vfP//77///zRxFTgFkDqBWCsQiZUIAEqAYMqAMNGAsQSH2XJIETWIHYcIEWiIEZGID0hn9g AIAgGIIiOIJd4YALaIAo6IEbsIIs2IIu+IIVIUIbZyH1VIM2KBp9k4OLsYPL0IM++IN/pAlCGAdE WIRGSChImITqsIQbyIH7twpNcAZBYAqMAAApYAbpUANuwGYk2IVemBImeILYVwKCQYZm+FVniIaC 4CZNCIMxmC7aYU84OIc6iHg8eId4mId1mINyqCI2yCJtmBVlmIbshoSAtBxz8oN8SIeMuBtE/wg2 ZCgOXcBFv1eJt/UAm5CJVzCFH1AHKXAKRIAFWziKXKiCpAiANdADWvgCJPCBpfiFGCGGaTiL+vED tXCLtJiLuLiLvDiIXrUKs+WGwvgQL+KHN9iIe6iHyriMeDiEBteH5/FAAohVgZA+OkGEioiM2miH itCN3giEOxGOHpCIi4FrF+aKlkh1BXAGcFAN7XgER+CJHJACUWgG3JCADxiBpgiCFAAORPAHABmQ zTCQA0kBBjkCCMmJqbiK6JgRgvCLungDKBiRvkiRpMCLd3CRGZkHvShOgRgqcHiM28iNzAiEJbmD 8TQF1GKIyBEHC7JlH6kQjSInPRgI0HIcy/8QB3egDjvxjWPwk0AZlEj3AERZlEb5BU2AlElZBF9A DVjIjg0AJ8K3hulIb5r4jvB4BZtoAonAARRwBQXgBpkwA2SpAmYJCmiJljigF/43AknwlkgQl3Ip kG+ZlXQJiv8Ij+DQkBaBWVl1NzZBMZPIZqw4icBofLrIkWe5kRsJCY75mJAZD5I5mSuQkRc5gDFJ jOgBjSKZjCdpkqCpiJvDgIA5kTqgDp6ngWxyD2dQlHgwVtDSA2SVD7RZm0eZCEqZm7qJCLzpAg7g m8AZnBYwnMRpAVCpDAdYlQvRAHaJlbzQiUVAj+kwAveoBvqXj/93hXA5l9vZnf54l3UZkHz/WRF+ 2SiluYboSYWr4AS+sJiW+Z53gAryKR/0iQL1aZ/4mZ8CsJ/WwJ/9+Z+pUJkqgJnDGCqrtxydOZKf GZoM2oOjUC1JaHoQugypaREFwJz/2AwHuQNeqZQGqQcc6gM70JtRUKImKpwoWpwpuqIBmQ6VkA9T SYnKCTDMWQ1msI5xUAnMWQe9YALXEIVBIJZqCQREWqQDygD4OC/VaX+MgIXc+aR1WQS9YAh1sI5O +p1mwJRncIp96YvoiX+MgAcjIAXzmSf6iQKwgqZnuqb+2aYA6gpwGg8ZSaAFSoxmIYQUmqCeuaAN 2qAjeU+qORGwoJVa2ZtNIKLA+aEnuqgr/9qoKsqij0qc6fAF5zijOOGOVyCFZJAKolAPzxkEKfAB RVAJhTmki0mkZWmkRaoXhgClrhqXTUAPW+gHW3ANC/maWtiUsAgwXvqKXhkGabokwjqsasqmxvqm OYAPlZkXdepa2oGSekqSfDqO1FqtjWCtfsoUi/hwK2EReECoVoAIhwoLsMCUv6moIpqujOqokcqu 7eqbrXmYSmqpBJGVLxoHltCpYHmQcVmYSKqPr8iW+8gChtCUBPmq3BmqVMiJU4gFC4mFu0oQDjiL g+mB9AisxJqxGlusx+qmcZqsqXCLVNmsC4E3rbF20Tqt2LqyLJuNzFihMQiuGgqi6FqzIf86oji7 ru66s5H6j9QZGOJAr/Vqr43gDyfgqTn7jx94gKv6r0DrtPX3Ak3gnQhbtQZ7owAZsZhmgFJwB6jK kRvQDgaJsRtbthx7th37scmaA8u6CpmZHaD3bwqqsi1bt9m6iMlEEd+al82gDLx5qH8LuDebszrL s5D6rkswnNNJBZj1iq6VlT3JD40Aj0VQCIl7BA/QioGhqk2LA57btPQHC1U7ulTbonuptSvItU+Q kbnAuvhnAhxAtmY7u2ibtmrLtvhIsgphsgg6t3Rrt8DrsnWYt2xCqA/AAbnACjwAok0ZBTZLuNBr uIeLuFbwj35QsUILDfBoD/EgCvaQDJr/WLlxWQ1hCQ3YObCmyAShW7qJ277ua7UHS5Com7pn6LVe 6wsroAUG8Ku027+1a7triw95QKdveEx5uqe/O4QKvMAMHLzQaiTdGrNX4JJ1sAKuwAqB6wLPG73S y7PV+8Hxa5ywwLgjCxHwuKneGwBZebXVgAc3kQlmOYhI+rlc6pbve8M4TLrxO78Ugxdd21V5oL8X 679EDMABvLYrQKRsKID1M0++26cNHHUO/MBpE8HF+6I7uQuVUaJN4AIeOrgc3MHTC8JerKLWi70m PMGfYAQBoMKUe7ktrLn5OMOfq8RMqsOWm8c5rKWm+508PJGfYItV6A7l4A6wK7tFXMQe/3u7yTrA hUmewPFkTwyOdXuElhzFU9w3VeytWjkMrdsGYUCzleu80IuohSvGZky9kurC8/oQ2uuOKezGkwrH pgAGj8yluEx/orrHvMydTPnLSdmhWPrHPrwAUvADVEjI5QCqiJzItLvIjJwDXhCytzwRvHvAk1zJ l7zNUqyHmyzBrVkAshAASznKgquup4zKxUnG7LzORPAFe4DGVkm07PjGcXkGtgqMtxzPjmuxvazH AI3DOZulIdwMxIyLkAiwzIwBDO3MzwzN/3nEqeDIujsWa4fN0tqMlIzJHdPRHs3NeJrJkGHFoeKi mWoGAYCb5UzKpRyc6Yy4KQrC7SypGf96vTLaEFepl+kAikUQrqeQuVQgm7Q61PKqvkwqvgGd1P/c oV5Zroe6nQetOdESmCvoic3c0A4drBAdzQLsthVtOZGM0Qi80VL80WaNycLLFCNtEa160uV8zhv8 0jD9mzEt0+6suHkZpDddsuDKC+X6nSEKDiMc1EQt1LQKDF6ty6OsCkrd2I5dkEgN1fNbhsiZ0FUd u1id2cOq2Q+91dGcxEsMkgV3eGNN1lHXkqh91mgtvGtNnryglQUAqtEb13KtzjN910TAyv28nHrZ BLCAiTzNoYLNijbNzyTMBMZNsF1M14/d3Ik7rk39y3MZ1dTylyxoCpjN2Zut3Z3t2R//C9qFzMTr ohbZzNGpfY3nnd4gzaBQ5tqwjZBv7ZvoWttzXde4fd/VO9it6MrGuwnkWs/R+Yl18AKGvZDFTdih 69zM3dyk/NyRLZfUXY2UYjAbgN1Xzd0Y3t3eDd4FTAZiXZLmbY0ROuLqDXUo2doCCODkirNwLcph bNvAadcyftf6LbThG9ut8NrvLKJZSOCYV9hbaAI5vOBEXuQA/aHRPaKSrRETuYSm5zjZneFSruER Dc0cLt4flNEazbJmTeIQ6uUlbrfiEagl/d7wvdLMC8b0Xd85PON4nd+SuNuAoePs+N+Uq+SquAcH nudFfYUMbuSArgrlTNAPHuFICOW7/6DZb6DojJ7h/+vdcXrl1gwaJ6CtIM7lXf7lmr7pYV637Z3i hbriaj7fLw7jbn7DfGsBP0uBCnHjeADcfyC+ZnC9Ba7Px00CpuC+gb7rRt7Uvh7Chn4XUye1F97o U76xkB7pmACwoh0eraHlpm3JYM7p1K7aDIri1gzcDxAE/cji8o3mJGrqMU7Tt03jGlDC8xzOv/2U lfvTJFzrhu0GvfDnvF7vBW3Qk+3DhDLsYRvlxv7vjv7oVT7wuMvsSOVrlp6HmC7tSkjtNlnt1r6y Y07mBabtYvrFGbzmbC6cp97xq27jOp0PZwDYlhurt6qeBf4BiUDv9q7gB2vo08OCFP9wCABf81Tu 2ZJuoOMdGgm/5VEs4g7/8EIP8Uy3g+rwtmNh8Wee5moe7uJO7uX+5s8d5yA/qdsus8/tB6nIsKqY zAXr2On80rs+3fluhkDiuCZA8za/9sie7AX/1XeF8M+u8AsP9EHv5EPP6UYY0tl49BTvykoP3ebK 0hq/8VIf9am+BHot5wlhvERJ53iO8lr/7vI+omBvouic+WLf5khA3b0xbz6R9pm96KRf+qN/7Fqd 7CuQ2FjuAXPv8wxs95u+hENA+7af9+gd8aKJ9AdxoZka27vpxSAq34XP5h2P34tf9TcqugEZ+ZNP 3IWJBcud1Jiv+da/+QH9lp6/hKD/P6am//3gz/bE6varH9oHb4c8T/fWyvCzf/u1//7ur/d7j63p wfsAE/jATJDnXPxzDRBWBA4kWNBgsy1dBHEDRMDhQ4gRSWw6csZMgSBmiFSkoMqMqTpBRPYg2ePF nhGFVKpi6cBlFJg+ZM7kUJPmzZgvV+5c0tMnkmYshEokWhQiGgAllAIIJORJhg0GpKZI8wbD1TcK tG7N2tUqVrBXI4wlWxaFWQFp1Vpb68qtqxXtGBqlKxUNsQPLgtkJ1sKvXsAeBGsiHMcwD8RkFDtt 2njIY8iRJTsWsjjx4cKNBut9KrVu3QdXrnyE9aXJjtPNXKzOCZP169UWYsumXXv2/+yNuQ/WFrjS pJK5nx+KTgfuQQFeFdNxaPbFz4eQJf2cLNBS5/WbNrVvn9n6Os+fQYcKrzsFaS2llQF4jkr1q1eu 8N+HFWvWPtq2bPW/jQuVPNEp8EIsr78C02yzEzC7rDLKJnviQQgdZNCyURRE0K/O/isKudFgKQ21 1GBzDRERb7PtRBMt2E3F3nrSLbbf1mjoP+Iu4pCjIoqQrgYqeiQhJfCwy447Irv7LsifxtOwKEGS UuoJp2Jhj5w6qrIqPizjo6++++7Lbz8w+4tqyYcWEXAUvgo0EEEFLWvQwQjjVIcyCi28MEMyIeLQ jBH6zDHEElMEDyhBU3yRGt3+IP+CNytW8mE9NMCYkbwaW4FFt148jM6Q6fa4pg4kvRvSBFKLNHLE I8MTL08AnSyhMf/G7AMPBTDYqo0sa9VyPi57xe9LMN3KI9Ix87yLjhPWVDazCuVx80045Zxswssw uzAYPFnV4MYCQgQ00EKBahRFQ61oorhzLerooh2WeNG3hSTVsNJLlaujCVigM4XHa7BI4YsgRS0y BVO5S3XQVbU9aimmmpKr2BdohQ9XXXfl1Vdfz/o12P2GLdbYM9NUk80Em302FDlmSFlalqel1uSS 7xRmZoXrXdRPCtYNF8nmWGSxtHGD7pnPdLo9rol/+Vw3N51WiXdS4ejVbQSM9P3/LemAR92O4IEN RhXhnpRUOCpXoYySvYhv1eoXSOLRhWIsUemkLIzp1vhuYMH0+OMljyVM5GULg9nNUFZYIZJh5Gh5 cTqrZRYwbKdkFZYGRDPt8m/B1UO1dfsUVyDnTuuO6hS2SPcLG0e4yKKM3l0Cphih/ky5om3+g/RN n2v3SIG35rrU3039Gmyxxy4bsRJ0gFjirXyxxBdIUNnlh110MeITuT/JZe4tM/Yy77dc2Vtbvz0g cGSSB2ew8F/K4AflNICJH5gnZ2H8ZWsfbyHbyWvE+fKdueBeetiDHpB2tH9RgFMiGQFJFNjAGiDH Rqk7jZ9c54hHjQM4sqsL7Y5T/5yKEGwkEtDd67KmNeCVDg8rfFDwvHawJBWPfEsZgmKe5pkg+AJu qFgBrsLQC+opIAzY80Uurlex7nUJb+ATFrHIRwxi6EUa6EufydZXuMOVYRiicEYiaJEIeUDoGZIg 4/3qFLPNRI5m2qLcaI5mQADuzHQUEEefRmLHlIwgU3xyIAm61QPWaQRf5xqkRhRFGx+I8IY0Ug5G QHg7PIIkc0JCoQgf1DZWFAMPLnwhDGU4wydVRkpTyuEO2QaJO/ShD7i6Xiuvl73rJVGJKGBiEyXX Nzogy3xUrOLJDOcPfmzRGZegxSXyQb8y2s+MjssM5PiXpzaiKzWThI1sHrgFbP8iLQgdqUFG9Fia Pr1AD5nK2RkWVZzVjWZFBGsGADTIwQ428kaQHMkHfECoE1bSkm37hRf8EQg89ilnp4KhKj5prPM0 LBAbLJYpdEixbETPF7ugaEXbYERRZNQI1hMF9+q2RFrWUnyruKWGAhTFwPXSlzNAnD0u8dIAEPMH yaSptPCXP2diY439sxzV/gQwct0GCz3YQTcfWME6GPWbjEpUU3EjrkL04l/uJAE86eJBc8oTj6qi pD5Ld4dUYPKfAaBFWc3aSYQdFKGhVMciN8CIh+IKCm+D2y6wd9FXGhEVGUVF3XTRibmdBbAitSXf TArFZJ1vGSpd0IRS9thhxlT/pjW1aeNg1kzO6HRsQYADR1RHojiCazXQQUhHvkVNnzX1UOdUzet6 0YwzUFVG86KdZnKjKSBx9SVe/Z0EDJeK9hVjAQGQRXFl0S20DkqtZDpeW2NFtl3IFQpzbd4QwyAK 7aFCu0Pc6Cz/2gkjRGCwYohHeUPKsRzgQwVTMOxhp7jLlArOiouZwys80QJNDBemAZgpeurXspvi dLFq3KxoOvshEAFVtNZk6ooarNpFpbYlUoWtbK1aFIoox7Y385DO8snbKoUVuP9MA3GNC4vkKne5 JqWhDUfpGSVgQrpznWhFo6u9um60Vn0drCuNOICNjte8tVxve/+TiZDxUr7z/2VQfZWRFykMURbW 9e9/KxtgzGa2pBribI3M8NPWVjOAQgvziRwcYZ/5xAH+QkJsGUpbDVfitgPF54d9Vzo8b4EUv2XF WE0sC7KmGDwrZjFb2TslHci4DdOlcVzbsIvhWhd72DUCpTG6V1fyVchCRq96D/1ElAJusYylEEmm YQd75EJ6QpQCKSh7ZSynUcsF7inmFCxmRGZumgNljpkhDGGfcAAL7UqHheG8kUrIWVEfqrOda+JC q7HQbCX+My1SaJPh8YTQR2aYi/l2DkZ3Q9zhnu51n2BpjWa60uvWXqWjN97zMrHIRhaOEqDYF1GP mtQ2nEMjgoEy7bLa1VaG9f8Z0biZWWhWYYCsdYLLjGuBAgycEx9kztKcWtW6CM2yocdrN+LWetOu qUBTs7OfnedNidAETTgOHv583GsT9EjbJk9C0/Np9oCb3Du/bhElbURVt1K7Hp2lYOX9MFBLsS9K bpObSpEPf29PF1PPxcDH+GqXxXrUBF54ctz4ZTAH1ZodrjghVTdNXwP74px7AXMqwoA3M1Lkt9Xt d0AMnZVvU5DykwUtiotiTmZ7JzSvt6u8TY6c75znYXj0d7UiS7tt7Oj0rjdelJ7SyjiLvo1BzBya omqt+JzgBTd4lrlOvmR/PexiRwTZmQOijVPj4Rh3qqB6YQhVIBvu0Lgwhuf/npsc1X23MTm5ylFu TwaGJh+qlrRAYy74sBG+PIZfqGEVP25Gww1uF/Oe5CdP+fLcey9LR59kkjmnJkMIe9pTnBjPT3oB p1ESO2WVH87QWYugDrSzNxHaH0yuM3uqlWg7d3m7uAu537sZnumq4js+vBMoixgCqaO6bXq+gpK+ 6VuKBHGiKbm+7JMui4G87xGpeUs6pluGzGuMV1mQFYSWJ4CUV7mfaSODGdS3AZu/LTuy1AM7/Qs+ 1ku7AGwz1to4nkmBttONGBOH3iMK4vg9HzS5Bkw56NCmdAGrCJi6CIifwJO5wcNAoygbCEG6YvHA DwxBEfS+7zPB96IiMooD/wPQhPRwilFYqCkgg/MIw0VQgvl7kvOACqUYpTu8OcZoChucta6rhg7h Qf37wf87Mwe7jd3quM85A4VQwiWMiARclCeEwijUlxTIl9Koh+Uzr6nbpC28QC9kkrIxj5JSvEV7 xe0zw+5Dw/BJr/QqwfoTv3zbOjtsqxckI/Nwp6dICuBInkhRg0wQAhiMhUxgryFINA34wyc4gUBo Q4UixDQ6gOShP+baQZbrQf5jRNoDQiLkHQcwwhQQQgO0xGObu03kROPDpilMvkCYwL/Kl1P0pFRs FRqSBA4cQ1gsQ+17PO77KFqsxVt8AfALPzrwC8UqxBaIsad4kKSgw1EAjv+LDMYM8MdEA0YN6Egl EIKNzENhXCj3iwxZ08Yc1EH8A8dbE8fPicm1m8nhk40Rub0oUMcHgAaSukRMzMR3zCcHtBqitBpV u0Jd+ISAErSV2Ed+rJ9/hLGAFEhZPMODrMVUaMaFpIuTGjDys8E4CAakcMNqNA86NMZI+UUd4Mhn 7EiGESM0QL9q5Dxmkj9uJJM9aIWWVMRwBMBxlMkGUwnQMSRNTCQ208kmCQ65O4Im1EThGz6ZGEpG 8MSi/AD5aTUtVDnXg77oG5uF6UecS7wZA8FYLMjIG0ESVEyQacjxY7oh8IAaGsQ5MZtaSD/zkxC6 LL1rkaJt9Ey99LJFhMn/RpxJM7uHllMGZQgNXnABeiDAzymAxPRJiGjMRAnKEyoVqSqdBaLMoZLH B/wmy3QMXuNMp5QIm/PIVgy9gaxKg7xKjslK5dlKJtHFrwTLOEjBw9i8Y3AYyrrGrNPNg/PK3hyb 35Sn4PRLwHxERhHMCJQAZUJOqNuEWTAERwgPWIhO6RQK6qQd69wJ4hM2QzCBjkuqEa2nfplMFK1M yVg5LlSz8oyI8ySj9FQbGiVI0zxN98RKrZRPAIGiXNpFfZNNihzSfgTGt4zB/8y8y0oQiMSQuyST AkWnA0VQ4jwkBd2IucwHLd3SVngAf3sA1/iDnsADDG3H6nxMyPyATwGD/6E6CUY4CTaF037hBk/h FzcNz8caKM5MGM98K1dBCpCLivVkz/ZEzdTk0R79USAdDMdYHElgDKybzdwE0GRJSSddSfJQTuVo jikdzr88s8rh0qyyiFYwzlK1AbB7iSB4pwzVUMZ81UNB0w/tuBM1hOZ0AzXFgoiRlBfIVTltTqXa TFTsU7L500BFvEEtzRvFUZASKTFBVBj10UUdjDmsk/20VsdqnEml1N28VN+sHHXiSyr91CvdhA8a VXDdhHsAVxuAgzJb1QOMGlg9U1klvuaE14Rggh+B023s1V8liV7Nx4N50c9kmPi8pdJU1mVl1nhr WITMgWcFNWmYVog8uP/7fJZs1VYl5dYmHVCF0VQp7VRVSdAhBFWLYIe+KANgUgQbYAY4aFeXbVfT wCAkgFfVlNd5Bb5m+7BecAMR9Vld9ddfJQFgjdNczU49bVEXJdhiNdiDlZxzyBUsscqic9iHhdgd lViK3TfNw9iX+dq6ND3I8VYCTVdxbRFPVbuSQ4J2rQQbUAR/mAS5nYRI8DeYXdcGQNWaKAQrINN4 nZ2c1dm19dA0HTa8O9rKDFHvjDlsU9rOJNYmcdotmy6p9QqqNVRnjUrmktattc+SaSyvBVuOtVSH 9FhtAVlDAjtHXN2ZPIK2tYFh8IJJ8Ad8gIRhMK6YWgC8bYCl8dubBdz/wBXTev1Q4KEAaAuJoeSk xi0oPvXMyJXcGV3Yy21WworYXFTUh4yvz81PJgvd0e1Wh1RJhTvdtuWFs61S1l27131bL6jd6FEE itqHfQA0t5VZF7HZVuWGDRXc4U2kw/XOxEVc5U1a5mXapoVexPsYHbrcQqXe6tVcXMLe8D3BJete 7/3eJg1f02UV1D3ftM24i3Pddm3ZMqjdsdgHD2i8+b2EEUZVcYmdVg1ex+xf/+VOxO2mFN3O4mXK GCLWAwbU50I0JJLeWTQ6q+209LLe1ZzYzuXaaim9sM0y0t2LDYam8s0/1U1fg6g9B2iGFmZffCCL AFAG6tqFfWBhRGxX/xdQFBg2U9cZXMJV1QoE4BvezgXaYccdWQP+4WMtBympFbEgYoY14iO+WiXe XM6dYAqu4Kaz4CUN0CkevyomE2W44iyOPXL9tYv74mHAB6BDYcZrg334BxTGv8rxiTZezJzt0Dgm 3uSNxwFeXuZtXudF4Ft6AUBm4KotZCTGWmg1z0Suz0VmZPV54keW4gymYkzNVEu+5C0u2WcuRwcg ghG+gnsYA2y+v0bYBAAoN/o1sFMe00rMXxkWXhoenU68tljO4/DYY24w1hcTN0SrHl3eZV6+Wl/+ 5aMIZmEe5u0t5mNG5mReOmmY5CUpgGYmTEyOZrVljSv4YvMNguacg/8G6NL9dClTHo0u7ts+vioZ LoKdbWXIBLEG5GEV82FmtGWo3YVArmfMJayEXGaG5Asm7md//udGxmmB9ko1kWSZ/gyKxr+QfSSG 1uQ3fuh0dQBHuNVZ8JBWSDXtAaF6OAKNS2VK2V9zDumSG2neKmlZnmWgcGd4DuIE9tNcbmB7vmdb XGsvSKWyvl5Ftumb1mm6vpBIJr8DKOifrgs8qGYsHtWiNupyROqHPgMM6lk/ii5cuYpASI77OwMG BWJy/mitFmmuLhjhEZUC3uOx3rJE04W6KeIcxef2zYG2Ds3V/JsmrlhqJWaL3Wme7unx0+u9Noq+ FuovswiiDmzBtkn/wjZXmDBCQ8gHxRYLvdTtLD7G/NVfyq5sy+7qzAbrzxFrlUY0uApt0VbrXjbt 9h0fNVxt1m7txxlvux7ouKZtz+wyRPxrwF7oXwteF1HXqSYUR/gAWCDuXO4Exzan1vo4Vo3h5oaq cwYRFBqSPSUezq7uKWGEG8DutNZu7o7wCHdrfS4Ty7uFms5eJQtv8hbv8t462ca3vEbvzfJrUm1v aH5v+ObbDFtOlaBZWeCSUGAR/lYUxpRsAF9x535umTNwdgYbQqFuBffjcmBwB39wmJbw0vbuXAwG w8jw1pRrDq+iDzfv8+aL9ajtougBEz/x3VbxcsYnRGlxKW2FvhKL/05QBtlTaBt3Gt6bbB3fcR7v nR+XbiE3NrK2ixQA7UF+6SRX8tOucAtHlkDAixE/dCmf8ipf9Ni+cjugAwjuxoT2OjAPcyIsauwR r1zIB079skl0szfP8VOgzpcccFTpcc2Wbqi6cxxHND0PgyP38z8vbdklBTGEa02AckRPdEVndCsX 8UOHdC3f8rw1W+NA8Uq39E/nQaA4mi/rYh8kiEpodVWeV5BOUFNP9QMH8ulO8CHHoR/g8z534FlX cly8Xn7edV5PZl8H8RCf7WCP9L4pdjLX7WRX9oLwUkVE9QN91f8W9VVW0K02R7sjeFWPSVbvaMQL CXEfd0Iud0A/9/8llmB1X3d2v/ixdXSafnRhH3bz3IRJp/R7V3ZV0DvM8fH+Pid/V3jfi3OBn3OD P/iRpWXj+Xb/YAQTgHWHh3DSBnRWkHhEBnaO3/iKf3eM/3WNJ3p5N6n6rXdkH/kVV6EexKD65pp7 0jgbX/mqgvPAFdlsj3mZl8mEf9o8XwUO0Hkkh3hAl91AF3SpAAEQ0PWit/ijN/qkH/qOd96mN190 LWe//+jgtm/MsXqLS/ncWO9/d+NXvXZsH96AsewFFHOx93Y89+yaaPi0V3u29yegj2DOlfu5t3vR H32hx/uJXXqWDPm/X/13qXqaIPyczOrDR/zEv+rgLXU5f3ywj/z/mUd4yqf2krr8u5H17V57Wt/8 WiD7icde0w99uid9vK54vEd9GlF91md9oKB6pcYggvmaaMY/DaKC5TawrgeHJDj/lx943Q97kj3/ sc9zUtqBHxAv+h/+hy9+tjZ+tjeGzgcIAgIHEiyIbQoIYgrpMJRm5yHEAxInBqtoscXFjBoxcuzo cSNFhyIZTjFg0iDKlIBWVrLhctOZmDKP0Kxp8ybOnH9UOerp4CfQHap+IrHy5yiRpDhboRm3aiVU lQWv6CTyJQnWolq3Lunq9WuhsGLHki1rFixXo1lZsJXq1uAUACXmCuKW4e7JvCdNFUmDIsLfwIIH WyvsyvDhxDkU/y9unMML5MiQjdVqt+HyW5UIEzaM6DkkyNCiR2v83Lmk3swpW76sNBNmVaqxcfL0 EcUFWKJpleZk2jSqam6ycxbJujtt7rPKl6M9frRt8LdN6dbFm1pvEViQCHNHIeA7Y8fhH0suL5mU EszRC25eONI0fNLy58cnie3+epStWr+GPft/Us34ZEFyXyHFG042PCDXU8BlNhxtBxqHXHMFMlch hcdBl19KcVEXi3XXkXNZEUV84h2KKaoIHmLkiecijOZNhp56HJrEmXud1QdaafT1yCN8CqEhIoes +dcfgLMtEYVtGUqIYE5wLCiXgw9GeUpxT07opIUXGvilc89taP+jetN9SOSIJsHSjF/dsfjmeC/G KOMkk7BCY435tZfje33GJ5oHgWrykY9+NoQamVHtx59rR15ZDYSRcqlKllA+CoeC01X5VqQ2XbXl pBh6GapaWiYxZqKXCcLgb2jmFUQzBWy3Ipy1yjknrufpkKeeOPJp6EbLCDoKD8SSUSyyx8bhQaFB 6ohoqmss2kA9jVrbKbaQSvplTc0MZWmUmFIrJYObupWtVaCqC6ao7XK5rpjRlslqda6OuIq3d9Bq a4tx5krnnbvyGt2eObYwrCYJx4GswsQmLGyghAI5sbM6HmpvcNM6em246Iap1aXZZjqXuVJ5DI6p 8Lq78rvropr/qof0YhyLGX/IsS+//v5Lp514DqxawTqe4PB8ED/M7J8UV2yxHQLLqzHHIp+8W7cE hqytuDVjWkAPJJe82pU1q9wyy2SP/XKiSsgcIppz/PHArDjr7BjPdVPmNJlo+GqwHRB71PDQDC+8 7DI/Jk2R0QgPPjjeqT7AaNTgYptygAdKDds9DxQASw0FUMu1JAB8DbZOn1Judtmoa4l23mvPjAeW cec8986SGbPCCnVa8kTjHAbdUCODAh6x34Z/FqzigS8+fPJsJ/o45DGhO/nplmMdqW+w4OFHEAU8 UI9LoKc3ukHVll792Kqr/yTrrZ+JcRX62PxdirTTHhnuuOex/z/uuvP+c3B+9yumDTAjyVse4Y6m QOYhMGLje1r0pCc5OGwLfUihIAYzqKAtdE96Lwlf6OxCvqmEzYIp81aJUtiEHVCghes7Xfts5LqZ 1Qxu9Jvd/WznCyfkIX+sqJP/etervRXwIgc0lsOUt0AGJlGJEhPJwYY0s7fkI4K8mOD1kmS9y33w g5lThuhGWL6baE0fpkOfCleoRha2sIVfSOEL4RVDPc0QYwU4xRludsN+3ap2XkjFD4EoyJ4JcT16 89XBjthAJipxkYN6IhSDx4NjPKEyZooLfiBoxXR0bGpbzCIouwiTViijlEEoATQ0IEYSYuuMNVwj Bd4YyzbCsf+W3opj+syQJnlhpo72gl01FiA7PvZxToM8pj+SaQk5/K8cAJTO3hTJyCYuMCQ6qkjD KmlJtV0yZtxU2xQz4zlG1RCLj6qcOTXoRVKa0perJIH5rihPqojNDLSM5RsrdcJc8lNCr2zCCOZo SHeiaRVnqIYNiVlMYw5Smctk5hC0icpnZkYHLTCYIxNYuMJZ00+Bi2jouinSkVKnpM4jkzL4U84y grKT6OykuCAVE2XM4kOrsosfWiXCd8qmnvL83kv3icvTyXIERjWFIZJag6UaQqADfd/M9pNHhS6U oay4KkRrYVMdWIaimZlLHBZCvI5eM5FCmINESarWtbKKLnP/eetJbYQHlZZzE9Mr4QVvMq5xaQ6k q/gmU/8qWJ2+ky12xSMnJehKPiSisaXq59jUqL0g1AGpgWXENS6rVCo4NYDdjKuIUrqJAlCVbrmy BGrlwEytTqcdDHitE2L72nBKhbW1CMR7IEYGSoa0td6MC2CDu4jfsrW4YcxkonpwUApSo7lvnGcG XRrULH6Rpl3bw2Czq1nB7rSwywXl5miRhvGKlxaOhSzK/jnZD2y2vZl973Yv21nPQhVjQZBpKkpr 2sWkdrWsrReIsgFb2c7Wq9J5a2+Nq2DgMti3Dl5wuZCb3FGaQZZfgO5dW0rGvl4Xu1TQ7odBnN3u vhOpTYDa/2jTEIAA/EAK4j0vUds4Ava6F742ji+ONzvfihLUVYcNhX5/gQ98hKLIdyDFW5vi2i4M mMkCfjKBaauZ/0JYyVZ+8JUbrOUtY1mkoM2PBIxUYZZqmHrzZOcps/yCEOeYzSMmMX17UFkzgO8K 4S2veRnrXICut7I1bvONAy1oze74q0kuJJqAeoL83srIaeVukwksaSgX2MBuaWuVs5wJLnO605ru tJTdEoR7uGTMkZPuTK0LAHDi1M1rBrSr/7oGVRbWDR1mah1gobnGNja8HLTsoIMNa2HnuNAH7rGI gNmKXCwmHv2dwZGp7ORpU7rak660paec6U9z29Pe/vaXDf+J3e8y93KHbQUptyfiWLO73SCmda3d Texhz5vegDb2pX0b7uscVghFzkW0q/BpaxM80k3eN9Aw/e1uL7zhDYd3tL7ZwWvtda+plsCqPewU Esib4x4Hw6s7zuZZxzun9j55vVNObHxLhasMRrgzQYSGUqJVBVuldsENrvODZ1vbDHc40IMO6lB3 aOOA8PDmHoDupW8uhKl8ush3GvKpU13jroZ4iU2u9VtjVuUo/3p8Wd7ybwZYRC5HsLSXXPacs33n sIX5sX8udLKzmu52DzrRi64EjZO873z/uNUDP3LAg5zwhTf838XR98KuG+xer/rj5Sv2sbu88oBF +5WhoIX/zXO+85pvO+h53nO9z33vpj896lOv+tWz3u55Jz3iYy/72R8ezrQ3POO37vjIY4H37Z58 Rde+Ki6z7fPG93zok5+NXY6ePaVvPfQtH/3pQyvit78+9hevfb/bXvG1HkjjIe/73pO//OI/v/iB z8vuI7/9y1c+25uPkudTX/r2v3/9TS/htLG///7/PwAGYMKFH/oVoAEeoAGqn/wtYDe4nwN2HjnE HwMSBPHlH/5dIAZm4P3t3/phnQBy3wduHwiG4PxFHQKeIAomoAJOIAlCoAu+IOgxH/9pIA2yTQ0K zA1uYAeKIA96oA/+YA8GIRB6lgkmXvYdIRKSwAqy4OvB/6ATPqEMtk4O4qANViEVWiEW1uAODuH3 caEXdiHlCV72VQEuwIAEJCEaKqERbuHrlGEVGMAEwAAMIEADRmETQqEd5s0VTiHbkKEZZiEgBuKu qMEdjo4ZTsAEfCEYQgUMtGC8SZ0a2sUFICIusF8NVGLt4V4kbqIbcCIC/GEnhqIoOiIbigAdXgYi 1iET4iErzqAGTqIpZiEmCiIt1iLMXIAclgJUIAANdGEpfGIuLqIwzh8uniIN8KJdpGL/TcAFjKIz PuMzBiMCJCIJ4KIc4oIuimIczqESWuMcigAB+OEpwgwwIuNlYKOqzKKBCcInmqM1vqEBvOOIXCM3 5uEqDv9iBlRBMd7FK8yiMmLhBTSjLV4HMMKjPGbANlJjKQRj3mBjLK6ELYwjcDykuSDANB7dQtrC MG4kCxzjL8KjRYaiOUJjJ14k8E3jBIBjP17AK3QiLkZiHL5CO/AiDLCkQLwkHYoAKJKJKb7hMWIi GfbiBkxiz7GkIMBAIk4AHSrlUPIiU1YBNQqkKtoj/5HhR95FGeLFSBKJSQ6kdaRkBoTkBThlJeok VDaiAbwhMyYKWO7kNHLjTyalVCYkVKxlHJYCDTRiHDYjUS4kUn7iWdKkQH5iM/olOLZjYbHkQzLj KYqAUuolUt4lWxRkRyImMLIkWqIlYm7IWFIjMiIlC+j/5E6Z5Fj2ImiKpkDYAlomympugFm65mqi JVMOpRzC5k6qIjr+4TM0om62pk2uIuUpJiYGZGM+JhxGJmhCA2XOJDdeZlAaQCP2Y3LqRUBCQ2+G JTW6pSKmRFv6JC9CJV9SIj0CwlpqJyBYpU16JCD8ITaWZiNaZHuGZ3maYkrSZAgKZ2gy42BWQSzC p1WywDTm5WTiZWQGZRxKoi18ZGuyBWo6Jluwp1SGZnE+qMDhwlxSI09KpGpuIz3SY3hixntiaC8t pWwiZYliBlhS5T3exQU4Zk7qJ1byZyX6JzoGqGYSKDMaqGa2wyTOZl7MZDsc6HH2Y0u2g24Cpryw p0au/6dKjiNakuF5+uZKlOZYrkR0yqZA/uJKXOQ00icmruWWCmWtKWVEskB1niJRcoOS2mVOnmKN JmJ1csN+ogqSlkIi6iRDQoeW2mloXiOGOmiqVGkv3Sgq7ieUFqqglgmaLqqgziagAmcYIiQv0uGZ hkA8ZucbHmJhtqlJvGk8DmZaauhJIGOjvqVJoGanRiiZmKE5CuhKrGUswiiYvmozXqdo+ihRpumV ymlNigA4AkKaHqMjKiWpliaF9qmEsgCEmqmbmqYuWqiZCqWwciZ9TiYNzCqqVCq2EsA/sqU66uqS guus5qKIuuZcDiaMbgA6limkRgexWgZxdpWt0uGyCv8qexIoX7YkHKoqj3ZVnDokWiaqAXQla6oj Ux6iXnamhZJhnNYlHf4kebZoTX6inNKrLkIpsdqogI7lJKomPBbWQv4qknYkljIruUZmlf5rQHLs G3bsbTootqKjnq5mosqsQKRouYJZPQoqRWIpfA6lTtqpRELlZWyqpB4tmTZlu0aqBoRsp4IikQrD WgbkyepnJaoscX6mr7Ymj5pEUpYl2MpkwmJDSMrLVu4lMOqisX7iu0YFMMrhYP4lNrajaaIkXyKn m3KjX6pqdDzqb5LspCaiRSYkXMJtW1RnTzKo4bbFbG5jn17jkpLs197peHJr5aYKh15oOhYtcoJm GYr/qGr66TnWY1iSLsEurahh6N8yrD4KLjbmYuHW5Khuqr5aYzY+7eLSrUnYblouLhv+LvAG7+8y 7Hps4+kKL0qA4rYiL/M2r/M+L/RGr/ROr7y4KgFsJfVmr/ZuL/d2r/d2b4pO6/eOL/mWr/meL/pa bm7Kbvq2r/u+L/zGr/zOL/3Wr/3eL/7mr/7uL//2r//+LwAHsAAPMAEXhAqUQQEbMAIncLQcMAOr hAM/cAdGggQLBAVXMJlcMAYThAZvMDmUQQIkAAGoQAgnQCQwQAgvcGqmsEAAQQnHLwiLcAsjMAqb MAWy8Ai/cAHHcA6H8Anj8AzbcA/LcP3yMAFQQiSY/3ANq3APz0AL6zDyzoAJS3EZIHEC1LAMu3AC OHESi3AZdDABzEAMODEBXDAFl4ETJ4AKDAQak4MahzEDBC8VU7EVY/ETb3EZh3AZg7EYk/ER23Ab v7FABPIax0Ack+8cKzEI23ET57EX8/EYW/CInHEar/EgVzIcP28ilwEQfDEo6LAWc7Eef3FB9PET VzEBEPJAqLELT/IhNy8DxMAWf/IYm7DNiTAKp4kYk3BKJPErlzElpDIoEAAeXzIxD/MnD/PwyjIo 0DIV3/If63Ik8DJK+HILR0IkYHIxHzM3JzP5xvIshzMn83IuC8QuE3FBWPNAnDA3bzMe47E3wzIz 0/9yEk8zORPxOffyFQ+yCr+zMlPCFZdzPDdvG88AAsvyJMeAMK+yFANBh2wztJlzCTu0RIcwRZfz 7xb0QctwNi+0QGyxIMNFMSPwPsuyRa/zRD9x+Wp0GHO0QrfxRzf0QytzGFuySYf0TV80OiMvS5Py Hnu0G8v0/OGxFuNxTrMxFGM08+5zG8P0G+9zS3OyHxsECN8LGFd1QWD1ETPxFjK1Ezv1GkP1M091 VntxCauwViM1+HF193q1Rz/1IY+1SmB1LJc1VRMxA7B18Lo1VMO1REv1XIvwJ7e0Wt+wBue18/Ly YLtxHOeyC9tcNl9xSBuwQQ/yK+c1VAfxIVMCTLP/oWLL8D47NitHNkBTtEGoQGXHcWVvdWaz9mZ3 tvd+9oiEdkCPthSXdkqg9gKjsmZT4CKnJmwLr2xTs2hD9m1PNkHodg6TQ2r/9kB8sgpzNk1HcQoH M3HbcgoDAXTHsU+vcgLwNhGDMDtLcSorcUtvMxuaNCpfNydn93anMhhX9zp/tXmTt3gHs0mTdfeq t3Vn8XeT8H+/d3d/9HcfcnjXt1mPdwjrtxzLdwxcsAu3d4AXOHwXhHyX9xXfN2EveEUzOPAGd7SA MfmCeKqI+P6SeKKYOPqieAbLb2sn8It7cGbEeAXT+AN/cjDfuI3LeG7veALjuIwX9XQPsJDz+FeV //CQP3CRGzmTN7mTPzmUR7mUTzmVV7mVXzmWZ7mWbzmXd7mXfzmYh7mYjzmZl7mZnzmap7marzmb t7mbvzmcx7mczzmd17md33n8miJopq+e5+xA9LmRA/pXse3//qREfrOfcy+HJjr08u1ALDp3ii6f /+oWQvpbWDr/+iHpSu+1XuOhR+THfi+qXi+jA+9j+m5BjDpKvOb5dvo1hvr6qfql3Wb22oI3lrpq QKv2KiXlquP1Lqj3EiytIy8C/OpepsTxFkTZmm/PArtKHLpbJPuzQ/v06mSWDnvfOjv0UqSeE8Sx fzO2O+9D6uOes0e4p2a5ly8ugCTFZoauV9S5J/8vrjevZA4E9q6HwE5vsT/6S95svdvIsnegrG/7 jWL7wBMEq5svOlIitcNFvKe6tnfIwzNvXqqqozu8n7Nv9nblJNJswofjZYKf7t7lsRsvrd2lKbbp LBo6vHmjve+knqf777ZoTCr7NXq778YkYYr8ptc6vUolxFquRnbon+vuy286XYK8HPbige6jvke8 BljjXLLqH8rjf+66xwds1LdmKj4nyFtu67KqKoWktUf9XvrpzYN8gqIlu5pkGa5m10885t4tvLW9 VJI9++58uwvrx1PvZypktV7vOAb8bJquRnK84KKrBnCpRdJA38OyxhvEwlf9S87paUI9p6dkdCb/ /p9H5SxyrWMqr5N+ZzHqeeAKBOOj/pLqJnH6+036OhuiaWuao+gPRD3uLKHme7VTLjUO/a/u+YaC H83uqEDUfl7+vojW48Ejb82jhEkybOIbe2EGLOzveoU+ZLnH5rVL/r4TQPbn7dA/7B/eZdmCacLv ufYLrzeSrvmD4veHIyhSLPk3PPSG7qv/+ZMqr1sO/tgCBAERMKoQIIDrwgSCBgUubCjiIUOJEylW tHjRIAIYGipWcUgDxgSDMC7QIABywgUEtjJewPgSZsyKCE6ShDiwoECaEQ+6nEjSoEeRNUXaChlR YUaSJjNCPLhRpMeCE3bilHl1YhWfPRnicqpR/8MEoQaNiqTa1aXGlVjZsl3bkCkBlUoZzkV71ytd sTCOTrywsSFfBE7bFqbI16JCplbHNhzMsKxhyS8Tjtz5ty4unQRXAj15s+/AoWfhygWMsMpAmrYS jlUrtmFYsAM5s5x8cefIoa5JihVtkLRdxQdXV759W8RQ0xxbsgYqEoHLlBo8g6TBO3ryhVQjHzTr Nfdxw7gAUxwu1+d5zHJpDrRFQ7l4yXYPMkXYVfDfpYhFXP4IYzWH1ruvLJf4Euy6AzXqC4HsFoxO MPnMI6wx2gDkKyoAa2Jqrt+eQlDCwmwJDyyyFAyppA/X4oulxyxc8LsDDcwQovvoC/GqEs17Lv+3 BjM7EKK/uMPRLSDrMvFAx0wbDUDlcAlPIQBtI46omvzri7r9nMxLIZqEJBK4rQI7irySsIzyrZoA JEy/+MCMKU0VrazxLY2Uo+0xpcwcyigpgxIMou6wfBMjheJLTinPqgQOQ+a+JFSmv+KElNJKJerP 0kxhylPTwpLq1K/QwgOV1FJNlcmjQU+tVK24Vo2puvI0RdPNV229FddcdSX1N6OY2xXYYIUdllhh +2u02GSVXZbZZp19FtpopZ2W2mqtvRbbbLXdlttuvf0W3HDFHZdcLgg5l4V01V2X3XbdfRfeeOUt F5B67b0XX3oN2DeLfudF9Yl/BR6Y4ILbQgP/gFrUicODhluZBuIH8imAYjwsDsKUjP3YuAYqrvEY ZBJEdgNdg03WN9+URexCB4SncFmQmHWIZeYMbOYX55x19nfnnn3m+efCFG5BGhCYofnkpJVe+lI7 iAEBaqhtmJrqquGwuoGrtd6kkq69PgNsicWuuOKLL+Y45DXUXpvkttlGWeXbYi7hBgBoVgLmhOne W++X8a757psFHzzowg2P6WUhFKHjacaJOeDwyJmeXCZJGo+aE6+vOILzzTv/HPStRdca69JN5/rr sB/4YvUH5ngb7rhXdltewP2+PW+Zcf87HKQJlxz4iYKJ+nLGg/k9+OQpn8xy4o3mJXQipJ+e//rq ow89a9K133706zlvBYzlZR+ffKDLPx99XG3XPffd10ce/qsOcN5xo7dR951DztE/fybOeed+ARSg +AgIkxLUT2rUsIL1FthABloPDp6L4AQpyL0KXhB01gPf0vD2BA8gcBm/gt/GfoA2WpQtDSXcg/mY EL59OeEOK7BEKGj4BLulD4fDel/7eMi7ghWteI973ODqpj8j8q+I/fOfEgFYQCcGJYg2UKADLVBF K1IRgtjD4Ba5KMEMdm6Dkxke/ewXtFWosGM12EIT2DgCWqSwBO+rFwxlOENRrOAOTsgGcwDHR+XB BIZ6fCLlapY3vqHhh2R82vHw10RH/m9/SP/8wRHDcIgwtPCP5MhkW5pHvAYg4oqhFKUDZVBKL56y i6lEpSmnF0bJIJB4jIwf2j4WhCYkwo16eGMaMMkyftHxF8HEoy83OZk8sCIGThjkMl94Q/kF0XGy BN4jk1hMa1aucUD8pAu42U1vfpOUrFylKsk5Tji40jBApF8LCoeHWm4BnrjUAyjdSIs+dkEFdZwh KDLhx/g9AaBqiJ9k8vAIZTKTmXHEyvyyeTlpMtGRA2XDNSmKTaONsQGOcIAqNspRcI5SnOYs50gl +ADaFUadUKuA8cbXgx68QI0YIxsodfkDQIxjbzScoSXysEeJ3lOhfcxhRWLIAIQmNJHQHCL//o4Y yaZCEqoR/QYmj8q8RTqNGBmNwg58wNWtfjSUISXpWMd5BqallA78YOksPQbPeOYSHtwcgQ6AkcI0 jIEfZdinT1nYVwPArKLqKuhBq+pEhT6zodkkYlQx4dQiPtWI+ZvkDXbR1AEGVmiJbUAKutpZr4I1 nCIlq2hLetK2oHWlZXQhERlBBYzFU5cUmCc8dJmGAqRBHsGoAATuCAQVjOOe/iRcQIU6VKImUwuF NSzw0OrQaVJzqpCcbCWpW8nLYpYtT1gnZ2Xb3a+CNoujFe/3zqrIh7LWrR84YS5ny4dEUOwedqjA MtQhhcn+1lw/faFEjWlQ5S53oYpUbWCh/4tdqzrvHtz1rkdBGlrSPpikJl0aatcq3H65NAW2bCNc S/le3drhBHaVgv9UgF/DzeyMQTXuRQb73wI6UybNVayLDZzd7XKAjZ8FZYPDC2Efc1HCYnReas87 OGC4FRYbHgE8OnyGYEgjGPJIQ33t29gqE1OiODgsf9nSYhoTEsYxYSg0i1xjM3PyxgvmKo97/GM3 l3bCQ67w79CAZCV/oQHu5QMn6BDlEx7jB1JIIcsEjQm/ErFh6ljxS4DwiJ5yML80DjNMsEpmAp95 eUNIs5rB22bvffHNnkMnSs0btz08w85t/EIpFzi/e7y3tpO8raHtu4BeDvQEJaDvolmsR/8gnMy3 QPC1sInthGIbVWaRVvayTzzpl1QamgbmHVW/bBHtIljBOmazp0MdYdOyhcIDJtxrU1C2JrB6z0bT c215CUc2YGIB9o0f4IRwAh7woLjHITazBbZvvrLv2MYW+MADTnAG/NuHWUBkgIXoAUlIQhPitiaK fUtcTNsY293NcRF2vG2xghrk4w3yK+UscX5dI8MapoAb05FnKzTgcetmNxhKcGVB23reHBmCw7nc loLyE9hGTRrCfWrwYRM8XQtH7OMAMASnLxXSRKw5GW4hiWpf5NqezDanPR7yj3ebgiNPZ6n7ukb2 rvzl0rNBzGVeW/8F2qbwjrcI6X5T+p7/gNq8XtfPkybspCOzXYJcFwxNfFBK+L122TB20pNKjBO0 AGqjgPp1T6yzqU59GB4gw6+vThFNZ3zl2u70A0PKbfGKndSxnDPQmvDNrrIa5iCQAZNl/sY+/NXm c4dfzTw4BOxm4+d8LRjiH9EP5Pq6+I9gweKzYQxWPDoP/dBj8h+deMYzHASaWIbRNA25qC8RYU+o 9zLsMQxRINumF39J1qNWia2Lvuul//p44Sxk4hFZZdf4wjdByTkrPM3l9My9Ym2iJuvtbg1+Hg/f eg4rgi/olu+YDAoUJND5HA2ZCsoYOI8LnK+nYsAC82BeFG+/sK8FpgDEhGDyNOm5BCf8/3KrBZwh GWKQn8hAHm5PBfMNoT5P60IP/uJP/sAulVDvtMjOfLYgCcDJ/9YuAAUwtgaN5gLtACfq0KjO6epO 7/4KFEDwAaPP+YzB0XzLCzEQCCowv5wAmRzNv7wwBIuu8bIPylYveaZNYVxwEGIwBochFLTvBPjp 4HDwzNgPAN+vBx3sB7WI/vxPeoQQ3BBs+7yPcCjAClxgyfigijyH7WaPEmmLtnbJ0J7Q0FQMedCA B5zO9xgQK/rwAZOvC1nBCx/BFV0xAr3w8IrPGCYBFs1QC+MFFZUuxi4nEGLhBKCmzCSnD/xmDp+M GWBQGfMq8/JKDvrpZqbgBqcRuzTt1f8K4B5kTxA7bvQK0RAPcYEUEfuM5hl44MnwpWYKwAw+YAeO MAkiyAWKBt0ycQBh7Y3CBxNGDMuk0HzqZQjuzQptRdgOD9kq7gsnUAwPjxVv0RW7sPp0UeicDSPU aQwWJhDgkBqDBhjyoRbQ4B9vgRkO4MMGoQ6TgRmHgRnziB9N8TbUwWhsoGuybxu70fQO0XM06NvG 0WiCscw2ZgT+ACgREQRgMh1uKa4ycbb+rIUaax/n7d5A8QqTbhGm8gGbrQwFb/kUbyD/RQQVrvEW xw1TEHg2kiM/EhlFkiSXkRn5wRkgIBSYciUvrvu8RiY1bhAJEQhVifTEcekijwf67Kb/+nEPEiEo NycJnmZ6PoAekXKedGkpgSsuBZMjzFEIpK0jWVKwhE+5ulIiL2LMSrAEUNDkDucHAsA0F+Ys0TIk b+EO8yotB4EfSCG4KC8jJ8MlXy2+6CDBvGq2aLImgXAvS2bsYgkFHbEf8YAaUMcC4CCrGsiWFjOu YksPgGsV8m737E78/HAyEs5gEE/Srm/ppMHegGgYNXIBTDMZFoAOX1A11RICngwG88pulkj9WEAH YRIE7sGzuNE3vQ7sHsiKCiAn+5IOzHE0XUgxj+AdL/EICuAaoLMep3OFZjMyb2bnAiYqsyJhMHME aYwzG+8E//JAf6YP4g09qS6+XnM1/xWBNV1Tt5bxGTnUNnfyARohP7+L/3zQP0MNQK2AL3uReD6P nSRTBwoAHplTQRfoChJhMKEzKYl0lkaxMmUUI/CmM+fFO//rQ0kwYYQ0eEo0AKYsPZPhDVf0RV8Q JdkyGWHwEkySylRSLo0Gvm40R/vzN3mUgX5UzGLp8UYUDbhmORl0gdToKKFzC6AUfp4AyjA0ICXj dqrSQ8ETSH1xkUyxD+oqTKXAHhrGDkLSTF8zr9RqTW8BPc1PFPCwKasRc1wtCkTJTu90R2NVTymN TyGvPIEBDpS0OUkJDwChUBuItlYLUQmHBqeUSi1ibv4oSzczItswGDhVLEkUU08TJP9VU75Isj1D FS0TYLdM01QHAFVz0C8BsFXr9FVj9SY/bZWoR0DjjHjubUSN9Aj5LKysoAnYABg0kfb4oAYs7DpR LMQ8IFX1zYZ8Z/iEbkCfaBe/UhpFszx1ZsqmNRlyE1vL1Fpd9Fnj0x7U81vPD9NQ8B7woBWcZhPK 1VzP1RvT1ceqZ1afjU/J4EAZoRKCclcjcXq+oGUQob34wJ40QDv/KdeO9SIE4TIhVUublQTHgPww cme+oa5SiFo9NZqktlNDEmNL0iRFQWvbdAA8lpluM/Z002QZ7GTrlfRSdmVZVjhTL2r6dEh3Rl4D tRKtp18nkckoYEKF9V8DExDkwd7/hPZNljUWuvTeMm8M8FAOZLMfDWZLl65hRpFpdSbQInYBxpRq oaxiVfNqneE8IaBr2/QSujb9vKHGLjJkR5ZOybajUPZs1fXBbnZthzBqMvZAAfX/pCiLguCvdqwJ +pXf9nYcKJNR67PfEHZoQhV5k5cfRmF4E/ZdFpYENy8YR/TkJtdE7fBys9dq1TQZT7AttzZ0B2DE vnZcswpHz7ds8bJ18RR23TVqhmB4ygwWDPMKiOFs50oH2hEefPdnd08I/rcUARdHfG0I0jR50XK3 Drgihw5pZUIHoO0sqffdJus8421j7TAGM5dqYZMfUrMk5UsetBZcodHMTFcdoaYS/9B3ddNXfWG1 i6rHAu7VfXcyftHxr262ATiBEguTehCBI5asZykUeP82Q4nkmA4YlhIrgbl18xLPfdiQS21GUY2z aZ22bip4AQbhPDE4AOxhEDC3arfXU1U0JPEwAAYgFGozsEwYG1NXhVl4fb9RL4HV9WJ3ETFHRN9W cObXHTPHbOFxhbbgDBih8hKVU59hYE9FCeQAeWUssbIJeRcQXqaShyQVJh44m5CxUifZSm+ugrVY 0NqUTZ3BYqu2g9tTRXmrcnPhqEyXE2wA8kq2bFnXhSeoh/lvq/B2hqXhf6EsX2ogHdyRCOggCZSU h3PVBV5gd5XAZ4d1cfcFgBWNeP9rhxQUQVuTWKmCKFRHwQ93J44ad1IPIJqjFWeM0ZN5Scoq91TX NIzDeLfGmJRfk03vKJEzLT8nZnhkeYX3mZbdzGa5ybNwLKDLizjFMgiA9R5wN4uKkgr+qleduZnh 5yH7t1JwwIDB8pGzWZvLYHmlcWAEjxcv+TPV5YDsgJkr9O1q7uY8OgNu7oO/2IPduc+uVRlB1wiM 4AbElRNO2I35uZ/l2JZv1qsEmqiLGn/tr21rGF/4uPUOIFeNuTBzVZdfABggOucGS6DqmS3MgasJ ZgoYOYFn2pHrB9rIei2buA+N7uigMaRpVRgv8gC0SxoMtpxTeqXbRR3guZ33eoP/WRODbxphB+k2 1VEeNcqnfbqF01ZnuQrHUs4EHPuxi5qg3xcOV23NdLjNptoPrDqif8cBBVgqEYbLgCAS+GGl5mum TzuBV3ulwNhaRdK0ORpxC06t6dpxu0+uSbQYVTqi+IUnM5ivS7mUE7hrWflj5fQB+CyFD/unuSgS F5sDIrsOphuyI5sHowAW7Hgco4wn8cUIm4GNzOCTeDiqG3RCq7Oz9za9ZwarCaxvThpewJotlXbM NPpx2jOlWvskhaCta8d5hWfG7NNPd1sidW2mgfu1MTeeNxi2b5o2xccld7oSyJW5+/OFhXrlUu4D Npy6O9y6i3oHjprk3lWpbYYK/1qvjbqGm4ISqg1TvV/cZw1KcHnNSg+JpdXFDE17vg43gjX6We+N /MRvjNLqyXZrDO6NI726DWsQfkczuvymZ/ogt/pslGOaprXXaulZXNlBYtjBfCv8j4E6Sasolx+7 wzkczZHsw69bxIcz8gCgxHMWvFludYqZfkMqb2F89xrN0bRaaMIv/JS2YJevtPlBafVQJLE5m45c EyDmyZxOE6DMNZ/GGYu1Fn438BJpGTZ9FORBcZwcxRCwnFETLbG3U1kby00ZsLc8q2LZsFW3G7lH egBayaZbY1oL19O8uqObBzkAuyc7+xpmwEZAyTZBHZvBBQwztNBbzw9NA9obtP9DW7QV9XHoSxIu +tAxOqOrvdOfzEAh/Vkn3Q7wEMntzepCsL8nMthPgKSjtRhRmojgt2qX8dTfU4PVqd5JNReaV1Wv 0dXBfG7X9bm7yszT3BDSKNdv3cN3ndcJXrsJtN7y016UIMnqCRvtlghmthl22JSgstkJZ+DW+zhY hpLzWoiM5wAYPdvLOrHwih8C4RZCNr6UgRQeL6wfZwbkoFj/Nw743V2utCKK5vFSXvy6j3DenaLJ 4atLXSSHvkUTXbhPPRnvKBmsc425D3WXG+DDaeB53eARnpbAXtcZ/rpj+OEnVRg3OQNqoOItpkaf Uw/CZl93mEnh/Zn3fCujPfD/II6sw7jRR4FFFb1xqC4Y6OZ/l4GXd077aHgB/3HnNcHn2eXGRdrx irP3JA7pubJl1hPKEPyLxXq4RXJrF4B8Mcd+3xisOC7Dvz7sxd71FX7h13wH5ArY31DiTbztf/IB 1Au88SwRft9QC9nZGaACJ7qIRx3xyVP5A1/wn8YcW6Aj50D8IF8dWHSMNO+k663TeT7E5m3yaZVF 2d3ExW23hRh5POilN3XBg9udtdiLq36ZLvLkxbbCGbvgD/5jXj/h9X//AcKUwDpbUowwgZCCwh1R HLiAxSIigYkUK1q8KA2ERo0ZQRwABLIHrCAkg2wq0CMFtSYF7iXS8xIen5i0/wywycDFZhacPHv6 /Kkhm5OhaoKCPHoxqVKJOpk+GQPVTkepdKRRJYY1q1ZicYItqyXoyRxlo8SeaHE1WBcWi4RoGgWX jNuySpjanWJ3KcUDXDUFq6XpqUeffX70uUnOm87CiBfjZTJkELNgdgYlcwZBkWa0LTqnpZoMsGZ1 eZvqPU1RHTGXrTJWaogI9g4OChF+uF0j9zXdfgYy+s0bePDhvYvjvm0w4UKGFigQKo26YkeOlAfr uD6yZCU8Kb+wdAmTJi09Nff02GMa6M716rPleZTNKNLo9O0+AUvG62erV6tuPTsGWAAM4ZY6BI6C lkbLLGJAJnPFJYQ6cg1RV/9peNWXAV8IVrfRRxEB8E1hhzUl4g+SjPhhCVMwocQCklkmmT0nvFUW GR7cclZVB0xmzwKkbGgPJtANiaEyHh3QSAsgvCZbbQQJRJxvBR0nXJRWVklQcsr5wNwIRNI3HUd0 WAeIH9mNtB1yBdDSCi9rvkTeeOWV1x576oEExCN6rnUnhtFViIaB6iTIn479aTUMP5EIeN8Qkhy4 THWBrOXgjBBGOKEgFn6JEVeBaKIDGVl5uJhhTDFhKovA/MATMPeBCJk8Lk6G3zJCkDNFhCW4tWMy PcpzQmQViOLjNpz6OZGRDdwzTTBLOsKlbU9CSW2WJR007ZXaSjmllrR965D/c24gK91GR45JakrX nmHcmw28mUgatMyLR5mJMGJnn+3pmUd88s1H7rERXWeAWLz2tyPCw0QyA6Un1vJofoY+8aGNll4c SKZ5oSHwXn0dUJcSopLaoIkoNhgiY6h+E5HBrwKwq2SksRVhijwtMGFZFJagCLGhvdNxfcoW8IBr 30prrbWwLO0k0tUaB3XU3F675WxFXN0cN0EnFSaSYy5zlLrcEd3uvODR+wO99tJJsL6N2elEv/8C jGzb6RG5iFhKjpqwjqPIAbiNgZjFA86VQQVATjjwcHHjGf994cAcY6hhIHTAdV9VidlU2Kqnsiji dYmz1ahYJZCSTGVCLiZ5/8gEGnhiLDdZ7MwgM98dMAuqdcjV0VUvN1vTyVGJRfEvHI988ugpz3zz u/UC/W3P5Q5ImOYGA5ISYpuJ0nHuor3FvMdv8RIYRbld59voY6ii3R0/dQvCoDGu4+M0IuiXWjk9 danjGksUuT+BRhrqUBEAyEQ6YDBBMSULWcoyACuUQXBFT7EDGTjFMtlViIFduMWwJDO6renFcqMC ARno4bwUGsJ4K2yhC4lHpRgiZ4YEAQPShmcQEXbKXB3K3ge405vuGQcP85JBK4D4g4KsDSYfyJf7 1gdF9p0ugnw6lvbUkT//YIVDXolUZ1rAuM1ccH/3i4v/GBfCydXHDiCgUf/L+EIyVKVhgZsb0YqU 4EDoiAKEOiSRB8gghRYMoY9LIeEWl6ScNQGPJYxspCMfCclILtKRH5AkSwh5FOv1sGQkCSISzyOS 8XCCFp3bwgILcpDyzQ13q4xi3aZowEc5SlOs/FwtHscXvh0KSX6ByiBpBhUzMu6MQijBh7aWETEm E4EFU6D6QNc2NfrRMrWs5qkWFEJMWsSQ/mmFtyZZG99taZziLKdyzqmcXoRTnHUYF/U0yREfgtJM PagnFewZPpjco5TmOdMDePAMa7ZyoHQjFwVhBjOJgbGY0sRbF8ISCEKNaSsJ8wpAbfKjMzYOYxGk XBtFFRgdHDCOsjoZBxH/wzJn2kUetNJmHVe3OZcmi3dt/OY6b4pTdOp0p9jKaR2w0ARzUiAI7swd PMn0yezgs570YtbKUFUSomXsfOZzpVWliNBAsXGLFi1gJqC4K79ocaxb5AEtLQaXMqb1LcEs0BMC GJ3KgS0WADiB5pwyx5NyjjDpYcBlnFFFgcZUsDLlJhu9eZCh0vA4PeWpY336WEMEFZxe0uZEt4LU IUqtN0AMRgGeBwySHAMPLpvbONZx1YIaNKtoQAMPtkrRrnYUbxKTX1bM2qAwamaja+3iMAORzbhe bkYF29sgBtvMZ9otRHkJpO3YIlMtRPcihu1dOYMHrslq97rAQ+d2c/ot/6A6CXoJIaplOZEOOPAQ e5zD5zE2695RQjUIDH2CJ4oRUKquArUEJWzu7ngDA74Ws7F9CyloSaSDHQorMzvQMDqj1o0uVC7G 9OiNqkKaWhBDf0xJGx1ZCaK82IOP/i2xiZUiBDEd1qaGQKVihaM0acHihcOD3gNGgC8wYKEO3z2n eFOwQiD/eHpGbYAjXGCD64VNs5tFj2HycY/QSpkBz7hvMTLxDBwojgrLS61qMSQI1rqWQ2Qt8N8O LN3mDjNSYwUZWyzlls0Ec868LWbQdJBMi0pCC09gZgK/1L5pJuPEhKZedRGLLeV1UtGmVA49wqdj KIGhkk0MQhOKRxIU2v/U0UG1sXfoURsiB4wORj6yktez1Nb6IcvGEV1h7vGXLQDRyp7ggife2lon KtfLf1K1qgdM0TLHFpBwzQCkxpDLr61FDrcYzbHpvNsZtTW4qMnzCXTnrA0DxURPBBSrVhqj6RY6 Oiku4Y0TcrwmrIS8LGkiIxs9WRbwmBsqYcgKi0BU2sj7ajuwxQvAi2Ph3SbU54UHtBowKqSMA4if 7KQ9g7KqD8BayrTGcjTequv+8vo0eMyqxZJ9WQIH21ZeVZyAcrRhHOmulzjCFJCizVZpg5Hap5GK tB8zMtwh9HOk+8kUmi2NG4gbudMtt1YQfWk3WHqR7g51Yr1kgiYQopL/Ud+CG4bKgqH+eyHtBLh4 KcBCyWL9vDJwhEESzh5n1hMH9fxk29Lgqns0grTFuG9A7b7xvFtEpLRcxOIoox9DTUXkZi7gnvlM CkkU7lW000RbAQcVOa9V2mW5c56x4oEplEDbRC8RdG0mYhgJfdykF5qKQXDuqhsv0uElAdfX8PR9 03uoqsi3CbIOb9V7XSHsnnFyRE2uifICyJyIp8L3CzW398RVx/BK3euep4t3W+//pWJk2uzFigp7 +5UBZOK5gIPEh/WL0Q6cbi0a+WlbnsBKYu/AWheih01xg5sbFI7sIYWhlx7Fp0c6doNQA0rHe65H G1YXTlMndVS3A113/3taF3UDuHtgJ3af9XuWxRH3cg/GF033NERIlB7M53zPJ33Ut3+OEWAddyBh tEtstmDcx1WQcwP50UVy9ngbsgyOB22jQHN6AUceEHKcV0uhM33k5wxjVIIkSF39x2O8t4QrgYAL aEMFeHXeAXXOUUkFAHaux4ACiIU6FoG9B2pNYF7vZC4NUHx+xne+VhLn0RR8YhZ2EA11F4fTh4QG ZTfwMwYFZD/IBni6VBmDR3gaAUgRZShEqAjBYiO+lX7pV2Fr9FFeoWJ5hwnMgDN/dYSXmITmpiVO NoBbMBsB+Ho79lMEGGkfgAVu4Af4Rgiqx0LYxU5f1wso9GhBNYZGxf9DaOdzyMdZQKQeT2AjdKAo 0bBcGleHS9Fxb7chO0J+cyEoyahiLfgfQCAEcESNUgFhOPhFurWIOrh+fOgivnJXpJd5lkNN+oeJ unMuKxaKskh1OHYNPsaOn8aOSwdkD/hTLQZwjeVTLnVU7qdcmtUn60CII0iHxVgfvoZROHeI9FNR lNdb0BiN0wiR1gh4vMRyi9iIYPIxlyALsnAJQFh6ShBu5oiJoqKJ2YUQRJSPtaEH32U1KAmTjvV1 TMOS7WSBt4iG7cWBD9dfmcAXbViQ6BNYX4ZVXUAgWuYgg7QIb4FlgJd9MyhRBDYHonE4tmVm2xhM O7gUNucsySALRsD/DDmZWjxzbSQpbiZZKKn3dD22kkL1WG5pAurklkU1ajgplj2BkO1xWhAEksRo kBwnOoTYRUjyI4owOGsGchPpEYmnCMoGANXIfWOgjRiJTB/lDB4ZAKJwl1tzjGkoEQRibBQCKpGh IrLABGHAKgsgC2FgLOc4U4aCepsGl2+5lrXZlg7oWPxol/6ol1wWkKpWMJdzFFQllBlHlLkjCchG eIWyS1TRN7d1S31zQT7pgvzxFsoIcyeglUrRg4SSOrzpFEKQQQkWIRP1KBxRlljBMweweZ+iP6u5 mmEgn6bZmueIllYRm7dJm9ylnzV5hS6JEmtwk7cInumjl2xXIT44/w4KV5yAwADGST1DonmKt2aB yFV8wxEGgnJjEghsgRYT2SuaUIg3KJnbyTUpVxmRWBoAYgdBOSNDYEI7YjmSQBksIAkaQSB2AKP5 UZZh0JHbsEDyaZboCJtqeZsMwW+W5JJtOTwvMCUuxEK6iZMFCqHqAZwhgxUNuh5A4ARlQhQacJwR KkE9YSQdERjn1zUZYUG3JKKC16HrKXjOSZGO95wJEyDr10ULQAy1g4ZTQAeJ86c/d0EHsp5hBaMi czkg8JjYgz+BIQ12lTozcwhGwJossAuryUDmeJ/q6FhJ86TRA6XEkUIkUFWk2jzdgqoBOqAUNZxa iperlmtOZkLZ4/+gVdoFk2AMbGAMk/BVrvmBsRRmRqed/tJxowBbZfV3G8acb9qHdTqi+VMdzlkL 3YggtWMZfWksj1kXKgJGOmqskeEo93eoKcYDHgECFLNQf1EVF0YxlkqpQPMOPlqf9pmO5xp2q6dC 2/I01HIla8kciGABVkANAisDBVsAAkqGJkSuatqquwahuhirgFCu7Vqck9AvecCrvkoiKYiNymkH EeaxOpKucUoVt7IIFcmczAlGXnSd/vEXlfkWzuArMouGT9CiiYEGLToEjndBvBQMwKIaiGqsrwU2 1vinGJYRo+OjpnkITUufvrqpxHAGSNqSSrqk+eipMpQ0wAOwAUv/sAR7sDd5OsRQV5splMWBfD2x IwsalDvhBP2QDcYABHLrl9RTV9nHh1FplSIbrSmLYR5KsnF6g7lkVo25rhkpXMrakR6JrTZ6s7mi swvFAmB0H4wzrhakqAqqI+fqLJv3p2wBn/OJqRobtVawAxagCrGRpKtrtZD1qVrrr12Lul5LBAVr sHQZfDhartNotm2LtnvZIA46q0B5J7naD/DRpWAapgEjMjeiH4Hnt9jnrHLqHxmGstP7sW16OWVr jYjLcYkJI31KDDhxAK+1csQFMrmCOW20p0HrgzPKACakoJ2Rray5C4cApLswr/TKnGaQurNLu7Ir wKpLwKxbXq8b/0OxC8Bfa7u2+wDAhyyDFxnO0gJhGpS/u19tk2Leq7x30qt/eRcKNpiBS8J6O1bW 64efERUM9pjK+rIeJXJUqqN9VgIHMCj8g23BICGAZI3ac227MiA4+6B49HkAtiu+yMFFV6+VULtN /LUBPMAFXMACh6oullgtKbsM3MBXcARc/MCrCmxU2ravmsFErLZi/BOvY2c5obGn4p4jjL3WYytH xWANkphtdjjLAJ3ZVhWH54gxjDuqoaM2CkbGNjr38X4fhjICklBv5ShpJZo5IxfaOaQjcxWbwAtd zMWavMVP7MlQ7IrYopJrWQBYM7C0u8WbDAer/C5S+qjTUcGuSv8YvNGZy1erLqofmQfCd5F4csAD m0GRcawjJxKyKcusy+mUe8MVAGC4FaAISbyVy+mar3MCkwwXP3sWEEPJQJsxZlFslxi1TOzE40zO 5SywXqu6SmoG65zK7czKNgDP7xy2CavDjoIutCrL5lHGtTzGHSxB+9zGb0SDyTzQmKUIdaG91EsH pHGyMYydYsXCeXunMMx+08yxEWYw8vANO9s/00p00VWuzInJnEzSJd3J5wzA/1u1K23KWqzKDfDO 8SzT8dwKuIsswBDGety7vwnQZsyguwxmy8XRvxx564qVBs0gPkh4xzxyirhVNryUdurHAmSXjetQ nEIgC3WdSvD/yAUSLAZQTI8CYP0cMHGwxJn80ibdzuac0i2NygT70jMt1zM9DS7FdqdjkgqyvF/W ZSY2jKLzRHsNmHj0UBAEMcZUV9lrFXyIg9XMx5iX1BDJ0HfMtyvrnGRwA8o8yBSNWXHk19smF9rD MSZKWIFNLiFdKCMd02mt1mzd1ujs0nE917Nd09qkhrFCB7HM1xvoa+vQ24QN3HxX2qYt2MYYZoWN E68CuEDnGdg8skenKV2h0H/bwmQFlfSzx6Pi0X9c0XeWyENqIfRHPWYt0qvNyqzd2igN2+sd2zEN z5zw3vFN13YNSx03f8RJ3IQGzcXN30rhd8ctXaZzDJVoOJ6R/wz50CzO+x/RHb0cCridPYPX7DcN rab7faKALDD5Lct9NJ4RSt6prdrnLeLo3cDqzd5v7c7yreIqXtt2ezoPBaz9XWKBJtgfjInB7Tp4 CLTSDWEI3iwV3UHYmZhKGT+xFeF6zB9zwAXGukXbTdXbR7wBneHEq3kgfdYjjuUkbrsnjuJNLNsr DubwXNe2/eITdFr8JeMW3FDHSQlG0ebnONbJLRqXcBl07lvTkDMLtiAZkNCHYrJFflmDGylsVSgA ZVfoMtXCRaIsaNVSDqRacA6RLumtKelNS0dVLlMfzh8wneWdrspbzuWnLOpe7t5hruJcoTUu3j4x nuZRfnwa3v9Xb568rZ4U/Fy5LXd/N+h9FCaRFPVVfe6mb6am6EKn1yjRbTVMTq7oi3d9Oz3c8Drp 9YkJTUvt1Q7tlR5Nyp474Rzinv7pJR3qZyDuaN3ts22Gy1IJ6d4KCE40ib5arFbftP7TJMK2NS7r GvvfsmMWzJIPl4Dnuq7NUwnsnDfwgDc5Niu912jNFjM4UrAACzB63I0kv+jsmSo51Y7xGS/t0x7t +2ul2s68j8LHnG7u5v7tou4dD1DKTMNwa8iv+vq79L0qsETjIenPMCPvcI7jWVC52avVPItWKHtb EfFadUoZJvvg/EHQE6LGQpCZdB4AIM+DLowuWwSU2F7plp7/7RnP8dCkyB5f2lL/SgglkSSP7uqu 8lioVAj8PPhqqm8P96War21PyzJP82yX83fj245eNwDOIOBXAtLdS9OQfoRPfs9JDA12vYtN4yE9 Z3ksKw//9JMP9Ra+d2qazPd88Vxv6Tfw9Q5r8z4XXaItZqG6G6N6r6iPsKsv961/+q8P+8Vh93dv wSYWYnmP+2zB1bEj5xcJLHR6zXCcSy8c1dCb23+/P8bebL4C9ZdA+c4P/VG/fsGGQB0P7WAf+rz9 QI9+48AKK6mv+n0d/qnO+q4/9xyIHmQuZjW/24R1+58t5VPVKjKI4H9k+H/kvIf/oTyg+wDBQt0B OnakHWyx/yCbgS4GWNwIRMbeJYoBLF6smFHjDxYEPH4EGTKDNBAliZ1EGczhyo4tXbKEGXPby5kZ mCi5mRPnTh2xbMqkGVTkUJEljB6lsufFUqZJmz6FSiKqUqlrql7lltUqVqpYvH516lQoUaKZkPpB CkjtWrZZgLaFi2MdXLp139olS7ahuicN3aLxIG3akyf5NC1rEczD4nuJgz1+TCxYCRZ+h5BUTEaI kFp+K9dagFH0aI0VOeYtKqQFStZ2xr6WqZPn7J93Yd9GLVJJLQC9e1B2A2ar8ODFjQ8nnlw5cubN uU69VkM6Fdyo0cg9mh2vbbpq1snlwn27+NxlF/EV1BLA4/9Rc4TEYTwGscGCrEseAO7whr1bPDa/ t+cGTASUIjTSDrzIQIpOK88j34wahSCUyLmtJwtpu5C86jZscKjdsisBw+dGdK7E405EUSsVl+PQ POxAHO+v2t76bh3vNMQxxtx606y3DARCiD7HDrPvJMU0OeAWNLRgchFSClSwoigTRBBKKWq5ssAF c7wOxBKGOOEEEcdssUwzO9TNy7C6go5NN9uEk8QUTURTrRrV1DHD7saxkZIbc8xTR70A2CxEnwZq 7cj3CFJ0CMKszHJKKielNMFIJSWDwQYf5K1Lo84ENVRR0wTxTTnjNPVUVKEb1VOqfAv0xz37DO9P QG9FUxD/NAoVEMhEOdMCB76yhNRAYytFMFllA8hvUy/TwrXCMb/JkMxod8RTVW1X3bbbVq8Ly8dY gZJNjVp5EjTdOj/CKSJJAOgpkJQyI3YBKI9dNl99S7OXyVw5hXHUoKgleLYpCpZVRIEH5XTNVLn1 FmI5RaVVuAEzUWLc2B6+Vt1NY3EU3nAMKEETef7DN2VkV2Z52SsFvFjWDl1tWCidKkM32owvpJYh g3de2MNsJSa66GpTXRckcP8Cdy6P42JDRg30fLrqHZVAL2GVW+Z6Xypfjrncm1o8GGBYB+5J5J7X 9vHnGd+WmUagO2b4QYXntHhFE+emCm9vvyWOT8GttrNv/7oJnxnrQA5u0uuu9bUXbLt57uLimMme PGea1KY8bf12MrRsn2sL/aEpgl73Q1f1Zr1zmgync++JY69z7Lw1d+vwuHVHXGlBChP5Icgfr1Ry s7s0Z1pdbU986cpv3tyl033CyXTq+Y5l+tM5Z5zx16OuCXXfkQ9eW5xhpx1ntP9Ov7zOq+89d97j zwv06YV3XFJLiZ0c5+ObdtvIBIi5n3kveuoZ3c5ow70Ckmx79wuf+OqGvNbJ7nwVtOAFY4c+ih2N g/SbHwg7kryfpAd/+QtNGlTYqcydzWcNSx4AW0g1Z70Pe+pDIO5Il8AG3i2CPxSfDmT4Qb+1L4is S9qsLP8kwhAykV2LcN4JXbbCd/1AXC/0VP/KRr4CunCLu7taF232I+wp0IxnpBAafSjBCepwg4TQ YBExOMfZJXFPYGyiE0UoOil+jX8zVOMXlzRCLg7RftdbGgHfN0b4SQtuaiyhT3DIRvO4LoNGPCIm 3ZdHPXZSaDj5QeT+CEAbDhKLMaQgIbdIygAeUpFiC9oSI0lIHsKNkpWUpSbhqMtdypGXdpQfJz3p SVCy0IQeRCQfNYjKRooxl+ha3vJeCURh4rGaqUNiL2/pS25uc5jfBCaXBjhONy5SlaUUYDnJ9kxb etOd2PzlO7U5T3qGE5z3xGc707lPdlqylsjspyRjmUn/edqzngVFqEHzudDaBdOh1oToQ7+XMIle M6IJxWhGNapQhnaUoxYF6UZF+tGRltSjJzVpSlW6Upa2FKUvdWlMZTpTmpIUpjetaU51ulOe4tSn PbUpUIM6VKIW1ahHRWpSlbpUpjbVqU+FalSlOlWqVtWqV8VqVrW6Va521atfBWtYxTpWspbVrGdF a1rVula2ttWtSkUADCYw1irgAgZVMGhc5/pWvha1rnftK0cRgFcNwEADYKUBAgR7WKnSwLCB9Wpi QzJYhYpAsevSa1ATCwO5buqx5YkrYJU6Abtydq4X2GvSSAsDxVrWjqG9gINCKwIC/PWy7AotDT4i V87e//YjF+AsYcuz2s6qtreE3SxnP2JZzrJWuL8NrkdWu1fbQle0ZCHudRuEWjuu1rdJNC0BEDDX zX43nJ2dAG0nENu8rLdBpK0te5GKgPFK967aFUl9h0JaGthCsdxNHWsPS1n00ra117XselPLXNoW V7r/xcV7DYxfkOhXJMClrWs1oFjHXvYC+t2sbpdr4APTQASGtYVcU6ze1sp3KPSlrXgZ2yEKvxcX /TVvSDScl/Gm10G1/aw96ypd3daXuQSAL5JN61/ATjck/L2ALZLKXfp6hLebtW9xRetk8e41trhg rm5tu9kwV3jBGhgykkVMgBSvmcOfTeyJPWLhwuJVzv+gTS9/lRxbAG85vHqWLpsN22Mkz5W07MWF i3/75b3e1b1dRjIC/CtlolRZaXF1rAiYK2m9YrrNcVUyeePKZ85Ses5ePnSX//pg2ToYuqkl8kfB 7KDmXqAK7uWue++KV8O6FrgiUS5cT71hMLMWvr7mrWmRzerdDhbFNz6xbgU8a2ZPNsYgefScbXHn IUc7xQt+7J3dJ+nHxpkAjm5ueiFc50onWMaCJuyHdXNjx+q2zVpudJCLou9CC9jXE5C2YsF84vHS u7439sinrx1pxpp7165trmHvSmdaz5jJsM5rjHd8cE0/+7AQz3CQ40zto/rXyn+OMJVDXug5r5zZ 0Yb/L3fbfOfrUvwjdBaBoiueZmLbVbjyZniDJL3jXT/20bM+sbh1/GUDfzzCc9a5pJVM63pbWQQj xzi2n+7kJD8WsDTPecrJ22sX2zzodXbsYfus9g/nOK4LnzpJjQ7wuRZ9w4b2MMCbXHanwzW9QeZ4 mxk+WL3jNdssx3Xd5ypn9/L83HBn12d97KGJ59e3QCc5aoh7WcZflvBVV/DTgd1cw0e4uJm+NKXv /GHBy3nrohdJkoNu5ANLN7ZD5vjgMY7wC9++15f9OoTlmnV1Y/zwr93rirs89InTV651lbeKpb/m uhZZ50YFupX7O/zp15ncepe9vDme6tzT2dUgbnK8/+etaNJ+99iwr1/ebU9wgVs20/WWfYVjHOQk pxq3RK6+6iss8BNAs6O1sWs03WK9RKu/u0O74eMuFSs4SAOy3/ov1GItcpOy9So4TfuunGM51wK0 cKoyJhswqTs00lovuYKxcys455qs3lqqFEu3CoS+niMsARMv56orQ+sswHIuLqtBrbMz55uaKjux 5jK1/1suY9utvYorqQMtSiutHeTAq9PBKMxB+Xu0JDytiKO40iou4CouL5wzGWyv3vo6ozO2Hwwv ObvBTjM2x9JBIPPBL7xC6Ls1hLMr4/OwaYNBhYKtGYOs7jqu8lC6GBQwJnO1p6KscPor9MqxqkrE of+oxCTyLsjLlTosxEI8vq96O5Kqq0msKgBrr+vrxFSkqkRTRbZKu9xgxVaUxakKLfibxbAiw+eq NDS8xV70xV8ExmAUxmEkxmI0xmNExmRUxmVkRq9SgTLoq2dsxqKARlWMgRiYRpuKhMDaxmwEiW5M RXD0xpAogwRIAAIABXOcATYzx2p0kHZ8R3PEqnI8RzaLhAQoAwaAR3bZRyDYR1Wkx48AhXUkgHus RnqkBJBASI8wxwRIyKsKyIJUR3JYyHisRn+Ux66aAXzcyHwsR33MSIxcR4MsSHFEx2tkSCDwR4pc xwRQgY8og5Z8yRhggHDqyI6khI9syHgcSXksA5P/nAGUZMd8JICYJAeXhEmZLMia1KqbxMecdMid rK2JJMmfDImgJEiJrMmBpASXjAFoNEqP+MqixEYVyEo7YoByBIWP3Mig3MeAFEl/ZEqxFEqK/Iix DEuyPMqZnMuuYoAYcMl0vEZ8VAFp1EcKOUkVqEeRuMea7Eo/iUpQIACkZEjJRMp0lEy0BMyBTIDB LIPCPMfDpEvFJIrGZEh3RErKnEzLlEzM1Kq/DMzO7EjQZEfEDErSHArTRMdyDAmHjIRt/M27BM5t TEuTxKan7MxIUEsgQMlIyEqHzMtvdEiYrMbgDM7KXM3dzEyvMsoZgEbApBDn1MvKVM2Q0MfMpMdz /wRMcwSCu2zI9qxNYOrO76xH8czLzixPpUFKjOxMiWRP9/zP+Myq+ZTI8MTG+9xI+NQN1fTOb2zN hsxKxZxIhnxIO8LN1CRIl1xJulTOsihP8ZTQ/hTL93xHsJpOowzL1GTK2TxLclzMrgRH3nRRdnHH JDrRdUzRl5xOdCTMFlXIc0xHHqVOkZBRNqvRq7rR8VTREf1MH4XJxRRPsdxOrbzKHZ1MxLQjlFxJ 3DzMsWRI2cTSGYXJlxzRCvWIIk3LryLNID1Kx3RIfyxM54xKBQ0Js6zGdLzIj1QaPTXSKV2XNa3H 6TxMOGXOjexKOgUJOxXSBk1LKzXSHc1JP60qQP+lEEF9Uw2V00MtiwbFzqVExzPNz3vcTqsMJxQd yW7cyKIES8UcyCMVSE4VUlCd0kZlykj9qvUkSi4lzHYEAjytSVL9CF6dTBEtx0hIyFQt1mOd0Cxt x4TU1c/kVV8dz2B9SlCFzs5U1qLEVv90UqrCVWetR3+E1h6tVmD9UqK8R3lcT68kzNqcTR4V0XCC 0DMlyI2U0/6cSMU002Y9ymp918NMVm4Fq+g0KONsKoK1J4NtK4QNJ4WNKtzkKIflK0dtK4qdRovt Ky8dx0TF2LRKRzOdxo8FSIllRv6UVLQyWW9M2UJMz4112ZeF2ZiV2Zml2Zq12ZvF2ZzV2Z3l2Z7/ 9dmfBdqgFdqhJdqiNdqjRdqkVdqlZdqmddqnhdqoldqppdqqtdqrxdoO0Nqt5dqu9dqvBduwFdux JduyNduzRdu0Vdu1Zdu2dduuFYC4ldu5pdu6tdu7xdu81du95du+9du/BdzAFdzBJdzCNdzDRdzE VdzFZdzGddzHhdzIldzJpdzKtdzLxdzM1dzN5dzO9dzPBd3QFd3RJd3SNd3TRd3U1dsBGIC9RQbW Vd3Ofd3WFQPYjd3bxd3cFdwBqA9tEAO8rYAKAIEK+Nvgpd3FrQBkEFzlfdzgJYYK4N2C0N3ppV7d Zd3jRQY6kNvgvVvbvdvZxV5ieF1iKNwBCF7j/0UGZCDewOXdxzXfuM3e6l1d5gVc75Xf+93d5BWA +BUA7oVf37Vb8f3eAVBeEDhe/yVc9SVg9QWB9KVf0aUD2kVg/KXbCeZbBm7g1L3eDX5gvwXf351b Ao7dCA7huCWG48Xb9u1e+M3g/W1hwl3fuBXe0+VfAThhy93g6+3gvp3dEpZb9e3fGNZb7VXd1x1f EBbhv1Vf5RXeB5Ze1YUAId5fF2Ze+7XdKBYA+93f9YUAIs5iL95f711gAWbdB7bf4Z3bHq7b9KVd 2n3dH9biKoZfFF7juFXh7N1hxzViFc7iPM7b633h95VbLV5dMD5dCJBhL/bjP5bbk6BfOjDgIv9+ 4RAmYuHlYuctYEDu4PWlgxjuZDjm3fRtYujt3+gN4fA9YNaN5EGGAPOlXRDQBuElYgVuYFe+4Rn+ YruVZQnmYkOGXETuX0Wu3wKO4exFYSneWwsuXWC2YWY+ZQDuY2PeXmgWXl6e5P8FZc5VZhkm3ta9 YSCeWzTm47odXgLu4kfOZVUGZtgl4R8mXzuGZTvmZCFOXj5OXvXl5C8GYv8tiWlOY/2N52bmZspl 5k+uWytO33bWhlc+XleG4z4e5N99Yzi+4Tmm4yle6DlmZRB2XE9u3SReYkgOYwMm5e1l3vH9aOel ZDTmZlzW3FUm5zaO55Jm4SPu3ha25+SlA+b/RWBY3ubt9WIBDuI01gaDjmUTTmk8XmhpluYwptud zmUqRmqCrmmI3uLsJWLedWj47eaA9mb61enn3eIGluXtjWKvhl6xtuXWxWVBjuCfRtysNmA+JuNa FgOWDmEuvmtvLmpPzmQ7vmjMVeo1RmsXhuYv1l/g9eKepmmB/uIkxluWzumYtmOJjufnReE7bmEp FmT/1ezDhly5VuVGtmwjxutpvuOvrmxv/mitjmUu/uh35t9zRmR+XmzDBm3GJeEuxmZBVupx1uVm LuNVbmUTBmGh5tzBptv2/WvgNl5kDufjrejBZt6A9t9Fdu2oLuod/mZelmqMVuEmtupGZuiB/z7i RVbc3ZZtea5q4KZkGTZup9ZuXCbh2eZkmV7qSG7qiT5tPfZdo55q3MZivH3j4e1q351tuf7cpq5g 6EVksg5liL5h5F5uRW5haSZle9ZeQdZlr85gDp/b5yZvAo7kksZjCDBmQhZnkhZu83VwywVwx7bv FIZl6WZioCZvAS/v7YbnHv/uGD5nyoXpAB9whQ5uG57pSp7ngf5cABfhanbhncbqxJ5pzo5gqIbn 4r7rkuBpIC+JwB5rKY/yAT9oI//yLcdyE+bkNA/n4cXq/77lIZ9cOSfu+6ZxE2fxHBdwIm7hDB7s dg7vD1fe6oZuxo3wcM5n3O5eCd7xGdbq2v+u5NzGYZx25h/+YT8O6Et33bxFb6LW9O8F7Qfe4Ybm dGzG6FOv3ENv5ES/a0lnYWZ+c3cG4vCu5xL3aaa28JC+3viO8cbtYgM2YwOvYl8OZqNeX2MWZS53 5C/u9cyN3sYOXM8udAq23pOA7GCO4mHndDBW7ihn4jUn8XJmaUgG8b6Gc7DG5OTu9DkWdbpNX4xu d9nN4Xmn93rf4E4+a3vX933n9373938HeHtfdz0eeAK/6IIP9VGPaHdHeGr33Og1iYiX+Imn+Iq3 +IvH+IzX+I3n+I63+Ep3+JAX+cPF5/M1+ZNH+ZRX+ZVn+ZZ3+ZeH+ZiX+ZVv+JG3+ZvH+Zwx1/md 5/me9/mfB/qgF/qhJ/qiN/qjR/qkV/qlZ/qmd/qnh/qol/qpp/qqt/qrr9yAAAA7 ------=_NextPart_000_000E_01C814A6.F4B33110-- From pavliknde@yeanet.com Mon Oct 22 09:25:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxHB-0002p9-AL for ospf-archive@megatron.ietf.org; Mon, 22 Oct 2007 09:25:01 -0400 Received: from [64.76.44.251] (helo=[64.76.44.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjxHA-0000HO-Nw for ospf-archive@megatron.ietf.org; Mon, 22 Oct 2007 09:25:01 -0400 Received: from ale ([135.159.28.151] helo=ale) by [64.76.44.251] ( sendmail 8.13.3/8.13.1) with esmtpa id 1hBjZc-000FUF-bC for ospf-archive@megatron.ietf.org; Mon, 22 Oct 2007 10:25:40 -0300 Date: Mon, 22 Oct 2007 10:25:07 -0300 From: "Sukhbir pavlik" Reply-To: "Sukhbir pavlik" Message-ID: <789844300652.124165134201@yeanet.com> To: Subject: de'teler MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 4.0 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hello pal ospf-archive never be nervous in bed again with a big strong dick http://oecdorg.com/ Sukhbir pavlik From ospf-bounces@ietf.org Mon Oct 22 09:43:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxVM-0007TD-8M; Mon, 22 Oct 2007 09:39:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxVJ-0007NE-IR for ospf@ietf.org; Mon, 22 Oct 2007 09:39:37 -0400 Received: from bay0-omc2-s29.bay0.hotmail.com ([65.54.246.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjxV8-0002GH-07 for ospf@ietf.org; Mon, 22 Oct 2007 09:39:37 -0400 Received: from BAY144-W26 ([65.55.155.61]) by bay0-omc2-s29.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Oct 2007 06:39:10 -0700 Message-ID: X-Originating-IP: [222.130.193.26] From: fuchao To: Date: Mon, 22 Oct 2007 21:39:10 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Oct 2007 13:39:10.0540 (UTC) FILETIME=[ED23B8C0:01C814B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [OSPF] About the self-originated LSAs X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2080505493==" Errors-To: ospf-bounces@ietf.org --===============2080505493== Content-Type: multipart/alternative; boundary="_858fc8be-fc31-4395-9a12-35bde1dcfa68_" --_858fc8be-fc31-4395-9a12-35bde1dcfa68_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi All, RFC 2740 says "3.6. Definition of self-originated LSAs In IPv6 the definition of a self-originated LSA has been simplified from the IPv4 definition appearing in Sections 13.4 and 14.1 of [Ref1]. For IPv6, self-originated LSAs are those LSAs whose Advertising Router is equal to the router's own Router ID." Because the link local address on one link is unique, we also can know the Link-LSA is self-originated if the link local address in the LSA's header is same as the interface's which receives the LSA. It is useful when the router id changes. If we do so, OSPFv3 will work better, won't it? Regards Fu Chao _________________________________________________________________ Óà Live Search ËѾ¡ÌìÏÂ×ÊѶ£¡ http://www.live.com/?searchOnly=true --_858fc8be-fc31-4395-9a12-35bde1dcfa68_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hi All,
 
RFC 2740 says
"3.6.  Definition of self-originated LSAs

   In IPv6 the definition of a self-originated LSA has been simplified
   from the IPv4 definition appearing in Sections 13.4 and 14.1 of
   [Ref1]. For IPv6, self-originated LSAs are those LSAs whose
   Advertising Router is equal to the router's own Router ID."
 
Because the link local address on one link is unique, we also can know the Link-LSA is self-originated if the link local address in the LSA's header is same as the interface's which receives the LSA. It is useful when the router id changes. If we do so, OSPFv3 will work better, won't it?
 
Regards
Fu Chao



ʹÓÃÐÂÒ»´ú Hotmail£¬¸üÇ¿´ó¡¢¸ü°²È«¡¢¸ü¶à´æ´¢¿Õ¼ä£¡ Á¢¿ÌÌåÑ飡 --_858fc8be-fc31-4395-9a12-35bde1dcfa68_-- --===============2080505493== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============2080505493==-- From ospf-bounces@ietf.org Mon Oct 22 10:01:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxpX-0001IW-7w; Mon, 22 Oct 2007 10:00:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxpV-0001Gi-8d for ospf@ietf.org; Mon, 22 Oct 2007 10:00:29 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjxpU-0002d3-Mi for ospf@ietf.org; Mon, 22 Oct 2007 10:00:29 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 22471DB03B8; Mon, 22 Oct 2007 07:00:28 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32124-09; Mon, 22 Oct 2007 07:00:27 -0700 (PDT) Received: from [?K??N???p??????$IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 89161DB03B4; Mon, 22 Oct 2007 07:00:27 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Acee Lindem Subject: Re: [OSPF] About the self-originated LSAs Date: Mon, 22 Oct 2007 09:58:49 -0400 To: fuchao X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 1.8 (+) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0591781857==" Errors-To: ospf-bounces@ietf.org --===============0591781857== Content-Type: multipart/alternative; boundary=Apple-Mail-1-5964699 --Apple-Mail-1-5964699 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Hi Fu, On Oct 22, 2007, at 9:39 AM, fuchao wrote: > Hi All, > > RFC 2740 says > "3.6. Definition of self-originated LSAs > > In IPv6 the definition of a self-originated LSA has been simplified > from the IPv4 definition appearing in Sections 13.4 and 14.1 of > [Ref1]. For IPv6, self-originated LSAs are those LSAs whose > Advertising Router is equal to the router's own Router ID." > > Because the link local address on one link is unique, we also can =20 > know the Link-LSA is self-originated if the link local address in =20 > the LSA's header is same as the interface's which receives the LSA. =20= > It is useful when the router id changes. If we do so, OSPFv3 will =20 > work better, won't it? The details of how dynamic configuration changes are handled have =20 typically not been documented. As an implementer, you are free to =20 take advantage of this assertion above. However, I personally =20 wouldn't do much to optimize for the router ID change event since it =20 should be rare. Rather, I'd optimize to avoid Router ID changes =20 unless necessary. Thanks, Acee > > Regards > Fu Chao > > > > =E4=BD=BF=E7=94=A8=E6=96=B0=E4=B8=80=E4=BB=A3 = Hotmail=EF=BC=8C=E6=9B=B4=E5=BC=BA=E5=A4=A7=E3=80=81=E6=9B=B4=E5=AE=89=E5=85= =A8=E3=80=81=E6=9B=B4=E5=A4=9A=E5=AD=98=E5=82=A8=E7=A9=BA=20 > =E9=97=B4=EF=BC=81 =E7=AB=8B=E5=88=BB=E4=BD=93=E9=AA=8C=EF=BC=81 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf --Apple-Mail-1-5964699 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Fu,

On Oct = 22, 2007, at 9:39 AM, fuchao wrote:

Hi = All,
=C2=A0
RFC 2740 says
"3.6.=C2=A0 Definition of = self-originated LSAs

=C2=A0=C2=A0 In IPv6 the definition of a = self-originated LSA has been simplified
=C2=A0=C2=A0 from the IPv4 = definition appearing in Sections 13.4 and 14.1 of
=C2=A0=C2=A0 = [Ref1]. For IPv6, self-originated LSAs are those LSAs whose
=C2=A0=C2=A0= Advertising Router is equal to the router's own Router ID."
=C2=A0 Because the link local address=C2=A0on one link is unique, we also can = know the Link-LSA is self-originated if the link local address in the = LSA's header is same as the interface's which receives the LSA. It is = useful when the router id changes. If we do so,=C2=A0OSPFv3 will work = better, won't it?

The details of how dynamic = configuration changes are handled have typically not been documented. As = an implementer, you are free to take advantage of this assertion above. = However, I personally wouldn't do much to optimize for the router ID = change event since it should be rare. Rather, I'd optimize to avoid = Router ID changes unless necessary.=C2=A0

Thanks,
Acee=C2=A0<= /DIV>



= =C2=A0
Regards
Fu Chao



=E4=BD=BF=E7=94=A8=E6=96= =B0=E4=B8=80=E4=BB=A3 = Hotmail=EF=BC=8C=E6=9B=B4=E5=BC=BA=E5=A4=A7=E3=80=81=E6=9B=B4=E5=AE=89=E5=85= =A8=E3=80=81=E6=9B=B4=E5=A4=9A=E5=AD=98=E5=82=A8=E7=A9=BA=E9=97=B4=EF=BC=81= =E7=AB=8B=E5=88=BB=E4=BD= =93=E9=AA=8C=EF=BC=81
OSPF mailing list
=

= --Apple-Mail-1-5964699-- --===============0591781857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0591781857==-- From ospf-bounces@ietf.org Mon Oct 22 23:59:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAr0-00064R-Me; Mon, 22 Oct 2007 23:54:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAqz-00063J-Su for ospf@ietf.org; Mon, 22 Oct 2007 23:54:53 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkAqu-0004LE-Da for ospf@ietf.org; Mon, 22 Oct 2007 23:54:48 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l9N3rntd037507; Mon, 22 Oct 2007 23:53:49 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200710230353.l9N3rntd037507@harbor.brookfield.occnc.com> To: Erblichs From: Curtis Villamizar Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPF protocolQuestion In-reply-to: Your message of "Sat, 20 Oct 2007 01:02:15 PDT." <4719B607.770D8C01@earthlink.net> Date: Mon, 22 Oct 2007 23:53:49 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org In message <4719B607.770D8C01@earthlink.net> Erblichs writes: > > Abhay D.S., > > Sorry about the top post, but.. > > TCP has a slow-start mechanism with ACK > clocking to verify completion of xmit'ed data, > until a threshold is met or, Not a good description of TCP's window mechanism but off topic anyway. > Until 2 or 3 DUP ACKs are seen and then > rexmited or a coarse grain timeout occurs, 3 Dups. Its called fast retransmit. The timer is based on an estimate of RTT unless there is no basis to determine RTT. > However, TCP does not guarantee that the > recvr will actually recieve data xmited > by the send, just that if the data arrives > then, it will send acks.. Are you claiming TCP doesn't guarentee arrival of data? It does. > And again, their is no guarantee that the > acks will be recieved, so the sender can > send more data. The sender retransmits in the complete absense of ACKs after 3 seconds if the initial retransmit is lost. Then doubles the timer up to 75 seconds (odd default) and keeps that up for 15 minutes (by default, all this is changeable). > Mitchell Erblich So what's your point? Acee's response regarding using the MIB is still valid. With SNMP you *in theory* have to retransmit but if your NMS is not braindead and overrunning equipment with SNMP gets then you'll get the response because it is on IP prec 6 the whole way (unless your OPs staff is also not too swift). If you do lose an SNMP get, a retry or even a series of retries is not the end of the world. Curtis btw - There is also FTTCP (fault tolerant) from Avici (patented but I beleive the patent is invalid) which keeps TCP going even if the primary server goes down (hacked TCP does application level 2 phase commit on primary and standby server before sending ACK). Amber and others used a secondary that snoops on the TCP data for another form of fault tolerant TCP adequate for BGP and manangement sessions. But this is OSPF WG so we're off topic. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Oct 23 00:02:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAy0-0007Qq-JR; Tue, 23 Oct 2007 00:02:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAxy-0007PK-SU for ospf@ietf.org; Tue, 23 Oct 2007 00:02:06 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkAxy-0005SJ-F8 for ospf@ietf.org; Tue, 23 Oct 2007 00:02:06 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l9N402F5037669; Tue, 23 Oct 2007 00:00:02 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200710230400.l9N402F5037669@harbor.brookfield.occnc.com> To: Erblichs From: Curtis Villamizar Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPFprotocolQuestion In-reply-to: Your message of "Sat, 20 Oct 2007 01:21:19 PDT." <4719BA7F.BC701169@earthlink.net> Date: Tue, 23 Oct 2007 00:00:02 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org In message <4719BA7F.BC701169@earthlink.net> Erblichs writes: > > Abhay D.S., > > > Actually it is just a bit more > complicated. > > With OSPF, we should start with a case > of two routers. > > How does the restarting router know > that the restart is done and how does > the other router know that the restart > is done? > > The restarting router can determine > whether NSF and restart is done. Whether > restart required a a standard resync of > the LSDB is almost irrelevant. > > So, the question is why must Gracefull > be successful? It basicly just "reduces" > overhead while NOT distrupting forwarding. More important it does not slosh all of the BGP routes (hundreds of thousands of them) away from the restarting router and then back. In an IGP only transient routing nasties due to inconsistent notion of whether that router is up or not is something to be avoided (you know, transient loops, transient blackholes, and all that). > Thus, It is done when it re-starts sending HELLOs > and re-extablishes full adjs from the perspective > of the 2nd router. The hellos are the aliveness > criteria from my earlier post. > > ` So, you MIGHT want to track the nbr FSM > if you have access to the OSPF source code. > > Mitchell Erblich > ---------------- > > > "Abhay D.S" wrote: > > > > Mitchell, > > > > 2) Their is no GUARANTEE that any Restart will > > be sucessful, that the LSDB will be stable and/or > > that helper(s) exist. > > > > I wanted an automated and deterministic number 2. > > > > Any ideas or any attempts in the direction of 2 ? > > > > With Regards, > > Abhay Looks to me to be more like a windmill than a dragon. Curtis _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From kypros670@thesavorys.com Tue Oct 23 13:06:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkNDA-00010G-TB for ospf-archive@megatron.ietf.org; Tue, 23 Oct 2007 13:06:36 -0400 Received: from [84.52.167.88] (helo=tm.84.52.167.88.dc.telemach.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkND9-0002TA-FV for ospf-archive@megatron.ietf.org; Tue, 23 Oct 2007 13:06:36 -0400 Received: from user ([151.189.154.9] helo=user) by tm.84.52.167.88.dc.telemach.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1fafJJ-000BAK-Bq for ospf-archive@megatron.ietf.org; Tue, 23 Oct 2007 19:07:02 +0200 Message-ID: <000701c81597$15b68fb0$58a73454@user> From: "kypros rumeo" To: Subject: ahurie Date: Tue, 23 Oct 2007 19:06:42 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C815A7.D93F5FB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.9 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C815A7.D93F5FB0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable hey poppi ospf-archive extended cumming means extended pleasure, sound good? http://www.panggya.com/ kypros rumeo ------=_NextPart_000_0005_01C815A7.D93F5FB0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
hey poppi ospf-archive
extended cumming means extended pleasure, = sound=20 good?
http://www.panggya.com/
kypros rumeo
------=_NextPart_000_0005_01C815A7.D93F5FB0-- From beryl_chantel@DEJAYY.COM Tue Oct 23 15:26:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPOn-0002Lx-Lv for ospf-archive@megatron.ietf.org; Tue, 23 Oct 2007 15:26:46 -0400 Received: from adsl-243-90.37-151.net24.it ([151.37.90.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkPOa-0000sK-Er for ospf-archive@megatron.ietf.org; Tue, 23 Oct 2007 15:26:39 -0400 Received: from orso-c2819ae316 ([125.120.176.0] helo=orso-c2819ae316) by [151.37.90.243] ( sendmail 8.13.3/8.13.1) with esmtpa id 1PLliQ-000ZLK-Dy for ospf-archive@megatron.ietf.org; Tue, 23 Oct 2007 21:26:54 +0200 Message-ID: <000901c815aa$983828a0$f35a2597@orsoc2819ae316> From: "beryl chantel" To: Subject: nahgnikw Date: Tue, 23 Oct 2007 21:26:22 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C815BB.5BC0F8A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.6 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C815BB.5BC0F8A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello friends ospf-archive create your own sexual destiny and enlarge your cock http://patrouts.com/ beryl chantel ------=_NextPart_000_0008_01C815BB.5BC0F8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello friends ospf-archive
create your own sexual destiny and enlarge = your=20 cock
http://patrouts.com/
beryl chantel
------=_NextPart_000_0008_01C815BB.5BC0F8A0-- From vhoy@bphomeinspections.com Tue Oct 23 20:01:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkTh3-0000QP-OE; Tue, 23 Oct 2007 20:01:53 -0400 Received: from [189.24.180.15] (helo=18924180015.user.veloxzone.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkTgn-0003zT-N9; Tue, 23 Oct 2007 20:01:43 -0400 Received: from [189.24.180.15] by mail.host.eticomm.net; Tue, 23 Oct 2007 20:57:45 -0300 From: "Juliette Dougherty" To: Subject: 18-year-old disappeared while hiking with parents in national forest Date: Tue, 23 Oct 2007 20:57:45 -0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000E_01C815B7.5C58A190" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6Q36RH83F4M5LU4HF3WS1B1D57Z== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <01c815b7$5c58a190$0fb418bd@vhoy> X-Spam-Score: 0.1 (/) X-Scan-Signature: 303e29529f30c23b95ea718537067fd5 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C815B7.5C58A190 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C815B7.5C58A190" ------=_NextPart_001_000F_01C815B7.5C58A190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit SNCF has insisted the industrial action would not continue into the weekend. High demand has pushed upward the price of a pair of tickets for the final to as much as $3,000 in eBay auctions.On Tuesday in Tehran, Putin warned the United States not to use a former Soviet republic to stage an attack on Iran.The strike is expected to cripple France's national train network.Khamenei told Putin that Iran is serious about continuing uranium enrichment in turn but wants to avoid adventurism and cooperate with the U.N. nuclear watchdog, the news agency said."We will ponder your words and proposal," IRNA quoted Khamenei as saying.LONDON, England (CNN) -- Widespread strikes are expected to cripple France's transport network just as rugby fans make their way to Paris for this weekend's World Cup final.A police officer and the woman's lawyer also were injured, but not seriously, police said.Russian officials could not immediately be reached to verify the report and the Iranian news agency provided no details on what Putin had proposed.Vladimir Putin's visit was the first by a Kremlin leader to Iran since 1943.About 80,000 rugby fans are expected to attend Saturday's World Cup final between England and South Africa.ROME, Italy (AP) -- A man opened fire in a courtroom in northern Italy on Wednesday, seriously wounding his estranged wife and killing her brother before being shot to death by police, officials said.Railway workers will join bus, power, gas and some state employees for the action called after President Nicolas Sarkozy refused to back down over planned pension reforms, according to Monique Ricard, spokeswoman for the French railway SNCF.Commercial flights to the French capital were sold out, while thousands of England supporters have booked to travel on the Eurostar rail service from London to Paris.Officials close to hard-liners within Iran's ruling Islamic establishment said they believed the proposal by Putin was a type of "time out" on U.N. sanctions against Iran, if Tehran suspends uranium enrichment. The two officials spoke on condition of anonymity because of the sensitive nature of the issue.Ayatollah Ali Khamenei, who has the final say on all government matters, said Iran will give Putin's proposal serious thought before giving a response, the news agency said. ------=_NextPart_001_000F_01C815B7.5C58A190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

SNCF has insisted the industrial action would not continue into the we= ekend.


High demand has pushed upward the price of a pair of tickets for the f= inal to as much as $3,000 in eBay auctions.


On Tuesday in Tehran, Putin warned the United States not to use a form= er Soviet republic to stage an attack on Iran.


The strike is expected to cripple France's national train network.

=

Khamenei told Putin that Iran is serious about continuing uranium enri= chment in turn but wants to avoid adventurism and cooperate with the U.N.= nuclear watchdog, the news agency said.


"We will ponder your words and proposal," IRNA quoted Khamenei as sayi= ng.


LONDON, England (CNN) -- Widespread strikes are expected to cripple Fr= ance's transport network just as rugby fans make their way to Paris for t= his weekend's World Cup final.


A police officer and the woman's lawyer also were injured, but not ser= iously, police said.


Russian officials could not immediately be reached to verify the repor= t and the Iranian news agency provided no details on what Putin had propo= sed.


Vladimir Putin's visit was the first by a Kremlin leader to Iran since= 1943.


About 80,000 rugby fans are expected to attend Saturday's World Cup fi= nal between England and South Africa.


ROME, Italy (AP) -- A man opened fire in a courtroom in northern Italy= on Wednesday, seriously wounding his estranged wife and killing her brot= her before being shot to death by police, officials said.


Railway workers will join bus, power, gas and some state employees for= the action called after President Nicolas Sarkozy refused to back down o= ver planned pension reforms, according to Monique Ricard, spokeswoman for= the French railway SNCF.


Commercial flights to the French capital were sold out, while thousand= s of England supporters have booked to travel on the Eurostar rail servic= e from London to Paris.


Officials close to hard-liners within Iran's ruling Islamic establishm= ent said they believed the proposal by Putin was a type of "time out" on = U.N. sanctions against Iran, if Tehran suspends uranium enrichment. The t= wo officials spoke on condition of anonymity because of the sensitive nat= ure of the issue.


Ayatollah Ali Khamenei, who has the final say on all government matter= s, said Iran will give Putin's proposal serious thought before giving a r= esponse, the news agency said.


------=_NextPart_001_000F_01C815B7.5C58A190-- ------=_NextPart_000_000E_01C815B7.5C58A190 Content-Type: image/gif; name="footer" Content-Disposition: attachment; filename="footer" Content-Transfer-Encoding: base64 Content-ID: <006901c815b7$5c58a190$0fb418bd@9NVS2KR> R0lGODlhigHWAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/ /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBm AABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/ MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/ mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZm zGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb/ /5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZ AJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwA M8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZ ZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8A mf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+Z zP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAACKAdYA AAj/AP8JHOiP4L+CAwVqS8iw4b9q2yJKnFitosOLGDMOnKaxo0B8AiUh9DiwX0dtIx0qskXyorZU CRm1ZIgQ5MVJJE0mTAnr4MyGKS/e+9mRI9GhPgX6M/ovW9CfSDHm6zg0atKBC/9RuxiRqECJFr1i zCr240CZZEkyLctWadudVxvi7OjModW40rK9ZXj37bS1JG1ynNaXLWCxBYMqdmtzL8OI1WJNLKu3 7dOZhx3/m0fyMtvELf05Tdhsp7+nmTWrZpg6I77Bq+OWRVp448CtGGt73RZZouN8uOECja2Z80Wd AltbLpr2p2fiq5ULhW4a3+nrHVPqjuv5+b9XDidu//s3eTz5fl09UmucEaF36kRZFsUKf/lP6fVb bsdMcmr26/7gIyA1BBYYFH4YBTeQPBopmNE2jCwi3jQRxSKZY0i9lx9J8jmkIXx4jJIRgh1JQ52J munmjCoJDgTcWg4OxF5CAuJT4HoFTnOjjTHS1xZI/glUmUfiFRkRehJZCEssCVXj1VDdOTbkTODR dNGHJMnk1VLYDTTllfe899qVNM7o0TRftqdRXzfe6A+BAjkpXHKu4dgmNfcMOOA0etr4JkgyAdaj QPuN9U+Qvg1k5KK8UQjRNtMoKednFw2GZaVlLbIRU4s5pqVjmeF2D2EttTakmaV2RI13wFEz1Ytt yv+olVkNIfcPnzX+yWObNgqI63qvEbgrSq+BlOaal875GKPMTlNRNdk8CwsjTBL3VHMdHUsUfsnm Z6K2DWUzja0YtSYaqppldeeuBeaTj41GBRhrgDTVaB2PbxZoXb441piMsL2yS00zBDejTYFN/VTg PXdN4w8skzI0JKMUQiaRP0Y+W402GsdC7aN7vXnrcOUSZxRuqKK74UWonAnuQD2cMZBuY1I34Lo3 unjrm6CxRq+dvPLa61L2ChgLKQs3Q+A0BA/cjI4AJ4tqX0s11FU2zEJUsTbboKTx1xVxbGEsS3ps 4Xid7DUaQ2lFJsbbYvgD99tccDH33XBbCJFtDlX/0+3Kbd15Z0MqazZ4mUUL6FBlp61KTSqp+DGN 5EADDLC9Owp7oypME3yP0gQ2re+f682U7LgJRUQN1kbCwltFb1ZDDdhfj0322GVTK9k2aQu0hVeV YYvbNmLcgMPx2uBg/A3LM688880zz/Q0N3BhXm2FAy6W4Nx3P5tX3LMXJEOlg2QiNZL7Ic0U7E8x eeX6Jh6s0/Qv3TnUO8pf46oz2WReSxcTD9fA8qyH0M52ZMsG7hC4pEY4sBER+wcg4MEOt2jkZQjZ BheOZzxqLO950IteCEHIvJ54qSwfcgU2qNO9FnLvHksj2Jb+AY+ZCK4fCNPZP/ABuVSIAkccoQb7 //qAD/dNoQ/u61f4MJeK0IEOfvoTUD9wVTT+zaRQiiqSP2j3LFXAjoEIvF2kbNdAjzHijA+EIEPU UcGRXaQ0ACweB59HwhGGcITKwwFM6KS9g0gnRt2ThiCpAQsXcq9zzQhGweB4lGnUkCRtkgb+RLYV YflhCneYgh/Wwyf0ta9965OcvHCWOWrgD1j3iqL80NQnK4YGgBbjGBcrYiFVhPGWY9PGLdPISwf+ LyHKYdA/GNEhjBDvg3dMJvS0oEzn7VE5n8JIt6yTEe45IxVPNOQhm4ZNgv3Fm+yYHiO9chjZCSSa bfpLgZoIEtJhUpMMcxwqNPlJ9t2hXwHTV4FUAf8srfTKTqoMaD41NLBfPggsvIkd2HDJ0FiEwXYK 7GUvz4gGNDoJMNhiixyNl8dmQu8PzCuDIpJpQnAVRFNq2tRf/tIQBzmxYI/LpiF19IobrRSRT1tp J75ZsB6monNtUY4hbnMjaVDDGabEppMKdMlMNpGTqUBiFqYw1SMmcZQC29XN8LGI/Qn0q1EbzzKW QZO/ScR1XntWQ9dqoUWMTaITRWMY0MiIbaCIb47ZaB09ytcb9OQ92zBhWxJxEMgh9UbXLJgzDtu9 aUBOafhYZMF4+k2nESwVpIAcD32Kzc/tpRCq6l4TtUKgVLyTcgVphlTbV9VU5ItHAcMcKgUkidn/ BtS2lwMWjjDWEIdp5F1fEc+zZKlWtjY0rnA9YyEYYQhGiGGujGgEpOBjiA32FRU3oF5f/fqllOAm EI4ZhD98KlOb3smHfkhvelHxNMlOb4qjGhVnydveJ+Y0eyQBbTULxNjSzq4ikbNnJ210yXqyb5PW uRxsbzY63AItWFEkpYD+RpYiLdS4sWhEGOHaiDNG94x/QaMDPVwIQ5hYDNGV7l0vogW2VLevrriB B7c7DcEKpzGAOIlHxgs5xz72vPfww08JdEltZGGqd0AFYSa7Uj0wjbOSXeRKT0MhU/p2Q9Yc2I0K PIWn2si0SGRfFjqRh02+dqsAs2WE8aknrKZS/7YEiqeNiLIVo1DkwhjW8DREnEY+M6IQHXbFnj1M aOY2F26GoAYyIuiQ3zkEGVeyoiG24NFpYFe7283usVCj4wb5dBrS6CGB+Bm5LDj2L6jog6n74Ic+ KBmRK82pHtx703TedCkDG9XKWvjUbRDitAhLRVVZe0SALtirwiKdbgkkLwa3aZTxk63ijPm/iHDt H0giYHGPazaPOTAbvBRxoaNbiGk8kK6GZq4YDDE3fwijEWxp45UKQulVoekv2c00Sf+hDemQiy3z DXUqkLoiP2hByH+JXB/64A9VS+5+7b2pOieuo5XaVOI68sfTMKMTEgmE10IObKvZ99Q3FVjVQ//s srJ1u+BlVxGV8LMTvwRHOh6RJCIU+krFigGPyMRijLs0m0QH3WE+F93DhmjE21LciOY6fd3svhs1 zugRLF5k0srEtL6hJ9jWrMXqGJlvDw/7hyOKQkeqZXWr++EHpeX0pkqTuCmpgYdvTo/iEh/VxmlF puRIEiOCISr3UjEKamjjkkhEcGnZh4eqJj7Bs82HjvYVW8z16SD2epPDYCs4Hg24dB2xTkQKgvNt /zzo1Opzis2t+qOPW+konlaH2R11vC3dgTsmCSEagnW+xmDrfu0IuTx+EbEb9ppqz6kostBqP5i6 ibCWRtwx/va6y93K11faP/zwHsC0BilkmTr/f28EuXwI256p8FOA+zCKlPfBcQJDajYOVkV2IVtz u12VNpytL1w1Dk51Qh6jBxEaUzYWAnS243qFNmIfNm7iFl1Jt3TTAoFo8Da1dzfTwDGd4RG7xxAv Bnx9BQsvcxErRhTzlQ1j53wI51jq1Wp9AH3ehH12h3ES93Y0CHcccQfC1xAlKCvfcRuMMHhNhHia pFtUQAVUNVV94FQ1F2G3VUl3IAp9gkRfhQr7Iy9ccRBGskWmNzYImGENGIYL6HpF1whLckYmRgVi UFHT8DYOZHt302FVE3pi8YEg6FF/tYHYtmPWcRdih2tRxXxup4LM1wdnNzASJ0kVd4Nod4M2/+g0 OvJKwAR4/CZ4gqMKhDds6QcSpkVsiedyQpNg/rRDOzINrgYLhVCEExYg+JAn+aRg+kNtFvZfYeRh kZJcH7YICvhhKBZdZpRihqaGY+AxroBiHgOHcBNdS5VRfKEw/2CHd6hMJjRF6vEWxpcKreCCT+WC 6cVqP+VN3yRIUHN9nYOIEXeDpiR9g+IQHicobcJY13RJU4VgBJaEVCVg/1R5RaMVU/BD+7JD/9AM U4AKAQJZNnIwuMZm9iIN9QeAO0Qv4+Ekd1YR1IBADNgIe9ZhF1loEwiMIGaMExh1EHhi8KYNYvAK xuhcyHhG5jE+fUcVlfiMlOZ7v6dvNkZ8Zf9xjYImiI+jggsnZKa0FJSlNPBgSjnVUytocXc3lN8k ELXgCvAhOIV0VOvXZb3SiVPACZ+0f63EROr1OEwghblSZ1bZK/8gCu5zT4/TL6xYI1SEZsmREhlT EQb4VhKFbkeXdAvoYfggBhmJRreHDCcmBh2GEhrZYcioYeQDKllRDTPpUTFQk5lmYysDOffAWaMw OUCZdgv3k0a5iKEzMH5QDDcVOdgkCkrTTeAogzM4TlE5d5tDlScHJ57EDNPADMYwRFzJcmMiRO1z B3xikDkjkKKgcV3mWkzjj6syYbNVELOFI8LBKHRpIbhYhg4YXVPnYRZii2+jDYhJV4YgDHP/40AZ NntvaHvNFUHrqBEBMhIj4ZjbJZnJVAt3RJkMUUwNwYwYQY09xGMwMTmslpoO13zNkA3guBSRI2RR lQ7kdwc/dZrp9WNWxprqmBH2WRZ4Yk0Bpoo8VE9h5k/Hxonb90S+IiBYqZZM4FoC6UMiEzAEw2Oc dCuP44/2MicWRhgJOHR4SWhFRw1LRzYP2IZ/AVeDSVeIZnsm2WEG9ZKS+BCPCZl89QohdKExcREm 5SBoMhA+dZmpcHjOhwqiqYKtdnZLOQ1nF6HeNA4RmgoOmqAKikipkAdw2gxGxWwZUSUjoh5+cifx SHIFoQi/JmZW1QcoYTn7k0lbYS8CqTT9/+hD/UgNDhpZxzkF6NMM4zUwqvk0Z4cKqAA5yxYjCPU6 X1ieFzloDthcjPAmFahh51lR7NaX/caqTWekb5NhbzMGyCgG2sAFjMBomFIWGhSfzZQIiVCfF6EK dVEyYsFZ47V9Afo4atdqzPCNFsemT9WTxTI5ovCCkSMKd7BJf4GCcepDolCu2fQjkEQgB/OO65eo nThVStiPhcqb46VysFWv6YcjAtl2/RiQKtcMBTZwAtIM0Gd3BCsK7LQrVvMozjAKtLSd1wliEdtc 3qmSR4erFoidhPkKiGmBHYsGjYCxd4OxFfg202A9gdEW1pVMUso8khmZfEWl8DFfLMhqRv/Zgn4Q Cp+5UulFfn1AsAG2rZDTdgHWRE+jBZAjCqhgrjlDTnwnJBfhQgEGplpRYPBaVZZqqDVySWy5Hita tadFnJIKEyCxr6l1WUcJOp6KD4iSOtrmc9Rpnej2Yc3VCGlAaP7gYevmQKhaaIbQhg7UhrXXCHmb q3C4RUqRJv6QJ/fwCmB3ESvLPDyQby4rnyHYR//wh9KKJzgLlLE2MHjwQ+oUOc1QrqKgXkOLTdbq Y6bZTezVtETRMwnRg5Z4XpfUDJHFpoJ6ZBzKm/XocjbCBIzadpDKrzCxotfkSZtYrjFVRWvbtkqR gf/1sL/IJaYqhmfkhg9kCBWFq3qZvYT/SVcmGb6Egas6Ygjja7hzE12QMoIC0YH8MRAri3VgcAM2 ULn6FgOCZRP9xoOaYXwRygz3EK3P+nYDE4XYFzmH9zhRGIWmu16WZcCiA7uV0hcc8bi8hgcIdrpW VVVT5Vr2tz9cu0OKOgUAC5w79K2+OTBdJgpMQHKQZ1v7wxSSxxvV9jrUC4ZkyKN9C74pBoaMMAY+ EL5nJMSEOWJx4zAOcw/akA1zk754kwd4sIYYizHu+xM5lhBrE7mUGwb420x4EEL6q8XMeAoMkQp4 +hNilw2uIC4AG61ZILqLyDTp9TQvcbqjMAqn6wem+1jYtDQ5UnHcU3VXhnkKI1oaPCBh/3aPVOWg btZs+HBJ+XoQXttlmaQ0BVa6mgSwbpdbmWdbVHRRy2J6EYt0KHZ0TUfE1MIIf8AIdlN0hkAKcLO9 b1NRb9MM6ru+aygGPlCRSyoWjTFUNHJvkduydwSzykQFYixY6+lG1ih2Peum3Wi0cpcK4oK6RPsS ouN2BcM5tdZCXdJbDtHM4yxaVpm5UyAIgvqJW1UjrtiJwDINbWrCAsk+SvtD7aI4esJmWmsj7qIK 7nIrSCEZ2+ZhGsmjFWWxGTYNeAB7D4Ri2vBn2ouYqoCqfIs3fZnLImsIPuAPFzJDNCIUKaF1yhSZ lttMY2xB0nQQYVLIagzNSrat6eUPEf+KiBL3EmianOp6WZy1CK8wDd4syNwjJnshtZHqSVMwCNMQ r4qHSgGSJyb3wiN3BwRjlWsJEqtyGv8UigpZI5I3Fc7gLsCRD6S3bQp4dCeZYrWMkcw1xUdssREt kkB6bhZ4gSar0c6lkh6dEIuVKjNDKqzREIBAkzBr0ob9sikNkAnhOHjlEXBkJgCsZDibDW1HfeNY IJeloC9BX99sIKehFo29PVIrSkjNPtPQPiAcNfKzfps4Z9OG1bvCzTC1P5bDSSaBGxYRFvfAGwno tyaWvdmwyrCXqszl0B0rE+Cbkr/4NmkQdW2Yy3H4Nv/w0WIRL32RxoudXYB7A4fd3d7/bdgyCxT6 6RDoEtkA24JZUJA0CLTGRzD9hnZP0yZZ/BNTgl8ijRSjvSq6a2Aqp9r115a6IlsyNcHRZi98Mi7T 4JJyEjHUO7ffm3QVCG7R9TbZGYFEXHSxkLfcm4wRiKpz89zqiwYViAYWLl1+UTMNAb8JsQqGEJnT 8NPfHeOHXUkakYGpgZ+VYhQAPLQt2AfSN4Ox9lhSBjoQ98fCMhDzbSgJMd5EgQakJVpmhpUe6jjG 5lW7snIRHN9Bk1teOyoEItZZ1BXboCC8PTZMd3tFZ7Kzx253q3QW22HedkbHeDciXoEqGeJLt26M QOIWa1CLqyHJCrUt0hBLpQqGvgVb/yDjLgsDjN7okek37UHOxXQXn62l0Dy0fUAI3ViD4RprrcnT QPtEPuIRTE4paJDfNP1Jw/Z+AdMP+lNx03fZ+ZMriVPbAOMijyLms2IecAvE50nEEcgIr7Dnbw6+ DLjnbnjKu7jLzG57JbuGSJfc6VEsLYGlRU0Fjo7SMeDo4V0WjTGHCbHj0tx8ZSrB7t05Qm7kQVHq oy4Q16TSiPFxILceXGaPHMpK+mNlp9DPMrzPs74jAS3W7jIeEXltuG070UV0cIMPHYYGgJvXvLzK Ube9hpAGz6UK4Tt76Za9ttzscGMDfM5cEHie1P034vwWib5dVgADf0ANv+ya8R52l/8eVT1e2Xd3 lNOjcQTrWJPlSkveEvpp8gYh71C+HgvHyFWFYPjTJ5bHkPn+ipi99PnItgIf0FnkJK5QDR3ocwbN CCEGe2JwDx2m8IaAsbz41km3vaf6t9mrt8jei2toAx52Cga9dOOBKw1SH4EuBsfT937/91wwKU+x RyNSOMoh7oXYjW1XX57uxuwd6qBnJc6MQmwRHKM2lW1yuvWI9EP0qUzfZqDcQi1nVHryETYh8K4C 5lNBC1GlKXA7bq9R7GJo8UfcsRZdyrZoYn27dMROaGgQ3NIAmIQ5HlCCuQ3hH9VgCH+//DiwQWLw yyrdI9O2JjI/XxGKs94Ijp8e6qv/mUF87R4gvRoudLoEkkn3yLtFuGxLnO/m5ULqRCCkX/oC0Spf /hD+MTsHoUlx0pE8KvIl2wgAcW8ao0aMDDISI+ZgIzQHHRZ0GFFaRIqGDEJsNNBgQkbb/n3E91Hk SJIlTZ5EWXIbLC44uLx0+WoaDpo1cYjxaLIfSWomtaUE+jHVUKJD/RxF6qePUlTUmjWb9hQq1KhU qU2jRs3fVpPO/AU9+VWkWLApOf3LmlZt1lR+rk6Bm2VKFrlT3GbFh29aXr748OaFmhUrNXz+1h7O Ki1rvnwfGedb64waY3+Mhfqb0ucjNViNPH++aFFMxmkYHaJJaNHzxYgFVxvURpAi/+vXEQcWTGir 7G7eJ2GlSWgTx7RXLY3T9JE81sl7YKf1LjlUW6pp2qZlm7Y06dKla6dOqwoefNatZEty7W3+30/o JkVVQ5y2bVa5dOHOtRu/7368WgP7HUYYvw4B5LC9HsvKMbWckayxahrLJ5X7/PhIlc4goi2jjXwY LZZYCGpEtYIAwXA20A4qrTbZHsIIookS8giW3Z4rSxqwtPpom1jSGGMMHhPiwodXkKPmhiCTE4Om 6qpzRSQanRvJn+pOejIboYaaJhVCjFIqqaP66CMVA8ULL8EbP2qmvX/8YU9NksSM76o7wKuvTrn6 aIavq/7aL6+0/DLwT8IAzcfGf/+2qeafROFTCx/IKuuJGgkzsyvHajyMpRF8KNLGs4TSKDEiQBaa bTZ/SqWokNkSaiSn3dQj6RUnUzJPxzRu7TFXaoLDITkcqPGhhyRpasklMZaTdc3d2oxSG/WYtbIo bV7h0ssus/ADzsMMyyqbnsD66ts0oWPWzY/siZOtLKnxAz+66soilbykTIsKfBLxCx9vAdWvz7we gzCnBxv7x1HIUvFnlFTQkrAPuJb65x4dPQTPNBRj44g1VBdqUWPYQi3RM1VLRK1VKk8qt6Rk/3nS pJ622eZWmWc27FYOb0oSH+F2FgOWRKGzkqSQSgJklX9kvLKoardTqg9stVVrMMH/SuokrGxg/WgU oNBzszmRmEk3lTmnadfOCcdTy158B82G37/86fNPR/9ZhJBqqoH57nymgUxhZ1JpJi1/2oXrqMyU RXQaWAhKsbVTQWTxochXZDE2j2c7A0PgtHHVJEe/FanNo1DaCSXOd+Rx5lu1mnkMbXxwiYuZhEsu uWKP7RysoM9DCWmlibL2y6axVQWxe9hJcHeRtD7p6n9Kf/4eZ2gFnaR45Nlt6M3inDSV+vCbq12s 3OYzX2cH7Qv9fPmSMhWC70ZU0YjRkmwyyNDC7OF3KXxum2kujcUrMnWRE3XqNbU54IlWEzIQWW6B tVmEZ8LACHwYYjTbqJ5J8tSe/1u0jCSx0EaPVCezaYjwRz6YxrB+Fbti9ap2L2TEz3jjNWWxLCi/ W5qXuAOmbB3mHsEwE2/IY8OypKw96gkbHu6zxLjUBWGE4RPL+OWtdP0LYAS7IoTu9j+RTEZS7aIG tghXqaFtQxvVmIaHCPgZBV6OciBiYxvfeECKuCaFJqthSrSXPf+ZJGbaGOEIczUGJKVQDC+EnU04 tMja4Y43T8LaSXDYluDxEEx3gppaNiPDG23Fgyjh2hFBwpO0SI0tSmQiE+XiB1n1xC+G2Uu+2BEM 8hVsUFnEpWUm8w8sJohd9/mH4eLSsv/FIhuYGiAcJRfH1YRiGRZzjYbeSBvJFf9igqu5Bx43IxLl jWSPKQHdNLAWyGmorkcJSYiP0gDIH6HTne9MyAtxshvo8WaSwhMemJw2PLsMRVKDWVMkwfkRQxHR MFHKYHrGwhNRlFItqUBlKlPpB214cTP3yIefEKMNK+bSo99i1M/aAhd2Lew+q6QRe6ACwC0g00Oe yUYcNRYyOhpkU7I50RotthEukkQsX/HHPQSKkm9+chvqVB01BskhMSBVZuwMpMyW6k4OIQ0s9SzJ N5OmNHwiRZ9Oe1d9juLPzQz1JEEUiNDghj+zgtKbPIGa1CAq0bjUdQpiKpjB8uqvvGjjMX71aD6a AbBE3W9NbFmiH75yH4dNgRD/LGvZKKahI0O4FFOuGCAz5VgQjXgGH58hUE1piptYDI1M4PmIOI+I o4+wx4PbaGrrxvDOqN6qnLXFbTutCpRP8kQ9qUDF76xlybC+axp3GqtWyNNWhNowoWN5rpqQuBZu fZGu37NPmD7yoLvxMrB/9eiDnEHYnzUmS2MMEyoclr/7oKJ5HgKgSxeYqZzCMY7+OOCmRsuIaZxh gtcxCGpiwUmUqQmrH1nrSNApVRPm1sFRnS06OZQ7cyX4H9T53R+6hJTidjg72hFTRbUilm6i5CoL Pc9VpGQuE29LFM0YqUTlclzw+WF62x3Yd/NRGcBe8W45fkzBmsMuVzB2pJwA/19d3GuSMGSjGmeM r17wIV/NtrE0LIpmiVK0GuIozlX4uHH1APGPEtNqSVaCVcuqESSnPjiq1antbBlZEwKzGC1b5aoY /UAXaYA1rPchW3JFjB4jnvVbB/3KItZUaDt3ETGGUcUYVQmXvdQYKzBDy4/vBgruGuLHfuVbPjQ9 aiCHaxr3aIY0ChfjKSCZiUuO0nPC8JUPxWIvlsVUI2pdZdFiGXKMsBwjDGEIgWgVTSMxGnNb+xyv HdgksOhVm9381NIE8p3CucFuGw1X4X61D9L4M6W1Q1GyoiUrziLijYI4ElhEd9vbiw+rU1mXh02B CnC5x6JIXY1QDGzAWxT1vv8DrretREjSd5U3XCLah96yDHo6Ioga2YgHma5ovyrydWehshx3B0UU BXbST8pcElgseNoOjnA8sV28kbjhDO8eiXCVwueTIiVLCwvdSNQiFmMbGlY9XyjQg1IKc+88K65I uETZu0SsiAWD/+uuSAL+v2Mc425fYRRjeiLig2fr4IU7isJSQcOSlAuAhtB1LGARi1HkWrOwuRxo XoNfjCTEZ5DljXo+HpTC5BGcJj+5IFMuBpjUhAvFgwfMeRdzovzjPtJACpycFxZ4k6fnWONWc4Hi SnM94zD8csXXU7l0+0xhXR7B+r41PZa7hYRga0p4tigJ9rESJS1kH0mhV4L/ELSrKJqd1RCvNaYR gtgd70IMJvN6I3SSlPxTuZUGhKmayBtUfwuwcFUxsnoPfOAeOr1ll2LvQpJuXu1q4ixPWlThjMJg LaWkJEvHu3iooPhB+SVBDKCSzkRqyJjS0yAErDiJffOHH9sbhkk62aOkP7C9tJChhmM0kYA4dJKm jHgcg7gN4VsRy7E7NGoZ5kMwsIjAoZG/f4iFdHKw25IqCbMJf8CBG/A0xQuKhkMxbgqLoSmP6qIG VeiHSHqO3kI91pLBEHS0eJM0cZqGJXI8uoILzBgcf1o3nxKJu6GGUZA0Kqi9ogicoFA23xqJlUiI VxCDZuAUEwmVg0CnWMgd/xphvhJMN6p5q6CABQ6RNmt7Jy4gPJswBCF0k3GZoaBww5wrQsMoBGc5 tU8aOfwZwpFomawoHmcoHvkgHOxgwkoEDyaqvcNQBUP4m7aIqLArCk3ajXtYmdRyNrAwoxRqJDHQ hncaNoRIDXhSiOVgRO+LQ5SYBylMiarhjW0wBDrErZRLpJ2JwRoMCkPQNqHjvi50k/KoPK0QKqzp O/xbRJ8CnR0sHlWAmhi7h0qsxPxhBvBJrKMgGyrAg3NMCgbMgyEynbLQtiLCGitZCQsSg1dApFWU RUagRUbUi5J4vX+4MZTAniEUi2r4xdi6lS7AlRuIp2G0icOrMxkMhMVrD/+kMSt0KzrBoQZnCSUp CaouYhZfYDFAMISSuI6PQBpHpIa/eSjCuYci80ZvDEe6agY8SIqhAJuRyIN/4IKJDItTqEaVKUWS iK8BkjB0WjsKixgQbA+fVKgo0bmDVKdDOCfCI7wWsj7sK5j2CIZgqJEmEYlTFCLm4sitMLqNzEH0 wMEMcgZxAIsssDOVZEm1IARKi8l5S6WZfBhyLLeRsEWgKKigHIl/fDcaZDEpGTMTGwaT1LwptKDB 2xVfeUHrYzlvIjtm7A3DfJVl8SQdfLSFIo/qCUigeIG4TIu/qR/JGKNmuMtKPApmyEQVQ4m90Eze eEfB/AdXwAbcfBUQPAf/XVQWWKmGQzokH6CGYuGBMKDMiKRGNfnLjxBLoFAFzEQoHPFMdoSuhJKS fqjN3SjFVTCaZzyMMcKHk2rNm4STDwyK51STfSwLgZKSeYE5bYhAc5m83sAqssgGG1mz4cABF6SJ 6kNGpSwLRkCDsmBPN1EFv4MOw/gpUFq3n0Ctj0jElFA0kxhKuIrE/kOBX2rNvVRAsLjNfziGWeHN Ew1Lk2CT9rhQ3aFOD+o+/DMELvCH6nuFLajME+3OZtxRQ9tIkWg/wQmK6ASKDFWtlKiGbBQTwxA9 00usLcE56BjReBhMFDVGk/gDLbDP3KvPsNAG3RCJ0TSJhqOGF4hSWgnM/ylsN8XJBlfp0godxY8o hBcwUzcZOc38x1TQghfQ0ijRC7QMJUYkCbIpizmt0zHlLZ3DEg/FRD8Yj2qshj+g028hzC3lQqBI hRcYUd1ZRBDsORjo0yHdGr+LwC5FUFiAgVR9gT/YDVi4hZGwkntIKK+JJILZUz4NVSJsnihBhpLY OxNLVRhYVTv1rVRwhUE4ii0BHepcg0coizKl0xcIRF11q6DoUlSVEVXQ1O+TQeocCS3oU3BN0ZJ4 ikTVuV3dtnuogRa1T2kICdDRVqt6zkJghm0SVxWtnvz0BCE61KC4mm8pMeU5qCiESt6I16CoBhjY rXsFC+br0VSQVD4tCf9tTZRUgAHmDB2ySDYEXQ8CvVKSK4RbPdOP0IJC+AgYMNnUQlR/5dTomAY6 1YKRRQlx9VaR0FM6lQblsVhO2iOxKFNVoCGUzSr1IItIfYGXLQSMJQmGpZU2YY9y8YerkVBEvQeB +MjlEQoteNmSHaWdDYosJQmhvVSggFObfQFR+BvFKYk/YNXWclCf+CRSeB6eENQdhZUS3S5wXRim 3QxpZcyg7C1whYX/4dqJJUJUxTmflVkTA9cFnQZUENuTiY4XqIZvMg9joxFUbds5Vdo7Q1ySKIRS XJLmGUoacT+g4ITGDQmLLYQELQkYaBl2pZVtascbClVQXbEuuthbBM7/M1koZSsxP9SCBf2HOX3H P0jZJzlSKy2E3WWZQlhcApPUnuCKzw2KVijTXP2H4RUJW0gZ77tX81CPloGehDXZn0jYS53eb9WC DH3DQS1YkRhIBiU5if1WphwJVdAG4v0IMBXVknBdkwzVOSXeJ+FeobGzTEWavSgLw8wSkQDViQ1V svCgac1b7Q2KCHaSTR2JVF2Pj7gHzgXEVoAB3GuGPyhBNXuBQsBBlPCaUwOdOe0JGsHgsRAqrZgG GBiJaljh2RxbkliHH0RSDWZEC74OyuVWyVVRn8KHQjDgF2APsUBeObXfrWxeYR1ZatjTPOhTapDU oeDTn3FiLDaXF/Aa/21NWd1NFFjYU7FQreZ9gRoYWYtNVZzTUx3eU+JlYzrV4bOq4uIFnZuFAf5F Cz4Viz192ReA3fgViT0ljJE4YSrW3ivuV21dUHzYY0KO2GngTkFcXyuJ1Pzd0xIOwexFST6GWSVm DpLgvnE9CUdWK0kGXVVdmOdg2EwWCVW4VUIeKqFCQp6TQn9wYpFQ5Dtbk0Jg1Wq4VS0YGjSqWL+1 2ZSFgZ1MBWTGgpAFqT+oBn/IVAuOEh6GheaYU5xbUGXuCWmIVuX9A18ohm4mIhS+MGlVZljA1TSG XishYpNI1TqLVC2lhn2GVkW2jhcoZz6dUBM127bFPWVO5e3S5oiB5v9qEGF/iFbQ0QJWpY7nmlOT zVCwTVhmwAptUORoJejihWYfVuX3TYlMbdvzWOYpfOhufg4eTtlMnVSUvFhlruGT0KpI8gd6/pk/ ns7NQOE6xQdlbuQ+BgmfrVOT3dNBmMI+nQYtUOoG3d6UNd4K2V4ZmQYUpuqo9pqvVpZQ/Wo4UeSF 2Qknvg56XlyRmFMtIDBUuAO3NtNkEIbtPaPn+QpttUX1gOVREglYKOrEDdUcZl+VFWtFOVQaFNY0 dusBfuCv2FNO4tun/MPtPWnfKlOcQ2qSVWpL/og/YGOlbl7pEgkbaTj1qGI9zaPm/RYtSCuansLP 9lv61AYYsGiQilz/q5ZAGW5kroZgskYa2Q6JQkhjIs5UqWZjK0bilJDUXN1st47cfJaS5obfLvpj k/Btf9CC4Z6GNJZtMsOHfNbg50xYGDjT6Kbi44buHkawKdm2atA2ZjNlWoFmLQAp9zZpTtJgbGiF kv6+oQFK+OzgPmVtIrxX6shlAP8Htk1q7G7pA/8H0DbtmCPo6cFvItRWOw5V0PYLaFZvzAYdZojS ynbpKnZtusY5eg5d0MlnhBaK7C6Xe9WGDmcG/t1wClUFfCBkbd1pnaNT/vVtKsa5MnXsTF1QjARg 3l7ieP5xkhULCadwZ0jsNelXyPoWIp0f+kVpktXSqS6J8L5okZDU/5/52eA2W/4d89C2bjs7WDOh oeb9mTXv6uYG2wo5aSJWhZxUbMcmqj3FuT0diUJwhWmwESQHcj9vLZKQVEVvE9nW4pb+g54qXtyW bunVb5Tw8QcXCxGecAbf3qpeWejAPdMKbVRQ9B127zVv8OauBipo6eLNa93t49oMiefA36UdZK2d 2JIO7zKl7W/Jcc/+mV8v5ndja2Y+j1gqwBcYmmw49n8g4sQ2cukuHapua6HR1rb14EYma+eN8Z7o 7Fe+chQDbWP/7C3QUoneXrguiSpfchE/2aoG10O+2DZhraFoclESCdyjamkQy3N3b2Bf8AUthJ6o d5IYdu/rh6Bx4/+t7FGSldhP4lxtlFgtBlUt9uLm/mtpD1VTxnj8znDKe1Y6XZhvkm38dvaj0VqR Z2k873AG31MbAVdphdgZdO9U/RZUlaEXL3OLzfZQD/qKT26Wz3j8puikBdeUf9lvKe1Vlvif0fnN sPSTZRO4MYxV1enObQ8a+iZAZxkbUQ+il9jRFnlq4NyQVRShrfG25eGg73eVVemvDdWvx+3hjVaV T+UvbncQ1++A1vvspsjNK/elRm8GhFZ8wO9EVnkt1eVhJfZGjlZVMFSFzV9odpbM/5bnRouqL2TH 5m6YNUyJ7uGGo2pl1laYhdaBBdWSBvRJR3RU9XNxFSo0Z3N/9nz/rXBseqbTWFe8oQmJOM/0d7/7 1M/4vMfse91sBqzxyJ9d3qrNVOCkVpZ4Gh7W7CVekQZV0i/4b71+PiXkag0K0D+sTx/5PWXV7KXh Og5vjwfyLJCRPVX0U3PshM3VW33ozUB0RvzuD+6dTQeIf9P+EVSliqCWFwf/Jfzzj9oLbQurvdBC rWDFgf/+vHgBIxXBkBRfVNMWstALWCEZdvyjkWAqhSv/wdByMNvMnDp38sT3zydGLSsvplqYECRL hxBtEuSI9J+qihepJaxYjac/gvd4zpz2kmtIf1lnmsRK7c8UPxtfgG2L1e1MsXD/jf2XyuE/ioXm 7qwGA99WuzXh/2qBsXOav7JcEy4kCEsoX56B26I0+YcqDJVuC4uMu9KZs2aR4QJFKDPkY4LZFI8e XTey15WTc2adTfBrV8gIDecM1Jr2b75UD26FiBh35GocPV6eC2MvVuQzqcGAEVuV7p3+FAVfKW1l qoRUtECH+3zoSulDSwvsLvCe348ws/+eZrvta/c/CYodWzf/P6z9Uxx9g/V2C1gX/YPGb+zoR1Nj +PgzjYJv8dVYW6rAcBVP2fhz30zVoFQRhjqNtYh76o2mYTUVroSTdjv1E1Zk/bwkYkdaaAOjTgOp GNdAID4IVmySgeUTeQ9t8w9KT+WEIE9PMWgiV8G09lVUHOZl4P+ROU2TjTTZIIddW9UwxZU23w1J 15BqzuTMdPiwl5OZC7no1ksVfjUnV0K+KOBtP/Z4j6BkHTmhjQCm594fmTX1Al765RPjmlqFtFRB hWkJ1od8EbKTUB294KSFwWlT6Ggz5gSUhHyGlNA0HZHKl6Lt0chXeXDhVCubRurqnqvBjUgila3d eWtOPI5mn2NVyQebfhxp01ylPSqrn0ZbBcbIaC5RQw2vcCmq6m/0tSUNoIt2x2FW4aoYbHKR+QPv aOley+m99LaFqrzpVsrvXDCSi880UP4m4Upi3SMXsjP5yRfCps40p74EHUsbvcz46l6JcGnkb07F 8HTnvXhOKFv/griBu98/sIDs1pwvuxcmWNwGJwx/zLbly3Si9dohV85sqpOfnbq1Y486RbzvXNJd 7DBByBxTLdX/vKOTmAGGVHK1cq3MX13qhVvsSukOXbVjwSEzGs+jeciVWEuHpE1d5Casq8w94beT Znfr9HRIFU8s+IN5T4MK2nD7k2u7nP4sbuIE2Q14qbV+OheK7nGN37EPR+54SKLM1Pdtrcn5uXsv DzTr53WVR7jRD00KemQ+Q95wSIeshA1/LNua0ytYAWozXa0G3Brdh6EOFoi22V5tFlkA3ZqQxlCe oumbdHcRqtMYM42+hD7UmjTMuLnTU2GshM/XK+lOkCuXjqUR/71zWg8uwMt3pbT2bkfmk/X0txJj 4IMSlFDQJqZBCdE97h/G6N8/DGhAoMzrH3iY2CYMCEF8bMIYM2mGBA14kQwukCd5y4kxJIhAAzJw JaLQoMUkGLudUIOEG+xgTprBjH5sAigvpAQEtxeSM4QkhQYMCQiBOCcQiqUJ/qCGBJ/XMA7C0B9G 7OEHNYgwEopibA/CjREPSBAu5oSEiPlHEikhRaLZEH4avFMNDegzMvIFhM3ARwoduIl5qVE1SAQi QbQhxdfIYSWbEIUx7PgPEnpwJyBEIyXA18ek1VGNHaSEHn+Cj+eB0Cc4xKEO23LIRPaRjh4SCzNE IwrtdXKRjf+slh0v+cQ+rnIoavSHKPCBAlByAjdzGmUzpiFISniyhQ8p5UAe+BMxQsw9sUxhIZRZ QE4SU4F37GMruZJAr6ixGacAICZXUsJHdnKaleSg7waCw0COcRPam8Ym1sgTNQawNOvUySeNkRVl 7mRzOumk9hgxifW9Eo39E0UukbG2e0xyns2oZ0juGUOfkPOgxlxTJ3EGwCAOUHsUREw2siGKYPot JPQ0CXuaEUR+9iOcBOGgFy31IIDupzybUFYHcfJA9giSK/ZgBh4vcjqCXIGYf5zJOvkJFyjWciX9 oIYmNLY1Y0hjGeaLIAlt97RNSGMTLoJnQW3pkA4O5JH9FM7/Ajm6zK9AkRrThCJgFilPQ7rzTjh8 YkRFg8MCurWhlWLqJnC2SHcqka4Z7CFcx9iMyQDInV69zVgkqsx+8DUk1qyVYoqUk44lKK0hCc1a DdlIs76UEtpQjCuu1Ye65vAJAwSiCF1JENIu9Ye2UyAWA0fMB2YFm4/VGnCoWliBdPAZ94hrEbX3 hxfKKYNQ+w01bFtEIOYHhIeEZF5D4hudPHC4sp0ObP94XbRFV46D9WQQ3Yle0sbTd9w9LFCS6CIm /uOFCkrhcVkzO3YujCexGE15G5rCPb62uS5dJANB9oru5naZz0uhKjGZQgMvNXDxjCRdDSkaY5jE FKW5g8+m/5HGlxYRngwEKyl00tALO/e5CeJfNtu5EpWO8Vsube9snXDEmSRyvN+9lFFpTOMfu6V9 lHzphTk42gOvE4RQzO6ARsxjlRqTtg7UoFEVdA+17vd3W1MP4TgY40XixobhJJj4/rhjF1J5tn7N 5DJHiGWwkA7JBWQNaQtoQG0c0RTZxQegJmO9rhKEGRI9KgrVGpJ7XMw/q+ohM+lC2/YGgolGjeBc eUwNpR6an3zFsZXJxjwM8rWptDU1MS/95pkgxXpNLe3FSFqXxa5qfiYsmeA4WFkkck2a3uOLq1m5 arPumiBKVQ/xHlhDEGbDnTJeiS0yCUXRFBAo6qHnKBIY0f+wjrGF0pykiwjWshg9NbnLjuSpCOXs 0GHxCXtsb6idas0e2+7QToYkPlaJXqbBzNwXhiRIJHrvT4om3uChp0qbAcJkHriTYmK0tgcbHPU8 TNn/Xve6je3RPlLCGJxFFsLjOW2lUaIVrajlt32mJkKp6IdipCIlpOHJRi6Jn2m0nWLsplIYbtvN Phk5kg3I7QYqLnQSpJt9tChbmGMRiuYFy84B2XN8X9m8TA9fTPPjcgU1YxRSbzLPnb7qHLaxvpHE aytFkQ0gboWDiGkwrR5Gr63/xIYzrzsLIWnAP0xSHo40o9lDSA0d/lzpgBF6SOx2JLXmb30zuRaj +XJB4OT/RPFECtxLCNcrPbUlgDo5oVu20ngLd+W0pHELjDwPJErhLiTBK1Vw0KmfuvhdUd+rs+P3 dx9+ncxLsd9fWBg2l4v2jvL1iildxgIo5H9+TczH09yeT7v/zSXaAuxO1sfNelvxafTqAv3EcrII W+CvpOP7H3Is7zGBMB9A0jlbTkwCfq5oHvgC5GzepM8T768JH8rq/U4YTkicz0xMTWvkB6D4C72M xWy8hhfVyn3o3898iBelC/8F0vw53/WFxCoYn2vEn6LM0AbSRbp4TlsEhvoRxDwEh4sACphxhUb8 x7LwRQqChTOkwvWY39ykDfIkD/bxW/FVDQCChTbkoN6k/4eizIkE7oQo9EFX2IY/8EgGeomNEETw +FN3nBE7qUtcjE1+1MoowMkIos0UxkUZ9spLECBdqArynSGtYCHsDcTyiVql3AMUPs4UTsgQEkQt RA6FWFbZHIY/oAA1pAIK/IMfTAEgjiH2MR+FEKIhIqIiMuJLBMk/qKG4KcYQeCAheBE1QOIhJiIX 1uEPfhEgIkddfCI1aEMoTmIgEiH9EY0J9khWXMsctos/GGJiuOISMuIOwoViRKIo8kUHPkgDkpiM rMSUmF/8nJYecoUwuiLRPUgISuAzrOBcyMUXukU0esb0KY3D9KJA8AuYWFYrLmLiuMgTuQvB6Asc AhdMnP/jhQxJfsyIu8CNZ5geWHRjEJYj6rzNPwhDO1BNDPpeW/DjFn7jkc1iPE4BCqAAUjgkCkzB t0wkRIbEFEikIk4DKEoiNfIEufSiIUpkRD7kFJyKRT5FRj7kQKgiQvqiN0KjRV6kQJhkRTqkSmrk Q3TkMLqXQsIkeMxkRHLkFDDaRE5DTprkThYiCqhDT2Zf6I2GIYKEIVLDMCYiNViCWqxERl5EWgwi UzKJuRgLT7iJv8DhVNoFIV4lRb7CVmIkRf5DWrikPELf55xQWlalHygIVqLAWxJEV8rlXvIkL65f +RGEF4zhneTlWk7BQCTiPfjlTExBE8DJXIJiMQyjG+7/RGk8A1xEIkFA5EOOJiGiQCdMJlIkIiuG ZU+6B4BkRQ3q4CKC5j+IJmmW5lOoxBSkJkUSJl14CGJYoP7glUyGhG2S5ieSym4SRF+ypjTeTvKF hCAAJV1o4XFKAyqgQGQqZyo8Zm86Z/2RBQSuhGcSIW2KppMkJ2oyJ0VSyEviI3zGhRomIzquziGG 5ivQpMXoZ8ss5z90wne+J0iOIliQwZWAzHlOZYWo50v4Z3MKKBACjBEiByFcDjfeZ21OJU4UBzNw 51b0ZTZEY3giI10YmUy1BVDkJ1XKY18q50bu5io6J2S1zzbGp1OZaIwgV1CmwiIUQvCwpXpypSL6 Qyfg/6BvEondBAbyrUG1MCYi8mVvIoVGZORDwOiR2ugEdg2a7EQsGEI8rqhHIqI0cGQDZiSFWClS huKIkugRomhDPiRfPiQVVKSLEuVOagOELtpX7OFtEIqfekcQ9gn6HKUrxGlXBilGMoOd0iUiSs/1 tOTvtGSX0ZApqqVEKsggTgNFJqeVtMdKTuRS5qmh1GfzfeCPLAnceMWlMqdNUgMqPIVJTAEooAAq KKKrsqYw4Z5dNg1nwsRs+MQrIIWW+B1Gdueohh7BvMbmdMH7HOA0GuIU+idXPCqbTMY79l8wYqhs BkNZaCrrTA8dYinkvMbo6aLwdchY7KY9yKB4OuvxaP9HkGjrx+gEscrlfC6LuJXO9aXCta6nm07H jNpK1qwftgQl1hzsbH3r/l1g67nFHn5JhdHmsfpRsTqVQR4MwWIFxQxITMUmdZohuOqPgiheBloe FuKGSQiKv/CKGKLOEirKwLaFrv7iP2Bhv8LFZPgJFvqE4uXrx2Yh4XzJcWymZGghjTCk8qgLgHCe vJyVTnRgy3YFIERGty4Pv8wsPKLNNNyr/enppSCLOP6sw8oN7GntuXrZ0Vjs1rSenMzLUPXHT4LF 1IbEI8RFpKBt84Vt4kwqccakACmhbKij2A7u76TYaDAkoZzKqbAfMG5poP7EQJQGjr7ib1ABFaxE 3Zr/37fq4XEQ7kxgIxLGX2TcazbET82abq+mrmwOhd4+SMzuxMPAnweWRXk2k7vSRX85brjKxlgI jid8TnhO7s+iwl/SLOXChRMGR1bAy5wIb1gYrS9+iRry6Wa5hcdC5/5NiIAw3/zpibIQD1f8rtgS LVl+bCjMRT64iLJIx30Yoec2LOy6BS1k7qHs7kw4SNma0G8MofXl78+6rwbOYLVcr6jVINK+r99G 5a4m7ZHxRL02cFugajbCINFQzX8cMMDyBSB8XGtkGsoQpAA/boJEbbUA8PIw5AUybBR2Bvbqr/+2 LnDA8LQGBwfPVvjNBAH7T2T8nwjzhAS7BSwYzEr8//DXDi4GX8n+6uv57c0Cu9gHl/DiAktbXI/I oBA8zC1YXIV0cO3EhXBOOC9cAEIO/wYpPMETyK57VIMezIFrdUfmRIYqmDEaE26wkPBHesjN3nB3 wMM/MMIb5wQg2HHuVR4Iu7AH0kYvWgEp3CwgmLFBWIGKWIGWhAvqggWPOIMVhIQezK34dq1OqA9f 6AGHOMMZ78QT1PD1wYsBzjCt7J/gyDDeEoQiI/AmJ6Qe/8akEoQan3EcX0s1lLEZG+4/1DIpYLF0 qIIeDDLCggzEajJnJYMwn+iQqEImfyQCJ6Te6ugJdknGioQe8PIp80QjhzMsUs3Kdger7IQoG0TN iv8ENRxEHI9yKXsJblhBiRzxAIbIE9hxNewzgfqvOmOx8kJvIeMJUKyiLT8ELOuH+6rHOnOwFUzt NCRzW5Dv8niRFXzzQoxFYwACRf8DIAh0slyKP4MH8W1fSDRGHOvESi/aXBBOP6MyfjDsr8Qduybw 9dUoVwCkTmQ0OecEKVTzGItjNdgzEw9ocDjD1KrxTKiCgvw0ORf1R1PzE0zDVax0HIu0N5txMsex KvgDKcdGNTTyH8ytRxfEKfezGZ+yKjRDNWNyiOiBKOuBNPzyE8xtUT/BVK/1VexySk9DODcynKhx JpfxRfjDLktyXliBXqMxwHDxUVOwAKFi4GCNeij/dV589ErEtBJnthxDBWOHcy2DdIkIdhyXMjWr Qop5dUiM82B/M2LH7z8QgRvQhp9UctCsNV//gzOkdkGsdjWHwQ0AQlEfRB7ghUkgM0GcMinEsTNo AylohBpfBTkbtUGUtFGDdFGnWD9vth5k9Ab7AypwNiZXAzUTRDEHSCb/8lmD9EXINSAAdl549Hqf MmJLMilfhR6oQj8Lcg877W+YBByW20XHojCszdr+RjyXzTSUd1HbsyiHNG8/geGyc2tndTXEdDHf tXk7N0Hsd3EXdTU4g1VvtuSE3k3zzosFdWtXc4b7M2YPs+Ey9osPzX0TRH6bdxtnt2Lnd174s47r //I+18VKM3VKk3KKxfeEX4U9B/VVV7MeDASTw3M1V+dZW/UTZEU8T0NI+zZIa3UCv94/t7Larl43 V4o/tIInM2x7z0R2N7JBLPiCQ0XLZjg19/U+X/dBBDmXCzQgRLc9q8zuxS1YRHRIGHpBVLNRV8Mq DHY4nzcprzVdLMR5D/NS+7MqdAFBtHdLyzha58c+93ZTl7IVZMVZx/F+H/pC2Hc2+Phoj0U4y8VV eDSWUzh/ACeCo/Q/iPl/N22tAAw+n9756HRrZPdKzLlcf3g1x/FejHVOjHalf7cmK/lPq3X+8ApB w4UznII8N0Yt+7gqzC0pf/g0qELU9vdiX/pBNP/yL1uBoi/EWSczOQOClrfsfpPC0Jx1Pw9Ekzcy jps7ap9xir1CNd81XUytj0vEu193X//5pctuTJ1WBh5LFV4s/AqKCgPhiszzh6v2PJOztOe1Fhj5 TGD3qi8EYKvCPYzCvKuCVcMHILSQn1DcaNjzdqvJnP+DPW8wOFczi08IICi2ZaW1RkPFGQf9Jvdz imn0XMN3TIuyFbzz3BJMSGv1LBc5c7P7ecczPjyBPa+7HsRCIydzejt3VtTy03u1iJ/6E/DCOXB8 r/OHgPjgAQrK2ZrfnnYP9U5jn0D2bbh7MeP7MOv5l6c0hQcyhScz3OJ4KZ81WJeyNuz7fou2QTD/ g8tLcjXIgeHe/YBAMFwAM4Z8s9f/xGLx/ClLuM7T+z80dk6gAoWDO4cH/azfdRwbtbsfBCkbNTUY +2xplpCD/Y9P7WlvtNdzeXZ/MyCIvV5T+vKvPu4bvFoLfl4HdpUHOE13dgYPMnu4ic5wCvxNg6pc P0vfg26v9VKLPoYgM4fw/j+0Ai0YvRkDgoJoQyYPRO7zN2OL8o8/AXz8OCqLP0D8Eyjwnr+BBxFW A/TsHyBAAw0i/BdR4LR/qqxI1LgRIbWNqh5yFCmR4siNpA6uMYLQokmXI++9lCkRn8aW/2K6LDmT p8iaPV3qCSkQn0F/2ga+OnjPHlCITk3iy6kR/+S/fP/0oOTYT6I0oRWn7Rx4syegalBJQk3G0R/Z sWg3ToXL8edBt//qbhQ7t2fYuXIFPtHDUhs1pAI98lXs9MnZf9WeqBIJODA1vxzvHuyXWaAzyQcj /ik0MyZnqNT2Gjy8+J9pxZQPFvIjcO/AvD21Wcw2tzbH3QMpO2tcSqI2Z6tZm3QNNfJjK4MxaySF 73N0p6q0Pn159+ZyjbdgsdTr8WZ1tNpgi3TG8zbQxEBf/a7IW/lAaUslAmrMcf1ifMJ0Sk4gjJ54 IjvtNoKsQLysc0kYdgTSzwrzJgqwNY1y4kpA4C48KBWTeuPQu4P6sxChEGl6yZ+i6spMvg0rlP+o xIP0KPCJoWD0CxmXRhyomhmhIqsdkd6zC8aRWvpNLkks6lGmIucbCKkXMSRKHo3QE6gZoC6L8SAo yTtSTITuaEKj91DzUcDwtlPMSaB2GpKtqNJjjaIVJZrkHw3tFA8h5CSq8yBAAWXrJn/E2ktQHtMa 8zS02OQoUrrCelMkS3lCUaZp2suRtks3JMuxp7RRSqNOD6qpUChPHVSjHvZC1aVs7topJk0dfStV mWJx6bZCj2GNM6lk5ROhSXGFySlanUIxWbiueiqbQglyltqZDCrqxDCqrBOpRAk6sdFcRwpWo2f1 MtYogSYV6EphU+W0PoEK+XAgCt1zcxpMeSr/48ibkHIttZrqfKVdjhY5mFX8Rv0HqWt1lfKfPxCS ilyIsmmrpFGqnJOnltAFEbSGgKwwp9k26sfY66bZz0MCcfz44kSSY+SfF3HdqaQ6F271H5tNbNgk ygwyL6KQBwJkxiadasZchOo0SKEFGaUSLreoseLAT+vCYyOmodLjrLtUuam5jkyy+msx85IVIUYs WvRcp9ziwhB6Tb0JaCSdilamqSSRSeu3+B261WoyGgkf4RzTrcO5DqumRmpUORuiavCxUXOhvURI 7IGWkQgjiQ96AmJ/bjUJuWshBgqw29wed6ZaTJVJ02WWib2nwGs2SfLGKi/75oNAsvHzl6iJ/3kj fPSobuHeLErN57kHEptyibK2CJDEsVobIUCgEyh0z+syRL7KhxcJaaiS5fc+iRaRRK5eFQMUV92B 2puge/C/R16gxKaKsuXGR3po3mOw8gTB4UsjkCnRbRblGCihikV6udBznpCYdVkhMRNKWsQEsjIP coQa1Plg0sInEL+JayNfWQyilEW35SGEfny500vcthl/ZMwpBeGJPJqhsQRt5DmW2aGPPKgfyTDO JdUwDkm6dBEF+gROGGOhTf7hjIdIzkv4CIkDLzIqUjwhFdzTT2TOSLWKNaNAjvkddEaoH2f87gkZ UQV0/FEgyUgOEKqoxhg/c0D1GQl76xMI5/9ACJdnEbBnKboYVODhEi225jak+AwTHZK0Aq2Hjoh7 wisEI5HfWeEs4GvIND7TSZw0Ax/vq9zZXsnAmWRGY7tRBT5qUrkqqPGAemiJMzJiSvSd6iGjyyIp RwfGPipwQpA5CxerIpTi9dGPlSulLBvEQh8ixBcc4dw2BrKyi6ntkSNZXySvKLt/mPFGphTIAZtT lSRSC3E/esJ6nmOWV6wHmNVAHCkBQYqC4IMUDzHgRQyqPBJq5H0ssUV4pqGNxtzjoMmL0GfyIDxn opAqiXPhhEhBSike0pSNMZAzjuEZyIBkMKoQDikoksSSIWhkPIFFN2eyGrmxhpzlHAmzbPj/EoUM xArFfM5FJpQVgRwjD2OZUKFGeMg6InU3cdwPKi/SpZW603YIaairDiKPn2AViQPi2IUw4pioHmSE 8azjVLh6NuF8pib6EaQUG3bH7nlsINHaCywORjpyHVEgDMGWT3FTuHSO5HMrjVBjrHCjhplyGg6U jzaO0oS87kco/bDmOwfDRBcKZIx3VYw0nEEKcn6Wow0ZDGS0t8V7DnUgTKzcFgr6hJh4Zp1+VJrL hOMRs6wzJH5sTfj8QQ3GhaQtFVMfLhGLJIosorDRXWhsetLTx52HeHac4jpJebbmJW5fI61GRFtS uSk8RjJ6/Udk9uWyeCbOQBEi7oAQ2ZPN/3xqI4DQTW78sb1/jNEhwcNKSxtjWmuqohSW/IN+/JHW 9wJiFAK852vb6Zgn7KEhD5EohfKoNMyhBFH9g65GHrEGn4plNNaVyC1quJMWg5Ujp6ufw5C4RzlC xizNs6Y/kkjK4z12jp8b3Ev925xMurZ4gwnoe4OpULSIc0BPaEbLqlM5sRUIJWf8XOWUB5kJga+9 epSqHnIpmM+sVUKSmYYz5MC5qUIGf22hVV3kcz2JKPYgK7Qgfy+1U9RtKE0b0e5AyLlTl3zrsQXa V2UFElk9/MaXN3osvhSkFccKZ4s1slyNzNLm5La5nHhycU7dpRGXEeVSd8rJoRNZHAEdRf99bunp NpOzF3nAOob0aZ91MXtqsG2qY/8SCW13xagoacQZ71r2n1bTOi5tF9Fy4XNypuFsp9xmRGojIEQS A86D8NomjXSJubM5EFtAhYAROYc5yekPLVh3KFsiTZ9qmhwq3+yGfCnIv9d3p9at+x+1C5eHXvLt PzUQIeQGjdRWvBH98SQnLXm3oSfDLT+Nabisji6gvgovjQDV4U/CzL6/Rlgp+eMVRzH4XN6E55ng T0wt8bMV/2xqjyuSehtSUMdPrZFWNFwxKEe5ijL1JkM+kl9LZ41cSnRz2f3PLfk1LHusC0MxCSoi IHOTTKQsEmnTZhqKXuxMxP3sp1cx6CX/WaHUkw0agrlkFa6Lda6Wbm97T08vJYmVmMIOlMI4vXMi SXvPk2P2oOO72KHC8bVNNBdnhOeszmWQBSWxN7eUnSNwV/vF1ncbXB1+z4vHElBofiTCS2R8iw6h 4pt140i5Ze6IH/fdD5LfnZez5LSpE/44hyJt9B4qDR2797DjKMiPhBrSoMYgaBB9pWSh4NHHAo5f QYNXoNz66M4+Db6wFdtHZ2F7331SArV5bGnf8jDqfvVp4Ip8wR4hhLj+SGBhfaBAn/3/4P/LQUj+ ji/dVA8qiqJWJCL7CEEgtIH/BgL6KiT7XsE1UIEG0E0gviD8+OpT8kH3JiIndqIBt6s2/2oH19SJ I1pugowt+94DArcNLezvJVxwJjLwH2KwBu2vNl5kAE9Ng9CCUwAm96gB/BBiBu2vUEyDBcdtGqyG EDSQr+6HphBjEMaPkMROu1xjOfilSZRQIGKwJyIi9f5sJL5QJrSB/bLgC85w+rCQAU1PcYTohRBC FQjBAjuCBg6jDF9CCVHECUeixZBGLF5hAfluWWbIJairCkEkJrrQBu+vTWKE/kgC3fTQJSSwJSSw c8wP0RhvQ/Bh+cTFb4aQBjRiEBKDEABwJJRwOfzwDzXiDnCDBgix9ILKCtUpEWlxJvikEfVwGkJO S0BIY66t0GxC/hBiEc5AUrSvJVKh//8OIh6851Iyg2YQY/WeC2lgL/uecCPsbze+QPoG4vloAAtO 4TD8wQJHEQuc8SAG4QsqEByT4htpYBCQ4vsWcApkUSBeQR7pMQGjz/pM5RWyIPpm8SDs8R++kRBh gR+/5R9RASeiLwPhsTX47wtMxfoI4R1pABW+zw47gv+woCQacRAesSPkERU+5Pumwf7A7z0aMCJr RxzBDyneDzHkMQsMTg9dARsGgiUtEgP/URr2kQYGsv9YsuCA0gInEA//gRpOcgGPjmasMSxaRwyp zSUqcBs1IgZ3YwhN5QwJEQs08BXwwSOcslDgoRj8jyg9wv4Swyu9kPowMCOH8PrgEiH/5VIisKAg s68l2nEjvoAQnA8L7NIosyDAMtELTeUuRQELMNEj9xIx+o8asoBaIvMfKrB2eLEkGTAbssEjGpAK BUIdDxMhmfIf0lAf7RAsBSI1qy8xXoEaTAX6VoMkAXMs+28CJ1AgpEEoH1AN2wInVXMQMzELQPMv R2IbfFAkkMET5iL1JDErfeILd8MwBwILRHMCZVMrJcItJdNUviAv79IJlaIGwzMc1/E6CxKomjI9 edM3zVM88bDuznM0D6L/RIEGKOIyvzD7VsQfOBJL8rE9a6cHPNIRz6QyH3AgwjMihnABK3A1ItM2 BWITCLELdVM136MSNbQnW+IellE1/8srEw2CEOTyQavvFe5BQQVCNCOvq+YiY8JCPgon+/LSJgih DxANCy7SRQ2SBlIBOa/SBp/wLq3vH/kTC4rkSP+xINUTIjbyIC7TXv5BGqBvSZl0JYez4AqSR5NS HaPvRNlvEOxv+hqJGlChKDWTBzaUMxmUIFFhNdRQSsNPHsGUKFHzCSGEXQ6U5TSyBd10Le3CDhMz RQXiHSPqH5ECRceCH+P0b2TCGAFtTDwQIQiTVV5BKfyBJEel/+ZRIxRwGgZ0L/qhSD01/MSiEonQ JC4zuaL0Ol3UXvxBVakRxw4iNb9gScGTFG9TG6gvCwjBKTkiPOP0Ll+zJ28UIVChDv/HkUHJggi/ USPEElQ9Uhsy8CG7cFaT1QsfcRoq0CMKNTEzUyyMtUKWVR0DVRE3ghZozBqPbQ8HVEqB4/oiwkvx Ul6PtVC78ybukhgL7iER9FZ5VR8B1lIJMfxck0D3jEKvEwsSISJeoWAlMFnt1TsZ0EWzj0ybci9r pyS+dUs7tEUDdRBvNW9YFEUt1mGosD7ts+BiEwPz8mMZMDNWMWAlEGJzUz8PQgPLlWSvMxWTI9qc ghbY9UQMKSsPYx9rR1RpYw1VUzQzMmRpcyMY1isNIvuS9gkrMWP1kTtHM/xINhOt1WtbgzMVsGsR YiANzmkdJg3Nck4btoTO8DQBrUz/C+4bJfZAObT6AJYagrUp5dEjwvNh3BZw65EGpGJWATY+EmMg 6/Eba4ckASUQSqEGDTVFk9YZSXI2F9MZGSH7+tY4ieOwXGIqeBAMiY9LMRI2/3EjLVJUCZUfR9Mh mXUcy0syAbICvWAcY8JaCVI1jzQch/JTR24aBvIJBfJ3/VFU1dEgZRchsm9nj/Q4o88UPS5NE2MQ fPRP+G8BtfEfWtciW7dgp5BZfxID3TEiXZL/rPcT70EeCVH6oo/l1HQtUXF8t5Ioz/fRRLUj4ZFZ hdM0HfIfYOH5zFcpUoj5emMYAGQgmuECZwJKeGgxHhgKYdQkBGFSfSX38muCXaIp/3BiDDVYhM8l dXLxYiyXL6JIXduvWlYYLloHXO5NIqgUN84FFEloZ8TEXaWk95gBM3Yi9TTlf/aMh10iC7a1h2DN X2WiLH1K4U73/ASiht9QOY4iWxaL8Hg4irEn2SjCKqPQxfwXaGVGdV5wxablhQ8J0ZBDEquYJfbt LiwGKtx4IFKBimViZdjEIvwVUxzUJI7uYupY8IBiOgai8moq2Hji6ghJbf4Yh0XmkWrDI6zyjRGi H1RO1vCD7SSCSiB5I0pFI9hBTvgMiHiCiweMIp7mH1ZhFY6G9F6CkW0162bok82pU4jRlvcMwHS5 UoZYJAguU6ywGTbxUVhYlwWEM/+W4RTWRTF6I+BOmQCl+Yz9BJlLTTFgIXXTx4h9AkUC+Q1NQ+ss 2Ut+8boCpXSt+SCoAGUMEXlGAptmZTG8g/Ow6Noyo1a8ptfGGfcKjxrQjf4MydochZvHRG0yYzXu ooaAInV3JFNMWJN5DosQoqn4BkQMaVTwWBdJeCTgIR3IpRp2wkmSRdq0oaRL1/TkRo1nrWca+kSW w9xQeeOKOEpWOegyGhLhYiq05UgkYxO/+R/CQOMiWdZO95nfmKA/UIWbeVeiVjE8oRNkmiVoLSYQ 2fR++uxIty5QRKWxjpBq2phx+hALESqIgD544qtBg39Ewgq6gCeshlV05t+mDFT/0GsjtKCcJwI1 mPjrVkynaYyftaSYie0f0HpMlkNWQPENYhQoCttdv0qGocasbdEpwCCi+wKxeuPQkDot/CYO+bqi JVpM2CEYTKJo5RAuPOJ9QgSSWweeDeclZmws0GVseOIPdCZ1C1vaagMpKrWJIWL1CgKTc6KSsTo5 dkOc17UTJVua95R0x0WhN5o3X6ITnNRhILivWmHoVMQgqFScg/klIKQ9YC1Eetv0BJviJlsxfoPW PNGRlrtVMkPbXE8i4AaUw/FEimQz7gGvESKfCYMj2Nk9blsiamG+beOycw25q/j4rhoo+qGceVIi YDm6NOUnasMQXHuEKwS6bwZQuILPsycCURTcnFpHFBbv74TZmTebpw45GjmZI6ThLiRVMYjbihdv +DBjp/LiFGJ8nz9Gm8dkwqv4Jkw8LmJvkDTcx09Ekbt4THJmOeSiuZTcrU2PjMfZO6YCXS6QIhr8 JYB8PELG86gIsSpuyg8CHlrvpxbPyoMOEk44tJ07rPniyx9uxU/QzP+BHVoaRm4aJ3TutD9wjoEY zzniEfAOwdWb0BXdupjQIgpWFWT59CCiktdnvyQiIAAAOw== ------=_NextPart_000_000E_01C815B7.5C58A190-- From ospf-bounces@ietf.org Tue Oct 23 22:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkViT-0004of-Gi; Tue, 23 Oct 2007 22:11:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkViS-0004oP-3M for ospf@ietf.org; Tue, 23 Oct 2007 22:11:28 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkViR-00035S-FV for ospf@ietf.org; Tue, 23 Oct 2007 22:11:28 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQE004218PXB2@szxga01-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 10:10:45 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQE008L88PW9F@szxga01-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 10:10:45 +0800 (CST) Received: from d68733d ([10.111.12.195]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQE00IPJ8PVK9@szxml03-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 10:10:44 +0800 (CST) Date: Wed, 24 Oct 2007 10:10:43 +0800 From: "Abhay D.S" Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPFprotocolQuestion To: curtis@occnc.com, Erblichs Message-id: <012701c815e3$158d4b40$c30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200710230400.l9N402F5037669@harbor.brookfield.occnc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Abhay D.S" List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Curtis,Erblich, Could we focus on the key question of cascaded restarts, how to make sure the topology is stable before and after each restart ?. Automatically. How to make a deterministic planning, so we can know where the holes are and what is the impact. Has anyone thought on these lines ? Thanks, Abhay ----- Original Message ----- From: "Curtis Villamizar" To: "Erblichs" Cc: "Abhay D.S" ; Sent: Tuesday, October 23, 2007 12:00 PM Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPFprotocolQuestion > > In message <4719BA7F.BC701169@earthlink.net> > Erblichs writes: > > > > Abhay D.S., > > > > > > Actually it is just a bit more > > complicated. > > > > With OSPF, we should start with a case > > of two routers. > > > > How does the restarting router know > > that the restart is done and how does > > the other router know that the restart > > is done? > > > > The restarting router can determine > > whether NSF and restart is done. Whether > > restart required a a standard resync of > > the LSDB is almost irrelevant. > > > > So, the question is why must Gracefull > > be successful? It basicly just "reduces" > > overhead while NOT distrupting forwarding. > > More important it does not slosh all of the BGP routes (hundreds of > thousands of them) away from the restarting router and then back. > In an IGP only transient routing nasties due to inconsistent notion of > whether that router is up or not is something to be avoided (you know, > transient loops, transient blackholes, and all that). > > > Thus, It is done when it re-starts sending HELLOs > > and re-extablishes full adjs from the perspective > > of the 2nd router. The hellos are the aliveness > > criteria from my earlier post. > > > > ` So, you MIGHT want to track the nbr FSM > > if you have access to the OSPF source code. > > > > Mitchell Erblich > > ---------------- > > > > > > "Abhay D.S" wrote: > > > > > > Mitchell, > > > > > > 2) Their is no GUARANTEE that any Restart will > > > be sucessful, that the LSDB will be stable and/or > > > that helper(s) exist. > > > > > > I wanted an automated and deterministic number 2. > > > > > > Any ideas or any attempts in the direction of 2 ? > > > > > > With Regards, > > > Abhay > > > Looks to me to be more like a windmill than a dragon. > > Curtis _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 24 00:08:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkXUS-00065r-9k; Wed, 24 Oct 2007 00:05:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkXUQ-00065K-CT for ospf@ietf.org; Wed, 24 Oct 2007 00:05:06 -0400 Received: from corp.force10networks.com ([64.186.164.204] helo=mx.force10networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkXUK-0003ii-36 for ospf@ietf.org; Wed, 24 Oct 2007 00:05:06 -0400 Received: from EXCH-CLUSTER-03.force10networks.com ([10.11.0.54]) by mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 21:04:40 -0700 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: [OSPF] Cascaded Graceful Restarts with NSF forOSPFprotocolQuestion Date: Tue, 23 Oct 2007 21:04:40 -0700 Message-ID: <44ED058B21DF294ABE394CABE5C1B521E19881@EXCH-CLUSTER-03.force10networks.com> In-Reply-To: <012701c815e3$158d4b40$c30c6f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Cascaded Graceful Restarts with NSF forOSPFprotocolQuestion Thread-Index: AcgV5l/RbRK//1dDTcS3luu9hWjKbAACsOSQ References: <200710230400.l9N402F5037669@harbor.brookfield.occnc.com> <012701c815e3$158d4b40$c30c6f0a@china.huawei.com> From: "Nitin Kakkar" To: "Abhay D.S" , , "Erblichs" X-OriginalArrivalTime: 24 Oct 2007 04:04:40.0375 (UTC) FILETIME=[00257470:01C815F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Abhay, I am wondering if you can use LLS or similar mechanisms instead of GR? I can also think of something like an ospf task/process (with a different router id) in the same memory address space, acting as virtual/temporary router. This process borrow configurations from restarting process, pretend itself to be a new router on link, form adjacency with peer but does not do route calculations (unless you want forwarding refreshed). This does not require nbr to support GR, LLS or any other draft, but require your system to support temporary interfaces. Hope I am making some sense. Regards Nitin -----Original Message----- From: Abhay D.S [mailto:abhay.ds@huawei.com]=20 Sent: Tuesday, October 23, 2007 7:11 PM To: curtis@occnc.com; Erblichs Cc: ospf@ietf.org Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF forOSPFprotocolQuestion Curtis,Erblich, Could we focus on the key question of cascaded restarts, how to make sure the topology is stable before and after each restart ?. Automatically. How to make a deterministic planning, so we can know where the holes are and what is the impact. Has anyone thought on these lines ? Thanks, Abhay ----- Original Message ----- From: "Curtis Villamizar" To: "Erblichs" Cc: "Abhay D.S" ; Sent: Tuesday, October 23, 2007 12:00 PM Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPFprotocolQuestion > > In message <4719BA7F.BC701169@earthlink.net> > Erblichs writes: > > > > Abhay D.S., > > > > > > Actually it is just a bit more > > complicated. > > > > With OSPF, we should start with a case > > of two routers. > > > > How does the restarting router know > > that the restart is done and how does > > the other router know that the restart > > is done? > > > > The restarting router can determine > > whether NSF and restart is done. Whether > > restart required a a standard resync of > > the LSDB is almost irrelevant. > > > > So, the question is why must Gracefull > > be successful? It basicly just "reduces" > > overhead while NOT distrupting forwarding. > > More important it does not slosh all of the BGP routes (hundreds of > thousands of them) away from the restarting router and then back. > In an IGP only transient routing nasties due to inconsistent notion of > whether that router is up or not is something to be avoided (you know, > transient loops, transient blackholes, and all that). > > > Thus, It is done when it re-starts sending HELLOs > > and re-extablishes full adjs from the perspective > > of the 2nd router. The hellos are the aliveness > > criteria from my earlier post. > > > > ` So, you MIGHT want to track the nbr FSM > > if you have access to the OSPF source code. > > > > Mitchell Erblich > > ---------------- > > > > > > "Abhay D.S" wrote: > > > > > > Mitchell, > > > > > > 2) Their is no GUARANTEE that any Restart will > > > be sucessful, that the LSDB will be stable and/or > > > that helper(s) exist. > > > > > > I wanted an automated and deterministic number 2. > > > > > > Any ideas or any attempts in the direction of 2 ? > > > > > > With Regards, > > > Abhay > > > Looks to me to be more like a windmill than a dragon. > > Curtis _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From Biju361@abundantlifegrapevine.org Wed Oct 24 00:57:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkYIf-00041Z-Uf for ospf-archive@megatron.ietf.org; Wed, 24 Oct 2007 00:57:01 -0400 Received: from [195.206.6.106] (helo=[195.206.6.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkYId-0007V9-Sn for ospf-archive@megatron.ietf.org; Wed, 24 Oct 2007 00:57:01 -0400 Received: from PorLab ([177.196.106.6]:28734 "EHLO PorLab" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [195.206.6.106] with ESMTP id S22QZBNGWZERFPAZ (ORCPT ); Wed, 24 Oct 2007 06:58:04 +0200 Message-ID: <000c01c815fa$64568c20$6a06cec3@PorLab> From: "Biju Horowitz" To: Subject: cuirassa Date: Wed, 24 Oct 2007 06:57:34 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8160B.27DF5C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C8160B.27DF5C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hallo dear ospf-archive just out of curiousity, do you want a huge cock? http://pasaok.com/ Biju Horowitz ------=_NextPart_000_0006_01C8160B.27DF5C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hallo dear ospf-archive
just out of curiousity, do you want a huge=20 cock?
http://pasaok.com/
Biju Horowitz
------=_NextPart_000_0006_01C8160B.27DF5C20-- From ospf-bounces@ietf.org Wed Oct 24 01:24:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkYe6-0003Of-LT; Wed, 24 Oct 2007 01:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkYe3-0003Gq-RI for ospf@ietf.org; Wed, 24 Oct 2007 01:19:07 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkYdq-0005il-J6 for ospf@ietf.org; Wed, 24 Oct 2007 01:19:01 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQE00HJZHD9AS@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 13:17:33 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQE00H7RHD7AG@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 13:17:33 +0800 (CST) Received: from p709321533 ([10.18.4.174]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQE002CQHD2BE@szxml03-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 13:17:31 +0800 (CST) Date: Wed, 24 Oct 2007 10:47:19 +0530 From: sinbad To: ospf@ietf.org Message-id: <000301c815fd$2ad10630$8119fea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcgV/SYH8nmliTckS8q6zbRE/lOb1w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 66cd52c51f844cd6271a6211ea6f8f9d Subject: [OSPF] Routing loop , Dennis Ferguson X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1023899278==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1023899278== Content-type: multipart/alternative; boundary="Boundary_(ID_cYTVHj4P4Vem1lqxrAZdmA)" This is a multi-part message in MIME format. --Boundary_(ID_cYTVHj4P4Vem1lqxrAZdmA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, "The routing loop discovered by Dennis Ferguson which occurs when an aggregated forwarding address is in use. In this case, the desirability of the forwarding address can change for the worse as a packet crosses an area aggregation boundary on the way to the forwarding address, which in turn can cause the preference of AS-external-LSAs to change, resulting in a routing loop." "Can anyone explain how this can actually happen ... Thanks sinbad --Boundary_(ID_cYTVHj4P4Vem1lqxrAZdmA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

“The routing loop discovered by Dennis Ferguson which occurs when an aggregated forwarding address is in use. In this case, the desirability of the forwarding address

can change for the worse as a packet crosses an area aggregation boundary on the way to the forwarding address, which in turn can cause the preference of AS-external-LSAs

to change, resulting in a routing loop.”

“Can anyone explain how this can actually happen  ...

 

Thanks

sinbad

--Boundary_(ID_cYTVHj4P4Vem1lqxrAZdmA)-- --===============1023899278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1023899278==-- From ospf-bounces@ietf.org Wed Oct 24 02:26:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkZfk-0006Wh-OD; Wed, 24 Oct 2007 02:24:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkZfj-0006WV-HX for ospf@ietf.org; Wed, 24 Oct 2007 02:24:55 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkZfg-0001D9-Qv for ospf@ietf.org; Wed, 24 Oct 2007 02:24:55 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQE00H88KGEAS@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 14:24:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQE0035OKGCCP@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 14:24:14 +0800 (CST) Received: from d68733d ([10.111.12.195]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQE005KIKGCV5@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 14:24:12 +0800 (CST) Date: Wed, 24 Oct 2007 14:24:11 +0800 From: "Abhay D.S" Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF forOSPFprotocolQuestion To: Nitin Kakkar , "Abhay D.S" , curtis@occnc.com, Erblichs Message-id: <014101c81606$7e04fc90$c30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200710230400.l9N402F5037669@harbor.brookfield.occnc.com> <012701c815e3$158d4b40$c30c6f0a@china.huawei.com> <44ED058B21DF294ABE394CABE5C1B521E19881@EXCH-CLUSTER-03.force10networks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Abhay D.S" List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Nitin, I am thinking on the lines of preversing forwarding in a stable toplogy as much as possible which might become unstable due to cascaded restarts. In protocol lore LLS or GR signalling, which I feel should have some pre conditions for them to minimize fwding loss. I want have an automatic mechanism to make sure the preconditions exist after every device graceful restart using any mechanism, since they are all connected and have ripple effect. If this mechanism is automated, I am in more control of the whole forwading paradigm. With Regards, Abhay ----- Original Message ----- From: "Nitin Kakkar" To: "Abhay D.S" ; ; "Erblichs" Cc: Sent: Wednesday, October 24, 2007 12:04 PM Subject: RE: [OSPF] Cascaded Graceful Restarts with NSF forOSPFprotocolQuestion Abhay, I am wondering if you can use LLS or similar mechanisms instead of GR? I can also think of something like an ospf task/process (with a different router id) in the same memory address space, acting as virtual/temporary router. This process borrow configurations from restarting process, pretend itself to be a new router on link, form adjacency with peer but does not do route calculations (unless you want forwarding refreshed). This does not require nbr to support GR, LLS or any other draft, but require your system to support temporary interfaces. Hope I am making some sense. Regards Nitin -----Original Message----- From: Abhay D.S [mailto:abhay.ds@huawei.com] Sent: Tuesday, October 23, 2007 7:11 PM To: curtis@occnc.com; Erblichs Cc: ospf@ietf.org Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF forOSPFprotocolQuestion Curtis,Erblich, Could we focus on the key question of cascaded restarts, how to make sure the topology is stable before and after each restart ?. Automatically. How to make a deterministic planning, so we can know where the holes are and what is the impact. Has anyone thought on these lines ? Thanks, Abhay ----- Original Message ----- From: "Curtis Villamizar" To: "Erblichs" Cc: "Abhay D.S" ; Sent: Tuesday, October 23, 2007 12:00 PM Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPFprotocolQuestion > > In message <4719BA7F.BC701169@earthlink.net> > Erblichs writes: > > > > Abhay D.S., > > > > > > Actually it is just a bit more > > complicated. > > > > With OSPF, we should start with a case > > of two routers. > > > > How does the restarting router know > > that the restart is done and how does > > the other router know that the restart > > is done? > > > > The restarting router can determine > > whether NSF and restart is done. Whether > > restart required a a standard resync of > > the LSDB is almost irrelevant. > > > > So, the question is why must Gracefull > > be successful? It basicly just "reduces" > > overhead while NOT distrupting forwarding. > > More important it does not slosh all of the BGP routes (hundreds of > thousands of them) away from the restarting router and then back. > In an IGP only transient routing nasties due to inconsistent notion of > whether that router is up or not is something to be avoided (you know, > transient loops, transient blackholes, and all that). > > > Thus, It is done when it re-starts sending HELLOs > > and re-extablishes full adjs from the perspective > > of the 2nd router. The hellos are the aliveness > > criteria from my earlier post. > > > > ` So, you MIGHT want to track the nbr FSM > > if you have access to the OSPF source code. > > > > Mitchell Erblich > > ---------------- > > > > > > "Abhay D.S" wrote: > > > > > > Mitchell, > > > > > > 2) Their is no GUARANTEE that any Restart will > > > be sucessful, that the LSDB will be stable and/or > > > that helper(s) exist. > > > > > > I wanted an automated and deterministic number 2. > > > > > > Any ideas or any attempts in the direction of 2 ? > > > > > > With Regards, > > > Abhay > > > Looks to me to be more like a windmill than a dragon. > > Curtis _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 24 05:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkcGk-0002ST-E8; Wed, 24 Oct 2007 05:11:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkcGj-0002Op-3O for ospf@ietf.org; Wed, 24 Oct 2007 05:11:17 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkcGi-0006Tj-B9 for ospf@ietf.org; Wed, 24 Oct 2007 05:11:17 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQE00LRYS5NXO@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 17:10:35 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQE00GXLS5MCF@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 17:10:35 +0800 (CST) Received: from d68733d ([10.111.12.195]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQE002W7S5L4N@szxml03-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 17:10:34 +0800 (CST) Date: Wed, 24 Oct 2007 17:10:33 +0800 From: "Abhay D.S" Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF forOSPFprotocolQuestion To: Nitin Kakkar , "Abhay D.S" , curtis@occnc.com, Erblichs Message-id: <01a201c8161d$bc058480$c30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200710230400.l9N402F5037669@harbor.brookfield.occnc.com> <012701c815e3$158d4b40$c30c6f0a@china.huawei.com> <44ED058B21DF294ABE394CABE5C1B521E19881@EXCH-CLUSTER-03.force10networks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Abhay D.S" List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Nitin, I want reliability before the restart. So I can predict the result of it and then I can delay it if I want to by making corrections. Just like...looks good..before I begin the signaling. The mechanism described by Mitchell,Acee and yours do not provide reliability before restart. Folks, tell me something I dont know. With Regards, Abhay ----- Original Message ----- From: "Nitin Kakkar" To: "Abhay D.S" ; ; "Erblichs" Cc: Sent: Wednesday, October 24, 2007 12:04 PM Subject: RE: [OSPF] Cascaded Graceful Restarts with NSF forOSPFprotocolQuestion Abhay, I am wondering if you can use LLS or similar mechanisms instead of GR? I can also think of something like an ospf task/process (with a different router id) in the same memory address space, acting as virtual/temporary router. This process borrow configurations from restarting process, pretend itself to be a new router on link, form adjacency with peer but does not do route calculations (unless you want forwarding refreshed). This does not require nbr to support GR, LLS or any other draft, but require your system to support temporary interfaces. Hope I am making some sense. Regards Nitin -----Original Message----- From: Abhay D.S [mailto:abhay.ds@huawei.com] Sent: Tuesday, October 23, 2007 7:11 PM To: curtis@occnc.com; Erblichs Cc: ospf@ietf.org Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF forOSPFprotocolQuestion Curtis,Erblich, Could we focus on the key question of cascaded restarts, how to make sure the topology is stable before and after each restart ?. Automatically. How to make a deterministic planning, so we can know where the holes are and what is the impact. Has anyone thought on these lines ? Thanks, Abhay ----- Original Message ----- From: "Curtis Villamizar" To: "Erblichs" Cc: "Abhay D.S" ; Sent: Tuesday, October 23, 2007 12:00 PM Subject: Re: [OSPF] Cascaded Graceful Restarts with NSF for OSPFprotocolQuestion > > In message <4719BA7F.BC701169@earthlink.net> > Erblichs writes: > > > > Abhay D.S., > > > > > > Actually it is just a bit more > > complicated. > > > > With OSPF, we should start with a case > > of two routers. > > > > How does the restarting router know > > that the restart is done and how does > > the other router know that the restart > > is done? > > > > The restarting router can determine > > whether NSF and restart is done. Whether > > restart required a a standard resync of > > the LSDB is almost irrelevant. > > > > So, the question is why must Gracefull > > be successful? It basicly just "reduces" > > overhead while NOT distrupting forwarding. > > More important it does not slosh all of the BGP routes (hundreds of > thousands of them) away from the restarting router and then back. > In an IGP only transient routing nasties due to inconsistent notion of > whether that router is up or not is something to be avoided (you know, > transient loops, transient blackholes, and all that). > > > Thus, It is done when it re-starts sending HELLOs > > and re-extablishes full adjs from the perspective > > of the 2nd router. The hellos are the aliveness > > criteria from my earlier post. > > > > ` So, you MIGHT want to track the nbr FSM > > if you have access to the OSPF source code. > > > > Mitchell Erblich > > ---------------- > > > > > > "Abhay D.S" wrote: > > > > > > Mitchell, > > > > > > 2) Their is no GUARANTEE that any Restart will > > > be sucessful, that the LSDB will be stable and/or > > > that helper(s) exist. > > > > > > I wanted an automated and deterministic number 2. > > > > > > Any ideas or any attempts in the direction of 2 ? > > > > > > With Regards, > > > Abhay > > > Looks to me to be more like a windmill than a dragon. > > Curtis _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Oct 24 06:07:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikd6g-0003AD-RW; Wed, 24 Oct 2007 06:04:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikd6e-00035q-OI for ospf@ietf.org; Wed, 24 Oct 2007 06:04:56 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikd6e-0007oW-3Q for ospf@ietf.org; Wed, 24 Oct 2007 06:04:56 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8CB5719F478; Wed, 24 Oct 2007 03:04:55 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21250-09; Wed, 24 Oct 2007 03:04:55 -0700 (PDT) Received: from [f???N???p??0???$IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 12B6919F477; Wed, 24 Oct 2007 03:04:54 -0700 (PDT) In-Reply-To: <000301c815fd$2ad10630$8119fea9@china.huawei.com> References: <000301c815fd$2ad10630$8119fea9@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Acee Lindem Subject: Re: [OSPF] Routing loop , Dennis Ferguson Date: Wed, 24 Oct 2007 06:03:16 -0400 To: sinbad X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1699936775==" Errors-To: ospf-bounces@ietf.org --===============1699936775== Content-Type: multipart/alternative; boundary=Apple-Mail-1-164632287 --Apple-Mail-1-164632287 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Sinbad, I assume you are looking at section G.7 in RFC 2178. If the =20 forwarding addresses advertised for the same external route by =20 routers A1 and B1 are in ranges and the minimum cost is advertised =20 for the range, you could have a routing loop between routers A1 and =20 B1 (given that we didn't have forwarding address preference either - =20 RFC1583Compatibility set to enabled). On Oct 24, 2007, at 1:17 AM, sinbad wrote: > Hi all, > > =93The routing loop discovered by Dennis Ferguson which occurs when =20= > an aggregated forwarding address is in use. In this case, the =20 > desirability of the forwarding address > > can change for the worse as a packet crosses an area aggregation =20 > boundary on the way to the forwarding address, which in turn can =20 > cause the preference of AS-external-LSAs > > to change, resulting in a routing loop.=94 > > =93Can anyone explain how this can actually happen ... > > > > Thanks > > sinbad > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf --Apple-Mail-1-164632287 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Sinbad,=A0

I assume you are looking at = section G.7 in RFC 2178. If the forwarding addresses advertised for the = same external route by routers A1 and B1 are in ranges and the minimum = cost is advertised for the range, you could have a routing loop between = routers A1 and B1 (given that we didn't have forwarding address = preference either - RFC1583Compatibility set to = enabled).=A0

On Oct 24, 2007, at 1:17 AM, sinbad = wrote:

Hi = all,

=93The = routing loop discovered by Dennis Ferguson which occurs when an = aggregated forwarding address is in use. In this case, the desirability = of the forwarding address

can change for the worse as = a packet crosses an area aggregation boundary on the way to the = forwarding address, which in turn can cause the preference of = AS-external-LSAs

to = change, resulting in a routing loop.=94

=93Can anyone explain how = this can actually happen=A0 ...

=A0<= /P>

Thanks

sinbad

=
OSPF mailing list
=

= --Apple-Mail-1-164632287-- --===============1699936775== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1699936775==-- From Korpinenbhww@panamamovers.com Wed Oct 24 06:18:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdJm-00075N-76 for ospf-archive@megatron.ietf.org; Wed, 24 Oct 2007 06:18:30 -0400 Received: from p5086a472.dip0.t-ipconnect.de ([80.134.164.114] helo=p5086826C.dip0.t-ipconnect.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkdJX-0007Kq-B7 for ospf-archive@megatron.ietf.org; Wed, 24 Oct 2007 06:18:22 -0400 Received: by 10.239.176.231 with SMTP id dFcetGHBhiFQD; Wed, 24 Oct 2007 12:20:20 +0200 (GMT) Received: by 192.168.188.217 with SMTP id LVTBHaAOQCDcNC.3969448694721; Wed, 24 Oct 2007 12:20:18 +0200 (GMT) Date: Wed, 24 Oct 2007 12:20:15 +0200 From: "koray Korpinen" Reply-To: "koray Korpinen" Message-ID: <951160584726.945354937264@panamamovers.com> To: Subject: eturbnam MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hello moto ospf-archive lets talk about the size of your cock, small aint it? http://www.rpmcvo.com/ koray Korpinen From ospf-bounces@ietf.org Wed Oct 24 07:19:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkeDq-0008F4-DX; Wed, 24 Oct 2007 07:16:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkeDo-000885-WE for ospf@ietf.org; Wed, 24 Oct 2007 07:16:25 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkeDY-0000fz-VE for ospf@ietf.org; Wed, 24 Oct 2007 07:16:17 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQE007LZXWZO7@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 19:14:59 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQE002A8XWX4K@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 19:14:58 +0800 (CST) Received: from p709321533 ([10.18.4.174]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQE002W9XWRG3@szxml03-in.huawei.com> for ospf@ietf.org; Wed, 24 Oct 2007 19:14:57 +0800 (CST) Date: Wed, 24 Oct 2007 16:44:48 +0530 From: sinbad Subject: RE: [OSPF] Routing loop , Dennis Ferguson In-reply-to: To: 'Acee Lindem' Message-id: <002601c8162f$199183e0$8119fea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcgWJVxoyjluLGqySNWq5Eu+9BfRtAACVJIg X-Spam-Score: 0.0 (/) X-Scan-Signature: 85fe3afc5d9560be77aa81420052017a Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1879371336==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1879371336== Content-type: multipart/alternative; boundary="Boundary_(ID_wkF8iwXLVl8c/n1F7x3QWQ)" This is a multi-part message in MIME format. --Boundary_(ID_wkF8iwXLVl8c/n1F7x3QWQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Acee, Can u tell me in the following topology, where exactly the address ranges are configured and Why A1 thinks B1 is the best path and why B1 thinks A1 is best path. Please clarify me in little more detail. Thanks sinbad 10.0.0.0/8 ---------- | +----+ | XX | +----+ RIP / \ RIP --------------------- -------------------- ! ! ! ! +----+ +----+ 1 +----+......+----+.... | A3 |------| A1 |---------------| B1 |------| B3 | . +----+ 6 +----+ +----+ 8 +----+ . 1| . / . OSPF backbone | . / . +----+ 2 / . | B2 |------- Area A. +----+................ _____ From: Acee Lindem [mailto:acee@redback.com] Sent: Wednesday, October 24, 2007 3:33 PM To: sinbad Cc: ospf@ietf.org Subject: Re: [OSPF] Routing loop , Dennis Ferguson Hi Sinbad, I assume you are looking at section G.7 in RFC 2178. If the forwarding addresses advertised for the same external route by routers A1 and B1 are in ranges and the minimum cost is advertised for the range, you could have a routing loop between routers A1 and B1 (given that we didn't have forwarding address preference either - RFC1583Compatibility set to enabled). On Oct 24, 2007, at 1:17 AM, sinbad wrote: Hi all, "The routing loop discovered by Dennis Ferguson which occurs when an aggregated forwarding address is in use. In this case, the desirability of the forwarding address can change for the worse as a packet crosses an area aggregation boundary on the way to the forwarding address, which in turn can cause the preference of AS-external-LSAs to change, resulting in a routing loop." "Can anyone explain how this can actually happen ... Thanks sinbad _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --Boundary_(ID_wkF8iwXLVl8c/n1F7x3QWQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

Hi Acee,
Can u tell me in the following topology, where exactly the address ranges are configured and 
Why A1 thinks B1 is the best path and why B1 thinks A1 is best path. Please clarify me in little more
detail. 
Thanks
sinbad
                               10.0.0.0/8
                              ----------
                                   |
                                +----+
                                | XX |
                                +----+
                   RIP          /    \        RIP
           ---------------------      --------------------
           !                                             !
           !                                             !
         +----+      +----+       1       +----+......+----+....
         | A3 |------| A1 |---------------| B1 |------| B3 |   .
         +----+   6  +----+               +----+  8   +----+   .
                                           1|  .         /     .
                       OSPF backbone        |  .        /      .
                                          +----+  2    /       .
                                          | B2 |-------  Area A.
                                          +----+................
 
 

From: Acee Lindem [mailto:acee@redback.com]
Sent: Wednesday, October 24, 2007 3:33 PM
To: sinbad
Cc: ospf@ietf.org
Subject: Re: [OSPF] Routing loop , Dennis Ferguson

 

Hi Sinbad, 

 

I assume you are looking at section G.7 in RFC 2178. If the forwarding addresses advertised for the same external route by routers A1 and B1 are in ranges and the minimum cost is advertised for the range, you could have a routing loop between routers A1 and B1 (given that we didn't have forwarding address preference either - RFC1583Compatibility set to enabled). 

 

On Oct 24, 2007, at 1:17 AM, sinbad wrote:



Hi all,

“The routing loop discovered by Dennis Ferguson which occurs when an aggregated forwarding address is in use. In this case, the desirability of the forwarding address

can change for the worse as a packet crosses an area aggregation boundary on the way to the forwarding address, which in turn can cause the preference of AS-external-LSAs

to change, resulting in a routing loop.”

“Can anyone explain how this can actually happen  ...

 

Thanks

sinbad

_______________________________________________

OSPF mailing list

 

--Boundary_(ID_wkF8iwXLVl8c/n1F7x3QWQ)-- --===============1879371336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1879371336==-- From ospf-bounces@ietf.org Wed Oct 24 10:31:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhDm-0004lj-QG; Wed, 24 Oct 2007 10:28:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhDk-0004k5-TC for ospf@ietf.org; Wed, 24 Oct 2007 10:28:33 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkhDj-0006VP-KT for ospf@ietf.org; Wed, 24 Oct 2007 10:28:32 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 38613A647FC; Wed, 24 Oct 2007 07:28:31 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16417-01; Wed, 24 Oct 2007 07:28:31 -0700 (PDT) Received: from [JB??O??IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 8169DA647FE; Wed, 24 Oct 2007 07:28:28 -0700 (PDT) In-Reply-To: <002601c8162f$199183e0$8119fea9@china.huawei.com> References: <002601c8162f$199183e0$8119fea9@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <3BE48AF1-B9FF-48BE-805D-10C19469EC2C@redback.com> From: Acee Lindem Subject: Re: [OSPF] Routing loop , Dennis Ferguson Date: Wed, 24 Oct 2007 10:26:50 -0400 To: sinbad X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 1.8 (+) X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0445798097==" Errors-To: ospf-bounces@ietf.org --===============0445798097== Content-Type: multipart/alternative; boundary=Apple-Mail-2-180446280 --Apple-Mail-2-180446280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Obviously, the ABRs (A1, B1, and B3) are advertising the ranges. If =20 the lowest cost in the range is advertised as the type 3 LSA cost and =20= the range subsumes the forwarding address, then A1's best path could =20 be to B3's forwarding address and B1's best path could be through =20 A3's forwarding address. Note the respective forwarding addresses are =20= XX's interface addresses on the link's to A3 and B3. If you can't =20 see this, try plugging in some prefixes and costs assuming A1 and B1 =20 have are advertising a loopback address in the range. Acee On Oct 24, 2007, at 7:14 AM, sinbad wrote: > > > Hi Acee, > Can u tell me in the following topology, where exactly the address =20 > ranges are configured and > Why A1 thinks B1 is the best path and why B1 thinks A1 is best =20 > path. Please clarify me in little more > detail. > Thanks > sinbad > 10.0.0.0/8 > ---------- > | > +----+ > | XX | > +----+ > RIP / \ RIP > --------------------- -------------------- > ! ! > ! ! > +----+ +----+ 1 +----+......+----+.... > | A3 |------| A1 |---------------| B1 |------| B3 | . > +----+ 6 +----+ +----+ 8 +----+ . > 1| . / . > OSPF backbone | . / . > +----+ 2 / . > | B2 |------- Area A. > +----+................ > > > From: Acee Lindem [mailto:acee@redback.com] > Sent: Wednesday, October 24, 2007 3:33 PM > To: sinbad > Cc: ospf@ietf.org > Subject: Re: [OSPF] Routing loop , Dennis Ferguson > > > > Hi Sinbad, > > > > I assume you are looking at section G.7 in RFC 2178. If the =20 > forwarding addresses advertised for the same external route by =20 > routers A1 and B1 are in ranges and the minimum cost is advertised =20 > for the range, you could have a routing loop between routers A1 and =20= > B1 (given that we didn't have forwarding address preference either =20 > - RFC1583Compatibility set to enabled). > > > > On Oct 24, 2007, at 1:17 AM, sinbad wrote: > > > > > Hi all, > > =93The routing loop discovered by Dennis Ferguson which occurs when =20= > an aggregated forwarding address is in use. In this case, the =20 > desirability of the forwarding address > > can change for the worse as a packet crosses an area aggregation =20 > boundary on the way to the forwarding address, which in turn can =20 > cause the preference of AS-external-LSAs > > to change, resulting in a routing loop.=94 > > =93Can anyone explain how this can actually happen ... > > > > Thanks > > sinbad > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > > > --Apple-Mail-2-180446280 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252
Obviously, the ABRs (A1, = B1, and B3) are advertising the ranges. If the lowest cost in the range = is advertised as the type 3 LSA cost and the range subsumes the = forwarding address, then A1's best path could be to B3's forwarding = address and B1's best path could be through A3's forwarding address. = Note the respective forwarding addresses are XX's interface addresses on = the link's to A3 and B3.=A0 If you can't see this, try plugging in some = prefixes and costs assuming A1 and B1 have are advertising a loopback = address in the range.=A0

Acee

= On Oct 24, 2007, at 7:14 AM, sinbad wrote:

Hi Acee,

Can u tell me in the =
following topology, where exactly the address ranges are configured and =
Why A1 thinks B1 is the best path and why B1 thinks =
A1 is best path. Please clarify me in little moredetail. 
Thankssinbad
=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 10.0.0.0/8
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ----------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +----+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | XX |=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0+----+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 RIP=A0=A0=A0=A0=A0=A0=A0=A0=A0 /=A0=A0=A0 \=A0=A0=A0=A0=A0=A0=A0 =
RIP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
---------------------=A0=A0=A0=A0=A0 --------------------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
!=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 !=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
!=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0!=A0=A0=A0=A0=A0=A0=A0=A0 +----+=A0=A0=A0=A0=A0 =
+----+=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 =
+----+......+----+....
=A0=A0=A0=A0=A0=A0=A0=A0 | A3 |------| A1 =
|---------------| B1 |------| B3 |=A0=A0 .
=A0=A0=A0=A0=A0=A0=A0=A0=
 +----+=A0=A0 6=A0 +----+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
+----+=A0 8=A0=A0 +----+=A0=A0 .
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 OSPF backbone=A0=A0=A0=A0=A0=A0=A0 |=A0 .=A0=A0=A0=A0=A0=A0=A0=
 /=A0=A0=A0=A0=A0 .
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
+----+=A0 2=A0=A0=A0 /=A0=A0=A0=A0=A0=A0 .
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
+----+................
=A0

Acee Lindem [mailto:acee@redback.com]
Wednesday, = October 24, 2007 3:33 PM
To: sinbad
= ospf@ietf.org Re: [OSPF] = Routing loop , Dennis Ferguson=A0

Hi Sinbad,=A0

=A0

I assume you are looking at section G.7 in RFC = 2178. If the forwarding addresses advertised for the same external route = by routers A1 and B1 are in ranges and the minimum cost is advertised = for the range, you could have a routing loop between routers A1 and B1 = (given that we didn't have forwarding address preference either - = RFC1583Compatibility set to enabled).=A0=A0

On Oct 24, 2007, at 1:17 AM, sinbad = wrote:



Hi all,

=93The routing loop discovered by Dennis Ferguson which = occurs when an aggregated forwarding address is in use. In this case, = the desirability of the forwarding address

can change for the worse as a packet crosses an area = aggregation boundary on the way to the forwarding address, which in turn = can cause the preference of AS-external-LSAs

to change, resulting in a routing loop.=94

=93Can anyone explain how this can actually happen=A0 = ...

Thanks

sinbad

OSPF mailing list


= --Apple-Mail-2-180446280-- --===============0445798097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0445798097==-- From ospf-bounces@ietf.org Wed Oct 24 10:58:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhfK-000220-3I; Wed, 24 Oct 2007 10:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhfH-0001uE-Ob for ospf@ietf.org; Wed, 24 Oct 2007 10:56:59 -0400 Received: from imo-m27.mx.aol.com ([64.12.137.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikhf8-0000qk-Dz for ospf@ietf.org; Wed, 24 Oct 2007 10:56:55 -0400 Received: from HeinerHummel@aol.com by imo-m27.mx.aol.com (mail_out_v38_r9.3.) id l.d11.1758338c (39331) for ; Wed, 24 Oct 2007 10:55:53 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Wed, 24 Oct 2007 10:55:53 EDT To: ospf@ietf.org MIME-Version: 1.0 X-Mailer: AOL 9.0 VR sub 52 X-Spam-Flag: NO X-Spam-Score: 1.8 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [OSPF] next hop determination X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2034078468==" Errors-To: ospf-bounces@ietf.org --===============2034078468== Content-Type: multipart/alternative; boundary="-----------------------------1193237753" -------------------------------1193237753 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit It may sound like a newbie question and therefore I would be grateful if someone will help with clarification: How is the next hop wrt to destination node d inside an OSPF-network determined? Assumption: At first the current (=root) node computes the Dijkstra SPT and then navigates from each network node, e.g. from node d, towards the root of the SPT as to determine the respective root adjacent link. Can anyone confirm/correct me? Many thanks, Heiner -------------------------------1193237753 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
It may sound like a newbie question and therefore I would be grateful i= f=20 someone will help with clarification:
 
How is the next hop wrt to destination node d inside an OSPF-network=20 determined?
 
Assumption: At first the current (=3Droot) node computes the Dijkstra S= PT and=20 then navigates from each network node, e.g. from node d, towards the root of= the=20 SPT as to determine the respective root adjacent link.
 
Can anyone confirm/correct me?
 
Many thanks,
Heiner
 
 
 
 
 
 -------------------------------1193237753-- --===============2034078468== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============2034078468==-- From ospf-bounces@ietf.org Wed Oct 24 11:39:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiH6-0002KG-Gp; Wed, 24 Oct 2007 11:36:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiH4-0002IB-FL for ospf@ietf.org; Wed, 24 Oct 2007 11:36:02 -0400 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkiH3-0000BM-Tp for ospf@ietf.org; Wed, 24 Oct 2007 11:36:02 -0400 Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Wed, 24 Oct 2007 08:36:00 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 08:35:59 -0700 Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id l9OFZwn33900; Wed, 24 Oct 2007 08:35:58 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8F8E3E25-E59A-40DF-A892-BE95F6227161@juniper.net> From: Dave Katz Subject: Re: [OSPF] next hop determination Date: Wed, 24 Oct 2007 09:35:57 -0600 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 24 Oct 2007 15:35:59.0207 (UTC) FILETIME=[9374EF70:01C81653] X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1550973481==" Errors-To: ospf-bounces@ietf.org --===============1550973481== Content-Type: multipart/alternative; boundary=Apple-Mail-12-184592420 --Apple-Mail-12-184592420 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Take a look at the algorithm in the RFC. Basically, as the SPT is calculated, the first hop from the root determines the next hop(s) for everything deeper in the tree, and the identity of the next hop(s) is carried along as the algorithm goes deeper into the tree. There's no need to walk the tree after it's calculated (in fact, most implementations don't even bother storing the tree as it's calculated.) --Dave On Oct 24, 2007, at 8:55 AM, HeinerHummel@aol.com wrote: > It may sound like a newbie question and therefore I would be > grateful if someone will help with clarification: > > How is the next hop wrt to destination node d inside an OSPF- > network determined? > > Assumption: At first the current (=root) node computes the Dijkstra > SPT and then navigates from each network node, e.g. from node d, > towards the root of the SPT as to determine the respective root > adjacent link. > > Can anyone confirm/correct me? --Apple-Mail-12-184592420 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Take a look at the algorithm in = the RFC.

Basically, = as the SPT is calculated, the first hop from the root determines the = next hop(s) for everything deeper in the tree, and the identity of the = next hop(s) is carried along as the algorithm goes deeper into the = tree.=A0 There's no need to walk the tree after it's calculated (in = fact, most implementations don't even bother storing the tree as it's = calculated.)

--Dave

On Oct 24, 2007, at 8:55 AM, HeinerHummel@aol.com = wrote:

It may sound like a newbie question and therefore I = would be grateful if someone will help with clarification:
=
=A0
How is the next hop wrt to destination node d inside = an OSPF-network determined?
=A0
Assumption: At = first the current (=3Droot) node computes the Dijkstra SPT and then = navigates from each network node, e.g. from node d, towards the root of = the SPT as to determine the respective root adjacent link.
=
=A0
Can anyone confirm/correct = me?
= --Apple-Mail-12-184592420-- --===============1550973481== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1550973481==-- From ospf-bounces@ietf.org Wed Oct 24 13:23:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkjuC-00012I-AI; Wed, 24 Oct 2007 13:20:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkjuB-0000qS-1z for ospf@ietf.org; Wed, 24 Oct 2007 13:20:31 -0400 Received: from imo-m28.mx.aol.com ([64.12.137.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkjtW-00036x-Ii for ospf@ietf.org; Wed, 24 Oct 2007 13:19:50 -0400 Received: from HeinerHummel@aol.com by imo-m28.mx.aol.com (mail_out_v38_r9.3.) id 1.c5e.20f00617 (39954); Wed, 24 Oct 2007 13:19:39 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Wed, 24 Oct 2007 13:19:39 EDT Subject: Re: [OSPF] next hop determination To: dkatz@juniper.net MIME-Version: 1.0 X-Mailer: AOL 9.0 VR sub 52 X-Spam-Flag: NO X-Spam-Score: 1.8 (+) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1109631948==" Errors-To: ospf-bounces@ietf.org --===============1109631948== Content-Type: multipart/alternative; boundary="-----------------------------1193246379" -------------------------------1193246379 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 24.10.2007 17:36:28 Westeurop=E4ische Normalzeit schreibt= =20 dkatz@juniper.net: Take a look at the algorithm in the RFC. =20 Basically, as the SPT is calculated, the first hop from the root determines= =20 the next hop(s) for everything deeper in the tree, and the identity of the=20 next hop(s) is carried along as the algorithm goes deeper into the tree. =20 There's no need to walk the tree after it's calculated (in fact, most=20 implementations don't even bother storing the tree as it's calculated.) --Dave Exactly. That's what I would have suggested otherwise. =20 Thanks Dave anyway =20 Heiner =20 =20 On Oct 24, 2007, at 8:55 AM, _HeinerHummel@aol.com_=20 (mailto:HeinerHummel@aol.com) wrote: It may sound like a newbie question and therefore I would be grateful if=20 someone will help with clarification: =20 How is the next hop wrt to destination node d inside an OSPF-network =20 determined? =20 Assumption: At first the current (=3Droot) node computes the Dijkstra SPT a= nd=20 then navigates from each network node, e.g. from node d, towards the root o= f=20 the SPT as to determine the respective root adjacent link. =20 Can anyone confirm/correct me? =3D =20 =20 -------------------------------1193246379 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
 
In einer eMail vom 24.10.2007 17:36:28 Westeurop=E4ische Normalzeit sch= reibt=20 dkatz@juniper.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Take a=20 look at the algorithm in the RFC.=20

Basically, as the SPT is calculated, the first hop from the root=20 determines the next hop(s) for everything deeper in the tree, and the iden= tity=20 of the next hop(s) is carried along as the algorithm goes deeper into the=20 tree.  There's no need to walk the tree after it's calculated (in fac= t,=20 most implementations don't even bother storing the tree as it's=20 calculated.)

--Dave
Exactly. That's what I would have suggested otherwise.
 
Thanks Dave anyway
 
Heiner
 
 
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>

On Oct 24, 2007, at 8:55 AM, HeinerHummel@aol.com wrote:
=
It may sound like a newbie question and therefore I would be gratef= ul=20 if someone will help with clarification:
 
How is the next hop wrt to destination node d inside an OSPF-networ= k=20 determined?
 
Assumption: At first the current (=3Droot) node computes the Dijkst= ra SPT=20 and then navigates from each network node, e.g. from node d, towards the= =20 root of the SPT as to determine the respective root adjacent link.
 
Can anyone confirm/correct=20 me?
=3D
 
 -------------------------------1193246379-- --===============1109631948== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1109631948==-- From ospf-bounces@ietf.org Wed Oct 24 22:40:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IksZZ-0005eB-6N; Wed, 24 Oct 2007 22:35:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IksZX-0005ad-8l for ospf@ietf.org; Wed, 24 Oct 2007 22:35:47 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IksZQ-0004vL-TK for ospf@ietf.org; Wed, 24 Oct 2007 22:35:47 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQG00G9D4HW2D@szxga02-in.huawei.com> for ospf@ietf.org; Thu, 25 Oct 2007 10:34:45 +0800 (CST) Received: from M55527 ([10.111.12.186]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQG00KYX4HWX5@szxga02-in.huawei.com> for ospf@ietf.org; Thu, 25 Oct 2007 10:34:44 +0800 (CST) Date: Thu, 25 Oct 2007 10:34:44 +0800 From: Mach Chen To: OSPF List Message-id: <200710251034437516774@huawei.com> Organization: Huawei MIME-version: 1.0 X-Mailer: Foxmail 6, 10, 201, 20 [cn] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [OSPF] About extensions to OSPF in support of inter-AS TE. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi OSPFers, After discussion on the OSPF list and considering how we include inter-AS TE function in OSPFv3, we propose to change the mechanism for OSPFv2 to use a new and separate opaque LSA for inter-AS TE links(Main purpose is to make sure that the OSPFv2 and v3 implementations are samilar). Before we change the draft, we want to give you an opportunity to discuss this if you disagree. You can find the draft by:http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-01.txt Best regards, Mach Chen _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From Farhan@jonathanejackson.com Wed Oct 24 23:04:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikt1F-0007Hh-Ej for ospf-archive@megatron.ietf.org; Wed, 24 Oct 2007 23:04:25 -0400 Received: from ccm170.neoplus.adsl.tpnet.pl ([83.30.136.170] helo=ccp103.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikt1E-0001Bv-My for ospf-archive@megatron.ietf.org; Wed, 24 Oct 2007 23:04:25 -0400 Received: from adrianst ([110.137.34.105] helo=adrianst) by ccp103.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1uSNzI-000IAF-oj for ospf-archive@megatron.ietf.org; Thu, 25 Oct 2007 05:04:44 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 25 Oct 2007 05:04:32 +0200 To: ospf-archive@megatron.ietf.org From: "Farhan Menezes" Subject: volihsud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Greets ospf-archive give her the full sausage when you increase your cock size http://ritzeix.com/ Farhan Menezes From MAILER-DAEMON Thu Oct 25 00:51:15 2007 Return-path: <> Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikugd-0002kZ-7W for ospf-archive@lists.ietf.org; Thu, 25 Oct 2007 00:51:15 -0400 Received: from [62.149.33.238] (helo=server.alpsp.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikugc-0007MG-0a for ospf-archive@lists.ietf.org; Thu, 25 Oct 2007 00:51:15 -0400 From: postmaster@alpsp.org To: ospf-archive@lists.ietf.org Date: Thu, 25 Oct 2007 05:52:21 +0100 MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="9B095B5ADSN=_01C7FB9665B5F23C00011AB1server.alpsp.org" X-DSNContext: 335a7efd - 4523 - 00000001 - 80040546 Message-ID: <8oOBpvfwt000041ee@server.alpsp.org> Subject: Delivery Status Notification (Failure) X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a MIME-formatted message. Portions of this message may be unreadable without a MIME-capable mail program. --9B095B5ADSN=_01C7FB9665B5F23C00011AB1server.alpsp.org Content-Type: text/plain; charset=unicode-1-1-utf-7 This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. sally.morris@alpsp.org --9B095B5ADSN=_01C7FB9665B5F23C00011AB1server.alpsp.org Content-Type: message/delivery-status Reporting-MTA: dns;server.alpsp.org Received-From-MTA: dns;lists.ietf.org Arrival-Date: Thu, 25 Oct 2007 05:52:15 +0100 Final-Recipient: rfc822;sally.morris@alpsp.org Action: failed Status: 5.1.1 --9B095B5ADSN=_01C7FB9665B5F23C00011AB1server.alpsp.org Content-Type: message/rfc822 Received: from lists.ietf.org ([195.46.1.97]) by server.alpsp.org with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 05:52:15 +0100 From: To: Subject: Mail System Error - Returned Mail Date: Thu, 25 Oct 2007 07:44:21 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_31C25B57.E1C45EA6" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Return-Path: Message-ID: x-originalarrivaltime: 25 Oct 2007 04:52:15.0781 (UTC) FILETIME=[D0839550:01C816C2] This is a multi-part message in MIME format. ------=_NextPart_000_0010_31C25B57.E1C45EA6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The original message was received at Thu, 25 Oct 2007 07:44:21 +0300 from lists.ietf.org [86.146.73.139] ----- The following addresses had permanent fatal errors ----- ------=_NextPart_000_0010_31C25B57.E1C45EA6 Content-Type: application/octet-stream; name="transcript.zip" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="transcript.zip" ------=_NextPart_000_0010_31C25B57.E1C45EA6-- --9B095B5ADSN=_01C7FB9665B5F23C00011AB1server.alpsp.org-- From ospf-bounces@ietf.org Thu Oct 25 09:12:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2TS-00031I-L0; Thu, 25 Oct 2007 09:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2TR-000319-5V for ospf@ietf.org; Thu, 25 Oct 2007 09:10:09 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il2TL-0002qx-Vg for ospf@ietf.org; Thu, 25 Oct 2007 09:10:09 -0400 Received: by wx-out-0506.google.com with SMTP id s8so466451wxc for ; Thu, 25 Oct 2007 06:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=JM6W16deolQBohQoUMEgfUeDrzPxPvgzZlws6OxFRD8=; b=bnc/nupQagqsKflnDwy1WNOUyXXzW3dJmYqsoOHcm8XtIDxs2+hk6VrAnRiwn6d+k4ZwPiYsKrGKWQBPB5tWgqcepNpaeQdOThN3597fE/C/VkF30aT7CvvX741ryPlhw0IdrbfCkLRGKIS6XsfjcfSnlF46+/7QtvIMSjXVxxc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Dvt6nHD66iUBiC8AG6Mb7MAFBJ79jjaV4S2x4E6d7eEPRjQcpxpshtrvo723pRgB0dagSQb7Rf5XKY8igYcvT2RhHLrZAJx/DbUq2c5fAGwZNUycOzXLF24MqwgzZRkUBsblJn8Kn/h3MiD8j7+HT8j4zmCh1oKyLRvZDSeBTkw= Received: by 10.90.51.17 with SMTP id y17mr1477119agy.1193317789457; Thu, 25 Oct 2007 06:09:49 -0700 (PDT) Received: by 10.90.118.10 with HTTP; Thu, 25 Oct 2007 06:09:49 -0700 (PDT) Message-ID: Date: Thu, 25 Oct 2007 18:39:49 +0530 From: "techmail technology" To: "Acee Lindem" Subject: Re: [OSPF] Cisco doesn't choose low cost path to ASBR if rfc1583Compatibility is enabled ...!!! why??? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 1.3 (+) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi All, I just got curious to know (since I have a related problem to solve in our router), how the router should behave in the case of multiple ASBRs scenario, in both the cases when rfc1583compatible is enabled/disabled. When there are multiple ASBRs in the autonomous system, each originating a type-5 AS external LSA for a single external destination say N1, how does the rules in section 16.4 should be applied by a router to compute the paths to N1. How does the router prune from among the number of ECMP paths available to each of those ASBRs. rfc 2328 doesn't not talk about the multiple ASBR scenario. It explains the rules in section 16.4 assuming multiple paths to a single ASBR. But if there are multiple paths to multiple ASBRs, should the rules be simply be extended or is there something more to it. Please explain. Thanks in advance. regards, Shashidhar On 2/28/07, Acee Lindem wrote: > Hi Shashidhar, > > Are you testing with multiple ASBRs or multiple paths to a single ASBR? > > I suspect it is the latter. In this case, RFC 2328 (or 1583 for that > matter) isn't completely clear as to whether the selection rules > extend to a single ASBR path lockup. Given where we are in OSPFv2 > life cycle and being the pragmatic WG chair that I am, I'd say this > is an implementation choice. Personally, I've worked on > implementations doing it both ways. > > Besides, everyone should be using the new ASBR selection rules by > now and for OSPFv3 these are the only rules. > > Thanks, > Acee > > On Feb 28, 2007, at 6:43 AM, techmail technology wrote: > > > Hi All, > > > > I have one interesting question regarding the behavior of certain > > routers (including CISCO), when rfc1583Compatibility is enabled. (By > > default it is disabled). > > > > According to rfc2328, it clearly says in section 16.4, when > > rfc1583Compatibility is enabled, the preference rules mentioned in > > 16.4.1 should not be applied in choosing the best path to ASBR. > > Instead it should select the path based on the cost only i.e whichever > > path has the lowest cost should be considered as the best path, and if > > there are multiple low cost paths to ASBR, then choose that path > > through highest AREA ID, when considered as an unsigned integer. > > > > With this background, I tested the behavior of CISCO series 2651 IOS > > software release 12.4. I was surprised with the CISCO's behavior. > > Instead of choosing a low cost path when rfc1583compatibility is > > enabled, it continued to select the path to ASBR based on the > > preference rules (i.e path through non-backbone intra-area path). > > > > I know that rfc2328 uses preference rules specified in 16.4.1 to avoid > > formation of routing loops, in rfc1583 implementation in certain > > topologies as explained by Richard Woundy in rfc2178. But still > > network provider can have a topology where there is no chance of such > > loops forming, so he may want to use rfc1583 behavior to select the > > low cost path to ASBR, CISCO doesn't seem to be allowing that. > > > > Is there any specific reason why CISCO doesn't allow such behavior, I > > couldn't immediately find the reason, why CISCO(as well as other > > implementations like IP Infusion ZebOS) is behaving like this. If > > there are multiple routers behaving similarly, but not the way rfc2328 > > has specified, then there must be some reason. > > > > Does any one know the reason to this behavior ? > > > > regards, > > Shashidhar > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Oct 25 09:33:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2p4-0008IU-6k; Thu, 25 Oct 2007 09:32:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2p3-0008Dd-6B for ospf@ietf.org; Thu, 25 Oct 2007 09:32:29 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il2p2-0006pX-GC for ospf@ietf.org; Thu, 25 Oct 2007 09:32:29 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D4DD68317E9; Thu, 25 Oct 2007 06:32:27 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02317-04; Thu, 25 Oct 2007 06:32:27 -0700 (PDT) Received: from [*???O??IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 5CD658317EB; Thu, 25 Oct 2007 06:32:27 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <929C8B47-9F31-46BA-8CEF-8431F5A64BCF@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] Cisco doesn't choose low cost path to ASBR if rfc1583Compatibility is enabled ...!!! why??? Date: Thu, 25 Oct 2007 09:30:50 -0400 To: "techmail technology" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 1.3 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org On Oct 25, 2007, at 9:09 AM, techmail technology wrote: > Hi All, > > I just got curious to know (since I have a related problem to solve in > our router), how the router should behave in the case of multiple > ASBRs scenario, in both the cases when rfc1583compatible is > enabled/disabled. > > When there are multiple ASBRs in the autonomous system, each > originating a type-5 AS external LSA for a single external destination > say N1, how does the rules in section 16.4 should be applied by a > router to compute the paths to N1. How does the router prune from > among the number of ECMP paths available to each of those ASBRs. rfc > 2328 doesn't not talk about the multiple ASBR scenario. It explains > the rules in section 16.4 assuming multiple paths to a single ASBR. > But if there are multiple paths to multiple ASBRs, should the rules be > simply be extended or is there something more to it. Please explain. I'd say this should be an implementation choice based on the following: 1. It is not covered in RFC 2338. 2. I don't see a problem with routing loops if one router selects multiple ASBRs and another selects a single ASBR (given the other rules are followed). Please feel free to prove me wrong. 3. We can't retroactively mandate this. We'd really need to do this with a WG document and I don't see that this is a problem that needs to be solved. Thanks, Acee > > Thanks in advance. > > regards, > Shashidhar > > On 2/28/07, Acee Lindem wrote: >> Hi Shashidhar, >> >> Are you testing with multiple ASBRs or multiple paths to a single >> ASBR? >> >> I suspect it is the latter. In this case, RFC 2328 (or 1583 for that >> matter) isn't completely clear as to whether the selection rules >> extend to a single ASBR path lockup. Given where we are in OSPFv2 >> life cycle and being the pragmatic WG chair that I am, I'd say this >> is an implementation choice. Personally, I've worked on >> implementations doing it both ways. >> >> Besides, everyone should be using the new ASBR selection rules by >> now and for OSPFv3 these are the only rules. >> >> Thanks, >> Acee >> >> On Feb 28, 2007, at 6:43 AM, techmail technology wrote: >> >>> Hi All, >>> >>> I have one interesting question regarding the behavior of certain >>> routers (including CISCO), when rfc1583Compatibility is enabled. (By >>> default it is disabled). >>> >>> According to rfc2328, it clearly says in section 16.4, when >>> rfc1583Compatibility is enabled, the preference rules mentioned in >>> 16.4.1 should not be applied in choosing the best path to ASBR. >>> Instead it should select the path based on the cost only i.e >>> whichever >>> path has the lowest cost should be considered as the best path, >>> and if >>> there are multiple low cost paths to ASBR, then choose that path >>> through highest AREA ID, when considered as an unsigned integer. >>> >>> With this background, I tested the behavior of CISCO series 2651 IOS >>> software release 12.4. I was surprised with the CISCO's behavior. >>> Instead of choosing a low cost path when rfc1583compatibility is >>> enabled, it continued to select the path to ASBR based on the >>> preference rules (i.e path through non-backbone intra-area path). >>> >>> I know that rfc2328 uses preference rules specified in 16.4.1 to >>> avoid >>> formation of routing loops, in rfc1583 implementation in certain >>> topologies as explained by Richard Woundy in rfc2178. But still >>> network provider can have a topology where there is no chance of >>> such >>> loops forming, so he may want to use rfc1583 behavior to select the >>> low cost path to ASBR, CISCO doesn't seem to be allowing that. >>> >>> Is there any specific reason why CISCO doesn't allow such >>> behavior, I >>> couldn't immediately find the reason, why CISCO(as well as other >>> implementations like IP Infusion ZebOS) is behaving like this. If >>> there are multiple routers behaving similarly, but not the way >>> rfc2328 >>> has specified, then there must be some reason. >>> >>> Does any one know the reason to this behavior ? >>> >>> regards, >>> Shashidhar >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Oct 25 09:41:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2xR-0000fN-SN; Thu, 25 Oct 2007 09:41:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2xQ-0000fI-KX for ospf@ietf.org; Thu, 25 Oct 2007 09:41:08 -0400 Received: from no-more.cisco.com ([64.104.206.251] helo=av-tac-apt.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il2xJ-0003iB-J5 for ospf@ietf.org; Thu, 25 Oct 2007 09:41:08 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-apt.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9PDefB21087; Thu, 25 Oct 2007 23:40:41 +1000 (EST) Received: from [144.254.14.152] (dhcp-peg2-vl21-144-254-14-152.cisco.com [144.254.14.152]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9PDecI18969; Thu, 25 Oct 2007 15:40:38 +0200 (CEST) Message-ID: <47209CD5.9000804@cisco.com> Date: Thu, 25 Oct 2007 15:40:37 +0200 From: Anton Smirnov Organization: Cisco Systems, Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: techmail technology Subject: Re: [OSPF] Cisco doesn't choose low cost path to ASBR if rfc1583Compatibility is enabled ...!!! why??? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Shashidhar, this list is not a proper place to ask questions about vendor-specific behavior. Regarding question on what should be happening - please refer to updated algorithm to compute and compare routes to external destinations described in RFC 3101. It applies to both NSSA and external routes and has tiebreaker if advertisements from two ASBRs seem undestinguishingly equal. Thanks, Anton techmail technology wrote: > Hi All, > > I just got curious to know (since I have a related problem to solve in > our router), how the router should behave in the case of multiple > ASBRs scenario, in both the cases when rfc1583compatible is > enabled/disabled. > > When there are multiple ASBRs in the autonomous system, each > originating a type-5 AS external LSA for a single external destination > say N1, how does the rules in section 16.4 should be applied by a > router to compute the paths to N1. How does the router prune from > among the number of ECMP paths available to each of those ASBRs. rfc > 2328 doesn't not talk about the multiple ASBR scenario. It explains > the rules in section 16.4 assuming multiple paths to a single ASBR. > But if there are multiple paths to multiple ASBRs, should the rules be > simply be extended or is there something more to it. Please explain. > > Thanks in advance. > > regards, > Shashidhar > > On 2/28/07, Acee Lindem wrote: >> Hi Shashidhar, >> >> Are you testing with multiple ASBRs or multiple paths to a single ASBR? >> >> I suspect it is the latter. In this case, RFC 2328 (or 1583 for that >> matter) isn't completely clear as to whether the selection rules >> extend to a single ASBR path lockup. Given where we are in OSPFv2 >> life cycle and being the pragmatic WG chair that I am, I'd say this >> is an implementation choice. Personally, I've worked on >> implementations doing it both ways. >> >> Besides, everyone should be using the new ASBR selection rules by >> now and for OSPFv3 these are the only rules. >> >> Thanks, >> Acee >> >> On Feb 28, 2007, at 6:43 AM, techmail technology wrote: >> >>> Hi All, >>> >>> I have one interesting question regarding the behavior of certain >>> routers (including CISCO), when rfc1583Compatibility is enabled. (By >>> default it is disabled). >>> >>> According to rfc2328, it clearly says in section 16.4, when >>> rfc1583Compatibility is enabled, the preference rules mentioned in >>> 16.4.1 should not be applied in choosing the best path to ASBR. >>> Instead it should select the path based on the cost only i.e whichever >>> path has the lowest cost should be considered as the best path, and if >>> there are multiple low cost paths to ASBR, then choose that path >>> through highest AREA ID, when considered as an unsigned integer. >>> >>> With this background, I tested the behavior of CISCO series 2651 IOS >>> software release 12.4. I was surprised with the CISCO's behavior. >>> Instead of choosing a low cost path when rfc1583compatibility is >>> enabled, it continued to select the path to ASBR based on the >>> preference rules (i.e path through non-backbone intra-area path). >>> >>> I know that rfc2328 uses preference rules specified in 16.4.1 to avoid >>> formation of routing loops, in rfc1583 implementation in certain >>> topologies as explained by Richard Woundy in rfc2178. But still >>> network provider can have a topology where there is no chance of such >>> loops forming, so he may want to use rfc1583 behavior to select the >>> low cost path to ASBR, CISCO doesn't seem to be allowing that. >>> >>> Is there any specific reason why CISCO doesn't allow such behavior, I >>> couldn't immediately find the reason, why CISCO(as well as other >>> implementations like IP Infusion ZebOS) is behaving like this. If >>> there are multiple routers behaving similarly, but not the way rfc2328 >>> has specified, then there must be some reason. >>> >>> Does any one know the reason to this behavior ? >>> >>> regards, >>> Shashidhar >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ospf >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Oct 25 10:01:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3Fp-0003RP-QO; Thu, 25 Oct 2007 10:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3Fo-0003Qt-39 for ospf@ietf.org; Thu, 25 Oct 2007 10:00:08 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il3Fd-0004QT-UO for ospf@ietf.org; Thu, 25 Oct 2007 10:00:08 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7D443AAB5C1; Thu, 25 Oct 2007 06:59:52 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06758-02; Thu, 25 Oct 2007 06:59:52 -0700 (PDT) Received: from [ZJ??O??IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id D20B2AAB5BE; Thu, 25 Oct 2007 06:59:49 -0700 (PDT) In-Reply-To: <47209CD5.9000804@cisco.com> References: <47209CD5.9000804@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Acee Lindem Subject: Re: [OSPF] Cisco doesn't choose low cost path to ASBR if rfc1583Compatibility is enabled ...!!! why??? Date: Thu, 25 Oct 2007 09:58:12 -0400 To: Anton Smirnov X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 1.3 (+) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1515132458==" Errors-To: ospf-bounces@ietf.org --===============1515132458== Content-Type: multipart/alternative; boundary=Apple-Mail-21-265127518 --Apple-Mail-21-265127518 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Anton, On Oct 25, 2007, at 9:40 AM, Anton Smirnov wrote: > Hi Shashidhar, > this list is not a proper place to ask questions about vendor- > specific behavior. > Regarding question on what should be happening - please refer to > updated algorithm to compute and compare routes to external > destinations described in RFC 3101. It applies to both NSSA and > external routes and has tiebreaker if advertisements from two ASBRs > seem undestinguishingly equal. Nope. As pointed out by Pat Murphy, that tie break ONLY applies if the LSA has the same prefix, cost, AND non-zero forwarding address. In this case, the next-hops are inherited from the forwarding address route anyway so it shouldn't make a difference. Excerpted from RFC 3101: (e) If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred: 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. From an implementation standpoint, I don't see a reason not to use multiple ASBRs (given the other rules are followed). Thanks, Acee > Thanks, > > Anton > > > > techmail technology wrote: >> Hi All, >> I just got curious to know (since I have a related problem to >> solve in >> our router), how the router should behave in the case of multiple >> ASBRs scenario, in both the cases when rfc1583compatible is >> enabled/disabled. >> When there are multiple ASBRs in the autonomous system, each >> originating a type-5 AS external LSA for a single external >> destination >> say N1, how does the rules in section 16.4 should be applied by a >> router to compute the paths to N1. How does the router prune from >> among the number of ECMP paths available to each of those ASBRs. rfc >> 2328 doesn't not talk about the multiple ASBR scenario. It explains >> the rules in section 16.4 assuming multiple paths to a single ASBR. >> But if there are multiple paths to multiple ASBRs, should the >> rules be >> simply be extended or is there something more to it. Please explain. >> Thanks in advance. >> regards, >> Shashidhar >> On 2/28/07, Acee Lindem wrote: >>> Hi Shashidhar, >>> >>> Are you testing with multiple ASBRs or multiple paths to a single >>> ASBR? >>> >>> I suspect it is the latter. In this case, RFC 2328 (or 1583 for that >>> matter) isn't completely clear as to whether the selection rules >>> extend to a single ASBR path lockup. Given where we are in OSPFv2 >>> life cycle and being the pragmatic WG chair that I am, I'd say this >>> is an implementation choice. Personally, I've worked on >>> implementations doing it both ways. >>> >>> Besides, everyone should be using the new ASBR selection rules by >>> now and for OSPFv3 these are the only rules. >>> >>> Thanks, >>> Acee >>> >>> On Feb 28, 2007, at 6:43 AM, techmail technology wrote: >>> >>>> Hi All, >>>> >>>> I have one interesting question regarding the behavior of certain >>>> routers (including CISCO), when rfc1583Compatibility is enabled. >>>> (By >>>> default it is disabled). >>>> >>>> According to rfc2328, it clearly says in section 16.4, when >>>> rfc1583Compatibility is enabled, the preference rules mentioned in >>>> 16.4.1 should not be applied in choosing the best path to ASBR. >>>> Instead it should select the path based on the cost only i.e >>>> whichever >>>> path has the lowest cost should be considered as the best path, >>>> and if >>>> there are multiple low cost paths to ASBR, then choose that path >>>> through highest AREA ID, when considered as an unsigned integer. >>>> >>>> With this background, I tested the behavior of CISCO series 2651 >>>> IOS >>>> software release 12.4. I was surprised with the CISCO's behavior. >>>> Instead of choosing a low cost path when rfc1583compatibility is >>>> enabled, it continued to select the path to ASBR based on the >>>> preference rules (i.e path through non-backbone intra-area path). >>>> >>>> I know that rfc2328 uses preference rules specified in 16.4.1 to >>>> avoid >>>> formation of routing loops, in rfc1583 implementation in certain >>>> topologies as explained by Richard Woundy in rfc2178. But still >>>> network provider can have a topology where there is no chance of >>>> such >>>> loops forming, so he may want to use rfc1583 behavior to select the >>>> low cost path to ASBR, CISCO doesn't seem to be allowing that. >>>> >>>> Is there any specific reason why CISCO doesn't allow such >>>> behavior, I >>>> couldn't immediately find the reason, why CISCO(as well as other >>>> implementations like IP Infusion ZebOS) is behaving like this. If >>>> there are multiple routers behaving similarly, but not the way >>>> rfc2328 >>>> has specified, then there must be some reason. >>>> >>>> Does any one know the reason to this behavior ? >>>> >>>> regards, >>>> Shashidhar >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ospf >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf --Apple-Mail-21-265127518 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Anton,

On = Oct 25, 2007, at 9:40 AM, Anton Smirnov wrote:

=A0=A0 = Hi Shashidhar,
=A0=A0 this list is not a proper = place to ask questions about vendor-specific behavior.
=A0=A0 = Regarding question on what should be happening - please refer to = updated algorithm to compute and compare routes to external destinations = described in RFC 3101. It applies to both NSSA and external routes and = has tiebreaker if advertisements from two ASBRs seem undestinguishingly = equal.

Nope. As pointed out by Pat = Murphy, that tie break ONLY applies if the LSA has the same prefix, = cost, AND non-zero forwarding address. In this case, the next-hops are = inherited from the forwarding address route anyway so it shouldn't make = a difference. Excerpted from RFC 3101:

=A0(e) If the current LSA is = functionally the same as an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = installed LSA = (i.e., same destination, cost and non-zero
=A0= =A0 =A0 =A0 =A0 =A0 =A0 forwarding address) then apply the following = priorities in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = deciding = which LSA is preferred:

=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1. A Type-7 LSA with the P-bit set.

=A0=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 2. A = Type-5 LSA.

=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3. The LSA with the higher router = ID.


=46rom an implementation = standpoint, I don't see a reason not to use multiple ASBRs (given the = other rules are followed).=A0

Thanks,
Acee
<= DIV>

=A0=A0 Thanks,




techmail = technology wrote:
Hi All,
I just got = curious to know (since I have a related problem to solve in
our router), how the router should behave in the = case of multiple
ASBRs scenario, in both the = cases when rfc1583compatible is
When there are multiple = ASBRs in the autonomous system, each
originating a = type-5 AS external LSA for a single external destination
say N1, how does the rules in section 16.4 should be = applied by a
router to compute the paths to = N1. How does the router prune from
among the = number of ECMP paths available to each of those ASBRs. rfc
2328 doesn't not talk about the multiple ASBR = scenario. It explains
the rules in section 16.4 = assuming multiple paths to a single ASBR.
But if = there are multiple paths to multiple ASBRs, should the rules = be
simply be extended or is there something more = to it. Please explain.
Thanks in = advance.
regards,
Shashidhar
On 2/28/07, = Acee Lindem <acee@redback.com> wrote:
=
Hi Shashidhar,

Are you = testing with multiple ASBRs or multiple paths to a single = ASBR?

I suspect it is the latter. In this case, RFC 2328 = (or 1583 for that
matter) isn't completely clear = as to whether the selection rules
extend to a = single ASBR path lockup. Given where we are in OSPFv2
life cycle and being the pragmatic WG chair that I = am, I'd say this
is an implementation choice. = Personally, I've worked on

=A0 Besides,=A0 everyone should be using the = new ASBR selection rules by
now and for = OSPFv3 these are the only rules.

Thanks,
Acee

On Feb 28, 2007, at 6:43 AM, = techmail technology wrote:

Hi = All,

I have one interesting question regarding the = behavior of certain
routers (including CISCO), = when rfc1583Compatibility is enabled. (By
default = it is disabled).

According to rfc2328, it clearly says in section = 16.4, when
rfc1583Compatibility is enabled, = the preference rules mentioned in
16.4.1 should = not be applied in choosing the best path to ASBR.
Instead it should select the path based on the cost = only i.e whichever
path has the lowest cost = should be considered as the best path, and if
there are multiple low cost paths to ASBR, then = choose that path
through highest AREA ID, when = considered as an unsigned integer.

With this background, I tested = the behavior of CISCO series 2651 IOS
software = release 12.4. I was surprised with the CISCO's behavior.
Instead of choosing a low cost path when = rfc1583compatibility is
enabled, it = continued to select the path to ASBR based on the
preference rules (i.e path through non-backbone = intra-area path).

I know that rfc2328 uses preference rules specified = in 16.4.1 to avoid
formation of routing loops, = in rfc1583 implementation in certain
topologies as = explained by Richard Woundy in rfc2178. But still
network provider can have a topology where there is = no chance of such
loops forming, so he may want to = use rfc1583 behavior to select the
low cost path = to ASBR, CISCO doesn't seem to be allowing that.

Is there = any specific reason why CISCO doesn't allow such behavior, I
couldn't immediately find the reason, why CISCO(as = well as other
implementations like IP Infusion = ZebOS) is behaving like this. If
there are = multiple routers behaving similarly, but not the way rfc2328
has specified, then there must be some = reason.

Does any one know the reason to this behavior = ?

regards,

OSPF mailing list

OSPF mailing list

OSPF mailing list
=

= --Apple-Mail-21-265127518-- --===============1515132458== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1515132458==-- From ospf-bounces@ietf.org Thu Oct 25 10:12:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3Q4-0004kb-MB; Thu, 25 Oct 2007 10:10:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3Q3-0004kQ-3h for ospf@ietf.org; Thu, 25 Oct 2007 10:10:43 -0400 Received: from no-more.cisco.com ([64.104.206.251] helo=av-tac-apt.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il3Q2-0008H3-0O for ospf@ietf.org; Thu, 25 Oct 2007 10:10:43 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-apt.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9PEAca01041; Fri, 26 Oct 2007 00:10:38 +1000 (EST) Received: from [144.254.14.152] (dhcp-peg2-vl21-144-254-14-152.cisco.com [144.254.14.152]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9PEAZI10838; Thu, 25 Oct 2007 16:10:35 +0200 (CEST) Message-ID: <4720A3DA.3040003@cisco.com> Date: Thu, 25 Oct 2007 16:10:34 +0200 From: Anton Smirnov Organization: Cisco Systems, Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] Cisco doesn't choose low cost path to ASBR if rfc1583Compatibility is enabled ...!!! why??? References: <47209CD5.9000804@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Acee, > AND non-zero forwarding address I missed this. Thanks for correcting. Thanks, Anton Acee Lindem wrote: > Hi Anton, > > On Oct 25, 2007, at 9:40 AM, Anton Smirnov wrote: > >> Hi Shashidhar, >> this list is not a proper place to ask questions about >> vendor-specific behavior. >> Regarding question on what should be happening - please refer to >> updated algorithm to compute and compare routes to external >> destinations described in RFC 3101. It applies to both NSSA and >> external routes and has tiebreaker if advertisements from two ASBRs >> seem undestinguishingly equal. > > Nope. As pointed out by Pat Murphy, that tie break ONLY applies if the > LSA has the same prefix, cost, AND non-zero forwarding address. In this > case, the next-hops are inherited from the forwarding address route > anyway so it shouldn't make a difference. Excerpted from RFC 3101: > > (e) If the current LSA is functionally the same as an > installed LSA (i.e., same destination, cost and non-zero > forwarding address) then apply the following priorities in > deciding which LSA is preferred: > > 1. A Type-7 LSA with the P-bit set. > > 2. A Type-5 LSA. > > 3. The LSA with the higher router ID. > > > From an implementation standpoint, I don't see a reason not to use > multiple ASBRs (given the other rules are followed). > > Thanks, > Acee > > >> Thanks, >> >> Anton >> >> >> >> techmail technology wrote: >>> Hi All, >>> I just got curious to know (since I have a related problem to solve in >>> our router), how the router should behave in the case of multiple >>> ASBRs scenario, in both the cases when rfc1583compatible is >>> enabled/disabled. >>> When there are multiple ASBRs in the autonomous system, each >>> originating a type-5 AS external LSA for a single external destination >>> say N1, how does the rules in section 16.4 should be applied by a >>> router to compute the paths to N1. How does the router prune from >>> among the number of ECMP paths available to each of those ASBRs. rfc >>> 2328 doesn't not talk about the multiple ASBR scenario. It explains >>> the rules in section 16.4 assuming multiple paths to a single ASBR. >>> But if there are multiple paths to multiple ASBRs, should the rules be >>> simply be extended or is there something more to it. Please explain. >>> Thanks in advance. >>> regards, >>> Shashidhar >>> On 2/28/07, Acee Lindem > >>> wrote: >>>> Hi Shashidhar, >>>> >>>> Are you testing with multiple ASBRs or multiple paths to a single ASBR? >>>> >>>> I suspect it is the latter. In this case, RFC 2328 (or 1583 for that >>>> matter) isn't completely clear as to whether the selection rules >>>> extend to a single ASBR path lockup. Given where we are in OSPFv2 >>>> life cycle and being the pragmatic WG chair that I am, I'd say this >>>> is an implementation choice. Personally, I've worked on >>>> implementations doing it both ways. >>>> >>>> Besides, everyone should be using the new ASBR selection rules by >>>> now and for OSPFv3 these are the only rules. >>>> >>>> Thanks, >>>> Acee >>>> >>>> On Feb 28, 2007, at 6:43 AM, techmail technology wrote: >>>> >>>>> Hi All, >>>>> >>>>> I have one interesting question regarding the behavior of certain >>>>> routers (including CISCO), when rfc1583Compatibility is enabled. (By >>>>> default it is disabled). >>>>> >>>>> According to rfc2328, it clearly says in section 16.4, when >>>>> rfc1583Compatibility is enabled, the preference rules mentioned in >>>>> 16.4.1 should not be applied in choosing the best path to ASBR. >>>>> Instead it should select the path based on the cost only i.e whichever >>>>> path has the lowest cost should be considered as the best path, and if >>>>> there are multiple low cost paths to ASBR, then choose that path >>>>> through highest AREA ID, when considered as an unsigned integer. >>>>> >>>>> With this background, I tested the behavior of CISCO series 2651 IOS >>>>> software release 12.4. I was surprised with the CISCO's behavior. >>>>> Instead of choosing a low cost path when rfc1583compatibility is >>>>> enabled, it continued to select the path to ASBR based on the >>>>> preference rules (i.e path through non-backbone intra-area path). >>>>> >>>>> I know that rfc2328 uses preference rules specified in 16.4.1 to avoid >>>>> formation of routing loops, in rfc1583 implementation in certain >>>>> topologies as explained by Richard Woundy in rfc2178. But still >>>>> network provider can have a topology where there is no chance of such >>>>> loops forming, so he may want to use rfc1583 behavior to select the >>>>> low cost path to ASBR, CISCO doesn't seem to be allowing that. >>>>> >>>>> Is there any specific reason why CISCO doesn't allow such behavior, I >>>>> couldn't immediately find the reason, why CISCO(as well as other >>>>> implementations like IP Infusion ZebOS) is behaving like this. If >>>>> there are multiple routers behaving similarly, but not the way rfc2328 >>>>> has specified, then there must be some reason. >>>>> >>>>> Does any one know the reason to this behavior ? >>>>> >>>>> regards, >>>>> Shashidhar >>>>> >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ospf >>>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From sfcyv@s24.ch Fri Oct 26 15:25:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUoJ-0007FW-IB for ospf-archive@megatron.ietf.org; Fri, 26 Oct 2007 15:25:35 -0400 Received: from [189.70.104.67] (helo=18970104067.user.veloxzone.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlUoC-00013j-HE for ospf-archive@megatron.ietf.org; Fri, 26 Oct 2007 15:25:30 -0400 Received: from EST01 ([166.109.69.110]:10726 "EHLO EST01" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 18970104067.user.veloxzone.com.br with ESMTP id S22BVSILUKQRUFZN (ORCPT ); Fri, 26 Oct 2007 17:25:48 -0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 26 Oct 2007 17:25:20 -0200 To: ospf-archive@megatron.ietf.org From: "antony sf" Subject: niennut Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hallo whats up! ospf-archive its not about how you use it, its about how big your dick is http://www.rugerst.com/ antony sf From yancy-Bergman@radnors.com Sat Oct 27 12:36:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IloeT-0005yN-A9 for ospf-archive@megatron.ietf.org; Sat, 27 Oct 2007 12:36:45 -0400 Received: from lomza3.lom.vectranet.pl ([212.33.64.99]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IloeN-00007z-VM for ospf-archive@megatron.ietf.org; Sat, 27 Oct 2007 12:36:43 -0400 Received: by 10.165.79.43 with SMTP id hcqElRHAzKbuc; Sat, 27 Oct 2007 18:37:01 +0200 (GMT) Received: by 192.168.10.27 with SMTP id JqhRUQyqcbQspa.7652283246936; Sat, 27 Oct 2007 18:36:59 +0200 (GMT) Message-ID: <000c01c818b7$966851c0$634021d4@runescapf49eba> From: "yancy Bergman" To: Subject: ieraiirf Date: Sat, 27 Oct 2007 18:36:56 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C818C8.59F121C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C818C8.59F121C0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi ya ospf-archive her pussy is screaming for some seriously big dick http://www.tarmlsw.com/ yancy Bergman ------=_NextPart_000_0004_01C818C8.59F121C0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Hi ya ospf-archive
her pussy is screaming for some seriously big=20 dick
http://www.tarmlsw.com/
yancy Bergman
------=_NextPart_000_0004_01C818C8.59F121C0-- From stonen@humanitycorp.com Sun Oct 28 18:30:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImGdw-0007ac-VB for ospf-archive@lists.ietf.org; Sun, 28 Oct 2007 18:30:05 -0400 Received: from [219.150.227.141] (helo=[219.150.227.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImGdn-0005wI-0W for ospf-archive@lists.ietf.org; Sun, 28 Oct 2007 18:29:56 -0400 Received: from [219.150.227.141] by smtp.secureserver.net; Mon, 29 Oct 2007 06:29:56 +0800 Message-ID: <01c819f5$1f484110$8de396db@stonen> From: "Thelma Andersen" To: Subject: Gain a immence member Josefina Date: Mon, 29 Oct 2007 06:29:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.1 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Gain a monster massive shlong Grace http://vyciros.com From ospf-bounces@ietf.org Mon Oct 29 09:22:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUUk-0003jq-Lv; Mon, 29 Oct 2007 09:17:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUUk-0003jl-9a for ospf@ietf.org; Mon, 29 Oct 2007 09:17:30 -0400 Received: from n8.bullet.re3.yahoo.com ([68.142.237.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ImUUe-00061A-4C for ospf@ietf.org; Mon, 29 Oct 2007 09:17:30 -0400 Received: from [68.142.230.29] by n8.bullet.re3.yahoo.com with NNFMP; 29 Oct 2007 13:17:09 -0000 Received: from [66.196.101.133] by t2.bullet.re2.yahoo.com with NNFMP; 29 Oct 2007 13:17:09 -0000 Received: from [127.0.0.1] by rrr4.mail.re1.yahoo.com with NNFMP; 29 Oct 2007 13:17:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 987371.48808.bm@rrr4.mail.re1.yahoo.com Received: (qmail 93318 invoked by uid 60001); 29 Oct 2007 13:17:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=FHhkA9OGrH2ULXTwOR+oJA3g0XJ/iRpZryN0gkGoZLiGnG+CgBvf5vLlOzAut4oz+grGtqmxFyXl0Ez8ZLQsceub8dGDxeL/7EpN+AxXH4ah02aXXu0DVqLNXQYKTMubpSE709hV8VksUE26c0b8wdW9oHSFm+5k2DJM01npLX8=; X-YMail-OSG: XoTREI0VM1n219jeRJUXT958FnsNCps.25t0sscwYEGSXe5Xi7.gUddS_7MDwzL2vQ-- Received: from [80.96.82.125] by web57402.mail.re1.yahoo.com via HTTP; Mon, 29 Oct 2007 06:17:08 PDT Date: Mon, 29 Oct 2007 06:17:08 -0700 (PDT) From: Adi Pasca To: ospf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <880208.89146.qm@web57402.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [OSPF] Question about exiting graceful restart (Local Mode) for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, I have one comment/question regarding the exit restart procedure for Local Mode for OSPFv3 ( http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-07.txt ) - in RFC3623, "Section 2.3 Actions on Exiting Graceful Restart" it is said that: (...) 1) The router should reoriginate its router-LSAs for all attached areas in order to make sure they have the correct contents. 2) The router should reoriginate network-LSAs on all segments where it is the Designated Router. (...) >From what I have seen, the draft-ietf-ospf-ospfv3-graceful-restart-07.txt doesn't make any update to the above section, but I was wondering if this is enough in the case of OSPFv3 graceful restart (because for OSPFv3 there are also the Link LSAs and Intra-Area-Prefix LSAs which contribute to the intra-area's topology description); shouldn't the Link LSAs and the Intra-Area-Prefix LSAs be reoriginated also ? One scenario that could lead to neighbors' databases being not synchronized after an restart is as follows: 1. We have two ospf routers (Router_A and Router_B) having configured one ospf area, each having a single interface into that area; 2. Router_A is given a command to restart gracefully; almost simultaneously (after Router_A transmits its Grace LSA) Router_B's ospfv3 is disabled and then enabled (or non-gracefully restarted), so that it cannot act as helper. 3. Hellos are received and the Database Exchange takes place (with Router_A being in graceful restart, so not originating any of its LSAs) 4. After that (when exchange is done), Router_A determines that it should exit restart due to inconsistency (RFC 3623: A special case of LSA inconsistency is when Router X establishes an adjacency with router Y and doesn't receive an instance of its own pre-restart router LSA.) 5. When exiting restart, Router_A reoriginate its Router LSA and, if it is the case, its Network LSA, so Router_B receives those LSAs; but Router_B never receives Router_A's Link LSAs and Intra-Area-Prefix LSAs. Regards, Adrian __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From jerome@tvldyn.com Mon Oct 29 09:39:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUqU-00086y-O0 for ospf-archive@lists.ietf.org; Mon, 29 Oct 2007 09:39:58 -0400 Received: from [189.23.56.130] (helo=189.23.56.130) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImUqP-00078v-UX for ospf-archive@lists.ietf.org; Mon, 29 Oct 2007 09:39:56 -0400 Received: from [189.23.56.130] by PARK3.SECURESERVER.net; Mon, 29 Oct 2007 12:39:30 +0000 Message-ID: <000701c81a28$01eef1b4$8e65d083@pegkn> From: "bren micah" To: Subject: Representative from your Country needed Date: Mon, 29 Oct 2007 10:52:08 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 3.0 (+++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Our Company is a privately owned and operated promoting and marketing firm based in UK, with offices all over the world. We are currently expanding due to client needs. We are looking for candidates that will assist us. Now we offering positions at the entry level for marketing and management role. We train all candidates in: Service Representative Promotions Communications Public Relations Marketing We value your goals and your career; so we will connect you with mentors who can offer you as much guidance as you need. This is a permanent home based position, so anyone ready for a stable career should apply today! To apply for this job, please CUT AND PASTE your resume (NO attachments please) into an e-mail and send it to PierreKellyUO@gmail.com. You can also call us at 1-718-732-2785. If you received this message in error, or would like to unsubscribe, please send a blank email to: FredricLambJB@gmail.com From Kellen_Lorentz@life-mailorder.de Tue Oct 30 04:25:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImmQ6-0005ha-TU for ospf-archive@megatron.ietf.org; Tue, 30 Oct 2007 04:25:54 -0400 Received: from [60.240.142.17] (helo=nme-nxg-pr6.tpgi.com.au) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImmQ6-0001bA-4P for ospf-archive@megatron.ietf.org; Tue, 30 Oct 2007 04:25:54 -0400 Received: from erlinda ([132.117.156.182]:16543 "EHLO erlinda" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by nme-nxg-pr6.tpgi.com.au with ESMTP id S22UFVTGDAKIHKBP (ORCPT ); Tue, 30 Oct 2007 19:26:45 +1100 Message-ID: <000401c81ace$87869b30$88b3f5dc@erlinda> From: "Kellen Lorentz" To: Subject: 2ketl-lr Date: Tue, 30 Oct 2007 19:26:11 +1100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C81B2A.BAF71330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C81B2A.BAF71330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nice to meet you ospf-archive if your relationship has fizzled, fresh it up with a big dick http://www.ucpgt.com/ Kellen Lorentz ------=_NextPart_000_0005_01C81B2A.BAF71330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Nice to meet you ospf-archive
if your relationship has fizzled, fresh it up = with a big=20 dick
http://www.ucpgt.com/
Kellen Lorentz
------=_NextPart_000_0005_01C81B2A.BAF71330-- From Devrup.Ledezma@sedevils.zzn.com Tue Oct 30 10:37:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImsDt-00028K-IW for ospf-archive@megatron.ietf.org; Tue, 30 Oct 2007 10:37:41 -0400 Received: from [85.186.3.219] (helo=[85.186.3.219]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImsDY-0005WA-2u for ospf-archive@megatron.ietf.org; Tue, 30 Oct 2007 10:37:20 -0400 Received: from bratu ([110.135.88.171] helo=bratu) by [85.186.3.219] ( sendmail 8.13.3/8.13.1) with esmtpa id 1ivmXI-000NHV-NA for ospf-archive@megatron.ietf.org; Tue, 30 Oct 2007 16:37:32 +0200 Message-ID: <000b01c81b02$620776c0$db03ba55@bratu> From: "Devrup Ledezma" To: Subject: sehtneoc Date: Tue, 30 Oct 2007 16:37:22 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C81B13.259046C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C81B13.259046C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi ya ospf-archive enlarge your dick and they wont worry about what you look like http://www.batongen.com/ Devrup Ledezma ------=_NextPart_000_0007_01C81B13.259046C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi ya ospf-archive
enlarge your dick and they wont worry about = what you=20 look like
http://www.batongen.com/
Devrup Ledezma
------=_NextPart_000_0007_01C81B13.259046C0-- From prince@telia.com Tue Oct 30 14:27:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvnw-00018e-6t for ospf-archive@megatron.ietf.org; Tue, 30 Oct 2007 14:27:08 -0400 Received: from 088156096130.stk.vectranet.pl ([88.156.96.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imvnr-0004fp-4C for ospf-archive@megatron.ietf.org; Tue, 30 Oct 2007 14:27:04 -0400 Received: from [88.156.96.130] by ns02.savvis.net; Tue, 30 Oct 2007 18:27:13 +0000 Message-ID: <000501c81b22$02338a26$c628ae84@cxief> From: "ezra nathanae" To: Subject: Representative from your Country needed Date: Tue, 30 Oct 2007 16:39:51 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 3.2 (+++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Our Company is a privately owned and operated promoting and marketing firm based in UK, with offices all over the world. We are currently expanding due to client needs. We are looking for candidates that will assist us. Now we offering positions at the entry level for marketing and management role. We train all candidates in: Service Representative Promotions Communications Public Relations Marketing We value your goals and your career; so we will connect you with mentors who can offer you as much guidance as you need. This is a permanent home based position, so anyone ready for a stable career should apply today! To apply for this job, please CUT AND PASTE your resume (NO attachments please) into an e-mail and send it to KarlHaysGJ@gmail.com. You can also call us at 1-718-732-2785. If you received this message in error, or would like to unsubscribe, please send a blank email to: LenardDuncanTQ@gmail.com From shlee@ws.lukoil.com Tue Oct 30 14:27:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvod-000239-TU for ospf-archive@lists.ietf.org; Tue, 30 Oct 2007 14:27:51 -0400 Received: from [189.12.195.141] (helo=18912195141.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imvoc-0004hI-6S for ospf-archive@lists.ietf.org; Tue, 30 Oct 2007 14:27:51 -0400 Received: from [189.12.195.141] by lncomws.ws.lukoil.com; Tue, 30 Oct 2007 18:27:47 +0000 Message-ID: <000801c81b22$02c0566f$d6fa4b97@vqfdaos> From: "konstantin ting-tin" To: Subject: Work from home Date: Tue, 30 Oct 2007 16:40:24 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.9 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Our Company is a privately owned and operated promoting and marketing firm based in UK, with offices all over the world. We are currently expanding due to client needs. We are looking for candidates that will assist us. Now we offering positions at the entry level for marketing and management role. We train all candidates in: Service Representative Promotions Communications Public Relations Marketing We value your goals and your career; so we will connect you with mentors who can offer you as much guidance as you need. This is a permanent home based position, so anyone ready for a stable career should apply today! To apply for this job, please CUT AND PASTE your resume (NO attachments please) into an e-mail and send it to MarisaCashQS@gmail.com. You can also call us at 1-718-732-2785. If you received this message in error, or would like to unsubscribe, please send a blank email to: EmmanuelLottQI@gmail.com From illtyd@digitalmail.com Tue Oct 30 14:28:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImvpO-0002CP-PE for ospf-archive@megatron.ietf.org; Tue, 30 Oct 2007 14:28:38 -0400 Received: from dci113.neoplus.adsl.tpnet.pl ([83.23.60.113]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImvpI-0004iF-UU for ospf-archive@megatron.ietf.org; Tue, 30 Oct 2007 14:28:33 -0400 Received: from [83.23.60.113] by remote2.easydns.com; Tue, 30 Oct 2007 18:28:50 +0000 Message-ID: <000501c81b22$07676aa2$cae525ac@npahb> From: "jean nathalie" To: Subject: Work from home no enter fee Date: Tue, 30 Oct 2007 16:41:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Our Company is a privately owned and operated promoting and marketing firm based in UK, with offices all over the world. We are currently expanding due to client needs. We are looking for candidates that will assist us. Now we offering positions at the entry level for marketing and management role. We train all candidates in: Service Representative Promotions Communications Public Relations Marketing We value your goals and your career; so we will connect you with mentors who can offer you as much guidance as you need. This is a permanent home based position, so anyone ready for a stable career should apply today! To apply for this job, please CUT AND PASTE your resume (NO attachments please) into an e-mail and send it to SueLancasterVI@gmail.com. You can also call us at 1-718-732-2785. If you received this message in error, or would like to unsubscribe, please send a blank email to: LenardDuncanTQ@gmail.com From delbert@mixmail.com Tue Oct 30 14:30:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvr7-00033z-Ej for ospf-archive@lists.ietf.org; Tue, 30 Oct 2007 14:30:25 -0400 Received: from sgo-fw.saogotardo.com.br ([200.202.228.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imvr6-0004la-Lf for ospf-archive@lists.ietf.org; Tue, 30 Oct 2007 14:30:25 -0400 Received: from [200.202.228.3] by dns2.ya.com; Tue, 30 Oct 2007 18:30:15 +0000 Message-ID: <000601c81b22$0335c8dd$cf00069c@ogiia> From: "artus baldemar" To: Subject: Home based business opportunity Date: Tue, 30 Oct 2007 16:42:53 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 3.9 (+++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Our Company is a privately owned and operated promoting and marketing firm based in UK, with offices all over the world. We are currently expanding due to client needs. We are looking for candidates that will assist us. Now we offering positions at the entry level for marketing and management role. We train all candidates in: Service Representative Promotions Communications Public Relations Marketing We value your goals and your career; so we will connect you with mentors who can offer you as much guidance as you need. This is a permanent home based position, so anyone ready for a stable career should apply today! To apply for this job, please CUT AND PASTE your resume (NO attachments please) into an e-mail and send it to LonVelezNI@gmail.com. You can also call us at 1-718-732-2785. If you received this message in error, or would like to unsubscribe, please send a blank email to: LenardDuncanTQ@gmail.com From prakutha@orange.nl Tue Oct 30 20:49:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1lg-00025u-K7 for ospf-archive@lists.ietf.org; Tue, 30 Oct 2007 20:49:12 -0400 Received: from [216.23.126.6] (helo=mail.lacowoodworks.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1In1lZ-0007Zb-N8 for ospf-archive@lists.ietf.org; Tue, 30 Oct 2007 20:49:07 -0400 Received: from pczjb ([93.70.114.127]) by mail.lacowoodworks.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 30 Oct 2007 19:49:13 -0500 Message-ID: <000801c81b57$db77def0$7f72465d@pczjb> From: To: Subject: I played with this for hours Date: Tue, 30 Oct 2007 19:49:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original 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-Spam-Score: 2.8 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Just a little Halloween fun. http://24.215.78.220/