From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 1 04:00:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02216 for ; Mon, 1 Dec 2003 04:00:20 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C5FE7E@cherry.ease.lsoft.com>; Mon, 1 Dec 2003 4:00:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62537197 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 1 Dec 2003 04:00:25 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 1 Dec 2003 04:00:25 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id hB1957d25841 for ; Mon, 1 Dec 2003 14:35:07 +0530 Received: from ALOK ([203.124.140.97]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id hB1954M25828 for ; Mon, 1 Dec 2003 14:35:05 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <045401c3b7e9$43d5e4a0$fb01a8c0@aparabgl.com> Date: Mon, 1 Dec 2003 14:28:08 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: area -id To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, Is there any place where Area -id is used in the SPF and route advertisement procedure? i see it there in the DD and LSU packets. but do they serve any purpose (maybe other than the case where intra area my be prefered over interarea)? it does say in section 13.3 that the area id says that the LSA has to be flooded only over those interfaces that are in area A except for type-5 So why not simply use the type as a distinguisher rather than Area -id? -thanks Alok From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 1 07:32:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07683 for ; Mon, 1 Dec 2003 07:32:48 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C602D8@cherry.ease.lsoft.com>; Mon, 1 Dec 2003 7:33:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62593390 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 1 Dec 2003 07:32:59 -0500 Received: from 61.11.60.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 1 Dec 2003 07:32:58 -0500 Received: from vishwas ([192.168.10.104]) by sinettds (8.12.5/8.12.5) with SMTP id hB1CX2Jv001565 for ; Mon, 1 Dec 2003 18:03:04 +0530 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MS-TNEF-Correlator: 00000000E61A1023E6B026439CE2315114A2C0D2245A5D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <000101c3b825$0addbab0$680aa8c0@vishwas> Date: Mon, 1 Dec 2003 09:45:56 +0200 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1AB@xch-nw-27.nw.nos.boeing.com> Precedence: list Content-Transfer-Encoding: 7bit Tom, That solves it, exactly the same solution as I had pointed to you in a private mail to you. I guess we could declare the link up once we have done periodic flooding atleast once after the link has reached 2-way, this help minimize the probability of loops/because of which the OSPF DB exchange has been made to go thru so many states. I am still thinking of how we could add one-way neighbors. The following procedure would only work if there is a two way path between 2 neighbors, even if not directly. Assume three STA's A, B and C all in the same area. Assume B can see packets from A but not from B. C has a two way neighbor relationship with A and B. Now if we add a link in B's LSA(to one way neighbor A) with link cost 0xFFFF, the link will never be used for forwarding between B to A. A can have a link to B with the original cost. This way a route will be present from A to B, but not the otherway around. To do this, we assume C signals via the Wireless Hello to A that B is a oneway neighbor to A. When A gets this hello, it goes to state two-way with B. Whenever C removes B from the list of oneway hello to A, the adjacency will be declared down. The assumption above is that another path to the one way neighbor exists, if not directly. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Henderson, Thomas R Sent: Friday, November 28, 2003 10:06 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OSPF WG Direction with respect to MANET Requirements > -----Original Message----- > From: Vishwas Manral [mailto:vishwas@SINETT.COM] > Sent: Thursday, November 27, 2003 6:05 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: OSPF WG Direction with respect to MANET Requirements > > > Tom, > > I checked the link you sent a bit. > > I may be wrong here but if we model our interfaces as P2MP, > we will not have > a transit link from the Manet Area at all, as we are not > going above 2-way > state in which case the only link for the P2MP network will > be (as per 2328) > > o A single Type 3 link (stub network) is added with > Link ID set to the router's own IP interface > address, Link Data set to the mask 0xffffffff > (indicating a host route), and cost set to 0. We do the additional step as in Point-to-Multipoint: o For each fully adjacent neighbor associated with the interface, add an additional Type 1 link (point-to- point) with Link ID set to the Router ID of the neighboring router, Link Data set to the IP interface address and cost equal to the interface's configured output cost. This probably should be clarified further in the draft in section 12-- basically, on a wireless subnet, once neighbors get to state 2-Way (seeing themselves in each other's Hellos) they are considered "fully adjacent" from the perspective of generating LSAs (since they skip database exchange) and can advertise Type 1 links between them. Tom From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 1 12:18:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18392 for ; Mon, 1 Dec 2003 12:18:42 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C608B8@cherry.ease.lsoft.com>; Mon, 1 Dec 2003 12:18:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62617637 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 1 Dec 2003 12:18:48 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 1 Dec 2003 12:18:48 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB1HIkAt003641 for ; Mon, 1 Dec 2003 09:18:46 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOA37422; Mon, 1 Dec 2003 09:18:45 -0800 (PST) X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 References: <3FC3B40B.6050902@redback.com> <6.0.1.1.2.20031125150108.046eceb0@mira-sjc5-b.cisco.com > <3FC41A34.9000002@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.0.1.1.2.20031201091407.04cae150@mira-sjc5-b.cisco.com > Date: Mon, 1 Dec 2003 09:18:34 -0800 Reply-To: Mailing List Sender: Mailing List From: Fred Baker Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC41A34.9000002@redback.com> Precedence: list At 07:12 PM 11/25/2003, Acee Lindem wrote: >I agree that a MANET area is not cast in stone. However, on the surface it >would seem like a good way to segregate the MANET extensions from base >OSPFv3. I have a real problem with the concept of a "manet area". Ask yourself what an area is and why one uses an area. It is a containment boundary. Prefixes that cross it get summarized; other prefixes don't. It has nothing to do with the procedures used on interfaces in the area, with the exception of in some cases ensuring that all of the routers in the area are configured with the same set of interesting options such as DoNotAge. Tell me this. If I put an Ethernet into an area, does it become a LAN area? Why or why not? If I put a serial interface into an area, does it become a serial area? why or why not? If I put a frame relay interface into an area, does it become a point-to-multipoint area? Why or why not? The reason the don't is that LAN-ness, serial-ness, and p2mp-ness are not attributes of areas. They are attributes of interfaces. So if I put a radio interface into an area, give me one good reason it should become a radio area? Operationally, Alex is interested in keeping a summarization boundary around a domain containing radio interfaces and having a constant churn in routing. On that, I agree with him. Operationally, that makes a heck of a lot of sense. But that doesn't make it a radio *area* in a protocol sense. It makes it a well managed area that happens to contain some radio interfaces in addition to its other interfaces. Let's not make bad protocol decisions out of good operational practice. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 1 12:56:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20005 for ; Mon, 1 Dec 2003 12:56:49 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C60815@cherry.ease.lsoft.com>; Mon, 1 Dec 2003 12:57:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62621175 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 1 Dec 2003 12:56:59 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 1 Dec 2003 12:56:59 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C42E76A6964 for ; Mon, 1 Dec 2003 09:56:59 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07002-04 for ; Mon, 1 Dec 2003 09:56:59 -0800 (PST) Received: from redback.com (unknown [155.53.6.27]) by prattle.redback.com (Postfix) with ESMTP id B3BBA6A6960 for ; Mon, 1 Dec 2003 09:56:58 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3FC3B40B.6050902@redback.com> <6.0.1.1.2.20031125150108.046eceb0@mira-sjc5-b.cisco.com > <3FC41A34.9000002@redback.com> <6.0.1.1.2.20031201091407.04cae150@mira-sjc5-b.cisco.com > Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FCB80DA.4090700@redback.com> Date: Mon, 1 Dec 2003 12:56:42 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6.0.1.1.2.20031201091407.04cae150@mira-sjc5-b.cisco.com > Precedence: list Content-Transfer-Encoding: 7bit Fred, You seem to have cut the final paragraph of my 11/25 response. I've re-pasted it below since this is still my position. > If the MANET interface can be added without significant modification to > the basic OSPF mechanisms (e.g. the P2MP interface was a natural > extension since > it operates very similar to a mesh of P2Ps) then this would be an > instance of option #3. If OSPFv3 will need to changed significantly > to meet the > MANET requirements then this should be a separate option (option #5). > > Anyway, it for the OSPF WG as a whole to decide. Maybe it > is best to put forth the MANET interface proposal for technical review. Is the link below the correct draft for the WG to review? This was the draft link posted on 11/26 by Tom Henderson. I haven't had time to review it yet. http://www.ietf.org/internet-drafts/draft-spagnolo-manet-ospf-wireless-interface-00.txt Acee Fred Baker wrote: > At 07:12 PM 11/25/2003, Acee Lindem wrote: > >> I agree that a MANET area is not cast in stone. However, on the >> surface it >> would seem like a good way to segregate the MANET extensions from base >> OSPFv3. > > > I have a real problem with the concept of a "manet area". Ask yourself > what > an area is and why one uses an area. It is a containment boundary. > Prefixes > that cross it get summarized; other prefixes don't. It has nothing to do > with the procedures used on interfaces in the area, with the exception of > in some cases ensuring that all of the routers in the area are configured > with the same set of interesting options such as DoNotAge. > > Tell me this. If I put an Ethernet into an area, does it become a LAN > area? > Why or why not? If I put a serial interface into an area, does it > become a > serial area? why or why not? If I put a frame relay interface into an > area, > does it become a point-to-multipoint area? Why or why not? > > The reason the don't is that LAN-ness, serial-ness, and p2mp-ness are not > attributes of areas. They are attributes of interfaces. > > So if I put a radio interface into an area, give me one good reason it > should become a radio area? > > Operationally, Alex is interested in keeping a summarization boundary > around a domain containing radio interfaces and having a constant > churn in > routing. On that, I agree with him. Operationally, that makes a heck of a > lot of sense. But that doesn't make it a radio *area* in a protocol > sense. > It makes it a well managed area that happens to contain some radio > interfaces in addition to its other interfaces. > > Let's not make bad protocol decisions out of good operational practice. > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 2 08:41:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16529 for ; Tue, 2 Dec 2003 08:41:16 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C6209A@cherry.ease.lsoft.com>; Tue, 2 Dec 2003 8:41:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62759722 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 2 Dec 2003 08:41:22 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Dec 2003 08:41:22 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB2DfJw5004627 for ; Tue, 2 Dec 2003 05:41:20 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (ams-clip-vpn-dhcp4137.cisco.com [10.61.80.40]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOB27265; Tue, 2 Dec 2003 05:41:18 -0800 (PST) X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 References: <3FC3B40B.6050902@redback.com> <6.0.1.1.2.20031125150108.046eceb0@mira-sjc5-b.cisco.com > <3FC41A34.9000002@redback.com> <6.0.1.1.2.20031201091407.04cae150@mira-sjc5-b.cisco.com > <3FCB80DA.4090700@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.0.1.1.2.20031202143703.043e3c00@mira-sjc5-b.cisco.com > Date: Tue, 2 Dec 2003 14:38:11 +0100 Reply-To: Mailing List Sender: Mailing List From: Fred Baker Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FCB80DA.4090700@redback.com> Precedence: list At 06:56 PM 12/1/2003, Acee Lindem wrote: >Is the link below the correct draft for the WG to review? This was the >draft link >posted on 11/26 by Tom Henderson. I haven't had time to review it yet. it is Henderson's proposal. I don't think it is exactly the same as our proposal, which is coming as a set of several drafts. The working group is certainly welcome to look at Henderson's proposal. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 2 09:35:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19234 for ; Tue, 2 Dec 2003 09:35:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C621F6@cherry.ease.lsoft.com>; Tue, 2 Dec 2003 9:36:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62762381 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 2 Dec 2003 09:36:06 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Dec 2003 09:36:06 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DB2572410C3 for ; Tue, 2 Dec 2003 06:36:04 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08608-02 for ; Tue, 2 Dec 2003 06:36:04 -0800 (PST) Received: from redback.com (pptp-6-138.redback.com [155.53.6.138]) by prattle.redback.com (Postfix) with ESMTP id F1A322410C2 for ; Tue, 2 Dec 2003 06:36:03 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3FC3B40B.6050902@redback.com> <6.0.1.1.2.20031125150108.046eceb0@mira-sjc5-b.cisco.com > <3FC41A34.9000002@redback.com> <6.0.1.1.2.20031201091407.04cae150@mira-sjc5-b.cisco.com > <3FCB80DA.4090700@redback.com> <6.0.1.1.2.20031202143703.043e3c00@mira-sjc5-b.cisco.com > Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FCCA341.6000307@redback.com> Date: Tue, 2 Dec 2003 09:35:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6.0.1.1.2.20031202143703.043e3c00@mira-sjc5-b.cisco.com > Precedence: list Content-Transfer-Encoding: 7bit Fred Baker wrote: > At 06:56 PM 12/1/2003, Acee Lindem wrote: > >> Is the link below the correct draft for the WG to review? This was the >> draft link >> posted on 11/26 by Tom Henderson. I haven't had time to review it yet. > > > it is Henderson's proposal. I don't think it is exactly the same as our > proposal, which is coming as a set of several drafts. The working > group is > certainly welcome to look at Henderson's proposal. A single draft would be preferrable to a set of drafts. We're going to have to see them before we can debate whether or not they make sense for OSPFv3. Thanks, Acee > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 2 15:23:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07833 for ; Tue, 2 Dec 2003 15:23:35 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C62916@cherry.ease.lsoft.com>; Tue, 2 Dec 2003 15:23:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62798837 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 2 Dec 2003 15:23:45 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Dec 2003 15:23:44 -0500 Received: (qmail 6226 invoked by uid 404); 2 Dec 2003 20:23:42 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.405835 secs); 02 Dec 2003 20:23:42 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 2 Dec 2003 20:23:42 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id PAA06729; Tue, 2 Dec 2003 15:23:36 -0500 Message-ID: <200312022023.PAA06729@bigbird.nj.us.utstar.com> Date: Tue, 2 Dec 2003 15:23:36 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPF WG Direction with respect to MANET Requirements Comments: cc: zinin@psg.com, fenner@research.att.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Tue, 02 Dec 2003 09:35:45 EST." <3FCCA341.6000307@redback.com> Precedence: list Folks, If we end up solving the OSPF-MANET problem in this WG, a solution which is _not_ encumbered by patents would be preferred. I just want to point this out up front to minimize problems down the road. Best, --rohit. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 2 23:59:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03563 for ; Tue, 2 Dec 2003 23:59:47 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C63527@cherry.ease.lsoft.com>; Tue, 2 Dec 2003 23:59:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62839048 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 2 Dec 2003 23:59:58 -0500 Received: from 61.95.163.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Dec 2003 23:59:57 -0500 Received: from vishwas ([192.168.10.113]) by sinettds (8.12.5/8.12.5) with SMTP id hB34xGJv005435 for ; Wed, 3 Dec 2003 10:29:17 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <003a01c3b978$238c57c0$710aa8c0@vishwas> Date: Wed, 3 Dec 2003 10:33:32 +0200 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FCCA341.6000307@redback.com> Precedence: list Content-Transfer-Encoding: 7bit I agree with Acee, outline drafts which tell the exact nature of changes are essential to figureout the amount of changes that will be required to the OSPFv3 protocol for MANET. I went through Henderson drafts and the number of changes do not seem very many, though the draft works on OSPFv2 and not OSPFv3. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: Tuesday, December 02, 2003 4:36 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OSPF WG Direction with respect to MANET Requirements Fred Baker wrote: > At 06:56 PM 12/1/2003, Acee Lindem wrote: > >> Is the link below the correct draft for the WG to review? This was the >> draft link >> posted on 11/26 by Tom Henderson. I haven't had time to review it yet. > > > it is Henderson's proposal. I don't think it is exactly the same as our > proposal, which is coming as a set of several drafts. The working > group is > certainly welcome to look at Henderson's proposal. A single draft would be preferrable to a set of drafts. We're going to have to see them before we can debate whether or not they make sense for OSPFv3. Thanks, Acee > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.545 / Virus Database: 339 - Release Date: 11/27/2003 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 4 08:39:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24818 for ; Thu, 4 Dec 2003 08:39:28 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C659DE@cherry.ease.lsoft.com>; Thu, 4 Dec 2003 8:39:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63040761 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Dec 2003 08:39:37 -0500 Received: from 192.91.191.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Dec 2003 08:29:37 -0500 Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Thu, 4 Dec 2003 13:29:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <37701240971DD31193970000F6CCB9F704EA5507@duke.datcon.co.uk> Date: Thu, 4 Dec 2003 13:29:35 -0000 Reply-To: Mailing List Sender: Mailing List From: Oliver Carter Subject: FW: draft-ietf-ospf-graceful-impl-report-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Reposting to the list - now I've updated my e-mail address :-) > -----Original Message----- > From: Oliver Carter > Sent: 04 December 2003 13:20 > To: 'Acee Lindem' > Cc: OSPF@PEACH.EASE.LSOFT.COM > Subject: draft-ietf-ospf-graceful-impl-report-00.txt > > Acee, > > Thanks for publishing this draft. I have a question about section 2.1 3rd > Para of it. > > > The final difference was in whether or not additional extensions were > implemented to accommodate other features such as protocol redistribution > or interaction with MPLS VPNs [VPN]. Two vendors implemented extensions > and three did not. It should be noted that such extensions are beyond the > scope of Graceful OSPF Restart [GRACE]. > > > Do you know what additional extensions were implemented? What are the > issues with running Graceful OSPF restart in an MPLS VPN scenario? > > Regards > > Oli > > P.S. I couldn't find anything related to this on the OSPF or L3VPN mailing > lists - feel free to point me at previous posts if this has been discussed > before. > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 4 13:01:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06607 for ; Thu, 4 Dec 2003 13:01:51 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C65E2A@cherry.ease.lsoft.com>; Thu, 4 Dec 2003 13:02:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63060255 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Dec 2003 13:02:00 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Dec 2003 13:01:59 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 758294F33D0; Thu, 4 Dec 2003 10:02:01 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19069-02; Thu, 4 Dec 2003 10:02:01 -0800 (PST) Received: from redback.com (pptp-6-141.redback.com [155.53.6.141]) by prattle.redback.com (Postfix) with ESMTP id 1F0224F33C7; Thu, 4 Dec 2003 10:02:00 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <37701240971DD31193970000F6CCB9F704EA5505@duke.datcon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FCF7682.4060807@redback.com> Date: Thu, 4 Dec 2003 13:01:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-graceful-impl-report-00.txt Comments: To: Oliver Carter To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <37701240971DD31193970000F6CCB9F704EA5505@duke.datcon.co.uk> Precedence: list Content-Transfer-Encoding: 7bit Oliver Carter wrote: >Acee, > >Thanks for publishing this draft. I have a question about section 2.1 3rd >Para of it. > > >The final difference was in whether or not additional extensions were >implemented to accommodate other features such as protocol redistribution or >interaction with MPLS VPNs [VPN]. Two vendors implemented extensions and >three did not. It should be noted that such extensions are beyond the scope >of Graceful OSPF Restart [GRACE]. > > >Do you know what additional extensions were implemented? What are the >issues with running Graceful OSPF restart in an MPLS VPN scenario? > Yes - additional delays need to be added before purging stale LSAs after restart. In essence, you have to wait until your BGP has converged to assure you've received all your VPN routes. > >Regards > >Oli > >P.S. I couldn't find anything related to this on the OSPF or L3VPN mailing >lists - feel free to point me at previous posts if this has been discussed >before. > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 4 13:17:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06996 for ; Thu, 4 Dec 2003 13:17:47 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C6600B@cherry.ease.lsoft.com>; Thu, 4 Dec 2003 13:18:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63061536 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Dec 2003 13:17:52 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Dec 2003 13:17:52 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E2CC0716542 for ; Thu, 4 Dec 2003 10:17:53 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21381-09 for ; Thu, 4 Dec 2003 10:17:53 -0800 (PST) Received: from redback.com (pptp-6-141.redback.com [155.53.6.141]) by prattle.redback.com (Postfix) with ESMTP id 4B017716547 for ; Thu, 4 Dec 2003 10:17:53 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <37701240971DD31193970000F6CCB9F704EA5505@duke.datcon.co.uk> <3FCF7682.4060807@redback.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FCF7A3B.6060206@redback.com> Date: Thu, 4 Dec 2003 13:17:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-graceful-impl-report-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FCF7682.4060807@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem wrote: > Oliver Carter wrote: > >> Acee, >> >> Thanks for publishing this draft. I have a question about section >> 2.1 3rd >> Para of it. >> >> >> The final difference was in whether or not additional extensions were >> implemented to accommodate other features such as protocol >> redistribution or >> interaction with MPLS VPNs [VPN]. Two vendors implemented extensions and >> three did not. It should be noted that such extensions are beyond the >> scope >> of Graceful OSPF Restart [GRACE]. >> >> >> Do you know what additional extensions were implemented? What are the >> issues with running Graceful OSPF restart in an MPLS VPN scenario? >> > Yes - additional delays need to be added before purging stale LSAs after > restart. In essence, you have > to wait until your BGP has converged to assure you've received all your > VPN routes. Note that the reason this is needed is that BGP has been restarted as well (as would be the case in many redundant control processor implementations). Thanks, Acee > > >> >> Regards >> >> Oli >> >> P.S. I couldn't find anything related to this on the OSPF or L3VPN >> mailing >> lists - feel free to point me at previous posts if this has been >> discussed >> before. >> >> >> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 4 15:50:18 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13909 for ; Thu, 4 Dec 2003 15:50:16 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C66237@cherry.ease.lsoft.com>; Thu, 4 Dec 2003 15:50:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63076884 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Dec 2003 15:50:26 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Dec 2003 15:40:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13547; Thu, 4 Dec 2003 15:40:09 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200312042040.PAA13547@ietf.org> Date: Thu, 4 Dec 2003 15:40:09 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-2547-dnbit-02.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs Author(s) : E. Rosen Filename : draft-ietf-ospf-2547-dnbit-02.txt Pages : 6 Date : 2003-12-4 [VPN] describes a method by which a Service Provider (SP) may provide an 'IP VPN' service to its customers. In VPNs of that sort, a Customer Edge (CE) Router and a Provider Edge Router become routing peers, and the customer routes are sent to the SP. BGP is then used to carry the customer routes across the SP's backbone to other PE routers, and the routes are then sent to other CE routers. Since CE routers and PE routers are routing peers, it is customary to run a routing protocol between them. [VPN] allows a number of different PE-CE protocols. If OSPF is used as the PE-CE routing protocol, the PE must execute additional procedures not specified in [VPN]; these procedures are specified in [OSPF-VPN]. These additional procedures translate customer OSPF routes from a CE router into BGP routes. The BGP routes are sent to the other PE routers, which translate them back into OSPF routes, and then distribute them to CE routers. During this translation, some of the information needed to prevent loops may be lost. The procedures specified in this document remedy this situation by specifying that one of the OSPF options bits be used to ensure that when a VPN route is sent from a PE to a CE, the route will be ignored by any PE which receives it back from a CE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-2547-dnbit-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-2547-dnbit-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-2547-dnbit-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-4154930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-2547-dnbit-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-2547-dnbit-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154930.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 5 13:59:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18675 for ; Fri, 5 Dec 2003 13:59:03 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C67A59@cherry.ease.lsoft.com>; Fri, 5 Dec 2003 13:59:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63201854 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Dec 2003 13:59:07 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Dec 2003 13:59:07 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB5Ix8115667 for ; Fri, 5 Dec 2003 20:59:08 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 5 Dec 2003 20:59:08 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 10:59:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-auth-03.txt) Thread-Index: AcO7YdvPt5OfAMugTd+FljKKBgyEEg== X-OriginalArrivalTime: 05 Dec 2003 18:59:07.0068 (UTC) FILETIME=[DBD1AFC0:01C3BB61] Message-ID: <8D260779A766FB4A9C1739A476F84FA401546FF1@daebe009.americas.nokia.com> Date: Fri, 5 Dec 2003 12:59:06 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-auth-03.txt) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Group, As we had decided to add a section on changing OSPFv3 keys without breaking adjacencies, here is the text Me, Paul and Suresh came up=20 with.=20 Comments are welcome. I will wait for the comments till Monday and=20 then I will add this in the draft. Regards Mukesh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D X. Changing Keys To maintain the security of a link, it may be desirable to change the key values from time to time. The following three step procedure MAY be provided to rekey the routers on a link without dropping OSPFv3 protocol packets or disrupting the adjacency. 1. For every router on the link, create an additional input SA for the interface being rekeyed using a new SPI and the new key. 2. For every router on the link, replace the original output SA with one using the the new SPI and key values. The SA replacement operation should be atomic with respect to sending OSPFv3 packets on the link so that no OSPFv3 packets are sent without authentication/encryption. 3. For every router on the link, remove the original input SA. Note that all the routers on the link must complete step 1 before any begin step 2. Likewise, all the routers on the link must complete step 2 before any begin step 3. To control the progression from one step to the next, each router has a configurable time constant KeyRolloverInterval. After the router begins step 1 on a given link, it waits for this interval and then moves to step 2. Likewise, after moving to step 2, it waits for this interval and then moves to step 3. In order to achieve smooth key transition, all the routers on a link should use the same value for KeyRolloverInterval, and should initiate the key rollover process within this time period. At the end of this procedure, all the routers will have a single input and output SA for OSPFv3 on the link with the new SPI and key values. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 5 14:52:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20764 for ; Fri, 5 Dec 2003 14:52:46 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C67CE0@cherry.ease.lsoft.com>; Fri, 5 Dec 2003 14:52:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63206774 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Dec 2003 14:53:00 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Dec 2003 14:52:59 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id EFA5D68284B for ; Fri, 5 Dec 2003 11:52:55 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20710-08 for ; Fri, 5 Dec 2003 11:52:55 -0800 (PST) Received: from redback.com (unknown [155.53.6.32]) by prattle.redback.com (Postfix) with ESMTP id A6B47682844 for ; Fri, 5 Dec 2003 11:52:54 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3FC2243B.80207@redback.com> Content-Type: multipart/mixed; boundary="------------050400060909070702050409" X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD0E202.3070406@redback.com> Date: Fri, 5 Dec 2003 14:52:34 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Meeting Minutes for 58th IETF OSPF WG in Minneapolis To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC2243B.80207@redback.com> Precedence: list This is a multi-part message in MIME format. --------------050400060909070702050409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So far I've only received one comment on the minutes. I intend to submit them to the proceeding next week rather than wait until the deadline. Thanks, Acee Acee Lindem wrote: > Thaks to Dimitri Papadimitriou for taking the meeting minutes. If you > have comments, please > send them to me in a private E-mail. I will send an update to the list > before sending the final version > to the proceeding. I'd especially encourage those who spoke up at the > meeting to review your > statements as transcribed in the minutes. > > Thanks, > Acee > > > > --------------050400060909070702050409 Content-Type: text/plain; name="OSPF Meeting Minutes.txt" Content-Disposition: inline; filename="OSPF Meeting Minutes.txt" Content-Transfer-Encoding: 7bit 58th IETF OSPF WG Minutes - Reported by Dimitri Papadimitriou Monday November 10 (15:30 - 17:30) ================================= CHAIRS: Rohit Dube Acee Lindem AGENDA: o Chairs (5 Mins): Agenda Bashing o Chairs (10 Mins): WG document status - Published "Traffic Engineering (TE) Extensions to OSPF Version 2" as RFC3630 - Approved for publication "OSPF Refresh and Flooding Reduction in Stable Topologies" - draft-pillay-esnault-ospf-flooding-07.txt - To be published "Graceful OSPF Restart" draft-ietf-ospf-hitless-restart-08.txt - IESG Evaluation/Revised I-D needed: . "Detecting Inactive Neighbors over OSPF Demand Circuits" draft-ietf-ospf-dc-06.txt - Awaiting I-D write up . "Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance" - draft-ietf-ospf-scalability-06.txt - WG Last Call . "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs" draft-ietf-ospf-2547-dnbit-01.txt - Soon to become WG documents: . "OSPF version 2 Management Information Base" (update of the RFC1850) - draft-ietf-ospf-mib-update-07.txt . "Authentication/Confidentiality for OSPF version 3" draft-ietf-ospf-ospfv3-auth-03.txt - More discussion needed to get WG status: . "Management Information Base for OSPF version 3" draft-ietf-ospf-ospfv3-mib-07.txt . "Traffic Engineering Extensions to OSPF version 3" draft-ietf-ospf-ospfv3-traffic-01.txt . "Extensions to OSPF for Advertising Optional Router Capabilities" draft-ietf-ospf-cap-01.txt - RFC1264 - requirements for protocols and major features . implementation survey ********************************************************************* o Acee Lindem (10 mins): "Graceful OSPF Restart Implementation Report" - draft-ietf-ospf-graceful-impl-report-00.txt Summary: ------- This document provides an implementation report for the Graceful Restart extension to the OSPF protocol per RFC 1264 (stating the requirements for a report on implementation experience). - Five vendors have implemented graceful OSPF and have completed the implementation survey. - Implementation Differences: . Whether or not strict LSA checking was implemented and, if so, whether it was configurable (note: strict LSA checking indicates whether or not a changed LSA will result in termination of the graceful restart by a helping router.) . Whether a received grace LSA would be taken to apply only to the adjacency on which it was received or all adjacencies with the restarting router. . Whether or not additional extensions were implemented to accommodate other features such as protocol redistribution or interaction with MPLS VPNs - Addition to the OSPFv2 MIB: . 5 new objects to the ospfGeneralGroup . 3 new objects to the ospfNbrEntry . 3 new objects to the ospfVirtNbrEntry Discussions: - Acee Lindem: anyone else interested (from the already listed 5 vendors) ? -> yes, 2 additional vendors expressed interest and will be included upon completion of the survey. ********************************************************************* o Rahul Aggarwal (10 Mins): "Support of address families in OSPFv3" draft-mirtorabi-ospfv3-af-alt-00.txt Summary: ------- - Agenda: Motivation, Proposed solution, Design consideration - Motivation: Need to carry multiple AF in OSPFv3 (such as multicast IPv6, unicast or multicast IPv4) in addition to IPv6 unicast - Proposed solution: . Multiple AFs are introduced in OSPFv3 by reserving Instance IDs and using one OSPFv3 instance for exactly one AF. . Each AF establish different adjacency, have different LSDB and compute different SPT. . Hello processing: to avoid blackholing, hello processing is changed in order to only establish adjacency with the routers that have the AF-bit set in their Options field. . Modification of the semantic of some of the Option field bits defined in RFC2740. . Carrying Prefixes in new AF's: each Prefix has a prefix length facilitating the advertisement of prefixes of different lengths in different AF's (no need to define new LSAs). . Virtual Link (VL): virtual link are not currently supported in other AF's than IPv6 unicast AF (as there cannot be a multihop forwarding based on global IPv6 address or such a path may not exist). - AF Design Considerations: . Mmapping an instance to an AF doesn't introduce new mechanisms in the protocol . Minimizes the protocol extensions required and simplifies the implementation. . Presence of a separate LSDB per AF is easier to debug and operate. . Does not change the existing instance, area and interface based configuration model of most OSPF implementations - Request to make it a WG document Discussion: ---------- - Fred Baker: Agree to make it working group document but concern wrt mobile ad hoc networks (MANET) - does not want to have two neighbor relationships and favor keeping a single instance. Also this solution potentially doesn't address MANET concerns and requirements. - Acee Lindem: everybody here is in agreement that in OSPFv3 has to support multiple AF's so we need to address this issue - Fred Baker: In favor of having a single instance (neighbor with a process of transitioning) and doesn't want to see both OSPFv2 and OSPFv3 using AF's (doesn't want to have separate protocols for achieving this capability). This is a solution for allowing mutliple address families in OSPFv3 but this solution doesn't necessarily meet the MANET requirements. However, agrees to make it a working group document. - Hasmit Grover: Not specific to this solution, questions the duplication of information in OSPFv3. - Rahul Aggarwal: Not duplicating anything, it is a matter of having two router LSAs instead of one. - Hasmit Grover: Still need duplication of topology information and it would not be more complicated to have a single instance for doing this. - Acee Lindem: The target was simplication. - Hasmit Grover: Doesn't know how much that problem it is, why OSPFv3 is so different ? - Rahul Aggarwal: not TLV based - Acee Lindem: By comparison, using a single instance for providing this would require more work (than what is proposed here). - Rahul Aggarwal: Request for WG document ? - Acee Lindem: I would like to have some more discussion on the proposed solution, but the requirement is acheived - it seems that no one disagrees that this is a requirement for OSPFv3. - Acee Lindem: Sense the meeting room for WG document status. -> Few people in favor - Acee Lindem: Sense the meeting room for having an integrated solution. -> Few people in favor - Acee Lindem: WG document status and see how the discussion can progress. - Rahul Aggrawal: This is document is good basis to work on this topic. - Acee Lindem: The target for the working group is to come with something simpler. ********************************************************************* o Rahul Aggrawal (10 Mins): "Advertising a Router's Local Addresses in OSPF TE Extension" - draft-raggarwa-ospf-te-node-addr-00.txt Summary: ------- - Agenda: Motivation, Problem Statement, Proposed solution, Conclusion - Motivation: in some cases (for instance in a network carrying VPN and non-VPN traffic it is desirable to setup) CSPF computed MPLS TE LSPs to local addresses of a router that are not advertised in the TE LSAs i.e. loopback and non-TE interface addresses. - Problem: OSPF routers can only use CSPF to compute MPLS TE LSPs to the router ID or the local addresses of TE enabled links, of a remote router. This because: . OSPFv2/v3 TE extensions only advertise the router ID and the local addresses of TE enabled links, of a given router -> other routers cannot populate their TED with other local addresses of the advertising router i.e. loopback and non-TE i/f addresses. . OSPFv2 stub links in the OSPFv2 router LSA OSPFv2 provide stub reachability information but not sufficient to learn all the local addresses of a router (same problem w/ intra-prefix LSAs in OSPFv3) - Proposed solution: . Advertise the local addresses in a new node attribute TLV, in the OSPF TE LSA . Node attribute TLV carries the attributes associated with a router - it contains one or more IPv4/v6 local address sub-TLVs Discussions: ----------- - Acee Lindem: Put the discussion on the mailing list - Acee Lindem (to Rahul): You could poll this information out of the router LSA and set that information from the topology? - Rahul Aggarwal: Will give the details. - Acee Lindem: Ask for comments on the mailing list, this document is a small amount of work since it slightly modifies OSPF-TE ********************************************************************* o Sina Mirtorabi (10 Mins): "OSPF Tunnel Adjacency" draft-mirtorabi-ospf-tunnel-adjacency-00.txt Summary: ------- - What it is a Tunnel Adjacency (TA): Proposal to solve the intra- area/inter-area path preference, generalization of virtual links, it can force OSPF to take the desire path and it has the on- demand partition capapbility - What does TA resolve: intra/inter-area path preferecne, in hub and spoke topology, it saves the cost of adding a new interface, between ABRs, it helps in repairing by avoiding segmented areas - How a TA is established: configured as for VL's, and then it is announced - How data packet is fowarded: . if ABR-ABR link is direct link -> sent w/o encaps . if ABR-ABR link is mutli-hop -> encapsulation needed (doesn't need configuration) - TA Configuration/Parameters: . TA is configured between two ABRs attached to the same OSPF area. . Parameters: Tunnel-adjacency Transit Area (TTA) and as for VL's, a TA is identified by Router ID of the other endpoint and its Area ID - TA resolves the VL limitations: . a TA link can belong to any area, . summarization is not affected . TA can't go through stub/nssa area - TA has added value features: . TA cost is configurabken . Provides on-demand partition repaitr . Mutliple TA through a given path Discussions: ----------- - Padma Pillay-Esnault: Don't see what this adds wrt to tunneling between two ABR's. - Sina Mirtorabi: 3 differences, config overhead (IP address), rely on IP address (reachability is done in given area, while tunnel doesn't guide the reachability), and provides automatic partition repair. - Alex Zinin: RFC 2328 limits the configuration of the VLs so that they can only transit through non-backbone areas and always belong to the backbone. Among other things this prevents "recursive" VLs, i.e., VLs relying on other VLs. The draft relaxes this and suggests that the TA can belong to any area and can transit any area. This opens up a possibility for TA1 that belongs to area A1 to transit area A2 that has TA2. This means that it could be possible for packets to be encapsulated more than once. It seems it could also be possible to have recursive TA resolution, e.g. in the case above, TA2 transiting area A1. - Padma Pillay-Esnault: You're making people trying to avoid VL, while topological changes are going to generate re-routing. - Sina Mirtorabi: VL issue is that it was recommended to "not use VL". - Padma Pillay-Esnault: Any trigger in its own area is going to generate path re-computation. - Acee Lindem: But any intra-area topological change is going to generate path re-computation in one way or another. - Padma Pillay-Esnault: But here you may trigger several SPFs and thus end up with several levels of SPF, - Acee Lindem: Yes, changes can trigger other changes during re- computation - Acee Lindem: Express concerns about the requirements, today we have a limitation on an interface belonging to a single area. This requirement can be satisfied by considering the area ID but do we want to go further and have an automated tunneling ? - Sina Mirtorabi: Main reason is to have a solution that avoids direct links, otherwise Pat Murphy approach was there to solve this issue. - Acee Lindem: But that draft was too complicated. -> Take this to the list? ********************************************************************* o Kiretti Kompella (10 Mins): "OSPFv2 Traffic Engineering Extensions for Multi-access Networks" draft-kompella-ospf-multiaccess-te-00.txt Summary: ------- - Traffic Engineering extensions for OSPFv2 for dealing with multi- access networks since the bandwidth attributes in the OSPFv2 TE do not accurately model the available bandwidth across a multi- access network. - LAN being modelized as a star (modelisation X=DR being one of the router attached to the LAN) but X doesn't generate a TE LSA thus the bandwidth availability (i.e. Unreserved Bandwidth) is not available in the reverse direction (e.g. X->D) - Motivation comes from that fact that switches are increasingly the router interconnection of choice and it is fairly trivial to achieve this, by advertizing the reverse bandwidth (i.e. from the DR) - Next steps: . Two questions is this useful? Hole in RFC 3630 but also be a requirement from service provider? . Vendors to tell if this a reasonable solution. Discussions: ----------- - Acee Lindem: Put the question on the list? This is one is a bit more complicated than the previous TE extension (Rahuls), with two more vectors of information. - Acee Lindem: Do we want TE to this level of detail that keeps track of the type of switch ? - Dave Ward: There is a requirement to solve the problem, this is also a requirement for which Cisco is receiving input to define such kind of extensions. - Acee Lindem: Wonders if this has to be dealt here in the OSPF WG or in the TE WG? - (?): any admission control issue ? - Kireeti Kompella: Implementation needs a change to use this, backward compatible means that routers by seeing this, they don't pick out (of course they wouldn't be capable of using this); also by using a new TE LSA, router on the LAN would have to understand this TE LSA - concerning CAC issue suggests you read the draft - (?): interaction between admission control and RSVP ? - Kireeti Kompella: when TE extensions where defined, conclusion was that it doesn't make sense to say how RSVP-TE interacts with this, (this has not been done in OSPF-TE as well) some of the hints to do have been given in the document. Kireeti says it should be clear for the reader. - (?): put the information here asks the question of what is the added value of having this information to perform the CSPF. - Kireeti Kompella: Information is there to do admission control on the LAN. - George Swallow: It works in the fully point-switched case, but not in the case of cascaded switches. - Acee Lindem: Put also on the TE WG mailing list ********************************************************************* o Fred Baker (10 Mins): "Problem Statement for OSPF Extensions for Mobile Ad Hoc Routing" draft-baker-manet-ospf-problem-statement-00.txt - Problem statement for OSPF extensions for mobile ad hoc networks - Presentation: Discussions: ----------- - Rahul Aggarwal: High level comment, the argument on why OSPF is suitable is that one MANET network may co-exist with an existing LAN network -> so good to think about extensions The question is if meeting the MANET requirements generate a fundamental change is it not better to have a separate protocol? - Fred Baker: INRIA want to have their own protocol, but I want to keep both in one place - the only concern is related to the scalability properties of OSPF - note also the concern on the training issue (so ask if possible to just add a new interface). - Joseph Macker: A bit of history, in essence these protocol requirements seem applicable to OSPF, in addition people deploy and know how to manage it, it has homogeneous properties, and provides prefix summarization - here lot of interesting things in deploying OSPF for MANET networks seems to be stimulated by the development of this (new) problem statement. -> Is there a place for this development and in order to start this we need a problem statement document - Rahul Aggarwal: Arguments seem valid, but seeing the Baker's presentation, it also seems there are lot of changes to be expected. - Fred Baker: Not proposing to change the area hierarchy, what we are proposing is adding a MANET (radio) interface which is not behaving as a canonical "OSPF interface". - Rahul Aggarwal: We need probably more discussions. - (?): how do we address the bandwidth constraint issue? - Fred Baker: Turns out there are lot of things to be said here concerning this but we speak here in terms of Mbits . - INRIA rep: Disagrees strongly that they were not interested in OSPF, on the contrary INRIA put a lot attention and interest in OSPF, and are clearly also looking at OSPF extensions. - Alex Zinin: Refers to an understatement by "simply adding an interface" - before starting to speak about adding an interface, there are lot of things that may be impacted by adding such kind of interface and this even if it looks like very simple, it might not be the case. - Acee Lindem: Now OSPF is a general purpose protocol, if we take on all these requirements it will look like very different from what it is today? But I fear that if you take all the military requirements, I am not sure we will end up with the same protocol as we have today - Give the example of authentication in OSPFv3 using shared key multicast model - Thus take into account the military requirements may require a chain of changes from the existing documents. - Joseph Macker: We don't speak about military requirements, lot of these are like the existing requirements of an ISP, Baker's proposal was about optimization but wasn't pushed out and here proposal using a kind of stub within OSPF, being less intrusive but also less flexible - it is pretty easy to understand. - Sue Harres: Subsets have been worked out by the ISP's and how these changes can be allowed - point to the summarization issue. - Acee Lindem: Concurs on fears concerning summarization. - Sue Harres: Router protocols converge very fast today. - Acee Lindem: My fear was the change to the basic area hierarchy - Fred Baker: What I expect with the area boundary behavior, is that we will summarize at an area boundary as done now, but now information is spread, here departure by having a specific propagation w/i a specific area with longest prefix match first. - Sue Harres: Worry about the inter-region flooding, solved if there are multi-admin hierarchy, we have to gauge where we're getting benefits and problems. - Fred Baker: The big problem comes from the exponential explosion in messages and managing that growth (not the summarization). - Acee Lindem: there must be a defined hierarchy, the existing protocol will be summarizing when the entity moves from area to another. - Alex Zinin: Subsequent convergence in IGP is not the same wrt to the density of the topology - injecting information from an area to another while the majority of the nodes remains in the same area? - Rao: This would generate lot of dynamic state changes - using a list of neighbors depending on the region where the entity is located, this list would be pre-configured, but by moving from one region to another are you still keeping the same group of neighbors? - Fred Baker: Doesn't understand -> take offline - Joseph Macker: Idea with this is to find which WG can host the discussion here, proposes to discuss where people think this item has to go, key thing is to know if this protocol can be implemented using OSPF - Acee Lindem: Someone to send the list of drafts so that people can take a look about what we are talking about. *** Meeting is adjourned *** --------------050400060909070702050409-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 5 18:20:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02845 for ; Fri, 5 Dec 2003 18:20:07 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C68157@cherry.ease.lsoft.com>; Fri, 5 Dec 2003 18:20:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63226035 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Dec 2003 18:20:19 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Dec 2003 18:20:19 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D5EE5740071 for ; Fri, 5 Dec 2003 15:20:15 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12045-03 for ; Fri, 5 Dec 2003 15:20:15 -0800 (PST) Received: from redback.com (unknown [155.53.6.32]) by prattle.redback.com (Postfix) with ESMTP id 2A4A574006E for ; Fri, 5 Dec 2003 15:20:15 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA401546FF1@daebe009.americas.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD1129A.2090604@redback.com> Date: Fri, 5 Dec 2003 18:19:54 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-auth-03.txt) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401546FF1@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Mukesh, I like it except it almost implies that KeyRollloverInterval is a protocol constant. Maybe it just because I implement the concept of key lifetime (similar to another vendor). Perhaps you could replace the statement "To control the progression from one step to the next" with "One way to control the progression from on step to the next is for each router on the link to have...". All, We are ready to last call this document. Please take a look at it. We recently changed the source address selection algorithm for virtual links. Thanks, Acee Mukesh.Gupta@NOKIA.COM wrote: >Group, > >As we had decided to add a section on changing OSPFv3 keys without >breaking adjacencies, here is the text Me, Paul and Suresh came up >with. > >Comments are welcome. I will wait for the comments till Monday and >then I will add this in the draft. > >Regards >Mukesh > >=================================================================== >X. Changing Keys > >To maintain the security of a link, it may be desirable to change the >key values from time to time. The following three step procedure MAY >be provided to rekey the routers on a link without dropping OSPFv3 >protocol packets or disrupting the adjacency. > >1. For every router on the link, create an additional input SA for >the interface being rekeyed using a new SPI and the new key. > >2. For every router on the link, replace the original output SA with one >using the the new SPI and key values. The SA replacement operation >should be atomic with respect to sending OSPFv3 packets on the link so >that no OSPFv3 packets are sent without authentication/encryption. > >3. For every router on the link, remove the original input SA. > >Note that all the routers on the link must complete step 1 before any >begin step 2. Likewise, all the routers on the link must complete step >2 before any begin step 3. > >To control the progression from one step to the next, each router has a >configurable time constant KeyRolloverInterval. After the router begins >step 1 on a given link, it waits for this interval and then moves to >step 2. Likewise, after moving to step 2, it waits for this interval >and then moves to step 3. > >In order to achieve smooth key transition, all the routers on a link >should use the same value for KeyRolloverInterval, and should initiate >the key rollover process within this time period. > >At the end of this procedure, all the routers will have a single input >and output SA for OSPFv3 on the link with the new SPI and key values. >===================================================================== > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 5 18:26:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03028 for ; Fri, 5 Dec 2003 18:26:14 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C682DF@cherry.ease.lsoft.com>; Fri, 5 Dec 2003 18:26:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63226239 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Dec 2003 18:26:29 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Dec 2003 18:26:29 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB5NQP119823 for ; Sat, 6 Dec 2003 01:26:25 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 6 Dec 2003 01:26:25 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 15:26:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-auth-03.txt) Thread-Index: AcO7hlx1uXUmWzPoQOy9PWAmRphmogAAKivg X-OriginalArrivalTime: 05 Dec 2003 23:26:22.0339 (UTC) FILETIME=[3195DD30:01C3BB87] Message-ID: <8D260779A766FB4A9C1739A476F84FA401546FF9@daebe009.americas.nokia.com> Date: Fri, 5 Dec 2003 17:26:22 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-auth-03.txt) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Sounds reasonable Acee. I will use "One way to control.." when I add the text to the draft. > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Acee Lindem > Sent: Friday, December 05, 2003 3:20 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Changing keys in OSPFv3 > (draft-ietf-ospf-ospfv3-auth-03.txt) >=20 >=20 > Hi Mukesh, >=20 > I like it except it almost implies that KeyRollloverInterval is a > protocol constant. Maybe > it just because I implement the concept of key lifetime (similar to > another vendor). Perhaps > you could replace the statement "To control the progression from one > step to the next" with > "One way to control the progression from on step to the next is for > each router on the link > to have...". >=20 > All, >=20 > We are ready to last call this document. Please take a look at it. We > recently changed > the source address selection algorithm for virtual links. >=20 >=20 > Thanks, > Acee >=20 > Mukesh.Gupta@NOKIA.COM wrote: >=20 > >Group, > > > >As we had decided to add a section on changing OSPFv3 keys without > >breaking adjacencies, here is the text Me, Paul and Suresh came up > >with. > > > >Comments are welcome. I will wait for the comments till Monday and > >then I will add this in the draft. > > > >Regards > >Mukesh > > > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >X. Changing Keys > > > >To maintain the security of a link, it may be desirable to change the > >key values from time to time. The following three step procedure MAY > >be provided to rekey the routers on a link without dropping OSPFv3 > >protocol packets or disrupting the adjacency. > > > >1. For every router on the link, create an additional input SA for > >the interface being rekeyed using a new SPI and the new key. > > > >2. For every router on the link, replace the original output=20 > SA with one > >using the the new SPI and key values. The SA replacement operation > >should be atomic with respect to sending OSPFv3 packets on=20 > the link so > >that no OSPFv3 packets are sent without authentication/encryption. > > > >3. For every router on the link, remove the original input SA. > > > >Note that all the routers on the link must complete step 1 before any > >begin step 2. Likewise, all the routers on the link must=20 > complete step > >2 before any begin step 3. > > > >To control the progression from one step to the next, each=20 > router has a > >configurable time constant KeyRolloverInterval. After the=20 > router begins > >step 1 on a given link, it waits for this interval and then moves to > >step 2. Likewise, after moving to step 2, it waits for this interval > >and then moves to step 3. > > > >In order to achieve smooth key transition, all the routers on a link > >should use the same value for KeyRolloverInterval, and=20 > should initiate > >the key rollover process within this time period. > > > >At the end of this procedure, all the routers will have a=20 > single input > >and output SA for OSPFv3 on the link with the new SPI and key values. > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 8 01:03:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14658 for ; Mon, 8 Dec 2003 01:03:40 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C6AE74@cherry.ease.lsoft.com>; Mon, 8 Dec 2003 1:03:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63441284 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 8 Dec 2003 01:03:50 -0500 Received: from 64.124.170.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 8 Dec 2003 01:03:50 -0500 X-VirusChecked: Checked X-Env-Sender: rmalhotra@bankofny.com X-Msg-Ref: server-32.tower-16.messagelabs.com!1070863368!4079186 X-StarScan-Version: 5.1.13; banners=bankofny.com,-,- Received: (qmail 1640 invoked from network); 8 Dec 2003 06:02:48 -0000 Received: from unknown (HELO lgsbrc01.bankofny.com) (160.254.107.25) by server-32.tower-16.messagelabs.com with SMTP; 8 Dec 2003 06:02:48 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Mon, 8 Dec 2003 01:02:47 -0500 Reply-To: Mailing List Sender: Mailing List From: rmalhotra@BANKOFNY.COM Subject: Ravi Malhotra is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I will be out of the office starting 12/05/2003 and will not return until 12/09/2003. I will respond to your message when I return. Thank You, Ravi Malhotra ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 8 17:33:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07823 for ; Mon, 8 Dec 2003 17:33:46 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C6C126@cherry.ease.lsoft.com>; Mon, 8 Dec 2003 17:33:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63564637 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 8 Dec 2003 17:33:58 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 8 Dec 2003 17:33:58 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 837A048F6B4 for ; Mon, 8 Dec 2003 14:33:56 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23126-09 for ; Mon, 8 Dec 2003 14:33:56 -0800 (PST) Received: from redback.com (pptp-6-135.redback.com [155.53.6.135]) by prattle.redback.com (Postfix) with ESMTP id 7C71F48F6AE for ; Mon, 8 Dec 2003 14:33:54 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD4FC4E.4020808@redback.com> Date: Mon, 8 Dec 2003 17:33:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Support of address families in OSPFv3 - draft-mirtorabi-ospfv3-af-alt-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit My reading at the OSPF WG meeting in Minneapolis was that there was interest in making this a WG document and adding the task of supporting multiple address families in OSPFv3 as part of the OSPF WG charter. We agreed to take discussion to the list. Here is a link although I think a new revision is coming soon. http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-af-alt-00.txt Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 8 20:31:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19291 for ; Mon, 8 Dec 2003 20:31:40 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C6C5F7@cherry.ease.lsoft.com>; Mon, 8 Dec 2003 20:31:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63576087 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 8 Dec 2003 20:31:30 -0500 Received: from 192.11.226.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 8 Dec 2003 20:31:29 -0500 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB91UDD09082 for ; Mon, 8 Dec 2003 19:30:33 -0600 (CST) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Dec 2003 09:30:11 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="gb2312" Message-ID: <31C0F08B0D18D511ACC800508BAE7B4707F47DE7@CI0026EXCH001U> Date: Tue, 9 Dec 2003 09:30:10 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: about Area Splitting To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I've read the Internet Draft "OSPF Areas Considered Harmful" written by Mikkel Thorup http://www.ietf.org/internet-drafts/draft-thorup-ospf-harmful-00.txt. In Section 8.0 "Summarization and infinite loops", a scenario is described where area splitting results in infinite routing loop (although IMHO it is black hole). I think it is a basic problem related to OSPF hierarchy and area range. Has this problem been discussed in this list before? If yes, what is the solution? Thank you very much! Keqin Li Bell Labs Research China Tel: 86-10-68748088-8438 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 8 21:12:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20652 for ; Mon, 8 Dec 2003 21:12:22 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C6C698@cherry.ease.lsoft.com>; Mon, 8 Dec 2003 21:12:35 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63580322 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 8 Dec 2003 21:12:33 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 8 Dec 2003 21:12:33 -0500 Received: from smirtoraw2k03 (sjc-vpn1-211.cisco.com [10.21.96.211]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hB92CVk22583 for ; Mon, 8 Dec 2003 18:12:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: <000701c3bdf9$e7abd3d0$f2ce7243@amer.cisco.com> Date: Mon, 8 Dec 2003 18:12:30 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: about Area Splitting To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B4707F47DE7@CI0026EXCH001U> Precedence: list Content-Transfer-Encoding: 7bit Keqin, Tunnel adjacency allows to both avoid suboptimal routing ( because of intra-area path preference ) and automatic partition repair when the area is partitioned and summarization is performed http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunnel-adjacenc y-00.txt There were some concerns regarding the recursive TA and a new version of the document ( available soon) will prevent recursive TA Thanks Sina ->-----Original Message----- ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On ->Behalf Of Li, Ke Qin (Peter) ->Sent: Monday, December 08, 2003 5:30 PM ->To: OSPF@PEACH.EASE.LSOFT.COM ->Subject: about Area Splitting -> -> ->Hi, -> -> I've read the Internet Draft "OSPF Areas Considered ->Harmful" written by Mikkel Thorup ->http://www.ietf.org/internet-drafts/draft-thorup-ospf-harmful- 00.txt. In Section 8.0 "Summarization and infinite loops", a scenario is described where area splitting results in infinite routing loop (although IMHO it is black hole). I think it is a basic problem related to OSPF hierarchy and area range. Has this problem been discussed in this list before? If yes, what is the solution? Thank you very much! Keqin Li Bell Labs Research China Tel: 86-10-68748088-8438 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 8 21:38:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21506 for ; Mon, 8 Dec 2003 21:38:20 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C6C65F@cherry.ease.lsoft.com>; Mon, 8 Dec 2003 21:38:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63582500 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 8 Dec 2003 21:38:32 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 8 Dec 2003 21:38:32 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A18D780CD43 for ; Mon, 8 Dec 2003 18:38:31 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19773-06 for ; Mon, 8 Dec 2003 18:38:31 -0800 (PST) Received: from redback.com (pptp-6-135.redback.com [155.53.6.135]) by prattle.redback.com (Postfix) with ESMTP id 0684880CD41 for ; Mon, 8 Dec 2003 18:38:31 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <31C0F08B0D18D511ACC800508BAE7B4707F47DE7@CI0026EXCH001U> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD535A2.1070701@redback.com> Date: Mon, 8 Dec 2003 21:38:26 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: about Area Splitting To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B4707F47DE7@CI0026EXCH001U> Precedence: list Content-Transfer-Encoding: 7bit Li, Ke Qin (Peter) wrote: >Hi, > > I've read the Internet Draft "OSPF Areas Considered Harmful" written >by Mikkel Thorup >http://www.ietf.org/internet-drafts/draft-thorup-ospf-harmful-00.txt. In >Section 8.0 "Summarization and infinite loops", a scenario is described >where area splitting results in infinite routing loop (although IMHO it is >black hole). > Hi Kegin, The traffic should result in an ICMP reject since any deployable implementation will install a reject route corresponding to its active area ranges that do not coincide with computed intra-area routes. RFC 2328 doesn't state this explicitly but it is implied by section 3.5 (it says a single route may be advertised for an area range - this implies a route exists). >I think it is a basic problem related to OSPF hierarchy and >area range. Has this problem been discussed in this list before? If yes, >what is the solution? > I'm not sure how serious the problem is since there haven't been that many complaints. However, as Sina points out, the proposed Tunnel Adjacency (TA) extension can be used to repair a partitioned non-backbone area. > > Thank you very much! > >Keqin Li >Bell Labs Research China >Tel: 86-10-68748088-8438 > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 9 02:49:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15490 for ; Tue, 9 Dec 2003 02:49:38 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C6CDF4@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 2:49:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63610281 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 02:49:48 -0500 Received: from 192.11.222.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 02:49:48 -0500 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB97nh020629 for ; Tue, 9 Dec 2003 01:49:43 -0600 (CST) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Dec 2003 15:49:41 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="gb2312" Message-ID: <31C0F08B0D18D511ACC800508BAE7B4707F47DEB@CI0026EXCH001U> Date: Tue, 9 Dec 2003 15:49:40 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: Re: about Area Splitting To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, Thank you for your reply. Let's still use the notations in that draft. In my understanding, when a packet destined to y reaches a, a will discard the packet, and reply an ICMP Destination Unreachable message. But this will not change the routing table of c. C will keep sending packets to a. What does "reject route" mean? And what does "coincide with computed intra-area routes" mean? Do you mean that because m is not equal to x, a reject route corresponding to m-x will be installed? Thank you. Keqin Li > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, December 09, 2003 10:38 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: about Area Splitting > > > > Hi Kegin, > > The traffic should result in an ICMP reject since any deployable > implementation will install a reject route corresponding > to its active area ranges that do not coincide with computed > intra-area > routes. RFC 2328 doesn't state this explicitly but > it is implied by section 3.5 (it says a single route may be advertised > for an area range - this implies a route exists). > > I'm not sure how serious the problem is since there haven't been that > many complaints. However, as > Sina points out, the proposed Tunnel Adjacency (TA) extension can be > used to repair a partitioned > non-backbone area. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 9 03:23:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16871 for ; Tue, 9 Dec 2003 03:23:27 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C6CE45@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 3:23:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63611527 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 03:23:40 -0500 Received: from 192.11.222.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 03:23:40 -0500 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB98NZ002089 for ; Tue, 9 Dec 2003 02:23:36 -0600 (CST) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Dec 2003 16:23:33 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Message-ID: <31C0F08B0D18D511ACC800508BAE7B4707F47DEC@CI0026EXCH001U> Date: Tue, 9 Dec 2003 16:23:32 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: Re: about Area Splitting To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, In section 13.3 of your draft, it states: "Note that R1 and R2 will install a discard route for the configured summary range. If the destination is not found in the attached area the packet is discarded following the discard route entry in the routing table." What does "discard route" mean? "Note that the cost of on-demand TA should be set to maximum cost LSInfinity (16-bit value 0xFFFF)." Why the cost should be set to LSInfinity? When the TA is established, what is the metric of summarized route of area 1 advertised by R1 into backbone area? Thank you. Keqin Li > -----Original Message----- > From: Sina Mirtorabi [mailto:sina@CISCO.COM] > Sent: Tuesday, December 09, 2003 10:13 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: about Area Splitting > > > Keqin, > > Tunnel adjacency allows to both avoid suboptimal routing ( because of > intra-area path preference ) and automatic partition repair when the > area is partitioned and summarization is performed > > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunne > l-adjacenc > y-00.txt > > > There were some concerns regarding the recursive TA and a new > version of > the document ( available soon) will prevent recursive TA > > Thanks > Sina > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 9 07:30:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23895 for ; Tue, 9 Dec 2003 07:30:05 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C6D37F@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 7:30:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63654312 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 07:30:17 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 07:30:17 -0500 Received: (qmail 26477 invoked by uid 404); 9 Dec 2003 12:30:16 -0000 Received: from prz@xebeo.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.532394 secs); 09 Dec 2003 12:30:16 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.102) by lxmail.nj.us.utstar.com with SMTP; 9 Dec 2003 12:30:15 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <31C0F08B0D18D511ACC800508BAE7B4707F47DE7@CI0026EXCH001U> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Message-ID: <3FD5C057.4090404@xebeo.com> Date: Tue, 9 Dec 2003 13:30:15 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: about Area Splitting To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Li, Ke Qin (Peter) wrote: >Hi, > > I've read the Internet Draft "OSPF Areas Considered Harmful" written >by Mikkel Thorup >http://www.ietf.org/internet-drafts/draft-thorup-ospf-harmful-00.txt. In >Section 8.0 "Summarization and infinite loops", a scenario is described >where area splitting results in infinite routing loop (although IMHO it is >black hole). I think it is a basic problem related to OSPF hierarchy and >area range. Has this problem been discussed in this list before? If yes, >what is the solution? > > Thank you very much! > >Keqin Li >Bell Labs Research China >Tel: 86-10-68748088-8438 > > > I discussed and started to write once with John what we considered the optimal solution (and I know some people implemented it). Basically, when you realized that you see through the backbone advertisement of an ABR in your area that you don't have intra-area connectivity to, you inject with the summary all the more specifics into the backbone. Simple to implement, the only real disadvantage really being that you may put tons of routes into the backbone. On the other hand, you're only real other solutions are either for one to stop advertising (avg. 50% of area goes down) or maybe have some complicated 'tunnel-through-backbone' solution, which we didn't think was worth the effort. If anybody feels like writing that down, I can help a bit, I don't think I will find my writedown anymore on all my harddisks lying around ; -) -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 9 08:13:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24869 for ; Tue, 9 Dec 2003 08:13:58 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C6D317@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 8:14:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63655970 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 08:14:09 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 08:14:09 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4456F88968B for ; Tue, 9 Dec 2003 05:14:08 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20173-09 for ; Tue, 9 Dec 2003 05:14:08 -0800 (PST) Received: from redback.com (pptp-6-135.redback.com [155.53.6.135]) by prattle.redback.com (Postfix) with ESMTP id A4FA888968A for ; Tue, 9 Dec 2003 05:14:07 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <31C0F08B0D18D511ACC800508BAE7B4707F47DEB@CI0026EXCH001U> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD5CA99.8080902@redback.com> Date: Tue, 9 Dec 2003 08:14:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: about Area Splitting To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B4707F47DEB@CI0026EXCH001U> Precedence: list Content-Transfer-Encoding: 7bit Li, Ke Qin (Peter) wrote: >Hi, > >Thank you for your reply. > >Let's still use the notations in that draft. In my understanding, when a >packet destined to y reaches a, a will discard the packet, and reply an ICMP >Destination Unreachable message. But this will not change the routing table >of c. C will keep sending packets to a. > Correct. > >What does "reject route" mean? And what does "coincide with computed >intra-area routes" mean? Do you mean that because m is not equal to x, a >reject route corresponding to m-x will be installed? > When you advertise a prefix you should install a corresponding route (if there is no intra-area prefix that corresponds exactly to the area range). Hence, you install a route with a null nexthop and reply with an ICMP destination unreachable (with normal ICMP rate limiting). I believe the "reject" terminology dates back to BSD 4.x although others may correct me if they are aware of a different origin. > >Thank you. > >Keqin Li > > > >>-----Original Message----- >>From: Acee Lindem [mailto:acee@REDBACK.COM] >>Sent: Tuesday, December 09, 2003 10:38 >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: about Area Splitting >> >> >> >>Hi Kegin, >> >>The traffic should result in an ICMP reject since any deployable >>implementation will install a reject route corresponding >>to its active area ranges that do not coincide with computed >>intra-area >>routes. RFC 2328 doesn't state this explicitly but >>it is implied by section 3.5 (it says a single route may be advertised >>for an area range - this implies a route exists). >> >>I'm not sure how serious the problem is since there haven't been that >>many complaints. However, as >>Sina points out, the proposed Tunnel Adjacency (TA) extension can be >>used to repair a partitioned >>non-backbone area. >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 9 11:54:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03452 for ; Tue, 9 Dec 2003 11:54:38 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C6D7AE@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 11:54:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63676878 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 11:54:51 -0500 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 11:54:51 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <13.003A91CF@grape.ease.lsoft.com>; Tue, 9 Dec 2003 11:54:50 -0500 Message-ID: Date: Tue, 9 Dec 2003 11:54:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Area Parameters To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Group, RFC 2328 says (listing, inter alia, StubDefaultCost): " C.2 Area parameters All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of routing protocol and data traffic." On the other hand, " 12.4.3.1. Originating summary-LSAs into stub areas ... Note that StubDefaultCost need not be configured identically in all of the stub area's area border routers." 1) Don't the quoted passages contradict? 2) What about ospfAreaSummary: should all routers in a stub area agree upon this parameter? If so, how can they indicate that: no bit in area options tells about Totally Stubby Areas? Thank you, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 9 12:48:54 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05310 for ; Tue, 9 Dec 2003 12:48:53 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C6D921@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 12:49:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63683816 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 12:48:32 -0500 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 12:48:32 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C6D982@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 12:48:31 -0500 Message-ID: Date: Tue, 9 Dec 2003 12:48:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Manivannan Devarajan Subject: Question about installing path to external destination To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi all, Area 0 --------- cost 1 RT1 RT2 -------o(External destination) cost 1 (ASBR) --------- Area 1 My question is, whether RT1 will have a ECMP to Ex destination through Area0 & Area 1. Or RT1 will have only one route through Area 1 to the external destination. Reference RFC2328 Section 16.4.1. External path preferences o Intra-area paths using non-backbone areas are always the most preferred. o The other paths, intra-area backbone paths and inter- area paths, are of equal preference. RFC2328 Section 16.4. Calculating AS external routes (3) ... In any case, among the remaining routing table entries, select the routing table entry with the least cost; when there are multiple least cost routing table entries the entry whose associated area has the largest OSPF Area ID (when considered as an unsigned 32-bit integer) is chosen. Thanks in advance, -; Tue, 9 Dec 2003 13:17:46 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C6DA1A@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 13:17:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63686496 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 13:17:57 -0500 Received: from 209.119.0.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 13:17:57 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <10.003A8D4F@grape.ease.lsoft.com>; Tue, 9 Dec 2003 13:17:56 -0500 Message-ID: Date: Tue, 9 Dec 2003 13:17:22 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: Question about installing path to external destination To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Mani, In the case you presented, there will be a single path to the External Destination, namely, via Area 1. If RFC1583Compatibility is set to "disabled", the path via the Backbone will be pruned before cost comparison as having lower preference. Otherwise, the costs are equal, but Area ID will break the tie in the Area 1's favor, still resulting in a single path. If you change the interface costs in a way that RT2 is closer to RT1 via the Backbone, then the path (still single) will pass through the Backbone, provided RFC1583Compatibility is set to "enabled". Regards, Igor On Tue, 9 Dec 2003 12:48:31 -0500, Manivannan Devarajan wrote: >Hi all, > > Area 0 > --------- > cost 1 > RT1 RT2 -------o(External destination) > cost 1 (ASBR) > --------- > Area 1 > > >My question is, whether RT1 will have a ECMP to Ex destination >through Area0 & Area 1. Or RT1 will have only one route through >Area 1 to the external destination. > > >Reference >RFC2328 Section 16.4.1. External path preferences > o Intra-area paths using non-backbone areas are always the > most preferred. > > o The other paths, intra-area backbone paths and inter- > area paths, are of equal preference. > >RFC2328 Section 16.4. Calculating AS external routes >(3) ... > In any case, among the remaining routing > table entries, select the routing table entry with the least > cost; when there are multiple least cost routing table > entries the entry whose associated area has the largest OSPF > Area ID (when considered as an unsigned 32-bit integer) is > chosen. > > >Thanks in advance, >-; Tue, 9 Dec 2003 13:36:10 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C6DA6D@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 13:36:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63686993 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 13:36:22 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 13:26:22 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 75C9E46EC25 for ; Tue, 9 Dec 2003 10:26:20 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10047-01 for ; Tue, 9 Dec 2003 10:26:20 -0800 (PST) Received: from redback.com (dhcp-41-22.redback.com [155.53.41.22]) by prattle.redback.com (Postfix) with ESMTP id 1FD9F46EC22 for ; Tue, 9 Dec 2003 10:26:20 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD61388.3FEA6892@redback.com> Date: Tue, 9 Dec 2003 10:25:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Anand Oswal Organization: Redback Networks Subject: Re: Question about installing path to external destination To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mani, If you have RFC1583 Compatability "ON" cost is the first tie-breaker and if the cost is same - area-id is the tie-breaker. So in your case assuming RFC1583 is "ON" you will have one route via area 1 Thanks Anand Manivannan Devarajan wrote: > > Hi all, > > Area 0 > --------- > cost 1 > RT1 RT2 -------o(External destination) > cost 1 (ASBR) > --------- > Area 1 > > My question is, whether RT1 will have a ECMP to Ex destination > through Area0 & Area 1. Or RT1 will have only one route through > Area 1 to the external destination. > > Reference > RFC2328 Section 16.4.1. External path preferences > o Intra-area paths using non-backbone areas are always the > most preferred. > > o The other paths, intra-area backbone paths and inter- > area paths, are of equal preference. > > RFC2328 Section 16.4. Calculating AS external routes > (3) ... > In any case, among the remaining routing > table entries, select the routing table entry with the least > cost; when there are multiple least cost routing table > entries the entry whose associated area has the largest OSPF > Area ID (when considered as an unsigned 32-bit integer) is > chosen. > > Thanks in advance, > -; Tue, 9 Dec 2003 13:41:55 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C6DA98@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 13:42:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63687510 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 13:42:07 -0500 Received: from 199.68.77.225 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 13:32:07 -0500 Received: through eSafe SMTP Relay 1070373437; Tue Dec 09 13:25:06 2003 Received: by uspahormsx91.gmacm.com with Internet Mail Service (5.5.2656.59) id ; Tue, 9 Dec 2003 13:31:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BE82.AE36E48A" Message-ID: Date: Tue, 9 Dec 2003 13:31:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Jeff Wogaman - TX Subject: LSA flooding on a broadcast network To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3BE82.AE36E48A Content-Type: text/plain Greetings, I am new to the OSPF LISTSERV and this is my first post, I hope I am doing it the right way! I have some questions regarding LSA flooding as it relates to a broadcast segment. I have searched the archives and am looking to get a little more clarification on the flooding process. Given the following basic topology: | | | | A ----| |----C |---1---| | | |---2---| B ----| |----D | | | | Net X Net Y On Net X, routers A and B are DR/BDR, they are also both ABRs. On Net Y, routers 1 and 2 are DR/BDR. When routers 1 and 2 receive an LSU on Net X they should flood the update out their Net Y interface. Will both routers 1 and 2 flood the LSU out their Net Y interfaces to the 224.0.0.5 address? I would assume the answer is yes even though router 2 is the BDR for Net Y it will still flood the LSU to Net Y since it did not receive the original LSU on the this interface based on RFC 2328 section 13.3 paragraph 4, correct? Now, given the more complex topology: | | |---1---| A ----| |----C |---2---| | | |---3---| B ----| |----D |---4---| | | Net X Net Y On Net X, routers A and B are DR/BDR, they are also both ABRs. On Net Y, routers 1 and 3 are DR/BDR. In this scenario routers 1, 2, 3, and 4 receive the LSU on their Net X interface. I would think routers 2 and 4 send the LSU to the 224.0.0.6 address, while routers 1 and 3 would send the LSU to the 224.0.0.5 address. Is this correct? If this is the case it would appear that we might have multiple copies of the same LSA bouncing around on Net Y between the various routers. I apologize if I have not gotten my thoughts across clearly as it is not an easy topic to get across via text. I may be trying to read more into the flooding process as defined in the RFC but I am confused on how the DR/BDR should function in the more complex topology. I am trying to understand how things should work in this environment since it is active in our current topology and we have had some issues in the past. I would appreciate any input that the forum might have to help clear up the fog for me a bit. Thanks in advance for the help on this. Regards, jeff ------_=_NextPart_001_01C3BE82.AE36E48A Content-Type: text/html Content-Transfer-Encoding: quoted-printable LSA flooding on a broadcast network

Greetings,

I am new to the OSPF LISTSERV and this is my first post= , I hope I am doing it the right way! I have some questions regarding LSA= flooding as it relates to a broadcast segment. I have searched the archi= ves and am looking to get a little more clarification on the flooding pro= cess.

Given the following basic topology:


       |   = ;    |
       |  &nbs= p;    |
 A ----|       |---= -C
       |---1---|
       |  &nbs= p;    |
       |---2---|
 B ----|       |---= -D
       |  &nbs= p;    |
         |&nbs= p;      |
    Net X     =   Net Y


On Net X, routers A and B are DR/BDR, they are also bot= h ABRs.
On Net Y, routers 1 and 2 are DR/BDR.

When routers 1 and 2 receive an LSU on Net X they shoul= d flood the update out their Net Y interface. Will both routers 1 and 2 f= lood the LSU out their Net Y interfaces to the 224.0.0.5 address? I would= assume the answer is yes even though router 2 is the BDR for Net Y it wi= ll still flood the LSU to Net Y since it did not receive the original LSU= on the this interface based on RFC 2328 section 13.3 paragraph 4, correc= t?

Now, given the more complex topology:

       |   = ;    |
       |---1---|
 A ----|       |---= -C
       |---2---|
       |  &nbs= p;    |
       |---3---|
 B ----|       |---= -D
       |---4---|
         |&nbs= p;      |
    Net X     =   Net Y
 
On Net X, routers A and B are DR/BDR, they are also bo= th ABRs.
On Net Y, routers 1 and 3 are DR/BDR.

In this scenario routers 1, 2, 3, and 4 receive the LSU= on their Net X interface. I would think routers 2 and 4 send the LSU to = the 224.0.0.6 address, while routers 1 and 3 would send the LSU to the 22= 4.0.0.5 address. Is this correct? If this is the case it would appear tha= t we might have multiple copies of the same LSA bouncing around on Net Y = between the various routers.

I apologize if I have not gotten my thoughts across cle= arly as it is not an easy topic to get across via text. I may be trying t= o read more into the flooding process as defined in the RFC but I am conf= used on how the DR/BDR should function in the more complex topology. I am= trying to understand how things should work in this environment since it= is active in our current topology and we have had some issues in the pas= t. I would appreciate any input that the forum might have to help clear u= p the fog for me a bit. Thanks in advance for the help on this.

Regards,
jeff

------_=_NextPart_001_01C3BE82.AE36E48A-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 9 14:36:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09504 for ; Tue, 9 Dec 2003 14:36:15 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C6DA33@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 14:36:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63693656 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 14:36:26 -0500 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 14:36:25 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB9JaN810155 for ; Tue, 9 Dec 2003 21:36:23 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 9 Dec 2003 21:36:23 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 9 Dec 2003 11:36:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Support of address families in OSPFv3 - draft-mirtorabi-ospfv3-af-alt-00.txt Thread-Index: AcO92+eckto4gDJOQNaO8Nqmk1MyBAAr1BWA X-OriginalArrivalTime: 09 Dec 2003 19:36:17.0135 (UTC) FILETIME=[B6B1E7F0:01C3BE8B] Message-ID: <8D260779A766FB4A9C1739A476F84FA401547007@daebe009.americas.nokia.com> Date: Tue, 9 Dec 2003 13:36:16 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Support of address families in OSPFv3 - draft-mirtorabi-ospfv3-af-alt-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Acee, Just a minor concern. According to the ID-Nits=20 (http://www.ietf.org/ID-nits.html) there shouldn't be more=20 than 5 authors/editors for a draft. This draft has 6. Do we need 6 authors/editors for a 6 page draft. Last page is just contact information about all the authors so effectively 5 pages ;)=20 I think, we should choose one editor and move others to contributors. Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Acee Lindem > Sent: Monday, December 08, 2003 2:34 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Support of address families in OSPFv3 - > draft-mirtorabi-ospfv3-af-alt-00.txt >=20 >=20 > My reading at the OSPF WG meeting in Minneapolis was that there was > interest in making this > a WG document and adding the task of supporting multiple address > families in OSPFv3 as part > of the OSPF WG charter. We agreed to take discussion to the list. >=20 > Here is a link although I think a new revision is coming soon. >=20 > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-af- > alt-00.txt >=20 > Thanks, > Acee >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 9 17:24:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20537 for ; Tue, 9 Dec 2003 17:24:45 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C6DEFE@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 17:24:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63710416 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 17:24:57 -0500 Received: from 66.218.93.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 17:14:56 -0500 Received: from [206.54.51.125] by web41011.mail.yahoo.com via HTTP; Tue, 09 Dec 2003 14:14:56 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20031209221456.96148.qmail@web41011.mail.yahoo.com> Date: Tue, 9 Dec 2003 14:14:56 -0800 Reply-To: Mailing List Sender: Mailing List From: je chen Subject: multiple address families in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I have three questions. 1) Is there extension of OSPFv3 to support OSPFv3 running on IPv4 network ? 2) I read draft "support multiple address families in OSPFv3". It looks to me it is part of the effort to support OSPFv3 running on IPv4 network. Do I misunderstand the purpose of this draft ? 3) If OSPFv3 is running on top of IPv6 only, how can it support IPv4 address family as an IGP ? Thanks, Ed __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 9 18:24:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23853 for ; Tue, 9 Dec 2003 18:24:48 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C6E211@cherry.ease.lsoft.com>; Tue, 9 Dec 2003 18:25:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63715057 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Dec 2003 18:25:00 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Dec 2003 18:25:00 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E852E305308 for ; Tue, 9 Dec 2003 15:24:59 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16089-04 for ; Tue, 9 Dec 2003 15:24:59 -0800 (PST) Received: from redback.com (pptp-6-135.redback.com [155.53.6.135]) by prattle.redback.com (Postfix) with ESMTP id 47A76305305 for ; Tue, 9 Dec 2003 15:24:59 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA401547007@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD659C3.30602@redback.com> Date: Tue, 9 Dec 2003 18:24:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Support of address families in OSPFv3 - draft-mirtorabi-ospfv3-af-alt-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401547007@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Mukesh.Gupta@NOKIA.COM wrote: >Acee, > >Just a minor concern. According to the ID-Nits >(http://www.ietf.org/ID-nits.html) there shouldn't be more >than 5 authors/editors for a draft. > Mukesh, I'm not too concerned at this point since there are many RFCs and active drafts with more than 5 authors. If the ADs complain vehemently when it gets to AD review phase then I'll opt out. > >This draft has 6. > >Do we need 6 authors/editors for a 6 page draft. Last page is >just contact information about all the authors so effectively >5 pages ;) > I don't think that length is the only metric by which we should judge OSPF WG documents. Note that the both the "Declaration of Independence" and "Magna Carta" are only a few pages (depending on you formatting) :^). Also, we did go through a lot of iterations with input from all the listed authors. Thanks, Acee > >I think, we should choose one editor and move others to contributors. > >Regards >Mukesh > > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext >>Acee Lindem >>Sent: Monday, December 08, 2003 2:34 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Support of address families in OSPFv3 - >>draft-mirtorabi-ospfv3-af-alt-00.txt >> >> >>My reading at the OSPF WG meeting in Minneapolis was that there was >>interest in making this >>a WG document and adding the task of supporting multiple address >>families in OSPFv3 as part >>of the OSPF WG charter. We agreed to take discussion to the list. >> >>Here is a link although I think a new revision is coming soon. >> >>http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-af- >>alt-00.txt >> >>Thanks, >>Acee >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 10 08:23:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10993 for ; Wed, 10 Dec 2003 08:23:04 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C6F06A@cherry.ease.lsoft.com>; Wed, 10 Dec 2003 8:23:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63800974 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Dec 2003 08:23:02 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 10 Dec 2003 08:23:02 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9DFC841DC42 for ; Wed, 10 Dec 2003 03:19:40 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20321-09 for ; Wed, 10 Dec 2003 03:19:40 -0800 (PST) Received: from redback.com (unknown [155.53.6.10]) by prattle.redback.com (Postfix) with ESMTP id F004141DC4C for ; Wed, 10 Dec 2003 03:19:35 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD7013E.3010501@redback.com> Date: Wed, 10 Dec 2003 06:19:26 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Area Parameters To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Igor Miroshnik wrote: >Group, > >RFC 2328 says (listing, inter alia, StubDefaultCost): > >" C.2 Area parameters > > All routers belonging to an area must agree on that area's >configuration. Disagreements between two routers will lead to an inability >for adjacencies to form between them, with a resulting hindrance to the >flow of routing protocol and data traffic." > Hi Igor, The general statement above applies to area type. It probably should be more explicit. The OSPF specification evolved over a number or iterations and originally the authentication type was also specified at an area level. > >On the other hand, > >" 12.4.3.1. Originating summary-LSAs into stub areas > >... Note that StubDefaultCost need not be configured identically in all of >the stub area's area border routers." > >1) Don't the quoted passages contradict? > Somewhat - when in doubt, match on the more specific statement. >2) What about ospfAreaSummary: should all routers in a stub area agree upon >this parameter? If so, how can they indicate that: no bit in area options >tells about Totally Stubby Areas? > They don't necessarily need to agree if you want to prefer one ABR as an exit point for OSPF inter-area traffic. > >Thank you, >Igor > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 10 08:43:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11609 for ; Wed, 10 Dec 2003 08:43:25 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C6F0D9@cherry.ease.lsoft.com>; Wed, 10 Dec 2003 8:43:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63804079 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Dec 2003 08:43:23 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 10 Dec 2003 08:43:23 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C6EFE6@cherry.ease.lsoft.com>; Wed, 10 Dec 2003 8:43:23 -0500 Message-ID: Date: Wed, 10 Dec 2003 08:43:23 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: Area Parameters To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Acee, On of the OSPF postulates states that all routers attached to a common area must have synchronized LS databases in that area. What if one of those routers sends a non-default Network Summary to another one, which rejects it, as it was configured to neither generate nor propagate non-default Network Summaries? Should the latter raise Sequence Mismatch? Then this pair will unsuccessfully attempt to get adjacent forever. Otherwise, accepting such a Summary by the latter router will override the policy intended to reduce the LSDB and CPU overhead in it. Thank you, Igor On Wed, 10 Dec 2003 06:19:26 -0500, Acee Lindem wrote: >Igor Miroshnik wrote: > >>Group, >> >>RFC 2328 says (listing, inter alia, StubDefaultCost): >> >>" C.2 Area parameters >> >> All routers belonging to an area must agree on that area's >>configuration. Disagreements between two routers will lead to an inability >>for adjacencies to form between them, with a resulting hindrance to the >>flow of routing protocol and data traffic." >> > >Hi Igor, > >The general statement above applies to area type. It probably should be >more explicit. The OSPF >specification evolved over a number or iterations and originally the >authentication type was also >specified at an area level. > > > >> >>On the other hand, >> >>" 12.4.3.1. Originating summary-LSAs into stub areas >> >>... Note that StubDefaultCost need not be configured identically in all of >>the stub area's area border routers." >> >>1) Don't the quoted passages contradict? >> >Somewhat - when in doubt, match on the more specific statement. > >>2) What about ospfAreaSummary: should all routers in a stub area agree upon >>this parameter? If so, how can they indicate that: no bit in area options >>tells about Totally Stubby Areas? >> >They don't necessarily need to agree if you want to prefer one ABR as an >exit point for OSPF >inter-area traffic. > > >> >>Thank you, >>Igor >> >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 10 09:00:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12028 for ; Wed, 10 Dec 2003 09:00:15 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C6F1D2@cherry.ease.lsoft.com>; Wed, 10 Dec 2003 9:00:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63805451 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Dec 2003 09:00:14 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 10 Dec 2003 09:00:13 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9D8FC17BC08 for ; Wed, 10 Dec 2003 06:00:13 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29986-06 for ; Wed, 10 Dec 2003 06:00:13 -0800 (PST) Received: from redback.com (unknown [155.53.6.10]) by prattle.redback.com (Postfix) with ESMTP id 1597417BC05 for ; Wed, 10 Dec 2003 06:00:13 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD726E3.7010509@redback.com> Date: Wed, 10 Dec 2003 09:00:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: LSA flooding on a broadcast network To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Jeff Wogaman - TX wrote: > Greetings, > > I am new to the OSPF LISTSERV and this is my first post, I hope I am > doing it the right way! I have some questions regarding LSA flooding > as it relates to a broadcast segment. I have searched the archives and > am looking to get a little more clarification on the flooding process. > > Given the following basic topology: > > > | | > | | > A ----| |----C > |---1---| > | | > |---2---| > B ----| |----D > | | > | | > Net X Net Y > > > On Net X, routers A and B are DR/BDR, they are also both ABRs. > On Net Y, routers 1 and 2 are DR/BDR. > > When routers 1 and 2 receive an LSU on Net X they should flood the > update out their Net Y interface. Will both routers 1 and 2 flood the > LSU out their Net Y interfaces to the 224.0.0.5 address? I would > assume the answer is yes even though router 2 is the BDR for Net Y it > will still flood the LSU to Net Y since it did not receive the > original LSU on the this interface based on RFC 2328 section 13.3 > paragraph 4, correct? > Correct - since 1 and 2 are DR/BDR they will flood the new LSA in a packet with destinationn 224.0.0.5 on network Y. > Now, given the more complex topology: > > | | > |---1---| > A ----| |----C > |---2---| > | | > |---3---| > B ----| |----D > |---4---| > | | > Net X Net Y > > On Net X, routers A and B are DR/BDR, they are also both ABRs. > On Net Y, routers 1 and 3 are DR/BDR. > > In this scenario routers 1, 2, 3, and 4 receive the LSU on their Net X > interface. I would think routers 2 and 4 send the LSU to the 224.0.0.6 > address, while routers 1 and 3 would send the LSU to the 224.0.0.5 > address. Is this correct? If this is the case it would appear that we > might have multiple copies of the same LSA bouncing around on Net Y > between the various routers. > Correct on both accounts. If the LSA was deemed as more recent when it was received on network X it will be flooded on network Y. > I apologize if I have not gotten my thoughts across clearly as it is > not an easy topic to get across via text. I may be trying to read more > into the flooding process as defined in the RFC but I am confused on > how the DR/BDR should function in the more complex topology. I am > trying to understand how things should work in this environment since > it is active in our current topology and we have had some issues in > the past. I would appreciate any input that the forum might have to > help clear up the fog for me a bit. Thanks in advance for the help on > this. > > Regards, > jeff > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 10 09:07:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12226 for ; Wed, 10 Dec 2003 09:07:39 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C6F189@cherry.ease.lsoft.com>; Wed, 10 Dec 2003 9:07:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63807630 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Dec 2003 09:07:33 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 10 Dec 2003 09:07:33 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1659917BC16 for ; Wed, 10 Dec 2003 06:07:33 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01096-06 for ; Wed, 10 Dec 2003 06:07:32 -0800 (PST) Received: from redback.com (unknown [155.53.6.10]) by prattle.redback.com (Postfix) with ESMTP id 6790617BC15 for ; Wed, 10 Dec 2003 06:07:32 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD7289A.40801@redback.com> Date: Wed, 10 Dec 2003 09:07:22 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Area Parameters To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Igor Miroshnik wrote: >Acee, > > On of the OSPF postulates states that all routers attached to a common >area must have synchronized LS databases in that area. What if one of those >routers sends a non-default Network Summary to another one, which rejects >it, as it was configured to neither generate nor propagate non-default >Network Summaries? > Hi Igor, I'm not sure I understand your concern. Why would one of the ABRs rejected the LSA? The no-summary configuration dictates what is advertised - not what is accepted. >Should the latter raise Sequence Mismatch? Then this >pair will unsuccessfully attempt to get adjacent forever. Otherwise, >accepting such a Summary by the latter router will override the policy >intended to reduce the LSDB and CPU overhead in it. > I think the intent of configuring no-summary on only a subset of ABRs would be to prefer certain exit points for inter-area traffic. In any case, you would still reduce the total number of summaries in the area by configuring no-summary on some of the ABRs. > >Thank you, >Igor > >On Wed, 10 Dec 2003 06:19:26 -0500, Acee Lindem wrote: > > > >>Igor Miroshnik wrote: >> >> >> >>>Group, >>> >>>RFC 2328 says (listing, inter alia, StubDefaultCost): >>> >>>" C.2 Area parameters >>> >>> All routers belonging to an area must agree on that area's >>>configuration. Disagreements between two routers will lead to an inability >>>for adjacencies to form between them, with a resulting hindrance to the >>>flow of routing protocol and data traffic." >>> >>> >>> >>Hi Igor, >> >>The general statement above applies to area type. It probably should be >>more explicit. The OSPF >>specification evolved over a number or iterations and originally the >>authentication type was also >>specified at an area level. >> >> >> >> >> >>>On the other hand, >>> >>>" 12.4.3.1. Originating summary-LSAs into stub areas >>> >>>... Note that StubDefaultCost need not be configured identically in all of >>>the stub area's area border routers." >>> >>>1) Don't the quoted passages contradict? >>> >>> >>> >>Somewhat - when in doubt, match on the more specific statement. >> >> >> >>>2) What about ospfAreaSummary: should all routers in a stub area agree >>> >>> >upon > > >>>this parameter? If so, how can they indicate that: no bit in area options >>>tells about Totally Stubby Areas? >>> >>> >>> >>They don't necessarily need to agree if you want to prefer one ABR as an >>exit point for OSPF >>inter-area traffic. >> >> >> >> >>>Thank you, >>>Igor >>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 10 10:40:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17108 for ; Wed, 10 Dec 2003 10:40:11 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C6F3D5@cherry.ease.lsoft.com>; Wed, 10 Dec 2003 10:40:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63815046 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Dec 2003 10:40:05 -0500 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 10 Dec 2003 10:40:05 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C6F34C@cherry.ease.lsoft.com>; Wed, 10 Dec 2003 10:40:05 -0500 Message-ID: Date: Wed, 10 Dec 2003 10:40:05 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: Area Parameters To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Acee, My concern is all about the description of ospfAreaSummary in both RFC 1850 and draft-ietf-ospf-mib-update-07: "If it is noAreaSummary, the router will neither originate nor propagate summary LSAs into the stub or NSSA area. It will rely entirely on its default route." According to your interpretation, if I'm not mistaking, a router having, say, two OSPF interfaces in a Totally Stubby Area would accept a non- default Network Summary from a neighbor on one interface in this area, install it in the LSDB, and flood it to neighbors on the other interface in this area, abstaining merely from the originating of its own summaries. So what does mean RFC 1850 under "not to propagate"? Haven't the router above just propagated that summary? Thank you, Igor On Wed, 10 Dec 2003 09:07:22 -0500, Acee Lindem wrote: >Igor Miroshnik wrote: > >>Acee, >> >> On of the OSPF postulates states that all routers attached to a common >>area must have synchronized LS databases in that area. What if one of those >>routers sends a non-default Network Summary to another one, which rejects >>it, as it was configured to neither generate nor propagate non-default >>Network Summaries? >> >Hi Igor, > >I'm not sure I understand your concern. Why would one of the ABRs >rejected the LSA? The no-summary >configuration dictates what is advertised - not what is accepted. > >>Should the latter raise Sequence Mismatch? Then this >>pair will unsuccessfully attempt to get adjacent forever. Otherwise, >>accepting such a Summary by the latter router will override the policy >>intended to reduce the LSDB and CPU overhead in it. >> >I think the intent of configuring no-summary on only a subset of ABRs >would be to prefer certain >exit points for inter-area traffic. In any case, you would still reduce >the total number of summaries >in the area by configuring no-summary on some of the ABRs. > > >> >>Thank you, >>Igor >> >>On Wed, 10 Dec 2003 06:19:26 -0500, Acee Lindem wrote: >> >> >> >>>Igor Miroshnik wrote: >>> >>> >>> >>>>Group, >>>> >>>>RFC 2328 says (listing, inter alia, StubDefaultCost): >>>> >>>>" C.2 Area parameters >>>> >>>> All routers belonging to an area must agree on that area's >>>>configuration. Disagreements between two routers will lead to an inability >>>>for adjacencies to form between them, with a resulting hindrance to the >>>>flow of routing protocol and data traffic." >>>> >>>> >>>> >>>Hi Igor, >>> >>>The general statement above applies to area type. It probably should be >>>more explicit. The OSPF >>>specification evolved over a number or iterations and originally the >>>authentication type was also >>>specified at an area level. >>> >>> >>> >>> >>> >>>>On the other hand, >>>> >>>>" 12.4.3.1. Originating summary-LSAs into stub areas >>>> >>>>... Note that StubDefaultCost need not be configured identically in all of >>>>the stub area's area border routers." >>>> >>>>1) Don't the quoted passages contradict? >>>> >>>> >>>> >>>Somewhat - when in doubt, match on the more specific statement. >>> >>> >>> >>>>2) What about ospfAreaSummary: should all routers in a stub area agree >>>> >>>> >>upon >> >> >>>>this parameter? If so, how can they indicate that: no bit in area options >>>>tells about Totally Stubby Areas? >>>> >>>> >>>> >>>They don't necessarily need to agree if you want to prefer one ABR as an >>>exit point for OSPF >>>inter-area traffic. >>> >>> >>> >>> >>>>Thank you, >>>>Igor >>>> >>>> >>>> >>>> >>>> >> >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 10 11:45:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22160 for ; Wed, 10 Dec 2003 11:45:46 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C6F379@cherry.ease.lsoft.com>; Wed, 10 Dec 2003 11:45:47 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63819878 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Dec 2003 11:45:45 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 10 Dec 2003 11:45:44 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1AD3C9C0DCC; Wed, 10 Dec 2003 08:45:43 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22741-05; Wed, 10 Dec 2003 08:45:42 -0800 (PST) Received: from redback.com (unknown [155.53.6.10]) by prattle.redback.com (Postfix) with ESMTP id DC7FA9C0DD3; Wed, 10 Dec 2003 08:45:41 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD74DAB.4090200@redback.com> Date: Wed, 10 Dec 2003 11:45:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Area Parameters Comments: To: Dan Joyal To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Igor Miroshnik wrote: >Acee, > > My concern is all about the description of ospfAreaSummary in both RFC >1850 and draft-ietf-ospf-mib-update-07: > >"If it is noAreaSummary, the router will neither originate nor propagate >summary LSAs into the stub or NSSA area. It will rely entirely on its >default route." > > According to your interpretation, if I'm not mistaking, a router having, >say, two OSPF interfaces in a Totally Stubby Area > You mean a stub area with noAreaSummary - "totally Stubby Area" is a vendor term. >would accept a non- >default Network Summary from a neighbor on one interface in this area, >install it in the LSDB, and flood it to neighbors on the other interface in >this area, abstaining merely from the originating of its own summaries. So >what does mean RFC 1850 under "not to propagate"? Haven't the router above >just propagated that summary? > Nope - its simply flooded an LSA originated by the other ABR. In this context, the term "propagate" refers to the fact backbone inter-area routes result in summaries in an ABRs attached areas. However, it is confusinng and the term "originate" would suffice. Dan - can you replace "orginate nor propagate" with simply "orginate" in the description for ospfAreaSummary if you haven't already refreshed the draft? Thanks, Acee > >Thank you, >Igor > >On Wed, 10 Dec 2003 09:07:22 -0500, Acee Lindem wrote: > > > >>Igor Miroshnik wrote: >> >> >> >>>Acee, >>> >>> On of the OSPF postulates states that all routers attached to a common >>>area must have synchronized LS databases in that area. What if one of >>> >>> >those > > >>>routers sends a non-default Network Summary to another one, which rejects >>>it, as it was configured to neither generate nor propagate non-default >>>Network Summaries? >>> >>> >>> >>Hi Igor, >> >>I'm not sure I understand your concern. Why would one of the ABRs >>rejected the LSA? The no-summary >>configuration dictates what is advertised - not what is accepted. >> >> >> >>>Should the latter raise Sequence Mismatch? Then this >>>pair will unsuccessfully attempt to get adjacent forever. Otherwise, >>>accepting such a Summary by the latter router will override the policy >>>intended to reduce the LSDB and CPU overhead in it. >>> >>> >>> >>I think the intent of configuring no-summary on only a subset of ABRs >>would be to prefer certain >>exit points for inter-area traffic. In any case, you would still reduce >>the total number of summaries >>in the area by configuring no-summary on some of the ABRs. >> >> >> >> >>>Thank you, >>>Igor >>> >>>On Wed, 10 Dec 2003 06:19:26 -0500, Acee Lindem wrote: >>> >>> >>> >>> >>> >>>>Igor Miroshnik wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Group, >>>>> >>>>>RFC 2328 says (listing, inter alia, StubDefaultCost): >>>>> >>>>>" C.2 Area parameters >>>>> >>>>> All routers belonging to an area must agree on that area's >>>>>configuration. Disagreements between two routers will lead to an >>>>> >>>>> >inability > > >>>>>for adjacencies to form between them, with a resulting hindrance to the >>>>>flow of routing protocol and data traffic." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Hi Igor, >>>> >>>>The general statement above applies to area type. It probably should be >>>>more explicit. The OSPF >>>>specification evolved over a number or iterations and originally the >>>>authentication type was also >>>>specified at an area level. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>On the other hand, >>>>> >>>>>" 12.4.3.1. Originating summary-LSAs into stub areas >>>>> >>>>>... Note that StubDefaultCost need not be configured identically in all >>>>> >>>>> >of > > >>>>>the stub area's area border routers." >>>>> >>>>>1) Don't the quoted passages contradict? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Somewhat - when in doubt, match on the more specific statement. >>>> >>>> >>>> >>>> >>>> >>>>>2) What about ospfAreaSummary: should all routers in a stub area agree >>>>> >>>>> >>>>> >>>>> >>>upon >>> >>> >>> >>> >>>>>this parameter? If so, how can they indicate that: no bit in area >>>>> >>>>> >options > > >>>>>tells about Totally Stubby Areas? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>They don't necessarily need to agree if you want to prefer one ABR as an >>>>exit point for OSPF >>>>inter-area traffic. >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Thank you, >>>>>Igor >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 11 13:10:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12309 for ; Thu, 11 Dec 2003 13:10:19 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C7130F@cherry.ease.lsoft.com>; Thu, 11 Dec 2003 13:10:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63960678 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Dec 2003 13:10:18 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 11 Dec 2003 13:10:18 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C7121E@cherry.ease.lsoft.com>; Thu, 11 Dec 2003 13:10:19 -0500 Message-ID: Date: Thu, 11 Dec 2003 13:10:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: How to handle stray type-4 in stub areas? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Group, As specified in Section 12.4.3 of RFC 2328, Type 4 summary-LSAs (ASBR- summary-LSAs) are never originated into stub areas, just like AS-external LSAs. But, in contrary to AS-external LSAs, ASBR-summary-LSAs are not discarded during the flooding procedure in a stub area. (See Section 13, step 3.) Nor routers in a stub area doubt such instances during Database Description Exchange. I can undestand why ASBR-summary-LSAs are not simply dropped: it would violate the consistency of LSDB throughout the area. But why not reset the adjacency with the trespasser? Otherwise, we give up the principle of not originating type-4 LSAs into stub areas. Have I missed the point? Thanks, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 11 15:48:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22380 for ; Thu, 11 Dec 2003 15:48:08 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C716CE@cherry.ease.lsoft.com>; Thu, 11 Dec 2003 15:48:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63977102 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Dec 2003 15:48:06 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 11 Dec 2003 15:38:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21664; Thu, 11 Dec 2003 15:38:03 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200312112038.PAA21664@ietf.org> Date: Thu, 11 Dec 2003 15:38:02 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Authentication/Confidentiality for OSPFv3 Author(s) : M. Gupta, N. Melam Filename : draft-ietf-ospf-ospfv3-auth-04.txt Pages : 9 Date : 2003-12-11 This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-auth-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-11160018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-auth-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-11160018.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 11 16:16:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25269 for ; Thu, 11 Dec 2003 16:16:37 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C71733@cherry.ease.lsoft.com>; Thu, 11 Dec 2003 16:16:38 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63980517 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Dec 2003 16:16:37 -0500 Received: from 207.159.120.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 11 Dec 2003 16:16:37 -0500 Received: by xprdmailfe1.nwk.excite.com (Postfix, from userid 110) id B7960109ED1; Thu, 11 Dec 2003 16:16:36 -0500 (EST) Received: from [66.32.181.4] by xprdmailfe1.nwk.excite.com via HTTP; Thu, 11 Dec 2003 16:16:36 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ee51de19c6188d2910a75a505152baa1 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20031211211636.B7960109ED1@xprdmailfe1.nwk.excite.com> Date: Thu, 11 Dec 2003 16:16:36 -0500 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: How to handle stray type-4 in stub areas? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Igor, Resetting an adjacency to get rid of a single LSA is a bit harsh and usually would not do the trick. If a router is constantly injecting (incorrectly) a type-4 LSA into a stub area, then your proposal would keep the adjacencies to that router in a constant state of flux (very harmful and unneeded) preventing "good" destinations from being reached. Being liberal in what you accept is the edict here. Basically, silently ignore the type-4 LSA. Whether or not you install it is up to your implementation but definitely do not use it to build any paths to ASBRs outside the area. Essentially, you keep one or more extra LSAs in your structure (if this is an issue, there are larger problems in that network). Others might have additional thoughts to add. Cheers, Don ============================ Group, As specified in Section 12.4.3 of RFC 2328, Type 4 summary-LSAs (ASBR- summary-LSAs) are never originated into stub areas, just like AS-external LSAs. But, in contrary to AS-external LSAs, ASBR-summary-LSAs are not discarded during the flooding procedure in a stub area. (See Section 13, step 3.) Nor routers in a stub area doubt such instances during Database Description Exchange. I can undestand why ASBR-summary-LSAs are not simply dropped: it would violate the consistency of LSDB throughout the area. But why not reset the adjacency with the trespasser? Otherwise, we give up the principle of not originating type-4 LSAs into stub areas. Have I missed the point? Thanks, Igor _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 11 17:24:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28988 for ; Thu, 11 Dec 2003 17:24:15 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C718B9@cherry.ease.lsoft.com>; Thu, 11 Dec 2003 17:24:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63986088 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Dec 2003 17:24:15 -0500 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 11 Dec 2003 17:24:15 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBBMOET09582 for ; Fri, 12 Dec 2003 00:24:14 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 12 Dec 2003 00:24:13 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 14:24:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: I-D ACTION:draft-ietf-ospf-ospfv3-auth-04.txt Thread-Index: AcPAKWZJT3LZldcHQJmVTGtS0WR0YgAC5Uww X-OriginalArrivalTime: 11 Dec 2003 22:24:11.0211 (UTC) FILETIME=[802369B0:01C3C035] Message-ID: <8D260779A766FB4A9C1739A476F84FA40154703B@daebe009.americas.nokia.com> Date: Thu, 11 Dec 2003 16:24:11 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable A new section (9) "Changing Keys" has been added in the=20 new version. Comments/questions are welcome. Regards Mukesh > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org]On Behalf Of ext > Internet-Drafts@ietf.org > Sent: Thursday, December 11, 2003 12:38 PM > Cc: ospf@peach.ease.lsoft.com > Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP=20 > Working Group of the IETF. >=20 > Title : Authentication/Confidentiality for OSPFv3 > Author(s) : M. Gupta, N. Melam > Filename : draft-ietf-ospf-ospfv3-auth-04.txt > Pages : 9 > Date : 2003-12-11 > =09 > This document describes means/mechanisms to provide=20 > authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension=20 > Header. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-04.txt >=20 > To remove yourself from the IETF Announcement list, send a message to=20 > ietf-announce-request with the word unsubscribe in the body=20 > of the message. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ospf-ospfv3-auth-04.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-04.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 12 01:28:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13771 for ; Fri, 12 Dec 2003 01:28:54 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C72537@cherry.ease.lsoft.com>; Fri, 12 Dec 2003 1:28:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64030969 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Dec 2003 01:28:52 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 12 Dec 2003 01:28:52 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2FD0A7D4121 for ; Thu, 11 Dec 2003 22:28:51 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21695-04 for ; Thu, 11 Dec 2003 22:28:50 -0800 (PST) Received: from redback.com (unknown [172.31.254.34]) by prattle.redback.com (Postfix) with ESMTP id 6D7CA7D4134 for ; Thu, 11 Dec 2003 22:28:50 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20031209221456.96148.qmail@web41011.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <3FD9601B.7010209@redback.com> Date: Fri, 12 Dec 2003 01:28:43 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: multiple address families in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20031209221456.96148.qmail@web41011.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit je chen wrote: >Hi, > >I have three questions. > >1) Is there extension of OSPFv3 to support OSPFv3 >running on IPv4 network ? > No - although one alternative discussed for virtual links and IPv4 address families is to natively carry OSPFv3 over IPv4. >2) I read draft "support multiple address families in >OSPFv3". It looks to me it is part of the effort to >support OSPFv3 running on IPv4 network. Do I >misunderstand the purpose of this draft ? > I think you may have - what this draft would allow you to do is to advertise IPv4 prefixes with OSPFv3. You'd still run OSPFv3 over IPv6 . >3) If OSPFv3 is running on top of IPv6 only, how can >it support IPv4 address family as an IGP ? > The OSPFv3 intra-area calculation builds a graph (with routers and transit networks as the verticies) representing the area's topology . If you modify the calculation to choose an IPv4 next-hop (as opposed to the IPv6 link-local addresses) and advertise IPv4 prefixes in place of IPv6 prefixes for all types of prefix LSAs you can support IPv4 address families. Granted, I 've left out a lot of details but the approach is clear. > >Thanks, >Ed > >__________________________________ >Do you Yahoo!? >New Yahoo! Photos - easier uploading and sharing. >http://photos.yahoo.com/ > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 12 11:21:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14835 for ; Fri, 12 Dec 2003 11:21:45 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C72E1C@cherry.ease.lsoft.com>; Fri, 12 Dec 2003 11:21:44 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64083335 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Dec 2003 11:21:43 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 12 Dec 2003 11:21:43 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A9E929B7A0B for ; Fri, 12 Dec 2003 08:21:42 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17154-08 for ; Fri, 12 Dec 2003 08:21:42 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.46]) by prattle.redback.com (Postfix) with ESMTP id 72D087A09AA for ; Fri, 12 Dec 2003 08:15:05 -0800 (PST) Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Fri, 12 Dec 2003 11:14:56 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: WG Last Call for draft-ietf-ospf-ospfv3-auth-04.txt - Authentication/Confidentiality for OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable This begins the WG last call for the subject document. Due to the holiday= s, we'll have an extended last call period ending at 12:01 AM EST on January 13th, 2004. Thanks, Acee --=20 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 12 16:36:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27950 for ; Fri, 12 Dec 2003 16:36:34 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C73432@cherry.ease.lsoft.com>; Fri, 12 Dec 2003 16:36:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64111886 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Dec 2003 16:36:28 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 12 Dec 2003 16:36:27 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3867666D2AA for ; Fri, 12 Dec 2003 13:36:27 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14882-06 for ; Fri, 12 Dec 2003 13:36:27 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.46]) by prattle.redback.com (Postfix) with ESMTP id 1889566D2A1 for ; Fri, 12 Dec 2003 13:36:26 -0800 (PST) References: <4.3.2.20031212114754.030d6d20@zircon.juniper.net> Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Fri, 12 Dec 2003 16:36:16 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Fwd: Re: Extended last call draft-ietf-l3vpn-ospf-2547-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4.3.2.20031212114754.030d6d20@zircon.juniper.net> Precedence: list Content-Transfer-Encoding: quoted-printable FYI... ------- Forwarded message ------- From: Ross Callon To: l3vpn@ietf.org Subject: Re: Extended last call draft-ietf-l3vpn-ospf-2547-00.txt Date: F= ri, 12 Dec 2003 11:48:50 -0500 > The last call on draft-ietf-l3vpn-ospf-2547-00.txt has > ended successfully, and the document will be forwarded > to the IESG for their review. > > thanks, Ross > > At 10:37 AM 11/11/2003 -0500, Ross Callon wrote: >> The last call deadline on draft-ietf-l3vpn-ospf-2547-00.txt >> is extended to 11/21/2003 5PM Eastern. >> >> This is partly due to the IETF (people are pretty busy this >> week), and partly to correspond to the last call on the >> companion document draft-ietf-ospf-2547-dnbit-01.txt >> whose last call in the OSPF working group has also been >> extended to 11/21/2003. >> >> thanks, Ross >> >> >> >Date: Tue, 28 Oct 2003 08:57:53 -0500 >> >To: l3vpn@ietf.org, ospf@peach.ease.lsoft.com >> >From: Ross Callon >> >Subject: last call draft-ietf-l3vpn-ospf-2547-00.txt >> >Sender: l3vpn-admin@ietf.org >> > >> >This begins the working group last call on: >> > >> > OSPF as the PE/CE Protocol in BGP/MPLS VPNs >> > draft-ietf-l3vpn-ospf-2547-00.txt >> > >> >While this document is an l3vpn working group document, >> >the last call will take place on both the l3vpn and ospf working >> >group mailing lists. The last call will terminate at the end of the >> >day on Friday November 14th. >> > >> >Thanks, Ross >> > >> > --=20 ------ Acee From owner-ospf@PEACH.EASE.LSOFT.COM Sat Dec 13 21:38:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20007 for ; Sat, 13 Dec 2003 21:38:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C74EA1@cherry.ease.lsoft.com>; Sat, 13 Dec 2003 21:38:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64227436 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 13 Dec 2003 21:38:03 -0500 Received: from 195.117.137.85 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 13 Dec 2003 21:28:03 -0500 Received: from localhost (localhost [127.0.0.1]) by nsm.pl (Postfix) with ESMTP id 502626AFD8 for ; Sun, 14 Dec 2003 03:28:00 +0100 (CET) Received: from nsm.pl ([195.117.137.85]) by localhost (nsm.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03218-04 for ; Sun, 14 Dec 2003 03:28:00 +0100 (CET) Received: from sqix (hub3.chelmnet.pl [195.117.2.99]) by nsm.pl (Postfix) with SMTP id 065876AFC1 for ; Sun, 14 Dec 2003 03:28:00 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal X-Virus-Scanned: NSM AntiVirus System Message-ID: Date: Sun, 14 Dec 2003 03:28:02 +0100 Reply-To: Mailing List Sender: Mailing List From: Arkadiusz Binder Subject: OSPF_TE and DS To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello good people ! My ask is, will you consider in enabling onto some LSA / TLV to distribute DS polices between OSPF domain ? I see that importing/redistributing routes at the ASBR could take some unified action of classyfing packets by some rulez, to set them TOS or DS (AF's) . The redistribution of that could be in extended command syntax - such as area range. The problem point is to define the source/dest of our DS group, to do best understand all of the rulez, which must be taken at the egres ASBR router. 1. When route is inside OSPF network, then nothing happen (just we behave on ourselves DS.in=DS.out) - which might be configurable too (or already it is enabled by auto, when setting maximum reservable bandwith for each TOS or precendence) 2. When route (packet) exits from our OSPF network, and is going oudisde domain by egres ASBR, then the TOS field will be cleaned automatically (egres router know how to behave from ingres ASBR which has orginated rulez for such routes/DS) I think, that this Policy Distribution should be enabled into routing protocol, just because in large networks we could meet some QOS misconfigurations based on human mistake. I dont know now any other automated system of distributing such rulez between routers. Is it a good concept ? To not pollute list, i can't find everywhere answer for that: In Constraint Based Routing, based on OSPF_TE, could we dynamically calculate costs for different TOS based on the actually bandwidth usage of local interfaces/ Interfaces of other OSPF domain routers ? the concept is: A---C---Internet | | | | B---+ Current state A->C has 100% bandwidth used (80% NORMAL-TOS, 20% NO-TRANSMIT-TOS) Current needs A->C wants 150% bandwidth (120% NORMAL-TOS, 50% NO-TRANSMIT-TOS) -> we do some policy of queue over 100%... Current needs (after DS policing) A->C = 100% NORMAL-TOS +20% NO-TRANSMIT-TOS + 50% NO-TRANSMIT-TOS. Consider link A->B->C is empty at the moment,and i wand all NO-TRANSMIT-TOS for the same route 0/0 to go via A->B->C . If it is possible, please explain me, which of TLV are dynamically changing when traffic queues exceeds / drops . We want to create some new labolatories for students, to test,,,test,,,test,,, Arkadiusz Binder sorry for my english. From owner-ospf@PEACH.EASE.LSOFT.COM Sun Dec 14 11:22:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17460 for ; Sun, 14 Dec 2003 11:22:49 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C75986@cherry.ease.lsoft.com>; 14 Dec 2003 11:22:49 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64282243 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 14 Dec 2003 11:22:47 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 14 Dec 2003 11:22:46 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A95932C5B07 for ; Sun, 14 Dec 2003 08:22:46 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14984-04 for ; Sun, 14 Dec 2003 08:22:46 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.47]) by prattle.redback.com (Postfix) with ESMTP id EA5B72C5B0F for ; Sun, 14 Dec 2003 08:22:45 -0800 (PST) References: Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Sun, 14 Dec 2003 11:22:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: OSPF_TE and DS To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: quoted-printable Hi Akadiusz, For your experimentation, why don't you start by using the AS external route tag to carrid DS code point policy? Thanks, Acee On Sun, 14 Dec 2003 03:28:02 +0100, Arkadiusz Binder w= rote: > Hello good people ! > > My ask is, > will you consider in enabling onto some LSA / TLV to distribute DS poli= ces > between OSPF domain ? > > I see that importing/redistributing routes at the ASBR could take some > unified action of classyfing packets by some rulez, to set them TOS or = DS > (AF's) . > The redistribution of that could be in extended command syntax - such a= s > area range. > The problem point is to define the source/dest of our DS group, to do b= est > understand all of the rulez, which must be taken at the egres ASBR rout= er. > 1. When route is inside OSPF network, then nothing happen (just we beha= ve on > ourselves DS.in=3DDS.out) - which might be configurable too (or already= it is > enabled by auto, when setting maximum reservable bandwith for each TOS = or > precendence) > 2. When route (packet) exits from our OSPF network, and is going oudisd= e > domain by egres ASBR, then the TOS field will be cleaned automatically > (egres router know how to behave from ingres ASBR which has orginated r= ulez > for such routes/DS) > > I think, that this Policy Distribution should be enabled into routing > protocol, just because in large networks we could meet some QOS > misconfigurations based on human mistake. I dont know now any other > automated system of distributing such rulez between routers. Is it a go= od > concept ? > > To not pollute list, i can't find everywhere answer for that: > In Constraint Based Routing, based on OSPF_TE, could we dynamically > calculate costs for different TOS based on the actually bandwidth usage= of > local interfaces/ Interfaces of other OSPF domain routers ? > the concept is: > > A---C---Internet > | | > | | > B---+ > > > Current state A->C has 100% bandwidth used (80% NORMAL-TOS, 20% > NO-TRANSMIT-TOS) > Current needs A->C wants 150% bandwidth (120% NORMAL-TOS, 50% > NO-TRANSMIT-TOS) -> we do some policy of queue over 100%... > Current needs (after DS policing) A->C =3D 100% NORMAL-TOS +20% > NO-TRANSMIT-TOS + 50% NO-TRANSMIT-TOS. > Consider link A->B->C is empty at the moment,and i wand all NO-TRANSMIT= -TOS > for the same route 0/0 to go via A->B->C . > > If it is possible, please explain me, which of TLV are dynamically chan= ging > when traffic queues exceeds / drops . > > We want to create some new labolatories for students, to > test,,,test,,,test,,, > > Arkadiusz Binder > > sorry for my english. --=20 Acee From owner-ospf@PEACH.EASE.LSOFT.COM Sun Dec 14 15:44:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25266 for ; Sun, 14 Dec 2003 15:44:05 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C75CC4@cherry.ease.lsoft.com>; 14 Dec 2003 15:44:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64298082 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 14 Dec 2003 15:44:03 -0500 Received: from 209.119.0.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 14 Dec 2003 15:44:03 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <3.003A9CF7@grape.ease.lsoft.com>; Sun, 14 Dec 2003 15:44:03 -0500 Message-ID: Date: Sun, 14 Dec 2003 15:44:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Group, Is anybody familiar with an efficient algorithm testing network mask contiguity? Thank you, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Sun Dec 14 22:30:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07658 for ; Sun, 14 Dec 2003 22:30:00 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C762D7@cherry.ease.lsoft.com>; 14 Dec 2003 22:29:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64316697 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 14 Dec 2003 22:29:56 -0500 Received: from 195.117.137.85 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 14 Dec 2003 22:29:55 -0500 Received: from localhost (localhost [127.0.0.1]) by nsm.pl (Postfix) with ESMTP id 1A24E6AFD1 for ; Mon, 15 Dec 2003 04:29:55 +0100 (CET) Received: from nsm.pl ([195.117.137.85]) by localhost (nsm.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04501-08 for ; Mon, 15 Dec 2003 04:29:55 +0100 (CET) Received: from sqix (hub3.chelmnet.pl [195.117.2.99]) by nsm.pl (Postfix) with SMTP id AD4426AFC5 for ; Mon, 15 Dec 2003 04:29:54 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal X-Virus-Scanned: NSM AntiVirus System Message-ID: Date: Mon, 15 Dec 2003 04:29:57 +0100 Reply-To: Mailing List Sender: Mailing List From: Arkadiusz Binder Subject: Re: OSPF_TE and DS To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit > For your experimentation, why don't you start by using the AS external > route tag to carrid DS code point policy? Well, it's good idea :) but what with MPLS - OSPF + MP-BGP - the TAG is used for other purposes,,, if we can map some group of TAG for one VRF it will be polite for all solutions... Now i must check if MP-BGP can carry multiple routes for multiple TOS/DS learned from OSPF or if it is matter for that issue. (From this moment, I thing, that grouping multiple tags for one VRF, each with some DS policy will be possible to let this working OK) Well. i see many other unknown problems (i'm constructing a help site) which culdn't be explained. If we enable OSPF_TE+ MPLS capable network, then packets are swiched trough extra MPLS header, which no logner has TOS - it has CoS (Experimental and with less (3 bits)) - so PHB with MPLS services seems to be destroyed in full possibilites - PRECEDENCE ip is destroyed(unaviable) at the transport level. I've tried to ask over many list groups for contraint based routing, all examples behaves on using RSVP protocol, which inform about reservation. I cant find nowhere if it is possible and how,,, to tell OSPF_TE instance, that some link is overloaded. Is TLV with "Unreserved Bandwidth" = "router traffic % counter (aviable)" correct for telling OSPF_TE domain that some link could be used for extended traffic by different phisical router path? If yes, i;m looking for such ready applications (dedicated or some OpenSource for Linux). RFC 2211 says something like :"the controlled-load service described here may be invoked by a number of mechanisms, including RSVP, SNMP network management software, or proprietary control software. However, any" - so was right that there is no other (existing in RFC) possiblility (hardware connections with router and OSPF instance) to tell something about currently used(other words reserved) bandwidth on some router LINK/class?. In MPLS network we have to deal only with TOS (CoS) capabilites (uless MPLS transit router cant look without upacking packet onto packed L3 TOS field) , so DS services here aren't possible here, and seems to be soon dead (or can be used only in some special cases - (loose / explict routes). Can somebody comment out my threat ? A.Binder From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 08:34:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07669 for ; Mon, 15 Dec 2003 08:34:43 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C76E31@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 8:34:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64375555 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 08:34:40 -0500 Received: from 61.95.163.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 08:34:40 -0500 Received: from vishwas ([192.168.10.109]) by sinettds (8.12.5/8.12.5) with SMTP id hBFDTWJv028953 for ; Mon, 15 Dec 2003 18:59:33 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <008301c3c32d$ffb62e60$6d0aa8c0@vishwas> Date: Mon, 15 Dec 2003 19:08:01 +0200 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Igor, I dont think this question belongs here, however just thinking of it I found this could be fairly optimal. From the right start till u find the bit 1 (could make this more optimal), compare the value as stored in an array of index the number of bits. The value could be 2^32 - 2^x at index x. You could start with looking at the more possible prefix mask lengths, like 24 bits etc. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Igor Miroshnik Sent: Sunday, December 14, 2003 10:44 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Network mask contiguity Group, Is anybody familiar with an efficient algorithm testing network mask contiguity? Thank you, Igor --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.551 / Virus Database: 343 - Release Date: 12/11/2003 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 08:50:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08154 for ; Mon, 15 Dec 2003 08:50:48 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C76DB4@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 8:50:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64376256 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 08:50:46 -0500 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 08:50:46 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C76D9D@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 8:50:46 -0500 Message-ID: Date: Mon, 15 Dec 2003 08:50:32 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Vishwas, Thank you for reply. I tried to launch this question to the Networking list, but it didn't seem to be intact. I absolutely agree with your method, but it feels that there must be a trick with no iteration inside. A couple of lines, some bitwise magic... Don't you consent? Thank you, Igor On Mon, 15 Dec 2003 19:08:01 +0200, Vishwas Manral wrote: >Hi Igor, > >I dont think this question belongs here, however just thinking of it I found >this could be fairly optimal. From the right start till u find the bit 1 >(could make this more optimal), compare the value as stored in an array of >index the number of bits. The value could be 2^32 - 2^x at index x. > >You could start with looking at the more possible prefix mask lengths, like >24 bits etc. > >Thanks, >Vishwas > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Igor >Miroshnik >Sent: Sunday, December 14, 2003 10:44 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Network mask contiguity > > >Group, > >Is anybody familiar with an efficient algorithm testing network mask >contiguity? > >Thank you, >Igor > >--- >Outgoing mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.551 / Virus Database: 343 - Release Date: 12/11/2003 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 10:30:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13750 for ; Mon, 15 Dec 2003 10:30:52 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C76F28@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 10:30:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64382477 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 10:30:49 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 10:30:49 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20797 for ; Mon, 15 Dec 2003 10:30:34 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18812 for ; Mon, 15 Dec 2003 10:30:29 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 10:30:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55FB713A@vie-msgusr-01.dc.fore.com> Date: Mon, 15 Dec 2003 10:30:24 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Igor, -> I absolutely agree with your method, but it feels that there -> must be a trick -> with no iteration inside. A couple of lines, some bitwise -> magic... Don't you consent? You can check whether "log((~mask)+1)" is a natural number or not. If it is a natural number then mask is contiguous, else it is not. Note that, you should not check for whole numbers to avoid some degenerate cases. And the asymptotic complexity of the above simple algorithm depends on the underlying RAM model and arithmetic in hardware. If you want to know more, look at some DNA string matching and computational biology books. Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 10:49:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14364 for ; Mon, 15 Dec 2003 10:49:03 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C76FD6@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 10:49:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64383453 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 10:49:02 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 10:49:02 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hBFFmxrX007228 for ; Mon, 15 Dec 2003 07:49:00 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOM17850; Mon, 15 Dec 2003 07:48:59 -0800 (PST) X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.0.1.1.2.20031215073708.042e1ff8@mira-sjc5-b.cisco.com > Date: Mon, 15 Dec 2003 07:43:34 -0800 Reply-To: Mailing List Sender: Mailing List From: Fred Baker Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list At 12:44 PM 12/14/2003, Igor Miroshnik wrote: >Is anybody familiar with an efficient algorithm testing network mask >contiguity? On a 32 bit two's complement machine, one can isolate the least significant "1" in a number by lso = (mask) & (-mask); and test 32 bit mask contiguity by 0 == mask + lso Extending to a 64 bit machine should be obvious: test for the mask itself being zero, or the sum being 0x0000000100000000 for a 128 bit mask, the simple approach is to structure the number as four unsigned 32 bit ints. Some may be equal to zero, and some may be equal to 0xFFFFFFFF. The one in the middle meets the rule above. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 10:55:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14553 for ; Mon, 15 Dec 2003 10:55:34 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C76F22@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 10:55:35 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64383711 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 10:55:33 -0500 Received: from 61.95.163.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 10:55:32 -0500 Received: from vishwas ([192.168.10.109]) by sinettds (8.12.5/8.12.5) with SMTP id hBFFoQJv029163 for ; Mon, 15 Dec 2003 21:20:27 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <008601c3c341$af88bb10$6d0aa8c0@vishwas> Date: Mon, 15 Dec 2003 21:28:56 +0200 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55FB713A@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 7bit I think I agree with Venkata. I got exactly the same idea and thats what I got back to reply. Cheers, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Naidu, Venkata Sent: Monday, December 15, 2003 5:30 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Network mask contiguity Igor, -> I absolutely agree with your method, but it feels that there -> must be a trick -> with no iteration inside. A couple of lines, some bitwise -> magic... Don't you consent? You can check whether "log((~mask)+1)" is a natural number or not. If it is a natural number then mask is contiguous, else it is not. Note that, you should not check for whole numbers to avoid some degenerate cases. And the asymptotic complexity of the above simple algorithm depends on the underlying RAM model and arithmetic in hardware. If you want to know more, look at some DNA string matching and computational biology books. Venkata. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.551 / Virus Database: 343 - Release Date: 12/11/2003 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 11:44:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16099 for ; Mon, 15 Dec 2003 11:44:29 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C76F6C@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 11:30:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64392398 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 11:29:58 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 11:29:58 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Dec 2003 08:33:07 +0000 Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBFGTtAt014622 for ; Mon, 15 Dec 2003 08:29:56 -0800 (PST) Received: from cisco.com (sucia.cisco.com [64.101.210.69]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA24002; Mon, 15 Dec 2003 10:29:54 -0600 (CST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FDDE181.4080406@cisco.com> Date: Mon, 15 Dec 2003 10:29:53 -0600 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Igor, I believe that for a non-zero network mask m, the condition you want is: (~m & (~m + 1)) == 0 - Paul Igor Miroshnik wrote: >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Igor >>Miroshnik >>Sent: Sunday, December 14, 2003 10:44 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Network mask contiguity >> >> >>Group, >> >>Is anybody familiar with an efficient algorithm testing network mask >>contiguity? >> >>Thank you, >>Igor >> >>--- >>Outgoing mail is certified Virus Free. >>Checked by AVG anti-virus system (http://www.grisoft.com). >>Version: 6.0.551 / Virus Database: 343 - Release Date: 12/11/2003 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 12:00:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16645 for ; Mon, 15 Dec 2003 12:00:37 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C770D2@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 12:00:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64406178 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 12:00:35 -0500 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 12:00:35 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <1.003AC008@grape.ease.lsoft.com>; Mon, 15 Dec 2003 12:00:35 -0500 Message-ID: Date: Mon, 15 Dec 2003 12:00:34 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Vishwas, Venkata, Fred, Paul - thank you! It works wonderfully. Igor On Mon, 15 Dec 2003 07:43:34 -0800, Fred Baker wrote: >At 12:44 PM 12/14/2003, Igor Miroshnik wrote: >>Is anybody familiar with an efficient algorithm testing network mask >>contiguity? > >On a 32 bit two's complement machine, one can isolate the least significant >"1" in a number by > > lso = (mask) & (-mask); > >and test 32 bit mask contiguity by > > 0 == mask + lso > >Extending to a 64 bit machine should be obvious: test for the mask itself >being zero, or the sum being 0x0000000100000000 > >for a 128 bit mask, the simple approach is to structure the number as four >unsigned 32 bit ints. Some may be equal to zero, and some may be equal to >0xFFFFFFFF. The one in the middle meets the rule above. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 12:10:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16982 for ; Mon, 15 Dec 2003 12:10:55 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C77232@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 12:10:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64406925 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 12:10:49 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 12:10:49 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24884 for ; Mon, 15 Dec 2003 12:10:17 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06442 for ; Mon, 15 Dec 2003 12:09:43 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 12:09:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55FB713B@vie-msgusr-01.dc.fore.com> Date: Mon, 15 Dec 2003 12:09:41 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list -> You can check whether "log((~mask)+1)" is a natural number or not. -> If it is a natural number then mask is contiguous, else it is not. Realize the hidden beauty in the above algorithm. If the mask is continuous then the result will return the "mask length". (32 - log(~mask + 1)) is in fact the mask length. Converting back to mask is also straight forward (~(~0 >> masklength)). Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 12:27:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17466 for ; Mon, 15 Dec 2003 12:27:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00C77298@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 12:27:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64408688 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 12:27:04 -0500 Received: from 209.119.0.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 12:27:04 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <3.003AA273@grape.ease.lsoft.com>; Mon, 15 Dec 2003 12:27:05 -0500 Message-ID: Date: Mon, 15 Dec 2003 12:26:57 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Venkata, Indeed, it's very succinct and beautiful formula. The iterations, though, are hidden inside "log"-routine as a payback for added value - mask length. Thanks, Igor On Mon, 15 Dec 2003 12:09:41 -0500, Naidu, Venkata wrote: >-> You can check whether "log((~mask)+1)" is a natural number or not. >-> If it is a natural number then mask is contiguous, else it is not. > > Realize the hidden beauty in the above algorithm. If the mask is > continuous then the result will return the "mask length". > (32 - log(~mask + 1)) is in fact the mask length. Converting > back to mask is also straight forward (~(~0 >> masklength)). > >Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 12:31:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17630 for ; Mon, 15 Dec 2003 12:31:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C77291@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 12:31:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64408959 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 12:30:59 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 12:30:58 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 39C1841826D for ; Mon, 15 Dec 2003 09:30:59 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03365-01 for ; Mon, 15 Dec 2003 09:30:59 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.53]) by prattle.redback.com (Postfix) with ESMTP id 87505418260 for ; Mon, 15 Dec 2003 09:30:58 -0800 (PST) References: Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Mon, 15 Dec 2003 12:30:47 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: quoted-printable On Mon, 15 Dec 2003 12:26:57 -0500, Igor Miroshnik wro= te: > Venkata, > > Indeed, it's very succinct and beautiful formula. The iterations, thoug= h, > are hidden inside "log"-routine as a payback for added value - mask len= gth. Hey Guys, Let's shut this thread down or take it offline before subscribers that are interested in OSPF start unsubscribing (although I agree that the log() function probably performs worse than going back to the an iterative bit compare and shift to get the prefix length :^). Thanks, Acee > > Thanks, > Igor > > On Mon, 15 Dec 2003 12:09:41 -0500, Naidu, Venkata > wrote: > >> -> You can check whether "log((~mask)+1)" is a natural number or not= . >> -> If it is a natural number then mask is contiguous, else it is not= . >> >> Realize the hidden beauty in the above algorithm. If the mask is >> continuous then the result will return the "mask length". >> (32 - log(~mask + 1)) is in fact the mask length. Converting >> back to mask is also straight forward (~(~0 >> masklength)). >> >> Venkata. --=20 Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 15 12:31:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17637 for ; Mon, 15 Dec 2003 12:31:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C77259@cherry.ease.lsoft.com>; Mon, 15 Dec 2003 12:31:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64408965 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Dec 2003 12:30:59 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Dec 2003 12:30:59 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Dec 2003 09:34:08 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBFHUqZ2015152 for ; Mon, 15 Dec 2003 09:30:58 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOM26878; Mon, 15 Dec 2003 09:30:51 -0800 (PST) X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 References: <39469E08BD83D411A3D900204840EC55FB713B@vie-msgusr-01.dc.fore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.0.1.1.2.20031215092755.044428d0@mira-sjc5-b.cisco.com > Date: Mon, 15 Dec 2003 09:28:39 -0800 Reply-To: Mailing List Sender: Mailing List From: Fred Baker Subject: Re: Network mask contiguity To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55FB713B@vie-msgusr-01.dc.fo re.com> Precedence: list At 09:09 AM 12/15/2003, Naidu, Venkata wrote: >-> You can check whether "log((~mask)+1)" is a natural number or not. >-> If it is a natural number then mask is contiguous, else it is not. > > Realize the hidden beauty in the above algorithm. If the mask is > continuous then the result will return the "mask length". > (32 - log(~mask + 1)) is in fact the mask length. Converting > back to mask is also straight forward (~(~0 >> masklength)). yes. It does make some interesting assumptions about floating point arithmetic that may not actually work on a specific implementation, though. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 16 07:55:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13521 for ; Tue, 16 Dec 2003 07:55:09 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C78979@cherry.ease.lsoft.com>; Tue, 16 Dec 2003 7:55:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64547749 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Dec 2003 07:55:07 -0500 Received: from 80.68.244.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Dec 2003 07:45:06 -0500 Received: by HotBOX.Ru WebMail v2.1 id hBGCj0wk063674 for ; MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="HotBOX.ru_1071578700d651c0427cbad04588d1969821e34f56" X-Mailer: Free WebMail HotBOX.ru X-Proxy-IP: [212.150.43.131] X-Originating-IP: [212.150.43.131] Message-ID: <200312161245.hBGCj0wk063674@www5.hotbox.ru> Date: Tue, 16 Dec 2003 15:45:00 +0300 Reply-To: Mailing List Sender: Mailing List From: Alexander Cheskis Subject: OSPF routers with port rules question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format from HotBOX.ru --HotBOX.ru_1071578700d651c0427cbad04588d1969821e34f56 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Dear Group, I need to find routing solution for attached (PDF scheme) network configuration. Router 192.168.20.2 can relay traffic as shown: (port rule 1) From bottom networks (192.168.50.x) , to the bottom ports of 192.168.40.x (port rule 2) From the top networks (192.168.20.x), to the top ports of 192.168.30.x Obviously, when all port2port traffic is enabled on 192.168.20.2, everything is fine. All 5 routers are OSPF enabled in the same area. But when port rules are applied, bottom networks can't access top ones and visa versa. Thanks in advance, Alexander Cheskis --HotBOX.ru_1071578700d651c0427cbad04588d1969821e34f56 Content-Type: application/pdf; name="OSPF_and_PortRules.pdf" Content-Disposition: attachment; filename="OSPF_and_PortRules.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjYgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDggDS9IIFsgM TA3MyAyMTIgXSANL0wgNDE1NTAgDS9FIDM5ODA3IA0vTiAxIA0vVCA0MTMxMyANPj4gDWVuZG 9iag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA gICAgICAgICB4cmVmDTYgMzIgDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDk4NCAwMDAw MCBuDQowMDAwMDAxMjg1IDAwMDAwIG4NCjAwMDAwMDE0ODkgMDAwMDAgbg0KMDAwMDAwMTY5N SAwMDAwMCBuDQowMDAwMDAxNzM0IDAwMDAwIG4NCjAwMDAwMDE3NTUgMDAwMDAgbg0KMDAwMD AwMjM2NCAwMDAwMCBuDQowMDAwMDAyMzg1IDAwMDAwIG4NCjAwMDAwMDI5NzggMDAwMDAgbg0 KMDAwMDAwMjk5OSAwMDAwMCBuDQowMDAwMDAzNTg1IDAwMDAwIG4NCjAwMDAwMDM2MDYgMDAw MDAgbg0KMDAwMDAwNDE4NiAwMDAwMCBuDQowMDAwMDA0MjA3IDAwMDAwIG4NCjAwMDAwMDQ3O DcgMDAwMDAgbg0KMDAwMDAwNDgwOCAwMDAwMCBuDQowMDAwMDA1Mzk2IDAwMDAwIG4NCjAwMD AwMDU2MTQgMDAwMDAgbg0KMDAwMDAwNjA0NSAwMDAwMCBuDQowMDAwMDA2MDY2IDAwMDAwIG4 NCjAwMDAwMDY2MjkgMDAwMDAgbg0KMDAwMDAwNjY1MCAwMDAwMCBuDQowMDAwMDA3MjMyIDAw MDAwIG4NCjAwMDAwMjE5OTQgMDAwMDAgbg0KMDAwMDAyNDY3MSAwMDAwMCBuDQowMDAwMDI3N zEzIDAwMDAwIG4NCjAwMDAwMzIwMTcgMDAwMDAgbg0KMDAwMDAzNjE2OSAwMDAwMCBuDQowMD AwMDM5Njk5IDAwMDAwIG4NCjAwMDAwMDEwNzMgMDAwMDAgbg0KMDAwMDAwMTI2NCAwMDAwMCB uDQp0cmFpbGVyDTw8DS9TaXplIDM4DS9JbmZvIDQgMCBSIA0vUm9vdCA3IDAgUiANL1ByZXYg NDEzMDQgDS9JRFs8ZWI4NGY5MzkwNmY1YjRjMzU4ZDU2Y2YxNmQwNzM3MDg+PGQ1NDMzYTIyZ DcyYmZhMDQ4ODgyZDIxOTFhZWZhYmI2Pl0NPj4Nc3RhcnR4cmVmDTANJSVFT0YNICAgICANNy AwIG9iag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAzIDAgUiANL01ldGFkYXRhIDUgMCB SIA0vUGFnZUxhYmVscyAyIDAgUiANPj4gDWVuZG9iag0zNiAwIG9iag08PCAvUyAzNiAvTCAx MTMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzNyAwIFIgPj4gDXN0cmVhbQ0KSIliY GCQY2BgMWQAgmkxDNgAB5QWAGIZKGZgEGXgY7rDPYGlgYHTgIGhH6jsCgND9wEGjj0MDL0Hjr JlMDC0NzBwHJ8ZNIP7rNNbJuNcB0uoQYwMDLN6gTQTEHsABBgANEMR1g1lbmRzdHJlYW0NZW5 kb2JqDTM3IDAgb2JqDTEwMCANZW5kb2JqDTggMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy ZW50IDMgMCBSIA0vUmVzb3VyY2VzIDkgMCBSIA0vQ29udGVudHMgWyAxMiAwIFIgMTQgMCBSI DE2IDAgUiAxOCAwIFIgMjAgMCBSIDIyIDAgUiAyNiAwIFIgMjggMCBSIF0gDS9NZWRpYUJveC BbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0 +PiANZW5kb2JqDTkgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIF0g DS9Gb250IDw8IC9UVDIgMjQgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDMxIDAgUiAvSW0yI DMyIDAgUiAvSW0zIDMzIDAgUiAvSW00IDM0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxID M1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAxMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTA gMCBvYmoNWyANL0lDQ0Jhc2VkIDMwIDAgUiANXQ1lbmRvYmoNMTEgMCBvYmoNNTMxIA1lbmRv YmoNMTIgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMSAwIFIgPj4gD XN0cmVhbQ0KSIlMlE/LFDEMxu/zKfoJsk3Tpul5BVFQkD2KJwVRXETeg1/fPMk4fdnD7G+a5s +TZG5vH1y+vxx/jmkkWqr/5iLuRYaStXjUXr4+j9u7J5c3v49Px+3+ouX+CONaHvePB5f3hcv PwtTK38K1fCifv9TyzQ9+lKOL+1lanv6PyczBaPXyK3i00isjFrjSAneaJ1ZznLBybouqls6V mgVP8mNuuARUEsdBPZy3TurO2I2Sm3vtrRKndSV1Z/62BbPhHm5xmLMSOw5kDBQaHsxDpndPY sHcaCq4GjXwOqNVT8OjewkzuZFH84JBslYEl7Nwl4cmrBOEpsXhSmMPFaiBNmnlXQ4cSBiB8r Y1EotEBOjtnJlnWM9JjKoV8cE9RBnoMrBF1k2ILdilhjk666g+Je6M12muSgOs0S/RHu3jDin AkseeeaA7LxBqBXHoXTX1Fq0hQZWzDmcIWivKCfbBOdVP6DR0W8pi9PvyJGaktiNBKNt5iEkq kkmK1exM1gCdpu4SZY6UMxWATku3QHjY1g9W2deQFz5O61BfdMDJ1RyksHbrkN/cnUX6WUc2H uWtayxAontqwFX3SEGpa95wGH3NaQTqnlUEaq9mGXmw7llHmq3vXYBUQ69VQZX8apNEZ+p9bp roQoL/F1Emn5uVewqpMlqssUw9nceSQ6lq+xsgxqju+kaIdep+/k+AAQB83PEJDWVuZHN0cmV hbQ1lbmRvYmoNMTMgMCBvYmoNNTE1IA1lbmRvYmoNMTQgMCBvYmoNPDwgL0ZpbHRlciAvRmxh dGVEZWNvZGUgL0xlbmd0aCAxMyAwIFIgPj4gDXN0cmVhbQ0KSIlMkztuG0EMhvs9xZ6AHj6Ww 6njJk0Aw0dIKyFIlevnJ7nWGCqkT8P3Tx6mg5acGpP0fBymTBdwDeK4OQKsNLw4H/PX58Fnfj 5//DomrTj/nYf6qNdn+S17mf49ppwDH3yx4X8Y/n4ebz+fcr7/OT6OUa8Zi0kylLDfoYSvLiE y4qMYJdpAZVJs2YENo3njCOBMq+Qq3XiQRDH8gJJOiQONG2JaBR9BjmA8KZodUU0wjrJGEkcw EZJmST8TI25zGAKr4sfBC0UgmcyOzsuyB5Og6cWIk7w6G8ciQ3ZoMpudkA2zbNJKrnfjHDBL6 4I5acZ5zz0ZqQq9Ef+3Lyf6yoIzUXu7k0YVooWaBWSdbQ2v7NozP/iKGspFo2JfXlWL9s7wZS RpnlImCimC8foyH3Qle+nFFiUfZJN6ttnPqLwQwaEmjIpKJ4Mq3MZWIxh692EVxSCDRjMW52v 6BUaXb0tdnHq/ImlA/9iZNCDlrkMhAe8iFQrY7kFTA98t6rx6nD0BnULL94B0Doo9P/W4da3x KiRp656++pVBXuIovtaWTl16nK2swqn7aOFxcG1da5Gkvrcmuc77Xqk8z9e+5WPrWtuY6HtXM 5F82+Wsg33vepbZuvYtqN8C9Klkl/ztktRnz/u+NEU7M16HqJP7su47VbRT2fqMdXoF/y/AAA 5P7/wNZW5kc3RyZWFtDWVuZG9iag0xNSAwIG9iag01MDggDWVuZG9iag0xNiAwIG9iag08PCA vRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE1IDAgUiA+PiANc3RyZWFtDQpIiUyUPZJU MQyE83eKdwJh/VrOSQgpjkDKFsX9E1qyYV0b7HxjuSW15HmEmfLVuWjk++sRVhrxajJNabY60 DSyPLwEPEkbnRy4BnEeToSvVimG1qpPP54/z4SImrwDf/is9qonZbw+BEX8/Hi+fPvQ9+vv5/ tjKq/beD/wiUvTTWgZlIq9DpFKmkeV5JY0D6Ji944Cy6pa3I0kmyfVcdSlwkAn7ousxcUoIBb IuVmg6mHEO3pQQCyCpJmz7nkkcYdzEANXVVyo5Eg2+ajzqB58QrRMsZEkxXqyDSf44zBnbhZC tolvQbpWJ5+ncRhbQ/KWKstn9uHawUjVGI0Y2Np3udGr4EqkLZVCml1IjbXWYe46O3pO4rrcz RdbmwJjWxthVXXMvQSKOCmTnFob5mh5pCcc5nnx6Hlp9Ea5txXF2seOyhshDsLwm9pJ97H91h Kp2c/TB7gMNat2mgHH/QZN8rgi1Wven0oKx/PKhO3Jqw4sD19FYlvs6kF4z/Vfi7y2nccBLMe KyyC8pbz8Yzlz3fbWrsTl/lgl8jmcMbclZ3Qjtp1nstik3ccZ/LAdvdcCpPfWgEdcKzXufcNh z/VsIzCuXcU/uXcZdXBcu44yxa63MM4AzlNBFN8vqX6O4npp3AX+f4j79+XzneLWzrafMS6V+ F8BBgD+LvEhDWVuZHN0cmVhbQ1lbmRvYmoNMTcgMCBvYmoNNTAyIA1lbmRvYmoNMTggMCBvYm oNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNyAwIFIgPj4gDXN0cmVhbQ0KSIl MVDuyHDEIzOcUcwIsgQQod+LQ5SM49ZbL90/cgOaNapPtFTSfbvYabOT3ZKHm959r8KKmwJOM A0uLh8lOwzdefE/pJAk7zYCDum/sCBcLlsB4HA3ffl3/LnMSvRs+tqiPW6aS882dqY3W79+f6 9uPT7+//71+ZiqD+/OQ8hy0xluUp0X2V0+sjextmVUi6mskViWuEWNiVo+kgIpR2DqNJOdBCj IT8sIMVjalXtGNFGQYhRN3jzz2FgMFRiBgdhwQTaCYy2bvLWZgH2S5nwaewHNXa5MGqruSFWZ CNTcKJGtlcd+Dy9JQibOULCHzfFwVjFIJNWH8Xrk94YyGo5AklTOJZyOhq0Agqz4z2pAVyRz1 A49YCqZsyW2cXYeq2Yo14liSUXJj1QIymzscSszAnHqJjpQvkupZ8lnReUKQAyEoUerE+LFXc MsVzLXn0GRhOEu8MMDefoFGU4/IYaH3yzSgvx+VBqQ8+pBVG9lNipYyewaR0vUZcZ/JswFc0d JjQbCeH/uD9UrXWi+ct6Nr+9yD5BWnr1rJlg5OtEPZbnuOLTyMuV5bAIkergFueliq6+G38LS /bgTUw6soxKeX0UdmP15HmzyOW+AtwD4VTNnPS8I/Ue77ubT4J/L3EON4/bhTHHtVqzMWTvL/ AgwApg7w0g1lbmRzdHJlYW0NZW5kb2JqDTE5IDAgb2JqDTUwMiANZW5kb2JqDTIwIDAgb2JqD Tw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTkgMCBSID4+IA1zdHJlYW0NCkiJTJ Q7kpwxCITz/xRzAixAQih34tDlIzjdLZfvn7h5jFc1wcxXkhpoYJ4pm/wlumj46+OZcmgYeNO WYB1xIHPQ9OYjYCVNZFqBRuzNHtdTJRiHK4R+PX+f7SEy8NmHeL54cjwT1tfvz+fbj8/5+v7n +fkIW776xK+VemvSmVAJjngLSUvyzHRs0G6MbE1p1bFmNWYknsxRrHk8ChyoQjbTTPHhZBDbS l5sUJWN2vL2mGQQQxVSLPFOfEQtwfgBTAc+Hj6bFoK5ljqfrEF80rZkIQleFY390ER0R9BiI0 TzTUWawb0LZ0TdcTtDbXTL8zBd4o1QiVbIdOotB1qaH4E0peCOeiaiiRoJRJ51Gz2KxxLxwcv DFFQ5UntZZh0NzVTQKQmTNqX2ElKI7fW+PmgFS/aLZ3ZC9ggrgnceGzJPhDgoqgla6bdJ+c1z pgXrdB3gMHRlOcmAt/sJCG7XTUQzuZTwZX5Fwnj6lYeecqSTVKvOdA2q3dcuEZuglwPi0YMvg 8TIL/9kdl/LXpG+3e4Lh8hXc/iUJd069rKzO8u76+jGs9XtGguQ2jU14NzV90ixXfPGvdg9jW zVmJ5VBJJ7lpFHve5ZR5rV194F6Qb0qqBKvjdJtPx+b5qsSPD/IsY/lV97ir+ijNZrrJLi/wQ YAML871YNZW5kc3RyZWFtDWVuZG9iag0yMSAwIG9iag01MTAgDWVuZG9iag0yMiAwIG9iag08 PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDIxIDAgUiA+PiANc3RyZWFtDQpIiUxTP a6bMQzbv1PkBKr1Y1neu3QseoSuDYrefyklGfHDA/LC2KYoUnqEmeIlOmnE688jrDQceNGSwp YHYoMsDt4CrKQFJ82EThwHR17fyZIYXDOJfj3/HjAO/OFf/qY+Xr/fz7cfb3l9//v8fFTspdt fb3zTpNEdtA2PE+OFDWiVwpIqbBitAyHSxqLZx5zljQdJqlLe6NG4HiUMiDdItSJnJwcZL4rG yWoyiPu2kIMMNaTxyHcmRlzXRxADVuMJ4QiKyTrsQ7IHk6DlhSEq8e5qsnER1XXQamyEasrUi Ku4nsYlInMxbTBpRR2WSxIoVdALrk2733LBlYKzUL9eRholpJJcnAJSZ932TZxde9ZP7GUKxq S43Uo1cuncHe7kdabidhQBGXzv6zNoJvbKS6ZXfDBa+nj2MZQXBDnSRPiFtPwe3n5jdMqCoac P4DQUvmo0xuAc9xsYTb83NT2Vy6Tw1ONWUtgaV4eGtiMtUmN0Mt2DwtXlt0Vds+1sB3RJZvAx SNeguP6px8m17FV8ntvlvvpMkk846tqWdHQKznWTVefTRweP/erbNRaJ1O/UJO4V7ZHKbfzMW x52rjWNCf3OahaSL7OcOtjvrKdMsbsL6ieAXpXskr9skvpqv8+mKZpf8VlERe+9Wb2niua7Wq 2xLi/y/wIMAEL37a0NZW5kc3RyZWFtDWVuZG9iag0yMyAwIG9iag08PCANL1R5cGUgL0ZvbnR EZXNjcmlwdG9yIA0vQXNjZW50IDkzNSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjExIA0v RmxhZ3MgMzIgDS9Gb250QkJveCBbIC0xMzcgLTMwNyAxMDAwIDExMDkgXSANL0ZvbnROYW1lI C9DRkhBQlArQXJpYWxOYXJyb3ctQm9sZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxMTggDS 9Gb250RmlsZTIgMjkgMCBSIA0+PiANZW5kb2JqDTI0IDAgb2JqDTw8IA0vVHlwZSAvRm9udCA NL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTE4IA0vV2lk dGhzIFsgMjI4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI3MyAyMjggMjI4IDQ1NiA0NTYgN DU2IDQ1NiA0NTYgNDU2IDQ1NiANMCA0NTYgNDU2IDAgMCAwIDAgMCAwIDAgNTkyIDAgMCAwID AgMCAwIDAgMjI4IDAgNTkyIDUwMSAwIDU5MiAwIA01NDcgMCA1OTIgMCAwIDAgMCAwIDAgMCA wIDAgMCAwIDAgMCAwIDAgMCAwIDUwMSA0NTYgMCAwIDAgMjI4IDAgDTQ1NiAyMjggMCA1MDEg NTAxIDUwMSAwIDMxOSA0NTYgMjczIDUwMSA0NTYgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb 2RpbmcgDS9CYXNlRm9udCAvQ0ZIQUJQK0FyaWFsTmFycm93LUJvbGQgDS9Gb250RGVzY3JpcH RvciAyMyAwIFIgDT4+IA1lbmRvYmoNMjUgMCBvYmoNNDg1IA1lbmRvYmoNMjYgMCBvYmoNPDw gL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyNSAwIFIgPj4gDXN0cmVhbQ0KSImsU01v E0EMvc+v8DFBWnfs+T62wAGoEFLmhjilW6k0baquRP8+9swGsglVL2ilrD3v+dnPszGOCmZwq aDNsDOOCW0ElwkTt5wVcNmjz3NeWPKErqUOg6TFIuU5z0IvTlU095JotDFehV7AeKsdg42YIj zMqeeCwt0Zyha8YwFaFJtqZuRlfKCzdOv0Fr1FV00X7azu2lmnLOLIOltX7/QWvUXvVub04Ix zmEelgMUDB51WVTUSDVlPaHyNIumZD/YoCt5q5EjLe7IxF++nCNsJqD3T9lEIrEuPnFAuMOg9 DM5K/DyaW3NVzUWtLNx6axKWDFaeFnjvkLM0lCVBfTC2QSppoW7158Wsru8e79f1pxkIOWUGf VsH9YNZfRnHp+Fyd/drVAIhkagd4df7/ZMiH2uzyHQwq3fQLf6N+lJmsz3ZmDOTVMIrJv9pje RzPbH2PwzJDamcvJgtBrHmCnprSVt9X1FhpJhRBDivB0opoD86Desf9bORpTvx0IQPWBS11sC iLdCxr3v49A0ub26ex2lqg8s/MQbwGBa1Ya6t7xZnrGe6lSWb/yCnOoJQa5Nk/HBWSDPcRxxe m5FkaxRgKItiN3cV7ZyCrPAEdA0s54BvLWOrGk5H8l31twADAPI//eMNZW5kc3RyZWFtDWVuZ G9iag0yNyAwIG9iag01MDQgDWVuZG9iag0yOCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY2 9kZSAvTGVuZ3RoIDI3IDAgUiA+PiANc3RyZWFtDQpIiWSUy44UMQxF9/mKLAekMYntOM6WxxY hpv8AwQL1gMSA+H38SEY0qBdVR47t6+tKl/sJOkdt9fK23PWF0EWBG9CLy9dyv/4PsAfeXQpJ q7SkPtqbWjDgWmgKEJ6IMrCeiNUQ3hFuDU6Am8KSE+gTOp4IDkA9Eeqw+BRTBKyMC5CjUWDnK Les9M17HjtZJAhTnrNoEozns/9QHr2Wh/L6UkxXs589mAZMF4bA9fJY7j58//Hz46/r56ftTo +TD2/eFzeu/q4FcVSUbm3R5Pg7uR3XgsQ+MYr4SWcFFWMFUme2g8azuZfOCkON0b0xHqbY4wQ rUMFpAEV1azMNZSdLFp8TOMKToVnzqbv5DKucp6MvUAJXHNcF4r2j02Lr6DFFN9dW2rNUeN1C gXeawb351CZEE8eWGf4StpDJKYts8ZIzqssmanG6Q6yVzH6XJStVk32X6WCoJGZPQ2EYHMvLd Tx9+lZo9L0GT3LfpLu9ntW9GtrKs4nxwODYg/PMuMS8jNCSVTZLrDWzCVpo2EAYgkg2R2s+rc lNcl6HlycPT8uB3EsbsJ0BY37JJTtLxufGUBpX6S8/Zn4EzouDcxc8chIF3BgfpJ5BR3wT5jb xLefutqXX8uXl7TXBYffDHnbPOrYeN+X8lTRo9VXtsi/MHwEGAL724+wNZW5kc3RyZWFtDWVu ZG9iag0yOSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE0NjcxIC9MZ W5ndGgxIDIyODYwID4+IA1zdHJlYW0NCkiJ3FYJVFNXGr4vG5DI1gSdsYgXKJUlxJewKCDWEA LGYTMJMVLrmIQHiSZ5Ie+xFRWIFsGttFVcqSju4LgUl/FMHXr0iOJS17qMVkfGqda9xR107oM q2taZc+acmTNn8s49797//+5/v/sv+R/AAABeoAKwwaRkjSq1X0nIeiS5CYAoNFMzVDYl3D4X AD8RkulMNoNjA3mvDYDsAwBgq01FNJxZMGYg0lsB4OzOc+Tbxl708QFgYCha78u3luZt2vwoD 4BoMwD+sWbCkLv70PgQAMYz9mLNSOBFuEcDEIDOA++YbXRJi7qpBYDByAY/zUqaDGsGNVMAZD UAwA21GUocbtPYyJ6+E+Gh3WAjnlQ3cgAYhzhi+Q6SotE90G+cldE7nIQjt243moZNAEDQD02 wnod5A5EQvRkezEuAu0RuPI/wqtFVDz0xN1aDS/gIdwk7WRgm9cL78dx7NSwuF+CTePwIHsbB XMNYGKdBjWfh4lck/qsCKvzBiJ4nExgBBUhgBQSg0RjJPDh83R7HZ99eGXlvUO6dI5vu5MC3N 5Y1uLzfw12sVjTCWCJhTcvx2dfW7fsypm3ZvOr2we0a3Se450uuGAdRqvxcOhgfxGNnc/jC/j rCadFY8u1Q6yykaJhB0MWkc4p0AO7HAARCrxcAMVTZTRKpGA/vVQT37bTYCKihDTaHxZ4PNYS zyGIioJokaWk0LutFR2RkwjSVPEmVptKOh3KFQpmlVSaLYagpLG4YfP0MPGCAZ9wwPEYqw4fh 6JeDlnFSWZT0p+X//gUqV7zqc4wL2JXzkN9rWJWV4KQE3jVPFUdKKv238ratE+z09Rx3XnO2s ONgVPi2Uw883o/+8XrtM49+x/7yds4fj3z3oHprfeuskBvT9D7U5JJDBX7d+/UPwpr0E+s43Z FGX32lf3vBgtNB+qGnD4u4M2N3L9jYkj7m+u2EoE26JdMDl1urWsekLprcsjb2dJdH5MmWuGU sNkrqn6UEG/GK913+EXfkiesVT8tOb+hsLu3idi1MLAjeEBF6aa6QqHkmnoV9nLPU2O67rqJz 5x7RzuO6JVPcjcr9q9acjynnBn3rjORUcddN9ej/mUhx92H/9G/c5i/zseqf8WMWtdesuMRxL A+fZpj/1TVBwdL1bXnGpMSFC4Jki4NqZj/JdX/n/oknKH+PoBHL8gNf+i49r7gV+DRFP7OmPa W6NuS2aNL/XxI3S4fgIb2GA/45jRc3Fbzxpv8WxRf+4f/CP764N6NwE7qr7DThtBM0Xln/i5S eg6Iwi0npJsOtlk3zalNrL7T4TrRc4Jcba3nSI0efV3+SckYVv+D6Kd579ZtWleTcfNxlUmbu EtjxO6timyI9Lt0jhzR5jp3EjcksP6rNPLZTnHRWcGzeronPd1Qc66hrKQ9SJflYTy7eguka9 34tWRHfWb5ev/ZMEHF1blPJ8j+dS00yvx85rXs7C2P/SkLbJj1d8vvVli9OljkijMEByXDs5m C/Npr1WPXDkIETmqsKYtwjHnz87eXtddfmrPtdB3VgtEf9lvNzzvt92s6+6hGi432XsTp1zfF xKaeG6+4HHtn7bkJkiOzosit/HpX6/VlbatHVVrzRu+Jo+dmE6Q2PF4ZLI/yeHBDdurjlerbc kRIpno67PNai4d3AZmEslk9pXp19xpZjO7C37PWtLUTBq4xZKKENv+L1N0coCpf2Bjz8ZUYoS JuNcJosBivUkHl0scFJwKxCo9VCmQknBRXynpQcjkdLY3H8ZUoyS1lUTFxMXA7uwj74j5OQpu DJvZsSi4uLJUVoI4U2SkykbSjqwCRloUln6VBFloY5g3Q6JNBYCtVEnkTM5LUkTZvM5HKsdCQ +otdOTLIl30KjA1XJUGE1UBSMgpEw3WJykhSi0MdDZ7Bacg20hbTDIplUgHsw+3lCVrZGKsR9 mYW7kD/OQJlR6dGkXeqDe/W6wk1N5NpIe640APdnJGyRX595BeJIOnvMvtAL3qBHDoY/ryIX5 gmQ3J3lwjDQUnvi3fW5f7/ht/e5rUyeyX9MhhcclfxGs1YWe/mU+a8x3aq3ztZ1EV9rRHAP5+ CH9w86bAtuHv5iczi+VKafumPDlJD8Ja1Xir/nXr3TUfdwk+C3a/8wYqbjyiNyQuY00lutnO1 3hriQALkdiSuti+K9BCHCW4GH4Py4D40zuAeDB3ap65vr0+rOjMjQJ7rKbnvE6LabW5OUqxKk jU/PLnya3SZe37g3LPNo52d32YPL7vnFb3i0MWsG12a8O0dYPfxch78X9RVv1O7QvTeOfFrQt idv20pt0DeC/KmPZpXWNOfxN4590u0M7Kr6YH/nGK+bekNw+rGt8bmXhZ9PPPCRLa3/5kQ3VM iNLu5F3MU91xOdQUIOCwe4gJl6czhsFrcBr6xmVhinsgKfXuFTVve344pu8+Ifhx+2J/wgcK0 0/RcKycVloc9ODA9kmHAw7DlnAC7CmS+/vi+7/myWWwVA0UYQPoeHI/K8UbiLE/sKhs9sdXGC kXhwQ1jFEDNNO6j4oUP/RWGsdLF3VbrYLVqzhYImwklb8iwmA01AS0/BMMlGUEzVOIk8wknYT YQYGuy50EJTsJBCMApStNNioq2lfKrQOJkw0ZAmxZA2E7DPCS/tMvWS5TSYaKYhotZEEzbCTs NQxCSMj2hSDEAqwdEhRQaL1WC0Mkxet9Z3AWig4/lvumgCw1oZaUNmEA6iEyKdREEhQdHUqNd xpJOPoC+Ar8dUDGUxcVEojAbUIeVFBBKkk4V22oBY6SxEsRiFEMZF49FR/GyNHOEcpU5Lvplm mqQ0Li72Z+YglFutUM0gKPRHRKGeTORKoEKp1spVGfxxcrVanqFVKTUwWaVRpMlV6cpkKM9If qUPp6nSVagNS/gMOkOVkRoPtaOVMFujhJkpaKrS9JhTpagUcq0SoqVGq1YptGnjoSY7aYxSoY XaTGYLX6dU/4P5Kg+L4sjir6q6Rw5F5FI8YisrqCDOABEUIY44yCjMwAwY1pP7SDiUS7zIgIi iK7goUVHihbiXUaOf4dCgRnR1jeKJV+Kx0YluRGE1qKi9bwYRwq7ft3/tt10zX3dVv1f1e+/9 3qtqJX54qbrIK9UqIVgj9wtV+ilQDycIUqhCEbZhCaVWG4brCfKw0AC1BrGYdYDUdlggKIOCA 5VvMSvCgzUKrVbotAqdoPILDJtkmKVz1AxxByk0fgHY7bBSrRH8laEqg7o/PsuFYDli9AsLlG uE4DBNsFqrcDEu8rEyMFBQqUPNJiqMTgpUGBX81CqtIiQMwSvlgS6oolKGKqe91ekAq0arNMI keZB8skLrKmgVCjODnYb9wjDHJAVKBWrR036pmPspGLLUuO5cjE9Mx7IQGyOkpKYYaBWXGBuj bU8EeQZmRlQmJpBZbDbqG8mdFZmUGSukJ0QiD1JSM4SoWCE6FV/FGCeJTBcio6Mz09ozMC41L dmYM2ZZ7dsNSiBTDQiUclezHWN0Hv9NmneMJ6XGp7rGJ8ZJc/cYKonA5e6S6qQ6iXlEQQApeK 4gPQjBgeESE6wqPI8V1G7ge+dHJ0mj3klS6TSprV23eijFwwrp79Mx6JRu9Gxi5078rqYISYm RUa5CUgbmwq9Pl2C8pHZdKt0AzkQqwWqHv27nHsNJrTRw+4Kw6xkzVw07Vik8Sarav8h/0Rdb FtbMkwTYWsWemTXieYh34bx9T228sq8Xf2muG7NmVsD6evAy09ZN8BRXWjslw2SP1oBA17SWE xdzXk9KHVp8vmTL39c90otw6lhT2sBrm1nKwaPRi9yyJ3l/sWxlW36B53BXfaWXp2/Nq3/mOc jyOC+swR5oujTzf7B//IfDYE+JSbtTKM/D1txjUvt3XjJlsq4bC4dnjM6euazbtiMd3KnIyaw 4y3WHrKZ8NZ9Rhwuzp4cUWNRJ47qI95SFS6dtddW5gBzSIBEiIQkEUOE9DVsqzMfeRLwnQQw+ xeFTCmRs+41uqIFjbymW3HHUMXIsIy0zNmPB3NjR3Q46XB6BEM9+c3NbSW1kZW1Nr3PSbRXnL 6nrZyiLx4zjm89tcvyb7wVwdbz1gP90cEre9hFNhVM/vrRQWlS3+IivaUX5N6snZMstfjh+bV ZL+ZHPF7SVDTkcUvjglsNNW5chz6yjnyTeuhe+OC2udN21JO/zNXVfy6Za5NFNNZeLSp6oDpV fEryLffpN0Ec1JIRx5QU5TqZubtmlra21S25MKdPGW//ORTLr7D9ur7Kd10oHNSfrcnzCrraq sus3eR+c2Hw/d6ld035h4NS2H3/5y555MrZj93dH87ctWCt5MeDq6kH9Jf3LEgJcttJgq8wQc txFt3B9Mx80viDiiMnj7c2p363qv9jBRer/watteaQBz3pnOiMkkeWRwzhUbaBebtX//VcttY XDfcqu+z0a0uYfnl942n/FmmFNNhHd6Ptbab+u7DV/1+lBkLzv3vCy3sYPkg/dvNzcPNzdvab /G3l39ZR9Vlk+ru2k6eidqRUsqjupcnVe7ELf6oL9B/JvXCk8sOWuf8AKbfOBaRNrW5oC4lep MjaGVG9s2J2SXe9omeTcy/FkWtbkBMeQssimJ1k1t+1nnM19rb88qvzeJZu9JTrnKT8vqdoXV Tkl/NHZFy8f7vjoWb+csaord9j+dc9mxP2hZXaP4Q9vTUx3q9PcKDr6oM+Yc20JCmc8BzIHeg gYAF/Gu2PhW9t+p+YQR61MeGoukVBKGeVwbDl0uYLUKjVmldBG2/s9ssgeAWDLrUZDj68Be+O /Euw5R7AHEPUd/zdJot7w7k202ET1YhN/FKxoo/iUPwI9xSu4Dt67riS+56I+1Mf4vhHec7XL wUN8fPg+GVCDGxhm+Ayeg57YQzYsAgp94WfwQ79sBrW4B1qAwEu4K34PH8J98SRWlntiMUopY B68Rt0BsAVu49hhrD53UNIaboIL+MLvoRwqYBc0wPdwF0yhP3ijbiGcgfvwgvDicdS1Q+8MgB EwBTLha6iFK/AjAl8J5vAB9vXwCJ4QK6YUv4JBKDMT5kAWbIQK6sw0YAWrYB/sh1M4v55QYi/ OFBPEi+JVsAUH8AQvUEIszIVSbDvhINSh5Dlc4Rqi0UMzsSeTySySQaqYA3NlOlEHMxDdetgA 1YjxMrTCa2JBRhJnMpPMJRtIFV0Ig2E4jEI7EyEddNiWo5UH4QTO14q0HkjKSBW5RxX0JTNjg 9kGtpHVcISbw61Gf/EYWT/UDQEN1uNP0eJFkIutCHbAl7AXauAbaIY2rO9TSTIRaT2zYX1ZBH sslol7xWsYhV7QG5wQgTOMhjHYvGAC2hgO0ThfAnyCts6HxZCDcy7DVgqbjP7/M85t8O0hOI5 IT6NljXADfXYH4/ALrocbE+GJDemHHnEinkSJ60eTeFJESshu0khN0RoVS2b5rI6dYOfZI64v N5Ybz/3EE95HMlJS/Eb/5rHoJh4Qa8QnaCeDHhjtQTAEsTqDK/hjU8J09O4ciEe/ZWFbiIzLR 4zLYQWsgRJEuQujcxouwiXEdhN+QNa1ILpWEAkQE9IHsbW3gYjRjbgjzvFEReaTdWQXqSb15A JpopbUijpRGfWgaqqlUTSaxtO1jLLebChG2J15sQjOkQvnYrjl3F7uEFoAvCXvy2v4Cv5bySh JPjyAp/DTr1MEsyIK8oyPc0wcuGoyjubgnquGbbCZlJICMhtuU4FsAAny6hj8CS2ZzUJe7Xst ISvIKKIhDWQ18aQD6AzIIYRZkF5sKTvKFcFk1guWkU+oBamhCtbIdlJrcooOZzZQy8LIEnKWW vE+/Le0Hj00DCNynUuAkSwCprLHrIR5YRRiuPEYGRnmgjkdC/6kBZn1R2R+A6cnD0gzss2OOq E3b5IKUgEqao1cvU1CaTiVkqXYjmFGW8JJ+ByZkgd/ZZYAE7w/8h031svTw91NJh3tOsrFeeS /mK/62KiOIz7v884Y7ANsMByUd3mcSbEtQ1KCQ104uA9/JWATA3fUpc/GUEPaxIQkztmhdlRF qGciaCohQPnDkRIUNZGyR1HkRKhy1T+iqkKBWm7U5h+kNqIfkFoIUJomvP5m7z1zdtT+Xet+O 7szs7Ozs7Ozz998cE11dLX9QMRa9Y2VK8LLl1UtXVJZsXjRwlB52YL5pfNKggHT0PH1SbVJO+ VYotoRerXd3FzHY7sbjO4ihiMssFKzdYTlSDVrtmYMmgfnaMYKmrEZTSVkNVJjXa2VtC1xOWF b48rejjT6ryTsjCVuyv7jsq9Xy8ECDCIRzLCSVX0JSyiOlRSp5/tySScBe/nSeXE7fmBeXS3l 55WiW4qeSNn9eSW1WZEdNZXclFcpuABeiVY7kRQtdoJdEFo02d0r2jvSyUQ4EsnU1Qolvt/uE WRvE+U1UoXichlhxkVALmMd4u3QqJWvncidGA9Rj1Mzv9fu7e5KC607w2ssrBFNdkI0Df6lqq 52XDnfmRYl8XGFOtPvU6s7km8ZSSQyvNqiePp4sXpYyyWrDlk8zOWOW2KsI10sjXCbycBoXW3 bznQEXtvJExZvY2da7gBGlap6OMk83mZhwwfsJHOcw5YosbfZfbnDDg5reU7QzmzkwvLW2Pvu NWpNWrnOtB0RW8J2pjuxIl9BuZ3ZX7bErJbZkrrafGhhIdL5snKvM39BcefAjEz2pDr34LUfa oU9sluQIsLab8GTtC3UaAM3Bxoot78BavjLKIjoIcTPyYU28UEY0ZBt5e4QEsG+eWM2p9vjmN HQHeIup8tMykHu90VNjVi7ljMlEMfRwrPNcryhrvZ50Wb3hyzRhpBRexqTMpvqEfJIhE95dDx GPRiIkY50YWxRT/gCxeprMkJ1WDLhSyp3sWTEl8xMd2yk80U8EUSVIlg98ysPLVmc7NsklCX/ Q3ygIMf1SVp53Yjm2tPV3bnRcLWTO5HB0aRwFXO5lG2lck6ue9wd6bGtkJ3Lt7Xl+pOOv6Vxd 2I0LGInMn0KgioeLkRDLI6ntbCaKfTUsIZe2xN2W8fedIN3aEKP4tfSayd7DyGFRnoO47zw6z 7BiRbJhUTr3QjrqdHQFfvXilAWC6oICaVRuq0IWiwUHHyL0JY2QFjH+wy8eG87UfBJvE3XA67 cedGf+nNlEt8oXN0nC1Dr6bS2krq081QObDKmqEW/RK3KSWqDbA+wUX2FlmpTlIS+g/EG0Kwy 6d6DfhPwMrAW2AKsAtqAZk+WBDZgzhvAKGxsZzvA47pKe8yD9BDWImAQaAeyukNDkL1ohKkD4 yGsdRQ2VqJ/DPyXjAEa4D7krdAdBGV/h9D/DuSr0X8BfTLXkwGq6I57D/xFWH+AfQZdhfW/r5 13b6Nvw3Yj5E+BpkDZ30fAr+A+8IK314vgH+E+4vMD8AeAOPAM0Ib4PA35g5i3DGP2twR+BUH nAaVaM62AznrlY/oZaBTrb/T2TXLfvGd/T/CfffovSLF/xYBP8NG9CXwM/LHIt7k4WgzMbdAe pt3eGZUC69XH2KaM1zP6lPs5wzxJeezrLKDrvbTePOl+AD+/ZVykMxg/BDQyMF/RX0McblMtZ IPmaXodfFLXAz+iVWovVZpR2oj4NcM+4wnYHON8gF4n1p0GXaV/SsthawewB2u/CerHiTg+4H 0bZ4v8cr9CnxDbHwK7EYdjwPfYR/hQz3vis1eW3buOfhRrbQY4R/iMlvH+C2dLDuZ3wZYi1ym cRYE6Mv+e8mMLfM4++JC55oFtwb6q1rt3QMuBSuAtzjvOOWAH8BPWwfpB6JdwznLecH5yjnB+ 6JfcrzBOsO+FPeBu4Dy8e5PBfL6XFYBlZKnNQ0QPyvh0cN7ynZmxjfySue3TIOJNnPvKq7xPm f/3aVZ/D3L2AXvn/JqhuHuw28sU/xNmJX0HtHAvB3wq48L5hjvJ98KjnUV7Xe3dk9VaFJTjxz npUy8WPtVu0bCM9z7EJIga8wWwkrbox2iL+hmt0S+gT+4/9X10Wj1HWwPv0iBCsQP/up6dQ88 wAlPKYeNDmtAmsc/LdBYxbdKn1Af0KcUw3nb/pt9UJoy31R9z/+u0GIj3/wcOwp+/G1Ouq0+h 8qO2B/5RDMVivo9gjXIm+KQyHtiFGkl0G3haj8FODDVpAjqVAFEU/F3IK64TWaOPHuX3gN8Js 4NatBvItyl6Vf0D8hlA/wJof1Eezc65ubnkUT9f51JZz1V5r3RdxR2edH8PXAWuA38FbhUo7Q MO8fvANZpzkOu09hY9V8hXxMTPz1/RMOhzfn5+LU/v56cta93cvJxD+X3hGu/fU/jxrP5nGbt GWSNR57hOcq3j98/Xn0uL5h9B7fi3vPOXaa93r/mOR4EkbLzu1RHUYve4rIfn3DvGLfeOVgl6 0L1qLnH/ZQy7l7Hv1My7+p5Xy3Cf/PdUxgRvpP+W6o9Sp1fPmD+oTcvYrJZvJ95QYzuljG3UL t8X5gW9O4h4ck3QrtJujjF8n6/pBb42Slu4JvJZMB+8I/wuqjekPK6Xoe72wc5V0A+pTL9Fji HnuH9iHuswZR77b3xEa7gW6L/A24Gz4n2wP3z2gTpaan6Bb4NLVId5w3oF9jyOvVySdJjjIOe +434pbX2GWIQpCtmQBM95jcJePIaKYyHfZ44FbBpn5NqK/jupf9A8Q8OmQH26SBXmKHjjBf/M 38g3pETehTJ6DPEaUi/REb1GnvUjOt5YLYFvjKD3Fjcj/2ow/oSGtbvo897vQp/rPr/5G1ELk RfYX4K/KTDviPYRYjNAR42fwsZvaZnxCfwNIv/HqN44h7OYdL8s1G1882Bt8LdxfnvfM3yfLp pdVGHcYh/gT7P8divldaEr/cWbOBVop5cNk9Yg78oAfkfXFL6b3E+3uvSu2kUCuAZoeOm78MX 5rPpdtCF8TcSAEUCjMbTXAJUstZXWAf3ACDABXAFMcHZg3ojagdZBOwZcATSM2sGbQDsNqLC7 k9oBFas0w2IzeoTWH40Ap4AxwIRmMyw0w/5syQQwDQQxrwnzmuBXE2w3YUdNkDZhroN2BDgFj HkSA2s1zZqjz8y4AlwDpqVeO1q20D/HiolZKayUgjQFaQrSFCQpLsloLWCuhgnbKdhOwXZKxu T+zFOAACZmLITmWGmXEl93zNMtthiQ+r4uW9dhfxvibqF1AB6NAQKYBsytVZDFIYtDFocsjjk +h0fXJCek5MkC1in5WKlmZddlY9n+rN7/gfIfxqsGKKrrCt9z33u891h0d/l5LoK8XbfGH6Is AjFUkn3gLmncMSKsgWWFLKQEYqcjFrcTcbKl0xIlTrKbOmnG/GGT+pOflsdD4y7YQjtNptpJt DgZnXEUJpPG2pbRadW2tkLPfVCTTmynD+67557vu985976fPS9MeiCsKZR093Tj90BPPZXxjV J+LQryPEtSIoYqs057RSVWm9Vp9Vj58oT1gFW3jlnPWCet16yibAUVisALfHk/DMAonIYJuAo zgIigCkWCV0BEGBBGhdPChHBVmBEQ4VSuiPNyiHAD3Ch3mpvgrnIznCgTi83itHgsvFVUxSLR K2JAywGLbhmznLFMWq5ZxH5xQBwVT4sT4lVxRhS1JHVqQ0Ditrgz7olr8Zp4JN4Z74kn4umR+ LU4nfWOxc/EJ3EoOk95To2d4vbye4URfkTg8/g8IcAHBH4tv1Z4h39H4Deq/Sq1qqpKNxb0F1 BrgVpAZWuBVaXStlzw5mq5WL7acuk2B3gdmoMSh82B++YguUjISeRQb46WQ0mOLYduy05kU2+ 2lk3xuzEbSdlYlEr6E2mq/sTIzHW8IxT4wDgnqkn4QFtwrk5UNkcc6uaI3aGQ6mqsJDLtkjYC F9GS4V0jVojEI0Ysgt1hI3ZJrbTAG6Qdyy4VfgRB/i1yGAVfhqDxkqKkYP+skYRmI6bglLARW 4ldgxF7hs18lMSEUpxZA0G6k4RwZgAnTDhx5sMQ1OSTi5R/xpapfw+fYAHI3yAIS4+vUH4XW6 d+GqtMhxPoPANBuRY2EIWcRpWLRrvyYQp5LxtfVX6ThODQdbdyivW/zFdOJploIkcZwWWk5kS PI3mdsUo5huDRowuVgy1JodRQfxweMeE30Ytp9LNwFhy/DsHMdxFRyGsYbrMRVF5lE8+rygtI WfY6rkchCYTY5DhqbzNKlb6f30lyN7oGjAeUHkySO2E8ozyNmPgUaiv4Vg6mlRqXlE50LXnMV PomUzLUJ2OVNnOPD5Go2R8kjcsCjAH9pB6FVQgZ0cPqz9CspxlkIwL+ofqBPNx61YiOqpU2WI QVxS/IKCL5OOXr5D608tBaRVahtXCo/lM3snOP1Z9zKbcaU0zeUP5an4R5x5crZ6Me9bfdSZb LR/WpxVcZNhxNguU9NVl/ST3UmBTEocPKK0jP0jJWKD/AZPYgsLU7ldEKJzS7sgUVqi3VQrW0 WcYjkQSirRYTV8TE+2IiJH5FWiw5pQIpX1ooOSRFypYyJZs0X8qQ0iVJSpN4iUr4ml4+irdiO bavYfs1Nh70LC5AA3VVENDHHieBVqd+s86dhPRNjbrgrgI9M0ACwSr9/sIAvkdq9TWFAV2sCT cMAjwf0ukezCPYgOtm4948PXNdQ4oALO99Lo/1M73PhULQ5SBK4ZcPBztBoGbnMO5/ARELA3V oJkzTsUj/YaCuQX97UUhfzYyZRaGAvq3OuaUhha+ni35fCi6xLtSQ4lww4a9lfs7lCyHtsEkj 7XAJaSTGOqRhfdTOaKSd/zOj4e7P8sI4HXktrEOe2EfCJi8s9pk8oZTxBsfb/b7B9naTs7SWj Juc8aW1X+DgTYlzfYPhsMlasgeCZmLBJXuQRQL6/aZSdzdyot0mB54l3aZSNzxrJv/Q55TGOc qNO5QbJiXyOaV+lkKP/JtCjyAFOnF1f6lrMKpd1f69PsyPu8xGLebIiLVX+zvc/ojvf9Nawv8 PbZiM46rnmOQul3n2gP+K3P1oq4Kh5gv7d/nbUNftb8MW0fd+u8Oh97Q6nYP7LzDAqXP3RFof 72B9S5t+wd3m0/e7fc7B5l13gXcxuNntGyS7/MGGwV1am89o1pr97hZfaKhpe+u+/4jVdydW6 /a7iG1nYq0sVtO+u8D7GNzEYu1jsfaxWE1akxkL/E+yx62mYVAiVaF1W2b7IWpJx6cnkucKVS m2zgfNR2mtyxHLG+YJHCGWwpCe4a7S52Fj0MrKlZUMws8lBs1Ht3UOcsTWuvKG4cgcZEO3HR/ luUuA1Ye/Iwm/93fo2t6I7nT79DTmuDLnWIwOwhx/nHUk4Q9uH2nuau4yjy8ZO3Zgi3ZFozhs xtMXW2Ghae1AvAu6dnQxKg6irIt2MWPHnT+sQO8lBAaxOOSwltowKPBJ8BgkTRwBD4IAHx/jO JKeJiSh+D2Oo+tlkWcmkIelR7/hKHzEdr1iw+2KR2w3KzbYblcQbwWeb7NTsafE7rIvcdld90 Lv9NuwbPq8QP5ByvgDGJCUwW64RQ9g1DVaBgf0LKGAnxHAJaFMswqdpIckyAGik0n8uU9BGeF tnzXhv728nBRNlZcXe7JQvQzeR53c6cuouBNlI5CLiis0BRW3kHQKXMJJPEQjNSSChW0KHkCd m004n3hNkRJ7iX3n5VmFmemZy/CxcBYVSrVcDtf+KuWyKeUoAIefum/Sbwnc91EkA0VuTNmuT +FqvRW7hVWFu5/+VbFHhBKgsOIn02dzhT/dwg8vSh6aucwFhTFiIQvIes2VuTVtXsZWIuSME+ 4x7jtc/1wJJxZxcW6S47gkzdbmW8cjcqfcIydkXRbkFM3CUglzvt20HQNOeaeKPbA6026j7sX UbstcsDjNblNKVt9nt90DHw6cP/9T1nybNvn8NTXC2PTQdGS6ZXoI1sNBeA02XDk6rU/rQ0dh I9QcxV3rxTRfxAxl0njMK2wUKF7oQ5qd/0SjQNMkWQCSQUEmrAxZ2AN4WATCX+OpjXfyGl/DJ /hJPo1P0RySjllur7CXFzXh9a8w98bbdH2qqdjjctvTxLIHYU0JffGz774V+WjZMO9+wTez9O T32L2wAm++Wswhn3Roq3dngZjVYX/KzsliFkjWN+Z/krE1UyD5t4BmCPlaPtXzIZ/KfTk5RMM qjEKSZmlywfw+60v/IrtsYKM4rjg+b2Z39uN2fbvrs+8IcPjA2FDgAH/GcOANAdyGL4cPU4wP DggQTBR8Rklbtw5OBCIGARYJJa2agICkitqAGwK9mDSYiqAileI6TVsaFVvEoDTFwUGOEz5u6 ds7Q1Fr3e6M5s7aef/5vf97uwD3/D6dQIYbA/H+XtxOJGL0moXROG4mGSlP9vegdiuiK6JRME MlVmlJaUlxUd6okVL+dCgsyM7yZYCEH7bw7t/1be2vjSqqmv0z7WrWxV//rn3yuh9smmqB6Nx 5FTyX3pm2rDq2+uqw7s6BA9Vv/2pbY2UexlGOp70C4xhLOu1ZfBiIw0DBS9ZCeq2hAlHrVFqp Nqndap8qqKpPIIcQshjUQRP0gQBXhNp8PXDI69/jx9bZD7I/AU/Y+b7aoWIoaOqalkvM5spgS /BgsDXYHuwIdgelYFDqtHMrc2muK4N/nOEH/4VAwMCDao6RdBoJxIXoOy5E9Y1lEwO99ThN/g Rn8V7TKptYiDeC6rjK9OAYjfe4y9F4fW9Z4eRJxF2PZ5YGUaNBvUqzB5XjD6TjUhCyfAhlXnm XEnusYvWKx8dPG7KsqPCJKVOWyJ+E2vceObN06dotN95841PYFnr62Zc2b2zIukoLCpbPrVqz avz5k1/sjv18ytDEjvPOrcuYOyOQii2opkp0ss/2a7qgY1bLROO6JKoeXSKapusJmGN7meBjT GBUEyT9tkwTcMz2EEEkGtOpoJFTWCtV7LqSJ0SxRQW1DR4nEg3bykXaRSkZhCYDoYli8BHjS3 SvMtdoysvR3ZKItFnmZrnQaJz1er1glhHUB7E2Q8WADpI1ymQmUI+D7yq/37evy7kO+QPs8N0 V3ziXaBC+djwu5XOQjs3iW2Q4+dDOJyax1ljsUb3QLLJmWi/r2612s93qMDusbrPb6jP7rAzT shJQaSt6hk/XM/RDWgIetU21NuaDSfhytMXX7uvwib4E/MI2DPO2NwN5chkaqhveBBSckDrLA xBI0AnHR5j7rTb4JcmAPbap74fmFjRWmsaDpeAIIhHR3v6eZI/h4BhxcehxkwZTOtnfvz0jPE 7E6DF9/oeE/ExUQSopLPBnp09/zjXlqUjFurXz1yw49Txd5cwfPb9y95rGT84d/Bv8aHjs2V1 7d2zdGKJ3nFu3Jtbt+eKM88GfXaf8LqqzEU/bT0aRnfaYIXQDpVdMqPBVGUt8LFTbrnQoVFGG MnJoC4AXQMFLhgQE7BGsNkscWuvVecCCZrI/2GxrlVpMq9OatBaNa25i6KMDnTGrzmqyWizBc iPOddPBvfp7U/j3DibAIPuuy0ZJNA5SinIXcisVoOu5CDz4su9rwNniLmPznDX6uFp7V+flI+ /1DpzZ9lvHWD/DXlIzc0aNsCh45Mit6dOdW//43PkWlsIueAVWn7j72c5XGna2bH0Bj2DWvWu sBqMPkFwsV4ft5VytUqvynvPs8+zL41uFrTLdnr8/n+aTUlJBmEaG1ZIwKOG6cFP4YLg1LFbi hIbDmWNHwshaLp4bA2NqeSZk6pp3HBmdPeKCsn9cs+2t9FKvK4dZMKSZ7R/dHMuuy27KbskWs l1JJqfleCBKSpd4b7y8N562g6RbMiGa0iUMxUUlD2V+BuDh41Lmw8I8NIeMJVVn32pNLJu3ft 3adzcd/ezplienly98cpq9MOup2bNXrqqYvYr5x7+28Z0Ln76+8fWxBSe2vtzx7Fd/3PohzKu qqalaVBNNTnm+qaFhQ8OPkZdiVOz7g7z80A4tM6p9NFS7SYGLStd9UOoA0F8Vch8UE0HRERSR Bzptq9KilqtF5ug0NHu0Y9pFrUu7oYma6we5/1Xj//GIp/jILHXjK3VDp8VFiEW6LOdBKuKsV PRzu4z6easzxj0zo/njy4dPXh84+/Jv4KunkY3ozMeisCh4+PCtadOBX/ocVOdtZ7PzjPPGcZ az49WG3buRDUrwTzgptmF3ppLP7NhUMlWk03iBVC5PUpfzxdJfpX/xa5Jynp+TLnE2ludJVMa ORVGZICiSArCBSNiMSFwRhA0i94kiVyTKqm1ZVT2ojSCIMpeora3UWjUmtVGdcKrZPiUHeuwY gSKyGG2infRhA5WgHtsbU6BIWYwNSrvShw0Krp3IEXpE0WNgtX1kCPYp+HkkgFMjGRiIphoB/ MrtDCKPJCNW2WDHtD0ccAfJiES2G2ddb4m7aI0FFsK3y1CmB4STzrcbnJw1jgN/ARj55mGY5x wX2+7uoDnJbtdTN+NtLWrDyFy7GH2cEXmBuElsFRll64EQg9xv/9w6KKcXXN8T3fVK1/xgb6o ljNej2aX3mu4KN98U227Pxmc0ov7v4zM8pNueJvI8XsGruDCKl/BZHHsUDnKMNTG6kP+UnWKn +GnltMo5lxRVkVURy5LqUUXORUWWE7DczpO4T5I4c89CxbNQVZV6REHAzUuy7CGyyhTmwRb7x rviPvyPG+/ZEyWQErTYNkkO9ayHwZ0buDV385oxUB/FvbtqR1F1zFw/8oqdTyR1c3G9X7xwRM nlxrNMNiJyZLt7R90xnV20IerGDSEFQiCZjTfh31DhTIV/OuecEx+Jbcnn6M7kR3dfpK1fO7P w4S9ifb4oHkUqxtsqSl9NZEMEMUFLbJWtf1hf7ubQl3E3idLahrJevElrxKN3vvcNGVS4FBVW yJ/sF1rYAfkgOya3stNyH7snyz42VM5hE+VJrFy22QK5kq2Um9ieBz9qZxflDtYld7MbcrbBR sgU6ZYYpRtkySfLksxIWl8uSQrBb2WBdYg2j/E9/BgXJvI6foCf5l38Hh5bgpq2j8hKxyA87O E40g2u+3KTGlIdwgOdrbL7XIPl2iSpj7t6AoY7CszG63D9Sr8zDOGdwD6+PZt9cHcm5nYDRp6 Jkevo/JvssF/8g0W9Gtbvao+mkUBGNW77P2xXDWwT5xn+3u/Od747n33nnGMS4vNPSgKDETch hEDV3EgDhEFjjbSGhICjZXShVLHdDZYQaFoKNCBEWtYU1vA3StROoGaIQqDS1jHU/WogQFC6M NDUkk1aSiq1VSsas/c7J4VOk3w/Ptvy+/O8z/O8KnHG8sHYXCUeEt8T74i8JkbFmMghJiZbXu JWv4EEC5nakeaNg0IbSzWNZFHNBq8Ez5wD542RF7ah1J9l7umQR8tKH0VGnwmFHbDtw+qnd/7 s5NDBbdubH7VW7XWc9UX+8fbBa/Gxa/y5TKLoh4tqWyL4TxsxehxH4iNhctAK9XIoypO0WqVB 2afty7utiZKkgbPFCaqkuDWNwX+GohqKouZLIOU2lBhADDAMEm4A6iZO97shFVS1cPJm1hSKz ci3PCTsmwBTaBzyEdupsTaMYE4pew2z75CpmyasCnaBzGTYzhp+li1LlomVPyfMzaSYNGSTLi oumg4b4d75N9cd3fv4muWvZG4OrH5sSX3pyaMNc+ZEI0d+4zhb9/uXjl2aPGfrscw/oep4PDz Wxz0eWF674AlNwUrU3PsXh2XC+gfIU9b8FvEnIt0nQ7vcLXTLXD1Xr7ZwrUKr3KK2C+LkuCJ6 2PjKvrhDmUTB426E/Vod0hIlJ/TmNic4z8CntifDre+RkXGojdgblS08jCfDheW28GT9iB+hZ tz3ZQK391p5z5JXrl95vfa58uGxfQ83Vi5JPlMfS/Y1NEAhuEED3+LFVPs62bNr4RtHTx8+wF zYbMyjhX+U5BITiLXQE4Id7l7aK3CttJ12023CVtmxQVgvd7j3CvxTwhp5rZvr8neZ1I/Rmpa ZNLtwLRFiZgJvb5mjpkMzwRyEfCuke7x13t1ers0LQS94vb78O3APt7fn3yMwgMUYpLlWbcyX 8J32cV4f+OK80pYPgXzIj7tE01tCqgjdRW4QauKXm+Fwib/KT/3NUT2mJ/Sk3qX36AP6qO4ku qVTfZBWvOP9ppJBu5JsFD4bwbHUy7CY6SZ2fI6C3sQoMs1Gmp0QMilWYLQ4flbf4iJdq7D9rS 6GWYFzcEYiouCn6Y9nntv5u9bOTWvffHdtB4z9lj6ztK2Ua6mpLS0D+EHJodef78VCy4e27zi Q+Wto8w442bnpe/PXY53bkfYStm6JpOHXwA3SqdYswSGIvNwmDUiUE6hIHCgJjRDlLT7Gd/E9 vCPER/kEn+R5dsOe8vwZyEHaHZcv5B1MpTI771/87eFoDpIPh0f78PAwfwr4zNd3F/NFdz/EC qaQvXuZqkGJddwhCQK05wqAl7nTxOnOaVKlOM/ZK/QL7wu3nVKR0CK0888KW1HGkGGloJzg2q Q2Wahk72ghP10q4+dJV4TbwmeC6JQSXBIlsYc7xI1yIuHgf+XQKQpCUnIaEpNFlMLkg1IoUCC 2FMo3Vciq4cf3UFh2Og9YQVsKK6xJTAobbY6mowQmRB4XXayHa6IeTBLTTBJTTBNTE2Rd9W1N dDJNdExoomifs/SdRuZAT7LKlsfq5ScSAkBqxYRIFnKinhoGFQoyV6Hqy6G1yO1fwPpM59gqu NGdOcaU7X6fLWsa5sURmbkTSjlsrB2yLTDMkfDfTuL/epL24XFPsgG797I9py9Y1hSj3KB5Rr vRbewz3jLOGMJXBni84JKFuNetCl7R41Fc0FhCAFmnhNSR1WQ3eZtcIDfJHTRFg9Rt5SqNUVy aaNAVddEQntgKxbtYJH47EiQiPLHCkSq0c8hFeqXNrikkIp3pRsQNPr1QL/OxXQmplnt5OH/h d+euKhq+Wrk7/qOd5dQ8sm7u9188nQnyRchCrUf7cBKqkXHex0xUkkdarYp+5ykn/YPjmoMqg KB0cv4OXu9QeFFRLk4Go3mRuFxMiEmxRxwQL4qjopPghSImNEt1Nydtm8e12TrxKcnHyNP23G Pvq7QRbSQ73KQpZ5Z3dnahEwoj5MGVpbrzj5sujW76S/u5e+Q/m1fEOzcvj2+ikT4gXZnTQ29 kvtwKU4E7fLT/lwf6+zH+dGYddx7j10gB2WaVvybAeuTH7QInCo1co/o0twZZciMnAhHy4w7R 6FAUj+bWqRv8zXXOHzuTTs45SOdYhZrb06jBfkKiGoS0qGZpMY3PXhJaUuvRBI11I8CUPYUN0 LICyAbe1j8mD1lpyMm2YHwXKdYLH8wvfW1Gz7JXr33was2G+cMf/XRZ3bq2WH0SG1KfyHyUuZ v5JHOjevnYv7kzJ3+1/8Rbh/czFLehNByxc9xomYhPB405Eo6kg7vpRZwFvVSWMD8ZWcs1CCu sGaIoS0QCp5pdxZD1EXiNANz+GO2h9BaFEI1Si8YoT1lOehZhmM8jyM0lbNrKxuVOLytlSaXQ ooYnsOUXi2ywwZPDVyvilXWLFlWWRWtDfNFra2vKP5+58OxXGPNUxNWTGHMxfGL9WSCKy6Ful 7d5txZ0P3Sx4ErgsnkpeDl0OawulpcqS11L1erAArM6OD9UE5YU1VFcbtaqCwKP4aMafLSw+C XlxcAWsyu4JbQl/IHCfn/R/n3uFE+lUh6qMZ8w02Y6eNR8x/yTcl1RCuQCpcBVoBqBHFML5oR ywivllcpK10q1PrDMjAWXhZaFvb+Q+5Q+V5/688Aesye4J7QnPCQPKUOuIfX+H3j350J3Hszz gCwFgsFB6rGOS4ohScrfJVCUboW6JEMqlNZKu6R+6aQ0JA0p0nekWmmFxElKMMCD4fch74AXQ sC9ACfhPHDn4BIqL3A+H7faD/64HuOAi09RdNEzDZSAFOQjbtXX6aMlvipfm+85H++7YFB4Fm gIopCAJPDQTAwjIlwl0Ev6ySlmPt1TheZI/gUSgWgkEUlGeiIDEUeEsYurzX3LTa+7oc4Nbja ZUxHFTI5TOJOdjFQmNaWyVw0fskP32oxdNdKE73BzxBdixMsEDj9pSqXSzOi5kcA1G/apNEnj YKRSORVZsBcXFT9UXFQ+a/Z/2a+6mDiqKHzuzN07dxa6y7KzM1BaWAJiA8JCN5QfsexCf6gt7 JYC1hJEDFWhRAqmYkwMvLS0QQNJeTIFrFLQ1LQRJdlUbbAhxviChsQoLzRKxAeVpEFf6u567j g1WqNUH/rE+TJzz/2Zn/vN3Hu+I8SR+GOYRzN0ARSBuC52rKZfOFKf7C6NrdQ++eF7l2eyv94 +2FiTmfnOx3v3LF57+0viy5sO+LM0zXlwT+Po6Mzp0aKBogezjJTCXbW1A699Oo1/WWr8e2mr bQzV+6uBgg7Hiw4p11HueNRxzEFTNDBkjwa6K9lNdJfkJoZsT1QVXTOUlxITjAiZDeThPu0ed kvuCGhMtQ+RYZjAPeWMITfrLs39Cbi8rkLUM2GXzSUWCsr6lnWMYdGKX1sq1nfiuo/iVrBSKX YBDA9+J5q5BxBPlgtn699ZYoi5Ig+urGJ/cYlLUsYUR563QgsfP9qZ7OjsXKU5N2MNQ/qOtKX chlD5DFm4uTgZO4dzex5X0BDNwRgzEHgkl5Wzz9gSo6cYWVdIkkII1cHuRJXm0TS7ipHR3ezT SZJOfHpIb9WH9av6gr6sr+lcvxNgeJhLGbyQS148BbBG+V0BJirCixml7wSYHjPCmEq3gBTjJ E2Ru9t0pdnCC41NZ6tXPTX+8qcyvptoajs2NS69Hkv5omf34f6vyBxKHZyJakbLHOAkJ/AAA5 WXQzE/A4PSWXaOT8I0eUu5zBNVSlQ8OAU3j8R/DJTZbJg3MkwkqSxcRjlF2aJwTcGwQyXppMh eUKswVCyMg73SPmKXnHbCI8Qb8CnjqpORshBrZd2sH9PLNUwwlUoWYgtYoV5WyAIszIYwB51j CouQsUC+6qR4BW2l3bSfLtM1GqdKJQ3RBaz8IfqG6FU6RxWKV8xI4/ABqh9C+kFN+mUlmiqYx O3TKlKiKz2/6wek1MpOB4XceXkexAIbdKD+wWN+npSWmtmSyJVISybxu40SN6rYZ2MXb036iq Z+iE3RnOg3s7NSuuBU2MMboB1OwxWIkyC5JB2S3per5RvyDdpMP/8rbE/chRHbCNvGgojr7Lq yHfHGxuCMX7Nwm99Wr6hL6hJ+kIkEF+JE4viWxC09jrRNbGITm7h/wH1SwggkTBMqDMPRVjwY bGjynytJKCI0j26kpELaNqst2yofggIfFIEfiv92j/01eDoEdSE4XH8EGpseO/r4xg++X0YxV QNIx6xCBgd4YReUQRAOiPeFMNTDceiALjgJL8TjOM4L+VBq9h+0+tux/wQ8B73xePzbf4bF/r +ZvOEIDk9b95HBALB8ir5h+Qy9AvGFqYot2bDX8iWcW4flyziiz/Ip+pcsn6G/WL2vJlgVzgv 2drR11bX19nb35Vd1d7X/t2aohn1QgzRVIUV5WPbiw9uQxjo8o0LGVK7PpPYZOIWtou1ersjH 3m5su7f7/9/RgknpPNyCCmgAGzKXBD4IIM2N5Cdz7QimJYDFYPRiq7PiZ8jgJvVvZkQ+EuW7I w3R2Gr0FSXOl7GaIMYK+20AVRU8iQplbmRzdHJlYW0NZW5kb2JqDTMwIDAgb2JqDTw8IC9OID MgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9MZW5ndGggMjU3NSAvRmlsdGVyIC9GbGF0ZURlY29 kZSA+PiANc3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuAsAaQNWxhkR0EUQhJCAESQkjY BUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbXjp0XOEedTmem0+8f7/c593fv7 93fvfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJAAMKIAIRADJ5rS4tOyEH4JLGS7Ba3An8i5 5eB5BpvSJMysAw8P+JLdfpDQBAGTgHKJS1cpw7ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3 nfOY52sQKjVaBsylnnUKjMPFpnFfXGZU4I6k4d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtB KS/H2Q9nuj4nS4LzAgDIdNU7XPoOG5QNBtOlJNW6Rr1aVW7A3OUemCg0VIwlKeurlAaDMEMmr 5TpFZikWqOTaRsBmL/znDim2mJ4kYNFocHBQn8f0TuF+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQ qAeBavzfq3ttItAIyvBMDy5luby/sAMPG+Hb74zn34pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6 /QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo26rFanUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0yt VeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4Y68Br9gHsC7yAPK3CwDl0gBStA3fgd70LZWSBzLwN d/h3vzczwn691PhPtOjVq2ai5Nk5WByo75ufs/0WQICoAIm4AErYA+cgTsQAn8QAsJBNIgHyS Ad5IACsBTIQTnQAD2oBy2gHXSBHrAebALDYDsYA7vBfnAQjIOPwQnwR3AefAmugVtgEkyDh2A GPAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqHUqEsqAAqgVSQFjJCLdAKqAfqh4ahHdBu6PfQUegE dA66BH0FTUEPoO+glzAC02EebAe7wb6wGI6BU+AceAmsgmvgJrgTXgcPwaPwPvgwfAI+D1+DJ +GH8CwCEBrCRxwRISJGJEg6UoiUIXqkFelGBpFRZD9yDDmLXEEmkUfIC5SIclEMFaLhaBKai8 rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbgRQgjSAmLCCpCPaGLMEjYSfiIcIZwjTBNeEokEvl EATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZEolkRfIiRZDSSTKSgdRF2kLaR/qMdJk0TXpOppEd yP7kBHIhWUvuIA+S95A/JV8m3yO/orAorpQwSjpFQWmk9FHGKMcoFynTlFdUNlVAjaDmUCuo7 dQh6n7qGept6hMajeZEC6Vl0tS05bQh2u9on9OmaC/oHLonXUIvohvp6+gf0o/Tv6I/YTAYbo xoRiHDwFjH2M04xfia8dyMa+ZjJjVTmLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXmIxaF5ca SsGSsVtYI6yjrBmuWzWWL2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n5wPOKc5dLsJ15kq4cu4K7hj3 DHeaR+QJeFJeBa+H91veBG/GnGMeaJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86/6WFnUWMhdJij cV+i8sWzyxtLKMtlZbdlgcsr1m+tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdN sctLlpC9t62mbZNtt+YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6 KmWMxWBU2hJ3GZhxtHZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLikubS47HW5 6UpxFbuWu252Pev6zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9vvSEP YM8yz1HPC96wV7BXmqvrV6XvAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9 b3tV+QX5XfmN8tEUeULOoQHRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4 G/SM4JFgfvD/4QYhLSEnIeyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79A sEC5YGzB3QinCFnEjojJSCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+ 0wSJlkmOR6HxCXGdcdNxHPic+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5 KXJZ9OoadkpwynfJPqmapPPZYGpyWnbUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9 ZoqyWrLPZ3Ozi7D3ZT3Nic/pybuW65xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4Wk wrzCnYWzi+MXb1o8XRRU1FV0fYlgScOSc0utl1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWv lc6I5fIN8sfKqIVA4oHyghlv/JeWURZf9l9VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDy t/rMqvOqAha0o0R7UcbaX2dLV9dUP1JZ2Xrks3WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpX GqbrIupG65/V59Yca2A3ahguNno1rGu81JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2z bXp54vJd7dT2yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2r Hndrej+osevZ7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa9dc3RG3Y1c/ub+q/uzFt4+EBbK B74PtNxZvODQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkC erp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28 Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1M RRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG +0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v 4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7 rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/b r+S/7c/23//wIMAPeE8/sKZW5kc3RyZWFtDWVuZG9iag0zMSAwIG9iag08PCAvVHlwZSAvWE9 iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDExOSAvSGVpZ2h0IDEyMCAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMCAwIFIgL0xlbmd0aCAyODc1IC9GaWx0ZXIgL0RDV ERlY29kZSA+PiANc3RyZWFtDQr/2P/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCw oLERUPDAwPFRgTExUTExgXEhQUFBQSFxcbHB4cGxckJCcnJCQ1MzMzNTs7Ozs7Ozs7OzsBDQs LDQ4NEA4OEBQODw4UFBARERAUHRQUFRQUHSUaFxcXFxolICMeHh4jICgoJSUoKDIyMDIyOzs7 Ozs7Ozs7O//AABEIAHgAdwMBIgACEQEDEQH/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGB wgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQ MEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q 2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3 EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTF WNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdo aWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVEkkklLJ0xKp5vVMXCbNrpf+awauK IBOwSATsG6q+Rn4eN/PWtZ5E6rls3rudkkhjvRqP5rOY/rLP5JJmTyTqVPHlj+kaZ48sf0jT1 T/rL05phu9/mG/3wo/8AOjB/0dn3D+9cukpPu8PH7WT7vDx+16yv6ydNeYcXV+bmmPwlXcfNx ckTRY2z4HVcMnaS0hzSWuHDhoR8wmy5aPQ/atly0eh+19ACS5LD6/mY5AuPr1DmdH/I910eHn 42bXvpfJ/Ob+cPiFBPFKG4YJ4pQ3bSSQ4STFikkkklKKZJU+qdQbgYzrTq8+2tvi5EAkgBIBJ oNfq/WG4TPTqh17hoOzR4lctbbZdY6y1xe9x1cU1ttl1jrbCXPeZcT4qKu48QgPFu48YgPFSS SSkXqSSSSUpJJJJSkSi+7HtFtDiywd+3wKGkgQCKKiARRew6V1WvPr19l7R72fxHktALhMfIt xbm30mHt/Ed12eBmV5mMy9n5w1HgfBU82LgNj5S082LgNj5S2UkklExLHhcf1vNOVmOa0/oqf Y3wJ/OK6jqGQMfDtuP5rTHxXEeZ1J1PxVjlo6mXZsctHUyWSSSVpsqSTpklKSSSSUpJJJJSkk kklKWt9Xs40Zf2Z5/R38T2cP71kp2WGqxtrPpMIcPkU2ceKJieyJx4okHs+gdkkAZLDh/afzf TNnyAlJZ9dHPrWnP+sthZ08NHNj2tPw5/guWK1vr/wBSd0/p+Na1gs33bYJj81xXDj61X8jEb HjuKu4IkYxLoSW9y2ORxiQrcvQqp1HqNODU0lpuyLjtxsdmr7HnhoCx3/W3JaWsZhiy61wbVU 1xLnOPYALt/qn9U7cW49a61tt6vcPYwasx2H8xnn4lDLlEdBqUZ8nt+n9I/g5eJ9Svrdk0MyM nq7MK633vxmUteK5/N3HmEX/mF9Zv/L8f+w7V3miWire5Lu1fcn3Lwf8AzB+s3/zwD/2Hal/z B+s3/wA8A/8AYdq7xJDjl+8Ve5PuXg/+YX1m/wDngH/sO1L/AJhfWb/54B/7DtXdwlCXuS/eK vcl+8XhP+YP1m/+eAf+w7f70v8AmF9Zv/ngH/sO3+9d3I8UO66uit1tjg1jBJcUROe1lXHPaz q8Jd9SfrDRWbLvrEGMbyTjthZPRbsx2T1HEy8n7WMS4V1W7QyRt52hdJ1TqtmfYQfbjsMtb2g fnOXC4/X2Y3UupPoYMirIv3NsmAdohWcWOfFGzcj0bOLHImIJJkeng+p4NnqfVuwzJbTa37g5 JZfQeqOv+pmbnGvaamZLgyeQ1hKSh4T7/D146/Fh4T7/AA9eOvxV/jLxzb9XfUAk0XMf9/s/7 8vMK7Qymxx1NY3AfJe2dfwB1Ho+Xhnm2pwafB0e38V4Vkl9ePbpDg0tcPPgqxgPFy04jeB4g2 eXkTy2SI+aHqD0v1M6r9W+lR1XqTbsnqlgJrhgNdLT+bXLuT4r0zoXX8PruO/IxGWNrrdsJsA EnygleF41+OKKwXtBjUErvfqn1Lot31Vyel5PV2dKustMXNuZVaBIdLS8jnhNzYcUcQnGXFM1 eqzPhxRxCcZcUzV+p9LSXD9Rf9Xs0ZPp/W8Y5yWUsGzLrhno8ub7uX/nKr0/G6Dh0ZtT/rp9o OZT6LX2ZVZNRkHez9J9LSFUaj6EkvN8Tp3Qsc27/rw+wWVurE5dftLh9Ie86hSz8HomXluyK/ rw6hrg0CtuXXA2tDe1g5iUEPoqp9U6jR0zBtzr2udVSJeGAF0fMheffsfpH/z/ANn/ALFs/wD Sqv5fUehdP+p+b00deq6te5r9j7L2PtO8/R0c46J0ADIA7WF0ADIA7WG//wCOb9Xv3Mj/ADB/ 5JQ6l1h3UiHNlmKAHNadNInc5eW+vR/pGfMrT6t15+fWzAwXFmKxjRkXDRzyBG0eSvnl8UCPb 9cie9t+WDDAj2/XI+NpOvdednufhYLyMNpi69uhsI/Nb/JWWxjK2bWCAOAEmtZW0MbAaBoAiU UWZN1ePX9O57a2x4uMK1ixe2DI0ZVqW3ixDHHiOs61L6Z0Wg0f4tryebcPKtPwc2wj8El0jel 0t6N+ygP0P2c48fySzYksj3P13uf1+P8AG3I9z9d7n9fj/G26RovIfr10Q9M6y+xrf1bNJtZ4 Bx/nG/xXr5WP9Zug09c6a7Ffpc330WfuvAT+Vze1ks/LLSS7ls3t5LPyy0k+JelTxtb9yf0aZ +i37gj5eNfiZFmNkMLLanbXNPiEJbAjA6gAjydgRgRYjE/Rj6NH7jfuCXo0fuN+4KSSXBH92P 8Aip4Ifux/xWPo0fuN+4JejR+437gpJJcEf3Y/4quCH7sf8Vh6NX7rf80JejT+637gpJJcEP3 R9iPbh+7H7FjVVH0W/cFNoa0QBA8AITJSiIxBsAD6JEYg2AB9FudV2H+Lvojs7qZ6laP1bC+h PDrXD/voXM9N6fk9Sy6sLFbuttOh7NHdx+C9o6H0ijo/TqsGj6NY9zu7nHVzvmVV53NwQ4AfV P8AJq87n4IcAPqn+TopJJLJclSYhOkil5f63fU+rrVX2nGivqFQ9j+zx+49eV5WLkYt78bJrd TfWYcxwgr3shZPXfq10zrdUZdcWgRXe3SxvzVrlucOP0z1h+Tb5bnDj9M9Yfk+KJaLpOs/UPr fTS59LPttA1Dqh7gP5TP7lzjwWOLHgtc3QtcII+R1WnDJCYuJBdOGWExcZAsUk8JKRepIJQpV 12WvFdTTY92jWNBcT8ghYGqjpqWMdwrWB0/M6lktxMOs23O/NHAHi49gug6L/i+6xnltmYPsO PoXb/50j+S3t816N0foHTujUejg1Bk/TsOr3H+U5VM/OwgCIeqX4NTPzsIAiHql+DR+q31Vxu g4+7S3MsA9a7/vrfALfExqnASWXOcpy4pGyXKnOU5GUjZKkkkk1apJfKySSn6pSXyskkp+qIV DP6F0nqA/XMSu4/vOaN338r5mSTo8d+i7/qro8d+i7/qvv13+Lb6u2uLmttpn81lhj/pbkD/x r+hf6fJ/zm/+QXhCSsj75WnG2R98rTiff8f/ABcfV2l0vZZd5WPMf9GFuYPRul9PG3Dxa6PNr QCfnyvmRJR5ff8A0+L6seT7x+nxP1SkvlZJQMD9UpL5WSSU/VKS+VkklP8A/9kKZW5kc3RyZW FtDWVuZG9iag0zMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1d pZHRoIDE1MCAvSGVpZ2h0IDE1MCAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAx MCAwIFIgL0xlbmd0aCA0MTM3IC9GaWx0ZXIgL0RDVERlY29kZSA+PiANc3RyZWFtDQr/2P/uA A5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgXEhQUFBQSFx cbHB4cGxckJCcnJCQ1MzMzNTs7Ozs7Ozs7OzsBDQsLDQ4NEA4OEBQODw4UFBARERAUHRQUFRQ UHSUaFxcXFxolICMeHh4jICgoJSUoKDIyMDIyOzs7Ozs7Ozs7O//AABEIAJYAlgMBIgACEQED EQH/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAA gMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUs FiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT 0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyEx EgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVN nRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAw EAAhEDEQA/APVUkkklKSSUbLGVML7HBrRySkpkg35ePR/OPAd2aNXfcFnZXVLLJbRNbP3vzj/ cqJJJk6k8kqaOEnWWjDPOBpHX8nRt6w86U1gDxfz9w/vVV+dmP5tI8mw1ATqUY4Dp9rAcsz1+ xRc8mXPc74ucfylRgdhBUkk6h2W2e5U19rPoWPb8Hu/vR6+oZtf+E3gdngH8RBQEkDCJ3ASJy GxLpVdZbxfWW/yme4fMcq9VfVc3fU8Pb4hc8na5zH72OLHj85uh/wBqjlgB+U0yx5g/pC3pEl mYvVtQzKhvhaPo/wBodlpAgiRqCoJRMTRDYjISFg2ukkkglSSSSSlJJKNljK2Gx5hrRJKSmF9 9ePWX2HTsO5PgFi5OVbkv3PMAfRaOAlk5L8mwvdo0aNb4BBVnHj4dTv8Ak1MuUyND5fzUnSSU rEpJJJJSkkkklKSSSSUpJJJJSys4ec/E9rpfj92jUt82+Xkq6ZNlESFFdGRibD0bHssYHsIcx wlrhwQpLE6fmfZrPTef1d51/kOPf4HuttVZxMTRbkJiQsKSSSTVylkdUyt9noNPsZ9Lzd/sWj lXehQ6zuBDfieFgySSTqTrKmwws8R6MOedDhHXfyWTpJKw1VJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSSSliBwdQVq9Jyi+s4zzL6hLCeSzt93Cy09drqLWXt5rMkeLfzh9yZkjxR8RsyYp8MvA 7vRpKO9mz1J9kbt3aOZSVRuOb1e2XMpHb3O+egWcrGdZvy7D2B2j5aICt4xUQPq0spuZ+z7FJ JJidJOg7lPWKJET2HKrftXpY0OZj6f8Kz+9cl13r2T13Jf0XoryzEYdudnDgjuxhQWfVXoTWB pxg4tEFziZPmdUYQnOzECh1l18kTnDHQmTxHpHoPF7P9q9L/7mY/8A26z/AMkl+1el/wDc3H/ 7dZ/5JczT9Qun3Yr8pmAPSrEyS6SO+0Tqqf8AzX6D/wBxG/ef70RiyG6MDWh1WnNjFEiYvUaD +L2X7V6X/wBzcf8A7dZ/5JL9q9L/AO5uP/26z/yS47/mv0H/ALiN+8/3pf8ANfoP/cRv3u/vT vYy/wBX8UfeMP8AX+wfxex/avS/+5uP/wBus/8AJJftXpf/AHNx/wDt1n/klx3/ADX6D/3Eb9 5/vTf81+g/9xG/ef70vYy/1fxV94w/1/sH8Xsv2r0v/ubj/wDbrP8AySX7V6X/ANzcf/t1n/k lx7Pqp0Sx7WMww5zjDQCdSfmrGd9RumYDw3IwWgH6LwSWn5ymnDksC4WdhaRmxkGQE6G5ofxe o/avS/8Aubj/APbrP/JJftXpf/c3H/7dZ/5Jcb/zX6D/ANxG/ef70v8Amv0H/uI37z/enexl/ q/ij7xh/r/YP4vZftXpf/c3H/7dZ/5JEpzMTIJGPfXcW6uFb2vgee0rksD6kdGzbdrcQNY36b 5dAH3on1a6fidN+uPWsLDZ6dFVVQY3nmPFRTEoSETwm+zLAxnEyjxAD94bvd12uf0ayoH3VEV E/wAgub/30wkqbLzWLKe14b97SSkovbF7fp/hTN7hq7/Q/G6Xe4ve5x5cSfxTLJd1a8Pc0MaA CR37FP8Ata/u1v4qz7MhWzUOeFnf7HUJiSdAOSuJ6717K65lP6L0V5ZhsO3OzhwR3YwoXVfrB 1Dr9z+j9LIqxWmMzMbOo7sYVewcLGwMZuNjNDa2/eT4lCGI5D/UG5H6XgF2TKMcR/nDsD+j4n +CsHBxsDGbjYzdtbfvJ8Stz6v09Mtyduaf0mnpMdownz81l6JtFalC4GAJhpQ4ejThkqYnICe tni6vfZ7sSvGLcl5ppPtJbLflI4WN9l+qP+m/6Tv7llO65nPwHYT3BzXQPUP0tv7qoaKti5WU QQZyjr+gd21m5uEiCMcZafpjUeD0n2X6o/6b/pO/uWT1avprL2Dpzt9W33GSfdPmqOiUhTwxG JvjnLwkdGvkzCca9uEfGI1dbpVPQn4xPULNl28wNxHt7cK99l+qP+m/6Tv7lzeiWiEsJJJ9yY voDomOcRiB7WOVdSNXpWUfVRj2vrvLXtMtIe6Z8tFt3MxbsUjIh1BbLjZ4eOq4BljqrG2VmHs Ic0+YV3qPWcvqENtIZWP8G3gnxKhycrOUo1ORA3lI6jyZ8XOQjGd44gnaMRofNr5rcRuS8Ybn Pon2l3Kng4NuZbtboxv039gP70sDBtzbdrPawfTf2A/vXTY+PVj1CqoQ0feT4lS5c3tjhBuVb n9rFhw+5IzI4YXsPyCsfHqx6m1VDa0feT4lch0v/wAXnXv+Lq/guzXBVZb8b69dccwAlzKgZ+ SpgGU49SS3pGMMcjsAP2vVvaTbU7s3dPzCSzP2zfxsZr8UlZ9ifh9rV+8Y+57bNfNr9LMvr/c scPxKq5Fn6vaP5DvyLX+slHo9WtPAtAsHzEH8Quf6i/063+DmO/IjkleGEx2H4oxRrPPGe5r6 PRf4rMbHf9T6HuqY5zrbdzi0En3d1132TF/0LP8ANC5b/FT/AOI3H/423/qlofXPq/WukdJGV 0bE+2ZBsa1zYLtrDy7a3U+CzLPd1eEdg7P2TF/0LP8ANCX2TF/0LP8ANC5brX1l+tWH+xfsnS jac8MOa2CfTcY3V6fR8ZK57rP+MX65YXVcrExul+pRTa5lb/SsMtB0MjQpcR7lXDHsH0r7Ji/ 6Fn+aEvsmL/oWf5oXG/U364fWLrQ6iep4X2b7JR6lH6N7Nzvdp7ueFzf/AI5/15mP2R/4Dalx HuVcMewfVvsmL/oWf5oS+yYv+hZ/mhefs+vH11s6NiZlXSPUyLsp1NrNjxDAG7RtOo3SdUP6y fX/AOt/TOs5GFh9M9Wirbtf6VjuWhx9zdDBKXEe5Vwx7B9F+yYv+hZ/mhL7Ji/6Fn+aF5P/AO Oh9ef/ACo/8BtS/wDHQ+vP/lR/4DalxHuVcMewfV/smL/oWf5oT/ZMX/Qs/wA0LjPqL9cPrH1 3qV2N1XB+yU11b2P9N7JdMRL13KXEe5Vwx7BzcmtldpbW0METDRAQkfM/nj8AsD6y/WXD6Bie pYPVy7fbjYzfpPd/5FTA+kEsBHqIHdX1m+suJ9X8MWWD1su724uM36T3eJ/krkOk4ed9oyerd Tfuz8+DYwaNY0cNUen9PzMnMd1nrLvW6hdqxh+jS3s1oWsrnL4CCMk9/wBGPbzaXM8wCDjhqP 0pd/AeDBzXF7SBo2d3z4SWliYjX9Kzstw/mzUxh893u/6pJS+76q/r8H/Nth9o8N/6v3P+dTt fW/ELqacto1rOx/wdx+K4frbT+zrbG81Dd8uCvU8vGZlY1mPZ9GxpbPgex+S87zMRzTdh3iD7 q7B8dFX5WQyYZYjuLryP9ra5uJx5oZhsavzH9js/4qT/ANhmN522/wDVLr141V9VKKWCunNyq mDhjLCAPkFP/m0P/LDM/wC3SoPuWbsPtZ/v2DufsfYk8rxz/m0P/LDM/wC3Sl/zaH/lhmf9ul L7lm7D7Vff8Hc/Y+xylK8c/wCbQ/8ALDM/7dKX/Nof+WGZ/wBulL7lm7D7Vff8Hc/Y+xylK8c /5tD/AMsMz/t0pf8ANof+WGZ/26UvuWbsPtV9/wAHc/Y+xylK8c/5tD/ywzP+3Sl/zaH/AJYZ n/bpS+5Zuw+1X37B3P2PscpSvHP+bQ/8sMz/ALdKX/Nof+WGZ/26UvuWbsPtV9+wdz9j3f1x+ s2H0Cr1LP02XcNuNit1c93y7LiMDp+Xk5bus9ad63ULdWMP0am9mtHipYX1fxMXK+1vstyr2i GPvdvLf6srUVnBy3DUsmpGw6ebU5jmxIGOOwJfNLqfBSYmOeE6vdFwDn9QrqImpn6S4/yW9v7 R0VmcxCJkdgLauOBnMRG8jTut6XYz6qvx2iL7Geu4dy7cLdv3CElvpLJ96ff9P3P8J2vYh2/Q 9v8AwVLnPrT0ovaOoUiXMEXgfu9nfJdGmcA4FrhIOhB7hNxZDjmJDp+ITlxDJAwPX8C+bJLV6 90V3T7TdSJxbD7T+4T+af4LKWxCcZxEo7FxMmOWORjLQhSSSScsUkkkkpSSSSSlJJJJKUkkkk pSSSRMcpKVqSAASToAOST2C7foPS/2dhgWD9Yuh9x8PBv9lZv1b6GWlvUMpsHnHrI4n88+fgu lWbzefjPBE+kbnuXV5Ll+Ae5IeqWw7BSSSSqN1SSSSSmFtVd1bqrWh7HiHNPBC4/rP1fuwXOv xwbMXk93M/reXmuzTc6FS4c0sRsag7juxZ8EMsaloRtLqHzaUl1vU/qvRkE24ZFFp1LPzD930 VzOXg5mE/Zk1mvwdy0/B3C0sWfHk2NS/dO7k5uWyYjqLj+8NkCSSSmYFJJJIKUkkkipSSaVew OjdQzyDVXtqPNz9G/LufkmylGAuRAHivhjlM1EGR8GkJJAAknQAamSul6J9Wy0tyuoN1GteOe x8X/3LS6X0HD6fFn89kf6Vw4/qDstNUM/NmYMYaR6nqXS5bkhCp5NZdB0CkkklTbqkkkklKSX yqkkp+qkl8qpJKfqpDu9D0nevt9KPdvjbHnOi+WUkgo7P0DmU/VO1xDLzQ/xqD3Mn4bS37llX 4eA3WjPZYOwfXa0/gxy8TSWnh4qFe9/hcNfi5Wfhs37H+DxX/zX2F7Q0wHNePFs/wDfmhRXkC Ssi/H8Goa8PxfY662v+layv+tv/wC+scrtGF0kmcjqIA/drqsP4ub/AAXh6SjnxdPc/wADh/a y4+Dr7f8Ah8f7H6K6Yz6qssDaXtsu7Ov3Az5eoGt+5b4iNOOy+VklmZ/n/T/6pu6vL/J+h/1L Z+qkl8qpKJmfqpJfKqSSn6qSXyqkkp//2QplbmRzdHJlYW0NZW5kb2JqDTMzIDAgb2JqDTw8I C9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTU1IC9IZWlnaHQgMTU1IC 9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEwIDAgUiAvTGVuZ3RoIDM5ODUgL0Z pbHRlciAvRENURGVjb2RlID4+IA1zdHJlYW0NCv/Y/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgI CAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBcSFBQUFBIXFxscHhwbFyQkJyckJDUzMzM1Ozs7O zs7Ozs7OwENCwsNDg0QDg4QFA4PDhQUEBEREBQdFBQVFBQdJRoXFxcXGiUgIx4eHiMgKCglJS goMjIwMjI7Ozs7Ozs7Ozs7/8AAEQgAmwCbAwEiAAIRAQMRAf/EAT8AAAEFAQEBAQEBAAAAAAA AAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcG CAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKyg yZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2 d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fA zJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9VSSSSUpMkkYSUqUx cAJOir35tVRj6TvALPuy7rSQTDfAKLJnhDTcssMMpdKDpWZlFfLgT4BVbepOP8ANtjzKopKtP mZnb0s8cERvqndm5Dvz4HkotyshvDyhJKL3Mn7x+1fwQ/dH2NgZ+UOXz8gpt6leNTBHgqiSIy 5B+kVHHA/oh06+o0u0dLD5qyyxjh7XA/BYcKTLH1mWGCpoc1IfML8mKXLjoadyU8rPp6iDDbR 81ea9rgC0yFahkjPUFglCUdCGaSaUk5YukkkkpSYpJklBRMCToqGXnRLKjPiR/BPnZW0ekwy4 /S8ln91V5jPXoj9S2MOK/VIeQUTJk6k90kklUbKkkkklKSSSSUpJJJJSkkkklKRsfJfS7mW/n BBSRiTE2N0SiJCiHbqtZa0OaZCIFi415psBn2dwthj2vaHNMg8K/hyiY8erTyYzA+B2ZBOmTq VYtKBlXCqoun3H6IRiRqsjMv9W0gH2t0aos+Tgh4nRfihxSrp1QucXEkmSTqUySSz99S3QKUk kkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUreDkbHitx9ruFUS4g9xwnQmYSEh0WzjxAh3k6r4d /q1fym6FWFo8Y4OLpu0uE8XD1Q5T9lD3d4WMtLqVkViscu1PwWaqfNSuYHYNnlxUSe5UkkkoG ZSSSp29a6PS91dudj12NMOY61gIPgQSkLOwUSBu3ElQ/b/AEL/AMscX/t5n/kkv2/0L/yxxf8 At5n/AJJHhl2KLHcN9JUf2/0L/wAscX/t5n/kkv2/0L/yxxf+3mf+SS4Zdiqx3DeSVH9v9C/8 scX/ALeZ/wCSS/b/AEL/AMscX/t5n/kkuGXYqsdw3klR/b/Qv/LHF/7eZ/5JL9v9C/8ALHF/7 eZ/5JLhl2KrHcN5JUf2/wBC/wDLHF/7eZ/5JL9v9C/8scX/ALeZ/wCSS4ZdiriHcN5JUP290P 8A8scX/t6v/wAknZ1zor3BjM/Gc5xhrRcwkk+HuS4T2KrHd2OnWbb9vZ3bzWosXHea72O8DqC tnePwn5KeMr5eY7EfmxGNZonu5vUnzc0T9EKoh9T6jXXm2VuY6Wx4eCqftjH42On4hVc/NYfd mDMAg+LPhwz9uJEejfSVD9sUD8x33hYfWfrVlZFw6L9XqXX9Uv0c4QW1N4Lndh80sOSGaXDjP EVZInHHikKS/WL6xZRyR0HoDPtPVrva8t1FI7lx7FaXSv8AFd9W6cNjeq0ftDOd7r8h73glx1 MbHN0C0fqh9U8f6v4cvPr9SyBuy8p2pc46kAnsuhAWpjxiAob9S0Z5DM2fseZ/8bT6kf8AlW3 /ALct/wDSiX/jafUj/wAq2/8Ablv/AKUXTp09jeX/APG0+pH/AJVt/wC3Lf8A0ol/42n1I/8A Ktv/AG5b/wClF1CSSnl//G0+pH/lW3/ty3/0ol/42n1I/wDKtv8A25b/AOlF1CSSnl//ABtPq R/5Vt/7ct/9KJf+Np9SP/Ktv/blv/pRdQmSU8x/42n1I/8AKtv/AG5b/wClEv8AxtPqR/5Vt/ 7ct/8ASi6clMSAJOgHJSS8wf8AFr9RwCT0xoA5/SW/+lFyX11+rX1b6S3pt/ScNuPac+lj7A9 7pbqY97neC9BzMw2TXXowfSPiuK/xgODcLpnl1Cp0eQDlXOa5iEdupZoYaHEfoHq3Eh5PcHla fqHw/wABuXPP6tVud+jdOsahbP2n+Sf6H6nyVLHzGMwykT+Xhv6ybM8UxPHpqeKvscX6wMLeo vceHgQB5Bc7l3Gq0iYnhdZ9aKwLaLB4EH71xn1hLa6GXTBnbPkQSs/mcf8ATpw/eOn2NnBP+i wPYfk5+X1POy8lvSei1nIz7tHFuorHi48Beh/VD6pYv1dwvcRd1C4bsvJOpc46w3waFwf1Gca MbJyqfbfbYQ+wauIk6arqR1HOOnrO+Oiuw5zl+UkcIxyMhQlIVqWDJy+bmAJmY4eg1e1CdZru o4fTMCi7qWSylrtrN9hgOeRMBGHV+mHMOAMqo5TWeqadw3BkA7vuK14niiD3FucRRI7aN1JZf /Ob6uf+WuH/ANv1/wDkkbI6z0jFFbsnNx6Be3fUbLWMD2/vN3HUIobySy/+cv1e9N7x1LFc2t u55bcx0NmJMO81N31g6FWyt9nUcattrQ+svtY3c09xuISU6KSy/wDnN9XP/LXD/wC36/8AySX /ADm+rn/lrh/9v1/+SSU6SUhVDk4+bgvvw72XVOB2XVOD2kjmHNkaLlP2lnf6Z34KnznPQ5Yx E4mXF2bGDlpZr4SBw93tXOAEkiO5WdmZu+a6z7e5HdYeHm5ll4Y+1zmkcGFPq/VsLpGE/Ly3h jWj2M/Oe6NGtHclRQ537xH9UDHWtd2T7t7UvWQequr9WwukYb8vLeGsaPY3857o0a0dyVxeJT 1D6wdQb1rqwNWPWZwsTgAdnEKONjZ/1izx1frANeNWd2Hh8ADs5wXRaDSOP9eypc3zYxA4sRu ZFTmOngG3gwGZE5/KPlj+0rgbnAfvECfius9AeP8A2j9P5LlaG7rq29y5o0+K7b0G+f8AN7FV wRP3Pmp/7MX/AIQX5T/SMMfCZr/BafXsb1sFxH0qvePyfxXCdaxnZXTLq2CXhu5nxH+xelWsF jHVu4cIXFZ2I7FybKHAloJAJ7tV74rjMMuPmANBQl9C1+QmJQniPWyPq8f9TuoYNHTXsyMiqp /qE7Xva08nxK3v2x0kajNont+kZ/eqln1U+r9j3Pdht3OJJO541P8AaUf+aP1c/wC4bf8APf8 A+SVHPk5TLllkJzRMzdCMf4tqEM8IiAGMgeJ/g9jfnfU3rHS8fG6rm4V7GbLPTfe1sPaOdHgo hu+ohz39SGZgjNfV9ndeMhk+nAbtjfHA8FxX/NH6uf8AcMf57/8AySX/ADR+rn/cNv8Anv8A/ JLSj8a5eMYx4Mh4QBtHp9WlL4dlJJ4oam9z/B0v+Zn+K/8A8sMf/wBiWf8Aklo9X6V/i+6xXh 15nUcYtwKRRRtyWCGAACfd5LnP+aP1c/7ht/z3/wDkkv8Amj9Xf+4bf89//kkf9N8v+5k+yP8 AFH+jcv70Px/g7WD9Wv8AFlhve5ubi2NtYa7GPyWbS0kH9/yReqdC/wAW/U3Um7PxWNx6xVUx mSwANHA+n5LA/wCaP1c/7hD/AD3/APkkv+aP1c/7hD/Pf/5JH/TfL/uZPsj/ABV/o3L+9D8f4 Ol/zM/xXf8Alhj/APsUz/yaX/Mz/Fd/5YY//sUz/wAms3/mj9XP+4Y/z3/+SS/5o/Vz/uGP89 //AJJD/TfL/uZPsj/FX+jcv70Px/g9hgZ/1S6H0U9P6d1LFNNQeWN9esmXkuP53iVzn7Y6T/3 Nx/8Atxn96pf80vq5/wBw2/5z/wDySX/NH6uf9wx/nv8A/JKnznOcrzJiZe7HhHSMf++bHL8v mw3XBLi7k/wbzfrH0bBDsl+XVYK2khlbw5zj2aA0lZGPjZ/1iz29Y6wDXi1mcPD4Edi4K3X9V fq/U9tjMRoewhzTuedR5Fy1uNPw7KEc3jxYjj5fiuRPFOYAIHhVs3synMTy16dox2+tqgRxp2 ASSP3pFULJLYb/AEXH9bqNfdrDvcF2Cxvq7hOpoN9jYdb9Cf3VtLchyso/DMkaPHkqdeRH8HM lnB5yJv0w9F/y8Vj4LI6/gfaKPXYJsqH3hbBUXNBEHjwWtnwxzY5Y5bSH49C0sWQwmJx3H8qe BSWt1zpZx7TkVD9C86x+aVk6Lk+YwTw5DCXTbxHd3MWWOSAlHr+CtEtEktFAyK0STJJKXhMkk kpScBMkkpeEtEySSl0oSSSUoK30zDdmZbGR7Adzz5BBx8ezJtbTUJc49u3muv6fgVYNIrrEuM F7vErR+Hckc8xOQ/VwNm+vg1Oc5kY48I+eQ+zxbLWta0NaIDRAHwUkoTyul4RVdHHXUSFJMZR QivqZdW6t+rXCCuT6j0m/Ce5wBfR2f/euxhDsqbYwssbuaeR4qpznJY+ZjR0mPlkz8vzEsMrG oO4eD0PklAW31L6v3NsdbigOYdfTHIWNZU+t2x7S1w7EQub5jlMuGRE4muhGxdjFnx5BcZDy6 sUoSATlV2ViknhKElLJJ0klKS0ShKNUaUrREootyLBVS0ueeB/erWH0jMyiIYa2Hl7hAXS4HT aMKvbWJefpWHkrQ5L4bkzEGYMMfc7nyanMc5DGKj6p+HRF0jpjcGqXQ61+rj4eS0gEwCcLo8W OOOAhAVGOzkTmZyMpG5FSUJ0k9apJJJJSkxTpJKYqvk4ONlNIuYHH97urSbsmZfb4T7nDw9eP b8V0eK/Td+G7zmR9WLBJx7Qf5Lv9izL+m51B/SUujuQJH4LtVF/0Dx/a4WJnx/C5E8OX2z/Vj Ij8qdPFLnQBcOMf1iAXhXU3NEuY4AdyDCgu1sjYf5n+1MKvp/3U/FVTg5LpzX245fwZvd5nrg /54eSKLXi5Nn83U506iASuoMR/2k/FXcfgfQ4/waMcHI36ua08Mcv4IOXmemAf44eaxvq9m3Q bSKRzrqfwWxh9Cw8Yhzh6tg4LlpJDlaPKR+GiQ4JRlL/WX+HE1M55wj1ggf1K/HhWAAgDQDhO nTrWFNFSSSSSFJJJJKf/2QplbmRzdHJlYW0NZW5kb2JqDTM0IDAgb2JqDTw8IC9UeXBlIC9YT 2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTE5IC9IZWlnaHQgMTIwIC9CaXRzUGVyQ2 9tcG9uZW50IDggDS9Db2xvclNwYWNlIDEwIDAgUiAvTGVuZ3RoIDMzNjMgL0ZpbHRlciAvREN URGVjb2RlID4+IA1zdHJlYW0NCv/Y/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBcSFBQUFBIXFxscHhwbFyQkJyckJDUzMzM1Ozs7Ozs7Ozs7OwENC wsNDg0QDg4QFA4PDhQUEBEREBQdFBQVFBQdJRoXFxcXGiUgIx4eHiMgKCglJSgoMjIwMjI7Oz s7Ozs7Ozs7/8AAEQgAeAB3AwEiAAIRAQMRAf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQY HCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIR AwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjd DYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/ cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1M VY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2 hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9USSSSUpJJBysvHxKzbkPFbB3Pf4J b6KTKLnNaJcQB4nRcznfWq55LMFnpt/0r9XfJvCxr8vKyTN9rrT/KJj7uFLHBI6nRHE9u/qXT 6zD8isEdtwQx1vpRMfaq/vXDAR2Sj7lJ93j1kUcT39WfhW6V31vPgHBWJnULziPJWsXqefiEe hc4NH5h1b9xTTy/aX2p4nvUlz+B9aankMzWekeBa3VvzHZbzHse0PYQ5rhII1BUMomJohLJJJ JBSkkkklKSSVbPza8LFfkW8N4A7k8BKiTQUh6p1Wjp1O5/utf/N19yf7lx2Zm5Obcbsh5c780 dm/1U2XlXZd7r7zue/7gPAfBAc5rGl7iGtaCXOJgABW8eMQF7lYSeinPaxpe9wa1olzjoAAuf s+uOOXvGNh231NMNtBDQ6O+qz+sdYf1h5x8clnTazDncOucP8AvqrABoAAgDQAcBTQgZ6g8Mf zWTyCOg1Lr/8APH/zXXf5zUv+eP8A5rrv85qyEk/2D++fsWe8ewdf/nj/AOa67/Oal/zx/wDN dd/nNWQnS9g/vn7Ar3j2Dr/88f8AzXXf5zVufVf67X/bfsoxbaqXVm707CCC0Hb7Fj/V76vP6 k/7RkgtwmHXsbD+63y8StDOYyv64sZW0MYzpwDWjgD1DwoMsQCI8Rlr6rZIEmzVPp2Jl0ZdDb 6HbmO/A+BR1xHR+qWdPyROuPYYtb4fyviu1Y9r2B7TLXCQR3BVXJj4D4dGQFkkkkmJWC5H6y9 QORm/Z2H9Fj6ad3n6X3LqM3IbjYl15/wbCfnGi4BznPcXuMucZcfMqbBGyZdkSKyzuqYreoZ3 SelXPe3FzssVZAYdpc0NmJWiqlv/AIovq7/4e/76pspPBLyWjdi3o31WO4Y/T+sXVVvfW2yv0 SwmtxY6JcNJapfsX6uf+VfW/wDwD/yS2Oif0D/r+T/7cWK+miWSh65I4I/uh5j9i/Vz/wAq+t /+Af8Akkv2L9XP/Kvrf/gH/kl06SPFk/fl/jK4I/uh5j9i/Vz/AMq+t/8AgH/klb6Z9V/qz1D 7W1lHUMa7Cayx9WU5g3B+4sjZu09i3FHpH/KnW/8Awri/+j02Usg145bp4I/uhTGMrrbXW0MY wQ1rdAAuY6l/4tR/6bh/58K6jsuX6l/4tW/+m4f+fHI9R5p6N1dR9V+oG2l2FY6X1e6ue7D2+ RXLq50rKOL1Cm0cbtjvg7RPyx4okdkAvdpJaJKivcj6z2FnSy0f4R7W/KZ/guPXQfXvqFWB07 Hsta5zXXRDYn6LvFcT/wA5MP8A0Vv4f3q5y8DwWBuWOUgDVusqlv8A4ovq9/4e/wC+qp/zkw/ 9Fb9w/vUcXqlGd9ZOgsqY9hZmhxL4ggt8k7NEjHLRUZRJ3el6J/QP+v5P/txYr6odF/oH/X8n /wBuLFfUcdguUkkkipSj0j/lTrf/AIVxf/R6ko9I/wCVOt/+FcX/ANHpmTYeagv2XL9S/wDFq 3/03D/z45dQOAuP+sGdVg/W5l1rXOa7ADYbEz6jk8C5ADugmgSXVSMjUaHssn/nLhf6O3/o/w B6X/OXC/0Vv/R/vVgwl2Wcce76iMknpX2rv6Bs+YbKSzcfMrd9TDmAOFYwbLNp+lArcUln166 /rUy3pbm/4zaS/wCr1doH8zkMJ+Dg5n/fl5rQA4EdwvZPrR0/9pdBzMQCXurL6/67Pe38QvGM d8WCfztD8Vd5U3ikP3TbDkHrB/eT+mFZ6K2PrT0P/wANt/IUJE6dfTR9Y+jXX2NqqrywXveQG gRySU3NkuEgvjEAh7Tov9A/6/k/+3FivrDx8vIw2Ooqyuk21i217LHZ2wkWWPtEtFZ/eRP2rm /6bo//ALkD/wCk1CJxA3XUXYSWP+1c3/TdH/8Acgf/AEml+1c3/TdH/wDcgf8A0ml7ke6qLsK PSP8AlTrf/hXF/wDR6yf2rm/6bo//ALkD/wCk1Z6V1TEw39Uzep53T6vtFFTK68fJFxikWTyG 6nfohOYIoHqEgNrIycfExn5OTYKqKm7n2O4C826r1R3Wuqu6l6fo0Nr9HHafpOYC47neZROud Zyev3te9rqemV64+OdC/wD4Sz+Cp/66K1hxkkTOw2Ycs69IUkTAJSVvpGE/qHVMXDrG43Wsaf Jsy78ArRNAnsGDfR9XqwrG/Uk4O39IenOr2/yjUR+VJbuxmz049sbY8uEljcXq4vG27WleFMj wvGfrh0d3SOu31Nbtx7yb8Yjja4y5v9kr2aFz/wBcfq63rnTC2sAZmPL8dx7nuz4OUvL5fbnr 8stJLMseKPlq+UC2QD4oGW+pzWVupGTdYdtFO3cXPOmiBl22YpLXscLA4sNUe4PBjb8ZWp0P6 vZORf6nUcLNZeZc65rdjKqhyfcwndHgnmB9yUbqI1vwUJ+kFp4/1Y63cyy2zDqoZUzcd2O6S4 /RraIkuKen6r9cspuudh1VsqA+ljulzjwxgiSfHwXRDCGdZXjMw+p42Hitcd7tAGgy+1w9OXP d4fJJuGM+yuo4fUsTCxKzDz+awal0enL3vd/rCk9vH/IrPck85V9V+tvx7b3YlVbagA0HHdue 8/mtG3XzPCev6r9bdjW5D8SuttZDWNOO7c95/NaI7DUnhdF9kHUbAH4XU8PCxK9ByGMH7oNcv e934pvsY6hYbLcLqWLiYlUNY0/RYPo11/o5c97kfax/yP8Aan3JPPN+q/WzjPyXYlTA1wYxhx zue48w2OG+Kdn1X62MQ5LsSppDwyuv7O4vefznCG6Bviuh+xjqFrr8nC6lj4uLWGsqaSIaNGU 1gVyXOPf5qFzenvL+odYbl9OxaQ1ldVr4Dg36NFVYa17h5oHHjG/11VxzecysbreI3GfnsbXV kWOrraWFrvYASYPbVN/FW+tdayOuZFDzSMXBxCTi1HWwyI3OPy4VVT8uCImwQCfSCx5SLHetV l3X+LLozrMm7rNohlINOPPdx/nHfIaLkuk9KyurZ9WBiiXWH3v7MYPpPPwXtPTenY/TcGnBxh FVDdo8T4k+ZKj5zKIx4B80t/JdhhZ4j0baSSSoNlSSSSCHiPr19RR1Zp6j00Fmcwh9lbTtNu3 gtPZ4/FeePzuvsc5j+rdQZYw7XNde8EEdiN2kL3qAue+sn1M6Z1wG6Ps+aBDchg58rG/nBT4s sBpljxDYHqGOcZbwNeD5L+0Ouf8Alxn/APsRZ/5JL9o9c/8ALjP/APYh/wD5JaXWfqn1vo7ic ig2UDjIpBfWR592/NY4giRr4q8MWCQuIBHgwGcwaJKb9odb/wDLjP8A/Yh//kkv2h1v/wAuM/ 8A9iH/APkkFJO9jF+6Fe5PuU37Q65/5cZ//sRZ/wCSQLTfk3Nvzci7NtYIY7IebC0eW5Onb7n BjZc8mA0CST8OUhhxg2IhHHI6ElZWundNzep5bMPCqNtz+w4a395x7ALd6H9QesdSLbcppwMX SXWD9I4fya/716R0XoXTui4/2fBq2z/OWO1e8+LnKLNzUYWI+qf4BfDETvoGr9V/qzjdAxNjT 6uVbByL41J/db4NC206SzpSMiZE2S2AKFBSSSSCVJL5WSSU/VKS+VkklP1QQCIIkHssbqH1Q+ rvUJN+Exrz/hKv0bvvYvnBJOhx36bv+qtlXWvq+63f4r+jPM05ORV4A7X/APVNlBH+KrBB16h d/mMXiCSsj75XX60s/U+D7zj/AOLLoFZBvsyL47F4a0/5gB/Fb/T+g9H6YB9hxKqXD88Nl/8A nHVfM6Siye//AJTi/Yujwfo0/VKS+VklEyP1SkvlZJBD9UpL5WSSU//ZCmVuZHN0cmVhbQ1lb mRvYmoNMzUgMCBvYmoNPDwgDS9UeXBlIC9FeHRHU3RhdGUgDS9TQSBmYWxzZSANL1NNIDAuMD IgDS9UUjIgL0RlZmF1bHQgDT4+IA1lbmRvYmoNMSAwIG9iag08PCANL1MgL0QgDT4+IA1lbmR vYmoNMiAwIG9iag08PCANL051bXMgWyAwIDEgMCBSIF0gDT4+IA1lbmRvYmoNMyAwIG9iag08 PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDggMCBSIF0gDS9Db3VudCAxIA0+PiANZW5kb2JqD TQgMCBvYmoNPDwgDS9DcmVhdGlvbkRhdGUgKEQ6MjAwMzA5MjIxNTE1MzctMDQnMDAnKQ0vTW 9kRGF0ZSAoRDoyMDAzMDkyMjE1MTUzNy0wNCcwMCcpDS9Qcm9kdWNlciAoQWNyb2JhdCBEaXN 0aWxsZXIgNS4wIFwoV2luZG93c1wpKQ0vQXV0aG9yIChzdGVwaGVuaykNL0NyZWF0b3IgKFBT Y3JpcHQ1LmRsbCBWZXJzaW9uIDUuMikNL1RpdGxlIChWaXNpby1PU1BGX2FuZF9Qb3J0UnVsZ XMudnNkKQ0+PiANZW5kb2JqDTUgMCBvYmoNPDwgL1R5cGUgL01ldGFkYXRhIC9TdWJ0eXBlIC 9YTUwgL0xlbmd0aCAxMDcxID4+IA1zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0nJyBpZD0nVzV NME1wQ2VoaUh6cmVTek5UY3prYzlkJyBieXRlcz0nMTA3MCc/PjxyZGY6UkRGIHhtbG5zOnJk Zj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6a Vg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+PHJkZjpEZXNjcmlwdGlvbiBhYm91dD 0nJyB4bWxucz0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgeG1sbnM6cGRmPSdodHR wOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyBwZGY6Q3JlYXRpb25EYXRlPScyMDAzLTA5LTIy VDE5OjE1OjM3WicgcGRmOk1vZERhdGU9JzIwMDMtMDktMjJUMTk6MTU6MzdaJyBwZGY6UHJvZ HVjZXI9J0Fjcm9iYXQgRGlzdGlsbGVyIDUuMCAoV2luZG93cyknIHBkZjpBdXRob3I9J3N0ZX BoZW5rJyBwZGY6Q3JlYXRvcj0nUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yJyBwZGY6VGl0bGU 9J1Zpc2lvLU9TUEZfYW5kX1BvcnRSdWxlcy52c2QnLz4KPHJkZjpEZXNjcmlwdGlvbiBhYm91 dD0nJyB4bWxucz0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeG1sbnM6eGFwPSdod HRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6Q3JlYXRlRGF0ZT0nMjAwMy0wOS0yMl QxOToxNTozN1onIHhhcDpNb2RpZnlEYXRlPScyMDAzLTA5LTIyVDE5OjE1OjM3WicgeGFwOkF 1dGhvcj0nc3RlcGhlbmsnIHhhcDpNZXRhZGF0YURhdGU9JzIwMDMtMDktMjJUMTk6MTU6Mzda Jz48eGFwOlRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+Vmlza W8tT1NQRl9hbmRfUG9ydFJ1bGVzLnZzZDwvcmRmOmxpPjwvcmRmOkFsdD48L3hhcDpUaXRsZT 48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0nJyB4bWxucz0naHR 0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIHhtbG5zOmRjPSdodHRwOi8vcHVybC5v cmcvZGMvZWxlbWVudHMvMS4xLycgZGM6Y3JlYXRvcj0nc3RlcGhlbmsnIGRjOnRpdGxlPSdWa XNpby1PU1BGX2FuZF9Qb3J0UnVsZXMudnNkJy8+CjwvcmRmOlJERj48P3hwYWNrZXQgZW5kPS dyJz8+CmVuZHN0cmVhbQ1lbmRvYmoNeHJlZg0wIDYgDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDA wMDAzOTc3NyAwMDAwMCBuDQowMDAwMDM5ODA3IDAwMDAwIG4NCjAwMDAwMzk4NDkgMDAwMDAg bg0KMDAwMDAzOTkxMyAwMDAwMCBuDQowMDAwMDQwMTUwIDAwMDAwIG4NCnRyYWlsZXINPDwNL 1NpemUgNg0vSURbPGViODRmOTM5MDZmNWI0YzM1OGQ1NmNmMTZkMDczNzA4PjxkNTQzM2EyMm Q3MmJmYTA0ODg4MmQyMTkxYWVmYWJiNj5dDT4+DXN0YXJ0eHJlZg0xNzMNJSVFT0YN --HotBOX.ru_1071578700d651c0427cbad04588d1969821e34f56-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 16 09:13:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15449 for ; Tue, 16 Dec 2003 09:13:19 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C78B21@cherry.ease.lsoft.com>; Tue, 16 Dec 2003 9:13:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64552149 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Dec 2003 09:13:15 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Dec 2003 09:13:15 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 16C547EE144 for ; Tue, 16 Dec 2003 06:13:15 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04636-08 for ; Tue, 16 Dec 2003 06:13:14 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.22]) by prattle.redback.com (Postfix) with ESMTP id 4DA637EE149 for ; Tue, 16 Dec 2003 06:13:14 -0800 (PST) References: <200312161245.hBGCj0wk063674@www5.hotbox.ru> Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Tue, 16 Dec 2003 09:12:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: OSPF routers with port rules question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200312161245.hBGCj0wk063674@www5.hotbox.ru> Precedence: list Content-Transfer-Encoding: quoted-printable On Tue, 16 Dec 2003 15:45:00 +0300, Alexander Cheskis = wrote: > Dear Group, > > I need to find routing solution for attached (PDF scheme) network confi= guration. > > Router 192.168.20.2 can relay traffic as shown: > > (port rule 1) From bottom networks (192.168.50.x) , to the bottom ports= of > 192.168.40.x > (port rule 2) From the top networks (192.168.20.x), to the top ports of > 192.168.30.x > > Obviously, when all port2port traffic is enabled on 192.168.20.2, every= thing is > fine. All 5 routers are OSPF enabled in the same area. > But when port rules are applied, bottom networks can't access top ones = and visa > versa. Alexander, If I understand what you are trying to do (and it ain't obvious), you can= 't solve this problem with OSPF. The cost via the Blue routers is always going to = be higher than the direct path. Rather than blocking ports, you need to something akin to policy based routing (i.e., forcing the traffic path to be different than the routed path using some other packet selection criteria). Good Luck, --=20 Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 16 13:09:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26036 for ; Tue, 16 Dec 2003 13:09:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C78FB3@cherry.ease.lsoft.com>; Tue, 16 Dec 2003 13:09:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64570931 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Dec 2003 13:08:59 -0500 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Dec 2003 12:58:58 -0500 Received: from user-2ivfjal.dialup.mindspring.com ([165.247.205.85] helo=erg.sri.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AWIoT-0005kw-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Dec 2003 09:16:50 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3FDF3DF9.1070609@erg.sri.com> Date: Tue, 16 Dec 2003 09:16:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello, I would like to comment on the Henderson draft (draft-spagnolo-manet-ospf-wireless-interface-00.txt) and also point out the following draft, which describes another approach for extending OSPF to support MANET interfaces: http://www.ietf.org/internet-drafts/draft-ogier-manet-ospf-extension-00.txt The above draft does not give a detailed specification, but discusses techniques that can be used as a basis for designing an extension of OSPFv3 to support MANET interfaces. This is my first post to the OSPF mailing list, but I have been working with the MANET WG for about 3 years, where I worked on the design of TBRPF. The goal of my draft is exactly as stated by Fred Baker in the problem statement draft and in his recent posts. In particular, I completely agree with his post of December 1. For example, it is not necessary to define a MANET area or cloud, but the existing notion of an OSPF area can be used to insulate non-MANET routers from MANET routers. In addition, the existing notion of an OSPF *stub* area can be used to insulate MANET routers from having to flood large numbers of LSAs originating from outside the MANET (as per Section 12.4.3.1 of RFC 2328). I will summarize my draft at the end of this email, but will first comment on the Henderson draft. My main comment on the Henderson draft is that it uses a completely different mechanism (OLSR flooding using MPRs) for flooding LSAs, whereas it is possible to use something that is much closer to OSPF, without giving up efficiency. Below I quote a set of bullets from the Henderson draft, summarizing their proposed OSPF extension, and for comparison, after each bullet I summarize how my proposed solution is different. (H indicates the Henderson draft and O indicates the Ogier draft.) H defines a new Wireless Hello message. The new message adds an MPR list and eliminate backup and designated router fields; O Does not require any change to the OSPF Hello packet format. The DR (and Backup DR) field indicates a CDS (connected dominating set) node instead of a DR. H implements the MPR selection algorithm and rules for reflood- ing LSAs; O Uses a CDS for flooding LSAs (called "overlapping relays" in Fred Baker's presentation). A CDS node is a simple, natural generalization of a DR. H efficiently floods LSAs periodically using a Link State Flood (LSF) message (with a new flooding sequence number for duplicate detection); O Uses an efficient method for reliable flooding using only OSPF message types, based on periodic Database Description packets. Duplicate detection of LSAs is done as in OSPF, based on the LS sequence number. H eliminates the formation of full adjacencies on wireless interfaces; all neighbor states beyond 2-Way are not reached, and no database synchronization is performed; O The draft provides a modified definition of full adjacency between a CDS node and its neighbors, to provide some synchronization. (Whether to require this is TBD.) H includes a mechanism for suppressing the redundant flooding of "outside" LSAs (LSAs originated external to the wireless sub- net). O Not addressed in the draft, but the existing notion of an OSPF stub area can be used to suppress flooding of "outside" LSAs. For convenience, a bullet presentation is included below that summarizes my draft. The purpose of this draft is to discuss and recommend candidate techniques for extending OSPF to support MANET interfaces. The draft may contain some new ideas, but the draft is mainly based on old ideas. The approach tries to minimize the changes to OSPF, while achieving the goal of reducing control traffic. As suggested by Russ White on Nov 28, it might be a good idea to form a separate mailing list to discuss this problem (since I can imagine having lengthy technical discussions). Regards, Richard Ogier --------------------------------------------------------------------- OSPF Extension for Manets Using Reliable Flooding draft-ogier-manet-ospf-extension-00.txt Richard Ogier SRI International --------------------------------------------------------------------- Objectives and Issues * OSPF generates too much control traffic in manets. - Link State ACKs - Database Exchange with each new neighbor * Unreliable, periodic flooding is wasteful of bandwidth. * To reduce control traffic, we need an efficient mechanism for reliable flooding of LSA in manets. * Minimize changes to OSPF: make only necessary changes (otherwise we are really designing a new protocol). * Some questions: - How to select relay nodes used for flooding LSAs? - How to flood LSAs reliably? --------------------------------------------------------------------- Choice for Relay Nodes * Connected Dominating Set (CDS) - Independent of originator - Called "overlapping relays" in Fred Baker's presentation. - A natural generalization of a DR. * Multipoint Relays (MPRs) - Dependent on originator - Useful if a min-hop path must exist that uses only MPRs as intermediate nodes. (Not necessary for OSPF extension.) - Can be neighbor-selected (as in OLSR) or self-selected. --------------------------------------------------------------------- Advantages of Using a CDS vs. MPRs * OSPF Hello packets can be used without modification (the DR field would indicate a CDS node, which can be the sending node itself). * Each node decides whether it is a CDS node based on Hellos and LSAs originated by neighbors. * Using a CDS is simpler since it is originator-independent. - Each CDS node is responsible for relaying all LSAs. - Full adjacencies can be formed between each CDS node and its neighbors. * A CDS node selects itself, similar to a DR in OSPF. This can result in faster recovery from link failures. --------------------------------------------------------------------- Suppression of LSA ACKs * A simple way to reduce ACK traffic (if the efficient flooding mechanism described on the next slide is not used). * An OSPF router can suppress LSA ACKs for received LSAs that are updated frequently (as may be the case in a highly mobile network). --------------------------------------------------------------------- Reliable Flooding Using Periodic Database Description Packets * Each router originates an LSA when it changes. * To flood the LSA, each CDS node transmits each LSA once. * Duplicate detection is done as in OSPF - based on the LSA sequence number in the database. * No new message type is required. OSPF Database Description (DD) and LS Request packets are used, but in a more efficient manner. * No ACKs, no NACKs. * Each CDS node periodically (e.g., every 5 or 10 sec) broadcasts a complete set of DD packets on each manet interface. Similar to the Periodic Complete Sequence Numbers packets of IS-IS. * Since a DD packet contains only LSA headers, this generates much less overhead than periodic flooding of LSAs. * Periodic DD packets accomplish two purposes: - The reliable delivery of LSAs to neighbors (without ACKs). - The exchange of LSAs between each CDS node and its neighbors (without requiring a separate Database Exchange with each neighbor) * If a node receives a DD packet that indicates a CDS neighbor has a more recent instance of an LSA, the node sends a LS Request for that LSA to the CDS neighbor. * LSAs and DD packets are always broadcast (to all neighbors) on manet interfaces. LS Requests are unicast to a single CDS neighbor. * The number of LS Requests can be reduced by using a redundant CDS, so that each node is a neighbor of at least two CDS nodes. The Backup DR field can be used to identify a redundant CDS node. * The number of LS Requests can be reduced by having each CDS node transmit each LSA multiple times. (The number of times can depend on recent history of LS Requests.) -------------------- Differential LSAs (optional) * A differential LSA reports only differences (new links lost links, and metric changes) between the current instance and a previous instance of an LSA, instead of reporting the entire LSA. * Example: If a node has 100 neighbors and loses one of them, it would be wasteful to generate a full LSA with 99 neighbor IDs, when the loss could be reported in a differential LSA containing a single neighbor ID. * The checksum in the differential LSA is the checksum for the entire LSA. * LS Request would also include a sequence number to indicate the current instance. * Differential LSAs achieve the greatest overhead reduction in dense, mobile networks. --------------------------------------------------------------------- Conclusions * Recommend using a CDS for flooding LSAs within a MANET: - A simple, natural generalization of a DR. - No change required for OSPF Hello packet format (the DR field is used to identify a CDS node). * Flooding of LSAs in a MANET does not require a new message type - the LS sequence number can/should be used for duplicate detection. * Periodic Database Description packets can be used for efficient reliable flooding (similar to IS-IS). * If LSA ACKs are used (instead of Periodic DD packets), LSA ACKs can be suppressed for LSAs that are updated frequently. * Differential LSAs can be defined as an option, to reduce overhead in dense, mobile networks. --------------------------------------------------------------------- Richard Ogier SRI International From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 16 14:16:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28124 for ; Tue, 16 Dec 2003 14:16:26 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C79058@cherry.ease.lsoft.com>; Tue, 16 Dec 2003 14:16:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64578485 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Dec 2003 14:16:22 -0500 Received: from 207.217.120.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Dec 2003 14:16:22 -0500 Received: from user-2ivfii8.dialup.mindspring.com ([165.247.202.72] helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AWKg9-0003gI-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Dec 2003 11:16:21 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200312161245.hBGCj0wk063674@www5.hotbox.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3FDF59D1.5D8B389@earthlink.net> Date: Tue, 16 Dec 2003 11:15:29 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: OSPF routers with port rules question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alexander Cheskis, The only way to favor or not favor a route in traditional OSPF hop by hop routing is with the link costs assigned to each hop of the route. However, even with an infinite link costs to for certain hops, if there is no alternate route available, the infinite link cost hop will still be used. Thus, within OSPF, I am not sure how you can enforce that the bottom networks not send or recieve traffic from the top networks. If packet policy routing is wanted, a MPLS OSPF network can possibly be used to achieve your results. Mithell Erblich Sr Network Software Engineer ----------------------------- Alexander Cheskis wrote: > > Dear Group, > > I need to find routing solution for attached (PDF scheme) network configuration. > > Router 192.168.20.2 can relay traffic as shown: > > (port rule 1) From bottom networks (192.168.50.x) , to the bottom ports of > 192.168.40.x > (port rule 2) From the top networks (192.168.20.x), to the top ports of > 192.168.30.x > > Obviously, when all port2port traffic is enabled on 192.168.20.2, everything is > fine. All 5 routers are OSPF enabled in the same area. > But when port rules are applied, bottom networks can't access top ones and visa > versa. > > Thanks in advance, > Alexander Cheskis > > ------------------------------------------------------------------------ > Name: OSPF_and_PortRules.pdf > OSPF_and_PortRules.pdf Type: Acrobat (application/pdf) > Encoding: base64 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 16 14:16:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28140 for ; Tue, 16 Dec 2003 14:16:31 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C79179@cherry.ease.lsoft.com>; Tue, 16 Dec 2003 14:16:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64578497 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Dec 2003 14:16:29 -0500 Received: from 130.76.96.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Dec 2003 14:16:28 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA14136 for ; Tue, 16 Dec 2003 13:16:27 -0600 (CST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id NAA27076 for ; Tue, 16 Dec 2003 13:16:27 -0600 (CST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id hBGJERK27570 for ; Tue, 16 Dec 2003 11:14:27 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 16 Dec 2003 11:11:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: OSPF WG Direction with respect to MANET Requirements Thread-Index: AcPD//iWzn6/T6I6SbCnolSCC+PiqQACAgVQ X-OriginalArrivalTime: 16 Dec 2003 19:11:55.0404 (UTC) FILETIME=[7853B4C0:01C3C408] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F7D@xch-nw-27.nw.nos.boeing.com> Date: Tue, 16 Dec 2003 11:11:55 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: OSPF WG Direction with respect to MANET Requirements To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Richard Ogier [mailto:ogier@ERG.SRI.COM] > Sent: Tuesday, December 16, 2003 9:17 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: OSPF WG Direction with respect to MANET Requirements >=20 > As suggested by Russ White on Nov 28, it might be a good idea to > form a separate mailing list to discuss this problem > (since I can imagine having lengthy technical discussions). >=20 I too would like to have a discussion on these issues, but was waiting to see a suggestion from OSPF WG or MANET WG on how to move forward. We could either: - cross post to both lists (MANET and OSPF)-- I am assuming that this is frowned upon for lengthy threads as usual - limit it to one or the other list - form a new list on this topic Tom From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 16 16:04:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04569 for ; Tue, 16 Dec 2003 16:04:52 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C79214@cherry.ease.lsoft.com>; Tue, 16 Dec 2003 16:04:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64589429 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Dec 2003 16:04:50 -0500 Received: from 80.68.244.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Dec 2003 16:04:46 -0500 Received: by HotBOX.Ru WebMail v2.1 id hBGL4kqH009304 for ; MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Mailer: Free WebMail HotBOX.ru X-Proxy-IP: [212.150.43.131] X-Originating-IP: [212.150.43.131] Message-ID: <200312162104.hBGL4kqH009304@www2.hotbox.ru> Date: Wed, 17 Dec 2003 00:04:46 +0300 Reply-To: Mailing List Sender: Mailing List From: Alexander Cheskis Subject: Re: OSPF routers with port rules question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Dear Mithell/Acee, The situation, which I described, is very common in contemporary networks. 192.168.40.3, 192.168.40.4, etc . they are common servers, firewalls, antiviruses etc. OSPFv2 based. 192.168.40.2 - smart router, supports OSPF, which get all traffic between top and bottom networks, and forward it (sometimes for load balancing, sometimes for redundancy) to relevant servers, I mentioned above. In case that these firewalls can't support MPLS signaling, I wander that there is NO way to configure smart router's OSPF to work as described. The one-way, I found is to "simulate" two different OSPF routers inside smart router, and duplicate LSDB tables. The other dirty way is to do all routing with static routes. May be there is another tricky way? To define smart router as ASBR and define different areas on its top and bottom ports? Thanks, Alexander -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Tuesday, December 16, 2003 9:15 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OSPF routers with port rules question Alexander Cheskis, The only way to favor or not favor a route in traditional OSPF hop by hop routing is with the link costs assigned to each hop of the route. However, even with an infinite link costs to for certain hops, if there is no alternate route available, the infinite link cost hop will still be used. Thus, within OSPF, I am not sure how you can enforce that the bottom networks not send or recieve traffic from the top networks. If packet policy routing is wanted, a MPLS OSPF network can possibly be used to achieve your results. Mithell Erblich Sr Network Software Engineer ----------------------------- Alexander Cheskis wrote: > > Dear Group, > > I need to find routing solution for attached (PDF scheme) network configuration. > > Router 192.168.20.2 can relay traffic as shown: > > (port rule 1) From bottom networks (192.168.50.x) , to the bottom ports of > 192.168.40.x > (port rule 2) From the top networks (192.168.20.x), to the top ports of > 192.168.30.x > > Obviously, when all port2port traffic is enabled on 192.168.20.2, everything is > fine. All 5 routers are OSPF enabled in the same area. > But when port rules are applied, bottom networks can't access top ones and visa > versa. > > Thanks in advance, > Alexander Cheskis > > ------------------------------------------------------------------------ > Name: OSPF_and_PortRules.pdf > OSPF_and_PortRules.pdf Type: Acrobat (application/pdf) > Encoding: base64 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 16 16:57:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09920 for ; Tue, 16 Dec 2003 16:57:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C792AA@cherry.ease.lsoft.com>; Tue, 16 Dec 2003 16:57:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64593004 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Dec 2003 16:57:05 -0500 Received: from 216.21.152.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Dec 2003 16:47:05 -0500 Received: (from mrozhavsky@localhost) by mrozhavsky.fortinet.com (8.11.6/8.11.6) id hBGLeNE27018; Tue, 16 Dec 2003 13:40:23 -0800 X-Authentication-Warning: mrozhavsky.fortinet.com: mrozhavsky set sender to mrozhavsky@fortinet.com using -f References: <200312162104.hBGL4kqH009304@www2.hotbox.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Message-ID: <20031216134023.B26921@mrozhavsky.fortinet.com> Date: Tue, 16 Dec 2003 13:40:23 -0800 Reply-To: Mailing List Sender: Mailing List From: Michael Rozhavsky Subject: Re: OSPF routers with port rules question Comments: To: Alexander Cheskis To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200312162104.hBGL4kqH009304@www2.hotbox.ru>; from cheskis@pisem.net on Wed, Dec 17, 2003 at 12:04:46AM +0300 Precedence: list Hi, It really depends on the OS you have on 192.168.20.2 but you can run two OSPF instances on your 192.168.20.2 (one for bottom half and one for the top one), each one of them will use it's own routing table (again assuming that your OS can do that). Bind corresponding interfaces to related routing table and I think you'll get what you are looking for. HTH On Wed, Dec 17, 2003 at 12:04:46AM +0300, Alexander Cheskis wrote: > Dear Mithell/Acee, > > The situation, which I described, is very common in contemporary networks. > > 192.168.40.3, 192.168.40.4, etc . they are common servers, firewalls, > antiviruses etc. OSPFv2 based. > > 192.168.40.2 - smart router, supports OSPF, which get all traffic between top > and bottom networks, and forward it (sometimes for load balancing, sometimes for > redundancy) to relevant servers, I mentioned above. > > In case that these firewalls can't support MPLS signaling, I wander that there > is NO way to configure smart router's OSPF to work as described. > > The one-way, I found is to "simulate" two different OSPF routers inside smart > router, and duplicate LSDB tables. > The other dirty way is to do all routing with static routes. > > May be there is another tricky way? To define smart router as ASBR and define > different areas on its top and bottom ports? > > Thanks, > Alexander > [snip] Best regards, -- Michael Rozhavsky mrozhavsky@fortinet.com Software Engineer Fortinet (Canada) Inc. 4710 Kingsway Suite 400 Tel: (604) 430-1297 ext 309 Burnaby, BC V5H 4M4 Canada Fax: (604) 430-1296 From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 17 05:40:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02516 for ; Wed, 17 Dec 2003 05:40:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C7A256@cherry.ease.lsoft.com>; Wed, 17 Dec 2003 5:40:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64655927 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Dec 2003 05:40:54 -0500 Received: from 202.43.216.210 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Dec 2003 05:40:53 -0500 Received: from [202.96.96.35] by web15407.mail.cnb.yahoo.com via HTTP; Wed, 17 Dec 2003 18:40:51 CST MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Message-ID: <20031217104051.7989.qmail@web15407.mail.cnb.yahoo.com> Date: Wed, 17 Dec 2003 18:40:51 +0800 Reply-To: Mailing List Sender: Mailing List From: =?gb2312?q?Jing=20Shen?= Subject: Re: OSPF routers with port rules question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20031216134023.B26921@mrozhavsky.fortinet.com> Precedence: list Content-Transfer-Encoding: 8bit I'm not sure whether I got clearly what it is desired. To my understanding, it is asked that traffic from 50' be routed to 40' ( then to other network), while traffic from 20' be routed to 30'.and, not cut-through is permitted. To realize such situation, routing is not needed at all. The point rule could be implemented as VLAN in a Layer3 siwtch. that 40' and 50 be cataloged into one VLAN and 20' 30' to another VLAN. The two VLAN is not allowed to communicate with each other directly. --- Michael Rozhavsky µÄÕýÎÄ£º> Hi, > > It really depends on the OS you have on 192.168.20.2 > but you can > run two OSPF instances on your 192.168.20.2 (one for > bottom half > and one for the top one), each one of them will use > it's own routing > table (again assuming that your OS can do that). > Bind corresponding > interfaces to related routing table and I think > you'll get what you > are looking for. > > HTH > > On Wed, Dec 17, 2003 at 12:04:46AM +0300, Alexander > Cheskis wrote: > > Dear Mithell/Acee, > > > > The situation, which I described, is very common > in contemporary networks. > > > > 192.168.40.3, 192.168.40.4, etc . they are common > servers, firewalls, > > antiviruses etc. OSPFv2 based. > > > > 192.168.40.2 - smart router, supports OSPF, which > get all traffic between top > > and bottom networks, and forward it (sometimes for > load balancing, sometimes for > > redundancy) to relevant servers, I mentioned > above. > > > > In case that these firewalls can't support MPLS > signaling, I wander that there > > is NO way to configure smart router's OSPF to work > as described. > > > > The one-way, I found is to "simulate" two > different OSPF routers inside smart > > router, and duplicate LSDB tables. > > The other dirty way is to do all routing with > static routes. > > > > May be there is another tricky way? To define > smart router as ASBR and define > > different areas on its top and bottom ports? > > > > Thanks, > > Alexander > > > [snip] > > > Best regards, > > -- > Michael Rozhavsky > mrozhavsky@fortinet.com > Software Engineer > Fortinet (Canada) Inc. > 4710 Kingsway Suite 400 Tel: (604) 430-1297 > ext 309 > Burnaby, BC V5H 4M4 Canada Fax: (604) 430-1296 Jing Shen ZheJiang University P.R.China ' spamcontrol ' __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 17 15:30:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02097 for ; Wed, 17 Dec 2003 15:30:58 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C7AD35@cherry.ease.lsoft.com>; Wed, 17 Dec 2003 15:30:56 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64721080 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Dec 2003 15:30:53 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Dec 2003 15:30:53 -0500 Received: (qmail 10124 invoked by uid 404); 17 Dec 2003 20:30:53 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.056759 secs); 17 Dec 2003 20:30:53 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 17 Dec 2003 20:30:53 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id PAA11807; Wed, 17 Dec 2003 15:30:52 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200312172030.PAA11807@bigbird.nj.us.utstar.com> Date: Wed, 17 Dec 2003 15:30:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPF WG Direction with respect to MANET Requirements Comments: cc: corson@flarion.com, macker@itd.nrl.navy.mil To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Message from "Henderson, Thomas R" of "Tue, 16 Dec 2003 11:11:55 PST." <6938661A6EDA8A4EA8D1419BCE46F24C026B5F7D@xch-nw-27.nw.nos.boeing.com> Precedence: list Thomas, Please use the OSPF WG list "without" cross-posting to the MANET WG list for further discussions on this topic. --rohit. PS: If there are folks you know of who are interested in this topic please ask them to subscribe to the OSPF WG list at http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1 On Tue, 16 Dec 2003 11:11:55 -0800 "Henderson, Thomas R" writes: =>> -----Original Message----- =>> From: Richard Ogier [mailto:ogier@ERG.SRI.COM] =>> Sent: Tuesday, December 16, 2003 9:17 AM =>> To: OSPF@PEACH.EASE.LSOFT.COM =>> Subject: Re: OSPF WG Direction with respect to MANET Requirements =>>=20 =>> As suggested by Russ White on Nov 28, it might be a good idea to =>> form a separate mailing list to discuss this problem =>> (since I can imagine having lengthy technical discussions). =>>=20 => =>I too would like to have a discussion on these issues, but was =>waiting to see a suggestion from OSPF WG or MANET WG on how =>to move forward. We could either: =>- cross post to both lists (MANET and OSPF)-- I am assuming that =>this is frowned upon for lengthy threads as usual =>- limit it to one or the other list =>- form a new list on this topic => =>Tom ___ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 18 08:54:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22020 for ; Thu, 18 Dec 2003 08:54:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C7C1FC@cherry.ease.lsoft.com>; Thu, 18 Dec 2003 8:18:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64827009 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Dec 2003 08:18:35 -0500 Received: from 195.117.137.85 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Dec 2003 08:18:34 -0500 Received: from localhost (localhost [127.0.0.1]) by nsm.pl (Postfix) with ESMTP id 14EF86AF89 for ; Thu, 18 Dec 2003 14:18:31 +0100 (CET) Received: from nsm.pl ([195.117.137.85]) by localhost (nsm.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24427-04 for ; Thu, 18 Dec 2003 14:18:31 +0100 (CET) Received: from sqix (hub3.chelmnet.pl [195.117.2.99]) by nsm.pl (Postfix) with SMTP id B2CED6AF2B for ; Thu, 18 Dec 2003 14:18:30 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 X-Virus-Scanned: NSM AntiVirus System Message-ID: Date: Thu, 18 Dec 2003 14:18:40 +0100 Reply-To: Mailing List Sender: Mailing List From: Arkadiusz Binder Subject: LSA 5 (7) filtering To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I wanted to filter LSA type 5 routes, but read old topics, where it is assumed that it is not OK. I use OSPF in Wireless Network connectivities too. I'm peering one OSPF domain across my ISP-partner network. Sometimes i want to not permit some routes to be injected into some places (i want them to be destroyed, and sent by partner's default route instead of that peering link with OSPF network). I think that it is possible to achieve target by using NSSA type. But at the point i can't find nowhere a possibility to filter LSA7 (or LSA5) type routes . If A-----B--NSSA--C--D router A is ASBR with injecting 1.1.1.1/24 as TYPE5 i don't want router C knows that route. At the moment, router C use fake route=his_default route to router D (Router D is announcing this route via RIP... etc) Is it a target of working group or is it a target of soft implementation ? A.Binder From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 18 10:28:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28835 for ; Thu, 18 Dec 2003 10:28:12 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C7C254@cherry.ease.lsoft.com>; Thu, 18 Dec 2003 10:28:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64836684 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Dec 2003 10:28:06 -0500 Received: from 65.205.166.188 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Dec 2003 10:28:06 -0500 Received: from dc1laptop (unknown [172.16.24.103]) by jera.movaz.com (Postfix) with SMTP id BDBC417D45 for ; Thu, 18 Dec 2003 10:28:05 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Thu, 18 Dec 2003 10:28:05 -0500 Reply-To: Mailing List Sender: Mailing List From: Dan Dovolsky Subject: Does anyone has experience with operationally down interface, which can still be IP reachable? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Does anyone has experience with operationally down interface, which still can be IP reachable? Thanks, Dan Dovolsky. ddovolsky@movaz.com From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 18 11:11:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01149 for ; Thu, 18 Dec 2003 11:11:17 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C7C50C@cherry.ease.lsoft.com>; Thu, 18 Dec 2003 11:11:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64839941 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Dec 2003 11:11:15 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Dec 2003 11:11:15 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C119D520FA8 for ; Thu, 18 Dec 2003 08:11:14 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00137-02 for ; Thu, 18 Dec 2003 08:11:14 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.26]) by prattle.redback.com (Postfix) with ESMTP id 33A215B5484 for ; Thu, 18 Dec 2003 08:04:20 -0800 (PST) References: Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Thu, 18 Dec 2003 11:03:57 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: LSA 5 (7) filtering To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: quoted-printable On Thu, 18 Dec 2003 14:18:40 +0100, Arkadiusz Binder w= rote: > I wanted to filter LSA type 5 routes, but read old topics, where it is > assumed that it is not OK. > I use OSPF in Wireless Network connectivities too. > > I'm peering one OSPF domain across my ISP-partner network. Sometimes i = want > to not permit some routes to be injected into some places (i want them = to be > destroyed, and sent by partner's default route instead of that peering = link > with OSPF network). > > I think that it is possible to achieve target by using NSSA type. > > But at the point i can't find nowhere a possibility to filter LSA7 (or = LSA5) > type routes . RFC 3101 defines how router B or C can easily control what type 7 routes = are aggregated or prevented from being advertised outside the NSSA. There is no provision for LSA filtering. Since an IGP is typically under a single administrative domain it would be better not to advertise the LSAs you don't want on the originator. > > > If A-----B--NSSA--C--D > > router A is ASBR with injecting 1.1.1.1/24 as TYPE5 > i don't want router C knows that route. > > At the moment, router C use fake route=3Dhis_default route to router D = (Router > D is announcing this route via RIP... etc) > > Is it a target of working group or is it a target of soft implementatio= n ? > > A.Binder --=20 Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 18 15:21:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14553 for ; Thu, 18 Dec 2003 15:21:49 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C7C85B@cherry.ease.lsoft.com>; Thu, 18 Dec 2003 15:21:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64862147 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Dec 2003 15:21:45 -0500 Received: from 63.150.47.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Dec 2003 15:11:44 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Does anyone has experience with operationally down interface, which can still be IP reachable? Thread-Index: AcPFe4wbE/eB2NzgSSeGBPiz/QnLRQAJlEOQ Message-ID: Date: Thu, 18 Dec 2003 12:11:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Mukesh Hira Subject: Re: Does anyone has experience with operationally down interface, which can still be IP reachable? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Yes, I've done this for a special purpose - management stations use the = IP address of one particular interface as a handle to communicate with = the node, so even if this interface is down, we've had to keep it IP = reachable. I was able to do this by changing the subnet mask to /32, = which tells the stack that no other node is reachable on the interface. = However, the interface IP address is still exported into all the routing = protocols as a /32 route (host-specific route), this keeping it IP = reachable via other interfaces on the node. - Mukesh -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Dan Dovolsky Sent: Thursday, December 18, 2003 7:28 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Does anyone has experience with operationally down interface, which can still be IP reachable? Does anyone has experience with operationally down interface, which = still can be IP reachable? Thanks, Dan Dovolsky. ddovolsky@movaz.com From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 18 15:29:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14936 for ; Thu, 18 Dec 2003 15:29:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C7C844@cherry.ease.lsoft.com>; Thu, 18 Dec 2003 15:29:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64862488 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Dec 2003 15:29:52 -0500 Received: from 132.177.123.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Dec 2003 15:19:51 -0500 Received: from iol.unh.edu (scrappy.iol.unh.edu [132.177.118.198]) by io.iol.unh.edu (8.12.10/8.12.10) with ESMTP id hBIKIsoF028864; Thu, 18 Dec 2003 15:18:54 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.9) Gecko/20020503 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100, required 5, USER_IN_WHITELIST -100.00) Message-ID: <3FE20CBF.1020608@iol.unh.edu> Date: Thu, 18 Dec 2003 15:23:27 -0500 Reply-To: Mailing List Sender: Mailing List From: Mike Cleary Subject: Advertising Type-7 LSAs for a defaul route Comments: cc: bahill@iol.unh.edu, eaburns@iol.unh.edu, "Kari L. Revier" To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Greetings, I am a tester for the UNH-IOL routing consortium and I was wondering if anyone can help me. I am working on developing a test suite for testing OSPF-NSSA. I was wondering if anyone knows how to make a Type-7 that advertises a default route. The test should test section 2.4 and section 2.7. The part of the RFC that I am trying to test is described by this: NSSA border routers must originate an LSA for the default destination into all their directly attached NSSAs in order to support intra-AS routing and inter-AS routing. This default destination is advertised in either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7. If anyone knows of a test setup that I can use to create a Type-7 LSA as described above it would be greatly appreciated. Thanks, -Mike -- ********************************************* Michael Cleary Email: mcleary@iol.unh.edu Routing Consortium UNH InterOperability Lab 121 Technology Dr., Suite 2, Durham, NH 03824 Phone: 603-862-3941 http://www.iol.unh.edu ********************************************* From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 18 15:44:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16517 for ; Thu, 18 Dec 2003 15:44:17 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C7C87F@cherry.ease.lsoft.com>; Thu, 18 Dec 2003 15:44:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64863550 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Dec 2003 15:44:14 -0500 Received: from 65.160.128.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Dec 2003 15:34:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Does anyone has experience with operationally down interface, which can still be IP reachable? Thread-Index: AcPFe7WVcu6lM6SfRl67ApN/Nreg2gAKV/FQ Message-ID: <10C3A30F132FCC4D8630A7C17FBA43F606D01A@megamail.internetphotonics.com> Date: Thu, 18 Dec 2003 15:35:23 -0500 Reply-To: Mailing List Sender: Mailing List From: Phanidhar Koganti Subject: Re: Does anyone has experience with operationally down interface, which can still be IP reachable? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Yes, we have done it in our system where the IP address assigned to the = management interface is used as the router ID, so we populate that to = all our neighbors which are connected through other interfaces using our = custom ECC.=20 So even when the management interface is operationally down, we achieve = reach ability by not bringing him down administratively and also change = the netmask to 32 bits. Changing netmask to 32 bits does two things, it = removes the interface route which will force the return traffic to go = through the other interfaces. This is needed if the routing protocol is = not running on interface which went down operationally. Hope this helps. Phani Koganti Internet Photonics Inc. -----Original Message----- From: Dan Dovolsky [mailto:ddovolsky@MOVAZ.COM] Sent: Thursday, December 18, 2003 10:28 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Does anyone has experience with operationally down interface, which can still be IP reachable? Does anyone has experience with operationally down interface, which = still can be IP reachable? Thanks, Dan Dovolsky. ddovolsky@movaz.com From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 18 15:47:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16607 for ; Thu, 18 Dec 2003 15:47:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C7C981@cherry.ease.lsoft.com>; Thu, 18 Dec 2003 15:47:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64865022 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Dec 2003 15:47:05 -0500 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Dec 2003 15:47:05 -0500 Received: from homejtm01a43f8 (unverified [24.5.244.52]) by ucmmail.com (Rockliffe SMTPRA 5.3.6) with ESMTP id for ; Thu, 18 Dec 2003 15:46:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <000c01c3c5a9$a102b540$6400a8c0@homejtm01a43f8> Date: Thu, 18 Dec 2003 12:58:03 -0800 Reply-To: Mailing List Sender: Mailing List From: Farshad Tavallaei Subject: Re: Advertising Type-7 LSAs for a defaul route To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FE20CBF.1020608@iol.unh.edu> Precedence: list Content-Transfer-Encoding: 7bit Mike, Have you tried creating a static default route and then redistributing it into OSPF? Farshad -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Cleary Sent: Thursday, December 18, 2003 12:23 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Advertising Type-7 LSAs for a defaul route Greetings, I am a tester for the UNH-IOL routing consortium and I was wondering if anyone can help me. I am working on developing a test suite for testing OSPF-NSSA. I was wondering if anyone knows how to make a Type-7 that advertises a default route. The test should test section 2.4 and section 2.7. The part of the RFC that I am trying to test is described by this: NSSA border routers must originate an LSA for the default destination into all their directly attached NSSAs in order to support intra-AS routing and inter-AS routing. This default destination is advertised in either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7. If anyone knows of a test setup that I can use to create a Type-7 LSA as described above it would be greatly appreciated. Thanks, -Mike -- ********************************************* Michael Cleary Email: mcleary@iol.unh.edu Routing Consortium UNH InterOperability Lab 121 Technology Dr., Suite 2, Durham, NH 03824 Phone: 603-862-3941 http://www.iol.unh.edu ********************************************* From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 18 18:07:53 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26732 for ; Thu, 18 Dec 2003 18:07:52 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C7CDE6@cherry.ease.lsoft.com>; Thu, 18 Dec 2003 18:07:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64880346 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Dec 2003 18:07:51 -0500 Received: from 132.177.123.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Dec 2003 18:07:51 -0500 Received: from iol.unh.edu (scrappy.iol.unh.edu [132.177.118.198]) by io.iol.unh.edu (8.12.10/8.12.10) with ESMTP id hBIN6soF017101 for ; Thu, 18 Dec 2003 18:06:54 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.9) Gecko/20020503 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000c01c3c5a9$a102b540$6400a8c0@homejtm01a43f8> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100, required 5, USER_IN_WHITELIST -100.00) Message-ID: <3FE23421.60308@iol.unh.edu> Date: Thu, 18 Dec 2003 18:11:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Mike Cleary Subject: Re: Advertising Type-7 LSAs for a defaul route To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit How would you configure a static default route? I know how to configure static routes but do you mean to take and create 0.0.0.0 as a static route? Farshad Tavallaei wrote: >Mike, > >Have you tried creating a static default route and then redistributing >it into OSPF? > >Farshad > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike >Cleary >Sent: Thursday, December 18, 2003 12:23 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Advertising Type-7 LSAs for a defaul route > >Greetings, >I am a tester for the UNH-IOL routing consortium and I was wondering if >anyone can help me. I am working on developing a test suite for testing >OSPF-NSSA. I was wondering if anyone knows how to make a Type-7 that >advertises a default route. The test should test section 2.4 and >section 2.7. The part of the RFC that I am trying to test is described >by this: >NSSA border routers must originate an LSA for the default destination >into all their directly attached NSSAs in order to support intra-AS >routing and inter-AS routing. This default destination is advertised in >either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7. >If anyone knows of a test setup that I can use to create a Type-7 LSA as >described above it would be greatly appreciated. >Thanks, >-Mike > >-- >********************************************* >Michael Cleary Email: mcleary@iol.unh.edu >Routing Consortium UNH InterOperability Lab >121 Technology Dr., Suite 2, Durham, NH 03824 >Phone: 603-862-3941 http://www.iol.unh.edu >********************************************* > -- ********************************************* Michael Cleary Email: mcleary@iol.unh.edu Routing Consortium UNH InterOperability Lab 121 Technology Dr., Suite 2, Durham, NH 03824 Phone: 603-862-3941 http://www.iol.unh.edu ********************************************* From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 18 18:38:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28719 for ; Thu, 18 Dec 2003 18:38:20 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C7CE46@cherry.ease.lsoft.com>; Thu, 18 Dec 2003 18:38:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64882524 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Dec 2003 18:38:19 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Dec 2003 18:38:19 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B5754A1EA6D for ; Thu, 18 Dec 2003 15:38:18 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20123-03 for ; Thu, 18 Dec 2003 15:38:18 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.26]) by prattle.redback.com (Postfix) with ESMTP id F0EDDA1EA66 for ; Thu, 18 Dec 2003 15:38:11 -0800 (PST) References: <000c01c3c5a9$a102b540$6400a8c0@homejtm01a43f8> <3FE23421.60308@iol.unh.edu> Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Thu, 18 Dec 2003 18:37:47 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: Advertising Type-7 LSAs for a defaul route To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3FE23421.60308@iol.unh.edu> Precedence: list Content-Transfer-Encoding: quoted-printable On Thu, 18 Dec 2003 18:11:29 -0500, Mike Cleary wro= te: > How would you configure a static default route? I know how to configur= e > static routes but do you mean to take and create 0.0.0.0 as a static ro= ute? Farshad, Note that an RFC 3101 compliant OSPF implementation will originate a default LSA as a consequence of being an NSSA ABR. RFC 1587 did not expli= citly require this. If the ABR is not advertising summaries (i.e., type 3 LSAs)= , a type 3 default LSA will be originated (similar to what is done for a st= ub area). If the ABR is advertising type 3 summaries, the default LSA will b= e a type 7. Thanks, Acee > > Farshad Tavallaei wrote: > >> Mike, >> >> Have you tried creating a static default route and then redistributing >> it into OSPF? >> >> Farshad >> >> >> -----Original Message----- >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mik= e >> Cleary >> Sent: Thursday, December 18, 2003 12:23 PM >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: Advertising Type-7 LSAs for a defaul route >> >> Greetings, >> I am a tester for the UNH-IOL routing consortium and I was wondering i= f >> anyone can help me. I am working on developing a test suite for testi= ng >> OSPF-NSSA. I was wondering if anyone knows how to make a Type-7 that >> advertises a default route. The test should test section 2.4 and >> section 2.7. The part of the RFC that I am trying to test is describe= d >> by this: >> NSSA border routers must originate an LSA for the default destination >> into all their directly attached NSSAs in order to support intra-AS >> routing and inter-AS routing. This default destination is advertised = in >> either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7. >> If anyone knows of a test setup that I can use to create a Type-7 LSA = as >> described above it would be greatly appreciated. >> Thanks, >> -Mike >> >> -- >> ********************************************* >> Michael Cleary Email: mcleary@iol.unh.edu >> Routing Consortium UNH InterOperability Lab >> 121 Technology Dr., Suite 2, Durham, NH 03824 >> Phone: 603-862-3941 http://www.iol.unh.edu >> ********************************************* >> > > > -- > ********************************************* > Michael Cleary Email: mcleary@iol.unh.edu > Routing Consortium UNH InterOperability Lab > 121 Technology Dr., Suite 2, Durham, NH 03824 > Phone: 603-862-3941 http://www.iol.unh.edu > ********************************************* --=20 Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 18 19:17:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00634 for ; Thu, 18 Dec 2003 19:17:36 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C7CF63@cherry.ease.lsoft.com>; Thu, 18 Dec 2003 19:17:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64887296 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Dec 2003 19:17:36 -0500 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Dec 2003 19:17:36 -0500 Received: from homejtm01a43f8 (unverified [24.5.244.52]) by ucmmail.com (Rockliffe SMTPRA 5.3.6) with ESMTP id for ; Thu, 18 Dec 2003 19:17:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Message-ID: <000401c3c5c6$f4a9a1a0$6400a8c0@homejtm01a43f8> Date: Thu, 18 Dec 2003 16:27:58 -0800 Reply-To: Mailing List Sender: Mailing List From: Farshad Tavallaei Subject: Re: Advertising Type-7 LSAs for a defaul route To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Excellent point! Thanx Acee. I guess the question to Mike should have been: what kind of router(s) are you using for your test? Are they RFC 3101 compliant? I am sure that with Acee's excellent input, Mike is already on his way looking into that.... -farshad -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Thursday, December 18, 2003 3:38 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Advertising Type-7 LSAs for a defaul route On Thu, 18 Dec 2003 18:11:29 -0500, Mike Cleary wrote: > How would you configure a static default route? I know how to configure > static routes but do you mean to take and create 0.0.0.0 as a static route? Farshad, Note that an RFC 3101 compliant OSPF implementation will originate a default LSA as a consequence of being an NSSA ABR. RFC 1587 did not explicitly require this. If the ABR is not advertising summaries (i.e., type 3 LSAs), a type 3 default LSA will be originated (similar to what is done for a stub area). If the ABR is advertising type 3 summaries, the default LSA will be a type 7. Thanks, Acee > > Farshad Tavallaei wrote: > >> Mike, >> >> Have you tried creating a static default route and then redistributing >> it into OSPF? >> >> Farshad >> >> >> -----Original Message----- >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike >> Cleary >> Sent: Thursday, December 18, 2003 12:23 PM >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: Advertising Type-7 LSAs for a defaul route >> >> Greetings, >> I am a tester for the UNH-IOL routing consortium and I was wondering if >> anyone can help me. I am working on developing a test suite for testing >> OSPF-NSSA. I was wondering if anyone knows how to make a Type-7 that >> advertises a default route. The test should test section 2.4 and >> section 2.7. The part of the RFC that I am trying to test is described >> by this: >> NSSA border routers must originate an LSA for the default destination >> into all their directly attached NSSAs in order to support intra-AS >> routing and inter-AS routing. This default destination is advertised in >> either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7. >> If anyone knows of a test setup that I can use to create a Type-7 LSA as >> described above it would be greatly appreciated. >> Thanks, >> -Mike >> >> -- >> ********************************************* >> Michael Cleary Email: mcleary@iol.unh.edu >> Routing Consortium UNH InterOperability Lab >> 121 Technology Dr., Suite 2, Durham, NH 03824 >> Phone: 603-862-3941 http://www.iol.unh.edu >> ********************************************* >> > > > -- > ********************************************* > Michael Cleary Email: mcleary@iol.unh.edu > Routing Consortium UNH InterOperability Lab > 121 Technology Dr., Suite 2, Durham, NH 03824 > Phone: 603-862-3941 http://www.iol.unh.edu > ********************************************* -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 19 01:01:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12950 for ; Fri, 19 Dec 2003 01:01:48 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C7D661@cherry.ease.lsoft.com>; Fri, 19 Dec 2003 1:01:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64923580 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 19 Dec 2003 01:01:43 -0500 Received: from 66.28.8.211 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 19 Dec 2003 01:01:43 -0500 X-VirusChecked: Checked X-Env-Sender: rmalhotra@bankofny.com X-Msg-Ref: server-16.tower-20.messagelabs.com!1071813702!1793703 X-StarScan-Version: 5.1.15; banners=bankofny.com,-,- Received: (qmail 11131 invoked from network); 19 Dec 2003 06:01:42 -0000 Received: from unknown (HELO lgsbrc01.bankofny.com) (160.254.107.25) by server-16.tower-20.messagelabs.com with SMTP; 19 Dec 2003 06:01:42 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Fri, 19 Dec 2003 01:01:41 -0500 Reply-To: Mailing List Sender: Mailing List From: rmalhotra@BANKOFNY.COM Subject: Ravi Malhotra is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I will be out of the office starting 12/18/2003 and will not return until 12/22/2003. I will respond to your message when I return. Thank You, Ravi Malhotra ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. From owner-ospf@PEACH.EASE.LSOFT.COM Sun Dec 21 11:10:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27920 for ; Sun, 21 Dec 2003 11:10:28 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C80774@cherry.ease.lsoft.com>; 21 Dec 2003 11:10:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 65193054 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 21 Dec 2003 11:10:24 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 21 Dec 2003 11:10:24 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0559C3524F4 for ; Sun, 21 Dec 2003 08:10:24 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22481-07 for ; Sun, 21 Dec 2003 08:10:23 -0800 (PST) Received: from acee-laptop (unknown [172.31.254.70]) by prattle.redback.com (Postfix) with ESMTP id 23CF63524F3 for ; Sun, 21 Dec 2003 08:10:23 -0800 (PST) References: <16265296676.20031219183158@psg.com> Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 User-Agent: Opera7.23/Win32 M2 build 3227 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable Message-ID: Date: Sun, 21 Dec 2003 11:10:05 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Fwd: AD-review comments on draft-ietf-ospf-2547-dnbit To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <16265296676.20031219183158@psg.com> Precedence: list Content-Transfer-Encoding: quoted-printable FYI - AD Comments on DN bit drafts. ------- Forwarded message ------- From: Alex Zinin To: Acee Lindem , Rohit Dube Subject: AD-review comments on draft-ietf-ospf-2547-dnbit Date: Fri, 19 Dec 2003 18:31:58 -0800 > Hi guys, > > See my comments below, pls. > Acee, Rohit, feel free to fwd this to the WG mailing list. > > Technical: > > - The "Security Considerations" section needs to be included > > - I assume that the DN bit is set for type-3 and type-5 LSAs > only. Seems that the document needs to spell this out and > state how the DN-bit set to 1 in other LSAs should be treated. > > While fixing the above, please address the following editorial > comments: > > - Please remove citations from the abstract > > - Please include standard IPR and Copyright sections (see RFC 2026 > for more info) > > Thanks > --=20 Acee